顶级 GPU 躺平，只因模型不懂硬件逻辑

    作者丨高允毅

    编辑丨马晓宁

上个月，一位做推荐系统的朋友找我大吐苦水。团队花了大几百万，刚咬牙把模型搬上了 8 张 H100，满心以为能轻松扛住流量。结果监控面板一拉，心凉了半截，GPU 利用率常年躺平在 40% 上下。

他的第一反应是：" 完了，老板咱们还得加卡。"

停！先捂紧钱包。 

别总觉得是卡不够。模型跑不快，问题很可能根本不在 GPU，而是你的模型在写下第一行代码的设计之初，就没有设计成适配 GPU 的形状。

就在最近，英伟达亲自下场，发布了一篇名为《AI Model Co-Design: Hardware-Friendly LLM Design》的技术博客。整篇文章洋洋洒洒，其实就想点醒行业一件事：别光顾着堆算力了，来看看你们是怎么把顶级显卡逼成 " 磨洋工 " 的吧。

01

为什么 " 大力士 " 在磨洋工

要看懂英伟达的这篇论文，得先认清 GPU 的真面目。

可以把 GPU 看作是个干活极快的 " 超级大力士 "，它的计算能力极强，每秒能完成几十万亿次浮点运算。理论上讲，其算力天花板极高。

但另一方面，它必须等材料喂到嘴边才能干活，对应的是所有的模型权重、输入特征，都必须从显存搬运到计算核心里。

当我们觉得 GPU 没有跑满的时候，未必是他自身的计算能力出了问题，还取决于能不能持续喂够原料，而 " 喂的好不好 " 的唯一标准，就是论文里指出的核心概念 " 算术强度 "。

这有一个公式，算术强度 = 显卡完成的计算总次数 ÷ 显卡搬运的内存总字节数这个公式解释的是，每搬运 1 字节数据，能让 GPU 干多少次算数活？ 当算数强度低的时候，GPU 花 90% 的时间在等数据读写，真正用来做计算的时间微乎其微。这个问题就叫" 访存受限 "。你花重金买的高端算力，就是这么被闲置的。

论文中列举的一个极具代表性的硬件低效反面案例 FFN-2。FFN-2 指的是大模型中前馈神经网络的第二层（降维映射层）。在标准的矩阵乘法计算中，该层涉及三个核心维度：

M 是输入的 Token 总数、N 是隐藏维度、K 是中间维度。这三者决定了矩阵乘法的总计算量 其中 N 固定设为了 8192，K 设为了 512。

图注：论文分析了 GB300 硬件下（15 PFLOPS FP4 算力 /8 TB/s 带宽）FFN-2 层在 N=8192、K=512 配置下的矩阵乘法理论耗时。结果表明，由于显存数据传输耗时始终长于实际计算时间，该层不论在何种 Token 数量下均受限于显存带宽。 关键问题，就出在这个 512 上。因为 K 过小，导致总计算量非常小。换句话说，计算的数量远远少于 GPU 搬了的数据数量。

更要命的是，现在的大模型为了提速，喜欢用低精度格式，会加速 GPU 的处理速度，那数据搬运的速度彻底跟不上计算的速度，GPU 根本跑不满。 在实际测试中，这种浪费更加严重。论文在英伟达最新的 GB300 芯片上跑了实测，结果发现，在固定 M=8192 的情况下，K 维度必须大于 3072，吞吐量才能勉强摸到 80%；直到 6144 才能彻底喂饱显卡。

对比一下 512 和 6144，差不多十倍的差距，算力浪费的原因自然显现。

所以，英伟达在博客中下了一个结论，" 有时存储是比 GPU 更大的瓶颈 "，这个论断在算术强度过低这个具体语境下是基本成立的，因为你的矩阵形状把 GPU 饿成了内存受限。

02

模型 - 硬件要协同设计的关键细则

在真实的 AI 商业落地中，性能永远被三个维度同时锁死，分别是：准确性、吞吐量和交互性。

准确性指的模型回答的对不对、准不准，这是模型的生命底线；吞吐量指的是服务器每秒能吐出多少 Token，代表系统能同时接待多少人，直接决定了运营成本；而交互性则是用户的直观体感，它分为 " 首字延迟 " 和 " 字间延迟 "，代表用着卡不卡。

一般来说，这三者紧密联系。然而在实际落地中，吞吐量和交互性天生相克。为了省钱追求高吞吐，系统就得把大量请求打包一起处理，这会导致用户排队、延迟拉长；而为了交互流畅，就要来一个处理一个，又会导致 GPU 严重闲置、成本飙升。二者此消彼长，在坐标轴上形成了一条无法跨越的帕累托曲线。

图注：吞吐量和交互性的帕累托曲线，提高其中一个指标通常会降低另一个指标 面对 " 既要、又要、还要 " 的终极商业诉求，业界的破局点在于 " 一起变强 "：让这条曲线向外整体迁移。

想要达到这个目的就要从第一天开始就做好 "模型 - 硬件协同设计 "。

那具体有哪些设计的要点要特别呢？可以从以下四个方面考虑。

1. 算准显卡的性能边界，对齐屋顶线模型：

必须精确计算边界，看什么情况下显卡是真的 " 计算能力跑满 " 了（算力受限）。在设计模型层数和维度时，坚决避开那些会把显卡逼进 " 等数据 " 状态的结构。

2. 迎合底层硬件的计算规格，对齐 Tile 尺寸：

迎合底层计算网格 128/256/512 的打包规格，不搞诸如 "333" 这种让机器卡壳凑整的奇葩维度。

3. 适配低精度计算：

针对新一代显卡（如 Blackwell）内置的极速低精度通道（NVFP4），让数据格式天生无合。

