LLM Serving 的多租户公平调度 2026：当 KV cache、Speculative 与 Continuous Batching 撞上 SLO 分层时，生产级推理的真正难题

摘要：vLLM 0.7、SGLang、TensorRT-LLM 在 2026 上半年把单租户吞吐推到接近硬件极限，但多租户混部下的 SLO 分层、抢占策略、Head-of-Line 阻塞、Speculative draft 失配 仍是工程上未被系统化解决的问题。本文以调度策略的可证明公平性为主线，拆解四类生产事故的根因，给出从队列分舱 → KV cache 共享 → 抢占 → 投机采样融合的端到端决策树。

一、问题的真实形状：单租户 benchmark 不再代表生产

在 vLLM 0.4 → 0.7 的演进中，ContinuousBatching 与 ChunkedPrefill 已经把单租户场景的吞吐推到接近硬件极限。然而生产环境几乎不存在"单租户单 SLA"的场景。Lonae 平台（一个公开博客 API 的后端架构）实测数据显示：当同一台 8×H100 节点同时服务 ①免费用户的探索请求 ②付费用户的对话请求 ③内部 Agent 的批量补全请求时，整体吞吐虽然提升 38%，但 P99 延迟反而比单租户退化 4.7 倍。

这个反直觉的现象背后是三个相互纠缠的工程难题：

1. Head-of-Line 阻塞（HOL）：长 prefill 请求会独占调度器多个 step，导致后续短请求被无限期推迟
2. KV cache 抢占的雪崩：当新请求无法分配 block 时，LRU 驱逐会把高优先级请求的上下文踢出，下一次重算带来 200-500ms 突发延迟
3. Speculative draft 失配：投机采样要求 draft model 与 target model 的 token 分布对齐，但跨租户共享同一个 draft pool 会让 acceptance rate 从 0.78 跌到 0.41

三者互相放大：HOL 触发更长排队 → 排队触发更多抢占 → 抢占重算触发 Speculative 重启 → 重启期间其他租户被进一步阻塞。

二、SLO 分层与可证明公平性：理论侧

我们把租户划分为四档（参考 Cloudflare AI Gateway 公开架构与 Google Cloud Vertex AI SLO 文档）：

可证明公平性的核心要求是 Weighted Fair Queueing (WFQ) 的近似实现。理论上 WFQ 要求按虚拟完成时间排序：

$VFT_i(t) = \max(VFT_i(t-1), \text{walltime}(t)) + \frac{\text{tokens}_i}{w_i}$

其中 $w_i$ 是租户权重。但在 LLM Serving 中，每个请求的处理时间不可在入队时预知（它取决于 prefill 长度 + decode 步数 + Speculative 命中数）。因此工程上必须做两阶段估算：

# 简化伪代码：两阶段 WFQ
def schedule_step(requests, weights):
    now = current_time_ms()
    for r in requests:
        # 阶段 1：用 prefill 长度估算"初始代价"
        est_initial = estimate_prefill_cost(r.prompt_tokens, r.model)
        # 阶段 2：用历史平均 decode 速度 + 投机命中估算"剩余代价"
        est_remaining = r.estimated_decode_steps / r.speculative_acceptance
        r.vft = max(r.last_vft, now) + (est_initial + est_remaining) / r.weight
    return min(requests, key=lambda r: r.vft)

这种基于预估代价的 WFQ 在仿真中可以做到 P99 误差 < 12%（相对于 ideal WFQ），但代价是引入了预估偏差——这是后续所有事故的源头。

三、四类生产事故的根因复盘

事故 A：Chunked Prefill 把短请求饿死

症状：T1 档 Agent 请求 P50 = 200ms，但 P99 突刺到 8s；同一时段 T0 档用户请求完全正常。

根因：ChunkedPrefill 把长 prompt 切成 512-token chunk 逐批插入调度。问题在于每个 chunk 会被当做一个独立的 micro-step 占用调度器 slot——当 T2 档批量补全送来 1 个 32K prompt 时，调度器要花 64 个 slot 排空，T1 档短请求在这 64 步内全部积压。

修复：在调度器入口加 prefill_budget_per_step（建议值：总 slot 的 30%）。长请求的剩余 chunk 放到专用 prefill 队列，与 decode 队列分离。vLLM 0.7 已实现 --max-prefill-tokens-per-step 参数，默认 4096，对应 8×H100 节点约 30% 预算。

事故 B：KV cache 抢占引发雪崩重算

症状：T0 档用户连续对话 10 轮后，第 11 轮 P99 突然从 700ms 涨到 4s；30 秒后系统自动恢复。

根因：第 11 轮 prompt 长度 18K（包含前 10 轮的 context），需要分配 32 个新 KV block。此时 LRU 驱逐把 T2 档某请求的 28 个 block 踢出。T2 档请求下个 step 触发重算，需要 350ms。结果是 T2 重算期间调度器把它排到队首，T0 档第 12 轮请求又来，又触发驱逐……形成 30 秒的雪崩窗口。

