你把一家餐厅的菜谱精简了，后厨未必就能更快出菜。厨具是否顺手、服务员怎样并桌、门口如何排号，都会改变客人最终等多久。部署 AI 也是如此：模型变小，只解决了“菜谱”这一层；编译器能不能把变化转成芯片上的效率，服务系统怎样安排请求，同样会左右结果。
Tejinder Singh 等人的论文《Optimizing AI Inference Across the Deployment Stack》试图把这几笔账放进同一个框架。它关注的不是又一种压缩算法，而是一个更基础的问题：为什么实验里看起来更快的模型，到了真实服务中未必更快？论文认为，推理部署的结果由模型压缩、编译变换和服务策略之间的交互共同塑造，孤立分析其中一层，无法可靠预测整体表现。
需要先说明，本文依据的是论文在 arXiv 公布的摘要材料。摘要没有列出所考察框架与服务引擎的名称，也没有披露延迟、吞吐、能耗或精度变化的具体数字。因此，这项工作的价值目前主要体现在分析框架和评测规范，而不是某组可以直接引用的性能纪录。
三层优化，其实是一条链
论文把部署优化分成三层。
第一层是模型。这里包括量化、剪枝和蒸馏。量化是用较低精度表示模型中的数字；剪枝是删去部分参数或计算；蒸馏则让较小的模型学习较大模型的能力。它们都能减少模型体积或计算量，但“计算更少”不自动等于“运行更快”。软硬件如果不擅长执行压缩后的结构，纸面收益就可能无法兑现。
第二层是编译器。AI 编译器负责把模型的计算步骤整理成硬件更容易执行的形式。论文列出图融合、数据布局优化和算子自动调优。图融合会把相邻计算合并，减少中间步骤；数据布局优化会调整数据在内存中的排列；算子自动调优则为具体硬件寻找更合适的执行方式。编译器像后厨的工作台：菜谱写得再简洁，动线不顺仍然会拖慢出菜。
第三层是系统。它包括动态批处理、准入控制和内存分层。动态批处理会把同时到达的多个请求拼在一起执行；准入控制决定何时接收或暂缓请求；内存分层则安排数据放在哪一级存储中。它们属于服务策略，决定请求怎样排队、拼批和使用硬件。
这三层不能各自结算。例如，量化可能降低单次计算量，但最后能省多少时间，还取决于编译器有没有合适的实现、数据搬运是否成为瓶颈，以及服务系统在高负载下如何拼批。论文的核心判断正是：部署性能不是单项优化效果的简单相加。
不能只问“快了多少”
作者把部署选择写成一个受约束的多目标优化问题。所谓多目标，是因为团队通常同时关心五件事：准确率、延迟、吞吐量、内存占用和能耗。延迟是一个请求要等多久；吞吐量是单位时间能处理多少请求。两者并不相同：把更多请求拼成一批，可能提高总处理量，却让其中一些请求等得更久。
“受约束”也很重要。真实选择往往不是找一个所有指标都最高的方案，而是在底线之上做取舍：准确率不能低于要求，内存不能超过设备容量，响应时间还要落在业务可接受的范围内。
论文进一步分析了一种部署排序函数，用来综合比较候选方案。它具备 Pareto monotonicity 和 scale invariance。前者可以通俗理解为：如果方案 A 在所有关注的指标上都不差于方案 B，并且至少一项更好，排序不应反过来偏爱 B。后者指改变指标的计量尺度，不应无端改变方案的相对次序。这是在给“综合评分”设基本规矩，避免权重和单位把结果带偏。
硬件瓶颈和排队效应会改写答案
为了说明跨层影响，论文引入了两类模型。
Roofline model（屋顶线模型）用来判断程序更受计算能力限制，还是更受内存带宽限制。内存带宽可以理解为芯片搬运数据的速度。模型换用较低精度后，计算和数据量会改变，但性能上限仍可能被不同层级的内存带宽卡住。也就是说，压缩带来的理论计算优势，未必能按同样比例变成实际加速。
Queuing model（排队模型）则解释服务负载的影响。请求较少时，单次服务时间缩短一点，用户感受到的改善可能接近这个幅度；系统接近繁忙状态时，同样的变化还会影响后续请求的排队长度，最终响应时间可能被进一步放大。反过来，一点额外开销也可能在高负载下形成更明显的等待。
这也是论文反对脱离条件比较跑分的原因。一个延迟数字背后，可能藏着不同硬件、软件版本、批次定义、并发负载和散热状态。数字看起来可以并排，实际回答的却未必是同一个问题。
先统一证据，再谈冠军
论文提出了一套证据协议，把论断分为三类：measured claims 是直接测量的结果；derived claims 是根据测量值计算出来的结果；analytical claims 则来自模型或理论分析。三类证据可以互相支持，但不能混作同等性质的实测数据。
协议还要求，数值比较限于同一篇论文内部，并明确报告硬件、软件版本、batch semantics 和 thermal state。batch semantics 指“一个批次”究竟如何定义和执行；thermal state 是设备测试时的温度与散热状态，因为设备是否因温度而限制性能，会影响结果。
作者综合考察了 Jetson AGX Orin 边缘平台上的五种推理框架、A100 与 H100 数据中心 GPU 上的三种大语言模型服务引擎，以及 Llama-3.1 系列的量化研究。不过摘要没有给出这些框架和引擎的具体名称，也没有提供可复述的性能数字。论文自己也强调公开 benchmark 的条件经常不可比，因此这里不宜把不同研究的数据直接排成排行榜。
为什么值得关注
这项工作的现实意义，是把部署决策从“挑一个最高分”改成“在约束下选一套组合”。模型团队、编译器团队和服务团队各自交出漂亮数字，并不能保证最终系统同样漂亮。真正需要评估的是整条链：某种压缩方法落到特定编译实现，再进入特定负载与调度策略后，准确率、响应速度、容量、内存和能耗怎样一起变化。
这也为 benchmark——用于比较系统表现的标准测试——提出了更严格的要求。一个数字如果缺少运行条件，参考价值可能很有限。论文的证据协议未必立刻解决行业中的可比性问题，但它至少把“比较前先对齐什么”说清楚了。
局限与未知
- 目前材料只有这一篇论文的单一信源。“跨层交互决定结果”“单层分析无法预测整体表现”是作者的综合结论，其适用边界还无法从现有材料中独立验证。
- 摘要未披露五种推理框架、三种服务引擎的名称，也没有具体性能数据，无法判断各层交互的实际幅度。
- 作者把编译器与服务系统的协同优化、跨硬件性能预测和标准化能耗报告列为开放问题。这说明统一框架已经提出，但若要形成可复用的行业评测方法，仍有不少工作要做。