推理 SLA

3 秒看懂

推理 SLA 是云厂商 / 模型平台对 AI 推理服务作出的可用性、响应速度、吞吐量等承诺，具体化为“首 Token 延迟 ≤ X 毫秒”“99.9% 请求在 Y 秒内完成”“月度可用性 ≥ 99.95%”等可量化指标。谁不达标，按约定赔付。它是大模型从“玩具”到“生产级 API”的通行证，直接决定企业能否把 GPT-4o、Llama 3.1 等模型嵌入自动驾驶、金融风控、实时客服等关键业务。

3 分钟产业解释

传统云 SLA 关注虚拟机 / 容器的 uptime，而推理 SLA 面向模型服务化（Model‑as‑a‑Service），指标更具“模型味”：

• 延迟维度：首 Token 延迟（TTFT）、每 Token 延迟（TPOT）、端到端延迟（E2E Latency），通常以 P50/P95/P99 分位数给出。
• 吞吐维度：每 GPU/ 每实例的 requests per second（RPS）或 tokens per second（TPS），要求在一定并发下不降级。
• 可用性：请求成功率（如 HTTP 200 占比）、模型存活探活（liveness/readiness）。
• 一致性：在低延迟／高吞吐压力下，模型输出质量不退化（如不出现乱码、截断、幻觉概率不飙升）。

产业逻辑：大模型推理是高并发、低延迟、带宽敏感、显存密集的异构计算任务，任何环节（GPU 调度、KV‑cache 管理、网络转发、令牌桶限流）的抖动都会被 SLA 放大。因此，提供硬推理 SLA 的平台必须在模型压缩 / 量化、批处理策略（continuous batching）、投机解码（speculative decoding）、分布式推理拓扑（张量并行 / 流水线并行）、跨地域负载均衡、算力冗余等方面做足功课。

当前 AWS Bedrock、Azure AI、Together AI、Fireworks、国内阿里云百炼、火山引擎等均已推出带 SLA 的推理服务，竞争焦点逐步从“跑得通”过渡到“跑得稳、跑得快、赔得起”。

15 分钟专家深入

推理 SLA 不仅是商业条款，更是推理系统工程能力的量化标尺。与训练 SLA（少见，多以“作业完成时间”“失败重试”形式存在）不同，推理 SLA 直接面对终端用户，涉及在线服务全链路。

1. 推理 SLA 的核心矛盾

• 长尾延迟与分位数承诺：生成式模型一次推理的 token 数量可变（1 token～上千 token），且自回归生成天然串行，导致延迟分布长尾。P99 延迟可能数倍于 P50。要求“P95 < 500 ms”需要针对性地减少尾部抖动，如 GPU 时间片抢占、优先级调度、推测解码。
• 资源利用率与性能隔离：为了最大化 GPU 利用率，推理引擎通常采用动态批处理（continuous batching），但过量并发会引发排队延迟和 KV‑cache 换页争抢。SLA 倒逼平台设计自适应 batching 策略，在超标前主动限流或弹性伸缩。
• 成本与冗余：承诺 99.99% 可用性意味着必须多 AZ/ 地域部署，并预留显著的缓冲算力（如 N+2 冗余），直接拉高单位 token 成本。平台需要在 SLA 违约金和冗余投入之间算账。

2. 典型量化指标（行业标杆，未精确标数字，无据不编）

• TTFT：用户发出请求到第一个 token 出现的时间。主流生产系统目标常为 < 100 ms（P50），对于 70B 参数 MoE 模型可能放宽到 <300 ms。[行业案例，未披露具体平台]
• TPOT：连续两个 token 之间的平均间隔（inter‑token latency），反映解码效率。通常要求 P50 < 20 ms，使得生成速度超 50 token/s，达到人类阅读舒适区。
• 可用性：类似云服务，每月请求成功率 ≥ 99.9%（“三个九”）是起步，关键业务要求 ≥ 99.99%。需要注意的是，“请求成功”不仅指 HTTP 200，还要求返回结果内容完整、语义正常。部分平台会在 SLA 中排除模型自身幻觉导致的失败。[平台公开条款]
• 容量承诺：为每个开发者按订阅级别保证 TPM（tokens per minute）或 RPM（requests per minute），超限返回 429 并明确不计入 SLA 异常（除非因平台故障误限）。

