多租户AI推理集群如何落地：技术负责人要权衡隔离、调度与成本核算

把一套独占 GPU 的推理服务改造成多个业务共享的推理集群，真正变化的并不是“把服务部署到同一批机器上”，而是资源、隔离、服务等级和成本核算方式都要重新设计。对企业技术负责人而言，多租户 AI 推理的核心决策不是追求最高利用率，而是在算力共享之后，仍然能够回答三个问题：谁可以使用资源、在什么条件下使用、使用多少成本由谁承担。

一、先判断：哪些业务适合共享推理资源

多租户并不意味着所有业务都必须共用同一套资源。共享集群适合模型类型相近、流量存在错峰、服务等级可以分层管理的业务。比如，内部知识问答、客服辅助、内容审核和办公助手，可能在不同时间段出现流量高峰，通过统一资源池可以减少低峰期的闲置算力。

相反，以下情况需要谨慎采用强共享模式：

• 业务之间存在严格的数据合规或网络隔离要求；
• 某个租户必须获得稳定的独占吞吐和低延迟；
• 模型版本、运行时或驱动依赖差异较大；
• 流量峰值不可预测，且突发请求会直接影响核心交易链路；
• 业务方无法接受共享集群升级、故障和资源争抢带来的联动风险。

因此，合理的方案通常不是“全部共享”或“全部独占”，而是把集群划分为不同资源池：

资源池	适用业务	主要特点
共享弹性池	普通内部应用、低峰业务、离线或准实时请求	强调利用率和成本效率
保障服务池	核心客服、生产辅助、面向外部用户的服务	预留资源，设置更严格的时延和可用性目标
独占或强隔离池	高敏感、高优先级或依赖特殊运行环境的业务	牺牲部分利用率，换取可预测性和隔离强度

微软的多租户 AI 架构资料也将租户隔离、推理服务和资源组织视为需要分别权衡的架构问题。企业在落地时，应先确定租户边界和服务等级，再决定使用哪种共享方式，而不是先选调度组件。

二、推理集群的基本架构：把“请求”和“资源”解耦

一套可运营的多租户 AI 推理集群，至少应拆成以下几层：

1. 接入与治理层：识别租户、校验身份、执行配额、限流和路由。
2. 服务编排层：管理模型服务实例、版本、健康状态和发布策略。
3. 调度层：根据优先级、资源需求、队列状态和服务等级分配 GPU、CPU。
4. 推理运行层：承载模型服务、批处理、缓存、请求合并和响应生成。
5. 资源与基础设施层：提供 GPU、CPU、内存、网络、存储以及节点生命周期管理。
6. 观测与成本层：采集请求、Token、GPU 时间、显存、队列和错误数据，并完成分摊。

关键原则是：租户信息不能只停留在网关日志里，而要贯穿请求的整个生命周期。一个请求从入口进入后，应至少携带租户标识、业务标识、服务等级、模型版本和成本归属信息。否则，后续调度可以运行，但无法实现准确的资源控制与成本核算。

资源池不要只按硬件型号划分

仅按 GPU 型号建立资源池，往往不足以支持生产调度。调度器还应关注：

• 显存容量与当前占用；
• 模型权重是否已经加载；
• 推理框架和运行时是否兼容；
• GPU 计算利用率与显存带宽压力；
• CPU、内存和网络是否成为瓶颈；
• 是否需要同一节点、同一拓扑或高速互联；
• 该节点是否属于保障服务池或维护窗口。

对于大模型推理，模型加载和显存占用可能比单次请求的计算量更影响调度结果。一个表面上有空闲 GPU 的节点，如果没有足够显存加载目标模型，实际上并不具备可用容量。因此，调度单位不能只有“GPU 卡数”，还要加入模型实例、显存和并发能力等维度。

三、GPU 与 CPU 如何调度：从静态分配转向分层调度

GPU 调度应同时处理“容量”和“公平”

GPU 资源调度通常有三种基本方式：

1. 独占分配

为一个租户或服务预留整卡或固定节点。它的隔离性和性能可预测性较好，但低峰期容易产生闲置，适合高优先级、稳定流量或强合规业务。

