2.8T也就是2.8万亿参数32张H20单卡96GB显存总算下来3TB出头。第一次看到这个需求任何搞过推理部署的人都会觉得是在开玩笑光FP16权重就要5.6TB这怎么塞但如果你真的了解Kimi K3这类超大MoE模型又用过H20这种“显存大、算力抠”的特型卡就会明白这其实不是一个能不能的问题而是一个用多少层量化、怎么切并行、以及愿意牺牲多少上下文长度的问题。这篇文章我想把这件事彻底拆开从显存账、硬件账、并行策略到最终启动命令一步步讲清楚。目标读者不只是算法工程师也包括正准备给公司采购8卡H20、又纠结“K3开源下载之后到底跑不跑得动”的技术负责人。1. 先算账2.8T参数的显存压力到底有多大1.1 一张H20的“家底”96GB不是你想的那样先说硬件。H20在坊间有个外号叫“大显存小算力”这印象不算全对但用在推理场景下确实点到了要害。它单卡HBM3显存96GB显存带宽4.0TB/sFP16/BF16稠密算力大约148 TFLOPSFP8约296 TFLOPS。跟H100比算力差了一大截但显存容量反而更大了这就是它被很多私有化项目盯上的原因——跑大模型推理显存容量和带宽往往比峰值算力更值钱。32张H20合计显存是32×96GB也就是3072GB约等于3TB。这个数字你要先刻在脑子里。2.8T参数的模型如果把所有权重都加载进显存FP16/BF162.8T × 2Byte 5.6TB远超3TB直接没戏。FP8/INT82.8T × 1Byte 2.8TB勉强塞得进但只剩约272GB余量。INT42.8T × 0.5Byte 1.4TB剩余约1.67TB看起来宽裕很多。所以第一个结论很残酷想让Kimi K3在这32张卡上跑起来FP16是不用想的FP8是“贴着天花板飞”INT4才是真正能留出余地的选项。很多人一听说量化就皱眉觉得效果肯定拉胯但注意MoE模型本身就是“参数多、激活少”对量化误差的容忍度比稠密模型要高不少后面我会专门说这个。1.2 模型侧的三张减负牌MoE、量化、Offload既然显存总容量摆在那减负就得从模型侧想办法。我对Kimi K3的具体结构没有官方数据但按目前社区信息和Kimi K2的路线来看K3延续超大规模MoE架构几乎是板上钉钉的事。MoE意味着“总参数2.8T”和“单次推理激活参数”是两个完全不同的数字。假如激活参数只有总参数的几十分之一那计算压力远没有2.8T稠密模型那么恐怖真正卡住你的只是显存里放不放得下全部专家权重。这三张减负牌我们要一张张打第一张牌是量化。FP8是基本盘INT4是真正的杀手锏。权重从FP16压到FP8显存直接减半从FP8再压到INT4又减一半。以2.8T参数计算每走一步就少1.4TB显存占用这对32卡H20来说是天壤之别。第二张牌是MoE专家调度。K3如果带了上百个专家推理时每层只激活Top-K个专家那么计算量可控。但注意绝大多数推理框架为了保证路由不卡顿还得把全部专家权重加载到显存里而不是只加载活跃专家。所以MoE只解决“算不动”不解决“存不下”。第三张牌是Offload也就是把冷门专家或部分层挪到CPU内存。32张H20附近的主机如果每节点配512GB或1TB内存4节点就有2TB到4TB的CPU内存可用。把一部分专家权重放内存用到时再搬到显存这在离线批量推理场景完全可行。代价是延迟变高所以在线服务一般不这么干。这里说句实在话如果K3的开源权重出来你发现原始FP16版本体积超过5TB别惊讶这是正常的。下载之前就要规划好磁盘和内存别到时候权重下了没地方放。2. 硬件底牌32张H20的组网与互联真相2.1 为什么是H20而不是L20显存带宽才是生命线最近总有人拿H20和L20放在一起比。L20只有48GB显存带宽864GB/s算力更弱价格便宜不少。坦率讲L20跑7B、14B这种中小模型性价比不错但想用来扛K3这种2.8T量级的东西差的不是一星半点。H20单卡96GB带宽4.0TB/sL20要四张加在一起才有接近的带宽和显存但这时候多卡通信的损耗又来了。所以你要是真准备为K3搭建一套私有化环境H20是比L20理性得多的选择。当然HPU、MI系列这些不在今天的讨论范围。单说H20它的NVLink带宽是900GB/s单机8卡可以通过NVLink全互联。这套拓扑对TP张量并行特别友好。跨节点就得靠IB或者RoCE网络了这个信息极其关键因为后续的并行策略设计完全取决于“机内带宽大、机间带宽小”这个前提。2.2 单机8卡和四机32卡预算与拓扑要一起看32张H20最自然的组法就是4台8卡整机。一台8卡H20的预算目前市场上没有固定报价受供货周期影响很大。我给个参考区间单卡价格在二十多万到三十万级别整机算上CPU、内存、系统盘、NVLink模组、电源和机箱单台两百万到三百五十万都算正常范围内。四台下来就是大几百万甚至上千万的项目这还没算IB交换机、存储阵列和机房改造。所以“一台8卡H20预算”这个问题本质上是问你要不要为了K3上四台答案取决于你的业务场景是超长离线任务还是高并发在线服务。组网拓扑建议每机8卡用NVLink组成一个超大带宽域机间用400G IB有条件上800G互联。千万别用普通万兆网跑这种规模的模型多卡通信会直接卡死。实际上跨节点用PP流水线并行、节点内用TP是最能发挥这种拓扑优势的方案下面详细讲。3. 并行策略怎么把权重和KV Cache分配到32张卡上3.1 张量并行、流水线并行、专家并行到底怎么配合大模型分布式部署绕不开TP、PP、EP这三个词。对K3这种2.8T参数的MoE设计并行方案必须把显存和通信带宽放一起考虑。TP张量并行把每个权重矩阵切成多块多卡一起算。H20机内NVLink带宽高TP适合放在单机8卡内部。但TP对通信极其敏感跨机做TP速度会被IB带宽拖垮不建议。PP流水线并行把模型按层切成多段每张卡只负责其中若干层。跨节点PP很自然节点间只需要传输激活和梯度通信量比TP小。缺点是流水线有气泡会有空闲等待。EP专家并行把MoE的专家分散到不同卡每张卡只存一部分专家。MoE路由时通过All-to-All通信把token发给对应专家所在的卡。EP和MoE是天生一对但它也要求卡间通信足够快最好和TP混在同一节点内。推荐组合很清晰PP4TP8EP8。4个PP stage对应4台机器每个PP stage内部8张卡构成一个节点节点内再同时跑TP8和EP8。这样一来32张卡相当于把模型权重切成32份每张卡大约负责2.8T/3287.5B参数。如果FP8权重每卡约87.5GB再叠加KV Cache和激活H20的96GB就比较紧了如果用INT4每卡约43.75GB剩下的空间就充裕得多。3.2 一个可行的4机32卡显存划分方案光说理论不够我给你一个可以照抄的显存划分示例假设整模型用INT4权重权重显存2.8T × 0.5Byte 1.4TB平摊到32卡每卡43.75GB。KV Cache假设单卡预留给KV Cache 20GB32卡总共640GB。这个体量能支撑多少并发和上下文取决于K3的层数、注意力头数和序列长度。粗略估计几十万token的并发会话没问题但想跑百万token级别上下文还是紧。激活和通信缓冲每卡留8GB到12GB比较保险。余量兜底每卡至少留5GB防OOM。这么算下来每卡显存使用量约75GB到80GB还有15到20GB的余量整体是健康的。如果你强行上FP8权重每卡权重就变成87.5GB基本没有空间给KV Cache和激活那个方案属于“能加载但跑不动”。所以我的建议是首版直接用INT4做不要贪FP8先把业务跑通再说。3.3 不要忽略KV Cache这个隐形成本很多人算显存只算权重忽略KV Cache这是实战里最容易翻车的地方。KV Cache和模型参数是两码事它和序列长度、并发数成正比。每多一个并发请求每多一个token都要在显存里多占一块地方。像K3这种超大模型即使总量2.8TKV Cache也不能简单从总参数推它只和Transformer层数、注意力头数、维度有关但绝对数值依然可观。部署之前一定估算好“输入长度×并发数×每token KV大小”的乘积不要一上来就设32K上下文很多显存就是这么爆的。4. 部署实操一次可落地的Kimi K3推理方案4.1 推理框架与权重格式选择K3如果开源大概率会同时放原始权重和量化权重。为了在H20上跑得舒服我建议优先考虑以下几个框架vLLM、SGLang、TensorRT-LLM这几个对MoE、TP/EP/PP、量化支持都比较成熟。SGLang的RadixAttention对高并发和前缀复用特别友好很适合K3这种大模型的在线服务TensorRT-LLM则适合把模型编译成TensorRT引擎压榨硬件性能但调试成本高。vLLM最通用社区活跃上手快我下面的例子先用它。权重格式上如果你拿到的是BF16/FP16的safetensors第一步要做的不是直接部署而是转成INT4量化格式比如GPTQ或AWQ或者专门适配MoE的FP8/INT4混合格式。转量化需要几块高显存GPU最好在8卡H20节点上做校准精度和稳定性都更可控。要注意量化文件本身也占磁盘空间1.4TB的INT4权重建议用多块NVMe SSD做存储阵列模型加载时能明显提速。4.2 关键的启动参数与配置示例假设你已经把权重转好放在/data/Kimi-K3-INT4路径下下面是一份可参考的vLLM启动命令python -m vllm.entrypoints.openai.api_server \ --model /data/Kimi-K3-INT4 \ --tensor-parallel-size 8 \ --pipeline-parallel-size 4 \ --trust-remote-code \ --gpu-memory-utilization 0.92 \ --max-model-len 32768 \ --quantization awq \ --enforce-eager \ --enable-prefix-caching \ --swap-space 4这里几个参数分别说明一下tensor-parallel-size 8和pipeline-parallel-size 4对应前面说的4机8卡拓扑。vLLM的PP支持是后来加的老版本可能不认先确认你安装的是最新稳定版。gpu-memory-utilization 0.92告诉框架最多占用92%显存留8%给CUDA上下文和临时缓冲。INT4权重下这个值很稳如果换FP8建议降到0.85以下。max-model-len 32768最大上下文长度。不要一上来就设128KK3这种体量长上下文会迅速吞掉KV Cache建议先32K验证流程。quantization awq对应你的AWQ量化格式。如果框架支持FP8也可以换成fp8。enforce-eager禁用CUDA Graph减少显存占用换取首次推理速度略慢。如果显存不紧张可以去掉这个参数换性能。enable-prefix-caching开启前缀缓存多用户共享系统提示词时能省大量重复计算。swap-space 4设置一定比例的CPU内存作为Offload兜底防止突发OOM。启动后先不要压测用一条最简单的请求验证curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: /data/Kimi-K3-INT4, messages: [{role: user, content: 你好}], max_tokens: 64 }能正常返回再逐步增加并发和上下文长度。4.3 不同业务场景下的吞吐与延迟调优先跑通再调优这个顺序不能乱。如果你用来做离线批量数据分析优先追求吞吐可以把请求并发拉高比如同时发32到64个请求让GPU一直处于满负荷状态。如果用来做在线对话服务那更关注首token延迟建议缩短max-model-len减少prefix cache之外的部分计算还可以打开vLLM的--enable-chunked-prefill把长请求切块避免它阻塞后面的短请求。H20算力不高但显存带宽很强这意味着它特别适合“高并发、长上下文、稀疏激活”这类负载。K3是MoE每次只激活少量专家H20的算力短板反而不那么致命。真正要盯的是通信EP的All-to-All如果走跨节点IB延迟会明显升高所以前面才强调TP和EP都要限制在单机8卡内部节点间只走PP。5. 问题排查与避坑实录5.1 显存OOM的三板斧部署期间最常见的错误就是CUDA OOM。遇到这个按顺序检查三件事第一步砍max-model-len。把32768改成8192立刻能释放大量KV Cache显存。如果业务允许这是最省事的办法。第二步降gpu-memory-utilization或者打开swap-space。有时候不是显存真的不够而是框架预分配策略太激进留了太大冗余。第三步检查是否启用了CUDA Graph也就是去掉--enforce-eager。CUDA Graph会额外吃不少显存对于32卡这种大规模部署先关掉更稳妥。如果三步都做完还是OOM那就说明当前量化精度和并行配置不匹配要么从INT4降到更激进的量化要么就得把权重Offload一部分到CPU内存接受更高延迟。5.2 通信瓶颈怎么定位另一个高频问题不是OOM而是显存明明够但速度上不去。症状是吞吐很低GPU利用率却不高。这种情况八成是卡在跨节点通信上。我最常用的排查手段是跑NCCL带宽测试看机内和机间的实际带宽对不对。H20机内NVLink理论900GB/s实测可能到700GB/s以上算正常机间IB如果有400G实际带宽单向大概在45GB/s到50GB/s左右。如果你发现机间带宽远低于这个值先查网卡协商速率、交换机和NCCL环境变量比如NCCL_IB_DISABLE、NCCL_P2P_LEVEL这些设置是否正确。5.3 关于官网会员与本地部署的几个常见误解最近总有朋友问“Kimi哪个会员能用K3”。这里要说清楚官网会员对应的是官方云端API背后跑在人家自己的大规模集群上跟你在本地用32张H20私有化部署是两条线。会员能不能用K3取决于官方产品策略和咱们今天聊的这套方案没有直接关系。本地部署解决的是数据不出域、私有化定制、批量离线推理这类需求。你买了会员不代表你可以把K3权重拉下来自己跑同样你在本地跑通K3也不影响官网会员的订阅选择。两者别混为一谈。还有一个误解是“开源下载免费无限用”。K3如果开源权重确实能下载但你要有足够大的磁盘、足够多的GPU和配套的组网才能跑起来。光下载不做量化、不做并行规划基本跑不动。这也是为什么我反复强调先做预算和显存规划再动手。5.4 量化精度损失的补救办法如果INT4部署后效果明显变差可以先试FP8。FP8权重2.8TB32卡H20能装下但很紧建议把max-model-len调小、把KV Cache预算压低给权重腾位置。很多MoE模型在INT4下精度损失可控但个别对数学推理或代码生成要求很高的场景建议先用FP8做A/B测试实在不行再切INT4。另外量化校准数据要选和实际业务接近的语料别随便用通用文本否则对边缘case影响很大。6. 最后说几句实在话我做推理部署这些年最深的体会是大模型能跑起来不是终点跑得稳、跑得快、能维护才是真本事。K3这种2.8T级别的模型放在32张H20上属于“极限求生”每一步都得精打细算。先量化再并行最后调KV Cache这个顺序千万别反。如果你也是第一次尝试建议先用一台8卡H20跑一个K3的降级版本比如先加载部分层或部分专家把组网和框架的坑都踩一遍再上完整32卡方案成功率会高很多。后续如果官方放出K3的详细架构和推荐部署配置记得以官方为准但显存这笔账无论谁来了都得这么算。