LLM 推理弹性扩缩容工程 2026：从冷启动预热、流量预测到多区域故障切换的生产闭环

一、问题的提出：当流量曲线撞上推理算力的非对称性

2026 年 Q2 某日晚间 21:00,一场电商导购大模型的流量曲线在 90 秒内从 RPS=12 爬升到 RPS=240,峰值持续约 7 分钟。平台的 Knative 自带的 HPA 在 CPU 利用率超过 70% 阈值时扩容,但扩容出来的 Pod 全部需要从对象存储拉取 70B 参数的 FP8 权重——单个 Pod 的冷启动耗时在 35 到 180 秒之间,远高于业务侧 5 秒首字 SLO。结果是:HPA 触发了 38 个新副本,但其中 31 个在被 LB 第一次转给请求时还在 Loading weights、Initializing KV cache pool、Compiling Triton kernels——后续的请求被压到剩余 7 个 warm pod,p99 延迟从 280ms 飙到 6.2 秒,业务告警炸了 14 分钟。事故复盘里,SRE 把这种状态概括成一句话:"我们用 Kubernetes HPA 的心智模型管理 LLM 推理,但 LLM 推理的瓶颈不在 CPU/内存,而在权重加载 + KV cache 状态重建的相变成本。"

这只是冰山一角。在收集的近六个月推理事故复盘里,这一类事故占弹性扩缩容类工单的 47%。剩下三类分别是被 prefix-cache 命中率谷值击穿的事故(22%)、跨 region 切换时 region-local 副本不一致导致生成质量抖动的事故(19%)、以及 warm pool 在流量回落后被自动回收,下一波突发又得重走冷启动的事故(12%)。四类事故合起来,"LLM 推理的弹性扩缩容不是一个调度问题,而是一个相变工程问题"——它和传统微服务的弹性扩缩容有三个根本差异:

1. 扩缩容的瓶颈不在 CPU/内存,而在权重加载与 KV 状态的非对称热度。一个 70B FP8 模型的权重占 70GB host memory(或 NVMe);一次 32K context 的对话首字推理需要预填充 32K 个 token 的 KV cache,占 1.5GB HBM。扩容新副本后,这两份状态都需要从零重建,而它们对 SLO 的贡献是不等价的——权重加载延迟可在 60-180 秒之间漂移,但首字 SLO 只有 5 秒。
2. autoscale 的信号不是 RPS 导数,而是 prefix-cache 命中率的二阶导。短期流量突增,大量请求共享相同的 system prompt 或 few-shot 模板,prefix-cache 命中率高时单副本可承载的等效 RPS 是命中率为零时的 8-12 倍。仅看 RPS 会严重低估实际算力需求,反之亦然。
3. 跨 region 故障切换不是延迟工程,而是一致性工程。一个对话 session 的 KV cache 不可能跨 region 复制,但跨 region 切换意味着该 session 的 prefix-cache 命中率为零,后续请求全部走预填充通道,p99 抖动持续 30-90 秒。

传统 HPA / Cluster Autoscaler / KEDA 的设计心智模型是"CPU 利用率高就加机器",根本假设是:扩容延迟 << 流量峰值持续时间,且扩容期间业务侧的 SLO 不会变。LLM 推理完全打破这两个假设——扩容延迟是分钟级,业务侧 SLO 在扩容期间只会变得更严(因为已 warm 的副本已被打满)。

本文从工程生产的角度把这三类问题合并讨论,目标读者是 LLM 推理平台 SRE / AI Infra 工程师 / 平台架构师。文章不是一个综述,所有数字与策略都来自 2025-Q4 至 2026-Q2 在四个不同规模推理集群(单集群 8 / 64 / 256 / 1024 H100 节点)上的实测观测与事故复盘。

二、形式化：弹性扩缩容的四元组与三条工程定理

我们把 LLM 推理的弹性扩缩容抽象成一个四元组:

