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 层被切分到四张 GPUGPU 0计算矩阵的一部分 GPU 1计算矩阵的一部分 GPU 2计算矩阵的一部分 GPU 3计算矩阵的一部分 ↓ 等待所有 GPU 完成局部计算 ↓ All-Reduce / All-Gather ↓ 合并计算结果 ↓ 进入下一层一张 GPU 即使已经完成自己的部分也不能直接进入下一层。因为下一层需要的是完整结果。它必须等待其他 GPU 完成并等待集合通信结束。NCCL 的集合通信要求参与操作的各个 Rank 共同完成相应操作。All-Reduce 会聚合所有 Rank 的结果并将结果返回给各个 RankAll-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 是整个系统每秒能够为所有用户生成多少 TokenConcurrency 是系统在延迟不失控的前提下可以同时服务多少请求。很多所谓的“最低配置”只能证明前两层。它证明模型能装进去也能输出答案。但如果没有公布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 0PCIe 4.0 x16 GPU 1PCIe 4.0 x16 GPU 2PCIe 4.0 x8 GPU 3PCIe 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 3GPU 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 SwitchPXB 表示经过多个 PCIe SwitchPHB 表示经过 CPU 的 PCIe Host BridgeSYS 则表示路径还需要穿越 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 配置虚拟机环境容器对系统拓扑的暴露IOMMUACSGPU 与 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 1NVIDIA 的 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代码助手文档分析OCREmbeddingReranker。这些系统通常面对的是多个并发用户。真正需要优化的是同时服务更多请求而不是让一个请求同时占满所有 GPU所以只要模型能放进一张卡优先考虑多个模型副本。2. 张量并行最容易被通信拖死张量并行会把同一层中的矩阵计算切分到多张 GPU。一层 Transformer ├── GPU 0 计算 25% ├── GPU 1 计算 25% ├── GPU 2 计算 25% └── GPU 3 计算 25%每张 GPU 完成自己的局部计算以后还需要交换和合并结果。因此几乎每一层都可能执行All-ReduceAll-GatherReduce-Scatter。假设模型有 80 层。那么生成一个 Token 的过程中就可能发生大量跨 GPU 同步。张量并行最麻烦的地方不一定是单次传输量特别大。而是通信发生得非常频繁。所以它非常依赖NVLinkNVSwitch高质量 PCIe P2P良好的 GPU 拓扑NCCL 拓扑优化足够大的 Batch计算与通信重叠。在只有 PCIe、没有 NVLink 的消费级多卡服务器上经常会出现TP1速度最快但模型放不下 TP2模型能运行性能尚可 TP4模型终于能放下但生成速度下降原因是 TP 从 2 增加到 4 后每张 GPU 的计算量减少了 但通信参与者增加了 同步点增加了 数据路径更加复杂 最慢 Rank 的影响更明显了所以TP4 很多时候不是性能优化而是显存不足时的容量妥协。3. 流水线并行通信少一些但容易出现气泡流水线并行按照模型层数进行切分。GPU 0第 120 层 GPU 1第 2140 层 GPU 2第 4160 层 GPU 3第 6180 层GPU 0 完成前 20 层后将 Hidden State 发送给 GPU 1。GPU 1 再计算第 2140 层。与张量并行相比它不需要在每一层内部进行完整的 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 DispatchExpert CombineAll-to-All 通信专家负载不均衡跨卡同步通信缓冲区等待最慢 Rank。因此激活参数描述的是“算多少”不是“搬多少”更不是“等多久”。K3 每个 Token 的计算量可能接近一个超大 Dense 模型。但它的系统行为和普通 Dense 模型完全不同。八、看 K3 这样的超大模型必须同时算四本账以后看到一个超大模型不能只看参数量。至少要同时计算四本账。第一笔账权重存储理论权重大小可以粗略估算为权重大小 ≈ 参数数量 × 每个参数位数 ÷ 8K3 有 2.8T 参数。假设全部按照 4bit 保存2.8T × 4bit ÷ 8 ≈ 1.4TB但真实模型中还包括部分高精度参数量化 ScaleEmbeddingNorm 参数视觉编码器元数据文件格式开销内存对齐。因此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 2Embedding Reranker GPU 3OCR、批处理或备用实例这通常比强行把四张卡绑成一个 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-sminvidia-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 P2Pnvidia-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 拓扑P2PPCIe LaneNUMACPU 绑定ACSIOMMUBIOS 设置。第五步查看 NCCL 实际通信路径运行任务前开启日志export NCCL_DEBUGINFO export NCCL_DEBUG_SUBSYSINIT,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每一种配置至少记录TTFTTPOT单请求 Tokens/s总吞吐量并发能力P50 延迟P95 延迟P99 延迟GPU 利用率GPU 显存占用CPU 内存占用。不要只比较模型能不能启动。真正需要回答的是GPU 数量增加以后业务指标到底有没有改善十二、买显卡之前应该先决定怎么并行很多人的采购顺序是先买显卡 → 再选择模型 → 最后研究怎么并行更合理的顺序应该反过来先确定业务负载 → 再确定模型规模 → 再选择并行策略 → 最后选择硬件采购之前至少应该回答以下问题。1. 模型能不能装进一张卡如果可以优先考虑多个独立副本。2. 模型至少需要几张卡能用 TP2就不要为了“让所有 GPU 都参与”而强行使用 TP4。3. 业务目标是低延迟还是高并发低延迟更怕跨卡通信。高并发通常更适合多个独立副本。4. 模型是 Dense 还是 MoEMoE 对以下能力更加敏感All-to-All 专家负载均衡 专家放置 GPU 高速互联 跨节点 RDMA5. 每张 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、分布式推理