2. 细粒度切分

将 GPU 的计算或显存能力切分给多个服务。它可以提高资源利用率，但需要底层硬件、驱动、容器运行时和推理框架协同支持。切分并不自动等于完整隔离，仍要验证显存、带宽、故障传播和性能抖动。

3. 共享调度

多个请求或服务动态竞争 GPU，通过队列、批处理、请求合并和优先级策略提高利用率。该模式弹性最好，但调度延迟和“吵闹邻居”风险也更高。

生产环境通常采用混合方式：核心服务使用预留容量，普通服务进入共享池，低优先级任务使用可回收资源。调度策略应设置租户级并发上限、队列权重、最大等待时间和资源借用规则，而不是单纯按照先到先得。

CPU 不能被当成“附属资源”

推理服务的 CPU 负载通常来自请求预处理、分词、后处理、网络通信、日志采集、缓存访问和模型调度。GPU 空闲并不代表服务有容量。如果 CPU 核数不足，可能出现 GPU 等待输入、队列增长和整体时延升高。

建议将 CPU 调度拆为三类：

• 接入 CPU：负责网关、鉴权、限流和协议处理；
• 推理协同 CPU：负责分词、批处理、数据搬运和后处理；
• 平台 CPU：负责监控、日志、控制器和节点管理。

租户的配额也不应只设置 GPU 数量，还应包括 CPU 核数、内存、并发请求数、队列长度和带宽等限制。否则，某个低 GPU 使用率的业务仍可能通过大量并发占满 CPU 或网络，造成其他租户服务降级。

用“保底配额 + 可借用上限”平衡隔离和利用率

比较实用的资源模型是：

• 保底配额：租户在正常情况下可以稳定获得的资源；
• 突发上限：租户在资源池有余量时可以临时借用的资源；
• 硬上限：任何情况下都不能超过的资源边界；
• 回收规则：高优先级业务到来时，低优先级借用资源如何释放。

例如，一个普通业务可以拥有固定的并发保底，并在共享池空闲时扩展实例；当核心业务进入高峰，普通业务的弹性实例被缩减，但不能突破其最低服务水平。这样比静态切死资源更节省，也比完全共享更可控。

四、租户隔离要分层设计，不能只依赖命名空间

多租户 AI 推理的隔离至少包含四个层面。

1. 身份和数据隔离

每个请求必须完成租户身份识别，并将租户上下文传递到模型服务、缓存、日志和计费系统。需要重点检查：

• 模型输入、输出和会话数据是否带有租户边界；
• 缓存键是否包含租户标识；
• 日志和链路追踪是否可能暴露其他租户内容；
• 对象存储、向量数据库和配置中心是否采用租户级访问控制；
• 管理接口是否限制跨租户查询和操作。

如果缓存键只使用用户 ID 或请求内容摘要，而没有包含租户标识，就可能出现跨租户命中。类似问题往往不是模型本身造成的，而是平台层的数据边界没有设计完整。

2. 运行时和网络隔离

容器、命名空间和服务账号可以提供基础边界，但不能替代完整的安全设计。企业应根据风险等级选择：

• 逻辑隔离：共享节点，通过身份、权限和网络策略限制访问；
• 节点隔离：不同租户使用不同节点或节点组；
• 资源切分隔离：在硬件支持的情况下划分计算与显存资源；
• 集群或网络隔离：面向高敏感业务建立更强的网络和管理边界。

网络策略需要覆盖入口、服务间通信、模型仓库、日志系统和外部工具调用。尤其是带有插件、检索或工具调用能力的推理服务，必须限制其访问范围，避免一个租户的运行时凭据被另一个租户复用。

3. 性能隔离

安全隔离不等于性能隔离。即使不同租户无法读取彼此数据，也可能因为共享 GPU、CPU、网络或存储而互相影响。

性能隔离应通过以下机制实现：

• 租户级并发、QPS 和 Token 配额；
• 队列优先级和公平调度；
• 单请求最大输入、输出和执行时间；
• 模型实例数量上限；
• GPU 显存和 CPU 内存保护；
• 慢请求、异常重试和超时熔断；
• 高峰期的降级模型或异步处理策略。