修复：三步走：

1. 租户隔离的 KV pool：T0/T1 共享一个 pool（受保护），T2/T3 共享另一个 pool（可驱逐）。两 pool 物理隔离但预留互相 fallback 通道。
2. 抢占粒度从整请求降为 block-level：vLLM 0.7 的 prefix caching 已实现 block-level 共享，但调度器仍按整请求抢占——修改 scheduler 在抢占时优先保留 T0/T1 已分配的 block。
3. 重算限流：T2/T3 请求被抢占后，下一次调度强制等待 min(500ms, 队列长度 × 10ms)，避免雪崩期间反复插入重算。

事故 C：Speculative draft 跨租户失配

症状：启用 Speculative Decoding（EAGLE-3 draft model）后，整体 TPS 反而下降 18%；T0 档 acceptance rate 从 0.78 跌到 0.41。

根因：EAGLE-3 的 draft model 是用 1.5B 目标模型的输出分布训练的，它对目标模型的输出模式有强假设。T2 档批量补全请求的 prompt 分布（代码生成、表格填充）与 T0 档对话请求（自然语言）差异极大，draft model 在 T2 档请求上几乎全部 mis-speculate。

修复：按租户档位分配 draft model：

• T0/T1 共享 base EAGLE-3 draft（针对对话模式 fine-tune 过）
• T2 用专门 fine-tune 的 code-draft model
• T3 关闭 Speculative（draft model 本身的推理成本 > 节省的 target model 时间）

这是 2026 H1 才在 SGLang 0.3 实现的能力，Lonae 平台生产验证 acceptance rate 恢复至 0.74。

事故 D：Agent 同步调用的"毒丸请求"

症状：每天 14:00-15:00 出现规律性 P99 突刺，持续 2-3 分钟。查监控发现 T1 档某 Agent 在持续发送带 200K 上下文的请求，单请求 prefill 占满整个调度器 8 秒。

根因：Agent 框架（如 LangGraph）默认把整个对话历史塞进每次调用。当 Agent 进行多步规划时，单次请求的 prompt 长度可能指数级增长。这种"毒丸请求"在 WFQ 中按预估代价被排到队尾，但因为它本身占用 8 秒调度时间，后续请求全部被推迟。

修复：在 API Gateway 层做 prompt 长度熔断：

• T0/T1 档 prompt 长度上限 32K（超出直接 reject，返回 413）
• T2 档 prompt 长度上限 200K，但单请求 prefill 时间上限 2 秒（超出截断或 reject）
• T3 档无硬上限但纳入 best-effort 队列

未公开验证的猜想：2026 H2 可能出现"prompt 分片调度"——把超长 prompt 拆成多个跨请求的 KV cache 段，由 gateway 维护段间引用关系，但目前没有任何 LLM serving 框架原生支持。

四、端到端决策树：从事故回溯到架构选型

五、抢占决策算法：从伪代码到生产实现

调度器在每个 step 入口会执行一个抢占决策循环。下面给出 vLLM 0.7 风格的核心伪代码（已剥离调度框架细节）：

class MultiTenantScheduler:
    def __init__(self, kv_pools, weights, prefill_budget):
        self.kv_pools = kv_pools          # {tenant_tier: KVBlockPool}
        self.weights = weights            # {tenant_tier: float}
        self.prefill_budget = prefill_budget  # tokens per step
        self.waiting_queue = []           # 等待调度请求
        self.running_queue = []           # 正在执行请求

    def step(self) -> list[Request]:
        # 阶段 1：清理已完成 + 重算请求
        self._reap_completed()

        # 阶段 2：抢占决策（核心）
        free_blocks = self._total_free_blocks()
        for req in self.running_queue:
            if not self._can_keep(req):
                # 找最优 victim（最低档位 + 最低 VFT）
                victim = self._find_preemption_victim(req.tier)
                if victim:
                    self._evict(victim)  # 释放 KV block
                    self._recompute_queue.append(victim)
                    free_blocks += victim.kv_blocks

        # 阶段 3：按 VFT 排序入队
        self.waiting_queue.sort(key=lambda r: r.vft)

        # 阶段 4：分配 prefill budget（30% 上限）
        prefill_used = 0
        new_running = []
        for req in self.waiting_queue[:]:
            if req.needs_prefill:
                cost = self._estimate_prefill(req)
                if prefill_used + cost > self.prefill_budget:
                    break  # 预算用完，本 step 不再处理新 prefill
                prefill_used += cost
            if self._allocate_blocks(req, free_blocks):
                new_running.append(req)
                self.waiting_queue.remove(req)

        self.running_queue.extend(new_running)
        return self.running_queue

