DeepSeek-V3는 671B인데 왜 토큰당 37B만 쓰나: MLA, MoE, MTP

DeepSeek-V3는 전체 671B 파라미터를 모두 매 토큰에 쓰지 않고 약 37B만 활성화하는 MoE 구조로 용량과 연산을 분리하지만, 일반 워크스테이션에서 가볍게 구동되는 모델은 아닙니다. MLA는 긴 문맥의 KV 캐시를 줄이고 FP8과 MTP는 학습 효율을 겨냥하지만, 어느 하나도 전체 가중치 저장과 전문가 통신을 없애지 않습니다. 채택 여부는 공개 벤치마크 순위보다 실제 요청에서 품질, 지연, 동시성, 운영 복잡도를 같은 조건으로 비교해 정해야 합니다.

671B와 37B는 서로 다른 비용이다

DeepSeekMoE는 입력 토큰에 필요한 전문가 일부를 선택합니다. 토큰당 활성 파라미터가 37B라는 수치는 dense 671B 모델보다 계산량을 줄인다는 뜻입니다. 그러나 배포 노드는 전체 전문가 가중치를 보관하거나 여러 장치에 나눠야 하며, 라우팅과 장치 간 통신 비용도 생깁니다.

따라서 활성 파라미터만 보고 VRAM 요구량을 추정하면 안 됩니다. 처리량은 배치 크기, 전문가 분산 방식, 네트워크 대역폭과 함께 측정해야 합니다.

MLA는 긴 문맥의 무엇을 압축하나

Multi-head Latent Attention은 각 토큰의 Key, Value 표현을 저차원 잠재 공간으로 압축해 KV 캐시 부담을 줄이는 구조입니다. 원문은 128K context를 제시합니다. 긴 입력이 메모리에 들어간다는 것과 코드베이스 전체의 관계를 정확히 이해한다는 것은 별개의 문제입니다.

문맥 길이를 늘리며 첫 토큰 지연, 토큰당 메모리, 중간 위치 정보의 회수율을 함께 봐야 합니다. 압축으로 절약한 메모리가 실제 서빙 동시성으로 이어지는지도 대상 엔진에서 확인해야 합니다.

FP8과 MTP는 학습, 생성을 어떻게 바꾸나

원문은 훈련 전반에 FP8을 사용해 계산과 메모리 효율을 높였다고 설명합니다. Multi-Token Prediction은 다음 토큰 하나뿐 아니라 뒤의 여러 토큰을 보조 목표로 예측해 학습 신호를 확장합니다. MTP가 곧 한 번에 완성 문장을 확정하거나 모든 추론을 빠르게 만든다는 뜻은 아닙니다.

보고된 훈련 비용 약 558만 달러도 논문이 계산한 조건의 수치로 읽어야 합니다. 데이터 준비, 실험 실패, 인력과 전체 연구 비용을 모두 포함한 가격이라고 단정해서는 안 됩니다.

벤치마크보다 내 서비스 조건을 먼저 만든다

원문은 코딩과 수학 성과, 가중치 공개를 강조하지만 “GPT-4o급”이라는 한 문장으로 작업별 품질을 대신할 수 없습니다. 한국어 문체, 정책 응답, 긴 코드 수정, 도구 호출처럼 실제 요청을 모아 정확성, 지연, 비용을 같은 조건에서 비교해야 합니다.

일반 개발자 장비에서 전체 모델을 직접 운영하기는 여전히 어렵습니다. 사용 전 GitHub 저장소, 공식 사이트, 기술 보고서의 모델 구성과 라이선스, 서빙 요구사항을 대조해야 합니다.

모델 크기와 요청 비용을 어떻게 분리할까

총 파라미터는 모델이 보유한 전체 용량이고 활성 파라미터는 한 토큰을 처리할 때 선택된 전문가의 계산량에 가깝습니다. 여기에 가중치 정밀도, KV 캐시, 중간 activation, 배치가 메모리를 추가로 사용합니다. 따라서 “37B 활성”만으로 한 장치에 들어가는지 계산하면 전체 전문가 저장 비용을 놓칩니다.

