成本优化与FinOps：多模型共享GPU降本

可视化演示

三步展示多模型共享GPU降本：MPS共享/MIG分区/时间片三种技术、Triton单卡多模型部署与动态批处理、以及显存80%上限与SLA的资源规划。

合租原理与价值

想象你开了一家“AI 模型公寓”。公寓里租住着好几个模型——有的负责图像识别，有的处理语音，有的做自然语言理解。过去你财大气粗，给每个模型都租了一整套 GPU“独栋别墅”。结果呢？很多模型一天大部分时间都在“睡大觉”，GPU 利用率可能只有 20%~30%。这就好比花大价钱租了别墅，结果每天都在客厅沙发上看电视，根本不需要那些房间。

多模型共享 GPU 的思路，就是把这套“独栋别墅”改成“合租公寓”。多个模型住在同一个 GPU 实例里，共享算力和显存。虽然每个模型的性能可能略有下降，但成本下降的幅度远大于性能损失。据统计，一台空闲 GPU 的资源利用率从 30% 提升到 80% 以上是常见的，这意味着同样的硬件成本，能干原来三倍的活。

$$\text{成本节约率} = 1 - \frac{\text{共享后 GPU 总成本}}{\text{独享时 GPU 总成本}}$$

1. 共享后 GPU 总成本：指多个模型共享后，实际需要购买的 GPU 实例成本总和。由于共享提高了利用率，所需实例数变少。

$$C_{\text{shared}} = N_{\text{instances}} \times P_{\text{per\_instance}}$$

2. 独享时 GPU 总成本：指每个模型单独拥有一台 GPU 实例时的成本总和。

$$C_{\text{dedicated}} = \sum_{i=1}^{M} P_{\text{model\_i}}$$

3. 计算节约率：用 1 减去共享成本与独享成本之比，得到节约比例。

$$\text{Rate} = 1 - \frac{C_{\text{shared}}}{C_{\text{dedicated}}}$$

总之，合租原理的核心就一句话：把闲置的算力变成钱。这不仅是技术方案，更是 FinOps（云成本优化）理念在 AI 领域的具体实践。

资源隔离方案

合租第一个要解决的问题就是：室友之间怎么不互相干扰？你不能让 A 模型半夜放“摇滚乐”（算力占满），吵得 B 模型没法工作。资源隔离，就是给每个“租客”砌一堵墙。

墙有两层：第一层是容器级隔离。每个模型跑在独立的容器（比如 Docker/Kubernetes Pod）里，文件系统、网络栈、进程空间都相互隔离。就像合租公寓里每个房间都有独立的门锁，室友进不了你的房间。第二层是显存分区隔离。GPU 显存被划分成多个区域，每个模型只能用自己分配到的显存块。这类似于公寓里每个房间的大小不同，但都是你的私人空间，别人不能占用。

$$V_{\text{limit}} = \frac{M_{\text{total}}}{N_{\text{models}}} \times (1 + \alpha)$$

1. 总显存除以模型数：在理想情况下，把 GPU 显存平均分给每个模型。

$$\frac{M_{\text{total}}}{N_{\text{models}}}$$

2. 乘以弹性系数：实际上不能分得那么死，要给每个模型留一点余量，应对突发流量。$\alpha$ 通常取 0.1~0.3。

$$(1 + \alpha)$$

除了显存隔离，还有算力限额（Compute Limit）。GPU 的 SM（流式多处理器）数量和算力也是有限的。通过 MPS（Multi-Process Service）或 CUDA 流优先级，可以限制每个容器使用的 GPU 算力百分比。这就像合租公寓里的公共水电气——每个人都有额度，超过就要限流。

显存分配策略

墙砌好了，接下来要解决“房间怎么分”的问题。显存分配策略，就是给不同租客分配房间大小的规则。

静态分配最简单：每个模型固定分配一定大小的显存，比如模型 A 分 4GB，模型 B 分 4GB，模型 C 分 4GB，谁也不能超过。优点是不会互相影响，缺点是浪费——如果模型 A 实际只用了 2GB，剩下的 2GB 就闲置了。这就像合租公寓里每个卧室固定面积，但有的租客带的东西少，房间一大半空着。

