从 Kimi K3 的 vLLM 配置说起——那些参数到底在控制什么

打开 Kimi K3 的 vLLM 部署页面，会看到 Hardware、MXFP4、TP、EP、KV Offload、P/D Disaggregation 等一排选项。只看名称，很难判断它们分别在控制什么。

这些参数不会改变 Kimi K3 本身的能力，但会影响到：模型能不能装进 GPU 集群、模型和请求如何分配到不同 GPU 与节点、部署最终更偏向低延迟，还是高并发吞吐。

Kimi K3 是一个 2.8T 参数的 MoE 模型。这样的规模会放大显存、通信和调度在配置上的影响。下面以官方 recipe 为主线，逐一解释这套 vLLM 配置参数。

模型的“体重”：为什么是 1680GB

Kimi K3 采用 MoE 架构，原生支持视觉和文本。模型共有 896 个路由专家（routed experts），每个 token 会激活其中 16 个，此外还有 shared expert。

“每个 token 只激活 16 个专家”很容易让人误以为模型所需的显存也会相应减少。实际上，推理时虽然每个 token 只调用 16 个专家，但部署时仍要把全部 896 个专家的权重加载到 GPU 集群中。稀疏激活降低的是计算量，不是显存需求，所以硬件门槛并不会因此降低。

K3 目前只有一个模型版本：MXFP4 权重、MXFP8 激活。这不是常见的部署时量化（PTQ），而是量化感知训练（QAT）直接产出的 4-bit checkpoint。

页面估算的权重占用为 1680GB：

2.8T × 0.5 byte/param × 1.2 headroom ≈ 1680GB

FP8 / MXFP8（1 byte）MXFP4（0.5 byte）— K3 默认2-bit（0.25 byte）

公式：
2.8T × 0.5 byte/param × 1.2 headroom

估算权重占用

≈ 1,680 GB

量化感知训练直接产出的 4-bit checkpoint，非部署时量化。

对比 1680GB 门槛

估算值1680 GB

1680GB 门槛1680 GB

1680GB 只是加载权重的最低门槛，实际运行还要为 KV Cache、通信 buffer 等预留空间。

1680GB 只是加载权重的最低门槛。模型实际运行时，还要为 KV Cache、通信 buffer、CUDA Graph、视觉 encoder，以及可能启用的 speculative draft model 预留空间。

Hardware：9 种选择，只有 3 种单节点够用

vLLM 页面提供了 9 种硬件选项。

NVIDIA：

AMD：

全部（9）Recipe 已验证单节点 ≥ 1680GB

GPU	配置	节点总显存	Recipe	单节点
H100nvidia	8×80G	640GB 1680GB	否	—
H200nvidia	8×141G	1128GB 1680GB	是	—
B200nvidia	8×180G	1440GB 1680GB	否	—
GB200 NVL4nvidia	4×192G	768GB 1680GB	否	—
B300nvidia	8×268G	2144GB 1680GB	是	✓
GB300 NVL4nvidia	4×288G	1152GB 1680GB	是	—
MI300Xamd	8×192G	1536GB 1680GB	否	—
MI325Xamd	8×256G	2048GB 1680GB	否	✓
MI355Xamd	8×288G	2304GB 1680GB	是	✓

提示：节点数会参与启动命令的生成，但前端并不会为所有多节点组合重新校验总显存。「Recipe 已验证」表示该配置经过 recipe 校验，不等同于前端默认选中。

页面中的大多数硬件按 8 卡节点配置，GB200 和 GB300 是例外。它们采用 4 卡 NVL4 单元，通过 NVLink 将 4 张 GPU 互联在一个模块内，因此“配置”一栏显示为 4×，而不是 8×。

按 1680GB 的权重体积粗略计算，单节点显存超过这一门槛的只有 B300、MI325X 和 MI355X。其他硬件需要使用多个节点或多个 NVL4 单元。

理解 Hardware 参数时，还要区分配置项表达的含义和页面实际做过的校验。

第一个细节是，节点数量会参与启动命令的生成，但前端不会为所有多节点组合重新校验总显存。例如，2×H100 的总显存为 1280GB，2×GB200 NVL4 为 1536GB，两种组合都装不下权重，但页面仍可能生成启动命令。因此，“Hardware × 节点数”表达的是集群组合，并不代表这个组合已经通过容量校验。