MoE 서빙에서는 라우터가 토큰을 전문가로 보내고 결과를 다시 모읍니다. 전문가가 여러 장치에 흩어지면 토큰 분포가 고르지 않을 때 일부 장치가 병목이 될 수 있고, 장치 간 전송도 지연을 만듭니다. 짧은 단일 요청에서 빠른 구성과 많은 동시 요청에서 처리량이 높은 구성은 다를 수 있으므로 두 부하를 분리해 재야 합니다.

비용 항목	구조가 줄이려는 것	여전히 확인할 것
MoE	토큰당 계산에 참여하는 파라미터	전체 가중치 저장, 라우팅, 통신
MLA	토큰별 KV 캐시 크기	긴 입력의 회수 정확도, 첫 토큰 지연
FP8	학습 계산과 메모리	대상 하드웨어 지원, 수치 안정성
MTP	다음 여러 토큰의 학습 신호	실제 디코딩 엔진에서 얻는 이득

이 표의 네 항목은 서로 다른 단계에 작용합니다. FP8 학습이 효율적이었다는 사실만으로 배포 엔진이 자동으로 FP8 추론을 잘 수행하는 것은 아니며, MTP 학습 목표가 있었다고 모든 생성 요청이 여러 토큰씩 확정되는 것도 아닙니다.

긴 문맥은 어떤 질문으로 시험해야 하나

128K 입력이 받아들여지는지만 확인하면 중요한 실패를 놓칩니다. 문서 앞, 중간, 끝에 서로 다른 식별 가능한 사실을 두고 위치별로 회수되는지 확인해야 합니다. 서로 비슷한 함수 이름이나 상충하는 정책 문장을 넣으면 모델이 가까운 문장만 따라가는지도 볼 수 있습니다.

코드 작업이라면 전체 저장소를 한 번에 붙이는 대신 변경 대상과 호출 관계를 정한 평가 세트를 만듭니다. 올바른 파일을 찾았는지, 수정하지 말아야 할 API를 보존했는지, 테스트 실패 원인을 근거와 함께 설명하는지 평가합니다. 긴 문맥이 유용하더라도 불필요한 파일을 모두 넣으면 지연과 비용이 늘고 관련 신호가 묻힐 수 있습니다.

문맥 길이를 단계적으로 늘리며 첫 토큰 시간, 생성 속도, peak 메모리, 정답률을 기록합니다. MLA가 KV 캐시를 줄이는 방향이라도 실제 엔진의 구현과 배치 정책에 따라 절약분이 동시성으로 이어지지 않을 수 있습니다. 같은 엔진, 같은 정밀도, 같은 요청으로 비교해야 구조 차이와 배포 설정 차이를 혼동하지 않습니다.

서비스 PoC는 어떤 순서로 진행할까

먼저 업무 요청을 코딩, 수학, 한국어 작성, 긴 문서 질의, 도구 호출처럼 나눕니다. 각 유형에서 정답 또는 합격 조건을 만들고 현재 모델과 DeepSeek-V3를 동일한 프롬프트, 도구 권한으로 실행합니다. 한 번의 인상적인 응답보다 반복 실행의 오류 유형과 응답 변동을 보는 편이 중요합니다.

그다음 짧은 요청과 긴 요청, 단일 사용자와 동시 사용자를 나눠 부하를 올립니다. 모델 서버만 재지 말고 라우터, 네트워크, 큐 대기와 실패 후 재시도까지 포함한 end-to-end 지연을 기록합니다. 전문가 통신이 병목이면 GPU 계산 사용률만 보고 원인을 찾기 어렵습니다.

마지막으로 라이선스와 데이터 경계, 로그 보존, 모델 업데이트 절차를 점검합니다. 공개 가중치는 운영 책임을 공급자가 대신 진다는 뜻이 아닙니다. 체크포인트 변경 뒤 같은 평가 세트를 다시 돌리고, 품질이 나빠졌을 때 이전 버전으로 되돌릴 수 있어야 합니다.

어떤 결론을 내리면 안 되나