4. 运维隔离

不同租户的发布、回滚、查看指标和修改配置权限也应分开。一个业务团队不应因为拥有模型服务管理权限，就可以查看其他租户的请求内容或修改共享资源池的调度规则。

五、弹性扩缩容：不能只看 CPU 利用率

传统 Web 服务常以 CPU 利用率作为扩缩容指标，但推理集群需要更接近业务体验的指标。建议至少组合以下数据：

• 等待队列长度；
• 请求排队时间；
• 首 Token 延迟；
• 完整响应延迟；
• 正在处理的请求数；
• 输入与输出 Token 速率；
• GPU 显存占用和计算利用率；
• 模型实例启动时间；
• 租户级服务等级目标的达成情况。

扩容要提前于延迟恶化

如果模型实例启动需要加载权重、初始化运行时和预热缓存，那么等队列已经堆积后再扩容通常来不及。扩容策略应结合预测和水位控制：

1. 为每类模型设置最小常驻实例数；
2. 根据队列长度和请求增长速度提前扩容；
3. 为高优先级业务预留可立即使用的容量；
4. 对冷门模型采用按需启动，但设置启动超时和降级路径；
5. 流量回落后延迟缩容，避免实例频繁抖动；
6. 在缩容前完成连接排空，避免中断正在生成的响应。

缩容也要考虑缓存和模型驻留

推理服务的成本不仅来自运行中的 GPU，还来自频繁加载和卸载模型产生的额外开销。如果缩容过于激进，可能出现“刚释放资源又重新加载”的循环，最终导致启动延迟和资源消耗同时上升。

因此，弹性策略应区分：

• 轻量模型：可以更积极地按需启动；
• 大模型：适合保持一定常驻实例；
• 高频模型：优先驻留在保障池；
• 长尾模型：进入共享池或采用异步队列；
• 有严格时延要求的模型：保留可快速接管的热备容量。

六、成本核算：从“买了多少 GPU”转向“每类请求消耗多少资源”

只按 GPU 数量向业务分摊成本，会掩盖真实消耗。不同模型的输入长度、输出长度、并发模式和驻留时间差异很大，同样一张 GPU 卡可能承载完全不同的请求量。

建立分层成本模型

成本至少可以拆成四层：

固定基础设施成本

包括 GPU、CPU、内存、节点、网络、存储和机房或云资源的基础费用。这部分适合按资源池、节点组或服务等级进行分摊。

运行时成本

包括模型实例运行时间、GPU 使用时间、CPU 使用时间、显存驻留时间、存储读写、网络流量和日志监控等。

请求成本

以请求、Token、字符数、图片张数或任务时长为单位计算。具体维度应根据业务形态选择，不能为了统一而强行使用单一指标。

平台运营成本

包括集群运维、版本升级、故障处理、容量管理、安全审计和平台研发投入。内部平台如果不计入这部分成本，业务看到的单价会被明显低估。

推荐的成本归属维度

维度	适合回答的问题
租户	哪个业务消耗了多少资源
应用或服务	哪个产品线成本增长最快
模型与版本	哪个模型运行效率更高
请求类型	同步、流式、批处理分别消耗多少
输入与输出 Token	生成型业务的主要消耗来自哪里
GPU 时间与峰值占用	资源池容量是否配置过量
服务等级	为低延迟和高可用付出了多少额外成本

可以建立一个简化的单位成本公式：

单位请求成本 = 资源运行成本 ÷ 有效完成请求数 + 平台固定成本分摊 + 存储、网络与运维分摊

对于生成式推理，还应同时观察“每百万 Token 成本”和“每个有效业务结果成本”。单纯追求 Token 单价下降，可能导致输出质量下降、重试增加或人工复核成本上升。

成本核算必须与调度联动

如果成本系统只是月底出报表，就无法指导资源调度。更有效的方式是将成本标签贯穿调度链路：

