Hướng dẫn tự host Kimi K3: Yêu cầu phần cứng chi tiết

Yêu cầu để tự host Kimi K3

Tự host Kimi K3 đồng nghĩa với việc tìm chỗ chứa cho 2,8 nghìn tỷ tham số. Moonshot đã công bố các open weights ở định dạng MXFP4, tương đương khoảng nửa byte cho mỗi tham số, vì vậy riêng phần trọng số đã chiếm khoảng 1.4 TB trước khi bạn cấp phát bất kỳ token nào cho cache. Không có bộ tăng tốc (accelerator) nào đang bán trên thị trường hiện nay có thể chứa được dung lượng đó một mình. Với một GPU, câu trả lời là không. Với một máy chủ, câu trả lời là có theo hai cấu hình. Thứ nhất là node 8-GPU với các bộ tăng tốc 288 GB, đây là cấu hình nhỏ nhất trong các công thức phục vụ đa người dùng đã được công bố. Thứ hai là một máy đơn lẻ với khoảng 1,6 TB RAM và VRAM kết hợp, chạy GGUF Q8 không mất dữ liệu của Unsloth trong llama.cpp, có hoặc không có GPU, phục vụ từng người dùng một.

Đó là kết luận cuối cùng. Mọi nội dung bên dưới là các phép tính đằng sau nó, vì đây là phần bạn sẽ dùng lại cho bản phát hành tiếp theo. Một số nhà cung cấp hạ tầng đã xuất bản các hướng dẫn triển khai K3 trong những tuần sau thông báo ngày 16 tháng 7 năm 2026, và mỗi hướng dẫn đều giả định rằng bạn đã sở hữu một cluster. Trang này bắt đầu từ phía ngược lại: chi phí là bao nhiêu, bạn có thể chạy cái gì thay thế, và làm thế nào để biết bạn thuộc trường hợp nào trong hai trường hợp trên.

Tổng số tham số và số tham số hoạt động không bằng nhau

K3 là một mô hình mixture of experts. MoE (mixture of experts) chia mạng thành nhiều mạng con và để một router chọn một vài trong số đó cho mỗi token. Model card liệt kê tổng cộng 2.8T tham số và 104B tham số được kích hoạt trên mỗi token, từ 896 chuyên gia (expert) được định tuyến, trong đó 16 chuyên gia sẽ hoạt động cho bất kỳ token nào, trải dài trên 93 lớp.

Hai con số tham số này trả lời cho các câu hỏi khác nhau, và việc nhầm lẫn giữa chúng là sai lầm phổ biến nhất trong mọi chủ đề thảo luận kiểu "tôi có chạy được cái này không".

Tham số hoạt động quyết định chi phí tính toán. Một token thực hiện phép nhân qua khoảng 104B tham số, vì vậy thông lượng bạn nên kỳ vọng tương đương với một mô hình dense 104B chứ không phải 2.8T. Đó chính là lý do toàn bộ để xây dựng một MoE.

Tổng số tham số quyết định chi phí bộ nhớ. Router có thể chọn bất kỳ chuyên gia nào cho bất kỳ token nào, vì vậy mọi chuyên gia đều phải được lưu trữ ở đâu đó có tốc độ nhanh trước khi request đầu tiên đến. Việc chỉ giữ các chuyên gia "nóng" trong VRAM và tải phần còn lại theo yêu cầu là có tồn tại: --moe-cache-mib của llama.cpp duy trì một GPU cache cho các chuyên gia vốn nằm trong RAM hệ thống và tải lên những chuyên gia còn thiếu khi router chọn chúng. Tuy nhiên, điều này không làm giảm tổng số tham số. Các chuyên gia còn lại vẫn phải nằm trong RAM, và kết nối PCIe chỉ truyền được hàng chục gigabyte mỗi giây so với hàng terabyte mỗi giây của HBM, nên mỗi lần cache miss đều gây tốn thời gian. Việc stream chuyên gia từ NVMe vì mô hình không vừa RAM hệ thống còn chậm hơn nữa, và hướng dẫn K3 của Unsloth cảnh báo rằng disk offloading chạy chậm hơn rất nhiều.

Tóm lại, nó rẻ về tính toán nhưng đắt về lưu trữ. Hãy chọn phần cứng dựa trên con số 2.8T. Hãy đặt kỳ vọng về tốc độ dựa trên con số 104B.

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