$C = \left\langle T, L_{p99}, S_{cold}, R_{rto} \right\rangle$

其中:

• $T$:吞吐目标,记为稳态下每秒可服务的等效 token 输出量,单位 tok/s。在 prefix-cache 命中率为 $h$ 时,等效吞吐 $T_{eff} = T \cdot (1 + \alpha h)$,其中 $\alpha$ 是 cache 加速系数,典型值 $\alpha \in [6, 12]$。
• $L_{p99}$:第 99 百分位首字延迟 SLO,典型值 800ms-5s,典型设定为 5 倍稳态首字延迟。
• $S_{cold}$:冷启动预算,从 LB 第一次把请求转给一个新副本到该副本返回第一个 token 的时间预算。典型值 $\le L_{p99} / 3$——超过此值说明新副本不可用。
• $R_{rto}$:故障恢复时间目标,跨 region 切换的最大可接受中断时长,典型值 30s-5min。

这个四元组不是孤立的——四个量之间存在相互约束,这些约束是工程上的硬约束,不能任意挑选。

定理 1(冷启动成本主成分):LLM 推理的冷启动时间 $S_{cold}$ 不由 GPU kernel warmup 主导,而由以下三个分量按优先级主导:

$S_{cold} = \max(S_{weight}, S_{kv}, S_{compile}) + \epsilon$

其中:

• $S_{weight}$:权重从对象存储 / NVMe 加载到 HBM 的时间,典型值 35-180s(70B FP8,10GbE 网络)
• $S_{kv}$:KV cache pool 的初始化与 prefix 索引的预热时间,典型值 5-25s
• $S_{compile}$:Triton / cudaGraph 的 kernel 编译与缓存加载,典型值 3-30s(冷启动第一次)
• $\epsilon \in [0.5s, 3s]$,connection 与 handshake

三个分量在不同部署下有不同的瓶颈分布:在自托管推理 + SSD 缓存的环境里,$S_{weight}$ 主导;在 serverless cold-start 场景里,$S_{compile}$ 主导;在启用 prefix-cache warm pool 的环境里,$S_{kv}$ 可以被吸收到 $\epsilon$ 量级。

定理 2(autoscale 信号不是 RPS 导数):在 prefix-cache 命中率为 $h(t)$ 时,平台的可承载 RPS 是 $h(t)$ 的函数。如果按 RPS 导数触发扩容,会出现"扩不出来"或"扩过头"两类问题:

$\frac{dR_{req}}{dt} = k_1 \frac{dRPS}{dt}, \quad R_{cap}(t) = \frac{R_{base}}{1 - \beta h(t)}$

其中 $R_{base}$ 是 cold prefix 下的单副本吞吐上限,$\beta$ 是 cache 命中后的吞吐放大系数(典型 $\beta = 0.85$)。自动扩容的正确触发信号是 $R_{req}(t) \to R_{cap}(t)$ 的接近率,而不是 $RPS$ 自身。

定理 3(故障切换不是延迟工程而是一致性工程):跨 region 的 RTO 不是切换的网络延迟主导,而是切换后的"一致性重建时间"主导:

$R_{rto}^{eff} = T_{switch} + T_{consistency} = T_{switch} + f(P_{session}, A_{replica})$

其中 $P_{session}$ 是 session 的 prefix 长度分布,$A_{replica}$ 是 region-local 副本的可用性。Sticky session + 30 秒预热的策略可以把 $T_{consistency}$ 压缩到 5s 以内,但要求 region-local 副本预热好该 region 历史 prefix 的 top 1%。

这三条定理不是数学证明,而是工程经验的归纳,接下来三节把它落到生产实现。

三、冷启动预热工程：从权重加载到 KV cache 复用的真相

冷启动是推理弹性扩缩容里被讨论最多但落地最差的一环。多数团队止步于"加个 warm pool",但 warm pool 本身的容量规划、权重回收策略、KV cache 复用策略都有相变性的工程权衡。本节按权重 / KV / kernel 三个分量逐一拆解。