动态分配更聪明：根据模型实时的显存需求，动态调整分配。模型 A 高峰期给它 6GB，低峰期收回 2GB 给模型 C 用。这就像合租公寓里，多出来的储物间谁需要谁用。但动态分配实施难度大——频繁搬动显存数据会影响性能，而且容易产生碎片。

$$U_{\text{mem}} = \frac{\sum_{i=1}^{N} A_i}{M_{\text{total}}}$$

1. 实际显存求和：把所有模型实际占用的显存加起来。

$$\sum_{i=1}^{N} A_i$$

2. 除以总显存：就能算出整体显存利用率，这是衡量共享策略好坏的核心指标。

碎片整理是另一件大事。当模型反复申请和释放显存后，显存会出现很多“小碎块”——就像仓库里堆满了大小不一的箱子，有空隙但用不上。定期做碎片整理（把连续的显存块合并），能进一步提高利用率。

调度优先级管理

合租公寓的厨房只有一个，但租客们都要做饭。谁先用？调度优先级管理解决的就是“谁先上 GPU”的问题。

通常我们给不同模型设置不同优先级。在线推理模型（比如实时语音识别、在线推荐）像上班族，早上八点必须用厨房——延迟要求高，必须优先调度。批量训练任务像在家办公的自由职业者，时间灵活，可以排在后面。离线数据分析像周末才做饭的人——优先级最低。

$$\text{Priority}(t) = w_1 \times \text{Latency\_SLO}(t) - w_2 \times \text{Wait\_Time}(t)$$

1. 延迟要求：Latency_SLO 表示该模型对响应时间的苛刻程度。SLO 为 10ms 的模型，优先级比 SLO 为 1s 的高很多。

$$\text{Latency\_SLO}(t)$$

2. 等待时间：为了防止低优先级模型“饿死”，随着等待时间增加，它的优先级也会逐渐提升。

$$\text{Wait\_Time}(t)$$

抢占式调度意味着高优先级任务可以打断低优先级任务——就像紧急情况下，上班族可以把正在做饭的自由职业者挤开，先用厨房。但实现抢占需要保存和恢复上下文，开销不小。公平调度（如 Max-Min Fairness）则更“社会主义”，保证每个模型都至少获得最低限度的资源，避免有人完全没饭吃。

SLA保障方法

合租省钱可以，但服务质量不能掉链子。SLA（服务等级协议）就像合租公寓的“管理公约”，规定了公共区域（GPU 算力）必须达到的清洁标准（性能指标）。

请求级 QoS 是 SLA 的第一道防线。通过限流和排队机制，保证高优先级模型的请求能迅速得到响应。这就像合租公寓的电梯——高峰期会启用“楼层分流”，让高楼层住户（高优先级模型）先上。具体技术包括 Token Bucket 限流、请求队列分离等。

弹性伸缩是 SLA 的第二道防线。当某个模型的负载突然暴涨（比如双十一的推荐模型），就需要给它“加房间”——动态扩展它的资源配额，甚至把多余的请求转发到其他 GPU 实例上。

$$\text{QPS}_{\max} = \frac{N_{\text{replicas}} \times \text{Model\_Throughput}}{\text{Avg\_Latency}}$$

1. 副本数乘单模型吞吐量：看整个共享系统每秒能处理多少请求。

$$N_{\text{replicas}} \times \text{Model\_Throughput}$$

2. 除以平均延迟：请求处理都需要时间，平均延迟越高，系统的实际 QPS 上限越低。

故障转移与容灾是最后一道防线。如果共享 GPU 上的一个模型崩了（比如内存泄漏），不能让它拖垮其他模型。Kubernetes 的健康检查 + 自动重启，以及模型副本的多节点部署，都是常见的保障手段。

性能测试与调优

怎么知道合租方案是否真的可行？性能测试与调优，就是给合租公寓做一次全面“体检”。