Số lượng tham số nhân với số byte trên mỗi trọng số. Đối với trọng số, đó 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 với nhận thức về lượng tử hóa (quantisation aware) và được phát hành với trọng số MXFP4 cùng activation MXFP8, vì vậy hàng 4-bit là hàng thực tế. Các hàng phía trên chỉ để so sánh: ở định dạng bf16, cùng mô hình đó sẽ cần 5.6 TB. MXFP4 cũng lưu trữ một scale 8-bit dùng chung cho mỗi khối 32 trọng số, làm tăng thêm khoảng 6 phần trăm, và cấu hình của Moonshot không áp dụng định dạng 4-bit cho attention, các shared expert và vision tower, nên checkpoint đầy đủ có dung lượng khoảng 1,56 TB theo tính toán của Unsloth thay vì con số tròn 1.4 TB.

Điều này thu hẹp lối thoát thông thường mà không đóng hoàn toàn. Checkpoint được phát hành đã ở dạng 4-bit, nên phần tiết kiệm dễ dàng đã được thực hiện, nhưng việc giảm xuống thấp hơn vẫn làm thay đổi con số. Tính đến ngày 27 tháng 10 năm 2026, các bản lượng tử hóa GGUF động của K3 mà Unsloth đã đo lường chạy từ 861,3 GB cho bản 2-bit UD-Q2_K_XL xuống còn 594 GB cho bản 1-bit UD-IQ1_S, và Unsloth công bố chi phí của việc đó: tỷ lệ đồng thuận token top-1 so với mô hình đầy đủ là 90,390 phần trăm ở UD-Q2_K_XL, 84,127 phần trăm ở bản 711,1 GB UD-IQ2_XXS và 78,875 phần trăm ở UD-IQ1_S. Repo Hugging Face của họ cũng chứa các file 1-bit nhỏ hơn, xuống tới 466 GB cho UD-Q1_0, mà không có số liệu đồng thuận nào được công bố kèm theo. Đó là mức suy giảm độ chính xác đã được đo lường, và ngay cả file nhỏ nhất vẫn lớn gấp khoảng 1,6 lần dung lượng của card đơn lớn nhất.

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 coi các con số này là mức tối thiểu, không phải mục tiêu. Chúng chỉ tính trọng số: không bao gồm KV cache, bộ đệm kích hoạt (activation buffer), phân mảnh bộ nhớ (allocator fragmentation), và không có dung lượng cho request thứ hai chạy đồng thời. Việc phân chia không nhất thiết phải đều nhau: pipeline parallelism của vLLM chia model theo các lớp và hỗ trợ phân chia không đều, còn các công thức prefill K3 của SGLang chạy 8 và 16 pipeline stage trên 93 lớp.

Hướng dẫn được công bố nằm trên mức tối thiểu này. Hướng dẫn ra mắt của Moonshot khuyến nghị một supernode từ 64 accelerator trở lên. Tính đến ngày 27 tháng 10 năm 2026, cookbook của SGLang cung cấp cấu hình H100 xây dựng từ bốn node 8-GPU, tổng cộng 32 GPU và 2.560 GB bộ nhớ gộp, so với mức tối thiểu là 18 card. Tài liệu này cũng liệt kê các công thức cho node đơn trên một node 8-GPU B300 và một node 8-GPU MI350X hoặc MI355X, với 2.304 GB (288 GB mỗi card). Khoảng cách vượt trên mức tối thiểu đó không phải là lãng phí. Đó là dung lượng dành cho KV cache, bộ nhớ kích hoạt và khoảng trống (headroom) cho phép máy chủ xử lý batch nhiều request cùng lúc. Dòng thân thiện nhất, 5 card loại GB300, trên thực tế được làm tròn thành đúng loại node 8-GPU đó, đây là cấu hình máy nhỏ nhất mà bất kỳ ai công bố công thức serving K3 cho nhiều người dùng.

KV cache là phần gây bất ngờ cho nhiều người

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 với mỗi 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 đó bạn nhân với độ dài context và số lượng người dùng đồng thời.

Dưới đây là một ví dụ tính toán, chỉ là ví dụ: 64 layers, 8 KV heads, head dimension 128, fp8. Kết quả là 2 64 8 128 1 = 131,072 bytes, tức là 128 KiB 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 tốn 16 GiB. Một người dùng với toàn bộ một triệu token tốn 128 GiB, gần bằng một nửa dung lượng của một card 288 GB cho một cuộc hội thoại, trước khi bất kỳ weight nào được load.

