대규모 언어모델의 서버 규모 산정은 한 가지 거친 규칙을 따라왔다. 파라미터 수를 세고, 정밀도를 곱하고, 그만큼의 GPU 메모리를 사는 것이다. DeepSeek의 V4.1 Flash가 이 규칙을 깬다. 가중치는 모두 7630억 개로 FP8 기준 763GB의 가속기 메모리를 바닥값으로 요구하지만, 실제로는 약 567GB로 서비스할 수 있다. 이 중 1960억 개가 애초에 일반 시스템 RAM에서 돌아가도록 설계됐기 때문이다.
핵심 요약
- 한 모델의 가중치 가운데 약 196GB어치를 가속기 밖으로 완전히 덜어낼 수 있다. 어떤 서버 구성이 필요한지가 달라진다.
- 옮길 수 있는 가중치는 한 번에 수십 개 항목만 읽는 룩업 테이블이다. 토큰 생성 속도를 좌우하는 메모리 대역폭을 놓고 경쟁하지 않는다.
- 이 절감은 GPU 아래 계층이 충분히 빠를 때만 성립한다. 엔지니어링의 초점이 GPU 예산에서 시스템 메모리와 스토리지 I/O 설계로 이동한다.
천장을 정하는 것은 용량이 아니라 대역폭이다
토큰 하나를 만들려면 모델의 활성 가중치를 메모리에서 읽어야 한다. 토큰마다 반복되는 이 읽기 때문에 처리량의 한계를 정하는 것은 연산량이 아니라 메모리 대역폭이고, 가속기 메모리가 지금 같은 값을 받는 이유도 여기에 있다. 용량도 중요하지만, 가중치가 GPU에 올라가는 진짜 이유는 그것을 얼마나 빨리 흘려보내야 하느냐다.
이 논리는 실제로 스트리밍되는 가중치에만 적용된다. 그렇지 않은 가중치도 있다. DeepSeek의 조건부 메모리 모듈은 1960억 개 파라미터를 N-gram 룩업 테이블로 보관한다. 짧은 토큰 열에 대해 학습된 연관 정보이며, 참조 비용은 블록 전체를 훑는 대신 토큰당 테이블 읽기 수십 회에 그친다. 이렇게 드물게 접근하는 가중치는 시스템에서 가장 빠른 메모리를 차지할 근거가 없다.
결과는 재고의 분할이다. 토큰마다 활성화되는 파라미터 약 80억 개는 빨라야 한다. 반면 룩업 풀은 시스템 RAM에 두거나, 지연 없이 응답할 만큼 빠른 스토리지 배열에 얹어도 된다. 기술 보고서를 분석한 The Register는 이 설계의 목표를 모델이 아는 것과 계산해야 하는 것의 분리로 설명했다.
구매 협상에 생기는 변화
200GB는 반올림 오차가 아니다. 노드 등급 하나를 가르는 차이인 경우가 많고, 그래서 자본 계획 자체를 가른다. 파라미터 수만 보고 규모를 잡는 구매자는 과잉 투자하고, 아래 메모리 계층을 확인하지 않은 채 오프로드 수치만 보고 잡는 구매자는 과소 투자해 지연시간으로 대가를 치른다.
지금은 어느 쪽 실수도 피하기 어렵다. 모델 카드가 메모리 수치를 둘이 아니라 하나만 싣기 때문이다. 필요한 공시는 분리된 두 숫자다. 가속기에 반드시 상주해야 하는 양과, 한 계층 아래에 둬도 되는 양이다. 이 질문은 문서에 등장하기 전에 벤더 평가 항목으로 먼저 들어올 것으로 보인다.
요구해야 할 숫자가 하나 더 있다. GPU를 채우는 것은 가중치만이 아니다. 키-값 캐시는 컨텍스트 길이와 동시 사용자 수에 따라 불어나며, 처리량이 높은 챗봇이나 에이전트 작업에서는 오히려 이쪽이 지배적이다. 같은 DeepSeek 릴리스는 이 문제를 따로 공략했다. 어텐션을 재설계하고 새로운 인과 인코더-디코더를 도입해 캐시 사용량을 이전 Flash 모델의 13~25% 수준으로 낮췄다. 용량으로 환산하면 메모리 단위당 동시 세션이 네 배에서 여덟 배로 늘어난다는 뜻이며, 대다수 운영자에게는 파라미터 계산보다 훨씬 피부에 와닿는 숫자다.
이 기법은 얼마나 옮겨 쓸 수 있나
독점 기술이 아니다. Google의 Gemma 팀은 계층 전부가 빠듯한 스마트폰에 쓸 만한 모델을 밀어 넣기 위해 유사한 기법인 Per-Layer Embedding을 만들었다. DeepSeek은 지난 1월 N-gram 변형을 공개했고, Alibaba도 이후 실험용 Qwen 모델에 510억 파라미터 규모의 룩업 풀을 넣었다. 가속기 가격과 DRAM 한 개 가격을 비교해 본 사람이라면 누구나 이해할 수 있는 경제성이 이 설계를 퍼뜨리고 있다.
아직 정리되지 않은 쟁점은 계층을 얼마나 아래까지 내려갈 수 있느냐다. 시스템 RAM은 검증된 목적지다. 스토리지는 아직 주장에 가깝고, 배열 성능에 크게 좌우된다. 도입을 검토하는 팀이라면 헤드라인 수치를 믿기보다 자사 추론 스택에서 직접 벤치마크해야 한다. 절감 효과는 실재하지만 조건부이고, 그 조건은 이미 갖고 있거나 갖고 있지 않은 인프라이기 때문이다.
변경 관리에도 변수가 하나 늘어난다. 엔드포인트 뒤에서 무엇이 돌아가는지를 바꾸는 사업자는 메모리 프로파일까지 함께 바꾸는 셈이다. 이번 주 고정된 모델명이 거부 선택지 없이 다른 가중치를 서빙하기 시작한 사례가 이 위험을 드러냈다.
FAQ
어떤 모델이든 가중치를 시스템 RAM으로 내릴 수 있나?
아니다. 대량 스트리밍을 피할 만큼 드물게 접근하는 가중치만 지연 손실 없이 옮길 수 있다. 실제로는 토큰마다 쓰이는 활성 가중치가 아니라 룩업 성격의 파라미터가 여기 해당한다. 일반적인 밀집 가중치를 내리면 GPU가 해결하려던 대역폭 병목이 그대로 돌아온다.
DeepSeek V4.1 Flash에 실제로 필요한 GPU 메모리는 얼마인가?
7630억 파라미터를 FP8로 전부 가속기에 올리면 최소 763GB가 필요하다. 1960억 파라미터 룩업 풀을 내리면 그 바닥값이 약 567GB로 내려간다. 실제 운영에는 키-값 캐시를 위한 여유 공간이 추가로 필요하며, 이 용량은 컨텍스트 길이와 동시 사용자 수에 비례해 늘어난다.
가중치를 오프로드하면 모델이 느려지나?
가중치를 받는 계층에 전적으로 달렸다. 시스템 RAM에서 처리하는 룩업은 구조가 유지될 만큼 빠르다. 반대로 느린 스토리지 배열은 룩업 한 번에 멈춰 서면서, 설계가 줄이려던 지연시간을 그대로 되돌려준다. 자사 하드웨어에서 직접 측정하는 것만이 믿을 수 있는 답이다.
