语音助手若停顿三秒，用户会以为它没听懂；代码补全若等到思路已经改变才出现，也失去价值。实时 AI 的体验，不由一个笼统的“每秒多少词”决定，而由请求进入系统后的一整段时间线决定。
AI21 的 Jamba 系列采用 Transformer、Mamba 状态空间模块和混合专家结构，为长上下文推理提供了一条不同于纯 Transformer 的路线。但架构效率只是起点，真实服务还要处理排队、缓存、批处理、网络和输出调度。
## 先把延迟拆成几个阶段
首字延迟是从用户提交到看到第一个输出的时间。它包含排队、输入处理和第一次解码。词间延迟描述后续输出是否流畅，总完成时间则决定任务何时真正结束。
三者可能相互冲突。系统积累更多请求后统一批处理，可以提高吞吐量，却会让早到的用户等待。输出流很快也不代表首字快，长文档的输入预处理可能早已耗去大部分时间。
因此，监控至少要区分预填充和解码。预填充一次处理全部输入，长上下文时计算密集；解码每次生成新 token，并反复读取历史状态，更受内存带宽影响。
## 混合架构为何值得关注
Transformer 的注意力能直接比较序列中不同位置，但保存和读取键值缓存会随上下文增长。Mamba 一类状态空间模型用压缩状态递归处理序列，在长上下文中具有不同的内存特性。
Jamba 将两类模块交错：注意力层保留精确检索和跨位置交互，Mamba 层承担高效序列建模，部分层再用混合专家扩大总容量而不激活全部参数。AI21 的论文报告了长上下文吞吐与内存方面的优势，但具体收益仍取决于硬件、软件实现、批量和任务长度。
混合专家也会带来路由和负载均衡问题。如果大量 token 同时涌向少数专家，局部拥堵会抵消理论效率。部署评测必须观察每层负载，而不只是平均速度。
## 连续批处理让服务器不必等齐一桌人
传统静态批处理要等同一批请求全部结束后再开始下一批。生成任务长度差异很大，短请求会被长请求拖住。
连续批处理可以在每个解码步插入新请求、移出已完成请求，让 GPU 保持繁忙。它能显著提升吞吐，但调度器需要照顾交互请求，避免批量任务长期占用资源。常见做法是设置优先级、最大等待时间和每类任务的并发预算。
分页式键值缓存则像操作系统管理内存页，减少预留大块连续空间造成的浪费。vLLM 的 PagedAttention 展示了这种思路。对于混合架构，缓存对象可能不同，调度器仍需解决碎片、复用和回收问题。
## 流式输出改善感受，却不等于更快完成
服务器可以在生成部分 token 后立即发送，让用户提前阅读或让语音合成提前开口。流式传输主要缩短感知等待，并不会自动减少总计算量。
界面还要平衡片段长度。过细会增加网络开销和闪烁，过粗又恢复成大段等待。语音场景可以按自然短语聚合，文本场景则要保证 Markdown、代码块和引用不会因半截输出造成误解。
## 推测解码、量化和路由各有代价
推测解码先让较小模型提出若干候选，再由主模型并行验证。候选命中率高时可以减少串行步骤，但小模型与主模型差异过大、任务风格复杂时，额外验证可能得不偿失。
量化用更低精度表示权重或缓存，能够节省显存并提高吞吐。Jamba-1.5 研究中也介绍了针对专家权重的量化方法。是否“无损”不能只看通用基准，还要检查本地长文档、数字、工具参数和多语言任务。
请求路由则按任务难度选择不同模型或推理预算。简单分类可以走快速路径，复杂推理使用更强模型。路由器自身出错会把难题送给小模型，因此必须统计误路由和升级重试成本。
## 正确压测比单个漂亮数字更重要
实验室测试应模拟真实到达分布，而不是固定间隔发送同样长度的请求。高峰时用户会集中到来，上下文长度和输出长度也呈长尾分布。平均延迟可能很好，第 99 百分位却已无法使用。
压测需要固定模型版本、量化方式、硬件、驱动、推理框架和采样参数，并报告首字延迟、词间延迟、总时长、吞吐、失败率和成本。还应加入取消请求、网络抖动、缓存未命中和工具超时。
当负载超过容量，系统应有可预测的降级策略：限制输出长度、暂停低优先级批量任务、切换快速模型，或明确告诉用户需要等待。悄悄降低答案质量会让性能问题变成信任问题。
## 架构与服务必须一起优化
Jamba 说明，实时推理的效率可以从模型结构本身重新设计；连续批处理、缓存和推测解码则从服务层挖掘硬件利用率。任何单项优化都可能在另一个环节形成新瓶颈。
真正的实时不是跑出一次最低延迟，而是在真实并发和长尾输入下，持续提供稳定、可测、可降级的响应。读者评估一套推理系统时，最值得追问的也不是“最快多少”，而是“高峰时最慢多少、为什么慢、失败后发生什么”。
## 参考资料