671B라는 숫자만으로 모든 70B dense 모델보다 항상 정확하다고 말할 수 없습니다. 활성 37B라는 숫자만으로 37B dense 모델과 같은 메모리, 지연이라고도 볼 수 없습니다. 벤치마크의 코딩, 수학 결과는 그 문제 분포의 근거이며 조직의 한국어 문서나 도구 호출 성공률을 대신하지 않습니다.

훈련 비용 수치도 자체 학습의 견적서가 아닙니다. 계산에 포함된 GPU 시간의 범위와 가격 가정이 다르면 값이 달라지고, 데이터, 실패 실험, 사람의 비용은 별도일 수 있습니다. 모델을 평가할 때는 숫자가 답하는 질문과 답하지 않는 질문을 함께 적어 두는 것이 과장을 막는 가장 간단한 방법입니다.

자체 운영과 외부 API 사용도 같은 표에서 비교해야 합니다. 자체 운영은 요청 데이터와 배포 설정을 더 직접 통제할 수 있지만 장치 확보, 모니터링, 장애 대응과 업데이트 책임이 생깁니다. 외부 API는 시작이 빠르지만 데이터 처리 조건과 단가, 사용량 제한에 의존합니다. 요청량이 작을 때와 커졌을 때의 총비용을 따로 계산해야 어느 경로가 유리한지 판단할 수 있습니다.

품질 회귀를 감지하려면 답변 점수만 저장하지 말고 model version, serving engine, quantization과 prompt를 함께 기록합니다. 같은 checkpoint라도 정밀도와 router 설정이 달라지면 결과가 바뀔 수 있습니다. 오류 사례를 유형별로 모아 다음 배포에서 다시 실행해야 평균 점수 뒤에 숨은 안전, 도구 호출 실패를 찾을 수 있습니다.

원문과 버전 확인

• 공식 GitHub 저장소

함께 읽으면 이해가 이어지는 글

• KTransformers: 24GB 단일 GPU와 시스템 메모리로 600B급 MoE 모델을 구동하는 이기종 추론 기술 — 단일 24GB GPU와 시스템 메모리를 결합하는 이기종 컴퓨팅 기술을 통해 수백만 원대 데스크톱 환경에서도 671B 규모의 최신 MoE(전문가 혼합) 언어 모델을 실용적인 속도로 추론하고 파인튜닝할 수 있게 해주는 오픈소스…
• BitNet b1.58은 GPU 없이도 빠를까? 3값 가중치와 전용 커널의 조건 — 가중치를 -1, 0, 1로 제한하는 BitNet b1.58이 메모리와 행렬 연산을 줄이는 원리, 학습 방식과 실제 가속에 필요한 커널 조건을 정리합니다.
• Meta Muse Glimmer 30B 로컬 에이전트: 4비트 메모리 조건과 도입 판단 — Meta가 2026년 8월 10일 소비자용 GPU 환경에 최적화된 300억 파라미터 오픈소스 모델 Muse Glimmer를 Apache 2.0 라이선스로 출시했습니다. 4비트 양자화를 적용해 메모리 점유율을 20GB RAM 이하로…

자주 묻는 질문

토큰당 37B만 활성화되면 37B 모델처럼 배포할 수 있나요?

아닙니다. 토큰 연산에는 일부 전문가만 참여하지만 전체 전문가 가중치를 저장하거나 여러 장치에 나눠야 합니다. 실제 메모리와 처리량은 정밀도, 전문가 배치, 장치 간 통신까지 포함해 측정해야 합니다.

128K 문맥이면 긴 코드베이스를 전부 정확히 이해하나요?

긴 입력을 넣을 수 있는 용량과 필요한 정보를 정확히 찾아 사용하는 능력은 다릅니다. 위치별 회수 문제와 첫 토큰 지연, KV 캐시 메모리를 실제 문서로 함께 평가해야 합니다.

보고된 훈련 비용을 자체 학습 예산으로 써도 되나요?

그 수치는 보고서가 정한 계산 조건의 결과입니다. 데이터 준비, 실험 반복, 인력, 인프라 확보와 전체 연구 비용을 모두 포함한 자체 프로젝트 예산으로 그대로 사용할 수 없습니다.