附录 性能指标与术语表

附录 性能指标与术语表

本附录汇总实时 AI 领域常用的性能指标、缩写和术语，方便随时查阅。

一、核心性能指标

实时 AI 的性能要用一组指标刻画，单一指标不足以反映全貌。

二、资源利用率指标

三、成本指标

四、常用缩写

五、关键术语简释

PagedAttention：借鉴操作系统虚拟内存分页的 KV Cache 管理机制，把缓存切成固定块按需分配，解决显存碎片，显存利用率从 40% 提升到 90%+。

连续批处理（Continuous Batching）：在 token 级别动态调度请求进出 batch，而非等整个 batch 完成，解决静态批处理的木桶效应，吞吐提升 2–4 倍。

推测解码（Speculative Decoding）：用小模型预生成候选 token、大模型并行验证，打破 decode 的串行性，降低单请求延迟。

流批一体（Kappa 架构）：用一套流处理系统同时支撑实时和批处理需求，避免 Lambda 架构的双系统维护成本。

端到端语音模型：直接处理音频输入和音频输出、不经过文字中转的多模态模型，延迟低但可控性弱。

边缘计算：在离数据源近的设备（而非云端）做计算，降低带宽、延迟和成本，适合视频 AI 等数据量大的场景。

抽帧（Frame Skipping）：视频处理中每隔 N 帧做完整检测、中间帧用轻量跟踪补全的策略，平衡精度和算力。

六、指标的测量方法与压测规范

指标定义清楚只是第一步，怎么测决定数字有没有意义。TTFT 和 ITL 的测量点必须固定：是网关收到请求开始计时，还是客户端发出开始计时？两者之间隔着网络往返和鉴权，差出的几十到几百毫秒足以让两份报告互相矛盾。规范做法是端到端测量以客户端为准（用户体感才是一切优化的最终裁判），同时服务端分段埋点用于归因。统计口径上，所有延迟指标都要报分位数（P50/P95/P99）而非平均值——重尾分布下平均值会同时掩盖最佳体验和最差体验。

压测有一套容易踩坑的规范。第一，负载要真实：prompt 长度分布、输出长度分布、请求到达节奏（泊松到达比固定速率更接近真实）都从生产日志回放采样，用"平均长度的 prompt"测出的吞吐上线后必然失真。第二，必须预热：首批请求包含模型加载、kernel JIT 编译、缓存冷启动，直接计入会大幅高估稳态延迟。第三，扫描并发档位而非单点：固定并发从 1 扫到系统饱和，画出"并发-延迟-吞吐"三条曲线，拐点位置就是容量规划的答案，单点压测只能证明"这个点能跑"。第四，压测时长要足够让排队效应显现（至少十几分钟），并且监控与被测服务分机部署，避免观测者效应。

语音和视频场景另有两套口径。语音交互报"轮次响应延迟"（用户停止说话到 AI 开始出声）和"打断响应延迟"（用户开口到机器停止播放），前者预算通常 1 秒，后者 200 毫秒内才有"听话"的体感。视频流式 AI 报"端到端帧延迟"（采集到结果输出）和"处理帧率"（与送检帧率区分，抽帧策略下两者不同），加上"轨迹连续性"这类业务指标——检测框每秒跳变一次的系统，帧率再高也不可用。

七、指标之间的关系与常见陷阱

这些指标不是独立的，理解它们的耦合关系才能避免"按下葫芦浮起瓢"。TTFT 与吞吐通过 batch 策略耦合：加大 batch 提吞吐会推高排队等待进而恶化 TTFT；连续批处理缓解了这个矛盾但没消除。ITL 与输出长度耦合：长输出的后半段 KV Cache 变大，ITL 会随生成长度缓慢上升，报告 ITL 要注明测的是哪个区间。GPU 利用率高不等于赚钱：算力打满但都在算无效重试或超长请求的尾部，吞吐依然低；反过来利用率低也不一定浪费——为延迟 SLA 预留的余量是买保险，不是浪费。成本指标里"每千 token 成本"要区分批处理档和实时档，同一模型两种部署的成本能差数倍，拿批处理价目评估实时业务会严重低估预算。

三个高频陷阱值得单独记。陷阱一：用 P50 对外承诺 SLA——一半用户体验达标另一半不达标，对外承诺永远用 P99 或 P999。陷阱二：优化前后用了不同的测量口径（换了压测工具、换了客户端地域），"提升 40%"纯属口径差。陷阱三：把流式指标当整体指标汇报——TTFT 很漂亮但 ITL 抖动，用户体感依然是卡，流式体验是"快开口"加"匀速吐字"的乘积。

