TechToast

DGX Spark 2대, 1M 컨텍스트 도전기. (Qwen3.8-Flash-Next day-0)주력 모델의 기준은 처음부터 고정돼 있었습니다. 1M 토큰, 그리고 어느 정도의 멀티유즈. 하드웨어는 DGX Spark 2대였고, GB10에 128GB 통합 메모리를 품은 기기를 200Gbps RoCE로 엮은 구성입니다. 사양서만 놓고 보면 "이건 되겠지" 싶은 조합이었죠. 결론부터 정리하면, 262K 서빙은 성공했고 300K needle도 통과했습니다. 완전한 1M는 아직 아닙니다. prefill을 약 365K 처리하는 지점에서 멈췄어요. 부분 성공인데, 한계는 명확하게 잡힌 상태입니다. 달리 말하면 "1M라는 문 앞까지는 갔는데, 문고리를 잡는 순간 멈춘" 그런 상황이었습니다.day-0 스택Flash-Nex..

[세컨드브레인 개발기] 16. 122B와 27B — 커도, 빠른 것도 다 이긴 건 아니었다15편 마지막에 122B 모델로 갈아탔습니다. 큰 모델로 바꾸면 다 나아질 거라 믿었죠. 그런데 직접 비교해 보니, 더 큰 모델이 이긴 건 속도뿐이었습니다. 지능은 아니었어요. 이 머신에는 사실 두 개의 후보가 있었는데, 크기로 보면 122B, 품질로 보면 27B였습니다. 그 둘을 이 머신에서 실제로 재보고 정리한 이야기입니다.올리고 나서 좋은 말만 적어뒀다 122B를 올리던 시절의 기록에는 좋은 말만 가득합니다. 모델 항목에는 "122B는 훨씬 똑똑함", 품질에는 "프런티어급"이라고 적혀 있고, 속도는 85~90 tok/s로 목표였던 81을 넉넉히 넘겼습니다. 컨텍스트도 256K로 늘었어요. 기록만 읽으면 이 머신..

[세컨드브레인 개발기] 15. 주력 모델이 3번 바뀌었다. 사유도 각각 달랐다.14편은 빚을 남기고 끝났습니다. "공식이 없으면 설명할 수 없는 숫자"라고 쓰고, 이 이야기는 다음 편에서 풀어야겠다고 했죠. 이 편은 그 빚을 갚는 편입니다. 그러다 보니 아직 아무 편에도 안 나온 이야기, 이 박스의 주력 자리에 맨 처음 무엇이 있었는지도 같이 쓰게 됐어요. 2개월 동안 주력 자리는 세 번 바뀌었습니다. 27B에서 35B-A3B로는 속도 때문에, A3B에서 27B로는 품질 때문에, 27B에서 122B로는 컨텍스트 때문에. 그리고 그 앞, 27B가 주력이 되기 전의 구간은 기록이 제일 얇은 곳입니다. 어떤 교체는 날짜가 있고 어떤 교체는 날짜가 없어요. 사유도 기록에 있는 게 있고, "기록에 없다"고밖에 쓸..

[세컨드브레인 개발기] 14. GB10 에서 배운 것 — 속도는 대역폭을 활성 파라미터로 나눈 값이다이 시리즈의 3부는 에이전트가 창고를 쓰는 이야기였습니다. 그리고 그 마지막 편에서, 하나의 빚을 남기고 3부를 닫았어요. 그 무렵 Hermes의 브레인은 27B였고, 그 27B가 왜 그렇게 느렸는지는 다음 부에서 풀겠다고 했습니다. 사실 그보다 더 일찍, 12편에서도 같은 질문을 접어둔 적이 있습니다. 모델이 느리다는 것 자체는 확인했는데, 왜 하필 그 모델이 그렇게 느린지는, 모델의 문제라기보다 그것을 올린 기계가 초당 얼마를 읽어낼 수 있느냐의 문제라며 그 자리에서는 접어두었죠. 이제 4부가 시작됐으니 그 빚을 갚습니다. 이 편의 주제는 하드웨어입니다. 창고도, 에이전트도, 도구도 아닌, 그 모든 것..

AI 직원 11명 고용기.2023년 7월, 중국 칭화대학 NLP 연구소가 챗GPT만으로 게임회사를 하나 세웠습니다. 쑨마오쑹 교수 지도 아래 만든 시연인데, 회사 이름은 ChatDev였어요. 게임타이쿤에나 나올 법한 구성을 그대로 갖췄습니다. CEO부터 CTO, CPO, CRO, 프로그래머, 디자이너까지, 회사의 모든 직원이 전부 ChatGPT 봇입니다. 회사에 아이디어 하나만 던져주면 설계부터 프로그래밍, 테스트, 문서화까지 전 과정을 AI가 알아서 완성하고, 사람이 개입하는 유일한 지점은 초기 아이디어 제공뿐이라는 게 이 시연의 핵심이었습니다. 게임 하나를 만드는 데 평균 409.84초, 약 7분이 걸렸어요. 가장 빠를 때는 3분도 안 걸렸습니다. 게임당 평균 48.5K 토큰, 비용은 평균 0.2..