基准测试是体检的第一项：跑一组标准的推理请求，看延迟、吞吐量和显存占用三个核心指标。比如 BERT-base 模型在独占 GPU 时延迟 5ms、吞吐 1000 QPS；共享后延迟变成 8ms、吞吐 600 QPS——要判断这个差距是否在接受范围内。

压力测试是体检的第二项：持续增加请求量，找到系统的“崩溃点”。性能分析则用 Profiling 工具（如 Nsight Systems、PyTorch Profiler）定位瓶颈——是显存带宽不够？还是 SM 算力饱和？还是内存分配锁竞争？

$$T_{\text{total}} = T_{\text{compute}} + T_{\text{memory}} + T_{\text{queue}} + T_{\text{overhead}}$$

1. 计算耗时：GPU 真正执行矩阵乘法等计算的时间。

$$T_{\text{compute}}$$

2. 访存耗时：把数据和模型参数从显存搬到计算单元的时间。共享场景下多个模型争抢显存带宽，这项开销会激增。

$$T_{\text{memory}}$$

3. 排队与调度开销：请求在队列里等待的时间，以及调度器切换模型上下文的时间。

$$T_{\text{queue}} + T_{\text{overhead}}$$

常见的调优手段包括：调整 Batch Size（让 GPU 算力吃饱）、开启 CUDA Graphs 减少内核启动开销、用 TensorRT 做模型优化、设置合适的显存池大小减少分配频率等。

云厂商兼容差异

合租方案在一家云厂商跑得好好的，换一家就“水土不服”？云厂商兼容差异，就是不同云平台的“公寓管理制度”不同。

实例类型差异是最显著的。AWS 的 A100 GPU 实例（如 p4d.24xlarge）和阿里云的 A100 实例（如 ecs.gn7i-c16g1.4xlarge）虽然都是 A100，但 CPU、内存、网络带宽的配置比例不一样，驱动和 CUDA 版本也可能不同。这就如同一套北京的老公房和一套深圳的电梯公寓——面积一样，户型完全不同。

迁移注意事项包括：检查 GPU 驱动的 CUDA 版本兼容性（比如 AWS 的 EFA vs 阿里云的 RDMA）、网络架构差异（VPC/安全组规则）、存储挂载方式（EBS vs 云盘 vs NAS）等。最容易被忽略的是镜像兼容层——用 Docker 镜像可以屏蔽大部分系统差异，但 GPU 驱动和 CUDA 运行时要根据云厂商版本重新构建。

$$\text{Portability} = 1 - \frac{N_{\text{modifications}}}{\text{Total\_Components}}$$

1. 需要修改的组件数：迁移时，要改动的代码、配置、依赖项数量。

$$N_{\text{modifications}}$$

2. 总组件数：整个服务包含的组件总数。如果总共 20 个组件，迁移时只改了 2 个，可移植性就是 90%。

多云部署策略则是为了“不把鸡蛋放在一个篮子里”。可以把在线推理服务部署在两个云厂商上，用 DNS 流量调度按比例分发请求，这样即使一家云厂商出故障，另一家也能扛住。

降本核算与FinOps

最后一个问题：合租到底省了多少钱？降本核算与FinOps，就是给“合租”算清账。

先看成本模型。GPU 成本包含三部分：实例费用（按秒或按小时计费）、存储费用（模型文件和数据）、网络流量费用（传输数据）。多模型共享 GPU 后，实例数量减少，实例费用大幅下降，但存储和网络费用可能略增——因为多个模型要同时加载和传输。

$$C_{\text{monthly}} = C_{\text{instance}} + C_{\text{storage}} + C_{\text{network}} - S_{\text{savings}}$$

1. 实例费用：GPU 实例的租赁费用。

$$C_{\text{instance}}$$

2. 存储与网络费用：模型文件存储和数据传输的费用。

$$C_{\text{storage}} + C_{\text{network}}$$

3. 共享节省：因为共享而省下的钱，也就是前面算的成本节约率对应的金额。