第二个细节是，页面默认值只代表前端的初始选择，不等同于 recipe 的推荐配置。recipe YAML 中写的是 default_hardware: b300，但前端代码并不读取这个字段。如果 URL 没有携带参数，浏览器也没有相关缓存，页面会默认选择 H200 × 2 和 Multi-Node TP。理解这些配置时，需要把“前端当前选中了什么”和“recipe 验证过什么”分开来看；verified 标记表示相应配置是否经过 recipe 验证。

Hardware 也不只是显存容量选项，它还会决定底层软件栈和执行路径。NVIDIA 使用 CUDA，AMD 使用 ROCm，对应的 Docker 镜像、推理 kernel 和 speculative decoding backend 都不同。例如，Hopper（H100/H200）强制使用 marlin MoE backend，Blackwell 强制使用 TRT-LLM Ragged MLA，AMD 则使用 AITER 路径。这些都是 recipe 的硬件 override，用户无法修改。也就是说，切换 Hardware 会连带改变底层 backend，而不只是换一组显存数字。

Strategy：模型和请求如何分到 GPU 上

Strategy 处理两个层面的问题：一是如何把单个大模型切分到多张 GPU 上，也就是模型并行；二是如何把多个请求分配到不同 GPU 上，也就是数据并行。

为了建立直觉，可以把 GPU 集群想成餐厅后厨：每个请求是一张订单，每张 GPU 是一名厨师或一个工位。模型并行是多名厨师协作完成同一张订单，数据并行则是多组厨师同时处理不同订单。

K3 recipe 底层支持 5 种策略，每种策略都对 GPU 数量设有最低要求（floor）。floor 可以理解为这种分工方式的最低开工人数：如果用户输入的 GPU 数量不够，生成器会自动将其提高到有效值。

TPTEPDEPP/D

后厨类比

一道菜始终由同一组厨师协作完成：每个工位只负责当前步骤的一部分，汇总后才能继续下一步。

最低 GPU

单节点起，可扩展到多节点

通信开销

每层都需要 all-reduce；单节点时全部走 NVLink。

适用场景

低延迟、拓扑简单

互联敏感度

低延迟偏向：低延迟高吞吐

TP（Tensor Parallel）：逐层切分模型

TP 会把模型的每一层切分到多个 GPU 上，同一批请求由整个 TP 组共同计算。放到后厨里看，它像一道菜始终由同一组厨师协作完成：每个工位只负责当前步骤的一部分，汇总之后才能继续下一步。

Single-node TP（同间后厨）Multi-node TP（跨后厨）⏸ 暂停

每层同步开销

低（NVLink）

TP 组规模

4

屏障数 / 前向

3

单节点：4 张 GPU 全在同一台机器内，层末 all-reduce 走 NVLink，延迟最低。

Single-node TP 的所有通信都在单台机器内完成，就像厨师都在同一间后厨，沟通路径最短。Multi-node TP 则让一个 TP 组跨越多台机器，相当于同一张订单要由分散在不同后厨的厨师共同完成。例如，两台 8 卡服务器对应 TP=16。其中 Head 节点负责提供 HTTP API，其他节点通过 --headless 方式只参与计算。

跨节点 TP 的每一层都需要同步，因此基本离不开 InfiniBand/RDMA 这类高速互联。普通以太网并非完全无法运行，但相当于每道工序都要经过一条较慢的传菜通道，延迟会不断累积，性能也会明显下降。

TEP（Tensor + Expert Parallel）：进一步切分 MoE 层

TEP 以 TP 为基础，在 MoE 层额外使用 EP，将专家分布到不同 rank。可以把 MoE 专家想成后厨里的不同档口，比如热菜、凉菜和甜点。Attention 等非专家部分继续采用 TP，专家权重和计算则通过 EP 并行。当 token 被路由到某个专家时，对应数据也要送到该专家所在的 GPU，就像一张订单会按菜品类型送到相应档口。

⏸ 暂停

TEP 同时包含 TP 同步（通用工位）和 MoE all-to-all（专家档口间），对互联带宽和负载均衡更敏感。

TEP 同时包含 TP 同步和 MoE all-to-all 通信，相当于通用工位和各个专业档口之间需要频繁传递订单与材料，因此对互联带宽和负载均衡更加敏感。

DEP（Data + Expert Parallel）：侧重高并发吞吐

