大模型推理优化:GPU、ASIC与存算一体的协同之道

大模型推理优化:GPU、ASIC与存算一体的协同之道 推理侧的卡点我是在一次压测里彻底想明白的。当时一台装满H系列的服务器GPU利用率跑出了30%出头的数字显存倒是快满了单个请求的延迟看着也还行可一旦把并发拉上去响应时间直接出现断崖式恶化。调度同事的第一反应是多开几个实例分摊压力结果开出来发现显存撞墙新请求根本塞不进去。那一刻我就意识到推理侧的优化跟训练完全是两码事——训练拼的是算力能不能喂饱推理拼的是存储、带宽、调度、硬件协同能不能跟上。这篇文章就是想把这几年在推理侧摸爬滚打的思路、踩坑和一些不太容易在公开资料里看到的东西系统性地整理出来。适合正在做推理服务化、模型部署、硬件选型或者关注大模型成本优化的工程师。核心围绕三件事展开GPU在推理场景的真实位置是什么、ASIC和存算一体到底能不能补上GPU的短板、多芯协同在实际调度中应该怎么落地。1. 推理侧到底发生了什么1.1 从训练思维到推理思维的转变先说一个很多人忽略的事实训练和推理的计算模式是两种完全不同的人。训练阶段数据是批量流式进入的权重在迭代更新矩阵乘法的规模非常大算力利用率天然容易打满。推理阶段恰恰相反单条请求的计算量小但每一步都要依赖前一步的结果——这就是典型的串行依赖GPU的并行优势在单请求表现上根本发挥不出来。我在实测里对比过一个7B量级模型的训练和推理表现训练时GPU利用率能稳定爬到90%以上推理时同一张卡、同样的算力峰值单请求利用率经常只有5%到10%。这不是适配问题这是计算本质决定的。训练是把数据灌满算力推理是把结果快速吐出来前者舍得花时间后者抠的是每个token的延迟和成本。所以现在看推理侧选型我会先用一句话判断方案合不合理它是在压算力上限还是在压访存和调度效率如果答案放在前者那基本跟推理的实际问题错位了。1.2 推理侧的价值判断变了推理成本的核心已经不是FLOPS了而是三点单token延迟、吞吐能压到多少、在限定显存/功耗下能同时处理多少请求。这三点的优先级在不同场景里完全不一样。线上交互式对话单token延迟是生命线首token拖到2秒以上用户基本就跑了离线批量任务吞吐优先宁可单任务慢一点也要把单位时间处理量顶上去端侧或者边缘部署功耗和物理体积排在功耗前面算力反而不是主要矛盾。实际做工程的人还要面临第四个隐形成本运维还有开发适配成本。这也是ASIC、存算一体这类新架构落地时遇到的普遍阻力——硬件参数再漂亮如果软件栈不成熟部署一个模型要折腾几周那我宁可用老方案顶着。这个问题我会在后面的章节展开因为它直接决定了新一代推理硬件能走多快。2. GPU在推理侧的演进路径2.1 制程红利减弱GPU在推理上靠什么硬撑先给GPU说句公道话它在推理侧的地位短期内仍然稳固但稳固的原因已经不是芯片算力本身了。算力提升这两年在明显变慢。摩尔定律在先进制程上逼近物理极限时钟频率基本到头了每年提升主要靠架构修修补补和更聪明的tensor core。可推理侧的瓶颈从来不是算力所以就算GPU算力再翻一倍如果你的程序受限于显存带宽用户感受到的加速也只有几个百分点。GPU真正的护城河我认为是生态。CUDA累积了十几年深度学习框架、推理引擎、算子库、加速工具链全部默认优先支持NVIDIA——这个生态沉淀意味着换个硬件就能跑在短期内根本不现实。所以就算我们明知道ASIC在某些场景下能效比更好工程上也会先做兼容评估而不是直接推翻现有技术栈。2.2 GPU在推理上的真实效率和核心操作我在生产环境里经常用nvidia-smi看GPU的实际状态有个习惯可能不值钱但对排查问题很有效每次都看UNCUncached内存那段如果它持续高位基本可以判断访存陷入了等待这时候GPU利用率再高也可能只是一个忙等的空转。推理侧要让GPU跑得稳几个常规但重要的操作绕不开。第一个是算子融合把多个细粒度算子合并成一个大算子减少kernel launch次数——这个显著降低CPU调度开销比单纯堆算力管用得多。第二个是tensor shape固定动态shape会让推理引擎反复做重编译和memory plan延迟抖动得很厉害用固定shape能把大部分中期优化提前做好。第三个是使用TensorRT-LLM或vLLM这类专为推理优化的框架它们内置了continuous batching和PagedAttention这类技术可以让适配请求次第嵌入gap而不是排队等整批跑完。实测下来vLLM这类框架在大并发场景下吞吐能比朴素的逐请求推理提升3到5倍这是非常可观的数字而且不需要改模型结构。GPU在推理侧的头号价值其实就是用成熟生态软件优化把现有硬件榨干而不是等下一代卡。3. ASIC的推理专精化专用才高效3.1 为什么推理跑不进通用芯片ASIC进入推理视野是因为前面提到的那个脉冲突出问题变得足够有必要了。大模型爆发之后推理请求量呈指数级增长功耗和成本压力让大厂开始思考凭什么拿一块重型通用卡去处理一些模式化程度极高的矩阵乘法和注意力计算ASIC的核心逻辑就是把结构省到极致。它把算法映射成固定电路运行时没有指令解码、没有分支预测、没有通用缓存管理所有资源都集中在乘加阵列和片上存储上。同等功耗下ASIC的算力能做得很高时延也低因为没有大量折腾硬件的系统开销。3.2 架构差异带来的实际影响从架构来看推理ASIC通常有几类设计我分别评估了一下它们适合使用的场景架构类型代表方向优势限制脉动阵列式谷歌TPU矩阵乘能耗比极高灵活性偏弱非矩阵运算兼容度低近存计算式各类带大容量SRAM的推理芯片权重读取功耗显著降低编程门槛偏高数据流式部分NPU架构算子级流水线吞吐高动态调度能力不足类脑/稀疏加速部分国内AI芯片稀疏场景能效极优通用场景适配周期长实操维度上我们团队在昇腾芯片上调过几个模型第一感觉是芯片本身并不弱真正的成本在适配。PyTorch的模型要先过一遍自带的迁移工具很多算子需要手写TBE表达式知识蒸馏之外还得做一遍自定义算子适配这个时间周期比想象中长。但如果业务稳定、请求量大、模型版本少一次适配的投入过几个月就能通过更低的单位推理成本收回来。3.3 ASIC降本的两个层面ASIC真实的价值不只是省电这一个层面。第一个层面是单次推理成本大幅下降同等功耗下算力高单价电费分摊到每token更低第二个层面也是容易被忽视的层面——单位物理空间内能塞进更多的算力机房密度上来了租金、空调、运维综合成本都可能被摊薄。我做过一个粗略的估算同样支撑100路并发的大模型推理服务纯GPU方案和混合ASIC方案在一年周期内硬件采购加电费的综合成本差距可以到2倍以上。这里有个前提请求规模必须够大不然ASIC的固定适配成本根本摊不回来。说白了ASIC适合的场景是量大管饱的常态化推理不适合三天两头变模型尺寸和结构的研究型业务。4. 存算一体把数据搬运算的账算回来4.1 冯诺依曼瓶颈为什么在推理里特别醒目之前几次做性能剖析我最大感触是推理的根本矛盾不是算得慢而是搬得慢。模型权重、激活值、KV Cache都要在存储和计算单元之间反复搬运带宽有限搬运时间直接暴露在延迟里。这背后的原理是经典的memory wall——处理器速度增长远快于内存带宽增长二者差距到了一定程度算力只能干等数据。我团队做过一次实验把同一个模型的推理任务切换成纯内存密集型的profiling模式观察发现计算单元空闲等待时间差不多占了总执行周期的六成。这不是单张卡的问题是整个冯诺依曼结构在推理场景下的通病。搞存算一体的思路就是要从物理结构上消灭这种搬运成本。4.2 存内计算和近存计算的落地套路存算一体目前大致分成两条路近存计算和存内计算。近存计算相对保守保持存储和计算独立结构只是把两者物理距离拉近让走线的延迟和功耗降下来——3D堆叠的HBM本质上就是走这条路。存内计算更激进直接在存储阵列的位线上挂计算单元矩阵乘法出结果不需要把数据搬出存储体这就是真正意义上的存中算、算中存。从实现形态上看现有存算一体芯片还分了模拟域和数字域。模拟域存算直接把电压、电流当作计算媒介理论能效比极高但精度受噪声影响明显量化位宽做不高数字域存算用电荷共享之类的方式做多位计算精度更稳但芯片面积和功耗会相应上去。目前推理侧主流落地还是数字域方案多因为它相对容易把INT8甚至FP16的精度撑起来。4.3 存算一体的真实受众和现状老实说存算一体在大模型云端推理这块目前还处于能跑通、不够好用的阶段。它更早落地的场景应该是边缘侧和嵌入式侧——typ边缘的视觉模型、端侧语音识别、机器人推理这种模型尺寸不大、但实时性要求极高、功耗约束又很严的地方存算一体靠省掉搬运的优势能把能效比拉到通用方案的5到10倍。我在评估存算一体方案时特别关注的几个点是精度损失能不能控制在应用可接受的范围、编译器能不能把模型无损映射到硬件拓扑上、量产良率带来的成本是不是合理的范围。这三个问题没解决的话存算一体永远只能是好看的技术而不是好用的产品。5. 多芯协同异构资源的编排艺术5.1 异构集群的真实形态光讨论单一架构其实是一条死路。真正的推理基础设施团队现在越来越接受不同芯片干不同活的思路。GPU承担通用性要求高、模型复杂、动态shape多的主力推理ASIC专门承接那些结构固定、调用量大的成熟模型比如某个版本的embedding模型、固定结构的视觉模型存算一体则更适合塞进边缘盒子或者做初步的特征计算尽量在数据入口就把计算消化掉。这套架构里最关键的不是每块芯片本身而是它们之间的协同方式。此时就要谈到两颗容易被人忽略的硬件——PCIe Switch和CXL内存池。PCIe承担最常见的卡间通信延迟低、兼容性好CXL则走的是内存语义可以对异构设备做共享内存式的协同给多芯系统引入一种统一寻址的能力非常适合跨厂商、跨架构资源协作。5.2 KV Cache联合调度多芯协同的核心抓手我做过多芯协同的竞品评测之后发现一个特别有意思的现象很多人以为多芯协同最难的是通信协议其实真正难的是缓存和中间状态的管理。大模型推理的KV Cache是每个请求的临时状态如果多芯之间不能共享KV Cache模型就必须把整条序列的上下文完整搬到另一张卡上搬运成本高得离谱。实操中我采用的优化是KV Cache分级分芯策略。把高频、热门的prefix共同缓存在高速GPU显存里低频但可能有转机的上下文落在ASIC的大容量存储中存算一体单元则负责把本地计算完的局部KV结果做近存合并。这样虽然跨芯通信不可避免但搬运的总量被压缩到最低。实测下多芯集群的整体吞吐比单芯片方案高50%到80%代价是要把调度器做得足够精细。5.3 调度策略是成败关键多芯协同的调度器本质上是个多目标优化问题。既要保证延迟敏感型任务优先拿到最快的芯片又要让吞吐型任务尽量填满ASIC的算力缝隙还要避免存算一体单元过载变成阻塞点。我的实践意见有三条分层调度全局调度器感知模型类型和请求特征决定流量路由到哪种芯片本地调度器负责同芯内部的任务排队和显存/内存分配。预热复用多芯协同下最怕的是频繁启停模型实例把模型常驻在推理框架的进程池里让请求在已加载的模型间切换能节省大量换入换出的时间。链路超时兜底新硬件免不了软件栈不成熟跑挂的概率比GPU高很多调度器必须为每条跨芯链路设计超时和降级策略一旦某个单元异常立即把流量拨回GPU兜底。调度策略这件事做得好的团队能把整体资源效率再往上抬15%到20%做得糙的会掉进越协同越慢的坑里这跟优化经验的关系其实很大。6. 推理未来三年值得关注的方向和选型建议6.1 到底该选谁的芯片这个问题每个来咨询我的人都绕不开。我的答案基本是按业务阶段选。如果你的团队还在快速迭代模型、两天换一个版本老老实实用GPU配合TensorRT-LLM和vLLM这些成熟方案把GPU的软件红利吃透这是性价比最高的路线。如果业务已经稳定下来、请求量开始规模化增长GPU的单位推理成本会越来越刺眼这时候值得立项评估ASIC——但一定要留足适配预算和时间。如果你做的是边缘盒子或者端侧产品功耗和实时性卡得很死那存算一体值得认真评估但优先选成熟度高的近存方案别一上来就冒险用模拟域存算。很多团队犯的错误是先选硬件再规划业务。这个顺序永远是反的——先搞清楚你是延迟敏感型、吞吐敏感型还是功耗敏感型再定芯片方向否则买回来的硬件很多都是浪费的算力。6.2 存算一体和ASIC会取代GPU吗这个问题我目前的判断是短期内不会长期会形成分层共存的局面。GPU凭借生态和通用性会继续占据需要灵活适配的头部推理场景。ASIC会在固定模型大流量的场景里逐步吃掉GPU的一部分地盘因为它确实更省成本。存算一体则会在边缘、嵌入式、端侧场景里扎扎实实扎根因为那些场景对能效比极度敏感容错空间也更大。三类硬件之间会用更成熟的PCIe、CXL和统一调度框架连接在一起形成一种各司其职的推理基础设施。6.3 推理能力的关键衡量指标最后分享一个我判断推理硬件靠不靠谱的方法不只看单卡峰值FLOPS也不只看跑分里的throughput数字而是看一个更实际的东西——单位成本有效吞吐即在指定的延迟约束下一块卡每秒能妥善处理多少请求再把采购、功耗、运维成本全部折进去算。这个指标能戳破很多纸面夸大的宣传。因为推理硬件是要放到真实业务里去扛压的不是放在机房里看参数的。单芯片私吞吐很高但如果并发一高延迟就超时那这个硬化在业务上就不成立电费便宜但适配成本高到团队头大半年内你也不会觉得它便宜。把单位成本有效吞吐作为第一衡量指标选型就简单很多。说起来在我做过的所有推理优化项目里收获最大的一次恰恰是最不依赖GPU算力的一次。我们把模型量化精度从FP16换成INT8把KV Cache从单卡独占改成多芯共享又把调度器从简单的先来先服务换成分层优先级最后整体吞吐提升了一倍多功耗几乎没涨单卡利用率反而看着变低了。那一次给我的启发很大也更让我确信推理侧的未来属于那批愿意把架构、调度、存储和算法放在一起综合考虑的人而不是单纯在算力上堆料的团队。