2026 年 7 月 27 日，Kimi K3 正式开放完整模型权重。

这是近期大模型领域最值得关注的事件之一。

K3 拥有 2.8T 总参数、约 104B 激活参数、896 个路由专家，每个 Token 选择其中 16 个专家，同时支持最高 100 万 Token 上下文。按照官方公布的评测结果，它已经进入全球最强模型的第一梯队，也因此被很多人直接称为“世界第三的大模型”。

但比“世界第三”更有冲击力的，是另一件事：

这样一个第一梯队模型的完整权重，真的被放出来了。

很多开发者看到这里，第一反应是：

权重开放
=
可以下载
=
可以私有部署
=
终于不用调用闭源 API

然而，AMD 随后公布的 Day-0 部署方案，却给这种兴奋泼了一盆冷水。

K3 当前公开验证过的最低整机配置之一，是：

8 张 AMD Instinct MI355X
每张 288GiB HBM3E
总 HBM 超过 2TB
TP8 张量并行

即便如此，AMD 也明确说明：

这次验证的目标不是追求峰值性能，而是确认模型权重为什么能装进去、如何在 8 张 GPU 之间分配，以及能否完成最小正确性测试。

换句话说，这套配置证明的是：

K3 能加载
K3 能生成
K3 能完成正确性验证

但它没有证明：

K3 的首字延迟是多少
每秒能够生成多少 Token
可以支持多少并发用户
长上下文性能如何
单位 Token 成本是多少
是否适合长期生产运行

AMD 没有在这次验证中公布这些生产指标。

这就产生了一个非常有意思的矛盾：

一个被认为进入世界前三、已经开放完整权重的模型，为什么绝大多数企业还是部署不了？

答案并不只是显卡太贵。

真正的问题是：

当模型大到必须跨越多张 GPU 时，部署就不再是一道显存加法题，而变成了一道分布式系统题。

---

一、K3 开放的是模型权重，不是一条廉价部署捷径

过去部署 7B、14B、32B 模型时，我们通常只需要回答一个问题：

模型需要多少显存？

如果模型能装进显存，推理框架又支持相应架构，那么部署大概率就能继续进行。

但 K3 已经完全不是这个尺度。

它的模型 Checkpoint 大约为 1.56TB。

即使使用 8 张每张拥有 288GiB HBM 的 MI355X，也需要通过 TP8，把模型权重分散到所有 GPU 上。

这意味着一个请求不再由一张 GPU 独立完成。

而是可能变成：

GPU 0 计算一部分
GPU 1 计算一部分
GPU 2 计算一部分
……
GPU 7 计算一部分
        ↓
所有 GPU 交换结果
        ↓
完成同步
        ↓
继续计算下一层

从这一刻开始，决定系统性能的就不只是 GPU 算力。

而是：

GPU 计算能力
× 并行策略
× GPU 通信带宽
× PCIe / 高速互联拓扑
× P2P 能力
× 请求调度
× 推理引擎优化

任何一项严重退化，整套系统都会被拖慢。

所以，K3 真正值得研究的地方，不只是它拥有 2.8T 参数。

而是它把一个事实暴露得非常彻底：

前沿大模型已经不再只是一份神经网络权重，而是一台由模型、GPU、互联、通信库和调度系统共同组成的分布式计算机器。

---

二、为什么会出现“GPU 没跑满”？

这是很多多卡用户最困惑的问题。

明明服务器里安装了四张 GPU：

• 四张卡都被正确识别；
• 显存也全部占用了；
• 模型成功启动；
• 没有出现 OOM。

但运行模型时，却发现：

GPU 利用率忽高忽低
有的 GPU 长期等待
Token 生成速度没有明显提升
从两张卡增加到四张卡，延迟反而升高

很多人会认为：

是不是显卡算力不够？
是不是 CUDA 没安装好？
是不是量化模型有问题？

但真实原因可能恰恰相反：

GPU 计算得太快，剩下的大量时间都暴露成了通信和等待。

假设一个 Transformer 层被切分到四张 GPU：

GPU 0：计算矩阵的一部分
GPU 1：计算矩阵的一部分
GPU 2：计算矩阵的一部分
GPU 3：计算矩阵的一部分
        ↓
等待所有 GPU 完成局部计算
        ↓
All-Reduce / All-Gather
        ↓
合并计算结果
        ↓
进入下一层

一张 GPU 即使已经完成自己的部分，也不能直接进入下一层。

因为下一层需要的是完整结果。

