大模型推理服务 QoS 保障机制研究

调研日期： 2026-04-15 所属域： 大模型框架 调研 ID： qos-8z0v

目录

1. 概念剖析
2. 行业情报
3. 方案对比
4. 精华整合

第一部分：概念剖析

1. 定义澄清

通行定义

大模型推理服务 QoS（Quality of Service，服务质量）保障机制，是指在多租户、高并发的 LLM（Large Language Model）推理服务场景中，通过系统化的调度、资源管理和请求控制策略，确保服务能够满足预设的性能指标（如延迟、吞吐、可用性）的一整套技术体系。其核心目标是在有限的计算资源约束下，最大化资源利用率的同时，为不同优先级的用户/请求提供差异化的服务质量保证。

常见误解

边界辨析

2. 核心架构

┌─────────────────────────────────────────────────────────────────┐
│                    大模型推理服务 QoS 系统架构                    │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│   请求入口层                                                      │
│   ┌─────────────┐  ┌─────────────┐  ┌─────────────┐            │
│   │  API Gateway │  │  Auth &     │  │  Rate       │            │
│   │  (路由/鉴权)  │→ │  Quota     │→ │  Limiter    │            │
│   └─────────────┘  └─────────────┘  └─────────────┘            │
│          ↓                                                        │
│   ┌─────────────────────────────────────────────────────────┐   │
│   │                    调度决策层                            │   │
│   │  ┌───────────┐  ┌───────────┐  ┌───────────┐           │   │
│   │  │ Priority  │  │  SLO      │  │  Load     │           │   │
│   │  │ Queue     │  │  Analyzer │  │  Balancer │           │   │
│   │  │ (优先级队列)│  │ (SLA 分析) │  │ (负载均衡) │           │   │
│   │  └───────────┘  └───────────┘  └───────────┘           │   │
│   └─────────────────────────────────────────────────────────┘   │
│          ↓                                                        │
│   ┌─────────────────────────────────────────────────────────┐   │
│   │                    推理执行层                            │   │
│   │  ┌───────────┐  ┌───────────┐  ┌───────────┐           │   │
│   │  │ Continuous│  │  Preemptive│  │  KV Cache │           │   │
│   │  │ Batching  │  │  Scheduler │  │  Manager  │           │   │
│   │  │ (连续批处理)│  │ (可抢占调度)│  │ (缓存管理) │           │   │
│   │  └───────────┘  └───────────┘  └───────────┘           │   │
│   └─────────────────────────────────────────────────────────┘   │
│          ↓                                                        │
│   ┌─────────────────────────────────────────────────────────┐   │
│   │                    资源管理层                            │   │
│   │  ┌───────────┐  ┌───────────┐  ┌───────────┐           │   │
│   │  │ GPU       │  │  Memory   │  │  Auto     │           │   │
│   │  │ Pool      │  │  Allocator│  │  Scaler   │           │   │
│   │  │ (GPU 池)   │  │ (内存分配) │  │ (自动扩缩) │           │   │
│   │  └───────────┘  └───────────┘  └───────────┘           │   │
│   └─────────────────────────────────────────────────────────┘   │
│          ↓                                                        │
│   ┌─────────────────────────────────────────────────────────┐   │
│   │                    监控反馈层                            │   │
│   │  ┌───────────┐  ┌───────────┐  ┌───────────┐           │   │
│   │  │ Metrics   │  │  Alerting │  │  Feedback │           │   │
│   │  │ Collector │  │  System   │  │  Loop     │           │   │
│   │  │ (指标采集) │  │ (告警系统) │  │ (反馈回路) │           │   │
│   │  └───────────┘  └───────────┘  └───────────┘           │   │
│   └─────────────────────────────────────────────────────────┘   │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

数据流向：用户请求 → 入口层 → 调度层 → 执行层 → 资源层 → 响应返回
          ↑                                              ↓
          └──────────────── 监控反馈回路 ────────────────────┘

组件职责说明：

3. 数学形式化

公式 1：服务等级目标（SLO）满足率

其中 $T_i$ 是第 $i$ 个请求的实际延迟，$T_{\text{target}}^{(p_i)}$ 是优先级 $p_i$ 对应的目标延迟阈值，$\mathbb{I}(\cdot)$ 是指示函数。

公式 2：加权公平队列调度权重

调度权重由优先级、等待时间和 token 预算共同决定，$\alpha + \beta + \gamma = 1$ 为权重系数。

公式 3：KV 缓存内存需求模型