3. 监控与赔付机制

推理 SLA 依赖细粒度的可观测性：

• 监控：全链路埋点，从 API 网关 → 推理调度器 → GPU kernel 执行，每个环节打点延迟，聚合为分位数。平台通常提供实时 Dashboard 和告警。
• 赔付：若月度可用性低于承诺，按超出部分的时长折算服务信用或现金赔偿，通常限制在月服务费的 100% 或某个倍数。生产关键应用通常要求对超额延迟也进行赔付（如每 100 万个 503 请求赔 X 美元）。

技术原理

推理 SLA 的保障根植于模型推理系统（inference serving system）的全栈优化。下面建立一个从请求进入到 GPU 执行的简化模型。

1. 推理服务架构与延迟分解

用户请求
  |
API 网关 (限流、认证、路由)
  |
推理调度器 (排队、batching、模型选择)
  |
KV‑cache 管理器 (显存分配、分页管理)
  |
GPU 执行引擎 (kernel launch、attention、FFN)
  |
响应拼接 & 流式输出

• 首次延迟 (TTFT) 核心在预填充（prefill）阶段：对整个 prompt 做一次 Transformer 正向传播，计算所有层的 KV‑cache，并生成第一个 token。该阶段与 prompt 长度强相关（O(n²) 注意力），需高并行度。
• 每 token 延迟 (TPOT) 由自回归解码决定：每次仅处理上一个 token，计算简单但串行，且需读取 KV‑cache，瓶颈在显存带宽和 kernel 调度。

2. 关键技术保障

a. Continuous Batching（连续批处理）
传统静态批处理等全批次完成再释放，GPU 空泡严重。Continuous batching 允许请求随时加入 / 离开批处理，GPU 计算资源被充分填满。但过大的批次会挤占 KV‑cache，引发换页（paging），导致延迟抖动。为保障 SLA，调度器会监控队列深度和 KV‑cache 水位，采用自适应批处理大小和抢占式调度。

b. 投机解码（Speculative Decoding）
用小模型快速生成多个候选 token，再由大模型并行验证，一次前向可产出多个 token，大幅降低 P50 延迟。但验证失败会回退，导致尾部延迟恶化，需精细控制候选步数以避免 P99 跳动。

c. 模型量化与稀疏化
INT8/FP8 甚至 4‑bit 量化减少显存占用和计算量，允许更大批次，降低排队延迟。结构化稀疏（如 2:4 稀疏）可加快推理吞吐。量化需在精度损失可控范围内，否则 SLA 中的“质量一致性”被打破。

d. 分布式推理拓扑
对于远超单 GPU 的大模型，采用张量并行（TP）将权重分片到多卡，流水线并行（PP）减少通信开销，或 DP‑TP‑PP 混合。通信原语如 AllReduce、ReduceScatter 的微秒级延迟都会影响端到端 SLA，故需高速 NVLink、NVSwitch 和 RDMA 网络。

e. 弹性扩缩与冷启动优化
当请求突发，动态拉起备用实例。模型加载从远端存储读取数十 GB 权重，若冷启动时间超 SLA 容忍，需热备或预取。常见方案：保持部分实例 running，或使用 GPU 内存池化技术加速加载。

3. 示例：保障 P99 TTFT < 200 ms（估算口径）

假定一个 7B 模型，prompt 512 tokens，GPU 为 H100。

• 预填充计算：约 512² 注意力，需要高效 FlashAttention kernel，理论上可控制在 50 ms 内。
• 调度排队：若平均队列长度 3，连续批处理下排队等待 ≤ 50 ms。
• 网络与网关：10 ms。
• 总计目标 110 ms，留出缓冲区，P99 稳定在 200 ms 内。
  一旦队列积压或 GC 停顿，P99 跳变，需通过扩缩容或流量限流恢复。

技术演进史