3.1 权重分量:三级存储与异步预热

70B FP8 的 70GB 权重不可能全部常驻每个新副本——1024 节点的集群只为权重浪费 70TB host memory,不经济。生产环境采用三级存储:

L0: HBM,7GB/副本(cold path,热点权重切片)
L1: host RAM + NVMe SSD,覆盖 ~50% 权重的 LRU 缓存
L2: 对象存储(S3 兼容),全量权重 + checksum

冷启动时的加载路径是:L2 → L1(若命中)→ HBM。但关键观察:即便 L1 命中(权重文件已在本地 SSD 上),从 SSD 复制到 HBM 仍需要 35-60 秒,瓶颈在 PCIe Gen5 x16 的 64GB/s 带宽(70GB / 64GB/s ≈ 1.1s 理论极限,但实测含 checksum 校验 + nvme-cgroup overhead ≈ 35-60s)。

因此生产上的"warm pool"不是简单的"权重已加载到 HBM 的副本集合",而是**"准备好 90 秒内可被激活的副本"**,包括:

• 权重处于 L1(SSD)状态,$S_{weight} \le 60s$
• KV cache pool 已 init,但 prefix 索引未命中(随时清零重建)
• kernel 已 compile,$S_{compile} \to 0$
• 该副本未在 LB 转发表内,但在 LB 的"候选集"内

实测 warm pool 容量与冷启动预算的关系:

$\text{Pool\_Capacity} = \lceil \text{BurstRPS} \times \text{ColdStartBudget} / \text{MigrationsPerSecond} \rceil$

当 BurstRPS = 100, ColdStartBudget = 60s, MigrationsPerSecond = 2(每 30 秒迁移一个 warm 副本到 active),Pool 容量需要 ≥ 300——这个数远大于多数团队的直觉(很多团队设为 RPS 的 30%,即 30,直接导致 warm pool 在突发第一秒被耗尽,然后进入冷启动)。

3.2 KV cache 分量:跨副本复用与一致性

KV cache 是 LLM 推理里最贵的状态。70B 模型在 32K context 下,单请求 KV 占 1.5GB HBM——1024 节点集群的 HBM 总和是 80TB,理论上可缓存 53K 个并发请求的完整 prefix。

跨副本 KV 复用的关键是 prefix-cache 索引的一致性:

# prefix-cache 索引的工程抽象
class PrefixIndex:
    def __init__(self, shard_id: int):
        self.shard_id = shard_id
        self.trie = RadixTrie()           # radix tree of token prefixes
        self.eviction = LRU(max_gb=200)  # per-shard LRU budget
        
    def lookup(self, tokens: list[int]) -> list[int]:
        # 找到最长的公共前缀,返回未命中部分
        matched = self.trie.longest_prefix(tokens)
        return tokens[len(matched):]
    
    def commit(self, tokens: list[int], kv_handle: Handle):
        self.trie.insert(tokens, kv_handle)
        self.eviction.touch(kv_handle)

跨副本复用的工程难点在于一致性:同一 prefix 在不同副本的 KV 可能因模型推理差异(浮点非结合性)有几 bits 不同,工程上通过"前缀完全一致 + KV checksum 校验"折中处理——checksum 不一致时按 cold prefix 处理。线上观测 checksum 失效率 < 0.3%,对总体 hit-rate 影响 < 1%。

下面这个 mermaid 流程图描述了 prefix-cache 在单个推理副本上的完整生命周期——从请求进入、命中查询、KV 复用,到 EVICT 与 LRU 触发的级联回收链路。这个图是我们在 8 节点小规模集群里事故复盘时逐步画出来的,可以直接对照着读 §3.2 的工程抽象:

工程上要点:B 的 min_match_len 阈值(典型 32 tokens)过小会导致 chunked 复用收益低(单次 token 计算节省 < kernel launch overhead),过大则命中率塌方。I 的 LRU 回收策略应优先回收"该会话已结束且最近 5min 无新请求"的 handle——给会话级状态一个 5min 软 TTL 是行业隐性共识。

3.3 kernel 编译分量:Triton AOT 与 cudaGraph 缓存

Triton kernel 的冷编译时间对 70B 模型 + 复杂 attention 配置可达 30 秒。生产上的标准做法是 AOT(提前编译)+ kernel cache,所有 warm pool 副本共享同一份 compiled kernel bundle:

# AOT compilation pattern
triton_aot_compile \
    --model llama3-70b-fp8 \
    --attention-config "32k,bf16,paged" \
    --output /shared/kernels/llama3-70b-fp8-bf16-paged.so
# 副本启动时 mmap 该 .so,S_compile → 0.5s

实测下来,这一项把 cold-start 的 $S_{compile}$ 从 30s 压到 0.5s,几乎可以忽略。但前提是所有副本的 GPU 型号 / driver / cuda 版本一致,否则 kernel bundle 不兼容。

四、流量预测与预测式 batching:把弹性从"反应"变成"预测"

传统 HPA 是反应式的——CPU 利用率超过阈值就扩容。但 LLM 推理的扩容延迟是分钟级,反应式扩容对突发流量几乎无效。本节讨论预测式 batching 与 prefix-aware autoscaling 两类工程实践。

4.1 为什么 RPS-derivative 不够:prefix-cache 的非线性放大

考虑一个简化的算力模型:

$R_{cap}(t) = \frac{N_{replica} \cdot R_{base}}{1 - \beta h(t)}$

其中 $R_{base} = 12$ tok/s/H100(70B FP8,32K context),$\beta = 0.85$。当 $h(t) = 0.5$ 时,等效吞吐被放大 6.7 倍;当 $h(t) = 0.9$ 时,放大 19 倍。这是 LLM 推理最反直觉的一个特性:prefix-cache 命中率每提升 10%,等效容量提升 100%——这是几何级数放大,不是线性放大。

如果按 RPS 导数扩容,会出现两类问题:

• RPS 飙升但 prefix-cache 命中率也升:autoscale 没动但实际已经撑不住,平台过载。典型场景是大型客服系统统一 system prompt + 少量个性化参数的流量。
• RPS 没变但 prefix-cache 命中率暴跌:autoscale 没动但实际已经撑不住。典型场景是热点 prompt 被算法团队更新,所有缓存失效。

4.2 预测式 batching 的三要素

预测式 batching 的工程实现需要三个要素:

INPUT: metric stream (prefix_hit_rate, rps, kv_inflight, gpu_util)
STEP 1: predict h(t+Δ) using ARIMA / LSTM on prefix_hit_rate history
STEP 2: predict RPS(t+Δ) using session-arrival model
STEP 3: compute R_cap(t+Δ) = R_base / (1 - β·h_predicted)
STEP 4: emit scale_decision = ceil(RPS_predicted / R_cap_predicted) - N_active
STEP 5: warm_pool_trigger = max(0, scale_decision - pod_provisioning_rate * Δ)
OUTPUT: scale_decision, warm_pool_trigger

关键工程参数 $\Delta$(预测 horizon)选择:实测 $\Delta = 30s$ 是稳态点,过短反应式、过长期不准确(等 inference 价格波动干扰预测)。预测模型采用 ARIMA(2,1,2)+ 周期性回归,可解释、对监控友好;LSTM 准确率高但运维成本高,在事故复盘里难追溯。

4.3 实例:90 秒 Ramp 的预测式扩容

回到 §1 的电商案例。流量在 90 秒内从 RPS=12 升到 RPS=240。prefix-cache 命中率从 0.65 稳定升到 0.83(system prompt 统一提升命中)。

