推理服务器的选型，这几年我一直有个很深的体会：在GPU集群里，真正让人头疼的不是算力不够，而是显存不够。70B模型量化到FP8还要70GB，叠上KV Cache，单卡想舒舒服服跑起来几乎是奢望。HBM带宽确实猛，但价格也猛，这种矛盾在推理场景里尤其别扭。所以英特尔披露AI推理GPU技术细节时，我最先盯住的两个数字就是：显存最高480GB，不用HBM。这个组合打破了很多人对"高性能GPU必须配HBM"的惯性认知，对做推理部署的人来说，值得掰开揉碎聊一聊。
这篇文章不打算复述新闻，而是想从一个长期做推理系统的人的视角，拆一下这条技术路线背后的逻辑：为什么推理场景敢把HBM换掉、480GB大显存到底解决了什么问题、对我们做部署规划的时候有什么实际参考价值，以及我个人对这条方向的看法。
1. 这条披露到底说了什么：一份专门照着推理痛点设计的规格
1.1 还原披露中的关键信息
先把这个消息本身的细节捋清楚。按公开披露的信息，英特尔此次展示的这款GPU是明确针对AI推理场景设计的，不是通用训练卡。它的显存配置最高到480GB，而显存介质用的不是HBM，而是更常见的LPDDR5X这类内存方案。关于具体带宽，公开资料里没有给一个特别夸张的数字，但从LPDDR5X的超宽通道规划来推，这个方案的带宽量级大概在1TB/s到2TB/s之间，远低于HBM3E最新的4TB/s级，但又不是完全不够用的水平。
"不用HBM"这几个字，我看下来并不觉得是什么技术妥协，更像是深思熟虑后的取舍。从产品定义上，这款卡把显存容量摆到了核心位置，用更大的容量去换一个更低的单位成本，同时把目标负载锁定在"大模型常驻显存+高并发推理"这个方向上。它刻意避开了和HBM训练卡拼峰值带宽的赛道，因为推理服务器里真正影响体验的瓶颈，从来都不是那个峰值数字。
1.2 这个规格精准打到了推理场景的三处痛点
第一个痛点，模型权重驻留问题。现在主流开源大模型动辄几十B到上百B参数，哪怕是FP8精度，70B模型也要70GB，405B模型算下来接近400GB。以前用HBM卡，单卡容量普遍撑在80GB或192GB，想跑大模型要么做张量并行拆多卡，要么用offload把权重往CPU内存搬，速度损失很大。480GB显存意味着绝大多数模型可以一次性完整塞进GPU，不用拆、不用搬，这对推理系统的简洁度提升不是一点半点。
第二个痛点，KV Cache膨胀问题。推理过程中每个token都要维护一组Key和Value缓存，这玩意儿和序列长度、并发请求数线性相关，甚至在某些长上下文场景下，KV Cache的大小会超过模型权重本身。显存容量如果不够，系统就只能被迫压缩batch size或者限制上下文长度，这两种操作都会直接损害吞吐和用户体验。480GB给了KV Cache足够的呼吸空间，128并发、8K上下文的场景也能从容应对。
第三个痛点，显存成本问题。HBM的每GB成本高出普通内存好几倍，而推理服务器的显存需求又远远比训练服务器大，成本压力会被急剧放大。这款卡把显存介质换成LPDDR5X，单位容量成本大幅下降，整卡TCO才能压到用户愿意大规模采购的区间。
2. 推理GPU为什么敢和HBM说再见：访存模式的底层差异
2.1 HBM不是过剩，是"训练特化"的产物
要理解这个决定，得先搞清楚HBM到底强在哪、贵在哪。HBM的全称是高带宽内存，它通过3D堆叠DRAM颗粒，再借助硅中介层和GPU die封装在一起，本质是用极高密度的互连换极高的带宽。HBM3E单颗就能提供TB/s级别的带宽，这是训练大规模模型时非常依赖的特性，因为训练过程里有大量的张量并行、梯度同步和矩阵乘累加，需要喂给计算单元极快的数据吞吐。
但HBM的代价也很直白。3D堆叠良率控制难，硅中介层的成本高，整个2.5D封装流程复杂，而且HBM产能一直被几家头部存储厂商垄断，价格谈判空间很小。一颗训练卡里，HBM的成本能占到整卡很夸张的比例。过去没有人在意这个成本，是因为训练卡本身算力极其昂贵，HBM只是配套。但到了推理场景，算力价格迅速下行，内存成本问题就浮出水面了。
2.2 推理场景的算力/带宽比截然不同
推理和训练的访存模式有个本质差异。训练是一次性处理大批量数据，每个权重可以被反复用很多次，属于"算得多读得少"的负载；而推理的生成阶段（decode）是逐token输出的，每生成一个token，理论上都要把所有权重从显存里完整过一遍。
这里就产生了一个关键指标，算术强度，也就是每个字节的数据被读取后能支撑多少次数学运算。用70B模型FP8精度来算，权重文件大约是70GB，每次decode的浮点计算量近似是2乘以参数量，也就是140 GFLOPs。算术强度等于140 GFLOPs除以70GB，刚好是2 FLOPs/Byte。
这个数字意味着，如果只跑单请求，再牛的HBM带宽也撑不住算力跑满。H100的HBM带宽约3.35TB/s，按这个算术强度推算，单路decode的最大吞吐也就是每秒不到五十个token。而如果换成带宽约600GB/s的LPDDR5X方案，单路decode就只有每秒几个token，这就是硬差距。
但推理服务器从不是只跑一个请求。当batch size提升到128时，权重还是那70GB，但每次读取能支撑的运算就变成了2乘以批大小，算术强度直接变成256 FLOPs/Byte。这时候600GB/s的内存带宽足以支撑约150 TFLOPs的等效计算能力，用来跑70B模型的批量推理绰绰有余。一句话总结：推理场景可以牺牲峰值带宽，但需要用大batch和足够大的显存容量来摊薄权重读取成本。英特尔这步棋，恰恰是把赌注压在了这个逻辑上。
2.3 不用HBM后，牺牲了什么，换来了什么
当然，没有免费的午餐。去掉HBM，首先牺牲的就是单请求延迟。如果碰到不能合并的低并发场景，比如必须把batch压到1的时候，这类卡的decode速度确实比HBM卡慢不少。其次是首token时延，预填充阶段对带宽需求也高，显存带宽不够会让首token出现明显卡顿。
换来的东西更多。最直接的是容量，480GB对HBM卡几乎是一个遥不可及的数字，目前主流训练卡的HBM容量顶多在192GB到288GB区间，再往上堆，成本和良率都难以承受。其次是成本，LPDDR5X和HBM在每GB成本上的差距不是小数目，同容量下能节省出一大笔预算。再就是供应链稳定性，HBM的产能紧张是行业常态，而LPDDR5X这类成熟制程的内存颗粒供应要宽松得多，量产交付的确定性更高。
所以这个取舍的本质是：用一些峰值带宽换来了容量和成本，使产品能覆盖推理场景里占绝大多数的批量并发、长上下文和高吞吐需求，而不是去死磕低并发、超高带宽那一小段性能指标。
3. 480GB显存的推理账本：成本、功耗、供应三者如何平衡
3.1 每GB成本：HBM的贵族逻辑 vs 大容量平民逻辑
聊完技术原理，算算经济账。HBM的单价长期维持在普通DRAM的数倍以上，再加上封装测试成本，整卡显存的价格非常可观。而LPDDR5X是消费级和移动市场大规模量产的内存，供应链成熟，成本低很多。行业里普遍按单颗颗粒容量来估算，如果用4GB单颗的LPDDR5X，攒到480GB需要120颗，这个颗粒数看着吓人，但单颗成本远低于HBM的堆叠晶粒，总体成本依然可控。
内存方案对比大致如下：
| 内存方案 | 带宽量级 | 单GB成本 | 功耗量级 | 容量扩展性 |
|---|---|---|---|---|
| HBM3E | 3TB/s~7TB/s | 很高 | 高 | 受限（封装面积与良率制约） |
| LPDDR5X | 0.5TB/s~2TB/s（视位宽配置） | 中低 | 中 | 优秀（颗粒多，堆叠灵活） |
| GDDR7 | 1TB/s~2TB/s | 中 | 中 | 中 |
训练卡不在乎HBM的成本，因为训练任务对带宽的渴求太强烈，没有HBM根本无法工作。但推理卡不一样，推理任务里用户付费买的是token吞吐和时延，不是峰值算力，所以每一分硬件成本都要转化成实际服务能力才值得花。480GB LPDDR5X方案把一个训练卡上想都不敢想的容量，放到了推理用户买得起的价位上。
3.2 容量对并发和吞吐的直接影响
显存容量在推理服务里，是决定并发上限和batch size的天花板。batch size一旦受限于显存无法撑大，前面提到的算术强度优势就发挥不出来。更直接的表现是KV Cache的占用，我按一个常见72B模型算过笔账：80层、8个KV头、128维head_dim，FP16精度下，每个token大约需要320KB的KV Cache。单条8192 token的请求大约就要2.7GB，如果并发128个这种请求，KV Cache总量大约343GB。
放到80GB的HBM卡上，这个负载根本没有讨论空间。而放在480GB的推理GPU上，权重占掉72GB（FP8），KV Cache占掉343GB，还能留下几十GB的缓冲余量，可以跑得非常从容。这就是480GB最大的现实意义：它允许推理系统用最朴素的方式做高并发，不需要为了让模型塞进显存而做各种复杂的显存碎片管理、批量换入换出、激进子图调度。运维复杂度直线下降，稳定性却明显上升。
3.3 功耗与部署形态的变化
HBM不仅贵，功耗也不低。一颗HBM3E堆叠的功耗能达到十瓦到几十瓦量级，整卡好几个堆叠，这部分热量都要靠服务器散热系统带走。LPDDR5X的能效比明显更好，虽然超宽位宽方案下内存子系统总功耗也不会太低，但相比HBM仍然有可观的节省空间。
对数据中心来说，省下的功耗意味着机柜里可以部署更多GPU，也意味着供电和散热压力下降。推理服务是典型的7x24小时长时间运行负载，功耗优势会直接体现在电费账单上。这对那些动辄数千卡规模的推理集群来说，省下的是一个非常可观的运营成本。
4. 对实际部署者来说：显存预算怎么重新算
4.1 模型显存的经典估算公式
如果要真正落地评估，第一步是掌握显存估算方法。模型权重的显存占用很简单：
权重显存 = 模型参数量 × 每个参数的字节数
- FP32精度：4字节
- FP16/BF16精度：2字节
- FP8精度：1字节
举几个例子，8B模型FP16权重约16GB，72B模型FP8权重约72GB，405B模型FP8权重约405GB。这部分是基础开销，跑都跑不掉。
然后是KV Cache的估算公式：
KV Cache大小 = 2 × KV头数 × head_dim × 层数 × 序列长度 × batch size × 每个元素的字节数
按前面那个72B模型算，2 × 8 × 128 × 80 × 8192 × 128 × 2字节，这个数值大约就是343GB。量化KV Cache到FP8可以减半到约171GB，但即使这样，普通卡也装不下。
4.2 从"显存不够"到"显存够了"的运维变化
过去为了在80GB或192GB的显存里跑大模型，部署团队习以为常的做法是：先做AWQ或GPTQ量化，剪到INT4精度；再不行就把部分层offload到CPU内存，靠PCIe来回搬运；还要上多卡张量并行，用NVLink或PCIe把模型切到好几张卡上。每一个操作都在牺牲时延或者增加系统复杂度，部署一个模型往往要调好几周。
如果换成480GB大显存卡，很多妥协就不必做了。权重用FP8甚至BF16精度直接放显存，KV Cache预留足够空间，推理引擎的显存规划变得简单直接。我在实际调优中体会到，显存越充足，vLLM这类推理框架的调度器就越不容易触发显存不足导致的重算，preempt（抢占）次数减少，线上服务的P99时延也会明显改善。
但"显存够了"不代表万事大吉。这类大显存卡的带宽相对有限，如果并发上不去、batch size撑不满，单请求decode速度还是会偏慢。所以部署时还是需要把beam search、动态批处理、continuous batching这些特性打开，用软件调度把内存带宽用满。另一件要注意的事是推理引擎的适配，并不是所有框架都对LPDDR5X这类内存方案的卡做了完整优化，跑之前要确认算子库和显存管理逻辑是否支持。
4.3 选型判断：多大的显存、多高的带宽适合你
选卡不是看参数，而是看你的负载形态。纯看模型规模和并发需求，可以画个大致的判断框架：
- 主要跑1到8B小模型，且需要极低时延响应，HBM卡依然有优势，带宽高，首token快。
- 主要跑30B到100B级别模型，单用户并发几十到几百，480GB这类大显存卡非常合适。
- 主要跑200B以上超大模型，且要求极高的单流吞吐，可能还是需要多卡并行加HBM方案，或者等这类卡生态成熟后再考虑。
换句话说，英特尔这款GPU瞄准的是推理市场里份额最大、需求最普遍的"中等偏上模型+高并发"区间，它不需要赢得所有场景，只需要在一个大市场里做到最优性价比就够了。
5. 我的一点观察和实操建议
从整个行业趋势来看，HBM近两年被热炒，似乎已经成了高端AI芯片的标配。但英特尔这个披露点醒了一件事：芯片设计最终要回归负载本身的特性。推理不是训练，它的算术强度完全可以用更大的batch和更充裕的显存容量来弥补带宽短板。谁先看清楚这一点，谁就在推理成本战中拿到了主动权。
我对这套方案落地前的几个观察供参考：
第一，软件生态是最大变量。硬件规格再好看，如果推理框架、算子库、驱动工具链跟不上，用户根本用不起来。英特尔在AI软件栈上的积累相比头部对手还有差距，这是决定这款产品能否真正打开局面的关键。
第二，带宽瓶颈会在某些负载下显现。如果你做的是大并发但序列极短的请求场景，比如一些实时交互应用，这类卡的带宽劣势会被放大。建议在采购前一定要拿自己的真实业务流量做压力测试，不要只看模型能不能装进显存，还要看实际吞吐能不能达标。
第三，大显存对运维是双刃剑。显存大了，能跑的模型变多，但也意味着故障爆炸半径变大。以前80GB显存不够，模型分布在几张卡上，坏一张卡影响面有限；现在一个480GB实例挂了，影响的是整个大模型服务。部署时要把单卡故障切换、模型快照、状态恢复这些机制提前做好。
结合我自己过去的部署经验，这类"大容量、中带宽"的推理卡，非常适合那种需要把多个模型常驻显存、用高并发换取吞吐的场景。如果英特尔后续能在软件栈上补齐短板，这套思路可能会带动整个推理硬件市场重新定位，倒逼其他厂商也不得不认真考虑"不用HBM"的路线。至于最终市场反馈如何，还得等产品真正量产、被真实负载检验过之后，才能下结论。