在 K3 当前生成的 multi-node DEP 配置中，TP=1。每张 GPU 对应一个本地 DP rank，集群的总 GPU 数就是 DP size，同时通过 --enable-expert-parallel 将专家分布到不同 GPU。放到后厨里看，DEP 更像同时开出多条出餐线：不同 DP rank 分别处理不同订单，需要专家处理的部分再送到分布在各张 GPU 上的专业档口。

出餐线数（DP size）:248⏸ 暂停

每线 TP

1

并发订单

4

节点是否完整厨房

否

每条线只处理自己的订单，互不阻塞；但每个节点并非一间能独立完成所有工序的完整厨房——专家档口是跨 GPU 分布的。

例如，两台 8 卡节点会生成：

--data-parallel-size 16
--data-parallel-size-local 8
--data-parallel-hybrid-lb
--enable-expert-parallel

DEP 让不同 DP rank 可以同时处理不同请求，更适合高并发吞吐。需要注意的是，当前 recipe 并不是让每个节点先组成一套本地 TP+EP，也没有为 multi-node DEP 配置节点内 TP。换成后厨的说法，每个节点并不是一间能够独立完成所有工序的完整厨房。

此外，8 卡节点使用 DEP 时，floor 是 2 个节点，也就是至少需要 16 张 GPU；4 卡节点（GB200/GB300）则至少需要 4 个节点。硬件选型时，需要把这一约束纳入规划。

P/D 分离：把推理拆成两个阶段

Prefill/Decode Disaggregation 将一次推理拆分到两组 GPU 上执行。在后厨里，这相当于把备菜和出餐分给两组人：Prefill 组一次性读完整张订单，准备好后续需要的材料和记录；Decode 组接过这些准备结果，再持续生成内容。

一次请求

一张 GPU

KV交接中的 KV Cache

⏸ 暂停

① 备菜

一次性读完整段 Prompt，生成 KV Cache（影响 TTFT——等多久看到第一个 token）。

② 交接

把准备好的 KV Cache 通过专用通道交给出餐组——不搬模型权重。

③ 出餐

出餐组拿着 KV Cache 逐个生成 token（影响 ITL——后续 token 的速度）。

④ 独立扩容

两组资源独立扩容——长 Prompt 不会堵住正在出餐的 Decode 组。

关键点：中间流动的是 KV Cache（每次请求产生的临时记录），不是 2.8T 的模型权重——两组 GPU 仍然各自要装下完整权重。交接本身消耗时间与带宽，所以 P/D 提供的是资源隔离与独立扩容，并不保证所有负载下总吞吐都提升。

• Prefill：一次性读取完整 Prompt，处理上下文并生成 KV Cache。它主要影响 TTFT，也就是发出请求后，要等多久才能看到第一个 token。
• Decode：基于已有 KV Cache 逐 token 生成内容。这个阶段通常更依赖显存带宽，主要影响 ITL，也就是首个 token 出现后，后续 token 的生成速度。

请求链路大致如下：

请求 → Prefill pool 生成 KV Cache
     → 通过 NIXL side channel 传输 KV Cache
     → Decode pool 持续输出

NIXL side channel 传输的是请求对应的 KV Cache，不是模型权重。对应到后厨，它传递的是已经准备好的材料和订单记录，而不是把整套厨房设备搬过去。

Prefill 和 Decode 都可以独立选择 TP、TEP 或 DEP，并分别配置 1 到 16 个节点。K3 recipe 默认让 Prefill 使用 TEP、Decode 使用 DEP。两个角色分别使用各自的 HTTP port（默认 8001/8002）、NIXL side-channel port（5557/5558）和跨节点协调地址，再由 Router 将请求发送到相应 endpoint。这里的 Router 就像调度员，负责把订单依次送到备菜组和出餐组。

P/D 分离的主要价值，是让两类负载可以独立扩容。这样一来，需要处理长 Prompt 的复杂订单不容易堵住正在持续出餐的 Decode 组，也可以分别针对 TTFT 和 ITL 调整资源。相应的成本也很直接：需要额外的 GPU pool，并引入更复杂的 Router 和 KV 传输拓扑。

KV 交接本身还会消耗时间和网络带宽。因此，P/D 分离提供的是资源隔离和独立扩容能力，并不保证所有负载下的总吞吐都能提高。如果 KV Cache 传输本身成为瓶颈，吞吐反而可能下降。