它必须等待其他 GPU 完成，并等待集合通信结束。

NCCL 的集合通信要求参与操作的各个 Rank 共同完成相应操作。All-Reduce 会聚合所有 Rank 的结果，并将结果返回给各个 Rank；All-Gather 则会收集各 Rank 的数据，并将完整结果分发给所有参与者。

假设某一次执行周期是：

有效计算：10ms
跨卡通信：15ms
同步等待：5ms

那么总时间为：

10 + 15 + 5 = 30ms

真正用于 GPU 有效计算的时间占比是：

有效计算利用率
=
10 ÷（10 + 15 + 5）
=
33.3%

也就是说，剩下约三分之二的时间，GPU 并不是没有任务。

它是在等待。

整个执行过程可能不断重复：

计算 10ms
通信 15ms
等待 5ms

计算 10ms
通信 15ms
等待 5ms

计算 10ms
通信 15ms
等待 5ms

于是，你在 nvidia-smi 中看到的 GPU 利用率可能是：

100% → 20% → 0% → 100% → 15% → 0%

GPU 可能在等待：

• 其他 GPU 完成局部计算；
• NCCL 集合通信；
• PCIe 数据传输；
• CPU 内存中转；
• 跨 NUMA 节点传输；
• 上一个 Pipeline Stage；
• 最繁忙的 MoE 专家；
• 推理框架完成调度。

因此，GPU 利用率出现波动，不一定说明 GPU 算力不足。

更准确的判断是：

GPU 的计算阶段很短，通信和同步阶段太长。

多卡执行时间可以粗略理解为：

总执行时间
=
有效计算时间
+ 数据传输时间
+ 集合通信时间
+ 同步等待时间
+ 调度开销

当通信和等待时间超过计算时间时，继续增加 GPU 数量并不会自动提升速度。

因为 GPU 越多：

• 通信参与者越多；
• 同步点越多；
• 通信路径越复杂；
• 最慢 GPU 拖累全局的概率越高。

这就是多卡系统最反直觉的现象：

显卡越快，通信瓶颈反而可能越明显。

---

三、8 张 GPU 能运行，为什么不能证明 K3 能服务？

评价一次大模型部署，至少应该分成三个层次。

第一层：能加载

模型权重能够进入显存
不会发生 OOM

第二层：能生成

模型可以完成前向传播
能够正确输出 Token

第三层：能服务

TTFT 达标
TPOT 达标
吞吐量达标
并发能力达标
稳定性达标
单位成本达标

其中：

• TTFT 是从请求发出到第一个 Token 出现的时间；
• TPOT 是开始生成后，每个新 Token 所需的时间；
• Throughput 是整个系统每秒能够为所有用户生成多少 Token；
• Concurrency 是系统在延迟不失控的前提下，可以同时服务多少请求。

很多所谓的“最低配置”，只能证明前两层。

它证明模型能装进去，也能输出答案。

但如果没有公布：

TTFT
TPOT
单请求 Tokens/s
总吞吐量
并发用户数
P95 / P99 延迟
长时间运行稳定性
单位百万 Token 成本

就不能直接得出“适合生产部署”的结论。

AMD 的 8 张 MI355X 方案，本质上是一次 Day-0 容量与正确性验证，而不是完整的生产性能报告。AMD 还特别说明，模型在 TP8 下每张 GPU 约占用 190.974GiB 权重；一条百万 Token 序列的已知额外运行状态，估算还会占用每张 GPU 约 14.427GiB，但这尚未包括通信缓冲区、Kernel Workspace、CUDA Graph、内存碎片和框架运行时开销。

所以，“8 卡能跑”的准确含义是：

8 张 MI355X 能够容纳 K3
并完成最小功能验证

它不等于：

8 张 MI355X 已经能以合理成本
高并发、低延迟地服务 K3

“能运行”和“能服务”之间，隔着一整套推理系统工程。

---

四、多卡性能不能只看显卡，还要看整台机器的拓扑

很多人购买 GPU 服务器时，只看四件事：

有几个 PCIe 插槽
可以安装几张显卡
总显存有多少
电源功率够不够

但这些信息只能说明：

显卡能不能物理安装进去。

它不能说明：

这些显卡能不能高效协同。

真正决定多卡训练和推理性能的，是：

GPU 型号
+
PCIe 代际
+
每张 GPU 的实际通道数
+
PCIe 交换芯片
+
CPU 数量
+
NUMA 结构
+
GPU P2P 能力
+
NCCL 实际通信路径

