在不断发展的大语言模型 (LLM) 领域中，“每台机器一个模型”的部署模式正成为企业 LLM 部署 成本效益方面的一个重大瓶颈。LLM 通常需要大量 硬件预留，例如完整的 8x H100 GPU 节点，才能管理峰值负载。 但是，在标准运营期间，这些昂贵的资源往往得不到充分利用，导致总拥有成本 (TCO) 很高。
模型共同托管 通过让多个模型实例共享同一虚拟机和 GPU 资源，解决了这一效率差距。这包括 完全不同的模型，例如 Llama 3.3 和 Gemma 3。通过利用子 GPU 内存切片和智能资源分区，Vertex AI Model Garden 将 静态硬件预留转换为灵活的高密度计算池。
这篇技术博客详细介绍了 Vertex AI Engineering 将模型共同托管引入到可用于生产用途的云服务的过程。我们将分享我们的方法，包括容器级实现策略、确定最佳部署配置，以及从我们广泛的多模型基准研究中获得的主要发现，帮助您最大限度地提高 LLM 部署成本效益。
了解模型共同托管：概念和架构
模型共同托管是一种高密度部署策略，可让多个大语言模型 (LLM) 实例或不同的模型架构在单个虚拟机 (VM) 中共享相同的物理硬件资源。与为单个模型分配完整虚拟机或 GPU 的传统部署模型不同，共同托管利用精细的资源分区来最大限度地提高硬件投资回报率，并提高内存和计算资源的利用率。
我们的实现侧重于容器级解决方案，该解决方案允许同时部署具有独立配置的多个模型。此架构通过多种集成技术机制运行，首先是在单个容器中部署多个独立的模型服务器实例。每个实例都充当模型服务器的完整独立副本，从而可以在虚拟机中同时处理请求。为了管理此流量，我们在容器内实现了一个实例路由层，该层可高效地将传入请求分配给活跃实例。
此设计通过允许每个共同托管的模型 利用专用部署配置来提供精细的并行性，该配置具有针对 张量并行处理 (TP)、流水线并行处理 (PP)和特定数量 的模型实例的独特设置。资源切片对此进行了补充，其中为每个模型分配了特定的 GPU 内存分区（例如每个模型 0.4 个 GPU 内存分区），以确保不同的工作负载在同一加速器上共存，而不会相互占用关键内存资源。这种架构方法将静态硬件预留（例如完整的 8x H100 GPU 节点）转换为灵活的计算池，能够部署各种模型，从大型推理模型到小型低延迟聊天模型。
原型设计和基准研究
在开发可用于生产用途的编排器之前，我们进行了一项全面的基准研究，以验证模型共同托管的理论效率。此阶段旨在彻底测试 vLLM的原生并行性，并精确 量化模型共享同一芯片时的“干扰”程度。
并行性调查：寻找“交叉点”
我们的初步分析侧重于 vLLM 的原生 张量并行处理 (TP) 和 Vertex 将模型实例实现为多个 vLLM 服务器 实例，以确定这些策略如何与不同的用户负载交互。 我们发现，最佳配置高度依赖于并发性；在较低的并发性下，较高的张量并行处理（例如 TP=8）通过在所有可用加速器之间分配层，为单个请求提供最低的延迟时间。但是，随着并发流量的增加，瓶颈会发生变化。为了在高负载条件下最大限度地提高吞吐量，最佳配置从 TP=8 转换为 TP=4、TP=2，最终转换为 TP=1，同时增加独立模型实例的数量。这种转换定义了一个“交叉点”，在该交叉点上，低 TP 设置中减少的 GPU 间通信延迟的优势超过了高 TP 执行的原始速度。下面是 Gemma 2 9B IT 模型的交叉点图表。
最佳伸缩：单模型、多副本
为了建立严格的可伸缩性基准，我们对在单个节点上部署同一模型的多个实例进行了基准测试。在饱和流量条件下（每个 GPU 2048 个并发请求），在 8xH100 节点上启动八个独立的 vLLM 服务器实例与单 GPU 基准相比，吞吐量大约提高了 7.8 倍 ，而延迟时间几乎没有回退。
基础架构比较：容器与 Pod 共同调度
我们进一步评估了容器级编排与原生 基础架构级解决方案（特别是 Pod 共同调度 ）的性能。虽然这两种解决方案在多副本部署方面都提供了相当的性能，但我们最终为最简可行产品 (MVP) 选择了容器级方法。这一决定是基于容器级 解决方案为 异构共同托管 提供的卓越灵活性，允许开发者使用精细的软件定义 内存分区并排部署不同的模型架构，这些分区不受底层 Kubernetes 调度 约束的限制。除此之外，容器级编排还允许更快地进行迭代，并且更易于自定义和创新。
干扰测试：共同托管不同的模型
最终的原型设计里程碑是“干扰测试”，我们在同一虚拟机上共同托管了 Gemma-3n-E2B-it 和 Llama-3.1-8B-Instruct。每个模型都分配了 0.4 个 GPU 内存分区，部署性能与单模型基准几乎相同。例如，Gemma-3n 在共同托管环境中达到了 30.21 个请求，而在隔离环境中达到了 30.96 个请求。这些结果 证实，即使在流量很大的情况下，共同托管的 模型之间几乎没有计算干扰，前提是内存资源已 适当分区，以防止 KV 缓存不足。
MVP 容器实现
从经过验证的基准到可用于生产环境的系统，需要设计一个强大的容器化编排器。此开发阶段的重点是构建一个高级软件层，该层能够管理多个模型生命周期的复杂性，同时确保确定性的资源隔离。
模型共同托管服务器设计
我们实现的核心是 model_cohost_server，这是一个自定义入口点，旨在充当容器内的主要编排器。与标准的单进程模型不同，此服务器实现了子进程管理，有助于将多个独立的模型服务器实例（例如 vLLM）作为隔离的子进程并发执行。为了管理传入流量，编排器采用高级请求路由，通过 --served-model-name 等实参按其唯一的模型标识符识别请求，并将请求定向到相应的内部服务器实例。除了路由之外，服务器还提供全面的生命周期
编排，管理所有共同托管实例的初始化、健康状况监控和终止
。这种集中式管理为外部流量提供了一个统一的端点，同时保持每个子进程的不同运营边界。
GPU 资源分区：确定性切片
为了消除单个模型的工作负载在共同托管环境中触发内存不足 (OOM) 错误的风险，我们实现了一个严格的资源切片机制。这是通过 gpu-memory-partition 实参实现的，该实参允许开发者定义显式内存比率（例如 0.4、0.4），为每个单独的模型实例预留节点总 GPU 内存的固定百分比。
为了指导此分配，我们采用了 "预分配与临时"内存
模型，该模型区分了静态和动态资源要求。
“预分配”内存包括用于模型权重和 KV 缓存的内存。用于模型权重的内存量取决于模型的参数数量和精度。例如，BF16 中的 8B 参数模型大约需要 16GB 的静态存储空间。用于 KV 缓存的内存量取决于模型维度、精度、上下文长度和序列数。“临时”内存 包括中间计算和
推理工作内存。gpu-memory-partition 实参用于计算“预分配”内存。我们建议为“临时”内存留出缓冲空间，方法是将 gpu-memory-partition 的总和设置为小于 1.0。
产品化
Vertex AI 模型共同托管的产品化阶段致力于为单模型多副本和多模型部署配置建立无缝的、可用于生产用途的环境。这种转换有效地将经验基准发现转化为简化的部署工作流和深度集成的基础架构支持结构。
简化的部署工作流
为了降低高密度部署的门槛，我们使用自定义容器实参标准化了 共同托管配置，这些实参与 现有的 Vertex AI API 原生集成。对于 完整形状的虚拟机（例如 8x H100 节点），我们开发了一个 基准实用程序 ，用于为您的特定使用场景自定义最佳方案。借助这些基准 实用程序，您可以根据模型的特定参数数量和 精度找到自动平衡 张量并行处理 (TP)、流水线并行处理 (PP)和模型实例数量的配置。强大的 Deployment API 支持对此进行了补充，允许开发者直接在标准 deployModel请求中指定这些精细的参数（包括 确切的 GPU 内存分区）并部署模型。
动态多模型部署
我们技术之旅中的一项重大进步是从静态配置到动态部署架构的转变。此功能对于以快速变化的流量模式为特征的生产环境至关重要，因为在不完全重启容器的情况下加载或卸载模型的能力对于保持基础架构敏捷性和高可用性至关重要。
动态更新 API (update_models)
为了解决不可变部署的固有限制，我们在 Vertex Model Garden vLLM 模型共同托管容器中实现了一个专门的模型更新 API。此 API 有助于 热重新加载 ，使 服务器能够根据存储在 Google Cloud Storage (GCS) 存储桶中的 集中式配置文件，即时调整其托管模型组合。
更新过程通过向 update_models 端点发出 POST 请求来启动，该请求包含指向 GCS YAML 文件的 model_config_path。
收到此请求后，服务器会执行针对最短停机时间优化的多阶段编排序列：
- 正常卸载：系统会识别新 配置中缺少的模型，并首先终止其子进程，立即 回收 GPU 内存和计算资源。
- 智能加载和重复使用：然后，服务器会初始化新的模型 实例。至关重要的是，如果模型的并行处理设置（例如张量并行处理 (TP) 或流水线并行处理 (PP)）及其分配的内存分区保持不变，编排器会重复使用现有的运行实例。此优化绕过了代价高昂的重新初始化阶段，确保活跃服务在配置更改期间保持不间断。
延迟时间和性能分析
对这些更新策略的实证分析表明，动态热重新加载可大幅缓解与大规模 LLM 部署相关的常见“冷启动”惩罚。
总结
Vertex AI 模型共同托管代表着一种根本性的范式转变，从僵化的、硬件密集型的单体部署转变为流畅高效的部署架构。通过从“每个虚拟机一个模型”的标准发展为高密度计算池模型，组织可以显著降低总拥有成本 (TCO)，同时保持（通常还会提高）性能基准。
我们的工程之旅和广泛的多模型基准研究为此架构建立了一套明确的生产指南：
- 没有一种配置适用于所有情况。我们提倡为特定使用场景（模型、硬件、流量）找到最佳部署方案，并为此构建工具。
- 使用副本扩缩吞吐量。
- 通过打破硬件边界并在更精细的级别拆分内存来提高资源利用率。
为了成功实现共同托管架构，我们建议采用以下技术工作流：
- 显式分区：使用
--gpu-memory-partitions实参为 各个模型分配内存资源。 - 迭代基准测试：利用提供的基准实用程序来 确定工作负载的特定“并发交叉”点，即 实例数量、TP 和 PP 的“最佳”配置。
在 Google Cloud Model Garden 上实现共同托管为构建高密度 AI 应用提供了可伸缩的蓝图。我们鼓励开发者 探索这些功能，并使用提供的 教程 笔记本 重现我们的基准，以针对其特定企业要求优化部署配置。
感谢阅读
欢迎您就 Vertex AI 向我们提供反馈和提出问题。
致谢
我们要衷心感谢 Google Cloud Vertex AI 团队。具体而言，我们要感谢 Bo Wu 和 Ting Yu 的领导和指导，以及 Deborah He、Shawn Ma、Desmond Liu、Yang Pan、Surya K G Tangatur 和 Luis Rizo 在整个项目中的宝贵贡献。