• 请求进入时绑定租户、应用和成本中心；
• 调度时记录分配的 GPU、CPU、实例和等待时间；
• 完成时记录输入、输出、错误、重试和缓存命中；
• 资源释放时记录实际使用时长；
• 报表同时展示资源成本、请求成本和服务等级成本。

这样，业务方才能看到：请求变多、输入变长、输出变长、选择更高服务等级，分别会怎样影响成本。

七、落地路线：先建立边界，再逐步共享

企业不宜一开始就把所有模型和业务迁入统一共享集群。更稳妥的实施顺序如下。

第一步：建立租户和服务目录

明确租户、业务应用、模型、版本、服务等级和成本中心之间的关系。没有清晰的服务目录，后续的配额、权限和核算都会变成临时规则。

第二步：定义隔离等级

为不同业务建立隔离等级，例如：

• 普通共享；
• 资源保障；
• 节点隔离；
• 网络与集群强隔离。

每个等级都应对应明确的资源、权限、网络、监控和故障处理要求。

第三步：先接入可预测业务

优先选择流量规律、模型相对稳定、对时延容忍度较高的内部业务验证共享模式。不要一开始就把核心交易链路和长尾实验业务同时接入。

第四步：引入公平调度和弹性策略

在基础配额可用后，再逐步加入队列权重、资源借用、优先级抢占、模型预热和自动扩缩容。每增加一个机制，都要验证其对其他租户的影响。

第五步：建立成本反馈闭环

将资源使用、服务等级和业务结果关联起来，定期识别低利用率实例、过度配置模型、异常重试和高成本租户。成本分析的目标不是简单压缩资源，而是推动业务选择合适的模型和服务等级。

八、验收时不要只测峰值吞吐

多租户推理集群的验收，应从单业务性能测试转向混合负载和租户互扰测试。

隔离验收

• 一个租户是否能够访问另一个租户的数据、缓存和日志；
• 删除、重试和超时操作是否会影响其他租户；
• 租户凭证是否可能跨服务复用；
• 管理员权限是否遵循最小授权；
• 网络策略和存储权限是否覆盖所有路径。

调度验收

• 高流量租户是否会长期占满共享资源；
• 低流量租户能否获得约定的最低服务水平；
• 资源借用后能否按规则回收；
• 优先级变化后，队列是否出现不可控饥饿；
• GPU 空闲但 CPU、内存或网络紧张时，系统能否正确识别瓶颈。

弹性验收

• 突发流量到来时，扩容是否赶得上；
• 模型加载失败时是否有重试、熔断或降级；
• 缩容是否会中断流式响应；
• 多模型同时扩容时，是否会争抢节点和存储；
• 扩缩容频繁发生时，成本和时延是否反而上升。

成本验收

• 每个请求能否追溯到租户、应用和模型；
• GPU 时间、Token、网络和存储是否重复计费；
• 共享资源的分摊规则是否可解释；
• 失败请求和重试请求如何计入成本；
• 成本报表与基础设施实际消耗是否能够对账。

九、技术负责人最终要做的取舍

多租户 AI 推理的架构选择，本质上是五个目标之间的平衡：

1. 隔离强度越高，通常越容易获得稳定性和安全边界，但资源利用率可能下降；
2. 资源共享程度越高，单位成本可能越低，但调度、观测和故障治理更复杂；
3. 服务等级越高，越需要预留容量、热实例和快速故障切换；
4. 弹性越激进，越能应对波峰，但模型加载和调度抖动风险也越大；
5. 核算越精细，越能支持经营决策，但数据采集、标签治理和对账成本也越高。

因此，验收标准不应只有“集群利用率达到多少”或“峰值吞吐达到多少”，还应包括租户互扰、最低服务水平、单位有效请求成本、资源借用回收、故障影响范围和成本可追溯性。

对于大多数企业，较稳妥的起点是“分级资源池 + 租户配额 + 公平队列 + 可控借用 + 全链路计量”。这套组合不一定在每个指标上都最优，却能够为后续扩展模型、业务和资源规模保留治理空间。共享算力真正带来的价值，不只是减少几张 GPU 的闲置，而是让企业能够把推理资源当作一种可分配、可度量、可运营的内部基础设施。