[세컨드브레인 개발기] 15. 주력 모델이 3번 바뀌었다. 사유도 각각 달랐다.

14편은 빚을 남기고 끝났다. "공식이 없으면 설명할 수 없는 숫자"라고 쓰고, 이 이야기는 다음 편에서 풀어야겠다고 했다. 이 편은 그 빚을 갚는 편이고, 그러다 보니 아직 아무 편에도 안 나온 이야기, 이 박스의 주력 자리에 맨 처음 뭐가 있었는지도 같이 쓰게 됐다. 2개월, 주력 자리는 세 번 바뀌었다. 27B 에서 35B-A3B 로는 속도로, A3B 에서 27B 로는 품질로, 27B 에서 122B 로는 컨텍스트로. 그리고 그 앞, 27B 가 주력이 되기 전의 구간은 기록이 제일 얇은 곳이다. 어떤 교체는 날짜가 있고 어떤 교체는 날짜가 없고, 사유도 기록에 있는 게 있고, 기록에 없다고밖에 쓸 것이 없는 게 있다. 제일 얇은 데부터, 순서대로 따라가 보자.

 

시점	모델	양자화	실측 속도	바꾼 이유
06-21~28 기록	Nemotron-3-Super-120B-A12B	NVFP4	스텝당 10~30초	— (별 박스 GUI 자동화용)
날짜 미기재	Qwen3.5-27B	FP8	8 tok/s	기록 없음
날짜 미기재	Qwen3.6-35B-A3B	NVFP4	168 tok/s	속도 (134초 → 2.7초)
07-24~25	Qwen3.6-27B	NVFP4 + MTP3	13~15 tok/s	품질 (A3B가 얇게 느껴짐)
07-25~27	Qwen3.5-122B-A10B	INT4+FP8	29 → 81 tok/s	256K 안정성

 

첫 번째 주력 자리, Nemotron

27B 보다 앞서, 이 박스의 vLLM 자리는 전혀 다른 일을 하던 모델이 차지하고 있었다. 기록은 06-21 과 06-28 이다. 그 무렵 별개의 Windows 박스에서 GUI 자동화 라인이 돌고 있었고, OmniParser 가 화면 하나를 텍스트와 좌표로 뽑으면, 모델이 다음에 어디를 누를지 판단하는 구조였다. 기록 원문에는 OmniParser 파싱이 한 화면당 3.5초 정도, 모델 판단이 스텝당 10에서 30초 정도라고 남아 있다. 실시간은 꿈도 못 꾸는 속도였지만, 단계형 자동화에는 충분했다. 모델은 Nemotron-3-Super-120B-A12B-NVFP4 였고, 기록의 vLLM 접속 정보는 이 박스의 IP 를 가리키고 있었다. 2080 Ti 는 파싱 쪽에 있었고, 120B 는 이 박스에 올라가 있었다. 이 조합에는 함정이 하나 있었다. Nemotron 은 복잡한 작업에서 긴 추론을 붙이고, 그 추론 토큰이 출력 예산을 다 써버리면, max_tokens 가 짧으면 마지막 JSON 이 반밖에 잘려 나오지 않는다. 기록의 해법은 max_tokens 를 4096 으로 올리고, 최종 JSON 추출 로직을 보강하는 것이었다. 화면 캡처랑 마우스 조작은 데스크톱 세션에서만 되며 SSH로는 불가능하다는 것도 기록에 있다. 자동화도 아직 완성 전이었으니, 주력 자리가 브레인을 위해 있는 것도 아니었다. 6월 말 기록과 12편 서사 사이 어딘가, 주력 자리는 Qwen3.5-27B 로 넘어갔다. 초당 8 토큰과 134초 쿼리, 그리고 12편의 3분 봇 이야기 전부, 27B 에서 시작한다. 그 이관의 날짜와 이유는, 기록에 남겨두지 않았다.

 

 

나중, 08-01 기록에서 그 2080 Ti 박스가 35B-A3B 로컬 서빙 후보로 한 번 더 검토된 적이 있다. 결론은 "된다, 단 램 대역폭 42.7GB/s 가 발목"이었다. 작은 박스도 결국 같은 공식에서 벗어날 수 없었다.

 

 

