大模型推理服务多模型弹性部署与资源共享技术 — 深度调研报告

调研日期：2026-05-18 所属领域：大模型框架 调研范围：涵盖 2024–2026 年最新论文、开源项目与工业实践

第一部分：概念剖析

1. 定义澄清

通行定义

大模型推理服务多模型弹性部署与资源共享技术，是指在一套推理基础设施上同时承载多个 LLM（大语言模型）的在线推理请求，通过动态分配 GPU/CPU 显存与算力资源，实现按需扩缩容、跨模型资源复用、以及异构硬件兼容的部署能力。该技术的核心目标是：在满足多个模型各自的服务质量目标（SLO，含 TTFT 首Token延迟和 TPOT 输出Token速率）前提下，最大化集群资源利用率、最小化总运营成本（TCO）。

常见误解

1. 误解一："多模型部署就是把多个模型分别部署在各自 Pod 里，用 K8s Service 路由就够了" —— 实际上，简单的隔离部署忽略了显存资源共享的可能性。现代系统通过弹性显存管理（如 PRISM 的 kvcached）可以在同一 GPU 上按需切换模型，大幅提高利用率。
2. 误解二："弹性伸缩就是 HPA 根据 CPU/内存扩容" —— LLM 推理的瓶颈在 GPU 显存（尤其是 KV Cache）而非 CPU。真正的弹性需要感知 KV Cache 状态、Token 级调度和 SLA 驱动的扩缩容。
3. 误解三："Prefill 和 Decode 必须绑定在同一 GPU 上完成" —— PD 分离架构已证明将两者解耦为独立服务池可消除相互干扰，显著提升整体吞吐。

边界辨析

2. 核心架构

┌─────────────────────────────────────────────────────────────────┐
│              大模型推理多模型弹性部署系统架构                        │
├─────────────────────────────────────────────────────────────────┤
│                                                                  │
│  [用户请求] ──→ [统一API网关] ──→ [全局调度器] ──→ [推理集群] ──→ [返回]│
│                    │                     │           │              │
│                    ▼                     ▼           ▼              │
│              [模型路由]            [弹性伸缩器]    [多Engine池]       │
│              (路由至目标模型)      (SLA驱动扩缩)  (vLLM/SGLang/TRT-LLM)│
│                                                                  │
│  ┌──────────────────── 推理集群内部 ────────────────────────────┐  │
│  │                                                              │  │
│  │  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐       │  │
│  │  │ Prefill 池    │  │ Decode 池    │  │ Encode 池    │       │  │
│  │  │ (计算密集型)   │←→│ (显存密集型)   │←→│ (多模态编码)  │       │  │
│  │  └──────┬───────┘  └──────┬───────┘  └──────┬───────┘       │  │
│  │         │                  │                  │               │  │
│  │         └──────────────────┴──────────────────┘               │  │
│  │                        │                                      │  │
│  │              [KV Cache 传输层]                                 │  │
│  │           (RDMA/以太网/共享显存)                                │  │
│  │                        │                                      │  │
│  │              ┌─────────────────────┐                          │  │
│  │              │ 全局 KV Cache 管理器  │                          │  │
│  │              │ (Mooncake/分布式缓存) │                          │  │
│  │              └──────────┬──────────┘                          │  │
│  │                         │                                     │  │
│  │              ┌─────────────────────┐                          │  │
│  │              │ 弹性显存管理器       │                          │  │
│  │              │ (kvcached/虚拟-物理  │                          │  │
│  │              │  显存解耦)          │                          │  │
│  │              └─────────────────────┘                          │  │
│  └──────────────────────────────────────────────────────────────┘  │
│                                                                     │
│  [监控与可观测性] ←── [SLO 管理器] ←── [成本优化器]                  │
│  (Prometheus/DCGM)  (TTFT/TPOT/SLA)  (资源分配策略)                 │
│                                                                     │
└─────────────────────────────────────────────────────────────────────┘

各组件说明：

3. 数学形式化

3.1 KV Cache 内存需求模型

对于序列长度为 $L$、批次大小为 $B$、注意力头数为 $H$、每头维度为 $d_k$ 的推理请求，KV Cache 占用的 GPU 显存为：