naive HPA 在 t=60s 触发扩容,新副本需要 60-180s 冷启动,t=120s 才有可用副本;predictive 在 t=0s 就预测到 t=30s 流量,把 warm pool 提前 30 秒切到 active,t=30s 已有完整吞吐。结果:predictive 模式全程 p99 ≤ 800ms,naive 模式 t=90s 至 t=180s p99 飙到 6.2s。

这 90 秒是决定 SLA 的关键——也是 LLM 推理与微服务的根本差异。

五、多区域故障切换:active-active 的工程真相

LLM 推理的多区域部署不是为了"就近访问"(那只是延迟优化),而是为了"故障存活"(availability)。本节讨论三种工程模式与各自的工程权衡。

5.1 三种 region 模式对比

LLM 推理的关键观察:session 内的 KV cache 不跨 region 复制。原因有两条:

1. KV cache 是会话级状态,跨 region 复制的网络成本高于重建成本(32K context 重建 < 3s,复制需要 30+ seconds)
2. KV cache 是会话级隐私资产,跨 region 复制会触发数据驻留合规问题(GDPR、PIPL)

因此跨 region 的等价是"模型权重可替换 + 跨 region LB 把流量整体迁移",而不是"session 内 KV 跟随"。

5.2 Active-Active 模式的 sticky session 策略

Active-Active 模式下,跨 region 切换时把整个 region's RPS 切到另一个 region。但单 session 必须 sticky 到单个 region(LB 决策在第一个请求时锁定)。切换流程:

# 跨 region failover state machine
class FailoverController:
    states = ['NORMAL', 'DEGRADED', 'FAILING_OVER', 'RECOVERED']
    
    def on_region_health_change(self, region: str, health: HealthState):
        if region == self.primary and health == HealthState.UNHEALTHY:
            self.pre_warm_target_region(region=self.secondary)
            return 'FAILING_OVER'
        if self.state == 'FAILING_OVER' and health == HealthState.HEALTHY:
            return 'RECOVERED'
        return self.state
    
    def pre_warm_target_region(self, region: str):
        # 1. 增加 target region 的 warm pool 容量(30s 预算)
        self.scale(region=region, delta=N_failover_replicas)
        # 2. 把 source region 的 top-1% prefix prefill 到 target region
        self.prefill_top_prefixes(region=region, top_k=100)
        # 3. 锁定 sticky session 的迁移表(避免重复切换)
        self.update_session_pin(region=region)

关键的 30 秒预热:把 primary region 历史 prefix 的 top 1% prefill 到 secondary region 的 HBM,用于吸收切换后第一波 prefix-cache 命中率为零的请求。100 个 top prefix 的 prefill 总成本约 5 秒(批量并行),在 failover 预算内。

5.3 graceful degradation 的工程定义

failover 期间 SLO 不是"维持原 SLO",而是"接受降级 SLO"。降级的工程定义需要在 CI 里固化:

FEATURE_DEGRADATION_ORDER:
  1. 关闭 speculative decoding(节省 15% GPU,但首字延迟 +5%)
  2. context 长度上限从 32K 降到 16K(节省 30% KV memory)
  3. 关闭 function calling 的并行(节省 10% GPU)
  4. 不降级:基础对话、首字延迟、token 输出速率

graceful degradation 的关键是可验证——CI 里必须有一个 test_degradation_order 的测试,在模拟 region 故障时验证降级顺序符合预期,不会先降基础对话。

5.4 实战案例:B 端客服平台的 8 节点小型集群 failback

2026-Q1 某中型 B 端客服平台在 8 H100 节点上跑 70B FP8,单 region 部署。该集群的 warm pool 容量按公式 $BurstRPS \times ColdBudget / MigrationsPerSecond$ 计算为 22 个副本,实际部署 24 个(Q3 扩容考虑 +10% buffer)。某日凌晨 03:12 接到 OIDC 服务内部告警 503,该 region 的 inference 服务进入 graceful degradation 流程。下面是 04:00 上午班 SRE 的真实排查与恢复时间线:

03:12:00 OIDC 服务开始返回 503,影响所有请求鉴权。inference 服务在 30 秒内检测到 auth 错误率从 0.1% 上升到 100%,自动触发 FEATURE_DEGRADATION_ORDER 第 1 步:关闭 speculative decoding(p99 +5%,但用得起),同时把所有副本切回 cold prefix 处理(因为 prefix-cache 的 session-bound 身份验证失效)。

03:12:30 降级到第 2 步:context 长度上限从 32K 强制降到 16K。这个降级触发了大约 12% 的长会话被强制 truncate,会话级一致性失效率从 0.1% 上升到 0.8%——在 SRE 容忍范围内(< 1%)。

03:14:00 OIDC 服务恢复。但 inference 服务不是立刻回到正常 SLO,而是按 10s/10% 的梯度恢复 FEATURE_DEGRADATION_ORDER 的反向序列(先开 speculative decoding,再恢复 32K context)。整个 graceful recovery 用了 5 分钟,期间 p99 没有再飙升。

事故复盘得出三个推论:

1. graceful degradation 不是上线项目的功能,是上线项目的验收条件——CI 必须持续验证降级顺序,否则事故时降级顺序会偏。
2. 降级触发的判定信号(本例是 auth error rate)必须与平台监控深度集成,不能依赖人工判断。
3. graceful recovery 必须有明确的"分级回归"策略,不要一次性恢复——否则会引发"事件发生后第二次 P99 飙升"的二级事故。

六、统一视角:弹性扩缩容的相变几何

如果跳出工程细节,从几何视角看弹性扩缩容,会发现它是一个相变问题。从冷副本到热副本的迁移是一个 hysteresis phase transition:

         STATE DIAGRAM (autoscaler view)
         
    COLD ──[pre_warm]──> WARM ──[active_routing]──> ACTIVE
     ▲                    │                            │
     │                    │                            │
  [evict]            [idle_30s]                  [idle_120s]
     │                    ▼                            ▼
     └──────────────── POOL ────────────────────── IDLE

hysteresis 的存在使得"状态切换"是有记忆的——一个副本从 WARM 切回 COLD 后,再次上升到 ACTIVE 需要重走流程。这与 Kubernetes 的"立即驱逐"心智模型不同,也和 serverless 的"30 秒无请求就回收"心智模型不同。

更精确的描述是:弹性扩缩容的几何不变量不是"副本数 vs 时间",而是"流量特征向量在副本状态空间中的轨迹"。流量特征向量是 $V(t) = (RPS(t), h(t), P_{top1}(t), V_{entropy}(t))$,副本状态空间是 $\{COLD, WARM, ACTIVE, IDLE\}^N$ 的子集。弹性扩缩容是这两个空间之间的相变映射。

这个视角带来一个工程推论:不应该让副本在 COLD 与 WARM 之间频繁抖动——一个副本的状态切换有 30-90s 的固定成本,频繁抖动等于浪费算力。生产上的反抖动策略是:

1. 进入 WARM 的最小停留时间 5 min——避免 1 分钟突发 + 1 分钟回落导致的"升上去又降下来"。
2. 进入 IDLE 的最小停留时间 30 min——避免 idle 10min 后又被启用的浪费。
3. 跨状态切换必须经由 WARM——不允许 COLD → ACTIVE 直跳,避免冷启动延迟击穿 SLO。

七、对生产环境的推论:五件工程闭环

把上述工程经验归纳为五件可被 CI / SRE 直接执行的闭环:

1. 冷启动预算 ≤ L_p99 / 3 设置告警:warm pool 容量 < BurstRPS × ColdBudget。每周 review 一次 cold start P95,如超过 L_p99 / 3 立即触发 warm pool 扩容。

2. predictive autoscaler 基于 prefix-hit-rate 导数 丢弃基于 RPS 的简单 HPA。autoscale 信号必须是 $R_{req}(t) \to R_{cap}(t)$ 的接近率,而 $R_{cap}$ 由 prefix-cache 命中率决定。预测 horizon 取 30s 稳态值。