其中 $B$ 为批大小，$L$ 为序列长度，$H$ 为注意力头数，$D$ 为每头维度，$S=2$ 表示 Key 和 Value 两个矩阵，precision 为精度字节数（FP16=2，INT8=1）。

公式 4：连续批处理吞吐优化增益

通过将不同长度的请求动态打包，减少 GPU 空闲时间，提升整体吞吐量。

公式 5：多租户资源隔离保证

确保每个租户 $i$ 分配到的资源比例不低于其最小保障份额。

4. 实现逻辑

class QoSInferenceSystem:
    """
    大模型推理服务 QoS 保障系统核心实现
    体现优先级调度、连续批处理、可抢占执行等关键机制
    """

    def __init__(self, config):
        # 配置参数
        self.max_batch_size = config.get('max_batch_size', 256)
        self.slo_targets = config.get('slo_targets', {
            'premium': 100,    # ms
            'standard': 500,   # ms
            'free': 2000       # ms
        })

        # 核心组件
        self.priority_queue = PriorityMultiQueue()      # 多优先级队列
        self.kv_cache_manager = PagedKVCacheManager()   # 分页 KV 缓存管理
        self.slo_monitor = SLONumbersMonitor()          # SLO 实时监控
        self.preemptive_scheduler = PreemptiveScheduler()  # 可抢占调度器

        # 状态跟踪
        self.running_requests = {}  # 运行中的请求
        self.completed_requests = []  # 已完成的请求

    def enqueue_request(self, request):
        """
        请求入队：根据优先级和配额决定入队策略
        """
        # 检查速率限制
        if not self.rate_limiter.allow(request.user_id):
            return RejectResponse(reason="rate_limit_exceeded")

        # 计算动态优先级（考虑用户等级、等待时间、SLO 紧迫度）
        dynamic_priority = self._compute_dynamic_priority(request)

        # 加入对应优先级队列
        self.priority_queue.push(request, priority=dynamic_priority)

        return AcknowledgeResponse(queue_position=dynamic_priority)

    def schedule_batch(self):
        """
        调度决策：从队列中选择请求组成批次
        体现连续批处理和可抢占调度的核心逻辑
        """
        # 获取当前运行的请求（可能正在被抢占）
        running = list(self.running_requests.values())

        # 检查是否有高优先级请求需要抢占
        preemptible = self.preemptive_scheduler.find_preemptible(
            running, self.priority_queue.peek_high_priority()
        )

        if preemptible:
            # 执行抢占：暂停低优先级请求，释放 KV 缓存
            for req in preemptible:
                self._preempt_request(req)

        # 从队列中选择请求填充批次
        selected = []
        remaining_capacity = self.max_batch_size - len(running) - len(preemptible)

        while remaining_capacity > 0 and not self.priority_queue.is_empty():
            request = self.priority_queue.pop_highest_priority()

            # SLO 感知选择：优先选择即将超时的请求
            if self.slo_monitor.is_urgent(request):
                selected.insert(0, request)  # 插入队首
            else:
                selected.append(request)

            remaining_capacity -= 1

        return running + preemptible + selected

    def execute_batch(self, batch):
        """
        执行批次：连续批处理的核心执行逻辑
        """
        # 为批次中的每个请求分配 KV 缓存
        for request in batch:
            cache_blocks = self.kv_cache_manager.allocate(
                request.expected_length
            )
            request.cache_handle = cache_blocks

        # 执行前向传播（简化表示）
        # 实际实现中，不同请求的 token 生成是异步的
        outputs = self.model.generate(
            inputs=[r.prompt for r in batch],
            kv_caches=[r.cache_handle for r in batch]
        )

        # 处理输出：检查是否有请求完成
        completed = []
        still_running = []

        for request, output in zip(batch, outputs):
            request.append_token(output)

            if request.is_complete() or request.is_timeout():
                completed.append(request)
                self.kv_cache_manager.release(request.cache_handle)
            else:
                still_running.append(request)

        # 更新运行状态
        for req in still_running:
            self.running_requests[req.id] = req

        # 从运行列表中移除已完成的请求
        for req in completed:
            del self.running_requests[req.id]
            self.completed_requests.append(req)

        return completed

    def _compute_dynamic_priority(self, request):
        """
        计算动态优先级：综合考虑多个因素
        """
        base_priority = self._get_user_tier_priority(request.user_id)

        # SLO 紧迫度：越接近超时，优先级越高
        slo_urgency = self.slo_monitor.compute_urgency(request)

        # 等待时间惩罚：等待时间越长，优先级提升
        wait_penalty = min(request.wait_time / 1000, 0.5)  # 最多提升 0.5

        # 综合优先级（0-1 范围，越大优先级越高）
        priority = 0.5 * base_priority + 0.3 * slo_urgency + 0.2 * wait_penalty

        return priority

    def _preempt_request(self, request):
        """
        抢占请求：保存状态，释放资源
        """
        # 保存当前生成状态
        checkpoint = {
            'tokens_generated': request.tokens_generated,
            'kv_cache_state': self.kv_cache_manager.save_state(request.cache_handle),
            'sampling_state': request.sampling_state
        }
        request.checkpoint = checkpoint

        # 释放 KV 缓存（但保留检查点以便恢复）
        self.kv_cache_manager.partial_release(request.cache_handle)

        # 从运行列表移除，加入等待队列
        del self.running_requests[request.id]
        self.priority_queue.push(request, priority=request.priority, resumable=True)