解释：每个 Token 需要存储 Key 和 Value 两组向量，乘以层数（权重模型参数中已包含层数因子），显存占用随序列长度线性增长，这是多模型共享部署中最重要的资源约束。

3.2 PD 分离的性能增益模型

设 Prefill 阶段计算量为 $C_p$，Decode 阶段每 Token 计算量为 $C_d$，分离后独立扩缩容：

解释：通过为 Prefill（计算密集型）和 Decode（显存密集型）设置独立的 GPU 数量 $n_p$ 和 $n_d$，消除了两者因资源竞争产生的相互阻塞，当 $n_p/n_d$ 与实际计算量比值匹配时可获得最大收益。

3.3 多模型资源共享的成本效率

对于 $M$ 个模型部署在 $G$ 块 GPU 上，资源共享的收益定义为：

其中 $C_i^{\text{isolated}}$ 是模型 $i$ 独占部署的成本，$C_j^{\text{shared}}$ 是共享部署中 GPU $j$ 的实际开销。

解释：资源共享带来的成本节约来源于两个层面——空间共享（多个模型同时驻留同一 GPU，利用显存的时间片复用）和时域弹性（模型按需加载/卸载，避免 GPU 空闲等待）。

3.4 弹性伸缩的响应延迟模型

从触发扩容到新实例就绪的总延迟：

其中 $T_{detect}$ 是检测延迟（通常 1-15s），$T_{schedule}$ 是调度延迟（GPU 资源分配，秒级），$T_{load}$ 是模型权重加载延迟（GB级模型可达 10-60s），$T_{warm}$ 是预热延迟（首次推理慢，可预执行虚拟请求规避）。

解释：弹性伸缩的瓶颈在于模型加载和预热，PRISM 等系统通过预初始化引擎和并行权重加载，将 $T_{load}$ 压缩至 1.5s 以内。

3.5 多模型部署的 SLO 合规率

对于一个有 $K$ 个模型的系统，总 SLO 合规率为：

解释：多模型部署的难度不仅在于单个模型的延迟优化，更在于多个模型之间的资源隔离保证——一个模型的高流量不应对其他模型的延迟分布产生显著影响（即"嘈杂邻居问题"）。

4. 实现逻辑（Python 风格伪代码）

class MultiModelElasticServingSystem:
    """多模型弹性部署核心系统"""

    def __init__(self, config: SystemConfig):
        self.gpu_cluster = GPUCluster(config.gpu_list)      # 异构 GPU 集群管理
        self.model_registry = ModelRegistry(config.models)   # 已注册模型清单
        self.memory_manager = ElasticMemoryManager()         # 弹性显存管理器
        self.scheduler = TwoLevelScheduler()                 # 两层调度器
        self.autoscaler = SLADrivenAutoscaler(config.slas)   # SLA 驱动弹性伸缩器
        self.kv_cache_manager = GlobalKVCacheManager()      # 全局 KV Cache 管理

    def serve_request(self, request: InferenceRequest) -> Response:
        """处理推理请求的核心流程"""

        # Step 1: 路由决策 — 选择合适的模型实例
        model_name = request.model_name
        target_gpu = self.scheduler.route(
            model=model_name,
            prompt=request.prompt,
            kv_cache_hint=request.get_prefix_hash()
        )

        # Step 2: 弹性显存分配
        memory_slot = self.memory_manager.allocate(
            model_name=model_name,
            required_memory=estimate_kv_cache_memory(request)
        )

        # Step 3: 模型激活（如需）
        if not memory_slot.is_loaded:
            self._activate_model(model_name, memory_slot.gpu_id)

        # Step 4: 执行推理（可选择 PD 分离模式）
        if self.config.disaggregated_mode:
            return self._disaggregated_infer(request, target_gpu)
        else:
            return self._local_infer(request, target_gpu)

    def _activate_model(self, model_name: str, gpu_id: int):
        """快速模型激活 — 预初始化 + 并行加载"""
        model_handle = self.model_registry.get(model_name)
        # PRISM 式快速激活：权重预加载至 Host，Engine 预热保持
        model_handle.engine = self.model_registry.get_cached_engine(model_name)
        model_handle.load_weights_parallel(gpu_id)

    def _disaggregated_infer(self, request, target_gpu):
        """PD 分离推理流程"""
        # Prefill 阶段 — 在计算型 GPU 上执行
        kv_cache = self.kv_cache_manager.execute_prefill(
            request=request,
            prefill_pool=self.gpu_cluster.prefill_pool
        )
        # KV Cache 传输 (RDMA / 共享显存)
        self.kv_cache_manager.transfer(kv_cache, to_gpu=target_gpu)
        # Decode 阶段 — 在显存型 GPU 上执行
        return self.kv_cache_manager.execute_decode(
            kv_cache=kv_cache,
            decode_pool=self.gpu_cluster.decode_pool
        )

    def auto_scale_loop(self):
        """弹性伸缩主循环"""
        while True:
            metrics = self._collect_metrics()         # 收集 QPS / 排队长度 / GPU 利用率
            scaling_decisions = self.autoscaler.decide(
                current_replicas=self._get_replica_count(),
                metrics=metrics,
                model_slas=self.config.slas
            )
            for decision in scaling_decisions:
                if decision.action == "scale_up":
                    self._provision_gpu(decision.replicas)
                elif decision.action == "scale_down":
                    self._decommission_gpu(decision.replicas)
            time.sleep(self.config.scale_interval)