八、术语的演化注记

几个术语在不同年代含义发生过漂移，读旧资料时要留心。"流式"在 2015 年前后指 Spark Streaming 的微批，在 Flink 语境下指逐事件处理，在大模型语境下又指 token 级增量输出——三个"流式"的延迟量级分别是秒、百毫秒、十毫秒。"实时"更宽泛：工业控制里的硬实时要求 deadline 违反即事故（微秒级），软实时允许偶发超时（交互产品都属于此类），看资料先分清对象是哪一类。"边缘计算"从 CDN 时代的"内容下沉"演化到今天的"算力下沉"，内涵从缓存变成了推理。Kappa 架构一词也常被误用：它特指"以 Kafka 可重放日志为核心、纯流式替代批层"的架构主张，不是任何流批一体方案都能叫 Kappa。

九、一张速查：技术到指标的映射

排障时反向用这张表：先看哪个指标劣化，再查对应技术栈的配置与健康度，比从头排查快得多。

十、容量规划速算与方法

指标最终要落到"我该买多少卡"这个问题上。给一个可操作的速算流程。第一步，把业务需求翻译成 token 需求：日活用户数 × 人均请求数 × 平均（输入 + 输出）token 数，再除以一天的可用秒数得到稳态 token 速率，乘上峰值系数（一般 3 到 5，看业务早晚波动）得到峰值速率。第二步，拿到单卡的实测能力：用真实流量分布压测目标引擎，记录"单卡在 SLA 约束下的吞吐"，注意这个数必须带 SLA 前缀——不卡延迟上限的吞吐数字没有意义。第三步，峰值速率除以单卡吞吐得到卡数，再加冗余：N 加 1 的宕机冗余、预留两到三成的增长空间、以及滚动发布期间的容量缺口。三步下来的数字通常比直觉乐观的估算大一倍，这个"直觉偏差"本身就值得写进规划文档。

语音和视频场景把这套速算换成各自的关键资源。语音交互按"并发通话路数"规划：单卡能支撑的实时会话数由音频 token 的生成速率决定（端到端模型）或三段组件的最大段决定（级联管线），同时要算音频转发的网络带宽。视频分析按"路数 × 每路码流"规划：边缘盒子按路数报价采购，云端按回传事件量规划带宽与存储，两边的容量曲线要分开画再合起来看总成本，很多项目栽在只算了边缘盒子钱、漏了云端的存储增长曲线。

容量规划还有个时间维度：模型升级会重置所有数字。换一代模型（哪怕参数量不变），单卡吞吐可能变三成，KV Cache 占用可能翻倍，规划表要标注"基于哪个模型哪个引擎哪个版本测得"，模型升级时全部重测。把容量规划当成一份持续维护的活文档，而不是立项时做一次就锁死的报告——这是推理成本不失控的组织性保障。

十一、术语使用的最后提醒

写方案和汇报时，术语的精确使用直接影响决策质量。三个建议。其一，对外行汇报时把指标翻译成体验语言："P99 TTFT 800 毫秒"不如"最慢的每一百次里有一次，用户要等不到一秒"有说服力，但内行评审时必须用精确指标，两套话术切换着用。其二，新兴术语先查原始论文再引用，社区传播中含义漂移最快的恰恰是热门词——"端到端""Agent""实时"都被过度使用过。其三，本文档列的术语表是快照不是全集，这个领域每月都有新词进来，养成"遇到新词记一句自己的话"的习惯，半年后你会拥有一份比任何现成术语表都好用的个人词典。

十二、指标周会怎么开：一个落地模板

最后给一个把附录知识变成日常实践的操作模板——推理服务的指标周会。议程固定四段：第一段看核心体验指标的分位数周环比（TTFT、ITL 的 P50/P95/P99，语音场景加轮次延迟），任何分位数劣化超过一成必须给出归因；第二段看资源与成本（GPU 利用率分布、每千 token 成本、超时与限流拒绝数），把成本波动和流量结构变化对上账；第三段看容量水位（当前峰值占规划容量的百分比、下一次扩容的触发点和到货周期）；第四段只讨论一个"指标故事"——本周挑一个异常数字深挖到底，沉淀成可复用的排障记录。四周下来，团队对数字的敏感度和归因能力会有肉眼可见的提升，这套会开得好不好，其实就检验了整本文集的方法论有没有真正长在团队身上。