class PriorityMultiQueue:
    """
    多优先级队列实现：支持动态优先级调整和可恢复请求
    """

    def __init__(self, num_priorities=3):
        self.queues = {i: deque() for i in range(num_priorities)}
        self.resumable_queue = deque()  # 被抢占的请求队列

    def push(self, request, priority, resumable=False):
        if resumable:
            self.resumable_queue.append(request)
        else:
            self.queues[priority].append(request)

    def pop_highest_priority(self):
        # 优先处理可恢复的请求（已被抢占过的）
        if self.resumable_queue:
            return self.resumable_queue.popleft()

        # 按优先级从高到低选择
        for priority in sorted(self.queues.keys(), reverse=True):
            if self.queues[priority]:
                return self.queues[priority].popleft()

        return None

    def peek_high_priority(self):
        """查看最高优先级队列的队首元素（不弹出）"""
        for priority in sorted(self.queues.keys(), reverse=True):
            if self.queues[priority]:
                return self.queues[priority][0]
        return None

5. 性能指标

6. 扩展性与安全性

水平扩展

1. 请求分片 (Sharding)：按用户 ID、模型类型或请求哈希将请求分散到多个推理实例
2. 一致性哈希：保证同一用户的请求尽可能路由到同一实例，提高缓存命中率
3. 跨区域复制：在多区域部署服务，就近接入降低延迟，同时提供容灾能力
4. 联邦调度：全局调度器协调多个集群的负载，实现跨集群的资源借用和迁移

垂直扩展

1. 张量并行 (Tensor Parallelism)：单模型跨多 GPU，支持更大模型或更高吞吐
2. 流水线并行 (Pipeline Parallelism)：将模型层切分到不同 GPU，减少单卡显存压力
3. 专家并行 (Expert Parallelism)：MoE 模型中不同专家分布到不同设备
4. CPU 卸载：将部分计算或缓存卸载到 CPU 内存，扩展单节点容量上限

安全考量

第二部分：行业情报

1. GitHub 热门项目（17 个）

数据来源说明： Stars 数量为约数，基于 2025-2026 年社区活跃度估算。实际数据请访问 GitHub 查看实时统计。

2. 关键论文（12 篇）

选择说明：

• 经典高影响力论文（vLLM、Orca）：奠基性工作，奠定现代 LLM 服务架构
• 最新 SOTA 论文（2024-2025）：反映当前技术前沿，如推测解码、解耦架构、可抢占调度

3. 系统化技术博客（10 篇）

选择说明：

• 英文来源覆盖：个人专家（Eugene Yan, Chip Huyen）、厂商博客（OpenAI, Hugging Face, Anyscale）、投资机构分析
• 中文来源覆盖：大厂技术团队（美团、阿里、字节）、社区专栏（知乎）
• 内容类型包含：架构解析、技术教程、实践分享、趋势分析

4. 技术演进时间线

2022 ─┬─ Orca (OSDI) → 提出迭代式解码和请求调度，奠定 LLM 服务研究基础
      │
2023 ─┼─ vLLM 发布 → PagedAttention 革命性优化，开启高效 LLM 服务新时代
      │
      ├─ TGI 开源 → HuggingFace 推出官方推理服务，推动标准化
      │
2024 ─┼─ 推测解码兴起 → SpecInfer、Eagle 等加速技术成熟
      │
      ├─ 解耦架构探索 → Splitwise、DistServe 分离 Prefill/Decode
      │
      ├─ 集群调度突破 → Llumnix 实现 SLO 感知请求迁移
      │
      │
2025 ─┼─ 流式无限上下文 → InfiniGen 突破上下文长度限制
      │
      ├─ 可抢占调度成熟 → Preblee、FastServe 实现精细 SLO 保证
      │
      ├─ KV 缓存中心化 → Mooncake 实现跨实例缓存共享
      │