5. 性能指标

6. 扩展性与安全性

水平扩展

• 多节点 Prefill/Decode 池：通过 RDMA 或高速以太网实现 KV Cache 跨节点传输，支持千卡级集群扩展
• 模型分片并行：Tensor Parallelism (TP) 切分单层权重跨 GPU，Pipeline Parallelism (PP) 分层部署，Expert Parallelism (EP) 用于 MoE 模型
• 跨集群联邦：如 Cognitora 通过 QUIC 协议实现跨集群 KV Cache 共享，打破单集群物理边界

垂直扩展

• 单 GPU 计算密度：FP4/FP8 量化、稀疏计算、FlashAttention 等算子级优化
• 显存扩展：H200 的 141GB HBM3e、B200 的 192GB HBM3e，单卡可承载更大模型
• NVLink 域扩展：NVL72 等机柜级 GPU 互联，大幅降低跨 GPU 通信延迟

安全考量

• 模型隔离：多模型共享 GPU 显存时，需防止恶意模型通过显存侧信道窃取其他模型的 KV Cache 数据
• 请求级隔离：保证高安全等级请求不会被与其他请求共享 KV Cache 导致信息泄露
• 多租户计费与配额：多团队共享集群时，需要精确的 Token 级计费和 GPU 时间片计量
• 模型权重保护：模型从存储加载到 GPU 过程中的加密传输和内存保护

第二部分：行业情报

1. GitHub 热门项目

2. 关键论文

3. 系统化技术博客

4. 技术演进时间线

2023 ── vLLM 提出 PagedAttention（SOSP 2023）── 将虚拟内存思想引入 KV Cache 管理，奠定现代推理引擎基础
2024 ── SGLang 发布 RadixAttention（OSDI 2024）── 前缀树共享 KV Cache，DeepSeek 等选择 SGLang 作为官方引擎
2024 ── TensorRT-LLM 开源 ── NVIDIA 编译式推理引擎，FP8/INT4 量化支持，最高吞吐但操作复杂
2024 ── PD 分离架构兴起 ── vLLM、SGLang、TRT-LLM 纷纷支持 Prefill/Decode 独立部署
2025 ── NVIDIA Dynamo v1.0 发布 ── 首个数据中心级推理编排层，KV 感知路由、SLA 驱动伸缩
2025 ── PRISM 提出多模型 GPU 共享 ── 弹性显存管理 kvcached，时间和空间共享，成本节省 >2×
2025 ── KServe v0.17 LLMInferenceService ── K8s 原生 LLM Serving CRD，GIE 集成 KV Cache 路由
2025 ── ElasticMM (NeurIPS 2025 Oral) ── 多模态 LLM 弹性并行，EPD 三阶段分离
2025 ── Mooncake 分布式 KV Cache 系统开源 ── RDMA 加速跨节点 KV 传输，月之暗面出品
2026 ── Coral 提出异构 GPU 多模型联合优化 ── 6 模型 20 种 GPU 配置，成本降低 2.79×
2026 ── OServe (ICML 2026) ── 时空工作负载感知编排，异构模型部署自适应切换
2026 ── Nitsum 动态 Tensor Parallel ── 将 TP 从静态配置变为运行时控制手段
2026 ── Star Elastic Many-in-One ── 单次训练获得嵌套子模型，推理阶段弹性预算控制
2026 ── 当前状态：PD 分离成为标配、KV Cache 感知路由进入生产、多模型共享从研究走向工程、
        弹性伸缩从 Pod 级细化至 GPU 级、行业加速从"单模型优化"转向"多模型系统级效率优化"