例如，主板上虽然有四个物理 x16 插槽，但实际运行状态可能是：

GPU 0：PCIe 4.0 x16
GPU 1：PCIe 4.0 x16
GPU 2：PCIe 4.0 x8
GPU 3：PCIe 4.0 x8

物理上是 x16 长度的插槽，不代表它真的获得了 16 条 PCIe Lane。

有些主板会因为 CPU 可用 PCIe Lane 数量有限，在安装多张 GPU 后自动降速。

所以，看到“4 个 PCIe x16 插槽”时，还要继续问：

四张卡同时安装后
每张卡实际运行在 x16 还是 x8？

双路 CPU 服务器还可能出现另一种结构：

CPU 0
├── GPU 0
└── GPU 1

CPU 1
├── GPU 2
└── GPU 3

GPU 0 和 GPU 1 通信时，路径可能是：

GPU 0
→ PCIe Switch
→ GPU 1

但 GPU 0 和 GPU 2 通信时，路径可能变成：

GPU 0
→ PCIe
→ CPU 0
→ CPU 间互联
→ CPU 1
→ PCIe
→ GPU 2

这条路径跨越了两颗 CPU 和两个 NUMA 域。

通常意味着：

• 传输路径更长；
• 延迟更高；
• 可用带宽更低；
• CPU 间互联也会成为共享瓶颈；
• NUMA 内存访问更复杂。

NVIDIA 的 nvidia-smi topo -m 会显示 GPU、CPU、NUMA 和网络设备之间的拓扑关系。其中，PIX 表示经过单个 PCIe Switch；PXB 表示经过多个 PCIe Switch；PHB 表示经过 CPU 的 PCIe Host Bridge；SYS 则表示路径还需要穿越 NUMA 节点之间的 CPU 互联。

因此，可以粗略理解为：

NV#：通常最好
PIX：路径较短
PXB：经过多个 PCIe Switch
PHB：经过 CPU Host Bridge
NODE：同一 NUMA 节点内跨 Host Bridge
SYS：跨 NUMA 或 CPU 间互联

假设拓扑结果是：

        GPU0  GPU1  GPU2  GPU3
GPU0     X    PIX   SYS   SYS
GPU1    PIX    X    SYS   SYS
GPU2    SYS   SYS    X    PIX
GPU3    SYS   SYS   PIX    X

这说明：

GPU0 和 GPU1 路径较近
GPU2 和 GPU3 路径较近
两组 GPU 之间需要跨 NUMA 或 CPU 互联

那么更合理的 TP2 组合是：

GPU0 + GPU1：实例 A
GPU2 + GPU3：实例 B

而不是：

GPU0 + GPU2
GPU1 + GPU3

必须记住：

GPU 编号相邻，不代表物理路径相邻。

多卡性能不是由显卡列表决定的。

它是由显卡之间的数据路径决定的。

---

五、最危险的情况：GPU 之间不能直接 P2P

理想的 GPU 间通信路径是：

GPU 0 显存
     ↓
GPU P2P
     ↓
GPU 1 显存

GPU 0 可以直接访问或传输数据到 GPU 1 的显存。

CUDA 是否支持两张 GPU 直接访问彼此显存，可以通过 cudaDeviceCanAccessPeer() 判断，并通过 cudaDeviceEnablePeerAccess() 启用。它是否可用，取决于具体的 GPU、PCIe 或 NVLink 拓扑以及系统配置。

如果 P2P 无法使用，数据传输可能需要经过主机内存：

GPU 0 显存
     ↓
PCIe
     ↓
CPU 内存
     ↓
PCIe
     ↓
GPU 1 显存

这会带来两个直接问题。

第一，多了一次或多次数据复制。

第二，CPU、系统内存带宽和 PCIe 会同时成为瓶颈。

原本应该由 GPU 直接完成的数据交换，现在需要 CPU 内存参与中转。

如果每生成一个 Token，都要在几十层甚至上百层模型中反复进行这种传输，性能损失会被不断放大。

NVIDIA 的 CUDA 文档明确说明，启用 P2P 后，GPU 间复制不再需要通过 Host Staging，也就是不必经过主机内存中转，因此通常会更快。

但 P2P 并不是“显卡插在同一台机器里”就自动成立。

它还可能受到以下因素影响：

• GPU 是否支持相应 P2P 路径；
• PCIe 拓扑；
• 驱动版本；
• BIOS 配置；
• 虚拟机环境；
• 容器对系统拓扑的暴露；
• IOMMU；
• ACS；
• GPU 与 PCIe Switch 的连接方式。