그때는 비추천이었던 모델

07-14 기록에는 "Qwen3.5-122B 비추천"이라는 판단이 있다. 그런데 그건 다른 박스에 대한 것이었다. 당시 비디오메모리 144GB 의 L40 3장 서버에 어떤 모델을 올리나를 보고 있었는데, 결론은 122B 가 27B 와 동급이거나 근소 우위일 뿐, 파라미터를 94B 더 쓰는 데 비해 성능 향상이 미미하다는 것이었다. 기록의 요구는 128k 에서 512k 까지였고, 그 서버에서 품질이 확실히 앞선 모델은 메모리가 그치자 128k 가 한계였다. 그 박스에서는 파라미터가 귀했고, B 하나하나가 메모리를 깎았다. 기록에는 "Qwen 세대론"이라는 표현도 있다. 파라미터가 많다고 무조건 좋은 게 아니라, Qwen3.6-27B 가 Qwen3.5-122B 를 추월하는 경우가 많다는 것. 11일 뒤에, 이 박스에 그 모델이 올라갔다. 두 박스의 평가가 완전히 반전된 것이다. 모델이 바뀐 게 아니라, 귀한 게 달라진 것이다. 메모리 박스에서는 전체 파라미터가 귀하고, 이 박스에서는 활성 파라미터가 귀하다. 14편의 공식이 말하는 바 그대로, 활성 10B 에 파라미터당 1바이트이면 분모는 10GB 안팎이고, 전체가 35 인지 122 인지는 속도에는 무관하다.

29 tok/s, 그리고 gibberish

중간은 14편이 이미 썼다. A3B 로 갔다가 얇게 느껴져 27B 로 한 번 돌아가고, 그다음 시선이 122B 로 갔다는 것. 14편이 한 문장으로 넘긴 그 구간에는, 07-24 기록에 A3B 자체의 A/B 테스트가 들어 있다. NVFP4 버전의 벤치 168 토큰에 대해 FP8 버전이 208 토큰으로 이겨, 기본 모델은 FP8 버전으로 정해졌다. 그리고 07-25 기록에 이르러 주력은 다시 27B 다. 07-25 기록의 표는 그것을 "27B-FP8 (기존)" 이라 쓰고 속도를 약 15 토큰으로 적고 있고, 14편의 기록은 MTP3 라는 여러 토큰 예측을 얹은 버전, 13에서 15 토큰대라 한다. 돌아간 27B 가 처음의 8 토큰이던 27B 가 아니라는 뜻이다. 이 편은 122B 가 실제로 올라간 07-25 기록에서 이어 받는다. INT4 와 FP8 을 섞은 하이브리드 양자화, 256K 컨텍스트. 이사 첫 단계는 집 정리였다. 기록에는 중복 캐시 61GB 를 지우며 디스크 여유가 189GB 에서 250GB 로 늘었다고 있다. 그리고 첫 기동에서, 출력은 gibberish 였다. 스톡 vLLM 이 INT4+FP8 하이브리드를 돌리면, 나오는 토큰이 말이 아니었다. 기록의 해법은 패치 한 개, patch_inc_hybrid.py 였고, 그 효과는 기록 원문대로 "FP8 shared-expert 레이어 정상 디스패치"였다. 더 깊은 곳, 스톡 런타임의 어디가 어긋나 있었는지는 기록이 말해주지 않는다. 패치를 얹고 나니 gibberish 는 사라졌고, 07-25 기록상 한국어와 논리적 추론은 정상이었다. 이 편이 남기는 함정은 여기 있다. 이 박스에서 모델은 디스크 위의 가중치만은 아니다. 가중치에, 그것을 제대로 돌리는 런타임까지 합쳐서 모델이다. 122B 를 받아놓고 끝난 줄 아는 것은, gibberish 를 끝난 줄 아는 것이다.

 

 

스톡 속도부터 공식에 대입해 보면. 273 을 29 로 나누면 9.4 가 나온다. 토큰 하나당 약 9.4GB 를 읽는다는 뜻이고, 활성 파라미터 10B 를 파라미터당 1바이트 정도로 읽으면 10GB 가량이라, 29 가 바로 공식이 예측하는 값이다. 27B-FP8 의 8 은 27B 전체가 활성이었기 때문이고, 29 는 10B 만 활성이기 때문이다. 파라미터는 4.5배인데, 토큰 하나당 읽는 양은 반대로 3분의 1 수준으로 줄어든 것이다. 공식이 이 모델을 위해 고쳐진 것이 아니라, 이 모델이 공식에 들어간 것뿐이었다.

 

 