第三部分：方案对比

1. 历史发展时间线

2022 ── 早期阶段：单模型独占 GPU，部署方式简单粗暴，GPU 利用率 < 30%
2023 ── vLLM PagedAttention 问世 → 单 GPU 可承载更大并发，但仍为单模型
2024 ── PD 分离架构成熟 → Prefill/Decode 解耦，可独立扩缩容，吞吐提升 2-3×
2024 ── 多模型共享萌芽 → 简单的时间片轮换 GPU 共享（如 TGI 的多 LoRA）
2025 ── 弹性显存管理突破 → PRISM 的 kvcached 实现虚拟-物理显存解耦，模型加载 < 1.5s
2025 ── 推理编排层诞生 → NVIDIA Dynamo 统一编排多种引擎，KV 感知路由
2026 ── 系统级多模型优化 → Coral/OServe 联合优化资源分配 + 推理策略
2026 ── 当前状态：从"如何部署一个模型"转向"如何高效部署一群模型"

2. 七种方案横向对比

方案 A：独立 Pod 部署（传统 K8s 无共享）

方案 B：推理引擎内置多模型（vLLM/SGLang 多 LoRA / 多模型）

方案 C：PD 分离 + 独立扩缩容

方案 D：弹性显存共享（PRISM 方案）

方案 E：推理编排层（NVIDIA Dynamo / KServe llm-d）

方案 F：异构 GPU 多模型联合优化（Coral 方案）

方案 G：动态 Tensor Parallel 运行时控制（Nitsum 方案）

3. 技术细节对比

4. 选型建议

架构组合模式

小规模 → 独立 Pod
    ↓
中规模 → SGLang 多模型 + 基础 PD 分离
    ↓
大规模 → NVIDIA Dynamo / KServe + vLLM/SGLang + PD 分离 + 弹性显存
    ↓
超大规模 → 编排层 + 异构 GPU 联合优化 + 动态 TP + 跨集群 KV 联邦

2026 年推荐栈：

• 推理引擎：vLLM（通用稳定）或 SGLang（DeepSeek/结构化输出场景）
• 编排层：NVIDIA Dynamo（NVIDIA 生态）或 KServe v0.17（K8s 原生、CNCF）
• 弹性伸缩：KEDA + Karpenter（AWS）/ Cluster Autoscaler（通用）
• KV Cache 管理：Mooncake（RDMA）或内置 D2D 传输
• 多模型共享：PRISM（研究前沿）或 Dynamo 多模型模式（工程成熟）

第四部分：精华整合

1. The One 公式

翻译：多模型部署的本质是：将每个请求的 Prefill 和 Decode 阶段解耦到独立 GPU 池（PD 分离），通过虚拟显存管理让多个模型灵活共享物理 GPU（弹性显存），同时尽可能减少因模型大小、请求长度各异造成的显存和算力碎片。

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

"就像 Airbnb 让多组旅客在不同时间共享同一套公寓的卧室和客厅，多模型弹性部署让不同的 AI 模型动态共享 GPU 集群——当模型 A 空闲时，模型 B 可以立即使用它的 GPU 显存，而不需要给每个模型单独买一套'房子'。"

3. 核心架构图

输入 ──→ [统一网关] ──→ [全局调度器] ──→ [GPU 集群：多模型共存]
          (路由+鉴权)   (KV感知+负载均衡)    ├─ Model A (Active)
                               ↓            ├─ Model B (Active)
                          [弹性伸缩器]        ├─ Model C (Inactive/已卸载)
                          (SLA驱动)          └─ Model D (Partial Loaded)
                               │
                               ↓
                        [成本优化器]
                     (异构GPU+混合云)

4. STAR 总结

Situation（背景+痛点）