NCCL 官方文档指出，NCCL 会优先使用 GPU Direct 和 P2P 进行 GPU 间通信。但错误的虚拟机、容器、BIOS 或 PCIe 配置都可能导致 P2P 不可用或性能很差。

其中 ACS 是一个非常典型的坑。

ACS 可能把原本可以直接进行的 PCIe 点对点流量，强制重定向到 CPU Root Complex。

结果就是：

原本：
GPU 0 → PCIe Switch → GPU 1

变成：
GPU 0 → CPU Root Complex → GPU 1

NVIDIA 的 NCCL 故障排查文档明确指出，VT-d、IOMMU 和 ACS 可能干扰 GPU Direct，把点对点流量重定向到 CPU Root Complex，从而造成显著性能下降，严重时甚至可能导致任务挂起。

所以，绝对不能简单认为：

四张卡都插在同一台服务器里，就一定可以高速互访。

物理上位于同一台服务器，不等于逻辑上能够直接访问彼此显存。

---

六、不同并行方式，对通信的敏感度完全不同

很多多卡性能问题，本质上不是显卡性能差，而是并行策略和硬件条件不匹配。

常见并行方式至少包括：

数据并行 DP
张量并行 TP
流水线并行 PP
专家并行 EP

它们对 GPU 通信的依赖程度完全不同。

---

1. 数据并行：最适合消费级多卡推理

推理场景中的数据并行，可以理解为每张 GPU 保存一份完整模型，然后分别处理不同请求。

GPU 0：完整模型副本，处理用户 A
GPU 1：完整模型副本，处理用户 B
GPU 2：完整模型副本，处理用户 C
GPU 3：完整模型副本，处理用户 D

不同 GPU 之间几乎不需要频繁交换中间状态。

它的优点是：

• 单卡利用率通常更稳定；
• 总并发能力强；
• 对 PCIe 和 NVLink 要求较低；
• 单个请求不需要跨 GPU 同步；
• 某张 GPU 故障不一定影响全部服务；
• 尾延迟更容易控制。

缺点也很明显：

每张 GPU 都必须完整保存一份模型。

但只要模型能放进单卡，这通常就是四卡服务器最高效的使用方式。

例如，企业内部的：

• RAG；
• 知识库问答；
• Agent；
• 代码助手；
• 文档分析；
• OCR；
• Embedding；
• Reranker。

这些系统通常面对的是多个并发用户。

真正需要优化的是：

同时服务更多请求

而不是：

让一个请求同时占满所有 GPU

所以，只要模型能放进一张卡，优先考虑多个模型副本。

---

2. 张量并行：最容易被通信拖死

张量并行会把同一层中的矩阵计算切分到多张 GPU。

一层 Transformer
├── GPU 0 计算 25%
├── GPU 1 计算 25%
├── GPU 2 计算 25%
└── GPU 3 计算 25%

每张 GPU 完成自己的局部计算以后，还需要交换和合并结果。

因此，几乎每一层都可能执行：

• All-Reduce；
• All-Gather；
• Reduce-Scatter。

假设模型有 80 层。

那么生成一个 Token 的过程中，就可能发生大量跨 GPU 同步。

张量并行最麻烦的地方，不一定是单次传输量特别大。

而是：

通信发生得非常频繁。

所以它非常依赖：

• NVLink；
• NVSwitch；
• 高质量 PCIe P2P；
• 良好的 GPU 拓扑；
• NCCL 拓扑优化；
• 足够大的 Batch；
• 计算与通信重叠。

在只有 PCIe、没有 NVLink 的消费级多卡服务器上，经常会出现：

TP1：速度最快，但模型放不下

TP2：模型能运行，性能尚可

TP4：模型终于能放下，但生成速度下降

原因是 TP 从 2 增加到 4 后：

每张 GPU 的计算量减少了
但通信参与者增加了
同步点增加了
数据路径更加复杂
最慢 Rank 的影响更明显了

所以：

TP4 很多时候不是性能优化，而是显存不足时的容量妥协。

---

3. 流水线并行：通信少一些，但容易出现气泡

流水线并行按照模型层数进行切分。

GPU 0：第 1～20 层
GPU 1：第 21～40 层
GPU 2：第 41～60 层
GPU 3：第 61～80 层

GPU 0 完成前 20 层后，将 Hidden State 发送给 GPU 1。

GPU 1 再计算第 21～40 层。

