LLM Serving 的突发流量整形与背压控制工程 2026：当 admission control、KV cache 复用与 SLO 防御撞上 GPU 利用率天花板时
LLM 服务的突发流量是「QPS × token 密度」双轴负载，传统 autoscaling 完全失效。本文提出三维 admission control + 自适应 cache eviction + SLO 隔离的工程组合，把突发从故障转译为可预测的资源调度问题。
约 17 分钟阅读4,885 字25 次阅读博主
LLM 服务的突发流量是「QPS × token 密度」双轴负载，传统 autoscaling 完全失效。本文提出三维 admission control + 自适应 cache eviction + SLO 隔离的工程组合，把突发从故障转译为可预测的资源调度问题。
在 2026 年的 LLM 推理服务工程领域，「多租户公平调度」「Continuous Batching」「KV cache 复用」已经是被反复讨论过的话题——vLLM 0.7 调度器的演进（id=249）、Prefix Cache 工程实战（id=284）、Speculative Decoding 的生产化（id=255）都各自沉淀了范式。但有一个边界场景至今未在工程化层面被系统化讨论：当流量从平稳态骤变为突发态（bursty traffic）时，admission control、KV cache 复用与 SLO 防御这三者之间的张力如何被工程化地解决。本文聚焦这一空白。
LLM 推理服务的负载形态与经典 Web 服务有本质差异。Web 服务的负载可被「QPS 峰值」一维刻画，但 LLM 服务是双轴负载：
其中 token_density 指每请求的 prompt + generation token 数。当 ChatGPT 类应用出现"插件风暴"（单次 prompt 从 200 token 暴涨到 8K token）或 Agent 任务密集提交（每请求 30K+ token）时，GPU 的 token 吞吐量上限是物理硬约束——以 H100 SXM 为例，FP8 推理约 3000 tokens/s/GPU 的稳态吞吐，在 200ms prefill SLO 下可服务的并发上限约 150 路，但 prompt 从 200 涨到 8K 后这一上限骤降到约 4 路。
# LLM serving 的双轴负载模型
def gpu_saturation_point(prompt_len, gen_len, prefill_slo_ms=200):
# H100 SXM FP8, 简化模型
prefill_throughput = 3000 / (prompt_len / 1000) # token/s/GPU
decode_throughput = 200 # token/s/request
concurrent = prefill_throughput * (prefill_slo_ms / 1000) / (prompt_len / 1000)
return min(concurrent, decode_throughput * 1000 / gen_len)
这个计算揭示了一个反直觉的事实：QPS 不变但 prompt 长度翻倍，足以让 GPU 饱和度从 30% 跳到 100%。传统的 CPU-bound 微服务 autoscaling 策略（K8s HPA on CPU）在 LLM 场景下完全失效。
经典 admission control 的二元决策（接受/拒绝）在 LLM 场景下颗粒度太粗。生产级实现需要三维 admission control：
图表加载中…
这套架构的核心创新在于把"拒绝"转译为"队列延迟"——经济敏感的租户可以排队等待，预算敏感的租户可以付费换取 admission。OpenAI 的 Tier 1/2/3 服务、Anthropic 的 Priority/Standard 队列都是这套模式的商业化变种。
Prefix Cache 工程（id=284）讨论的是稳态下的命中率和成本节省，但在突发流量下 KV cache 复用呈现出相变行为：
应对这一相变的工程化方案是自适应 cache eviction：
# 自适应 KV cache 淘汰策略（伪代码）
def should_evict_block(block, current_load):
reuse_rate = block.hit_count / block.lifetime_s
cost_of_eviction = block.compute_to_rebuild_ms
if current_load > 0.8: # 高负载
# 激进淘汰低命中率 block，释放显存给 active batch
threshold = 0.05
elif current_load > 0.5: # 中负载
threshold = 0.15
else: # 低负载
threshold = 0.30 # 保守淘汰，保留复用机会
return reuse_rate < threshold and cost_of_eviction > MEMORY_VALUE_MS
这种「按 GPU 负载动态调整 cache 策略」的设计是 2026 年 LLM serving 工程的最新前沿，截至 2026 年公开文献中尚未有系统化论述——本文据 vLLM 0.7 源码、Anthropic 公开 blog 与多份厂商技术分享综合推断。
突发流量下的 backpressure 与传统 TCP 流控的拥塞控制有相似之处，但实现机制必须感知 GPU 调度状态：
RTT-style backpressure signal:
sender → admission_control: POST /v1/chat
admission_control → token_pool: reserve(N tokens)
token_pool → GPU_scheduler: enqueue with priority
GPU_scheduler → admission_control: backpressure_score ∈ [0, 1]
admission_control → sender: HTTP 429 with Retry-After
backpressure_score 的计算公式为：
其中 ，典型配置为 。当 时，admission control 进入"硬拒绝"模式，发送 HTTP 429 + Retry-After: 30s。
当 burst 持续时间超过 KV cache 自我调节能力（典型为 5-15 分钟），需要更激进的策略：
图表加载中…
2026 年公开披露的 LLM serving 突发流量事故主要分四类：
SLO 防御的核心是隔离爆炸半径：
# 租户级 SLO 隔离（伪代码）
class TenantSLOLane:
def __init__(self, tenant_id, slo_target_ms, priority):
self.tenant_id = tenant_id
self.slo_target_ms = slo_target_ms
self.priority = priority
self.dedicated_token_quota = None # 默认共享
self.fail_open = True # 违约时降级而非失败
def admit(self, request):
if self.priority == "premium":
return ADMIT # 永不被拒绝
elif self.dedicated_token_quota and self.tokens_used > self.dedicated_token_quota:
return REJECT # 配额耗尽硬拒绝
else:
return ADMIT_WITH_BACKPRESSURE
突发流量下最容易失控的是成本计量。每请求的 GPU 成本由三部分构成：
其中 和 是动态的——burst 期间由于 KV cache 命中率下降， 会涨 30-50%。这意味着固定单价的定价模型在 burst 期间会出现亏损。
工程化的解决方案是动态成本感知定价（dynamic cost-aware pricing）：
这套机制据 Cloudflare AI Gateway 2025 公开 blog 中"dynamic pricing hints"功能的描述推断，但截至 2026 年公开技术报告未发现完整开源实现。
以下为基于多份公开技术分享与事故复盘总结的工程化调优清单（据 vLLM / TGI / Triton Inference Server 2025-2026 公开配置推断）：
# 1. 设置双轴 HPA（QPS + token 密度）
hpa_metrics:
- type: Pods
metric: requests_per_second
target: 100
- type: External
metric: tokens_per_second_per_gpu
target: 2800 # H100 FP8 稳态上限的 93%
# 2. KV cache 动态淘汰
cache_eviction:
high_load_threshold: 0.85
low_load_threshold: 0.50
min_reuse_rate: 0.05 # 低于此值立即淘汰
# 3. Admission control 优先级队列
priority_queues:
- name: premium
weight: 0.40
sla_ms: 200
- name: standard
weight: 0.45
sla_ms: 800
- name: batch
weight: 0.15
sla_ms: 5000
# 4. Graceful degradation 触发条件
degradation:
trigger: queue_depth > 5000 OR gpu_util > 0.92
max_token_per_request: 32000
paging_threshold_tokens: 1024
# 5. Cost-aware pricing 窗口
pricing_window_seconds: 300
miss_rate_premium_threshold: 0.30
premium_multiplier: 1.20
生产环境中最被低估的 burst 副作用是计费漂移（billing drift）。标准计费公式假设 prompt 与 generation token 是「可加性的资源消耗」，但 burst 期间 KV cache 命中率下降会让 prefill 成本非线性上升。据 Cloudflare 2025 AI Gateway 公开 blog 推断，典型云厂商的「per-token」定价未充分反映这一非线性——结果是：用户在 burst 期间为同样的 token 数支付了 1.2-1.5 倍的实际 GPU 资源。
工程化解决方案是双账本计量（dual-ledger metering）：
# 双账本计量伪代码
class DualLedgerMeter:
def __init__(self):
self.user_ledger = {} # 用户视角：per-token 固定单价
self.cost_ledger = {} # 成本视角：动态 per-token 实际 GPU 成本
def record_request(self, tenant, prompt_tokens, gen_tokens, cache_miss_rate):
user_charge = (prompt_tokens + gen_tokens) * self.user_unit_price
# 实际成本：考虑 cache miss 的 prefill 重算
actual_prefill_cost = prompt_tokens * (1 + cache_miss_rate * 0.5) * self.gpu_prefill_price
actual_decode_cost = gen_tokens * self.gpu_decode_price
actual_cost = actual_prefill_cost + actual_decode_cost
self.user_ledger[tenant] = self.user_ledger.get(tenant, 0) + user_charge
self.cost_ledger[tenant] = self.cost_ledger.get(tenant, 0) + actual_cost
def margin_warning(self, tenant):
if self.cost_ledger[tenant] > self.user_ledger[tenant] * 1.15:
return f"WARNING: tenant {tenant} margin < -15% under burst"
当 margin_warning 触发时，运营侧有两种选择：调高 burst 期间的计费系数（最直接），或优化 cache 策略以缩小成本差（长期解）。前者短期能止损但可能流失用户，后者工程投入大但建立长期护城河。
以下为基于当前公开信息的前瞻性推断，未经独立验证：
Predictive Admission Control：基于历史 burst 模式训练 lightweight 预测模型（推测 1B 参数），在 burst 发生前 30-60 秒主动收紧 admission，避免「事后反应」延迟。据 Datadog 2026 公开 blog 中提到的"predictive scaling"概念延伸。该方案对预测模型的精度要求极高——若误报率 > 5%，反而会造成稳态期间的过度拒绝。
Cross-Tenant Cache Marketplace：允许低优先级租户的 KV cache 在 burst 期被高优先级租户「租用」，按 token 复用计费。这是一种把 cache 资源商品化的范式，截至 2026 年公开技术报告未发现生产实现。该方案的关键技术挑战是 cache 隔离（不同租户的 prompt 不能混入同一 block）与 tokenization 一致性（必须使用完全相同的 tokenizer 才能复用）。
GPU 资源期货市场：把 GPU 时段打包成「preemptible spot instance」类的金融产品，burst 期可动态购买。推测将首先在 Cloudflare AI Gateway、CoreWeave 等 hyperscaler 出现。这种「算力期货」模式如果落地，将彻底改变 LLM serving 的成本结构——稳态期按 on-demand 付费，burst 期按期货合约批量锁价。
LLM serving 的突发流量整形与背压控制是一个尚未被工程界系统化讨论的空白。本文从双轴负载模型出发，提出了三维 admission control + 自适应 cache eviction + SLO 隔离的组合方案，并给出了生产级配置清单。这套范式的核心思想是：把"突发"从「故障」转译为「可预测的资源调度问题」——admission control、cache 复用、cost 计量三者必须协同设计才能在 GPU 利用率天花板下守住 SLO。
摘要：LLM 服务的突发流量是「QPS × token 密度」双轴负载，传统 autoscaling 完全失效。本文提出三维 admission control + 自适应 cache eviction + SLO 隔离的工程组合，把突发从故障转译为可预测的调度问题，并给出生产级配置清单。
Conversation
0 条