[세컨드브레인 개발기] 13. Hermes 에게 자율성을 얼마나 줄 수 있나 — 실측지난 편에서 남은 질문이 하나 있었습니다. 브리지가 살아나고, 대답이 3분에서 15초로 내려오고 나니, 이제는 그 에이전트에게 일을 얼마나 맡길 수 있을까였습니다. 여태까지는 에이전트가 질문을 받고 답하는 쪽만 보고 있었는데, 슬랙 저편에서 스스로 판단해서 뭔가를 만들어 내는 모습은 한 번도 본 적이 없었어요. 감으로 답하지 않으려고, 일을 실제로 던져봤습니다. kanban 보드에 다섯 개의 태스크를 올리고, 세 명의 워커에게 나눠 주고, 밤 열 시 반부터 새벽 한 시까지 지켜봤습니다. 그 실측이 이 편의 전부입니다. 결론부터 말하면, 일을 끝까지 해내는 경우와 중간에 죽는 경우가 갈리는 지점이 꽤 선명하게 보였고, 그 ..

[세컨드브레인 개발기] 12. Slack 봇이 3분 걸린 이유 — 원인이 3겹이었다플랫폼을 Hermes로 갈아타고 브리지가 다시 살아났습니다. 그런데 살아나기는 했는데, 그다음 문제가 바로 그 자리에서 기다리고 있었어요. 대답이 오는 데 걸리는 시간이었습니다. 슬랙에 질문을 던지면, 입력 표시는 뜨는데 대답이 오기까지 꼬박 3분이 걸렸습니다. 죽어 있는 것도 아니고, 살아 있는 것도 아니고, 그 중간 어딘가에서 하염없이 기다리는 상태였죠. 플랫폼을 바꾸는 일은 그 자체로 끝이 아니라 그 위에서 문제가 어디서 나는지가 달라지는 일이라는 걸 또 한 번 실감했습니다. 이번에는 그 문제가 통로가 아니라 시간이었어요. 이 편은 그 3분을 세 번에 걸쳐 고친 이야기입니다. 같은 증상을, 세 번, 서로 다른 이유로...

[세컨드브레인 개발기] 11. OpenClaw 를 버리고 Hermes 로 간 이유브레인에 MCP를 달고, 에이전트가 창고에 쓰는 손을 얻었습니다. 그런데 그 이야기에는 전제가 하나 숨어 있어요. 창고를 쓰는 쪽, 즉 에이전트가 제대로 서 있어야 한다는 전제입니다. 3부가 묻는 것은 창고를 쓰는 쪽이 누구인가인데, 그 쪽을 통째로 갈아탄 일이 이 편의 중심입니다. MCP가 붙은 뒤로 얼마 지나지 않아, 에이전트 플랫폼을 OpenClaw에서 Hermes로 바꿨습니다. 이유는 하나, 남의 버그였어요. 지난 편에서 예고한 그 도구들의 이야기는 다음 편에서 풀기로 하고, 이 편은 그 도구들이 달려 있던 플랫폼의 이야기입니다. 하나씩 보겠습니다.게이트웨이와 페어링 그때까지 에이전트 플랫폼으로 쓰던 것은 OpenCl..

[세컨드브레인 개발기] 10. 브레인에 MCP 를 달다 (읽기 → 쓰기)지난 편 끝에서, 입력은 이제 들어올 만큼 들어온다, 다음 문제는 채우는 것이 아니라 쓰는 것이라고 했습니다. 그 말이 이 편이 하는 일의 예고였어요. 이 편부터 시리즈의 부가 바뀝니다. 2부가 입력을 만드는 일이었다면, 3부는 그 입력을 쓰는 쪽이 누구인가의 이야기입니다. 파이프라인은 정해진 시간에 정해진 일을 하지만, 에이전트는 대화 속에서 무엇이 중요한지를 스스로 가릅니다. 그 차이가, 창고에 들어오는 것의 성격까지 바꿔요. 지금까지 브레인에 무언가 들어오는 길은 하나같이 기계였습니다. 파이프라인이 걷고, 회의록이 쌓이고, 논문 리뷰가 떨어졌죠. 사람이 직접 넣는 일도 있었지만, 그건 언제나 손이 필요했습니다. 그런데 이번에는 ..

[세컨드브레인 개발기] 9. 매주 월요일 아침, 논문이 온다.지난 편 끝에서, 논문은 매주 월요일 아침에 모여 한국어 요약으로 만들어져 텔레그램으로 온다고 했습니다. 그 이야기예요. 메일이 지금 일어나는 일을 남긴다면, 논문은 앞으로 할 일을 정하는 재료인데, 그 재료는 들어오는 것만으로는 부족하고 읽혀야 합니다. 하루에 읽을 수 있는 논문은 한정되어 있고, 쏟아지는 논문은 그보다 많으니, 이 자동화는 읽기를 대신하지 않기로 했습니다. 대신 고르는 일을 맡기로 했어요. 메일 편에서는 받는이를 기준으로 갈랐는데, 논문은 어떤 기준으로 갈랐는지가 이 편의 중심입니다. 무엇을 골랐는지, 하나씩 보겠습니다.매주 월요일 아침에 온다 첫 버전은 맥의 launchd가 매주 월요일 아홉 시에 깨우는 작업이었습니다. 논..