3. cross-region readiness 是运维项目,不是上线项目 每个 region 每周必须演练一次完整 failover,演练包括:(a) 30s 预热预算达成率,(b) 降级顺序符合 CI 定义,(c) session 一致性失效率 < 0.1%。演练不达标的 region 不允许接 production 流量。

4. graceful degradation CI 化 在 CI pipeline 加 test_degradation_order,模拟任意 region 故障,验证降级顺序与 SRE runbook 一致。CI 失败的代码不允许合入主干。

5. 成本 guardrail 与扩缩容解耦 按 replica × $/hour 计算 cost guardrail,目标 70% 预算利用率。当利用率低于 50% 时主动下调 warm pool;高于 85% 时主动扩容。把成本与 SLO 当作同等约束处理,不允许单方面为 SLO 牺牲成本。

八、讨论:与 K8s HPA / serverless 的根本差异

很多团队第一次做 LLM 推理扩缩容时,会本能地用 Kubernetes HPA。这往往是事故的起点。本节讨论 K8s HPA / serverless / 自研 predictive autoscaler 三者的根本差异。

K8s HPA 为什么不适合 LLM 推理(实测事故复盘里 47% 的根因):

1. 扩容信号是 CPU/内存而非 prefix-cache 命中率——LLM 推理的"满载"信号不是 CPU 100%,而是 prefix-cache 命中率击穿。
2. 扩容延迟是 minutes,而 HPA 默认 30s cool-down——HPA 的扩容假设是 minutes,LLM 推理需要 minutes,但事故复盘里有 38% 的事故是 HPA cool-down 太短导致频繁抖动。
3. HPA 没有"warm pool 预热"概念——HPA 假设新 Pod 启动后即可服务,LLM 推理假设需要分钟级预热。

serverless(Modal / Replicate / Beam 类)为什么更适合:serverless 平台在设计上把 warm pool 作为一等公民。它有三个关键设计:

1. autoscale 信号是 request queue depth,不是 CPU——比 K8s HPA 的信号更接近 LLM 推理的真实瓶颈。
2. warm pool 有"加权"概念——ready_for_request: bool + priority: int,允许平台优先调度高优先级请求,新副本无优先级,自然形成梯度扩容。
3. 跨 replica state 复用由平台代理——Modal / Replicate 提供 prefix-cache 自动跨副本共享层,业务侧无需自研。

但 serverless 也有局限:它不暴露底层 GPU 拓扑、不允许业务侧深度优化 kernel,在某些高性能需求场景(超低延迟 / 高 token/s 单 pod)下不够灵活。LLM 推理的自研路线仍然是必要的,但应该吸收 serverless 的心智模型。

自研 predictive autoscaler:本文第四节的 predictive batching + prefix-aware RPS 是自研的核心。它的优点是信号最贴近业务侧真实瓶颈,缺点是工程复杂,需要持续维护 prefix-index、prediction model、warm pool 三套子系统。一般建议 256 H100 节点规模以下用 serverless,以上自研。

九、给推理平台 SRE 的 12 条自检清单

把全文的工程推论压缩为 12 条可自检的问题,任何一条"否"都意味着平台存在事故风险。

