작성자 Kimi K3 자체 호스팅 방법 및 하드웨어 요구 사항
2.8조 파라미터 규모의 Kimi K3 모델을 구동하기 위한 VRAM 산술 연산과 KV 캐시 계산법을 정리했습니다. 32개 GPU 클러스터 없이 현실적으로 모델을 실행할 수 있는 세 가지 방법과 인프라 구축 시 반드시 고려해야 할 메모리 비용 문제를 상세히 다룹니다.
Kimi K3를 자체 호스팅하기 위한 조건
Kimi K3를 자체 호스팅한다는 것은 2.8조 개의 파라미터를 수용할 공간을 확보한다는 의미입니다. Moonshot은 MXFP4 형식으로 오픈 웨이트를 공개했는데, 이는 파라미터당 약 0.5바이트에 해당합니다. 따라서 단 하나의 토큰 캐시도 할당하기 전에 웨이트 용량만으로도 대략 1.4 TB에 달합니다. 현재 시판 중인 어떤 가속기도 이를 단독으로 수용할 수 없습니다. K3는 멀티 노드 모델이므로, 단일 서버로는 불가능합니다.
이것이 결론입니다. 아래의 모든 내용은 그 근거가 되는 산술적 계산입니다. 이 계산 방식은 다음 릴리스에서도 그대로 적용할 수 있기 때문입니다. 2026년 7월 17일 발표 이후 몇 주 동안 여러 인프라 벤더가 K3 배포 가이드를 게시했지만, 각 가이드는 이미 클러스터를 보유하고 있다는 전제하에 작성되었습니다. 이 페이지는 반대 방향에서 시작합니다. 즉, 비용이 얼마나 드는지, 대신 무엇을 실행할 수 있는지, 그리고 본인이 이 두 가지 상황 중 어디에 해당하는지 확인하는 방법입니다.
전체 파라미터 수와 활성 파라미터 수가 일치하지 않는 이유
K3는 Mixture of Experts(MoE) 모델입니다. MoE는 네트워크를 여러 하위 네트워크로 분할하고, 라우터가 토큰마다 그중 일부를 선택하도록 설계되었습니다. 모델 카드에는 총 2.8T 파라미터, 토큰당 104B 활성 파라미터가 명시되어 있으며, 이는 93개 레이어에 걸쳐 있는 896개의 라우팅된 전문가 중 16개가 특정 토큰 처리에 사용됨을 의미합니다.
이 두 가지 파라미터 수치는 서로 다른 질문에 대한 답이며, 이를 혼동하는 것은 "이 모델을 실행할 수 있을까"라는 질문이 올라오는 모든 스레드에서 가장 흔히 발생하는 실수입니다.
활성 파라미터는 연산 비용을 결정합니다. 토큰 하나가 약 104B개의 파라미터를 거쳐 연산되므로, 기대할 수 있는 처리량은 2.8T 모델이 아닌 104B dense 모델과 유사합니다. 이것이 바로 MoE 모델을 구축하는 근본적인 이유입니다.
전체 파라미터는 메모리 비용을 결정합니다. 라우터는 어떤 토큰에 대해서든 임의의 전문가를 선택할 수 있으므로, 첫 번째 요청이 도착하기 전에 모든 전문가가 메모리에 상주해야 합니다. 104B 파라미터만 VRAM에 올리고 나머지를 필요할 때마다 불러오는 방식은 불가능합니다. 데이터 인출은 마이크로초 단위로 완료되어야 하는데, PCIe 링크의 전송 속도는 초당 수십 기가바이트 수준에 불과하기 때문입니다. 이를 시도하는 경우가 종종 있습니다. NVMe에서 전문가 데이터를 스트리밍하면 초당 수십 개의 토큰을 생성해야 할 모델이 몇 초에 토큰 하나를 생성하는 수준으로 느려집니다.
결론적으로, 연산 비용은 저렴하지만 저장 비용은 높습니다. 하드웨어 규모는 2.8T를 기준으로 산정하고, 속도 기대치는 104B를 기준으로 설정하십시오.
가중치당 바이트 수와 테라바이트의 출처
파라미터 수에 가중치당 바이트 수를 곱합니다. 가중치에 대해서는 이것이 전체 공식입니다.
The data behind this chart
[
{
"label": "bf16",
"bytes_per_weight": 2,
"weights_tb": 5.6
},
{
"label": "fp8",
"bytes_per_weight": 1,
"weights_tb": 2.8
},
{
"label": "4-bit (MXFP4, as shipped)",
"bytes_per_weight": 0.5,
"weights_tb": 1.4
},
{
"label": "2-bit",
"bytes_per_weight": 0.25,
"weights_tb": 0.7
}
]K3는 양자화 인식(quantisation aware) 방식으로 학습되었으며 MXFP4 가중치와 MXFP8 활성화 함수로 릴리스되었습니다. 따라서 4-bit 행이 실제 값입니다. 그 위의 행들은 척도를 보여주기 위한 것입니다. bf16이라면 동일한 모델에 5.6 TB가 필요할 것입니다. MXFP4는 32개 가중치 블록마다 8-bit 공유 스케일을 하나씩 저장하며, 이는 약 6퍼센트의 용량을 추가합니다. 따라서 공개된 저장소는 순수 1.4 TB보다는 1.5 TB에 더 가깝습니다.
이것으로 흔히 사용하는 탈출구는 막혔습니다. 릴리스된 체크포인트가 이미 4-bit이므로 "그냥 양자화하면 된다"는 해결책은 통하지 않습니다. 2-bit로 낮추면 가중치는 0.7 TB가 되겠지만, 이 체크포인트에서 아무도 측정해 본 적 없는 정확도 손실이 발생합니다. 여전히 단일 카드로는 감당할 수 없는 수준일 것입니다.
Kimi K3에는 GPU가 몇 개 필요한가
The data behind this chart
[
{
"config": "H100 80GB",
"hbm_per_gpu_gb": 80,
"gpus_for_weights": 18
},
{
"config": "H200 141GB",
"hbm_per_gpu_gb": 141,
"gpus_for_weights": 10
},
{
"config": "B200 192GB",
"hbm_per_gpu_gb": 192,
"gpus_for_weights": 8
},
{
"config": "GB300 288GB",
"hbm_per_gpu_gb": 288,
"gpus_for_weights": 5
}
]이 수치는 목표치가 아닌 최소 사양으로 이해해야 합니다. 이는 가중치만을 계산한 값이며, KV 캐시, 활성화 버퍼, 할당자 파편화, 그리고 두 번째 동시 요청을 처리할 여유 공간은 포함하지 않습니다. 또한 93개의 레이어와 896개의 전문가 모델이 항상 균등하게 분할되지 않는다는 점을 고려하지 않은, 단순 병렬 분할을 가정한 수치입니다.
공식 가이드라인은 이 최소 사양보다 훨씬 높게 책정되어 있습니다. 2026년 8월 기준으로 Moonshot은 64개 이상의 가속기로 구성된 슈퍼노드를 권장합니다. SGLang 쿡북은 8개의 GPU를 탑재한 노드 4개, 즉 총 32개의 GPU와 2,560 GB의 총 메모리로 구성된 H100 설정을 제공하는데, 이는 18 카드라는 최소 사양과 대비됩니다. 이 차이는 낭비가 아닙니다. 이는 KV 캐시, 활성화 메모리, 그리고 서버가 여러 요청을 동시에 배치 처리할 수 있게 해주는 여유 공간입니다. 가장 낮은 사양인 5 GB300급 카드조차도 대부분의 클라우드 제공업체가 단일 SKU로 대여하지 않는 규모의 장비를 의미합니다.
KV 캐시는 의외로 많은 사람이 간과하는 부분입니다
가중치는 고정 비용입니다. 하지만 KV(key value) 캐시는 그렇지 않습니다. 컨텍스트 길이가 길어질수록, 그리고 동시 접속자가 늘어날수록 함께 증가합니다. 일반적인 어텐션(ordinary attention)의 공식은 bytes per token = 2 * layers * kv_heads * head_dim * bytes_per_element이며, 여기에 컨텍스트 길이와 동시 접속자 수를 곱해야 합니다.
예시를 들어보겠습니다. 단지 예시일 뿐입니다. 64개 레이어, 8개 KV 헤드, 헤드 차원 128, fp8을 가정합니다. 이 경우 2 64 8 128 1 = 131,072 바이트, 즉 토큰당 128 KiB가 소요됩니다.
The data behind this chart
[
{
"label": "8k context",
"kv_gib_per_user": 1
},
{
"label": "32k context",
"kv_gib_per_user": 4
},
{
"label": "128k context",
"kv_gib_per_user": 16
},
{
"label": "1M context",
"kv_gib_per_user": 128
}
]128k 컨텍스트를 사용하는 사용자 1명당 16 GiB의 비용이 발생합니다. 100만 토큰 전체를 사용하는 사용자 1명은 128 GiB를 소모하는데, 이는 단일 대화 하나를 위해 그래픽 카드 한 장이 수용할 수 있는 용량을 초과하는 수치입니다.
K3는 일반적인 어텐션을 사용하지 않으며, 마지막 수치가 바로 그 이유입니다. K3의 93개 레이어는 69개의 KDA(Kimi Delta Attention) 레이어와 24개의 Gated MLA(multi-head latent attention) 레이어로 구성됩니다. KDA는 토큰마다 증가하는 캐시 대신 고정된 크기의 순환 상태(recurrent state)를 유지합니다. 또한 MLA는 키와 값을 하나의 저차원 잠재 벡터로 압축하므로, 실제 토큰당 비용은 위 예시보다 훨씬 낮아집니다. Moonshot은 잠재 차원을 공개하지 않았으므로 K3 자체에 대한 사용자당 수치는 기재하지 않겠습니다. 대신 직접 측정하십시오. 작은 --max-model-len 값으로 서버를 시작하고 nvidia-smi로 메모리 사용량을 모니터링하면서, 할당이 실패할 때까지 제한을 높여가며 확인하십시오.
추론의 형태는 다음 릴리스에서도 유지됩니다. 만약 어떤 모델이 100만 토큰 컨텍스트를 지원한다고 광고하면서 어텐션 설계에 대해 언급이 없다면, 반대 증거가 나오기 전까지는 캐시가 병목 현상의 원인이라고 가정해야 합니다.
Tier 1: 시간 단위 클러스터 임대
이 티어는 K3를 직접 구동하는 유일한 방식입니다. 하드웨어를 구매하는 것이 아니라 필요한 시간만큼 임대하고 작업이 끝나면 중단합니다.
The data behind this chart
[
{
"label": "1 GPU, always on",
"gpu_hours": 720,
"usd_cost": "1,800"
},
{
"label": "8 GPUs, 4 hours a day",
"gpu_hours": 960,
"usd_cost": "2,400"
},
{
"label": "8 GPUs, always on",
"gpu_hours": 5760,
"usd_cost": "14,400"
},
{
"label": "32 GPUs, always on",
"gpu_hours": 23040,
"usd_cost": "57,600"
}
]요금은 추정치이며 확정된 견적이 아닙니다. 2026년 기준 데이터센터 가속기의 온디맨드 정가는 GPU 시간당 대략 2에서 5 USD 사이였으며, 예약 용량은 더 저렴합니다. 제공업체의 실제 단가를 확인하여 다시 계산하십시오. (GPU 수 × 시간 × 단가). 이 차트의 핵심은 비율입니다. 8 GPU 노드를 하루 4시간씩 버스팅하면 월 2,400 USD가 소요되지만, SGLang 크기의 32 GPU 구성을 상시 가동하면 57,600 USD가 소요됩니다.
주류 서버들은 모델 카드에 실행 명령어를 게시합니다.
pip install vllm
vllm serve "moonshotai/Kimi-K3"pip install sglang
python3 -m sglang.launch_server --model-path "moonshotai/Kimi-K3" --host 0.0.0.0 --port 30000실제 클러스터에서는 기본 명령어를 그대로 사용하지 않습니다. 하드웨어에 맞는 병렬 처리 플래그를 추가하십시오. SGLang은 텐서 병렬 처리에 --tp-size를, 전문가 병렬 처리에 --ep-size을 사용하며, 이 둘의 곱은 실제 보유한 GPU 수와 일치해야 합니다.
실제 트래픽을 보내기 전에 서버가 정상적으로 올라왔는지 확인하십시오.
curl http://127.0.0.1:30000/v1/models정상적인 서버는 모델 ID가 포함된 JSON 객체로 응답합니다. Connection refused이 반환된다면 프로세스가 가중치를 로드 중이거나 이미 종료된 상태이므로, 재시도 전에 서버 로그를 확인하십시오.
초기에 가장 흔히 발생하는 실패는 모델보다 런타임 버전이 낮은 경우입니다. K3는 KDA와 새로운 MoE 레이어를 포함하여 출시되었으나, 출시 당시의 안정적인 vLLM 및 SGLang 릴리스에는 해당 기능이 포함되지 않았습니다. 이 경우 서버가 시작 도중 Model architectures [...] are not supported for now 형태의 메시지를 출력하며 종료됩니다. 해당 레이어를 실행할 코드가 빌드에 포함되어 있지 않으므로 설정 변경으로는 해결할 수 없습니다. 모델 카드에 명시된 나이틀리(nightly) 빌드를 설치하거나, 해당 기능이 포함된 릴리스를 기다리십시오.
비용과 관련하여 주의할 점이 있습니다. 인스턴스가 시작되는 시점부터 요금이 부과되며, 모델이 준비된 시점이 아닙니다. 1 GB/s 속도로 1.5 TB를 다운로드하면 첫 토큰이 생성되기까지 약 25분의 클러스터 시간이 소요됩니다. 인스턴스가 종료되어도 유지되는 볼륨에 가중치를 저장해 두면, 두 번째 실행부터는 몇 분 내에 시작할 수 있습니다.
Tier 2: 단일 가속기에서 소형 모델 실행하기
이 단계에서는 K3를 실행하지 않습니다. 시작하기 전에 이 점을 명확히 밝힙니다. "로컬에서 K3 실행하기"와 관련된 대부분의 논의가 이 사실을 언급하지 않고 끝나기 때문입니다.
모델 적재 규칙은 축소된 형태에서도 동일합니다. 매개변수 수에 가중치당 바이트 수를 곱하고, KV 캐시와 약 2 GB의 런타임 오버헤드를 더한 값이 VRAM 용량 이내여야 합니다. 4-bit 양자화 시 매개변수당 약 0.5 바이트가 소요되며, 다음과 같은 조합이 적절합니다.
- 16 GB 카드: 4-bit 7B 모델 (긴 컨텍스트를 위한 여유 공간 포함)
- 24 GB 카드: 4-bit 14B 모델
- 48 GB 카드: 4-bit 32B 모델
- 80 GB 카드: 4-bit 70B 모델 또는 8-bit 30B급 MoE 모델
위의 모든 조합은 한 번에 하나의 요청을 처리하는 것을 가정합니다. 두 번째 사용자가 프롬프트를 보내는 순간, 각 동시 슬롯은 자체적인 KV 캐시를 요구합니다. 이는 Ollama의 NUM_PARALLEL 및 MAX_QUEUE 설정에서 병렬 슬롯, 대기 중인 요청, 그리고 남은 VRAM 사이에서 결정해야 하는 트레이드오프입니다.
Ollama는 GPU가 장착된 VPS에서 서버를 가장 빠르게 구축하는 방법입니다.
curl -fsSL https://ollama.com/install.sh | sh
ollama run qwen3:14bollama run는 처음 실행 시 모델을 다운로드한 뒤 프롬프트로 진입합니다. 존재하지 않는 태그를 입력하면 Error: model "..." not found 오류가 반환되므로, 기억에 의존해 입력하기보다 라이브러리 페이지에서 태그를 복사하십시오. systemd 유닛 설정과 원격 접근을 포함한 전체 과정은 VPS에서 Ollama 실행하기를 참조하십시오.
llama.cpp를 사용하면 양자화와 오프로드에 대해 더 많은 제어권을 가질 수 있습니다.
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release -j./build/bin/llama-server -m model.gguf -c 8192 -ngl 99 --host 0.0.0.0 --port 8080-ngl 99은 모든 레이어를 GPU에 올리도록 요청합니다. 로드 로그를 확인하십시오. 오프로드된 레이어 수가 출력됩니다. GPU 메모리에 올라가지 못한 레이어는 HBM 대역폭이 아닌 시스템 RAM 대역폭으로 동작하므로, 모델이 VRAM 용량을 초과하는 순간 생성 속도가 10배 이상 급격히 떨어집니다. 두 도구 간의 트레이드오프는 Ollama와 llama.cpp 비교에서 다룹니다.
Tier 3: 호스팅 API, 자체 호스팅 오케스트레이션
The data behind this chart
[
{
"label": "Input, cache hit",
"usd_per_million_tokens": "0.30"
},
{
"label": "Input, cache miss",
"usd_per_million_tokens": "3.00"
},
{
"label": "Output",
"usd_per_million_tokens": "15.00"
}
]해당 엔드포인트는 OpenAI와 호환되므로, base URL만 변경하면 기존 클라이언트를 그대로 사용할 수 있습니다.
curl https://api.moonshot.ai/v1/chat/completions \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $MOONSHOT_API_KEY" \
-d '{"model": "kimi-k3", "messages": [{"role": "user", "content": "Say hello."}]}'유효한 키를 사용하면 choices 배열이 포함된 JSON 객체가 반환됩니다. 401 오류는 키가 잘못되었거나 Bearer 접두사가 누락되었음을 의미합니다. 모델을 찾을 수 없다는 오류는 보통 모델 ID가 변경되었을 때 발생하는데, 이는 제공업체가 체크포인트 사이에 ID를 폐기하기 때문입니다.
앞서 가정한 임대료를 기준으로 손익분기점을 계산해 보겠습니다. 8개의 GPU를 탑재한 노드를 상시 가동할 경우 월 14,400 USD가 소요됩니다. 출력 토큰 100만 개당 15.00 USD인 API를 사용한다면, 같은 비용으로 약 9억 6천만 개의 출력 토큰을 얻을 수 있습니다. 비용 효율을 높이려면 한 달에 거의 10억 개의 출력 토큰, 즉 하루에 약 3천만 개를 생성해야 하며, 유휴 GPU도 동일한 요금이 부과되므로 클러스터를 쉬지 않고 가동해야 합니다. 프롬프트 비중이 높은 에이전트 워크로드는 이 기준을 더욱 높입니다. 반복되는 컨텍스트는 캐시 미스 시의 3.00 USD가 아닌 캐시 히트 시의 0.30 USD 요금이 적용되기 때문입니다.
이 계층에서 자체 호스팅하는 대상은 모델을 둘러싼 모든 요소입니다. API 키를 보관하여 클라이언트에 노출되지 않게 하는 게이트웨이, 요청 및 응답 로그, 재시도, 속도 제한, 사용자별 예산 관리 등이 포함됩니다. 이는 GPU가 없는 소형 VPS에서 실행됩니다. 이러한 분리 방식은 폐쇄형 가중치 모델에도 동일하게 적용되며, Claude 자체 호스팅과 같이 모델 수준의 호스팅이 불가능한 경우 오케스트레이션 계층만 직접 관리하게 됩니다.
어떤 서빙 스택이 어떤 계층에 속하는가
vLLM 및 SGLang 클래스 서버는 계층 1에 속합니다. 이들은 연속 배치(continuous batching)와 페이징된 KV 캐시, 그리고 여러 노드에 걸친 텐서 및 전문가 병렬 처리를 통해 다수의 요청을 동시에 처리하도록 설계되었습니다. 이들은 데이터 센터용 가속기와 노드 간의 빠른 인터커넥트를 전제로 합니다. 단일 소비자용 그래픽 카드에서는 설치가 더 복잡하며, 체감할 수 있는 이점은 거의 없습니다.
llama.cpp 및 Ollama는 계층 2에 속합니다. 이들은 단일 머신, GGUF 양자화, 모델이 메모리에 맞지 않을 때의 CPU 오프로드, 그리고 낮은 동시성을 목표로 합니다. llama.cpp는 기술적으로 대부분의 레이어를 시스템 RAM에 유지함으로써 거대한 MoE 모델을 로드할 수 있지만, 2.8T 모델의 경우 토큰당 처리 시간이 초 단위로 측정됩니다. 이는 파일 파싱이 가능하다는 것을 증명할 뿐, 실제 사용자를 수용할 수 있는 서비스는 아닙니다. 전체 비교는 Ollama와 vLLM 비교에 나와 있으며, 모델이 바뀌어도 이 기준은 변하지 않습니다. 핵심은 공유 하드웨어에서 다수의 사용자를 서비스할 것인지, 아니면 개인용 하드웨어에서 단일 사용자를 서비스할 것인지에 달려 있습니다.
이 체크포인트를 넘어서는 네 가지 수치
- 총 파라미터 수에 가중치당 바이트 수를 곱하면 메모리 하한선이 결정됩니다. 이보다 적은 메모리로는 아무것도 실행할 수 없으며, 이미 4-bit로 릴리스된 모델이라면 양자화 기법을 사용해도 메모리 요구량을 크게 줄일 수 없습니다.
- 활성 파라미터 수는 처리량 등급을 결정합니다. 104B가 활성화되는 2.8T MoE 모델은 104B 모델과 동일한 연산 성능을 보입니다.
- 토큰당 KV 캐시, 컨텍스트 길이, 동시성 요청 수를 곱한 값은 가중치 로드 비용을 지불한 이후에도 계속 증가하는 운영 비용입니다.
- 달러당 초당 토큰 처리량은 서비스 등급을 결정하는 유일한 지표입니다. 위의 모든 항목은 이 수치를 산출하기 위한 입력값입니다.
위의 네 가지 항목을 모든 릴리스에 적용하면 벤더 가이드를 열기 전에 올바른 판단을 내릴 수 있습니다. 기록하는 모든 수치에는 날짜를 기입하십시오. 가격과 지원 아키텍처 목록은 K3 출시 후 2주 만에 변경되었으며, 이 페이지의 모든 수치는 2026년 7월에 게시된 기준입니다.
FAQ
Kimi K3를 단일 GPU에서 실행할 수 있습니까?
아니요. Moonshot이 배포하는 MXFP4 정밀도에서 가중치 크기는 1.4 TB이며, 현재 판매 중인 가장 큰 단일 가속기의 용량은 288 GB입니다. MoE 모델은 토큰마다 라우터가 임의의 전문가를 선택할 수 있고 PCIe를 통한 데이터 인출 속도가 토큰 처리 예산보다 훨씬 느리기 때문에, 비활성 전문가를 디스크에서 실시간으로 스트리밍하여 사용할 수 없습니다. K3를 합리적으로 배포하려면 최소한 멀티 GPU 노드가 필요하며, 공개된 구성 가이드는 32개 이상의 가속기를 사용합니다.
Kimi K3에는 어느 정도의 VRAM이 필요합니까?
가중치만으로 1.4 TB가 필요하며, 이는 H100 80GB 카드 18개 또는 GB300급 카드 5개에 해당합니다. 여기에 KV 캐시와 활성화 메모리를 추가해야 합니다. 2026년 8월 기준으로 Moonshot은 64개 이상의 가속기를 권장하며, SGLang 쿡북은 총 2,560 GB 용량의 H100 32개 GPU 구성을 제시하고 있으므로 가중치 수치는 최소 요구 사항일 뿐임을 유의하십시오.
양자화를 사용하면 Kimi K3를 단일 노드에 올릴 수 있습니까?
실용적이지 않습니다. 배포된 체크포인트는 이미 양자화 인식 학습(quantization-aware training)이 적용된 4-bit 모델이므로, 쉽게 얻을 수 있는 최적화는 이미 완료된 상태입니다. 2-bit로 다시 절반을 줄이면 가중치는 0.7 TB가 되는데, 이는 여전히 가장 큰 카드 용량의 두 배가 넘으며 2-bit 적용 시의 정확도 손실은 이 모델에서 측정된 바 없습니다.
GPU를 대여하는 것이 Kimi K3 API보다 저렴합니까?
사용량이 많고 일정할 때만 그렇습니다. GPU 시간당 2.50 USD라고 가정할 때, 8개 GPU 노드를 상시 가동하면 월 14,400 USD가 소요됩니다. 같은 비용으로 15.00 USD(백만 토큰당)라는 공개 요금제 기준 약 9억 6천만 개의 출력 토큰을 사용할 수 있습니다. 또한 유휴 시간 비용, 가중치 다운로드 비용, 클러스터 유지 관리 인력 비용도 고려해야 합니다. 일시적인 부하에는 시간 단위 대여를 사용하고, 추측이 아닌 실제 측정된 토큰 사용량을 기준으로 비교하십시오.
104B 활성 파라미터는 속도 측면에서 무엇을 의미합니까?
토큰당 연산량이 104B 모델 수준이라는 뜻이며, 따라서 처리량(throughput)도 2.8T급이 아닌 해당 클래스 수준으로 결정됩니다. 이는 메모리와는 무관합니다. 라우터가 어떤 토큰에서든 모든 전문가를 호출할 수 있으므로 2.8T 파라미터 전체가 상주해야 합니다. 활성 파라미터 수는 초당 토큰 수를 예측하는 데 사용하고, 전체 파라미터 수는 VRAM 크기를 산정하는 데 사용하십시오.