2026 ─┴─ 当前状态：多技术融合，QoS 保障从单点优化走向系统级协同

第三部分：方案对比

1. 历史发展时间线

2020 ─┬─ 基础 API 服务 → OpenAI GPT-3 API，简单请求 - 响应模式，无批处理优化
      │
2021 ─┼─ 批处理萌芽 → 静态批处理出现，固定大小批次，GPU 利用率仍低
      │
2022 ─┼─ 动态调度 → Orca 提出连续批处理概念，请求可动态加入批次
      │
2023 ─┼─ 内存革命 → vLLM PagedAttention 解决 KV 缓存碎片化，吞吐提升 24x
      │
2024 ─┼─ 架构解耦 → Prefill/Decode分离，独立优化和扩缩容
      │
      ├─ 推测解码 → 小模型辅助大模型，减少自回归步数
      │
2025 ─┼─ 智能调度 → SLO 感知、可抢占、跨集群迁移
      │
2026 ─┴─ 当前状态：QoS 保障成为生产系统标配，支持多租户差异化服务

2. 六种方案横向对比

3. 技术细节对比

4. 选型建议

成本估算说明：

• 基于 2025-2026 年云 GPU 价格（H100 ~$3-5/小时，A100 ~$2-3/小时）
• 假设日均请求量：小型 1 万、中型 50 万、大型 1000 万 +
• 未计入人力运维成本，实际总成本可能上浮 30-50%

第四部分：精华整合

1. The One 公式

用一个"悖论式等式"概括大模型推理服务 QoS 的核心本质：

解读： QoS 保障是在内存效率、吞吐优化和服务保证之间寻找平衡，同时最小化抢占调度带来的上下文切换开销。

2. 一句话解释（费曼技巧）

大模型推理 QoS 就像"医院急诊分诊系统"：普通病人排队等候，危重病人优先救治，医生（GPU）时刻满负荷工作但不会让任何一个病人等太久，系统还能在紧急情况下暂停手头工作去处理更危急的情况。

3. 核心架构图

用户请求 → [API 网关/限流] → [优先级队列] → [连续批处理] → [GPU 推理] → 响应
               ↓                 ↓              ↓              ↓
           速率控制          SLO 监控        内存优化      延迟/吞吐指标

4. STAR 总结

5. 理解确认问题

问题：

假设你运营一个多租户 LLM 推理服务，有三个用户等级（Premium、Standard、Free），分别对应 100ms、500ms、2000ms 的 TTFT SLO。高峰期 GPU 资源紧张，一个 Standard 用户的请求正在生成第 50 个 token，此时一个 Premium 用户的新请求到达。根据现代 QoS 系统的设计原则，应该如何处理？请分析"立即抢占"和"等待完成"两种策略的利弊。

参考答案：

现代 QoS 系统会采用条件抢占策略，而非简单的"立即"或"等待"：

1. 检查抢占收益：计算 Standard 请求已完成比例（如 50/200=25%），若已接近完成，抢占的浪费较大，可能选择等待。

2. 检查 SLO 紧迫度：Premium 请求的 SLO 是 100ms，如果排队等待可能超时，则抢占优先级提高。

3. 检查恢复成本：被抢占的 Standard 请求可以保存 KV 缓存检查点，恢复时开销较小，这使得抢占更可行。

4. 公平性约束：系统会跟踪每个用户的被抢占次数，避免同一用户反复被抢占（饥饿问题）。

最佳实践：vLLM+Llumnix 等系统采用"软抢占"——暂停 Standard 请求的调度，但不释放 KV 缓存，等 GPU 有空闲时快速恢复。这样既保证 Premium 的低延迟，又减少 Standard 的重复计算开销。

附录：参考文献与资源

核心论文

1. Kwon W, et al. "vLLM: Easy, Fast, and Cheap LLM Serving." MLSys 2023.
2. Yu G, et al. "Orca: A Distributed Serving System." OSDI 2022.
3. Agrawal A, et al. "Sarathi-Serve: Chunked Prefill." arXiv 2024.
4. Liu X, et al. "Splitwise: Efficient Generative LLM Inference." ISCA 2024.

开源项目

• vLLM: https://github.com/vllm-project/vllm
• TGI: https://github.com/huggingface/text-generation-inference
• SGLang: https://github.com/sgl-project/sglang

技术博客

• Eugene Yan: "Building Production LLM Inference Systems"
• Chip Huyen: "Speculative Decoding for LLM Inference"
• 美团技术团队："高效大模型推理服务实践"

报告完成日期： 2026-04-15 总字数： 约 8500 字