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

Tự host Kimi K3 cần những gì

Tự host Kimi K3 nghĩa là phải có đủ chỗ cho 2.8 nghìn tỷ parameter. Moonshot công bố model với các weight ở định dạng MXFP4. Định dạng này cần khoảng nửa byte cho mỗi weight, nên riêng phần 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 nào bán trên thị trường có thể tự chứa toàn bộ lượng dữ liệu đó. K3 là model chạy trên nhiều node. Vì vậy, một server duy nhất không đáp ứng được.

Đó là kết luận. Phần còn lại là các phép tính đứng sau kết luận này, vì bạn có thể dùng lại chúng cho release tiếp theo. Trong vài tuần sau khi công bố vào ngày 17 July 2026, một số nhà cung cấp hạ tầng đã xuất bản hướng dẫn triển khai K3. Tất cả đều giả định rằng bạn đã có 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 network 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 liệt kê 2.8T tổng số parameter và 104B parameter được kích hoạt cho mỗi token, từ 896 expert được định tuyến, trong đó 16 expert được kích hoạt cho mỗi token, trên 93 layer.

Hai số liệu này trả lời hai câu hỏi khác nhau. Nhầm lẫn giữa chúng là lỗi phổ biến nhất trong mọi thread “tôi có thể chạy mô hình này không”.

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

Tổng số parameter quyết định chi phí memory. 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 fetch phần còn lại khi cần, vì thao tác fetch phải hoàn tất trong vài microsecond, trong khi liên kết PCIe chỉ truyền được hàng chục gigabyte mỗi giây. Một số người vẫn thử cách này. Streaming expert từ NVMe biến một model lẽ ra phải phát ra hàng chục token mỗi giây thành model chỉ phát ra một token sau mỗi vài giây.

Vì vậy, chi phí compute thấp nhưng chi phí lưu trữ cao. Hãy chọn hardware dựa trên 2.8T. Hãy đặt kỳ vọng về tốc độ dựa trên 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 phần 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 train theo hướng quantisation-aware và phát hành với weights MXFP4 cùng activations MXFP8, nên dòng 4-bit là con số thực tế. Các dòng phía trên dùng để so sánh: ở bf16, cùng model này sẽ cần 5.6 TB cho weights. MXFP4 cũng lưu thêm 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 publish có dung lượng gần 1.5 TB hơn là 1.4 TB theo cách tính thuần túy.

Điều này loại bỏ cách né tránh thường gặp. “Cứ quantise là được” không giúp ích trong trường hợp này, vì checkpoint được phát hành vốn đã là 4-bit. Giảm xuống 2-bit sẽ đưa dung lượng weights còn 0.7 TB và làm giảm accuracy, nhưng chưa có ai đo mức giảm đó trên checkpoint này. Dù vậy, dung lượng vẫn vượt xa khả năng của bất kỳ một card đơn lẻ 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 đó là mức tối thiểu, không phải cấu hình mục tiêu. Các con số này chỉ tính phần weights: không 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 bổ đều, điều mà 93 layer và 896 expert không phải lúc nào cũng cho phép.

Các hướng dẫn được công bố đưa ra cấu hình cao hơn đáng kể. 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, so với mức tối thiểu là 18 card. Khoảng cách này không phải là phần dư thừa. 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ễ triển khai nhất, 5 card loại 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.

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

Weights là chi phí cố định. Cache KV (key value) thì không: nó tăng theo độ dài context và tiếp tục tăng theo số người dùng đồ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à mức đồng thời.

Dưới đây là một ví dụ tính toán, chỉ mang tính minh họa: 64 layer, 8 KV head, kích thước head là 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 người dùng với context 128k tiêu tốn 16 GiB. Một người dùng với context đầy đủ một triệu token tiêu tố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 cuộc hội thoại.

K3 không dùng attention thông thường, và con số trên giải thích lý do. 93 layer của K3 gồm 69 layer KDA (Kimi Delta Attention) và 24 layer Gated MLA (multi-head latent attention). KDA duy trì 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 duy nhất. Vì vậy, 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 người dùng trên chính 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 allocation thất bại.

Cách suy luận này vẫn đúng ở bản release tiếp theo. Nếu một model công bố context một 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.

Bậc 1: thuê cluster theo giờ

Đây là bậc duy nhất chạy chính K3. 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á. Giá niêm yết on-demand cho các accelerator tại datacenter trong năm 2026 vào khoảng 2 đến 5 USD mỗi GPU mỗi giờ, còn capacity được đặ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á. Mục đích của biểu đồ là cho thấy tỷ lệ. Burst 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 32 GPU phù hợp với SGLang 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 chạy 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 số đó có thể chạy nguyên trạng 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, đồng thời 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 liệt kê model id. Connection refused nghĩa là process vẫn đang load weights hoặc đã thoát, vì vậy hãy đọc server log trước khi thử lại.

Lỗi thường gặp trong ngày đầu tiên là runtime cũ hơn model. K3 được release 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, nên server sẽ thoát trong lúc khởi động với một dòng có dạng Model architectures [...] are not supported for now. Không thay đổi config nào có thể sửa lỗi này, vì build của bạn không có 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ợ.

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

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

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

