一句话定义
加速比迁移性指一个推理优化在某个平台上测出来的加速比，能不能搬到另一个平台上继续成立。
arXiv 上有一篇 2026 年 10 月的工作（编号 2610.31479）把它当成正经问题来测：挑四类在服务器 GPU 上被反复验证过的优化，放到 Apple Silicon 上重跑一遍，看哪些收益还在、哪些直接变成负数。结论不是「这些优化没用」，而是——加速比不是技术自身的属性，而是技术、运行时、硬件契约、负载形态四者共同的函数。
它解决什么问题
端侧选型最常犯的错，是把别人在服务器上测出的倍率，直接当成自己设备上的预期。
服务器推理和端侧推理是两种负载，不是同一件事的两种规模：
| 服务器批量服务 | 端侧单机推理 | |
|---|---|---|
| 同时在跑的请求 | 几十到几百 | 常常只有一路 |
| 瓶颈 | 总吞吐、显存、请求调度 | 单条请求的时延、内存带宽 |
| 优化在追什么 | 每秒多服务几个请求 | 这一路什么时候出结果 |
批量服务里很多机制成立的前提，是「同时有很多请求可以拼在一起算」。到了只有一路的解码场景，这个前提消失了，机制本身就没有用武之地——不是实现得差，是它要解决的问题不存在。
关键做法
那篇论文的实验设定值得照着抄：四台 Apple 机器、统一的单请求解码负载、能对上的地方配 RTX 4090 做对照，四类优化分别是 KV 缓存剪枝、投机解码、移植过来的 GPU kernel、训练后量化。
结果按类看：
- KV 缓存剪枝：在 Apple 上最多做到 1.75 倍端到端吞吐，但在桌面 NVIDIA GPU 上可能反而降低吞吐。同一个方法，两台机器上符号相反。
- 投机解码：评测到的所有方法在 Apple 上都是降速的；而同类方法在服务器 GPU 上报的是 2–6 倍。原因还是负载形态——投机解码靠「一次猜几个、猜中就省几次」来摊薄开销，单请求、batch 为 1 时这笔账算不过来。
- 移植 GPU kernel：只能部分迁移。公开可用的 Metal 没有异步拷贝，batch 为 1 的解码又让不少面向批量服务的机制失效；能迁移的那部分最多带来 1.20 倍解码吞吐。
- 训练后量化：收益随机型变化。
四条合起来说明一件事：优化的收益挂在硬件契约和负载形态上。硬件契约是这颗芯片暴露给你什么能力——有没有异步拷贝、有没有某种精度的乘加单元、内存和计算是不是共享同一套；负载形态是你实际怎么用它——一路还是多路、预填为主还是逐字解码为主。
方法论上还有一个收获：把这四个变量分开看，比笼统地说「端侧慢」有用得多。谈一个优化时，先问它在什么硬件契约下、跑什么负载形态，再谈倍率。
用不上的时候
- 别把它读成「这些优化都不行」。 论文测的是 Apple Silicon 上的单请求解码。换成安卓盒子、换成带 NPU 的 ARM 板、换成多路视频并发，排名会变。它给的是方法：换平台就重测。
- 加速比不能替代绝对时延。 基线本来就慢的时候，2 倍也可能仍然不能用；基线快的时候，1.2 倍已经足够。能不能上线看的是压完之后的毫秒数，不是倍率。
- 优化之间会互相打架。 剪枝省下的计算，可能让另一项优化失去可并行的空间。两个「各自 1.5 倍」叠在一起，得到的很少是 2.25 倍。
- 别把服务端的数字写进端侧的验收单。 这是最常见的一类扯皮：指标是真的，测的环境不是你的环境。
参考
arXiv:2610.31479，Evaluating the Applicability of LLM Inference Optimizations on Apple Silicon（2026-10-22）。四台 Apple 机器、统一单请求解码负载，评测四类优化（KV 缓存剪枝、投机解码、GPU kernel 移植、训练后量化），可比条件下对照 RTX 4090。KV 缓存剪枝在 Apple 上最高 1.75 倍端到端吞吐、在桌面 NVIDIA GPU 上可能降速；所评测的投机解码方法在 Apple 上全部降速（服务器 GPU 上报 2–6 倍）；可迁移的 kernel 部分最多 1.20 倍解码吞吐；量化收益随机型变化。作者据此主张：报告的加速比取决于技术与运行时、硬件契约、负载形态的联合。
延伸阅读
- 供应商说快了三倍，装到店里为什么没感觉 —— 这篇讲的是这件事对门店意味着什么。
相关词条
火眼识别提供端侧视觉引擎与设备管理平台，相关方案见 火眼识别官网。