KV Offload：搬走的是 KV Cache，不是模型权重

KV Offload 解决的是 KV Cache 的容量和复用问题，无法解决 2.8T 模型权重的容量问题。

模型权重在服务运行期间基本常驻 GPU 显存。沿用后厨的比喻，它相当于厨房必须备齐的整套设备和完整菜谱。KV Cache 则是处理每张订单时产生的备菜和临时记录：订单越复杂、同时处理的订单越多，需要占用的操作台和存储空间也就越大。

页面列出了四种选项：

• Off：KV Cache 保留在 GPU HBM 中，相当于把备菜都放在手边的操作台上，取用路径最短。
• Simple：将部分 KV Cache 放到本机 CPU 内存，相当于暂时移到后厨储物区，需要时再搬回操作台。
• Mooncake：使用外部 KV Cache 存储和传输基础设施，相当于接入后厨之外的仓储和配送系统。
• LMCache：通过独立缓存组件，在 CPU、磁盘或节点之间存取和复用 KV Cache，相当于用一套独立的库存系统管理和复用备菜。

OffSimpleLMCache

Off：全部 KV Cache 留在 GPU HBM——取用最快，但占用宝贵的 GPU 显存。

核心结论：无论选哪种 offload，2.8T 模型权重都常驻 GPU——offload 搬的是每张请求产生的 KV Cache（临时记录），不是模型本身。所以启用 KV Offload 仍然无法让单台 8×H100 装下 Kimi K3。

不同策略支持的 offload 方式并不相同。当前的实际可用矩阵如下：

策略	Off	Simple	Mooncake	LMCache
Single-node TP	✓	✓	✗	✓
Multi-node TP / TEP / DEP	✓	✓	✗	✗
P/D 分离	✓	✗	✗	✗

提示：启用 Simple 后，每个 rank 还会预留约 220 GiB 的 CPU 内存。Mooncake 在 K3 的全部 9 种硬件上都被标记为 unsupported。提示：启用 Simple 后，每个 rank 还会预留约 220 GiB 的 CPU 内存。Mooncake 在 K3 的全部 9 种硬件上都被标记为 unsupported。提示：启用 Simple 后，每个 rank 还会预留约 220 GiB 的 CPU 内存。Mooncake 在 K3 的全部 9 种硬件上都被标记为 unsupported。提示：启用 Simple 后，每个 rank 还会预留约 220 GiB 的 CPU 内存。Mooncake 在 K3 的全部 9 种硬件上都被标记为 unsupported。

Mooncake 在 K3 的全部 9 种硬件上都被标记为 unsupported。启用 Simple 后，每个 rank 还会预留约 220 GiB 的 CPU 内存，因此不能只考虑 GPU 侧的收益。

Offload 更适合两类场景：一是 KV Cache 容量不足，也就是操作台已经放不下更多备菜；二是大量请求会重复使用相同的系统提示、文档前缀或 Agent 上下文，像一批订单共享相同的基础备菜。但如果缓存命中率不高，KV Cache 又需要频繁经过 PCIe 或网络传输，就会变成材料在操作台和仓库之间反复搬运，延迟和运维成本都会上升。

最容易误解的一点是：启用 KV Offload，仍然无法让单台 8×H100 装下 Kimi K3。 Offload 搬走的是每张订单产生的备菜和临时记录，不是厨房必须常驻的设备与完整菜谱。对应到模型里，被搬走的是 KV Cache，不是 2.8T 参数权重；模型权重仍然要由 GPU 集群容纳。

Features 和 Advanced：容易忽略的覆盖顺序

页面还提供了 4 个 Feature 开关和几个 Advanced 调优项。这里最重要的是参数合成的覆盖顺序：

base → variant → strategy → hardware → Advanced → Features → KV Offload

base

→

variant

→

strategy

→

hardware

→

Advanced

→

Features

→

KV Offload

覆盖顺序意味着 UI 上的开关状态与最终命令之间，可能已经发生过多次参数替换。检查配置时，应以合成后的 argv 和环境变量为准。

可以把这条链想成一张不断追加备注的订单：越靠右的配置越晚写入。如果后面的备注修改了同一个要求，就以后写入的值为准。因此，Advanced 会覆盖 hardware 和 strategy 中的精调值，Features 又会继续覆盖 Advanced。

Features