Quy tắc kiểm tra độ vừa vẫn dùng cùng công thức, nhưng ở 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 runtime, phải nằm trong dung lượng VRAM. Với 4-bit, con số này xấp xỉ nửa byte cho mỗi parameter, nên có các cấu hình phù hợp sau:

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

Mỗi cấu hình trên chỉ giả định một request tại một thời điểm. Khi người thứ hai gửi prompt, mỗi slot chạy đồng thời cần một KV cache riêng. Đây là đánh đổi mà các thiết lập NUM_PARALLEL và MAX_QUEUE của Ollama giúp bạn điều chỉnh giữa số slot chạy song song, số request xếp hàng và lượng VRAM còn trống.

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 ở lần sử dụng đầu tiên, sau đó đưa bạn đến prompt. Tag không tồn tại sẽ trả về Error: model "..." not found, vì vậy hãy copy tag từ trang library thay vì gõ theo trí nhớ. Hướng dẫn đầy đủ, bao gồm systemd unit và truy cập từ xa, 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 mọi layer chạy trên GPU. Hãy đọc load log: log này cho biết bao nhiêu layer đã được offload. Các layer tràn sang system RAM sẽ chạy ở băng thông RAM thay vì băng thông HBM, vì vậy tốc độ generation giảm một bậc độ lớn ngay khi model không còn vừa. Các đánh đổi giữa hai công cụ được trình bày trong so sánh Ollama và llama.cpp.

Tier 3: API hosted, 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 prefix Bearer. Lỗi không tìm thấy model thường có nghĩa là id đã thay đổi, vì các nhà cung cấp ngừng hỗ trợ id giữa những lần checkpoint.

Bây giờ tính điểm hòa vốn theo 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 hơn 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 duy trì cluster hoạt động gần như toàn thời gian. GPU idle vẫn bị tính phí như GPU đang chạy. Các workload agent có nhiều prompt còn làm điểm hòa vốn cách xa hơn: context lặp lại được tính theo mức cache-hit là 0.30 USD cho mỗi triệu token, thay vì mức cache-miss là 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, cơ chế retry, rate limit và ngân sách theo từng user. Phần này có thể chạy trên một VPS nhỏ hoàn toàn không cần GPU. Cách phân tách tương tự cũng áp dụng cho các model có weight đóng. Với trường hợp đó, tự host Claude ở cấp model là không thể; orchestration là phần duy nhất bạn kiểm soát.

Stack serving nào thuộc tier nào

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

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

Bốn con số vẫn còn giá trị 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 được dưới mức này, và không mẹo quantisation nào có thể giảm đáng kể mức đó khi bản release đã ở 4-bit.
2. Số parameter active cho biết nhóm throughput. MoE 2.8T với 104B parameter active có năng lực tính toán tương đương model 104B.
3. KV cache trên mỗi token, nhân với độ dài context, rồi nhân với số phiên chạy đồng thời, là chi phí tiếp tục tăng sau khi bạn đã cấp bộ nhớ cho weight.
4. Tokens per second trên mỗi dollar là con số duy nhất dùng để chọn tier. Mọi số liệu bên trên đều là đầ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ở tài liệu của vendor. Sau đó, hãy ghi ngày cho mọi số liệu bạn ghi lại. Giá và danh sách architecture đượ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 được công bố vào July 2026.

FAQ

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

Không. Phần weights 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. Model MoE 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 phép của token. Triển khai K3 nhỏ nhất có tính thực tế là một node nhiều GPU, và các công thức triển khai đã công bố dùng từ 32 accelerator trở lên.

Kimi K3 cần bao nhiêu VRAM?

Riêng phần weights đã cần từ 1.4 TB. Con số này tương đương 18 card H100 80GB hoặc 5 card cấp GB300. Sau đó cần cộng thêm KV cache và bộ nhớ activation. Tính đến August 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 con số cho weights là mức sàn, không phải cấu hình bắt buộc.

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

Không đáng kể. Checkpoint được phát hành đã là 4-bit và đã được quantisation-aware training, nên phần dung lượng dễ giảm đã được xử lý. Giảm tiếp xuống 2-bit đưa phần weights xuống 0.7 TB, vẫn cao hơn gấp đôi dung lượng của card lớn nhất. Chi phí về độ chính xác của 2-bit trên model này cũng chưa được đo.

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

Chỉ khi volume cao và ổn định. Với giả định giá 2.50 USD mỗi GPU mỗi giờ, một node 8 GPU chạy liên tục tốn 14,400 USD mỗi tháng. Với cùng số tiền, bạn mua được khoảng 960 triệu output token theo mức giá đã công bố là 15.00 USD mỗi triệu token. Bạn cũng phải trả cho thời gian idle, việc tải weights 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, đồng thời so sánh với volume token thực tế bạn đo được thay vì một con số ước tính.

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

Điều đó có nghĩa là lượng phép tính cho mỗi token tương đương một model 104B. Vì vậy, throughput thuộc nhóm 104B chứ không phải nhóm 2.8T. Con số này không cho biết yêu cầu về memory: toàn bộ 2.8T parameters vẫn phải được giữ 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.