Tự host Kimi K3 cần bao nhiêu VRAM?

Điều kiện để tự host Kimi K3

Tự host Kimi K3 nghĩa là phải dành chỗ cho 2.8 nghìn tỷ parameter. Moonshot công bố open weight ở định dạng MXFP4, tiêu tốn khoảng nửa byte cho mỗi weight. Vì vậy, riêng weight đã chiếm khoảng 1.4 TB trước khi bạn cấp phát dù chỉ một token cache. Hiện không có accelerator thương mại nào có thể tự chứa toàn bộ lượng dữ liệu này. K3 là model chạy trên nhiều node, nên một server đơn lẻ không đáp ứng được.

Đó là kết luận. Phần bên dưới trình bày các phép tính dẫn đến kết luận này, vì đây là phần bạn có thể áp dụng lại cho release tiếp theo. Trong vài tuần sau thông báo ngày 17 July 2026, một số nhà cung cấp hạ tầng đã công bố hướng dẫn triển khai K3, nhưng tất cả đều giả định rằng bạn đã có sẵn một cluster. Trang này bắt đầu từ hướng ngược lại: chi phí là bao nhiêu, bạn có thể chạy gì thay thế, và cách xác định bạn đang ở trường hợp nào trong hai trường hợp đó.

Tổng số parameter và số parameter được kích hoạt không giống nhau

K3 là một mô hình mixture of experts. MoE (mixture of experts) chia mạng thành nhiều sub-network và cho phép một router chọn một vài sub-network cho mỗi token. Model card ghi 2.8T tổng số parameter và 104B parameter được kích hoạt cho mỗi token. Mô hình có 896 expert được định tuyến, trong đó 16 expert được kích hoạt cho mỗi token, trải trên 93 layer.

Hai số lượng parameter này trả lời hai câu hỏi khác nhau. Việc đánh tráo chúng là lỗi phổ biến nhất trong mọi thread “tôi có chạy được mô hình này không”.

Số parameter được kích hoạt quyết định chi phí tính toán. Mỗi token đi qua khoảng 104B parameter. Vì vậy, throughput dự kiến sẽ gần với mô hình dense 104B hơn là mô hình 2.8T. Đây chính là lý do MoE được xây dựng.

Tổng số parameter quyết định chi phí bộ nhớ. Router có thể chọn bất kỳ expert nào cho bất kỳ token nào. Vì vậy, mọi expert phải được nạp sẵn trước khi request đầu tiên đến. Bạn không thể chỉ giữ 104B trong VRAM rồi nạp phần còn lại khi cần, vì thao tác nạp phải hoàn tất trong vài microsecond, trong khi một liên kết PCIe chỉ truyền được vài chục gigabyte mỗi giây. Nhiều người vẫn thử cách này. Stream expert từ NVMe khiến một mô hình đáng lẽ phải sinh ra hàng chục token mỗi giây chỉ còn sinh được 1 token sau mỗi vài giây.

Vì vậy, chi phí tính toán thấp nhưng chi phí lưu trữ cao. Hãy dimension phần cứng theo 2.8T. Hãy đặt kỳ vọng về tốc độ theo 104B.

Số byte trên mỗi weight và nguồn gốc của số terabyte

Số lượng parameter nhân với số byte trên mỗi weight. Với weights, đó là toàn bộ công thức.