• 2018‑2020 年（BERT 时代）：推理主要面向分类 / 抽取，SLA 以简单 QPS 和延迟衡量，批处理简单，可用性依赖容器编排。
• 2021‑2022 年（GPT‑2/3 小规模部署）：生成式模型开始上线，首次 token 延迟和输出长度成为痛点，推理引擎 TGI、NVIDIA Triton 等开始支持 continuous batching，SLA 概念萌芽。
• 2023 上半年（ChatGPT 爆发）：OpenAI 等提供 API，但 SLA 尚不成熟，爆红 429 和延迟波动普遍。开源推理框架 vLLM 发布，推动显存管理与调度效率提升。
• 2023 下半年‑2024 年：云厂商和推理平台推出带分位数延迟保障的推理 SLA，竞争白热化。Fireworks、Together、Anthropic 等均将低延迟承诺作为卖点。2024 年，MoE 模型（Mixtral、DeepSeek‑V2）流行，其动态路由给 SLA 带来新挑战（专家负载不均导致尾部延迟）。业界探索自适应路由和专家并行。
• 2025 年展望：离线 / 在线混合推理、基于 LoRA 的多租户适配、边缘推理的 SLA 或将标准化。

技术路线对比

表中数字为定性估算，无确切来源，仅供参考。

上下游

• 上游：GPU 硬件（NVIDIA H100/B200、AMD MI300X）、高速网络（InfiniBand、NVLink）、推理引擎框架（vLLM、SGLang、Triton Inference Server）、模型压缩工具（TensorRT‑LLM、LM‑Deploy）、监控平台（Prometheus、Datadog）。
• 中游：推理服务提供商（AWS、Azure、GCP、火山引擎、国内阿里云、腾讯云；独立平台 Together AI、Fireworks、Anthropic API 服务）。
• 下游：垂直应用：Chatbot、AI 搜索、代码助手、内容生成、游戏 NPC、智能客服、金融风控、自动驾驶云端仿真。对推理 SLA 敏感度由低到高：客服（秒级可接受）→ 代码补全（需 < 200 ms）→ 自动驾驶（毫秒级硬实时）。

关键指标

• 可用性 (Availability)：每月成功请求数 / 总请求数，排除客户端错误和配额限制；通常计算“错误预算”，可用性 99.9% 意味着每月允许约 43 min 宕机。
• 尾延迟 (Tail Latency)：TTFT/TPOT 的 P95、P99，甚至 P999。
• 服务质量 (SLO vs. SLA)：SLO（服务等级目标）是内部目标，SLA 是外部合同承诺，后者常比 SLO 严格。
• 吞吐量 (Throughput)：RPS 或 TPS，需注意与延迟的折中。高吞吐会导致队列延迟上升，降低延迟 SLO。
• 一致性 (Quality): 定量难，常用代理：输出长度方差、无意义符号率、重复率，或业务指标（如搜索任务完成率）。

供需与市场数据

• 推理算力市场增长迅速，据多方报告估算（如 SemiAnalysis、Gartner），2024 年全球 AI 推理芯片及服务市场可达数百亿美元，到 2028 年可能超越训练市场。
• GPU 云供不应求，优质推理 SLA 的服务价格较高，例如低延迟优先服务可能比“尽力而为”模式溢价 30‑50%。
• 开源模型（Llama、Mistral、DeepSeek）大幅降低推理门槛，但也促使平台间 SLA 竞争加剧。推理平台通过规模效应和工程优化降低每 token 成本，支撑 SLA。
• 国内由于模型备案和数据合规要求，推理 SLA 往往与模型部署区域和数据驻留绑定，催生本地化推理服务机会。

以上为行业判断，具体产值数据未获精确来源，属估算范畴。

代表公司与资本映射

• NVIDIA：提供硬件基石（GPU、TensorRT‑LLM、Triton），其推理微服务（NIM）也包含 SLA 支持。
• 云巨头：AWS Bedrock、Azure AI、Google Vertex AI 均推出一系列模型推理 SLA，资本投入于自研芯片（Trainium/TPU）和服务器架构以优化性能。
• 独立推理平台：Together AI、Fireworks、RunPod 等，以高性能推理和 SLA 为卖点，获一线风投青睐。
• 国内：阿里云百炼、火山引擎豆包大模型平台、腾讯混元、智谱 API 等。部分企业如硅基流动、趋动科技深耕推理优化，与算力合作提供 SLA 能力。
• 资本映射：投资者关注“推理即服务”的网络效应：越多开发者使用，推理工作负载越聚集，平台能进一步优化批处理效率和成本，抬高对手进入门槛。推理 SLA 是这种网络效应的直接表现。