与张量并行相比，它不需要在每一层内部进行完整的 All-Reduce。

相邻 Stage 主要传递 Hidden State。

但它存在一个严重问题：

Pipeline Bubble，也就是流水线气泡。

例如：

时间 1：
GPU0 工作
GPU1、GPU2、GPU3 等待

时间 2：
GPU0、GPU1 工作
GPU2、GPU3 等待

时间 3：
GPU0、GPU1、GPU2 工作
GPU3 等待

时间 4：
四张 GPU 才全部进入工作状态

想要减少流水线气泡，就需要持续输入多个 Micro-batch，让不同 Stage 同时处理不同批次。

但对于单用户、本地聊天和低并发推理：

请求数量不足
Batch 太小
Micro-batch 不够

流水线就很难被填满。

于是，即使安装了四张 GPU，也可能不断出现部分 GPU 空转。

---

4. 专家并行：对通信最凶险

专家并行是 K3 这类 MoE 模型最需要警惕的部分。

K3 拥有 896 个路由专家，每个 Token 选择其中 16 个专家。

这些专家会被分布到不同 GPU。

Router 完成选择后，可能得到：

Token 1 → GPU 0 上的专家
Token 2 → GPU 3 上的专家
Token 3 → GPU 1 上的专家
Token 4 → GPU 2 上的专家

系统先执行 Token Dispatch：

把 Token 发送到专家所在 GPU

专家完成计算后，再执行 Expert Combine：

把专家结果发送回来
重新恢复原来的 Token 顺序
合并计算结果

这个过程通常依赖 All-to-All 通信。

All-to-All 的意思是：

每张 GPU
都可能向其他所有 GPU 发送数据

同时
每张 GPU 也可能从其他 GPU 接收数据

NCCL 对 All-to-All 的定义是：每个 Rank 都提供面向所有目标 Rank 的数据块，并将对应数据块发送给相应 Rank。

专家并行还有一个比通信更加麻烦的问题：

专家负载不均衡。

例如，某个 Batch 的路由结果是：

专家 A：收到 10000 个 Token
专家 B：收到 8000 个 Token
专家 C：收到 100 个 Token
专家 D：收到 20 个 Token

专家 C 和专家 D 很快就计算完成。

但整个系统不能直接继续。

因为专家 A 还没有完成。

结果可能变成：

GPU 0：完成，等待
GPU 1：完成，等待
GPU 2：仍在处理热门专家
GPU 3：完成，等待

整个系统的速度，最终由最慢的那个 Rank 决定。

这就是分布式计算中的 Straggler，也就是掉队者问题。

因此，四种并行方式的通信敏感度可以粗略排序为：

数据并行      较低
流水线并行    中等
张量并行      较高
专家并行      最高

这也解释了为什么 K3 这种拥有 896 个专家的模型，需要高带宽、低延迟的高速互联域。

而不能简单地认为：

找几十张消费级 GPU
把显存加起来
就等于拥有一套 K3 推理集群

显存容量可能够了。

但通信系统很可能完全撑不住。

---

七、为什么 104B 激活参数不等于一个普通的 104B 模型？

很多人看到 K3 的参数配置：

总参数：2.8T
激活参数：104B

会下意识认为：

虽然 K3 有 2.8T 参数，但每次只用 104B，所以部署难度应该和一个 104B Dense 模型差不多。

这个结论不成立。

可以把 K3 想象成一家拥有 896 名专家的公司。

每次处理一个任务，只邀请 16 名专家参加。

这样做的好处是：

公司可以拥有巨大的知识容量
但不需要每个任务都让全部专家参与

这就是 MoE 的价值。

但是，虽然一次只邀请 16 名专家开会，896 名专家依然都需要办公室。

同样：

总参数量
决定所有模型权重需要占用多少空间

激活参数量
决定一个 Token 大约需要执行多少计算

2.8T 总参数解释了为什么 K3 的 Checkpoint 接近 1.56TB。

104B 激活参数解释了为什么每个 Token 不必让全部 2.8T 参数参与计算。

但 104B 激活参数没有包括：

• Router 计算；
• Token Dispatch；
• Expert Combine；
• All-to-All 通信；
• 专家负载不均衡；
• 跨卡同步；
• 通信缓冲区；
• 等待最慢 Rank。

因此：

激活参数描述的是“算多少”，不是“搬多少”，更不是“等多久”。

K3 每个 Token 的计算量可能接近一个超大 Dense 模型。

但它的系统行为和普通 Dense 模型完全不同。