[
  {
    "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 được huấn luyện có tính đến quantisation và phát hành với weights MXFP4 cùng activations MXFP8, nên dòng 4-bit mới là con số thực tế. Các dòng phía trên dùng để làm mốc so sánh: ở bf16, cùng model này sẽ cần 5.6 TB. MXFP4 cũng lưu một scale 8-bit dùng chung cho mỗi block gồm 32 weights, làm tăng dung lượng khoảng 6 phần trăm. Vì vậy, repository được công bố có dung lượng gần 1.5 TB hơn là 1.4 TB tròn.

Điều này loại bỏ cách né tránh thường gặp. "Chỉ cần quantise là được" không giúp ích trong trường hợp này, vì checkpoint đã phát hành vốn đã là 4-bit. Hạ xuống 2-bit sẽ đưa dung lượng weights xuống 0.7 TB, nhưng phải đánh đổi accuracy mà chưa có ai đo trên checkpoint này. Dù vậy, dung lượng vẫn vượt xa khả năng của bất kỳ card đơn nào.

Kimi K3 cần bao nhiêu GPU

[
  {
    "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
  }
]

Hãy xem các con số đó là mức tối thiểu, không phải cấu hình mục tiêu. Chúng chỉ tính phần weights: không bao gồm KV cache, buffer activation, phân mảnh của allocator và dung lượng dự phòng cho request đồng thời thứ hai. Chúng cũng giả định mô hình được chia song song theo cách phân chia đều, điều mà 93 layer và 896 expert không phải lúc nào cũng cho phép.

Tài liệu hướng dẫn được công bố đưa ra cấu hình cao hơn nhiều so với mức tối thiểu. Tính đến tháng 8 năm 2026, Moonshot khuyến nghị một supernode có từ 64 accelerator trở lên. Cookbook của SGLang cung cấp cấu hình H100 gồm 4 node 8 GPU, tổng cộng 32 GPU và 2,560 GB memory, trong khi mức tối thiểu là 18 card. Phần chênh lệch đó không phải là lãng phí. Nó dành cho KV cache, memory của activation và headroom để server batch nhiều request cùng lúc. Ngay cả dòng dễ đáp ứng nhất, 5 card thuộc class GB300, cũng mô tả một máy mà hầu hết provider không cho thuê dưới dạng một SKU duy nhất.

KV cache là phần khiến nhiều người bất ngờ

Weights là chi phí cố định. KV (key value) cache thì không: nó tăng theo độ dài context và tăng thêm theo từng user đồng thời. Với attention thông thường, công thức là bytes per token = 2 * layers * kv_heads * head_dim * bytes_per_element, sau đó nhân với độ dài context và số user đồng thời.

Dưới đây là một ví dụ tính cụ thể, chỉ mang tính minh họa: 64 layer, 8 KV head, head dimension 128, fp8. Kết quả là 2 64 8 128 1 = 131,072 byte, tương đương 128 KiB cho mỗi token.

[
  {
    "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
  }
]

Một user với context 128k cần 16 GiB. Một user với context tối đa 1 triệu token cần 128 GiB. Con số này lớn hơn dung lượng của bất kỳ card đơn nào, chỉ cho một conversation.

K3 không dùng attention thông thường, và chính con số trên giải thích lý do. K3 có 93 layer, gồm 69 layer KDA (Kimi Delta Attention) và 24 layer Gated MLA (multi-head latent attention). KDA giữ một recurrent state có kích thước cố định thay vì cache tăng theo từng token. MLA nén key và value thành một latent vector low rank, nên chi phí thực tế cho mỗi token thấp hơn nhiều so với ví dụ trên. Moonshot chưa công bố các latent dimension, nên tôi sẽ không đưa ra con số cho mỗi user của riêng K3. Hãy tự đo trên hệ thống của bạn: khởi động server với --max-model-len nhỏ, theo dõi memory bằng nvidia-smi, rồi tăng giới hạn cho đến khi việc cấp phát thất bại.

Cách suy luận này vẫn đúng ở release tiếp theo. Nếu một model quảng cáo context 1 triệu token nhưng không nói gì về thiết kế attention, hãy giả định cache là giới hạn chính cho đến khi có bằng chứng ngược lại.

Tầng 1: thuê cluster theo giờ

Đây là tầng duy nhất chạy K3 trực tiếp. Bạn không mua phần cứng. Bạn thuê trong số giờ cần dùng rồi dừng cluster sau đó.

[
  {
    "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"
  }
]

Mức giá này chỉ là giả định, không phải báo giá. Trong năm 2026, giá niêm yết on-demand cho accelerator tại datacentre dao động khoảng 2 đến 5 USD cho mỗi GPU-giờ, còn capacity đặt trước thì rẻ hơn. Hãy lấy mức giá thực tế của provider rồi tính lại: số GPU nhân số giờ nhân đơn giá. Biểu đồ nhằm thể hiện tỷ lệ chi phí. Bật một node 8 GPU trong 4 giờ mỗi ngày tốn 2,400 USD mỗi tháng, còn để cấu hình SGLang 32 GPU chạy liên tục tốn 57,600 USD.

Cả hai server phổ biến đều công bố lệnh khởi động trên model card.

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

Không lệnh nào trong hai lệnh trên có thể chạy nguyên bản trên cluster thực tế. Hãy thêm các flag parallelism phù hợp với phần cứng: SGLang dùng --tp-size cho tensor parallel và --ep-size cho expert parallel; tích của hai giá trị này phải bằng số GPU thực tế bạn có.

Kiểm tra server đã khởi động trước khi gửi traffic thật:

curl http://127.0.0.1:30000/v1/models

Server hoạt động bình thường sẽ trả về một JSON object có model id. Connection refused nghĩa là process vẫn đang load weight hoặc đã thoát, vì vậy hãy đọc server log trước khi thử lại.

Lỗi thường gặp nhất trong ngày đầu tiên là runtime cũ hơn model. K3 được phát hành cùng KDA và một MoE layer mới mà các bản release ổn định của vLLM và SGLang chưa hỗ trợ khi ra mắt. Triệu chứng là server thoát trong lúc khởi động, kèm một dòng có dạng Model architectures [...] are not supported for now. Không thể sửa lỗi này bằng cách đổi config, vì build của bạn không chứa code để chạy các layer đó. Hãy cài bản nightly được nêu trên model card hoặc chờ bản release có hỗ trợ.

Có một điểm về chi phí thường bị bỏ sót. Meter bắt đầu tính khi instance khởi động, không phải khi model sẵn sàng. Tải xuống 1.5 TB với tốc độ 1 GB/s mất khoảng 25 phút cluster time trước khi sinh token đầu tiên. Hãy stage weight trên một volume tồn tại lâu hơn instance để lần chạy thứ hai chỉ mất vài phút.

Tier 2: chạy model nhỏ hơn trên một accelerator

Bạn không chạy K3 ở tier này. Hãy nói rõ điều đó trước khi bắt đầu, vì hầu hết các thread về “chạy K3 local” đều kết thúc ở đây nhưng không thừa nhận.

Quy tắc chọn model vẫn dùng công thức tương tự ở quy mô nhỏ hơn: số parameter nhân với số byte trên mỗi weight, cộng KV cache và khoảng 2 GB overhead của runtime, phải nhỏ hơn dung lượng VRAM. Ở mức 4-bit, con số này xấp xỉ nửa byte trên mỗi parameter, nên có các lựa chọn phù hợp sau:

• Card 16 GB: model 7B ở mức 4-bit, còn đủ chỗ cho context dài
• Card 24 GB: model 14B ở mức 4-bit
• Card 48 GB: model 32B ở mức 4-bit
• Card 80 GB: model 70B ở mức 4-bit hoặc MoE thuộc class 30B ở mức 8-bit

Ollama là cách ngắn nhất để có một server hoạt động trên VPS gắn GPU:

curl -fsSL https://ollama.com/install.sh | sh
ollama run qwen3:14b

ollama run tải model trong lần sử dụng đầu tiên, sau đó đưa bạn đến prompt. Nếu tag không tồn tại, lệnh sẽ trả về Error: model "..." not found. Vì vậy, hãy copy tag từ trang library thay vì tự nhớ rồi nhập lại. Hướng dẫn đầy đủ, bao gồm systemd unit và remote access, có trong chạy Ollama trên VPS.

llama.cpp cho bạn nhiều quyền kiểm soát hơn đối với quantisation và offload:

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 yêu cầu offload mọi layer lên GPU. Hãy đọc load log: log này cho biết có bao nhiêu layer đã được offload. Các layer tràn sang system RAM sẽ chạy với băng thông RAM thay vì băng thông HBM, nên tốc độ generation giảm khoảng một bậc độ lớn ngay khi model không còn vừa với VRAM. Các đánh đổi giữa hai công cụ này được trình bày trong Ollama và llama.cpp đối chiếu trực tiếp.

Tier 3: API được host, orchestration tự host

[
  {
    "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"
  }
]

Endpoint tương thích với OpenAI, nên client hiện có sẽ hoạt động sau khi bạn đổi 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."}]}'

Key hợp lệ trả về một JSON object có mảng choices. Lỗi 401 nghĩa là key không đúng hoặc thiếu tiền tố Bearer. Lỗi không tìm thấy model thường có nghĩa là id đã thay đổi, vì các provider loại bỏ id giữa những lần checkpoint.

Tiếp theo là điểm hòa vốn, dùng mức giá thuê giả định ở trên. Một node 8 GPU chạy liên tục có giá 14,400 USD mỗi tháng. Với mức 15.00 USD cho mỗi triệu output token, cùng số tiền đó mua được khoảng 960 triệu output token từ API. Để có lợi về chi phí, bạn phải tạo gần 1 tỷ output token mỗi tháng, tương đương khoảng 30 triệu token mỗi ngày, đồng thời phải giữ cluster hoạt động liên tục. GPU khi idle vẫn bị tính phí như khi đang xử lý. Với workload agent sử dụng nhiều prompt, điểm hòa vốn còn xa hơn: context lặp lại được tính theo mức cache-hit 0.30 USD mỗi triệu token, thay vì mức cache-miss 3.00 USD.

Ở tier này, phần bạn tự host là mọi thứ xung quanh model: gateway giữ API key để key không bao giờ đến client, log request và response, retry, rate limit và ngân sách theo từng user. Thành phần này chạy trên một VPS nhỏ hoàn toàn không có GPU. Cách phân tách tương tự cũng áp dụng cho các model có weight đóng. Tự host Claude ở cấp model là không thể, nên orchestration là phần duy nhất bạn sở hữu.

Stack serving nào phù hợp với từng tier

Các server thuộc nhóm vLLM và SGLang nằm ở tier 1. Chúng được thiết kế để phục vụ nhiều request đồng thời, với continuous batching và paged KV cache, đồng thời hỗ trợ tensor parallelism và expert parallelism trên nhiều node. Chúng giả định bạn có accelerator trong datacenter và interconnect tốc độ cao giữa các accelerator đó. Trên một consumer card duy nhất, chúng khó cài đặt hơn và hầu như không mang lại lợi ích đáng kể.

llama.cpp và Ollama nằm ở tier 2. Chúng nhắm đến một máy duy nhất, GGUF quantisation, CPU offload khi model không vừa VRAM, và concurrency thấp. Về mặt kỹ thuật, llama.cpp có thể load một MoE cực lớn bằng cách giữ phần lớn layer trong system RAM. Với model 2.8T, cách này chỉ đạt tốc độ tính bằng vài giây cho mỗi token. Nó chỉ chứng minh rằng file có thể được parse. Đây không phải stack để bạn đưa user vào sử dụng. Phần so sánh đầy đủ nằm trong Ollama so với vLLM. Kết luận này không thay đổi theo model: câu hỏi luôn là bạn đang phục vụ nhiều user trên hardware dùng chung hay một user trên hệ thống của riêng mình.

Bốn con số vẫn còn đúng sau mốc kiểm tra này

1. Tổng số parameter nhân với số byte trên mỗi weight cho biết mức bộ nhớ tối thiểu. Không hệ thống nào chạy dưới mức đó, và không có mẹo quantisation nào thay đổi đáng kể con số này khi bản release đã ở 4-bit.
2. Số parameter đang active quyết định nhóm throughput. MoE 2.8T có 104B parameter active sẽ có đặc tính tính toán như model 104B.
3. KV cache trên mỗi token, nhân với độ dài context và số phiên chạy đồng thời, là chi phí tiếp tục tăng sau khi bạn đã phân bổ bộ nhớ cho các weight.
4. Tokens mỗi giây trên mỗi dollar là con số duy nhất dùng để chọn tier. Mọi con số ở trên đều là dữ liệu đầu vào cho nó.

Áp dụng 4 yếu tố này cho bất kỳ bản release nào, bạn sẽ có câu trả lời đúng trước khi mở hướng dẫn của vendor. Sau đó, luôn ghi ngày cho từng số liệu. Giá và danh sách kiến trúc được hỗ trợ đều đã thay đổi trong 2 tuần sau khi K3 ra mắt, và mọi con số trên trang này đều là số liệu được công bố vào tháng 7 năm 2026.

FAQ

Tôi có thể chạy Kimi K3 trên một GPU không?

Không. Trọng số có kích thước khoảng 1.4 TB ở độ chính xác MXFP4 mà Moonshot phát hành, trong khi accelerator đơn lớn nhất đang bán chỉ có 288 GB. MoE model không thể đọc các expert không hoạt động từ disk với tốc độ đủ dùng, vì router có thể chọn bất kỳ expert nào cho bất kỳ token nào và một lần đọc qua PCIe mất nhiều thời gian hơn ngân sách thời gian cho mỗi token. Triển khai K3 hợp lý nhỏ nhất là một node nhiều GPU, còn các công thức triển khai đã công bố sử dụng từ 32 accelerator trở lên.

Kimi K3 cần bao nhiêu VRAM?

Riêng phần trọng số đã cần khoảng 1.4 TB, tương đương 18 card H100 80GB hoặc 5 card loại GB300. Sau đó cần cộng thêm bộ nhớ KV cache và activation. Tính đến tháng 8 năm 2026, Moonshot khuyến nghị dùng từ 64 accelerator trở lên. SGLang cookbook cũng công bố cấu hình 32 GPU H100 với tổng cộng 2,560 GB, vì vậy hãy xem dung lượng trọng số là mức sàn, không phải yêu cầu đầy đủ.

Quantisation có giúp Kimi K3 chạy vừa trên một node không?

Không theo cách hữu ích. Checkpoint được phát hành đã dùng 4-bit và quantisation-aware training, nên phần tiết kiệm dễ đạt được đã được áp dụng. Giảm tiếp xuống 2-bit đưa trọng số về 0.7 TB, vẫn lớn hơn gấp đôi card lớn nhất. Ngoài ra, chi phí về độ chính xác của 2-bit trên model này chưa được đo lường.

Thuê GPU có rẻ hơn Kimi K3 API không?

Chỉ khi lưu lượng cao và ổn định. Với giả định 2.50 USD cho mỗi GPU hour, một node 8 GPU chạy liên tục có giá 14,400 USD mỗi tháng. Cùng số tiền đó mua được khoảng 960 triệu output token theo mức giá đã công bố là 15.00 USD cho mỗi triệu token. Bạn cũng phải trả cho thời gian GPU idle, việc tải trọng số và người duy trì cluster hoạt động. Hãy thuê theo giờ cho các đợt tải tăng đột biến, rồi so sánh với volume token thực tế đã đo thay vì dùng số ước tính.

104B active parameters có ý nghĩa gì đối với tốc độ?

Điều đó có nghĩa là lượng tính toán cho mỗi token tương đương model 104B, nên throughput thuộc nhóm này thay vì nhóm 2.8T. Con số này không cho biết yêu cầu về memory: toàn bộ 2.8T parameter vẫn phải nằm trong memory, vì router có thể gọi bất kỳ expert nào cho bất kỳ token nào. Dùng số active parameters để dự đoán số token mỗi giây, và dùng tổng số parameters để tính dung lượng VRAM cần thiết.