• Tool Calling：让 API 接收 tools 参数，并使用 Kimi K3 parser 将输出解析为结构化 tool calls。K3 偶尔会输出 parser 无法正确处理的格式，因此生产环境需要增加 schema 校验和重试机制。
• Reasoning：使用 kimi_k3 reasoning parser，将推理内容与最终答案分开。它只改变输出结构，不会增强模型能力。
• Spec Decoding：额外加载 Inferact/Kimi-K3-DSpark 作为 draft model。每轮最多提出 7 个候选 token，再由 K3 批量验证。NVIDIA 使用 FLASHINFER_MLA backend，AMD 使用 TRITON_MLA。这一功能适合低延迟、小 batch 场景，但 draft model 会额外占用显存；在 NVIDIA 上，max-num-seqs 还会被限制为 32。高并发时，这一约束可能抵消加速收益。
• Text Only：添加 --language-model-only，跳过视觉 encoder。这样可以减少资源占用和启动负担，但服务之后将无法接收图片。

Tool Calling

让 API 接收 tools 参数，输出解析为结构化 tool calls。

Reasoning

把推理内容与最终答案分开。

Spec Decoding

draft model 提出候选 token，K3 批量验证。

Text Only

跳过视觉 encoder，减少资源占用，但无法接收图片。

注入到最终命令的内容已启用 0 / 4

（未启用任何 Feature）

点击上方开关启用 Feature，查看每个开关的真实代价与覆盖行为。

提示：Features 在覆盖链中位于 Advanced 之右（base → variant → strategy → hardware → Advanced → Features → KV Offload），因此它会覆盖 Advanced 的值。例如同时启用 Spec Decoding 和 Advanced 的 max-num-seqs=256 时，Feature 层会把它覆盖为 NVIDIA 32 / AMD 128。

Advanced 的覆盖陷阱

Advanced 提供了四个通用调优项。手动启用后，它们会覆盖前面各层的精调值：

• max-num-batched-tokens=8192：会覆盖 PD Prefill 的 16384、PD Decode 的 32，以及 Blackwell 的 32768，相当于用一个通用值替代三套针对不同场景调整过的值。
• max-num-seqs=256：会覆盖 AMD 默认的 128 和 PD Decode 的 32。但如果同时启用 Spec Decoding，Feature 层又会将其覆盖为 NVIDIA 32 或 AMD 128。此时覆盖链变成 Advanced → Features。
• gpu-memory-utilization=0.95：K3 base 本身就是 0.95，是否开启通常不会改变最终命令，但会产生不同的 UI 状态。
• max-model-len=auto：会覆盖 Blackwell 默认的 1M 上下文上限，改由 vLLM 根据可用 KV Cache 自动决定。

这套覆盖顺序意味着，UI 上显示的开关状态与最终命令之间，可能已经发生过多次参数替换。检查配置时，应以合成后的 argv 和环境变量为准，不能只看页面上高亮了哪些 pill。

生成命令后，还要确认两件事：是否同时出现含义相反的布尔 flag，例如 --enable-prefix-caching 和 --no-enable-prefix-caching；某个值是否被后续配置层悄悄覆盖。

最后

vLLM recipe 涵盖了硬件、并行策略、推理阶段拆分和缓存管理等主要配置，顺着这张配置页面学习，可以把模型装载、并行计算和推理调度中的几个核心概念串起来：

• Hardware 和精度格式决定模型权重如何存储并装入集群。MoE 的稀疏激活减少的是每个 token 的计算量，不是需要加载的权重总量；
• TP、TEP 和 DEP展示了模型计算、专家和请求如何分布到不同 GPU，也带出了通信开销与负载均衡问题；
• P/D 分离将推理拆成 Prefill 和 Decode 两个阶段，帮助我们区分 TTFT 与 ITL，并理解 KV Cache 为什么需要在两组资源之间传输；
• KV Offload划清了常驻模型权重与请求中间状态的边界，也说明了 GPU HBM、CPU 内存和外部缓存各自承担的角色；
• Features 和 Advanced展示了最终命令如何由多层配置合成。页面上的开关只是输入，实际生效的是最终生成的 argv 和环境变量。

K3 的 checkpoint、Docker 镜像和具体命令还会继续变化，但参数背后的几个问题相对稳定：权重如何装载，计算和请求如何分配，推理状态如何流动，最终配置如何生成。理解这些关系和概念之后，可以更好地理解模型的部署和推理过程。