$$S_{\text{savings}}$$

账单分析是 FinOps 的日常工作。通过云厂商的账单接口，按模型、按项目、按团队拆分成本，看看哪个模型的 GPU 消耗最多、哪个模型闲置率最高。这就好比合租公寓每月贴出水电费明细，谁用得多谁多摊。

持续优化是最后一环。GPU 型号升级（比如从 A10 升级到 A100，单卡算力提升 3 倍但价格只贵 2 倍）、用 Spot 实例跑低优先级任务、关掉闲置时段的实例——这些都是可以持续做的降本动作。FinOps 的核心是“持续”两个字：降本不是一次性的，而是像记账一样每月复盘。

AI 应用场景

Python 演示

import timeimport threadingfrom dataclasses import dataclassfrom collections import dequefrom typing import List, Dict, Optional @dataclassclass Model:    name: str    priority: int    mem_required: int    mem_actual: int class GPUScheduler:    """多模型共享GPU调度器模拟"""    def __init__(self, total_mem: int):        self.total_mem = total_mem        self.models: List[Model] = []        self.queue: deque = deque()        self.gc_count = 0        self.free_lists: Dict[str, int] = {}     def add_model(self, model: Model, static: bool = True):        """添加模型到共享GPU，static=True为静态分配"""        # 为每个新的模型划分内存        if static:            if sum(m.mem_required for m in self.models) + model.mem_required > self.total_mem:                print("[调度器] 显存不足，拒绝部署模型", model.name)                return False            model.mem_actual = model.mem_required        else:            # 动态分配模式：先按最小需求分配            model.mem_actual = min(model.mem_required, self.total_mem // 4)        self.models.append(model)        self.free_lists[model.name] = model.mem_required - model.mem_actual        print(f"[调度器] 部署模型 {model.name}，占用显存 {model.mem_actual}G")        return True     def dispatch(self):        """调度主循环：按优先级处理请求"""        self.queue = deque(model.priority for model in self.models)        for model in sorted(self.models, key=lambda m: -m.priority):            if self._check_resource(model):                self._allocate(model)            else:                print(f"[调度器] 模型 {model.name} 资源不足，请求排队")                self.queue.append(model.priority);        return True     def _check_resource(self, model: Model) -> bool:        """检查模型是否还有剩余显存配额"""        return self.free_lists.get(model.name, 0) + model.mem_actual > 0     def _allocate(self, model: Model):        """为模型分配一个推理请求的算力"""        self.gc_count += 1        self.free_lists[model.name] = max(0, self.free_lists.get(model.name, 0) - 0.5)        print(f"[调度器] 模型 {model.name} 正在推理，累计推理次数 {self.gc_count}")     def compact_memory(self):        """模拟碎片整理：回收所有模型空闲的显存"""        reclaimed = sum(self.free_lists.values())        for name in self.free_lists:            self.free_lists[name] = 0        print(f"[调度器] 碎片整理完成，回收 {reclaimed:.1f}G 闲置显存")        return reclaimed if __name__ == "__main__":    scheduler = GPUScheduler(total_mem=12)    scheduler.add_model(Model("BERT", priority=3, mem_required=4, mem_actual=4))    scheduler.add_model(Model("GPT", priority=2, mem_required=5, mem_actual=4))    scheduler.add_model(Model("CV", priority=1, mem_required=3, mem_actual=2))    scheduler.dispatch()    scheduler.compact_memory()

1. class GPUScheduler代表一个“合租公寓管家”，负责所有模型的资源分配和调度。
2. add_model(model, static=True)“新租客签约”，通过显存检查决定是否允许该模型加入共享 GPU。
3. model.priority每个租客的“VIP等级”，决定排队顺序。
4. _check_resource(model)查看租客的“剩余水电气额度”，不足则请求排队。
5. _allocate(model)正式执行推理任务，每次调用减少该模型的一点配额。
6. compact_memory()“仓库整理”，统计所有租客的闲置空间并回收，腾出显存给新请求。

常见误区

面试题