# 热门搜索 #
大模型
人工智能
openai
融资
chatGPT
顶级 GPU 躺平，只因模型不懂硬件逻辑
上个月，一位做推荐系统的朋友找我大吐苦水。团队花了大几百万，刚咬牙把模型搬上了 8 张 H100，满心以为能轻松扛住流量。结果监控面板一拉，心凉了半截，GPU 利用率常年躺平在 40% 上下。
他的第一反应是：“完了，老板咱们还得加卡。”
停！先捂紧钱包。
别总觉得是卡不够。模型跑不快，问题很可能根本不在 GPU，而是你的模型在写下第一行代码的设计之初，就没有设计成适配GPU的形状。
就在最近，英伟达亲自下场，发布了一篇名为《AI Model Co-Design: Hardware-Friendly LLM Design》的技术博客。整篇文章洋洋洒洒，其实就想点醒行业一件事：别光顾着堆算力了，来看看你们是怎么把顶级显卡逼成“磨洋工”的吧。
要看懂英伟达的这篇论文，得先认清 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 饿成了内存受限。
在真实的 AI 商业落地中，性能永远被三个维度同时锁死，分别是：准确性、吞吐量和交互性。
准确性指的模型回答的对不对、准不准，这是模型的生命底线；吞吐量指的是服务器每秒能吐出多少 Token，代表系统能同时接待多少人，直接决定了运营成本；而交互性则是用户的直观体感，它分为“首字延迟”和“字间延迟”，代表用着卡不卡。
一般来说，这三者紧密联系。然而在实际落地中，吞吐量和交互性天生相克。为了省钱追求高吞吐，系统就得把大量请求打包一起处理，这会导致用户排队、延迟拉长；而为了交互流畅，就要来一个处理一个，又会导致GPU严重闲置、成本飙升。二者此消彼长，在坐标轴上形成了一条无法跨越的帕累托曲线。
图注：吞吐量和交互性的帕累托曲线，提高其中一个指标通常会降低另一个指标 面对“既要、又要、还要”的终极商业诉求，业界的破局点在于“一起变强”：让这条曲线向外整体迁移。
想要达到这个目的就要从第一天开始就做好“模型-硬件协同设计”。
那具体有哪些设计的要点要特别呢？可以从以下四个方面考虑。
1.算准显卡的性能边界，对齐屋顶线模型：
必须精确计算边界，看什么情况下显卡是真的“计算能力跑满”了（算力受限）。在设计模型层数和维度时，坚决避开那些会把显卡逼进“等数据”状态的结构。
2.迎合底层硬件的计算规格，对齐 Tile 尺寸：
迎合底层计算网格 128/256/512 的打包规格，不搞诸如“333”这种让机器卡壳凑整的奇葩维度。
3.适配低精度计算：
针对新一代显卡（如 Blackwell）内置的极速低精度通道（NVFP4），让数据格式天生无合。
4.对齐网络拓扑：
顺着显卡集群真实的网线分布，提前切好数据块，绝不在几万张卡的通信中造堵车。
总之，只有让模型的每一个维度数字、每一层结构，从头到尾都严丝合缝地贴合 GPU 的硬件运行逻辑，才能彻底打破性能上的死结。让系统反应更快、服务器能承载的用户更多，同时模型的智商依然绝对在线！
为了把这件事说透，英伟达直接甩出了 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科技评论”，作者 “AI科技评论”