4. 对齐网络拓扑： 

顺着显卡集群真实的网线分布，提前切好数据块，绝不在几万张卡的通信中造堵车。

总之，只有让模型的每一个维度数字、每一层结构，从头到尾都严丝合缝地贴合 GPU 的硬件运行逻辑，才能彻底打破性能上的死结。让系统反应更快、服务器能承载的用户更多，同时模型的智商依然绝对在线！

03

架构师 7 条核心设计准则

为了把这件事说透，英伟达直接甩出了 7 条按 " 对吞吐量影响大小 " 排序的硬件友好设计准则。这简直就是大模型时代的 " 设计施工规范 "：

▎准则 1：拒绝 " 畸形瘦高个 "，参数矩阵越 " 方 " 越好

在总参数不变的前提下，绝不能把中间维度捏得太窄，比如前面提到的 512。

因为矩阵一旦太窄，计算量就太小，单位计算对应的数据搬运量大幅提升。这会直接导致显卡掉进 " 内存搬运受限 " 的陷阱。论文实测证明，这种 " 畸形扁矩阵 " 会让极品算力全程都在磨洋工。

▎准则 2：模型维度严格对齐 GPU Tile 尺寸，模型维度必须是 128/256/512 的倍数

所有线性层的维度别拍脑袋定，必须认准 128 的倍数，追求极致就用 256 或 512。GPU 是按固定大小的 " 包装箱 "（Tile）干活的，你弄个零头，GPU 依然会分配一整个计算周期去处理 " 空箱子 "，吞吐曲线直接跌出锯齿状。测试显示，只有严格对齐，吞吐量才能摸到最高峰值。

▎准则 3：拥抱极限低精度，天生适配 NVFP4

新一代模型在设计层结构时，应该从一开始就把 " 支持 NVFP4（4 位浮点量化）" 考虑进去。

因为 Blackwell 架构的 GB300 显卡自带 NVFP4 专用计算通道，它通过一套双重缩放机制，把 4 位低精度计算的误差压到了极低水平。在 GB300 上，NVFP4 的峰值算力是 FP8 的 3 倍、FP16 的 6 倍！

DeepSeek-R1 已经验证过这一点，用 NVFP4 量化后，绝大多数测试成绩与高精度版本差距不到 1%，甚至在部分数学和代码任务上还出现了反超。这说明，极致压缩不仅可行，而且是提速降本的必杀技。

▎准则 4：同等参数量下，宽模型优先于深模型

固定参数下，要少叠几层、把每一层做宽。因为模型太 " 深 " 就像漫长的接力赛，延迟高；但变 " 宽 " 反而像拓宽高速公路，不仅算术强度飙升，吞吐大，还延迟低。

▎准则 5：搞 MoE 别瞎切，改用 " 专家分发（EP）"

在追求大吞吐、海量并发的批量服务场景下，面对庞大的 MoE 模型，不应单纯依赖传统张量并行（TP）。因为并发越高，跨卡聚合通信越拥堵，反而拖累性能。

优先选用扩展式专家并行（Wide-EP），把不同 " 专家 " 完整分给不同 GPU，单卡显存压力大幅降低。超大模型也可采用 EP × TP 混合并行，兼顾显存容量与吞吐效率。

▎准则 6：模型结构像 " 搭积木 " 一样规整，跑满流水线

模型每一层的设计模式要尽量统一、规整，不要搞得奇形怪状。

规整的结构能完美适配分块流水线并行（CPP），把几十万字的长文本输入瞬间拆解，彻底消灭 " 长文卡顿 "，把首字响应速度压到极限。

▎准则 7：分而治之，解绑 Attention 与 FFN

在要求极低延迟的交互场景下，不要把 " 注意力机制（Attention）" 和 " 前馈网络（FFN）" 强行绑在同一种并行策略上。

它们俩的脾气完全不同。FFN 适合分摊权重降内存，而 Attention 瓶颈在 KV 缓存。

这时候，应该给注意力机制开小灶，用一种叫 Helix 的并行架构去切割序列维度，并利用显卡间极高带宽的 NVLink 专线来掩盖通信时间的开销，从而把系统的交互延迟压到极致。

另外，如果你不想手搓这些高阶并行策略，英伟达已经把它们打包进了 TensorRT Model Optimizer 和 TensorRT-LLM 工具里。

说到底，谁应该特别关注这些准则呢？

最显而易见的是模型架构师，下次开训练新模型，先对照这 7 条把维度过一遍。这样改一行代码调整形状的成本，比上线后苦哈哈地加卡便宜一万倍。

然后对推理优化工程师来说，这是一本省钱指南。以后看到模型上线但 GPU 利用率低，先查 GEMM 的算术强度，别急着向领导申请扩容。

至于对采购决策者而言，更加需要慎重。买卡的 ROI 并不只看算力参数，它深度取决于你们家模型的 " 矩阵形状 "。形状不对，你花几千万加卡，也仅仅是把那堵冰冷的 " 内存墙 " 往后推了微不足道的一点点。

降本增效不只是在咬牙签下巨额算力订单的那一刻，能在这些设计细节上做对决定，团队就能在不知不觉中省下一笔天文数字。

参考链接：

https://developer.nvidia.com/blog/ai-model-co-design-hardware-friendly-llm-design/

上车，雷峰网 ( 公众号：雷峰网 ) 带你看遍全球 AI 顶会精华

可独家畅览：

专家演讲 PPT

大会报告全文

热门论文解读

学术新星访谈

扫描上方二维码

或点击「阅读原文」关注专区。

雷峰网原创文章，未经授权禁止转载。详情见转载须知。