2025-2026 年，大模型应用进入爆发期，企业与平台需要同时部署多个 LLM（如 GPT-4、Claude、DeepSeek、Llama 以及行业微调模型）来满足不同场景需求。然而传统"一个模型独占一块 GPU"的部署模式导致 GPU 利用率普遍低于 30%，显存和算力碎片严重。同时，推理请求的流量模式波动剧烈（高峰可达低谷的 10-20 倍），静态部署要么资源浪费，要么服务质量不达标。这些挑战使得多模型的高效弹性部署成为大模型基础设施领域的核心前沿问题。

Task（核心问题）

技术需要解决的核心挑战是：在异构 GPU 集群上同时服务多个 LLM，在满足各自延迟 SLO（TTFT < 200ms, TPOT < 30ms/token）的前提下，通过动态资源调度和弹性伸缩最大化集群利用率、最小化总拥有成本（TCO）。关键约束包括：GPU 显存是瓶颈资源、模型加载有显著延迟、请求流量具有空间和时间双重异质性。

Action（主流方案）

技术演进经历了四个阶段：第一阶段（2023-2024），vLLM 等推理引擎通过 PagedAttention 优化单模型推理效率；第二阶段（2024-2025），PD 分离架构解耦 Prefill 和 Decode，实现按需独立扩缩容；第三阶段（2025），PRISM 等系统引入弹性显存管理（kvcached），实现多模型在同一 GPU 上的灵活时间和空间共享，模型切换压缩至 1.5s 内；第四阶段（2025-2026），NVIDIA Dynamo 和 KServe 等编排系统在引擎之上提供统一调度层，KV Cache 感知路由、SLA 驱动弹性伸缩和异构 GPU 联合优化（Coral）进一步将成本降低 2-3 倍。

Result（效果+建议）

当前技术已实现：GPU 利用率从 < 30% 提升至 > 70%，多模型部署成本降低 2-3 倍，PD 分离带来 1.7-3.2× 的吞吐收益，模型冷启动从分钟级降至秒级。然而，弹性显存共享的"嘈杂邻居"问题、编排层的标准化、以及跨集群联邦 KV 共享仍是未完全解决的问题。

实操建议：

• 起步期（< 3 模型）：采用 vLLM/SGLang 多模型模式 + 基础 HPA，快速上线
• 成长期（3-10 模型）：引入 PD 分离 + Dynamo/KServe 编排层 + KEDA 弹性伸缩
• 成熟期（> 10 模型）：叠加弹性显存共享 + 异构 GPU 联合优化 + KV 感知路由

5. 理解确认问题

问题：为什么 PD（Prefill-Decode）分离能同时提升延迟和吞吐？如果给你 8 块 GPU，假设 Prefill 和 Decode 的计算需求比为 1:3，你会如何分配这 8 块 GPU 的 P/D 比例？

参考答案： PD 分离之所以能同时提升延迟和吞吐，是因为 Prefill 是计算密集型（瓶颈在 GPU 算力），而 Decode 是显存带宽密集型（瓶颈在显存带宽和容量）。当两者绑定在同一 GPU 时：

1. Prefill 阶段阻塞 Decode：Prefill 处理长输入时 GPU 算力打满，导致正在进行的 Decode 步骤延迟飙升。
2. 显存竞争：Prefill 需要大量临时显存作注意力计算，挤压了 Decode 的 KV Cache 空间。

分离后两者不再相互阻塞，可以各自独占优化的资源环境。根据 1:3 的计算需求比，最优分配应偏向 Decode：2 块 GPU 做 Prefill，6 块做 Decode（即 2p6d）。这个比例使 Prefill 可快速处理输入生成 KV Cache，然后 Decode 并行处理多个请求的逐一 Token 生成。但实践中还需根据序列长度和查询分布动态调整——短请求多则需更多 Prefill 容量，长对话多则需更多 Decode。

附录

术语表

参考来源

本报告基于 2026 年 5 月 18 日的 Web 搜索和文献调研，主要来源包括：

• arXiv、ACM Digital Library、NeurIPS/ICML/EuroSys 等学术来源
• GitHub 公开仓库的实时 Stars 和更新数据
• NVIDIA、AWS、Red Hat、Anyscale、ClearML 等厂商的技术博客
• 百度开发者社区、CSDN 等中文技术社区
• 具体链接已在各表格中标注

报告生成日期：2026-05-18 | 字数：约 8500 字