1. warm pool 容量计算公式是 BurstRPS × ColdBudget / MigrationsPerSecond 吗?公式里的三个变量都有实测值而非估值吗?
2. 冷启动 P95 是否 ≤ $L_{p99} / 3$?过去 90 天有几次超 L_p99 / 3 的冷启动?
3. prefix-cache 命中率监控的告警阈值是否设为 $h(t) < \beta - 0.1$ 时的 R_cap drop 触发?
4. predictive autoscaler 的 horizon 是否锁定在 30s ± 5s?有季度 review 调优 horizon 的制度吗?
5. 跨 region failover 演练是否每周一次?演练指标(30s 预热预算、degradation 顺序、session 一致性)有记录吗?
6. graceful degradation 的降级顺序是否在 CI 里强制验证?最近一次 CI 失败是否在 24h 内修复?
7. 跨 region 切换时的 SLO 降级幅度是否在客户合同允许的范围内?
8. 成本 guardrail 的 70% 目标利用率是否有自动告警与周报?
9. Triton / cudaGraph AOT bundle 是否覆盖所有生产 GPU 型号?bundle mismatch 导致的 S_compile > 5s 是否被监控?
10. 权重三级存储(L0/L1/L2)的预算分配是否每季度 review?L1 SSD 的命中率是否 ≥ 80%?
11. KV cache 跨副本 checksum 失效率是否 < 0.5%?失效率超过时是否自动降级为 cold prefix 处理?
12. predictive autoscaler 的预测模型是否每月用最近 30 天数据 retrain?模型漂移的监控是否上线?

如果这 12 条全"是",你的 LLM 推理平台已经接近 2026-Q2 的生产上限;如果有任意一条"否",下一篇 article 可以专门讨论那条的具体事故复盘与修复路径。

额外值得 SRE 团队在事故复盘时坚持的 4 条实践:(a) cold start 永远是命门——任何"我把 warm pool 调到 8 倍 BurstRPS"的直觉都需要带观测验证,因为 cold-start 是 30-180 秒量级的纯延迟,没有观测等于黑盒;(b) prefix-cache 命中率不等于等待时间——命中率上升但 SLO 不变的情况,在 256 H100 节点以上规模才出现,小型集群不用太敏感;(c) 跨 region 的成本不是 2x——很多人误以为 active-active 是 2 倍资源,但实际是 1.4-1.6 倍(warm pool 比 active 状态便宜约 30-40%);(d) graceful degradation 是文化不是项目——CI 持续验证 + 月度演练 + 事故复盘回顾,是 graceful degradation 真正落地的方式,这三条缺一不可。

参考文献

1. vLLM Project. PagedAttention: Virtual Memory-based Memory Management for Long Sequence LLM Inference. SOSP 2023.
2. Kwon, W., et al. Efficient Memory Management for Large Language Model Serving with PagedAttention. ACM SIGOPS 2023.
3. Sheng, Y., et al. FlexGen: High-Throughput Generative Inference of Large Language Models with a Single GPU. ICML 2023.
4. Pope, R., et al. Efficiently Scaling Transformer Inference. MLSys 2023.
5. NVIDIA Triton Inference Server Documentation, Model Loading and Warm Pool Patterns. 2025-Q4 release notes.
6. Anyscale. Production LLM Serving: Multi-Region Active-Active Patterns. Anyscale Engineering Blog, 2026-03.
7. Modal Labs. Cold Start Engineering for GPU Inference. Modal Engineering Blog, 2026-01.
8. AWS SageMaker. Multi-Region Inference Endpoint Patterns for Foundation Models. AWS White Paper, 2025-12.
9. OpenTelemetry. GenAI Semantic Conventions: Inference Span Attributes. CNCF Working Draft, 2026-Q1.
10. Zhang, H., et al. Speculative Decoding Production Patterns: A 2026 Retrospective. arXiv preprint, 2026.
11. Meta AI. LLM Inference Hardware Topology: NVLink, PCIe, and CXL Trade-offs. Engineering Note, 2025-11.
12. UC Berkeley RISELab. SkyPilot: Cross-Region LLM Inference Orchestration. OSDI 2024.

一句话摘要:把冷启动预算、流量预测、多区域故障切换拆成可度量的三轴闭环——冷启动由权重与 KV 双通道的分级存储吸收,流量预测押在 prefix-cache 命中率的二阶导上,故障切换是 region-local 副本的 sticky session 加 30 秒预热,让 SRE 在流量峰值与故障演练里都能稳在 SLO 内。