---

八、看 K3 这样的超大模型，必须同时算四本账

以后看到一个超大模型，不能只看参数量。

至少要同时计算四本账。

---

第一笔账：权重存储

理论权重大小可以粗略估算为：

权重大小
≈ 参数数量 × 每个参数位数 ÷ 8

K3 有 2.8T 参数。

假设全部按照 4bit 保存：

2.8T × 4bit ÷ 8
≈ 1.4TB

但真实模型中还包括：

• 部分高精度参数；
• 量化 Scale；
• Embedding；
• Norm 参数；
• 视觉编码器；
• 元数据；
• 文件格式开销；
• 内存对齐。

因此，K3 实际 Checkpoint 大约为 1.56TB。

这笔账决定的是：

模型权重能不能放进显存？

---

第二笔账：每个 Token 的计算量

激活参数决定一次前向传播中，大约有多少参数真正参与计算。

MoE 的价值可以理解为：

很大的总参数容量
+
相对受控的单 Token 计算量

但它没有完整计算：

路由开销
通信开销
同步开销
负载不均衡

所以这笔账回答的是：

大约需要算多少？

而不是：

最终需要运行多久？

---

第三笔账：KV Cache 和运行状态

生产环境中的显存占用，不只有模型权重。

完整占用更接近：

总显存占用
=
模型权重
+ KV Cache
+ KDA / MLA 运行状态
+ 活跃请求状态
+ 通信缓冲区
+ Kernel Workspace
+ CUDA Graph
+ 框架运行时
+ 内存碎片

K3 支持最高 100 万 Token 上下文，但“一条百万 Token 请求能够运行”，不代表“几十条百万 Token 请求能够同时运行”。

并发环境中，运行状态还会受到以下因素影响：

上下文长度
× 模型层数
× 隐藏状态规模
× 活跃请求数量

所以，支持百万上下文是模型能力。

能否以合理成本并发服务百万上下文，则是系统能力。

---

第四笔账：GPU 通信

多卡总时间可以粗略理解为：

总时间
=
计算时间
+ 数据传输时间
+ 集合通信时间
+ 同步等待时间
+ 调度开销

这笔账最容易被忽略。

却经常决定模型最终到底能跑多快。

一个模型可能已经成功放进显存：

模型加载成功
GPU 全部识别
显存全部占用

但系统仍然可能处于：

GPU 很快完成计算
然后长时间等待通信

所以：

能不能装下，是容量问题；能不能高效运行，是系统问题。

---

九、没有 NVLink，消费级多卡还有价值吗？

当然有。

但必须用对方式。

以 RTX 4090 为例，它没有 NVLink，多卡之间主要依赖 PCIe。

这意味着它不适合所有跨卡并行方式。

如果一个模型可以装进单张 GPU，可以让多张 GPU 分别处理不同请求：

GPU 0：处理用户 A
GPU 1：处理用户 B
GPU 2：处理用户 C
GPU 3：处理用户 D

这种情况下，不同 GPU 之间几乎不需要频繁交换中间状态。

四张 GPU 仍然可以显著提高总吞吐。

所以，真正应该问的不是：

服务器里有几张 GPU？

而是：

一个请求需要跨越几张 GPU？

一个请求跨越的 GPU 越多，对通信的要求通常越高。

因此，消费级多卡最重要的原则不是：

尽量让所有 GPU
都参与同一个请求

而是：

尽量减少一个请求
需要跨越的 GPU 数量

---

十、四张消费级 GPU，应该怎么分配？

假设你有四张 GPU，可以根据模型容量分成三种情况。

---

场景一：模型可以装进一张 GPU

优先部署四个独立副本：

GPU 0：模型副本 A
GPU 1：模型副本 B
GPU 2：模型副本 C
GPU 3：模型副本 D

然后通过 API Gateway、LiteLLM 或负载均衡器分发请求。

如果并发量不高，也可以按照服务拆分：

GPU 0：主语言模型
GPU 1：视觉语言模型
GPU 2：Embedding + Reranker
GPU 3：OCR、批处理或备用实例

这通常比强行把四张卡绑成一个 TP4 实例更加稳定。

---

场景二：模型必须两张 GPU 才能装下

优先考虑两个 TP2 实例：

GPU 0 + GPU 1：模型实例 A
GPU 2 + GPU 3：模型实例 B

而不是一个 TP4 实例：

GPU 0 + GPU 1 + GPU 2 + GPU 3

两个 TP2 通常意味着：

