截至 2026年7月28日，Kimi-K3 的官方权重已经发布。它不是普通的百亿或千亿参数模型，而是一个：
- 总参数量：2.8万亿
- 每个 token 激活参数：约1040亿
- MoE专家数：896个，每个 token 选择16个
- 原生权重：MXFP4，激活值MXFP8
- 最长上下文：约100万 token
- Hugging Face 权重仓库大小约 1.56TB，共分成96个权重文件。
因此，它的“最低可运行配置”已经不是一台普通8卡H100服务器，而是总显存达到约2TB的数据中心级GPU服务器或GPU集群。
一、先给出配置结论
| 部署档位 | GPU配置 | 总显存 | 适用情况 |
|---|---|---|---|
| 最低且最推荐的单机配置 | 8×NVIDIA B300 288GB | 2.304TB | 单用户、研发、低到中等并发 |
| AMD单机方案 | 8×AMD MI355X 288GB | 2.304TB | 成本或供应链偏向AMD |
| B200方案 | 16×B200 180GB，2台8卡服务器 | 2.88TB | 较成熟的Blackwell集群 |
| H200方案 | 16×H200 141GB，2台8卡服务器 | 2.256TB | 已有H200集群时使用 |
| H100方案 | 32×H100 80GB，4台8卡服务器 | 2.56TB | 可以运行，但性价比较低 |
| 生产高并发方案 | 16～64×B300、GB300或B200 | 4.6TB以上 | 多用户、长上下文、智能体平台 |
vLLM官方明确表示，最容易运行Kimi-K3的配置是 8张B300或8张MI355X；SGLang官方还给出了16张B200、16张H200以及32张H100的部署拓扑。(vLLM)
二、为什么“只激活1040亿参数”，仍需要2TB显存
MoE模型容易产生一个误解：既然每个token只激活1040亿参数，是不是只需要装下一个104B模型？
不是。
Kimi-K3推理时虽然只调用896个专家中的16个，但路由器可能在不同token上选择不同专家，因此：
全部2.8万亿参数仍然必须常驻GPU显存。
MXFP4大体上相当于每个参数约占0.5字节：
再加上量化比例因子、未采用4bit的稠密层、视觉编码器、索引和对齐数据，最终Hugging Face仓库达到约 1.56TB。此外还必须预留：
- KDA状态缓存；
- MLA KV Cache；
- 中间激活；
- CUDA Graph；
- 通信缓冲区；
- 推理框架和视觉编码器内存。
因此，虽然1.56TB理论上能够存放权重，但真正运行通常要准备 2.2～2.9TB聚合显存，不能把显存全部塞满权重。Kimi-K3同时维护KDA循环状态池和MLA KV缓存池，前者还会直接限制并发请求数量。(SGLang Documentation)
三、最推荐的单机服务器配置
真正意义上可以称为“单台服务器顺畅运行”的方案，是一台 8卡B300或8卡MI355X服务器。
推荐方案A：8×NVIDIA B300
建议配置：
| 部件 | 推荐配置 |
|---|---|
| GPU | 8×NVIDIA B300 SXM，单卡288GB |
| 聚合显存 | 2.304TB HBM3e |
| GPU互连 | NVLink 5 + NVSwitch |
| CPU | 双路Intel Xeon 6或AMD EPYC，合计128～256核 |
| 系统内存 | 最低2TB，推荐4TB |
| 本地存储 | 最低4TB NVMe，推荐8～15TB企业级NVMe |
| 网络 | 单机可用200GbE；扩展集群建议400/800Gb InfiniBand或RoCE |
| 操作系统 | Ubuntu Server及厂商支持的CUDA环境 |
| 推理框架 | vLLM或SGLang官方Kimi-K3 Docker镜像 |
| 电源散热 | 数据中心机房供电，液冷或高规格风冷 |
NVIDIA DGX B300本身就是非常接近这一配置的参考系统：8张B300提供约2.3TB GPU显存，配备双路Xeon处理器和默认2TB、最高4TB系统内存，并提供800Gb/s级集群网络。(NVIDIA Docs)
这套配置的优势是：
- 一台机器即可装下整个模型；
- 不需要跨服务器传输专家数据；
- B300原生支持MXFP4；
- 低精度矩阵计算效率更高；
- GPU间通过NVSwitch通信，延迟显著低于普通PCIe或跨节点网络；
- 更容易配置张量并行TP8。
推荐方案B：8×AMD MI355X
MI355X同样具有单卡288GB HBM3e、8TB/s显存带宽和原生MXFP4支持。AMD官方已经验证Kimi-K3可以在一台8卡MI355X平台上以TP8方式部署，vLLM也将其列为最简部署方式之一。(AMD)
建议配套：
- 双路AMD EPYC，至少128核；
- 2TB以上内存；
- 8TB以上NVMe；
- ROCm官方支持版本；
- 8卡Infinity Fabric互连；
- 使用vLLM或SGLang专用ROCm镜像。
其硬件规格很强，但从当前软件成熟度看，NVIDIA B300的软件生态和Kimi-K3专用内核优化仍更加完整；AMD方案更适合已有ROCm技术能力的团队。
四、H200服务器怎样配置
H200单卡具有141GB HBM3e显存和4.8TB/s带宽。16张H200总显存约为2.256TB，能够容纳模型并留出一定推理缓存空间。(NVIDIA)
推荐拓扑：
节点1
- 8×H200 SXM 141GB；
- 1TB～2TB系统内存；
- 4～8TB企业级NVMe；
- 400Gb InfiniBand；
- NVSwitch。
节点2
配置相同。
集群互连
- 至少400Gb/s InfiniBand或RoCE；
- 必须支持RDMA；
- 两台服务器的NCCL和Gloo绑定同一高速网卡；
- 不建议仅用100GbE，更不能用普通万兆以太网。
SGLang官方给出的H200部署形态是 2台服务器、每台8张H200，TP16/EP16。由于H200不是Blackwell架构，官方路径使用Marlin W4A16，而不是Blackwell上的原生MXFP4计算路径，因此同样运行Kimi-K3时，H200通常需要更多GPU，效率也低于B300。(SGLang Documentation)
这套方案适合已经采购H200集群的企业，但新建系统时，通常不如8卡B300简洁。
五、B200服务器怎样配置
B200每卡有180GB HBM3e显存，16卡总显存为2.88TB。与H200相比，它的显存余量更大，并且属于Blackwell架构，支持FP4计算。(NVIDIA Docs)
推荐：
- 2台8×B200 HGX服务器；
- 每台1～2TB内存；
- 每台至少4TB NVMe；
- 400/800Gb InfiniBand或RoCE；
- TP16或TP8+PP2；
- 使用FP8 KV Cache；
- 开启prefix caching。
vLLM官方将 16×B200 列为Kimi-K3的正式支持配置；SGLang还给出了适合长上下文的TP8/PP2部署模式。(vLLM)
从显存容量看，16卡B200比16卡H200宽裕；缺点是需要两台服务器，而8卡B300可以把模型放在一个NVSwitch域内。
六、H100和A100是否能运行
32×H100：可以，但不推荐新建
SGLang给出的H100方案是：
- 4台服务器；
- 每台8张H100 80GB；
- 共32张GPU；
- TP32/EP32；
- 使用Marlin和FlashMLA；
- 通过高速RDMA网络跨节点通信。
H100每卡只有80GB，32卡总显存约2.56TB。虽然能够运行，但跨4个节点进行MoE专家通信，部署复杂度、功耗和网络成本都很高。SGLang还特别指出，H100方案的权重加载后显存余量最少。(SGLang Documentation)
A100：理论可行，实际不适合“顺畅运行”
1.56TB权重即使完全按80GB显存计算，也至少需要约20张A100；考虑缓存、激活和框架开销，实际很可能要24～32张甚至更多。
而且：
- A100没有原生MXFP4支持；
- 没有官方Kimi-K3生产部署配方；
- 跨节点专家通信成本很高；
- 很难发挥模型的低精度计算优势；
- 长上下文和并发能力会受到模型的低精度计算明显限制。
因此，A100集群更适合做技术验证，不适合新建Kimi-K3生产平台。消费级RTX显卡、L40S以及单机多张RTX PRO同样不属于现实可行的顺畅部署方案。
七、存储不能只准备2TB
虽然模型仓库约1.56TB，但服务器磁盘不应只配置2TB。
至少还需要保存：
- Hugging Face下载缓存；
- Docker镜像；
- 解压和转换过程中的临时文件；
- SGLang/vLLM编译缓存；
- CUDA内核缓存；
- 推理日志；
- DSpark草稿模型；
- 模型升级版本；
- 可能生成的其他量化版本。
因此建议：
- 最低：4TB NVMe
- 研发环境：8TB NVMe
- 生产环境：15TB以上NVMe或高速共享存储
如果采用多节点本地加载，每个节点都可以保存完整权重副本；如果使用共享存储，则应使用高吞吐并行文件系统或高速NVMe-oF。NVIDIA的生产配方既支持节点本地预置权重，也支持共享PVC模型缓存。
八、100万token上下文对配置的影响
Kimi-K3采用69层KDA和24层Gated MLA。KDA状态不会像传统注意力KV Cache那样随上下文长度线性膨胀，因此100万token上下文在技术上成为可能；但24层完整注意力仍需要保存KV缓存，此外每个并发请求还需要48view0
所以需要区分两种需求：
普通对话和智能体任务
建议限制在：
- 32K～64K上下文；
- 少量并发；
- 开启prefix caching；
- 使用FP8 KV Cache。
这种情况下，一台8×B300或8×MI355X比较合理。
真正使用100万token上下文
建议：
- 16张以上GB300、B300或B200；
- FP8 KV Cache；
- 分块预填充；
- Prefill/Decode分离；
- KV-aware routing；
- 高速NVLink或RDMA网络；
- 控制单副本并发量。
九、生产环境的推荐架构
企业内部部署可以采用以下结构：
十、最终建议
如果目标是企业研发、私有化试用和少量用户访问，我建议直接选择：
1台8×B300服务器，2～4TB内存，8～15TB NVMe，NVSwitch互连，配400/800Gb高速网卡，使用vLLM或SGLang官方Docker镜像。
这是当前最接近“单机、顺畅、部署复杂度可控”的方案。
如果已经拥有H200设备，则采用：
2台8×H200服务器，共16张H200，每台1TB以上内存和4TB以上NVMe，使用400Gb InfiniBand连接。
如果是面向几十到数百用户的正式服务，则应从：
16张B300/GB300起步；长上下文或较高并发采用24～32张GPU的Prefill/Decode分离架构。