지난주 클라우드에 나온 2,840억 모델이 이미 노트북에서 돕니다
딥시크가 7월 31일 클라우드 API로 내놓은 V4-Flash는 총 2,840억 파라미터짜리 에이전트 모델입니다. 며칠 전 이 블로그에서 다룬 바로 그 모델입니다.
그런데 같은 모델이 지금 128GB 맥북프로에서 초당 34토큰으로 돌아갑니다. 2비트 동적 양자화로 96.5기가바이트까지 줄인 빌드입니다. 데이터센터 이야기가 아니라 책상 위 노트북 이야기입니다.
여기서 질문이 바뀝니다. 엔비디아의 생성형 AI 소프트웨어 총괄 조이 콘웨이가 정확히 짚었습니다. "책상 위 상자에서 돌릴 만큼 작은 모델들이 이제 충분히 좋아져서, 흥미로운 질문은 더 이상 돌릴 수 있느냐가 아니라 그걸로 무엇을 할 수 있느냐입니다."
지금 노트북에서 실제로 무엇이 도는가
숫자로 보면 감이 잡힙니다. 4비트 양자화 기준으로 파라미터 10억 개당 대략 0.5기가바이트가 필요합니다.
V4-Flash가 노트북에 들어간 방식이 흥미롭습니다. 전체를 똑같이 2비트로 누른 것이 아니라, 전문가 가중치는 2비트로 강하게 압축하고 민감한 층과 투영 행렬은 4비트에서 8비트로 남긴 동적 양자화입니다. 전문가 혼합 구조에서 대부분의 파라미터가 전문가에 몰려 있다는 점을 이용한 것입니다.
그런데 로컬은 무언가를 내줍니다
이 대목을 빼면 절반만 말하는 것이 됩니다.
문맥이 무너집니다. V4-Flash의 공식 사양은 100만 토큰인데, 노트북에서는 96.5기가바이트를 모델이 쓰고 남는 약 30기가바이트로 키값 캐시를 감당해야 합니다. 실제로 쓸 수 있는 것은 수만 토큰 수준입니다. 긴 문서 뭉치를 통째로 넣는 용도라면 로컬은 답이 아닙니다.
속도가 문맥에 따라 떨어집니다. 짧은 프롬프트에서 초당 34토큰이던 것이 문맥 1만 1,700토큰에서 초당 26토큰으로 내려갑니다.
품질 손실이 아직 측정되지 않았습니다. 발표된 점수는 전부 전체 정밀도 기준입니다. 2비트로 누른 상태의 독립 측정은 아직 공개되지 않았습니다. 참고로 전체 정밀도에서도 저장소 규모 코딩은 클로드 오푸스 4.8에 크게 뒤집니다(NL2Repo 54.2 대 69.7).
로컬 모델은 짧은 문맥의 반복 작업에 맞고, 긴 문맥과 어려운 추론은 여전히 프런티어 쪽입니다. 그런데 이 구분이 바로 다음 이야기의 전제가 됩니다.
그래서 라우터가 중요해집니다
콘웨이의 표현이 이 구조를 압축합니다. "우리는 프런티어 모델과 오픈 모델을 함께 쓸 수 있는 세상을 좋아합니다." 그가 말하는 모델들의 시스템은 특화된 로컬 모델이 일상적이고 비용에 민감하거나 정보를 밖으로 내보내면 안 되는 작업을 맡고, 더 큰 프런티어 모델이 복잡한 추론을 맡는 구조입니다. 그리고 그 사이에 어느 쪽으로 보낼지 정하는 라우터가 놓입니다.
숫자가 이 구조의 동기를 설명합니다. 실무 보고들은 에이전트 작업의 60~80퍼센트를 값싼 모델이 충분히 처리하고 나머지 20~40퍼센트에서만 프런티어 능력이 의미 있게 필요하다고 말합니다. 그리고 프런티어와 값싼 모델의 토큰당 가격 차이는 50배에서 200배입니다.
라우팅을 제대로 붙인 팀들이 보고하는 청구서 절감은 40퍼센트에서 85퍼센트 범위입니다. 학술 쪽에서도 비슷한 결과가 나왔습니다. 라우트LLM 연구는 비용을 85퍼센트 줄이면서 상위 모델 품질의 95퍼센트를 유지했다고 보고합니다.
라우팅의 어려운 부분은 따로 있습니다
여기서 조심할 대목이 있습니다. 라우팅은 개념은 단순한데 실제로는 답을 알기 전에 난이도를 맞혀야 하는 문제입니다.
쉬운 질문인 줄 알고 작은 모델로 보냈는데 사실 어려운 질문이었다면, 틀린 답이 그대로 나갑니다. 반대로 안전하게 전부 프런티어로 보내면 라우팅을 할 이유가 없어집니다. 그래서 라우터의 품질은 요청을 보고 결과를 예측하는 정확도로 결정되는데, 이건 이 블로그가 반복해 다룬 채점기 문제와 같은 성격입니다. 무엇이 잘된 것인지 판정할 수 없으면 어디로 보낼지도 정할 수 없습니다.
실무에서 자리 잡은 방식은 두 갈래입니다. 하나는 작업 종류로 미리 나누는 것입니다. 분류와 정형 추출은 작은 모델, 요약은 중간, 정말 어렵거나 위험이 큰 것만 프런티어로 보냅니다. 다른 하나는 작은 모델이 먼저 시도하고 자신이 없으면 위로 올리는 단계적 상승입니다. 프로덕션 게이트웨이도 여럿 나와 있습니다. 라이트LLM, 오픈라우터, 클라우드플레어 AI 게이트웨이 같은 것들이고, 라우터끼리 비교하는 공개 플랫폼도 생겼습니다.
엔비디아가 이 그림을 그리는 이유
콘웨이의 주장에 동의하더라도, 그가 양쪽 하드웨어를 다 파는 회사에 있다는 점은 감안해야 합니다.
로컬 모델이 늘면 DGX 스파크 같은 데스크톱 장비가 팔리고, 프런티어가 계속 커지면 데이터센터 GPU가 팔립니다. 모델들의 시스템은 엔비디아에게 어느 쪽으로 기울어도 손해가 없는 구조입니다. 오픈 모델을 적극적으로 밀고(네모트론 계열) 개발자가 자기 데이터로 미세조정하도록 돕는 것도 같은 맥락입니다. 로봇 쪽에서도 같은 전략을 쓰고 있습니다. 모델은 열어주고 그 모델이 돌아갈 실리콘을 파는 방식입니다.
이해관계가 있다고 해서 관찰이 틀린 것은 아닙니다. 다만 "둘 다 쓰는 세상이 좋다"는 말이 둘 다 파는 회사에서 나왔다는 사실은 함께 기억할 만합니다.
한국 기업에는 더 직접적인 문제입니다
이 구도가 국내에서는 조금 다르게 작동합니다. 최근 공개된 국산 모델들의 서빙 문턱이 크게 갈리기 때문입니다.
업스테이지 솔라 오픈 2는 양자화하면 H200 두 장으로 돌아가고, SKT A.X K2는 800기가바이트 이상, LG K-엑사원 2.0은 그보다 더 큰 메모리를 요구합니다. 같은 국가 사업의 결과물인데 도입 문턱이 네 배 차이 납니다.
여기에 데이터를 밖으로 내보낼 수 없는 금융과 공공 환경이 겹치면, 모델들의 시스템은 선택이 아니라 기본 설계가 됩니다. 민감한 자료는 사내 장비의 작은 모델이 처리하고, 일반적인 추론만 외부 API로 나가는 구조입니다. 이때 라우터는 비용 절감 장치가 아니라 정보가 밖으로 나가는 경계선이 됩니다. 어느 요청이 어디로 가는지가 곧 규정 준수의 문제이기 때문입니다.
정해야 할 것은 모델이 아니라 작업을 나누는 기준입니다
로컬이 프런티어를 대체한다는 이야기가 아닙니다. 노트북 위의 2,840억 모델도 문맥이 수만 토큰으로 줄고 저장소 규모 코딩은 여전히 밀립니다. 대신 경계가 옮겨갔습니다. 예전에는 데이터센터가 있어야 하던 작업의 상당 부분이 이제 책상 위에서 처리됩니다.
그래서 지금 정해야 할 것은 어떤 모델을 쓸지가 아니라 작업을 어떤 기준으로 나눌지입니다. 우리 업무 중 짧은 문맥의 반복 작업이 얼마나 되는지, 밖으로 내보내면 안 되는 자료가 어디에 있는지, 그리고 잘못 보냈을 때 되돌릴 수 있는 작업과 없는 작업이 무엇인지. 이 셋을 정리해 둔 조직은 라우터를 붙이는 순간 청구서가 줄고, 정리해 두지 않은 조직은 모든 요청을 가장 비싼 모델로 보내며 그것을 안전이라고 부르게 됩니다.
본 글은 공개된 인터뷰와 기술 자료, 그리고 커뮤니티에 보고된 실측값을 근거로 한 기술 분석이며, 특정 종목에 대한 판단을 담고 있지 않습니다. 로컬 실행 속도와 메모리 수치는 개별 하드웨어와 양자화 방식에 따라 달라지며, 2비트 양자화 상태의 품질 저하는 아직 독립 측정이 공개되지 않았습니다. 조이 콘웨이는 로컬 장비와 데이터센터 GPU를 함께 파는 엔비디아 소속입니다.
주요 출처: 더뉴스택의 조이 콘웨이 인터뷰, 엔비디아 네모트론 관련 공개 자료, 딥시크 V4-Flash 로컬 구동 실측 보고(2비트 동적 양자화·MLX), 로컬 실행 하드웨어 가이드, 라우팅 비용 절감 보고 및 라우트LLM 연구, 시리즈 선행 글.