• 每个实例参与通信的 GPU 更少；
• 总并发能力更高；
• 尾延迟更稳定；
• 故障隔离更容易；
• GPU 更容易持续执行有效计算。

但 GPU 配对不能只看编号。

应该结合：

nvidia-smi topo -m

优先选择 PIX、PXB 或高速互联路径较近的 GPU。

---

场景三：模型必须四张 GPU 才能装下

这时候 TP4 是容量上的被迫选择。

目标不应该再是：

四张 GPU 必须长期保持 100% 利用率

更合理的目标是：

模型稳定加载
不发生 OOM
TTFT 可以接受
TPOT 可以接受
并发达到业务要求
NCCL 没有走异常路径
没有严重 Host Staging
单位请求成本合理

如果跨卡通信已经占用大量时间，那么 GPU 利用率只有 40% 或 50%，不一定说明程序写错了。

它可能已经接近当前硬件拓扑的性能上限。

---

十一、真正排查多卡性能，不能只看 nvidia-smi

nvidia-smi 的 GPU 利用率，只能告诉你某个采样窗口内 GPU 是否在执行 Kernel。

它不能直接告诉你：

GPU 为什么没有执行 Kernel
是在等待数据
还是在等待同步
还是在等待 CPU
还是在等待其他 GPU

一套完整的多卡排查流程，至少应该包括以下步骤。

---

第一步：查看 GPU 拓扑

nvidia-smi topo -m

重点查看：

GPU 之间是 NV#、PIX、PXB、PHB、NODE 还是 SYS
GPU 分别属于哪个 NUMA 节点
GPU 和网卡之间的距离

---

第二步：查看 PCIe 实际速率

nvidia-smi -q

或者使用：

lspci -vv

确认每张 GPU 实际运行在：

PCIe 4.0 x16
PCIe 4.0 x8
PCIe 5.0 x16

不要只看主板插槽外观。

---

第三步：检查 GPU P2P

nvidia-smi topo -p2p p

其中 p 用于检查 PCIe P2P 能力。

NVIDIA 文档也建议使用 CUDA Samples 中的工具测试 GPU 间 Peer Access、带宽和延迟。

例如：

p2pBandwidthLatencyTest

它可以帮助确认：

• GPU 是否支持 Peer Access；
• 单向 P2P 带宽；
• 双向 P2P 带宽；
• GPU 间延迟。

---

第四步：测试 NCCL 集合通信

可以使用 nccl-tests：

./build/all_reduce_perf \
  -b 8M \
  -e 8G \
  -f 2 \
  -g 4

分别测试：

-g 1
-g 2
-g 4

重点关注：

algbw
busbw
不同数据量下的带宽
GPU 数量增加后的扩展效率

如果从两张 GPU 增加到四张 GPU 后，通信带宽没有合理扩展，甚至明显下降，就需要继续检查：

• PCIe 拓扑；
• P2P；
• PCIe Lane；
• NUMA；
• CPU 绑定；
• ACS；
• IOMMU；
• BIOS 设置。

---

第五步：查看 NCCL 实际通信路径

运行任务前开启日志：

export NCCL_DEBUG=INFO
export NCCL_DEBUG_SUBSYS=INIT,GRAPH,P2P

重点观察 NCCL 选择的路径：

P2P / IPC
SHM
NET
Socket

可以粗略理解为：

P2P / IPC：
GPU 之间直接传输，通常更理想

SHM：
通过主机共享内存中转

NET / Socket：
通过网络或 Socket 通信

如果同一台服务器中的 GPU 通信大量退化到 SHM，就需要进一步检查：

• P2P 是否被禁用；
• ACS 是否强制流量绕路；
• IOMMU；
• 容器权限；
• /sys 是否正确挂载；
• PCIe 拓扑；
• 驱动和 NCCL 版本。

---

第六步：对比 TP1、TP2、TP4

如果显存允许，应分别测试：

TP1
TP2
TP4

每一种配置至少记录：

• TTFT；
• TPOT；
• 单请求 Tokens/s；
• 总吞吐量；
• 并发能力；
• P50 延迟；
• P95 延迟；
• P99 延迟；
• GPU 利用率；
• GPU 显存占用；
• CPU 内存占用。

不要只比较模型能不能启动。

真正需要回答的是：

GPU 数量增加以后，业务指标到底有没有改善？

---

十二、买显卡之前，应该先决定怎么并行

很多人的采购顺序是：

先买显卡
→ 再选择模型
→ 最后研究怎么并行