K3 không sử dụng attention thông thường, và con số cuối cùng đó là lý do tại sao. 93 layers của nó bao gồm 69 layers KDA (Kimi Delta Attention) và 24 layers Gated MLA (multi-head latent attention). KDA duy trì một trạng thái recurrent kích thước cố định thay vì một cache tăng theo từng token, và MLA nén key và value thành một latent vector rank thấp, vì vậy chi phí thực tế trên mỗi token thấp hơn nhiều so với ví dụ trên. File config.json được Moonshot công bố cho biết kích thước của latent đó: một kv_lora_rank là 512 cộng với một rotary key rộng 64 (qk_rope_head_dim), tổng cộng là 576 giá trị mỗi token cho mỗi MLA layer. Với 24 layers, mỗi layer 2 bytes, tổng cộng là 27,648 bytes, khoảng 27 KiB mỗi token, hoặc xấp xỉ 27 GiB cho một cuộc hội thoại đầy đủ 1,048,576 token, cộng với trạng thái KDA cố định. Hãy coi đây là ước tính thay vì đo lường chính xác: các engine tự padding và bố trí cache theo cách riêng, và cache 8-bit sẽ giảm dung lượng xuống khoảng một nửa.

Để xem deployment của bạn đang chiếm dụng bao nhiêu, đừng theo dõi nvidia-smi trong khi tăng --max-model-len. vLLM cấp phát trước pool KV cache, được tính toán từ --gpu-memory-utilization (mặc định là 0.92 trong tài liệu hiện tại) hoặc từ một ngân sách cache cụ thể trên mỗi GPU, vì vậy tổng bộ nhớ GPU hiển thị pool đó thay vì chỉ một cuộc hội thoại. Thay vào đó, hãy đọc log khởi động, nơi vLLM báo cáo kích thước KV cache theo số lượng token và mức concurrency tối đa tại độ dài context của bạn.

Hình thái của quá trình suy luận vẫn sẽ tồn tại trong các bản release tiếp theo. Nếu một model quảng cáo context một triệu token mà không đề cập gì đến thiết kế attention, hãy mặc định cache là ràng buộc chính cho đến khi có bằng chứng ngược lại.

Tier 1: thuê cluster theo giờ

Đây là tier phục vụ K3 ở độ chính xác nguyên bản cho nhiều người dùng cùng lúc. Một máy có đủ RAM cũng có thể chạy K3 ở độ chính xác nguyên bản thông qua Q8 GGUF của Unsloth (được Unsloth gọi là lossless full precision), nhưng cách đó chỉ phục vụ một người dùng tại một thời điểm và được đề cập ở tier 2. Ở đây bạn không mua phần cứng. Bạn thuê nó theo số giờ cần dùng và dừng lại 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á chỉ là giả định, không phải báo giá. Giá on-demand thay đổi tùy theo nhà cung cấp và thế hệ GPU; các dòng 288 GB cần thiết cho cấu hình single-node có giá mỗi giờ cao hơn H100, và reserved capacity thì rẻ hơn. Hãy lấy con số thực tế từ nhà cung cấp của bạn và tính toán lại: số lượng GPU nhân với số giờ nhân với đơn giá. Mục đích của bảng này là để thấy tỷ lệ. Việc chạy burst một node 8 GPU trong bốn giờ mỗi ngày tốn 2,400 USD một tháng, trong khi để cấu hình 32 GPU H100 chạy SGLang 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ố đó là lệnh bạn chạy trên một cluster thực tế. Hãy thêm các flag song song phù hợp với phần cứng của bạn: SGLang dùng --tp-size cho tensor parallel, --pp-size cho pipeline parallel và --ep-size cho expert parallel. Tích của tensor parallel và pipeline parallel phải bằng số GPU bạn thực sự có, và expert parallel chia nhỏ các expert trong nhóm đó, đó là lý do tại sao cấu hình 32 GPU H100 thiết lập cả --tp-size 32 và --ep-size 32.

Kiểm tra server đã lên chưa trước khi gửi traffic thực tế:

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

Một 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à tiến trình vẫn đang load weights hoặc đã thoát, vì vậy hãy đọc log của server trước khi thử lại.