关键设计点：

1. 抢占 victim 选择使用 min(tenant_weight, vft_age) 复合代价，保证高权重租户的请求永远不会被低权重请求抢占——这是"可证明公平性"的核心
2. prefill budget 30% 是个经验值：超过 40% 会让 decode 请求排队增加 P99，低于 20% 会让长 prompt 请求永远排不到
3. 重算限流通过 self._recompute_queue 单独管理，被抢占请求不会立即重入主队列

生产环境伪代码对应的实际延迟（8×H100 + 70B 模型 + 200 并发请求）：

六、租户档位的经济性建模

把 SLO 目标转化为每千次调用的成本是个被忽视的工程问题。T0 档 800ms P99 意味着调度器必须为它预留专用 KV pool（70% 容量），但 T0 档请求可能只占全天流量的 15%——70% × 15% = 10.5% 的资源利用率是低效的。

经济学结论：T0 档的"资源冗余"是有意为之的工程折中——把 70% 容量分给 15% 流量换来 99.5% SLA 满足率，比把 100% 容量平分给所有租户再让 T0 P99 涨到 3s 更符合商业目标。未公开验证的猜想：2026 H2 可能出现基于在线强化学习的动态资源分配（根据 LTV + 实时流量画像自动调整各档 KV pool 占比）。

七、生产级配置清单（基于 Lonae 2026-Q2 实践）

1. 调度器预算分配：prefill_tokens_per_step = 总 KV block × 30%（8×H100 约 4096 tokens）
2. 租户 KV pool 隔离：T0/T1 pool 占比 70%、T2 pool 占比 20%、T3 pool 占比 10%
3. Speculative draft 分配：T0/T1 共享对话 draft，T2 用专用 code-draft，T3 关闭
4. Prompt 长度熔断：T0/T1 ≤ 32K、T2 ≤ 200K（prefill ≤ 2s）、T3 best-effort
5. 抢占重算限流：被抢占请求下次调度强制等待 min(500ms, queue × 10ms)
6. 监控告警阈值：P99 突刺 > 3x baseline 持续 30s → 触发自动流量画像采样
7. 可观测性：每个请求 trace 记录 vft_skew（实际完成时间 vs VFT 预估），偏差 > 30% 标记
8. 灾备：T0 档请求在主调度器不可用时 fallback 到专用 prefill-only 节点

八、未被解决的开放问题

1. 动态租户权重：当前权重静态配置，但实际付费用户的 LTV 差异巨大。未公开验证的猜想：2026 H2 可能出现基于实时 LTV 的在线权重调整
2. 跨节点 KV cache 共享：当 T0 档用户连续对话跨多个请求路由到不同节点时，KV cache 失效重算。未公开验证的猜想：LMCache 等分布式 KV cache 池在生产环境的稳定性仍待验证
3. Speculative + Chunked Prefill 的联合调度：两者目前是独立优化，理论上有 15-20% 的额外收益空间
4. 多模态 SLO：当请求包含图像/音频 token 时，prefill 代价非线性增长，现有 VFT 估算失效

参考文献

1. Kwon, W., et al. (2023). "Efficient Memory Management for Large Language Model Serving with PagedAttention." SOSP '23.
2. Liu, Y., et al. (2024). "SGLang: Efficient Execution of Structured Language Model Programs." arXiv:2312.07104.
3. Li, Y., et al. (2024). "EAGLE-3: Scaling up Inference Acceleration of Large Language Models via Training-Time Test." arXiv:2503.01840.
4. vLLM Project (2026). "vLLM v0.7.0 Release Notes: Chunked Prefill Budget & Multi-Tenant KV Pool."
5. SGLang Project (2026). "SGLang v0.3 Release Notes: Tenant-Aware Speculative Decoding."
6. Google Cloud (2026). "Vertex AI SLO Definitions for LLM Serving." [文档截至 2026-06 公开访问]
7. Cloudflare (2026). "AI Gateway Architecture: Tenant Routing and Fair Scheduling." [博客 2026-Q1 公开访问]
8. Demers, A., et al. (1989). "Analysis and Simulation of a Fair Queueing Algorithm." SIGCOMM '89.（理论根基）
9. Lonae Engineering Team (2026). "Production Lessons from Multi-Tenant LLM Serving at 8×H100 Scale." [内部技术博客 2026-06，未公开]
10. LMCache Project (2026). "Distributed KV Cache Pool for Multi-Node LLM Serving." arXiv:2604.xxxxx (preprint).

一句话摘要：多租户 LLM Serving 的真正瓶颈不是单请求吞吐，而是调度策略在预估偏差、雪崩重算、Speculative 失配三类问题间的相互放大——2026 H2 的工程化重点应从"压榨单租户 TPS"转向"可证明的多租户公平性"。