大模型推理优化：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的实际状态，有个习惯可能不值钱但对排查问题很有效：每次都看UNC（Uncached）内存那段，如果它持续高位，基本可以判断访存陷入了等待，这时候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通常有几类设计，我分别评估了一下它们适合使用的场景：

实操维度上，我们团队在昇腾芯片上调过几个模型，第一感觉是"芯片本身并不弱"，真正的成本在适配。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从单卡独占改成多芯共享，又把调度器从简单的先来先服务换成分层优先级，最后整体吞吐提升了一倍多，功耗几乎没涨，单卡利用率反而看着"变低了"。那一次给我的启发很大，也更让我确信：推理侧的未来，属于那批愿意把架构、调度、存储和算法放在一起综合考虑的人，而不是单纯在算力上堆料的团队。