发布日期2026-07 | 关键词Kimi K3 本地部署、vLLM、SGLang、MXFP4、多机部署数据来源Hugging Face 仓库实测数据、vLLM 官方 recipe YAML、SGLang cookbook、官方 config.jsonKimi K3 本地部署的第一个现实是权重体积Hugging Face 仓库的 96 个 safetensors 分片实测合计1,560,936,091,448 字节即约 1560.9 GB1453.7 GiBvLLM 官方 recipe 标注最小显存需求为1680 GB。这意味着单卡、单机 8×80GB 配置均无法承载完整权重——vLLM 官方前置条件明确写的是至少 8× GB300生产流量需多机。官方已验证的硬件为 H200、B300、GB300、MI355X 四种并行策略上 TP 与 TEP 最低 8 卡、DEP 最低 16 卡。技术上值得注意的是这个 MXFP4 检查点并非全量 4bitconfig.json 的 quantization_config 设有 ignore 列表注意力层、共享专家、mlp 投影、lm_head 与视觉塔均保持高精度group_size 为 32。对绝大多数团队而言务实路径是官方 API 或社区 GGUF 量化版本已有 unsloth、GrEarl 等多个版本含 IQ1_S 极限量化而非自建集群。本文给出四条部署路线的完整命令、参数与适用判断。一、先看清硬件门槛避免无效投入1. 权重体积的实测数据这是所有部署决策的起点。我直接从 Hugging Face API 统计了全部 safetensors 分片项目实测值safetensors 分片数96 个权重总体积1,560,936,091,448 字节换算约 1560.9 GB / 1453.7 GiBvLLM 官方标注最小显存1680 GB含 1.2 倍余量注意 1680 GB 这个数字的来源——vLLM recipe YAML 的注释写明这是预发布估算2.8T params × 0.5 byte/param × 1.2 headroom并注明权重发布后应替换为真实 safetensors 体积。实测 1560.9 GB 与该估算基本吻合。2. 官方验证过的硬件据 vLLM recipe YAML 的hardware字段已标记为verified的有四种硬件状态备注GB300verified官方前置条件推荐default_hardware为 b300B300verifiedBlackwell 架构有专属优化参数H200verifiedHopper 架构需特殊 MoE backendMI355XverifiedAMD ROCmCDNA4 gfx950官方前置条件原文“At least 8x GB300. Multi-node for real production traffic.”至少 8× GB300真实生产流量需多机ROCm 路线原文“Use vllm/vllm-openai_rocm:kimi-k3 docker and at least 8x MI355X/MI350X hardware.”3. 并行策略的最低卡数据 YAML 的strategy_min_gpus字段策略最低 GPU 数说明single_node_tp8默认策略multi_node_tp8跨机张量并行multi_node_tep8张量专家并行multi_node_dep16数据专家并行卡数要求翻倍KV Cache 分布式存储全部不支持——YAML 的kv_cache_strategy_hardware字段显示 Mooncake 的分布式与集中式方案在 H100、H200、B200、GB200、B300、GB300、MI300X、MI325X、MI355X 上均标记为unsupported。二、MXFP4 不是全量 4bit一个容易误判的细节很多人看到MXFP4 量化就按 0.5 byte/param 估算显存但实际检查点保留了大量高精度模块。据官方config.json的quantization_config{format:mxfp4-pack-quantized,quant_method:compressed-tensors,quantization_status:compressed,config_groups:{group_0:{targets:[Linear],weights:{num_bits:4,group_size:32,strategy:group,symmetric:true,type:float,observer:minmax}}},ignore:[re:.*self_attn.*,re:.*shared_experts.*,re:.*mlp\\.(gate|up|gate_up|down)_proj.*,re:.*lm_head.*,re:.*vision_tower.*,re:.*mm_projector.*]}保持高精度的模块不参与 4bit 量化self_attn— 全部注意力层shared_experts— 2 个共享专家mlp.gate/up/gate_up/down_proj— 稠密 MLP 投影lm_head— 输出头vision_tower/mm_projector— 视觉编码器与投影层这解释了为什么实测 1560.9 GB 高于纯 4bit 理论值2.8T × 0.5 byte 1400 GB。三、架构参数部署前需要知道的关键配置据官方config.json实测提取参数值num_hidden_layers93hidden_size7168intermediate_size33792moe_intermediate_size3072vocab_size163840max_position_embeddings1048576num_attention_heads96kv_lora_rank512q_lora_rank1536first_k_dense_replace1attn_res_block_size12hidden_actsituSiTU-GLUdtypebfloat16KDA 与全注意力层的精确分布config.json 的linear_attn_config给出了确切的层号分布这比69 KDA 24 Gated MLA的概括更有用full_attn_layers: [4, 8, 12, 16, 20, 24, 28, 32, 36, 40, 44, 48, 52, 56, 60, 64, 68, 72, 76, 80, 84, 88, 92, 93] kda_layers: [1,2,3, 5,6,7, 9,10,11, 13,14,15, ...] 共 69 层规律是每 4 层里有 3 层 KDA、1 层全注意力第 4、8、12… 为全注意力末尾第 92、93 层连续为全注意力。KDA 配置num_heads: 96、head_dim: 128、short_conv_kernel_size: 4、use_full_rank_gate: true、gate_lower_bound: -5.0。四、路线一vLLM 部署官方推荐文档最全1. 前置要求项目要求vLLM 版本≥ 0.27.0min_vllm_version镜像NVIDIAvllm/vllm-openai:kimi-k3镜像AMDvllm/vllm-openai-rocm:kimi-k3nightly必需nightly_required: true难度标注hard2. 基础参数所有硬件通用据 YAML 的base_args--trust-remote-code\--load-format fastsafetensors\--moe-backend auto\--gpu-memory-utilization0.95fastsafetensors是官方推荐的加载格式YAML 注释说明它能显著加快权重加载考虑到 1560 GB 的体积这个优化很关键。3. BlackwellB300 / GB300优化参数--max-model-len1000000\--kv-cache-dtype fp8\--attention-config{mla_prefill_backend:TRTLLM_RAGGED,use_prefill_query_quantization:true}\--max-num-batched-tokens32768\--enable-prefix-caching配套环境变量exportVLLM_ENABLE_K3_LATENT_MOE_TAIL_FUSION1exportVLLM_ALLREDUCE_USE_FLASHINFER1exportVLLM_ENGINE_READY_TIMEOUT_S3600exportVLLM_USE_V2_MODEL_RUNNER1exportVLLM_USE_RUST_FRONTEND1VLLM_ENGINE_READY_TIMEOUT_S3600不是可选项——1560 GB 权重的加载时间远超默认超时。4. HopperH200专属参数H200 需要不同的 MoE backend--no-enable-flashinfer-autotune\--moe-backend marlin\--disable-custom-all-reduceexportVLLM_ENABLE_K3_LATENT_MOE_TAIL_FUSION15. AMDMI355X / MI350X参数--load-format auto\--gpu-memory-utilization0.95\--mm-encoder-tp-mode data\--max-num-seqs128\--reasoning-parser kimi_k3\--max-num-batched-tokens4096exportVLLM_ROCM_USE_AITER1exportSAFETENSORS_FAST_GPU1exportAITER_SITUV2_A8W41# 0 a16w4 MoE 路径1 a8w4exportAITER_BF16_FP8_MOE_BOUND0exportVLLM_USE_BREAKABLE_CUDAGRAPH0# ROCm 上必须设为 0构建会自动置 1⚠️VLLM_USE_BREAKABLE_CUDAGRAPH0在 ROCm 上是强制要求——YAML 注释原文标注 “REQUIRED on ROCm: the build auto-enables 1”。6. 功能开关工具调用--enable-auto-tool-choice --tool-call-parser kimi_k3推理内容解析把思考与最终答案分开--reasoning-parser kimi_k3投机解码需额外显存故须限制并发--max-num-seqs32\--speculative-config{model:Inferact/Kimi-K3-DSpark,num_speculative_tokens:7,method:dspark,attention_backend:FLASHINFER_MLA,draft_sample_method:probabilistic,rejection_sample_method:block}纯文本模式跳过视觉编码器与 encoder_parallel 互斥--language-model-only7. 客户端调用官方示例importtimefromopenaiimportOpenAI clientOpenAI(api_keyEMPTY,base_urlhttp://localhost:8000/v1,timeout3600# 注意超时设为 3600 秒)messages[{role:user,content:[{type:image_url,image_url:{url:https://example.com/receipt.png}},{type:text,text:Read all the text in the image.}]}]starttime.time()responseclient.chat.completions.create(modelmoonshotai/Kimi-K3,messagesmessages,max_tokens2048)print(fResponse costs:{time.time()-start:.2f}s)print(fGenerated text:{response.choices[0].message.content})五、路线二PD 分离集群生产级配置Prefill / Decode 分离是官方给出的生产方案两侧用完全不同的并行策略。Prefill 侧TEPTP8--enforce-eager\--max-num-batched-tokens16384\--no-disable-hybrid-kv-cache-manager\--no-enable-flashinfer-autotuneDecode 侧DEPTP1--data-parallel-hybrid-lb\--moe-backend deep_gemm_mega_moe\--no-enable-prefix-caching\--max-num-seqs32\--max-num-batched-tokens32\--no-disable-hybrid-kv-cache-manager\--compilation-config{cudagraph_mode:FULL_DECODE_ONLY}\--all2all-backend flashinfer_nvlink_one_sided集群环境变量exportNCCL_CUMEM_ENABLE1exportNCCL_MNNVL_ENABLE1exportNCCL_NVLS_ENABLE0exportVLLM_SSM_CONV_STATE_LAYOUTDS# Blackwell 且启用 RDMA 时追加exportUCX_TLSrc,cuda_copyexportVLLM_ENABLE_K3_LATENT_MOE_TAIL_FUSION1通信后端选择据官方 Notes场景参数RDMA跨机--all2all-backend deepep_v2NVLink--all2all-backend flashinfer_nvlink_one_sidedDEP 环境MoE--moe-backend deep_gemm_mega_moeTP 1MoE--moe-backend flashinfer_trtllm⚠️RDMA 必须显式设置UCX_TLSrc,cuda_copy否则 KV Cache 传输可能不走 RDMA 通路。六、路线三SGLang 部署SGLang 支持的硬件列表更宽b300、gb300、b200、gb200、h200、h100、mi350x、mi355x。Docker 启动骨架dockerrun--gpusall --shm-size 32g--ipchost\lmsysorg/sglang:dev\sglang serve...并行参数别名--tp-size/--tp/--tensor-parallel-size、--ep-size/--ep、--dp、--enable-dp-attention、--attn-cp-size、--dcp-size、--pp-size。多机追加--nnodes、--node-rank、--dist-init-addr。PD 分离端口固定prefill 30000、decode 30100。SGLang 的五个已知限制官方 cookbookMTP 开启且未设--max-running-requests时SGLang 会强制重置为 48interleave 型 prefill-CP 与 DP-Attention 不能同时用——当前版本 assertdp_size 1冲突会在启动时直接失败prefill-CP 尺寸是推导值attn_cp_size TP / DP-AttentionDSPARK 与长上下文方案冲突——后者用流水并行而 DSPARK 要求pp_size 1DFLASH 已禁用——官方说明No K3 DFLASH draft checkpoint published yetPD 模式下客户端流量应打路由器而非直连角色服务器。七、路线四量化版本消费级硬件的唯一现实选项社区已产出多个量化版本这是没有 8 卡集群时的实际路径。据 Hugging Face 搜索结果当前可见的主要量化仓库仓库类型likesunsloth/Kimi-K3-GGUFGGUF44GrEarl/Kimi-K3-GGUFGGUF19GrEarl/Kimi-K3-GGUF-IQ1_SIQ1_S 极限量化7RedHatAI/Kimi-K3-FP8-BLOCKFP8 分块2pipenetwork/Kimi-K3-REAP80-MLX-mxfp4-q8MLXApple Silicon1Inferact/Kimi-K3-DSpark投机解码草稿模型15适用工具llama.cpp、Ollama、LM Studio、Jan。官方 Docker Model Runner 路径dockermodel run hf.co/moonshotai/Kimi-K3⚠️量化档位与质量的权衡必须清楚IQ1_S 这类 1bit 级量化能大幅降低显存但与官方评测成绩reasoning_effortmax下取得的差距会显著扩大。不要用量化版本的表现去评判 K3 的真实能力。八、部署路线决策表你的条件推荐路线说明8× GB300 / B300 及以上vLLMsingle_node_tp默认策略文档最全8× H200vLLM Hopper 覆写参数需--moe-backend marlin8× MI355X / MI350XvLLM ROCm 镜像注意VLLM_USE_BREAKABLE_CUDAGRAPH016 卡以上追求吞吐vLLMmulti_node_dep或 PD 分离DEP 最低 16 卡需要 H100SGLangSGLang 硬件列表含 h100vLLM 未标 verified单机多卡但不足 8 卡❌ 无可行方案走 API 或量化版本消费级硬件 / MacGGUF / MLX 量化版本接受明显的质量损失只想稳定用上 K3官方 APIplatform.kimi.ai选kimi-k3九、六个部署避坑要点1. 超时必须调大1560 GB 权重加载远超默认超时vLLM 需设VLLM_ENGINE_READY_TIMEOUT_S3600客户端 timeout 也建议 3600 秒。2. 用 fastsafetensors 加载官方base_args指定--load-format fastsafetensors注释明确说明much faster weight load。但AMD 路线覆写为--load-format auto不要照搬。3. 工具调用需要校验重试官方 Notes 原文“K3 occasionally emit a tool-call format its own parser doesn’t expect. Suggest to run do schema validation and retry.”必须做 schema 校验加重试不能假定输出格式稳定。4. 投机解码要限并发spec_decoding配置里 YAML 注释写明Speculative decoding needs additional VRAM, so cap concurrent sequences故须配--max-num-seqs 32。5. 分布式 KV 存储不可用Mooncake 的分布式与集中式 KV 存储在所有列出硬件上均为unsupported不要按这个方向设计架构。6. 这仍是预发布配方vLLM recipe 的description标注 “Pre-release”nightly_required: true。参数和行为可能变动生产前需自行验证。十、FAQQ我有 8×H100能跑 Kimi K3 吗AvLLM 官方 recipe 未把 h100 标为 verified仅 h200、b300、gb300、mi355x 为 verified但 SGLang 的supportedHardware列表包含 h100。8×80GB 640GB 显存远低于 1560GB 权重体积单机 8×H100 无法承载完整权重需多机或走量化版本。Q1560GB 和官方说的 1680GB 哪个准A1560.9 GB 是我从 HF API 统计 96 个分片得到的实际权重体积1680 GB 是 vLLM recipe 的vram_minimum_gb包含约 1.2 倍余量YAML 注释注明这是权重发布前的估算。规划显存按 1680 GB 起算更安全因为还需 KV Cache 和激活空间。Q为什么 MXFP4 量化后还有 1560GBA因为它不是全量 4bit。quantization_config的ignore列表把注意力层、共享专家、mlp 投影、lm_head、视觉塔全部排除在量化之外这些模块保持高精度。纯 4bit 理论值为 1400 GB实测高出 160 GB。QMac 能跑吗A有pipenetwork/Kimi-K3-REAP80-MLX-mxfp4-q8这类 MLX 版本但那是经过大幅裁剪和量化的版本。Apple Silicon 无法运行完整 2.8T 模型。QGGUF 的 IQ1_S 版本值得用吗AIQ1_S 是接近 1bit 的极限量化能让模型在小得多的显存里跑起来但质量损失显著。适合体验和实验不适合据此评估 K3 能力或用于生产。QPD 分离和普通 TP 该选哪个A单节点 8 卡且流量不大用single_node_tp官方默认。真实生产流量官方建议多机PD 分离能让 prefillTEPTP8和 decodeDEPTP1各自优化但复杂度和最低卡数要求显著更高。Q为什么 decode 侧的 max-num-batched-tokens 只有 32A这是 PD 分离架构的特性——decode 阶段每步只生成少量 token配合--compilation-config {cudagraph_mode:FULL_DECODE_ONLY}做全图捕获优化小 batch 反而延迟更低。十一、总结Kimi K3 本地部署的核心结论是一句话这不是个人或小团队能自建的模型。1560.9 GB 权重、1680 GB 最小显存、8× GB300 起步、DEP 需 16 卡——这些数字划定了明确的门槛。三条务实路径按成本递增官方 APIplatform.kimi.ai选kimi-k3门槛最低→社区量化版本GGUF / MLX接受质量损失→自建集群8 卡起步需 vLLM ≥ 0.27.0 nightly。若确定要自建六个技术要点务必记住VLLM_ENGINE_READY_TIMEOUT_S3600、--load-format fastsafetensorsAMD 例外、H200 需--moe-backend marlin、ROCm 需VLLM_USE_BREAKABLE_CUDAGRAPH0、工具调用需 schema 校验重试、分布式 KV 存储不可用。本文数据来自 2026 年 7 月 27 日的 Hugging Face 仓库实测统计、官方config.json、vLLM 官方 recipe YAML更新于 2026-07-25标注 Pre-release与 SGLang cookbook。该配方仍处预发布状态且要求 nightly 版本参数与行为可能随版本变动生产部署前请以官方最新文档验证。延伸资源Kimi K3 Hugging Face 仓库huggingface.co/moonshotai/Kimi-K3vLLM 官方部署配方recipes.vllm.ai/moonshotai/Kimi-K3Kimi K3 GitHub 仓库github.com/MoonshotAI/Kimi-K3Kimi K3 coding Planqiniu.com/ai/plan
Kimi K3 本地部署完全指南：1560GB 权重、8 卡起步与真实硬件门槛
发布日期2026-07 | 关键词Kimi K3 本地部署、vLLM、SGLang、MXFP4、多机部署数据来源Hugging Face 仓库实测数据、vLLM 官方 recipe YAML、SGLang cookbook、官方 config.jsonKimi K3 本地部署的第一个现实是权重体积Hugging Face 仓库的 96 个 safetensors 分片实测合计1,560,936,091,448 字节即约 1560.9 GB1453.7 GiBvLLM 官方 recipe 标注最小显存需求为1680 GB。这意味着单卡、单机 8×80GB 配置均无法承载完整权重——vLLM 官方前置条件明确写的是至少 8× GB300生产流量需多机。官方已验证的硬件为 H200、B300、GB300、MI355X 四种并行策略上 TP 与 TEP 最低 8 卡、DEP 最低 16 卡。技术上值得注意的是这个 MXFP4 检查点并非全量 4bitconfig.json 的 quantization_config 设有 ignore 列表注意力层、共享专家、mlp 投影、lm_head 与视觉塔均保持高精度group_size 为 32。对绝大多数团队而言务实路径是官方 API 或社区 GGUF 量化版本已有 unsloth、GrEarl 等多个版本含 IQ1_S 极限量化而非自建集群。本文给出四条部署路线的完整命令、参数与适用判断。一、先看清硬件门槛避免无效投入1. 权重体积的实测数据这是所有部署决策的起点。我直接从 Hugging Face API 统计了全部 safetensors 分片项目实测值safetensors 分片数96 个权重总体积1,560,936,091,448 字节换算约 1560.9 GB / 1453.7 GiBvLLM 官方标注最小显存1680 GB含 1.2 倍余量注意 1680 GB 这个数字的来源——vLLM recipe YAML 的注释写明这是预发布估算2.8T params × 0.5 byte/param × 1.2 headroom并注明权重发布后应替换为真实 safetensors 体积。实测 1560.9 GB 与该估算基本吻合。2. 官方验证过的硬件据 vLLM recipe YAML 的hardware字段已标记为verified的有四种硬件状态备注GB300verified官方前置条件推荐default_hardware为 b300B300verifiedBlackwell 架构有专属优化参数H200verifiedHopper 架构需特殊 MoE backendMI355XverifiedAMD ROCmCDNA4 gfx950官方前置条件原文“At least 8x GB300. Multi-node for real production traffic.”至少 8× GB300真实生产流量需多机ROCm 路线原文“Use vllm/vllm-openai_rocm:kimi-k3 docker and at least 8x MI355X/MI350X hardware.”3. 并行策略的最低卡数据 YAML 的strategy_min_gpus字段策略最低 GPU 数说明single_node_tp8默认策略multi_node_tp8跨机张量并行multi_node_tep8张量专家并行multi_node_dep16数据专家并行卡数要求翻倍KV Cache 分布式存储全部不支持——YAML 的kv_cache_strategy_hardware字段显示 Mooncake 的分布式与集中式方案在 H100、H200、B200、GB200、B300、GB300、MI300X、MI325X、MI355X 上均标记为unsupported。二、MXFP4 不是全量 4bit一个容易误判的细节很多人看到MXFP4 量化就按 0.5 byte/param 估算显存但实际检查点保留了大量高精度模块。据官方config.json的quantization_config{format:mxfp4-pack-quantized,quant_method:compressed-tensors,quantization_status:compressed,config_groups:{group_0:{targets:[Linear],weights:{num_bits:4,group_size:32,strategy:group,symmetric:true,type:float,observer:minmax}}},ignore:[re:.*self_attn.*,re:.*shared_experts.*,re:.*mlp\\.(gate|up|gate_up|down)_proj.*,re:.*lm_head.*,re:.*vision_tower.*,re:.*mm_projector.*]}保持高精度的模块不参与 4bit 量化self_attn— 全部注意力层shared_experts— 2 个共享专家mlp.gate/up/gate_up/down_proj— 稠密 MLP 投影lm_head— 输出头vision_tower/mm_projector— 视觉编码器与投影层这解释了为什么实测 1560.9 GB 高于纯 4bit 理论值2.8T × 0.5 byte 1400 GB。三、架构参数部署前需要知道的关键配置据官方config.json实测提取参数值num_hidden_layers93hidden_size7168intermediate_size33792moe_intermediate_size3072vocab_size163840max_position_embeddings1048576num_attention_heads96kv_lora_rank512q_lora_rank1536first_k_dense_replace1attn_res_block_size12hidden_actsituSiTU-GLUdtypebfloat16KDA 与全注意力层的精确分布config.json 的linear_attn_config给出了确切的层号分布这比69 KDA 24 Gated MLA的概括更有用full_attn_layers: [4, 8, 12, 16, 20, 24, 28, 32, 36, 40, 44, 48, 52, 56, 60, 64, 68, 72, 76, 80, 84, 88, 92, 93] kda_layers: [1,2,3, 5,6,7, 9,10,11, 13,14,15, ...] 共 69 层规律是每 4 层里有 3 层 KDA、1 层全注意力第 4、8、12… 为全注意力末尾第 92、93 层连续为全注意力。KDA 配置num_heads: 96、head_dim: 128、short_conv_kernel_size: 4、use_full_rank_gate: true、gate_lower_bound: -5.0。四、路线一vLLM 部署官方推荐文档最全1. 前置要求项目要求vLLM 版本≥ 0.27.0min_vllm_version镜像NVIDIAvllm/vllm-openai:kimi-k3镜像AMDvllm/vllm-openai-rocm:kimi-k3nightly必需nightly_required: true难度标注hard2. 基础参数所有硬件通用据 YAML 的base_args--trust-remote-code\--load-format fastsafetensors\--moe-backend auto\--gpu-memory-utilization0.95fastsafetensors是官方推荐的加载格式YAML 注释说明它能显著加快权重加载考虑到 1560 GB 的体积这个优化很关键。3. BlackwellB300 / GB300优化参数--max-model-len1000000\--kv-cache-dtype fp8\--attention-config{mla_prefill_backend:TRTLLM_RAGGED,use_prefill_query_quantization:true}\--max-num-batched-tokens32768\--enable-prefix-caching配套环境变量exportVLLM_ENABLE_K3_LATENT_MOE_TAIL_FUSION1exportVLLM_ALLREDUCE_USE_FLASHINFER1exportVLLM_ENGINE_READY_TIMEOUT_S3600exportVLLM_USE_V2_MODEL_RUNNER1exportVLLM_USE_RUST_FRONTEND1VLLM_ENGINE_READY_TIMEOUT_S3600不是可选项——1560 GB 权重的加载时间远超默认超时。4. HopperH200专属参数H200 需要不同的 MoE backend--no-enable-flashinfer-autotune\--moe-backend marlin\--disable-custom-all-reduceexportVLLM_ENABLE_K3_LATENT_MOE_TAIL_FUSION15. AMDMI355X / MI350X参数--load-format auto\--gpu-memory-utilization0.95\--mm-encoder-tp-mode data\--max-num-seqs128\--reasoning-parser kimi_k3\--max-num-batched-tokens4096exportVLLM_ROCM_USE_AITER1exportSAFETENSORS_FAST_GPU1exportAITER_SITUV2_A8W41# 0 a16w4 MoE 路径1 a8w4exportAITER_BF16_FP8_MOE_BOUND0exportVLLM_USE_BREAKABLE_CUDAGRAPH0# ROCm 上必须设为 0构建会自动置 1⚠️VLLM_USE_BREAKABLE_CUDAGRAPH0在 ROCm 上是强制要求——YAML 注释原文标注 “REQUIRED on ROCm: the build auto-enables 1”。6. 功能开关工具调用--enable-auto-tool-choice --tool-call-parser kimi_k3推理内容解析把思考与最终答案分开--reasoning-parser kimi_k3投机解码需额外显存故须限制并发--max-num-seqs32\--speculative-config{model:Inferact/Kimi-K3-DSpark,num_speculative_tokens:7,method:dspark,attention_backend:FLASHINFER_MLA,draft_sample_method:probabilistic,rejection_sample_method:block}纯文本模式跳过视觉编码器与 encoder_parallel 互斥--language-model-only7. 客户端调用官方示例importtimefromopenaiimportOpenAI clientOpenAI(api_keyEMPTY,base_urlhttp://localhost:8000/v1,timeout3600# 注意超时设为 3600 秒)messages[{role:user,content:[{type:image_url,image_url:{url:https://example.com/receipt.png}},{type:text,text:Read all the text in the image.}]}]starttime.time()responseclient.chat.completions.create(modelmoonshotai/Kimi-K3,messagesmessages,max_tokens2048)print(fResponse costs:{time.time()-start:.2f}s)print(fGenerated text:{response.choices[0].message.content})五、路线二PD 分离集群生产级配置Prefill / Decode 分离是官方给出的生产方案两侧用完全不同的并行策略。Prefill 侧TEPTP8--enforce-eager\--max-num-batched-tokens16384\--no-disable-hybrid-kv-cache-manager\--no-enable-flashinfer-autotuneDecode 侧DEPTP1--data-parallel-hybrid-lb\--moe-backend deep_gemm_mega_moe\--no-enable-prefix-caching\--max-num-seqs32\--max-num-batched-tokens32\--no-disable-hybrid-kv-cache-manager\--compilation-config{cudagraph_mode:FULL_DECODE_ONLY}\--all2all-backend flashinfer_nvlink_one_sided集群环境变量exportNCCL_CUMEM_ENABLE1exportNCCL_MNNVL_ENABLE1exportNCCL_NVLS_ENABLE0exportVLLM_SSM_CONV_STATE_LAYOUTDS# Blackwell 且启用 RDMA 时追加exportUCX_TLSrc,cuda_copyexportVLLM_ENABLE_K3_LATENT_MOE_TAIL_FUSION1通信后端选择据官方 Notes场景参数RDMA跨机--all2all-backend deepep_v2NVLink--all2all-backend flashinfer_nvlink_one_sidedDEP 环境MoE--moe-backend deep_gemm_mega_moeTP 1MoE--moe-backend flashinfer_trtllm⚠️RDMA 必须显式设置UCX_TLSrc,cuda_copy否则 KV Cache 传输可能不走 RDMA 通路。六、路线三SGLang 部署SGLang 支持的硬件列表更宽b300、gb300、b200、gb200、h200、h100、mi350x、mi355x。Docker 启动骨架dockerrun--gpusall --shm-size 32g--ipchost\lmsysorg/sglang:dev\sglang serve...并行参数别名--tp-size/--tp/--tensor-parallel-size、--ep-size/--ep、--dp、--enable-dp-attention、--attn-cp-size、--dcp-size、--pp-size。多机追加--nnodes、--node-rank、--dist-init-addr。PD 分离端口固定prefill 30000、decode 30100。SGLang 的五个已知限制官方 cookbookMTP 开启且未设--max-running-requests时SGLang 会强制重置为 48interleave 型 prefill-CP 与 DP-Attention 不能同时用——当前版本 assertdp_size 1冲突会在启动时直接失败prefill-CP 尺寸是推导值attn_cp_size TP / DP-AttentionDSPARK 与长上下文方案冲突——后者用流水并行而 DSPARK 要求pp_size 1DFLASH 已禁用——官方说明No K3 DFLASH draft checkpoint published yetPD 模式下客户端流量应打路由器而非直连角色服务器。七、路线四量化版本消费级硬件的唯一现实选项社区已产出多个量化版本这是没有 8 卡集群时的实际路径。据 Hugging Face 搜索结果当前可见的主要量化仓库仓库类型likesunsloth/Kimi-K3-GGUFGGUF44GrEarl/Kimi-K3-GGUFGGUF19GrEarl/Kimi-K3-GGUF-IQ1_SIQ1_S 极限量化7RedHatAI/Kimi-K3-FP8-BLOCKFP8 分块2pipenetwork/Kimi-K3-REAP80-MLX-mxfp4-q8MLXApple Silicon1Inferact/Kimi-K3-DSpark投机解码草稿模型15适用工具llama.cpp、Ollama、LM Studio、Jan。官方 Docker Model Runner 路径dockermodel run hf.co/moonshotai/Kimi-K3⚠️量化档位与质量的权衡必须清楚IQ1_S 这类 1bit 级量化能大幅降低显存但与官方评测成绩reasoning_effortmax下取得的差距会显著扩大。不要用量化版本的表现去评判 K3 的真实能力。八、部署路线决策表你的条件推荐路线说明8× GB300 / B300 及以上vLLMsingle_node_tp默认策略文档最全8× H200vLLM Hopper 覆写参数需--moe-backend marlin8× MI355X / MI350XvLLM ROCm 镜像注意VLLM_USE_BREAKABLE_CUDAGRAPH016 卡以上追求吞吐vLLMmulti_node_dep或 PD 分离DEP 最低 16 卡需要 H100SGLangSGLang 硬件列表含 h100vLLM 未标 verified单机多卡但不足 8 卡❌ 无可行方案走 API 或量化版本消费级硬件 / MacGGUF / MLX 量化版本接受明显的质量损失只想稳定用上 K3官方 APIplatform.kimi.ai选kimi-k3九、六个部署避坑要点1. 超时必须调大1560 GB 权重加载远超默认超时vLLM 需设VLLM_ENGINE_READY_TIMEOUT_S3600客户端 timeout 也建议 3600 秒。2. 用 fastsafetensors 加载官方base_args指定--load-format fastsafetensors注释明确说明much faster weight load。但AMD 路线覆写为--load-format auto不要照搬。3. 工具调用需要校验重试官方 Notes 原文“K3 occasionally emit a tool-call format its own parser doesn’t expect. Suggest to run do schema validation and retry.”必须做 schema 校验加重试不能假定输出格式稳定。4. 投机解码要限并发spec_decoding配置里 YAML 注释写明Speculative decoding needs additional VRAM, so cap concurrent sequences故须配--max-num-seqs 32。5. 分布式 KV 存储不可用Mooncake 的分布式与集中式 KV 存储在所有列出硬件上均为unsupported不要按这个方向设计架构。6. 这仍是预发布配方vLLM recipe 的description标注 “Pre-release”nightly_required: true。参数和行为可能变动生产前需自行验证。十、FAQQ我有 8×H100能跑 Kimi K3 吗AvLLM 官方 recipe 未把 h100 标为 verified仅 h200、b300、gb300、mi355x 为 verified但 SGLang 的supportedHardware列表包含 h100。8×80GB 640GB 显存远低于 1560GB 权重体积单机 8×H100 无法承载完整权重需多机或走量化版本。Q1560GB 和官方说的 1680GB 哪个准A1560.9 GB 是我从 HF API 统计 96 个分片得到的实际权重体积1680 GB 是 vLLM recipe 的vram_minimum_gb包含约 1.2 倍余量YAML 注释注明这是权重发布前的估算。规划显存按 1680 GB 起算更安全因为还需 KV Cache 和激活空间。Q为什么 MXFP4 量化后还有 1560GBA因为它不是全量 4bit。quantization_config的ignore列表把注意力层、共享专家、mlp 投影、lm_head、视觉塔全部排除在量化之外这些模块保持高精度。纯 4bit 理论值为 1400 GB实测高出 160 GB。QMac 能跑吗A有pipenetwork/Kimi-K3-REAP80-MLX-mxfp4-q8这类 MLX 版本但那是经过大幅裁剪和量化的版本。Apple Silicon 无法运行完整 2.8T 模型。QGGUF 的 IQ1_S 版本值得用吗AIQ1_S 是接近 1bit 的极限量化能让模型在小得多的显存里跑起来但质量损失显著。适合体验和实验不适合据此评估 K3 能力或用于生产。QPD 分离和普通 TP 该选哪个A单节点 8 卡且流量不大用single_node_tp官方默认。真实生产流量官方建议多机PD 分离能让 prefillTEPTP8和 decodeDEPTP1各自优化但复杂度和最低卡数要求显著更高。Q为什么 decode 侧的 max-num-batched-tokens 只有 32A这是 PD 分离架构的特性——decode 阶段每步只生成少量 token配合--compilation-config {cudagraph_mode:FULL_DECODE_ONLY}做全图捕获优化小 batch 反而延迟更低。十一、总结Kimi K3 本地部署的核心结论是一句话这不是个人或小团队能自建的模型。1560.9 GB 权重、1680 GB 最小显存、8× GB300 起步、DEP 需 16 卡——这些数字划定了明确的门槛。三条务实路径按成本递增官方 APIplatform.kimi.ai选kimi-k3门槛最低→社区量化版本GGUF / MLX接受质量损失→自建集群8 卡起步需 vLLM ≥ 0.27.0 nightly。若确定要自建六个技术要点务必记住VLLM_ENGINE_READY_TIMEOUT_S3600、--load-format fastsafetensorsAMD 例外、H200 需--moe-backend marlin、ROCm 需VLLM_USE_BREAKABLE_CUDAGRAPH0、工具调用需 schema 校验重试、分布式 KV 存储不可用。本文数据来自 2026 年 7 月 27 日的 Hugging Face 仓库实测统计、官方config.json、vLLM 官方 recipe YAML更新于 2026-07-25标注 Pre-release与 SGLang cookbook。该配方仍处预发布状态且要求 nightly 版本参数与行为可能随版本变动生产部署前请以官方最新文档验证。延伸资源Kimi K3 Hugging Face 仓库huggingface.co/moonshotai/Kimi-K3vLLM 官方部署配方recipes.vllm.ai/moonshotai/Kimi-K3Kimi K3 GitHub 仓库github.com/MoonshotAI/Kimi-K3Kimi K3 coding Planqiniu.com/ai/plan