投资逻辑

1. 从训练到推理的重心迁移：随着开源模型能力逼近闭源，企业需求从“训练自己的大模型”转向“高效推理外部模型”，推理 SLA 成为平台锁定客户的护城河。
2. SLA 驱动的溢价与粘性：一旦企业将特定 API 集成进生产（含 SLA 条款），迁移成本高，形成稳定经常性收入。
3. 芯片和系统层的受益者：推理需求爆发拉动推理芯片、高速互连、液冷等产业链。能提供端到端 SLA 保障的集成方案（如 NVIDIA AI Enterprise + NIM）估值受益。
4. 风险：推理 SLA 竞争可能沦为价格战，各平台承诺过度导致高赔付；此外，SLA 仅覆盖基础通信和可用性，难以解决模型可靠性（幻觉、安全），业务价值存在上限。
5. 关键观察点：各平台是否公开 P99 延迟 data 和实际赔付记录；是否引入“质量 SLA”（如准确率承诺）；是否将推理 SLA 与微调、评估编排捆绑销售。

常见误读纠偏

• 误读 1：“推理 SLA 只保证服务器不宕机，延时高不算违约。”
  纠偏：成熟的推理 SLA 明确包括延迟 KPI，如“P95 首 Token 延迟 < 200 ms”，若未达到，即使 HTTP 200 返回也视作违反 SLA。延迟定义需看清是全链路还是仅模型处理段。
• 误读 2：“月可用性 99.9% 意味着每月 43 分钟宕机，超过就赔。”
  纠偏：失败请求并非仅以时长计。一台服务器宕机 10 秒但所有请求失败，算作请求失败纳入错误预算，可能很快耗尽。错误预算为（1‑可用性）× 总请求数，而非连续时间。可用性 99.9% 下，若月请求量 1 亿次，可错 10 万次。所以小机率长时间宕机不一定是主要风险，持续微小错误也会突破 SLA。
• 误读 3：“使用 MoE 架构模型，推理 SLA 更难保障，因为专家负载不均。”
  纠偏：MoE 的“专家并行”本身不是 SLA 的天然杀手。通过智能路由（re‑route 过载专家）、层次化 all‑to‑all 优化、以及预留容量，已有平台将 MoE 模型的推理延迟做到与稠密模型可比。难点在于工程实现，但并非不可攻克。

学习路径

1. 基础：理解 Transformer 推理过程（prefill 和 decode），掌握延迟和吞吐指标。
2. 系统工程：阅读 vLLM 论文（“Efficient Memory Management for Large Language Model Serving with PagedAttention”）、Orca 论文（Continuous Batching），理解 KV‑cache 管理和调度。
3. 分布式：研读 Megatron‑LM 推理并行策略，了解 Tensor Parallelism 与 Pipeline Parallelism 对延迟的影响。
4. SLA 设计：学习 Google SRE 书中的 SLO/SLA 工程方法，结合推理特定场景实践错误预算。
5. 案例研究：分析 OpenAI、Anthropic 的状态页面与 Postmortem，观察它们如何描述延迟超限和可用性问题。
6. 实验：部署 vLLM 或 SGLang，压测，设置 SLO，用 Prometheus + Grafana 监控，切身感受。

一句话总结

推理 SLA 是 AI 应用从 API 调用走向企业级业务生命线的契约，它倒逼底层异构计算、调度系统、模型压缩技术的整体协同进化，也是衡量平台推理工程能力的最直接标尺。

延伸阅读与来源

• 论文：Kwon et al. “Efficient Memory Management for Large Language Model Serving with PagedAttention” (vLLM) (2023)
• 论文：Yu et al. “Orca: A Distributed Serving System for Transformer‑Based Generative Models” (2022)
• NVIDIA Triton Inference Server 文档：Model Configuration and Scheduling
• Google SRE 书籍：Service Level Objectives
• AWS Bedrock SLA 页面（公开条款，可查看具体违约赔付方式）
• Fireworks AI 的技术博客（如关于 continuous batching 和 speculative decoding 的实践）
• 行业报告：SemiAnalysis “AI Inference Landscape” 2024‑2025

注：受限于检索，具体数据均为定性描述或[未充分披露]，实际项目应查阅最新平台服务协议和第三方基准测试。