ARTICLE DETAIL

资讯详情

深耕网站视觉设计与运营推广的一线实战洞察。

推理GPU告别HBM:480GB大显存如何破解大模型部署难题

推理GPU告别HBM:480GB大显存如何破解大模型部署难题 推理服务器的选型这几年我一直有个很深的体会在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模型也要70GB405B模型算下来接近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成本功耗量级容量扩展性HBM3E3TB/s~7TB/s很高高受限封装面积与良率制约LPDDR5X0.5TB/s~2TB/s视位宽配置中低中优秀颗粒多堆叠灵活GDDR71TB/s~2TB/s中中中训练卡不在乎HBM的成本因为训练任务对带宽的渴求太强烈没有HBM根本无法工作。但推理卡不一样推理任务里用户付费买的是token吞吐和时延不是峰值算力所以每一分硬件成本都要转化成实际服务能力才值得花。480GB LPDDR5X方案把一个训练卡上想都不敢想的容量放到了推理用户买得起的价位上。3.2 容量对并发和吞吐的直接影响显存容量在推理服务里是决定并发上限和batch size的天花板。batch size一旦受限于显存无法撑大前面提到的算术强度优势就发挥不出来。更直接的表现是KV Cache的占用我按一个常见72B模型算过笔账80层、8个KV头、128维head_dimFP16精度下每个token大约需要320KB的KV Cache。单条8192 token的请求大约就要2.7GB如果并发128个这种请求KV Cache总量大约343GB。放到80GB的HBM卡上这个负载根本没有讨论空间。而放在480GB的推理GPU上权重占掉72GBFP8KV Cache占掉343GB还能留下几十GB的缓冲余量可以跑得非常从容。这就是480GB最大的现实意义它允许推理系统用最朴素的方式做高并发不需要为了让模型塞进显存而做各种复杂的显存碎片管理、批量换入换出、激进子图调度。运维复杂度直线下降稳定性却明显上升。3.3 功耗与部署形态的变化HBM不仅贵功耗也不低。一颗HBM3E堆叠的功耗能达到十瓦到几十瓦量级整卡好几个堆叠这部分热量都要靠服务器散热系统带走。LPDDR5X的能效比明显更好虽然超宽位宽方案下内存子系统总功耗也不会太低但相比HBM仍然有可观的节省空间。对数据中心来说省下的功耗意味着机柜里可以部署更多GPU也意味着供电和散热压力下降。推理服务是典型的7x24小时长时间运行负载功耗优势会直接体现在电费账单上。这对那些动辄数千卡规模的推理集群来说省下的是一个非常可观的运营成本。4. 对实际部署者来说显存预算怎么重新算4.1 模型显存的经典估算公式如果要真正落地评估第一步是掌握显存估算方法。模型权重的显存占用很简单权重显存 模型参数量 × 每个参数的字节数FP32精度4字节FP16/BF16精度2字节FP8精度1字节举几个例子8B模型FP16权重约16GB72B模型FP8权重约72GB405B模型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的路线。至于最终市场反馈如何还得等产品真正量产、被真实负载检验过之后才能下结论。
返回列表