Lỗi phổ biến trong những tuần đầu là runtime cũ hơn model. K3 được phát hành với KDA và một layer MoE mới mà các bản release ổn định của vLLM và SGLang chưa hỗ trợ tại thời điểm ra mắt, triệu chứng là server thoát trong quá trình khởi động với một dòng dạng Model architectures [...] are not supported for now. Không thay đổi cấu hình nào sửa được lỗi này, vì code để chạy các layer đó không có trong bản build của bạn. Điều đó đã thay đổi: kể từ ngày 27 tháng 10 năm 2026, SGLang đã hỗ trợ K3 trong các bản release từ v0.5.17, với v0.5.22 là bản mới nhất, và ghi chú release từ v0.28.0 đến v0.32.0 của vLLM đều bao gồm các công việc liên quan đến K3. Hãy cài đặt bản release hiện tại. Một số đường dẫn dành riêng cho phần cứng vẫn yêu cầu image chuyên dụng, ví dụ như các bản build NVFP4 của SGLang trên Blackwell, vì vậy hãy kiểm tra công thức cho card của bạn.

Một lưu ý về chi phí thường gây bất ngờ. Đồng hồ tính tiền bắt đầu khi instance khởi động, không phải khi model đã sẵn sàng. Việc tải xuống 1.56 TB ở tốc độ 1 GB/s mất khoảng 26 phút thời gian cluster trước khi có token đầu tiên. Hãy lưu trữ weights trên một volume tồn tại độc lập với instance, để lần chạy thứ hai bắt đầu chỉ trong vài phút.

Tầng 2: chạy model nhỏ hơn trên một bộ tăng tốc

Bạn không chạy K3 ở tầng này. Hãy xác nhận điều đó trước khi bắt đầu, vì hầu hết các chủ đề "chạy K3 cục bộ" đều kết thúc tại đây mà không thừa nhận điều này.

Quy tắc vừa vặn vẫn là công thức tương tự ở quy mô nhỏ hơn: số lượng tham số nhân với số byte trên mỗi trọng số, cộng với KV cache, cộng thêm khoảng 2 GB overhead runtime, tất cả phải nằm gọn trong VRAM của bạn. Ở mức 4-bit, con số này xấp xỉ nửa byte trên mỗi tham số, tạo ra các cặp cấu hình phù hợp:

• Card 16 GB: model 7B ở 4-bit, còn dư 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 model MoE lớp 30B ở 8-bit

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

Có một cách để chạy chính K3 trên một máy chủ lớn, nằm giữa tầng này và tầng trước. Unsloth có tài liệu về các bản build GGUF của K3 trong llama.cpp, từ các mức quantisation 1-bit và 2-bit cho đến UD-Q8_K_XL, được gắn nhãn là độ chính xác đầy đủ không mất dữ liệu, và chỉ định NVIDIA DGX Station là phần cứng có thể chạy chúng. Quy tắc ngón tay cái của nó là RAM cộng với VRAM xấp xỉ bằng kích thước bản quant, từ khoảng 610 GB cho bản build 1-bit UD-IQ1_S đến khoảng 1.6 TB cho bản Q8. Nếu thấp hơn mức này, model sẽ phải dùng đến disk và tốc độ sẽ giảm mạnh. GPU là tùy chọn: hướng dẫn build của Unsloth cho phép tắt CUDA "nếu bạn không có GPU hoặc chỉ muốn chạy inference bằng CPU". Các bản build 1-bit và 2-bit là K3 đã được quantisation nặng, với cái giá phải trả về độ chính xác như đã đo lường ở trên. Bản build Q8 là K3 ở độ chính xác nguyên bản, phục vụ một người dùng ở tốc độ RAM. Cả hai đều không phải là model nhỏ hơn.

Ollama là con đường ngắn nhất để có một server hoạt động trên một VPS có 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 dấu nhắc lệnh. Một tag không tồn tại sẽ trả về Error: model "..." not found, vì vậy hãy copy các tag từ trang thư viện thay vì gõ theo trí nhớ. Hướng dẫn chi tiết, bao gồm cả systemd unit và truy cập từ xa, nằm trong bài chạy Ollama trên VPS.

llama.cpp cho bạn quyền kiểm soát tố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 đưa mọi layer lên GPU. Hãy đọc log tải: nó sẽ in ra số lượng layer đã được offload. Các layer bị tràn sang RAM hệ thống sẽ chạy ở băng thông RAM thay vì băng thông HBM, vì vậy tốc độ tạo văn bản sẽ giảm đi một bậc độ lớn ngay khi model không còn nằm gọn trong VRAM. Sự đánh đổi giữa hai công cụ này được đề cập trong bài so sánh Ollama và llama.cpp.

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