읽기 한 번에 12 토큰

29 tok/s 도 나쁜 숫자는 아니었다. 그런데 기록의 목표는 그보다 위에 있었다. 07-25 기록에 DFlash 스펙ulative 디코딩이 적용됐다. 별개의 드래프터(07-25 기록에는 z-lab/Qwen3.5-122B-A10B-DFlash 로 적혀 있다)가 12 토큰짜리 초안을 한 번에 만들고, 본 모델이 그것을 검증하는 식이다(07-26 기록 원문). 읽는 것이 병목인 상태에서는, 한 번의 읽기로 더 많은 토큰을 만드는 것 외에는 빠른 길이 없는데, 이 기법이 정확히 그 것이다. 07-25 기록상 적용 후 실측은 81 tok/s, 스톡의 약 2.8배였고, 첫 토큰까지의 지연(TTFT)은 2.3초에서 0.18초로, 기록의 표현 그대로 13배 줄었다고 한다. 07-26 기록의 숫자는 85에서 90 tok/s, 문서 목표치 81 을 초과했다고 적혀 있다. 같은 기록에는 INT8 lm-head v3(+33%) 같은 패치도 더 얹혀 있었고, KV 캐시는 1,390,157 토큰을 확보해 256K 요청 5개 이상을 동시 처리할 수준이었다고 있다. 메모리는 121GB 중 111GB 사용, 여유 10GB, 07-26 기록의 비고에는 DFlash 이후에도 그대로 유지된다고 있다. 그리고 07-26 기록이 옛 27B 를 256K "스왑 위험"이라 하고 새 모델을 "안정적"이라 쓰는 그 표가, 3번째 교체를 뒷받침하는 기록 속 사유다.

 

 

교체 자체는 아무도 모르게 하는 방식으로 했다. 07-25 기록에는 새 모델을 기존 시스템이 쓰던 이름, Qwen/Qwen3.6-27B-FP8 같은 참조로 별칭 등록했다고 있고, 07-26 기록에는 Qwen3.6-35B-A3B 이름도 같이 매핑했다. Hermes, brain_query, Gmail 자동화, 어느 쪽도 한 줄도 고치지 않은 채, 이름 뒤의 모델이 바뀐 것이다. 재부팅 이후에도 자동으로 돌아오도록 재시작 정책도 얹었다고 07-26 기록에 있다.

 

 

기록에는 하나 더 있다. 122B 로드를, 그 박스에서 돌고 있는 에이전트 쪽이 "OOM 으로 불가능"이라 선언해 두었던 것이다. 07-25 기록은 작업 목록 첫머리에 "Hermes 오진 정정"을 올리고 있고, 07-27 기록 원문에는 그 선언을 뒤집어, 패치된 vLLM 과 DFlash 로 "성공적으로 가동"했다고 남아 있다. 122B 가 안 들어간다고 단정했던 쪽은, 그 박스 그날까지의 주력인 27B 를 쓰고 있던 에이전트였다.

검증 대기

이 이야기의 마지막 기록은 07-27 이다. 그날 기록의 시점에서는, 컨테이너가 DFlash 모드로 재부팅 중이고 워밍업 후 실제 속도 검증이 대기 상태였다. 81 tok/s 는 07-25 기록이 실측이라고 보고하고, 07-26 기록이 초과했다고 하는 숫자지만, 기록 속 속도의 마지막 문장은 "완주"가 아니라 "대기"였다. 이야기는 여기서 깔끔하게 닫히지도 않는다. 08 월 서빙 구성 기록에는 122B 가 운용 중단이라 적혀 있고, 주력 자리는 다른 모델이 차지해 있다. 이 박스의 주력 자리는 아직까지도 넘어가고 있는 중이다. 다음 편에서는, 이 편은 못 답한 질문을 실측으로 본다. 122B 가 27B 보다 정말로 더 똑똑한지.