更合理的顺序应该反过来：

先确定业务负载
→ 再确定模型规模
→ 再选择并行策略
→ 最后选择硬件

采购之前，至少应该回答以下问题。

1. 模型能不能装进一张卡？

如果可以，优先考虑多个独立副本。

2. 模型至少需要几张卡？

能用 TP2，就不要为了“让所有 GPU 都参与”而强行使用 TP4。

3. 业务目标是低延迟还是高并发？

低延迟更怕跨卡通信。

高并发通常更适合多个独立副本。

4. 模型是 Dense 还是 MoE？

MoE 对以下能力更加敏感：

All-to-All
专家负载均衡
专家放置
GPU 高速互联
跨节点 RDMA

5. 每张 GPU 实际获得多少 PCIe Lane？

物理 x16 插槽，不等于实际运行在 x16。

6. GPU 是否跨 CPU 和 NUMA？

跨 NUMA 会增加通信路径和延迟。

7. GPU P2P 是否真正可用？

必须通过命令和基准测试确认。

8. NCCL 实测带宽是多少？

购买多卡服务器时，应该要求供应商提供真实 NCCL 测试结果，而不只是显卡规格表。

---

十三、多卡服务器真正的采购清单

下一次采购多卡服务器，不要只问：

可以安装几张显卡？
总显存有多少？
电源功率够不够？

还要继续追问：

每张 GPU 实际运行在 PCIe x16 还是 x8？

四张卡同时安装后是否会降速？

GPU 分别挂在哪一颗 CPU 下？

GPU 是否跨 NUMA 节点？

GPU 之间是 NV#、PIX、PXB、PHB 还是 SYS？

是否存在 PCIe Switch？

GPU P2P 是否可用？

ACS 和 IOMMU 如何配置？

NCCL All-Reduce 实测带宽是多少？

目标模型准备使用 DP、TP、PP 还是 EP？

TP2 和 TP4 的真实性能分别是多少？

是否支持 GPU Direct RDMA？

跨节点网络使用什么网卡和交换机？

显卡型号只能告诉你：

单个计算节点有多强

拓扑和通信才能告诉你：

这些节点能不能组成一个高效系统

---

结语：K3 开放了世界级模型，但没有消灭系统工程门槛

Kimi K3 的开放，确实具有标志性意义。

一个拥有 2.8T 参数、896 个专家、百万 Token 上下文、进入全球第一梯队的模型，其完整权重已经可以被开发者获取。

但 K3 同时也证明了一件更现实的事：

模型权重开放，不等于部署门槛消失。

8 张 MI355X 可以让 K3 完成加载和正确性验证。

但这首先解决的是：

模型能不能放进去？

它还没有完整回答：

模型放进去以后
能不能以合理的吞吐、延迟和成本运行？

同样，四张 24GB 显卡的确可以提供 96GB 总显存。

但它们不会自动变成一张拥有 96GB 统一显存、四倍算力和四倍速度的超级显卡。

显存只能相对直接地相加。

性能却取决于：

单卡计算能力
× 并行策略
× GPU 通信带宽
× PCIe 拓扑
× P2P 能力
× NUMA 路径
× 批处理与调度
× 推理框架优化

对于消费级多卡服务器，更合理的原则通常是：

模型尽量控制在一到两张 GPU 内
+
使用多个模型副本提高并发
+
按照真实拓扑选择 GPU 组合
+
让不同 GPU 承担不同服务
+
容量不足时再提高张量并行规模

以后再看到：

支持八卡
总显存 192GB
四卡并行加速

不要只看 GPU 数量。

真正应该追问的是：

这些 GPU 之间如何通信？

数据会经过哪些设备？

P2P 是否可用？

是否跨 CPU 和 NUMA？

NCCL 实测带宽是多少？

一个请求需要跨越几张 GPU？

选择的是 DP、TP、PP 还是 EP？

当你开始关注拓扑、P2P、NCCL、NUMA 和并行策略时，才算真正从“会买显卡”，进入了“会设计大模型计算系统”的阶段。

最后记住一句话：

K3 开放的是世界第一梯队模型的权重，但真正让这种模型运行起来的，不是某一张最强显卡，而是让几十张甚至上百张 GPU 像一台机器一样协同工作的系统能力。

---

文章标签：Kimi K3、大模型部署、MoE、GPU 通信、NCCL、张量并行、数据并行、流水线并行、专家并行、PCIe、P2P、NUMA、RTX 4090、AMD MI355X、分布式推理