Một key hợp lệ sẽ trả về một đối tượng JSON với mảng choices. Lỗi 401 nghĩa là xác thực thất bại: hãy kiểm tra xem key có chính xác, đã hết hạn hay bị vô hiệu hóa chưa, và header có chứa Authorization: Bearer theo sau là key hay không. Lỗi model-not-found thường có nghĩa là id đã thay đổi, do các nhà cung cấp ngừng hỗ trợ các id cũ giữa các checkpoint.

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

Những gì bạn tự host ở tier này là mọi thứ xung quanh model: một gateway lưu trữ API key để nó không bao giờ truyền đến client, log request và response, cơ chế retry, rate limit và ngân sách cho từng người dùng. Hệ thống này chạy trên một VPS nhỏ không cần GPU. Cách phân chia tương tự áp dụng cho các model đóng, nơi việc tự host Claude ở cấp độ model là không thể và orchestration là phần duy nhất bạn sở hữu.

Stack phục vụ nào thuộc tầng nào

Các server như vLLM và SGLang thuộc tầng 1. Chúng được thiết kế để phục vụ nhiều request cùng lúc, sử dụng cơ chế continuous batching và paged KV cache, cùng với tensor parallelism và expert parallelism phân bổ trên nhiều node. Chúng yêu cầu các bộ tăng tốc cấp trung tâm dữ liệu và kết nối tốc độ cao giữa các node đó. Trên một card đồ họa phổ thông, việc cài đặt chúng tốn kém hơn và bạn sẽ không nhận thấy nhiều lợi ích.

llama.cpp và Ollama thuộc tầng 2. Chúng nhắm đến một máy đơn lẻ, sử dụng định dạng GGUF, hỗ trợ offload sang CPU khi model không đủ chỗ chứa, và xử lý mức độ đồng thời thấp. llama.cpp sẽ load một model MoE khổng lồ bằng cách giữ các trọng số expert trong RAM hệ thống (--cpu-moe hoặc --n-cpu-moe) và, với --moe-cache-mib, cache các expert đang sử dụng trên GPU; đó là cách các bản build K3 GGUF của Unsloth chạy trên một máy đơn lẻ. Tốc độ khi đó phụ thuộc vào băng thông RAM và tần suất router bị miss cache; nếu file lớn hơn tổng dung lượng RAM và VRAM, nó sẽ ghi xuống đĩa. Đây là thiết lập khả thi cho một người dùng. Nó không phải là một dịch vụ để bạn phục vụ nhiều người dùng cùng lúc. Bảng so sánh đầy đủ nằm tại Ollama so với vLLM, và điều này không thay đổi theo model: vấn đề luôn là liệu bạn đang phục vụ nhiều người dùng trên phần cứng dùng chung hay một người dùng trên máy của riêng bạn.

Bốn con số quan trọng hơn checkpoint này

1. Tổng số tham số nhân với số byte trên mỗi trọng số cho ra mức sàn bộ nhớ. Không có gì chạy được dưới mức này ở độ chính xác mặc định, và việc quantising xuống dưới bản release 4-bit chỉ giúp bạn tiết kiệm tối đa khoảng 70 phần trăm tài nguyên với cái giá phải trả là độ chính xác, chứ không phải là một bậc độ lớn.
2. Số tham số hoạt động (active parameters) quyết định phân khúc throughput. Một mô hình MoE 2.8T với 104B tham số hoạt động sẽ tính toán như một mô hình 104B.
3. KV cache trên mỗi token, nhân với độ dài context, nhân với số lượng concurrency, là chi phí tiếp tục tăng sau khi bạn đã trả phí cho các trọng số.
4. Số token trên mỗi giây trên mỗi đô la là con số duy nhất để chọn phân khúc. Mọi yếu tố trên đều là đầu vào cho con số này.

Áp dụng bốn yếu tố đó cho bất kỳ bản release nào và bạn sẽ có câu trả lời đúng trước khi mở hướng dẫn của nhà cung cấp. Bản tiếp theo đã được công bố: Moonshot đã triển khai K3.1 Pro, xây dựng trên nền tảng K3 với quá trình post-training bổ sung, trong Kimi Code vào ngày 23 tháng 10 năm 2026, và hướng dẫn quickstart API của họ cho biết các trọng số đầy đủ sẽ được phát hành trước ngày 4 tháng 11. Sau đó, hãy ghi ngày cho mọi con số bạn viết ra. Danh sách giá cả và kiến trúc được hỗ trợ đều đã thay đổi trong vòng hai tuần sau khi K3 ra mắt. Các con số ra mắt trên trang này được công bố vào tháng 7 năm 2026, và các công thức serving, bản phát hành runtime cùng các con số quantisation đã được kiểm tra lại vào ngày 27 tháng 10 năm 2026.

FAQ

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

Không. Trọng số của mô hình là khoảng 1.4 TB ở độ chính xác MXFP4 mà Moonshot phát hành. Ngay cả bản quantisation nhỏ nhất được công bố của K3 là file UD-Q1_0 466 GB của Unsloth cũng lớn gấp 1,6 lần dung lượng 288 GB của các bộ tăng tốc phổ biến nhất hiện nay. llama.cpp có thể giữ các expert trong RAM hệ thống và cache các expert đang hoạt động trên GPU, nhưng cách này vẫn yêu cầu dung lượng RAM cộng VRAM tương đương kích thước file quant. Nếu thấp hơn mức đó, mô hình sẽ phải ghi xuống đĩa và chạy rất chậm. Các công thức triển khai (serving recipe) nhỏ nhất hiện nay đều sử dụng một node 8 GPU loại B300 hoặc MI350X/MI355X, còn cấu hình cho H100 cần tới 32 GPU.

Kimi K3 cần bao nhiêu VRAM?

Hãy bắt đầu với 1.4 TB chỉ riêng cho trọng số, tương đương với 18 card H100 80GB hoặc 5 card dòng GB300. Sau đó, bạn cần cộng thêm dung lượng cho KV cache và bộ nhớ activation. Hướng dẫn ra mắt của Moonshot khuyến nghị dùng từ 64 bộ tăng tốc trở lên. Tính đến ngày 27 tháng 10 năm 2026, tài liệu SGLang cookbook đã công bố các công thức cho một node đơn sử dụng 8 card B300 hoặc 8 card MI350X/MI355X (tổng 2.304 GB) và cấu hình 32 GPU H100 (tổng 2.560 GB). Vì vậy, hãy coi con số trọng số là mức tối thiểu chứ không phải yêu cầu thực tế.

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

Checkpoint 4-bit được phát hành đã có thể chạy trên một node nếu node đó có tám card 288 GB (đây là cấu hình mà các recipe B300 và MI355X của SGLang sử dụng). Nó cũng có thể chạy trên một máy có khoảng 1,6 TB RAM cộng VRAM thông qua định dạng Q8 GGUF không mất dữ liệu của Unsloth. Việc giảm độ chính xác giúp ích cho các máy nhỏ hơn: các bản build GGUF động của Unsloth dao động từ 861,3 GB ở mức 2-bit đến 594 GB ở mức 1-bit, và repo của họ liệt kê các file 1-bit xuống tới 466 GB, so với khoảng 1,56 TB ở mức không mất dữ liệu. Chi phí về độ chính xác đã được đo lường: tỷ lệ đồng nhất top-1 với mô hình đầy đủ giảm xuống còn 90,390 phần trăm ở bản UD-Q2_K_XL và 78,875 phần trăm ở bản UD-IQ1_S. Không có bản nào trong số này chạy vừa trên một card đơn lẻ.

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

Chỉ khi bạn có lưu lượng truy cập cao và ổn định. Với giả định giá 2,50 USD mỗi giờ cho một GPU, một node 8 GPU chạy liên tục sẽ tốn 14,400 USD một tháng. Với cùng số tiền đó, bạn có thể mua 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ả tiền cho thời gian nhàn rỗi, chi phí tải trọng số và chi phí nhân sự duy trì cụm máy chủ. Hãy thuê theo giờ cho các đợt tải cao điểm và so sánh với lưu lượng token thực tế của bạn thay vì ước tính.

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

Nó có nghĩa là khối lượng tính toán trên mỗi token tương đương với một mô hình 104B, vì vậy throughput sẽ nằm trong phân khúc đó thay vì phân khúc 2,8T. Con số này không nói lên điều gì về bộ nhớ: tất cả 2,8T tham số vẫn phải nằm trong bộ nhớ vì router có thể gọi bất kỳ expert nào cho bất kỳ token nào. Hãy dùng số lượng active parameters để dự đoán số token mỗi giây, và dùng tổng số tham số để tính toán dung lượng VRAM cần thiết.