CUDA 13.4 与共享 GPU 推理：MPS v3 如何改变资源管理

共享 GPU 首先是资源边界问题

从利用率转向服务目标。对推理平台，值得验证的假设是：更细的资源控制能否在同一张卡上容纳更多工作，同时守住交互请求的等待时间。可以把在线对话与离线向量生成作为两类实验流量。前者关注首 token 和持续输出，后者可以更重视批量完成速度。单看 GPU 平均利用率，会把这两种不同的目标混在一起。

先区分容量、带宽和隔离。给一个进程限制可分配显存，只能回答容量预算的一部分问题，不能据此推导它获得了固定内存带宽或固定响应时间。MIG 文档描述的是受支持硬件上独立分配的计算与内存系统资源。[5] 因此，选型时应分别列出容量边界、性能干扰和故障恢复要求，再测试对应机制；不能把 MPS 的配置名称直接当作 MIG 的替代证明。

显存预算与失败行为要一起设计

显存限制会改变失败方式。MPS v3 显存分区文档要求 Linux、cgroup v2 和非 MIG 设备；超过硬限制会导致分配失败，超过软限制则可能在真实压力下成为驱逐对象，托管内存另有约束。[4] 对在线服务的推论是：容量规划必须包含请求中途失败的代价。将较可中断的后台作业和交互推理分开验收，比只证明模型能够加载更有意义。

按一次请求的生命周期做预算。我们的建议是记录空闲服务、加载模型、预热、短上下文、长上下文和并发峰值各阶段的显存高水位。把常驻占用、随活跃请求增长的占用、临时工作区和恢复余量分开记录。此处应使用实际观测值，不给出通用的“预留百分比”。相同模型在不同后端或批处理策略下，配置一个相同容量数字也未必具有相同效果。

一个典型的误判是只在模型加载完成后测量显存，再把剩余容量全部分给其他进程。真正的高水位可能出现在长请求进入、批次扩大或某个临时算子分配工作区时。建议为每种任务记录稳态与峰值，并保留恢复余量；限额要对应服务的生命周期，而不是对应某一瞬间的监控截图。没有这些数据，共享部署只是把潜在的容量冲突延后到线上。

还需要明确谁可以被中断。离线处理能够重跑，交互请求却有用户正在等待；二者即使消耗相同显存，也不一定适用同一种压力处理策略。把工作负载分成可重试、可延期和需要连续响应的类别，再决定资源预算与排队优先级。这样才能把底层资源控制翻译成实际产品承诺，而不是只有一组看起来精确的配置数字。

先建立基线，再测共享与限额

建立可以归因的对照实验。固定硬件、驱动、模型权重、精度、服务镜像和请求样本，先测单独部署，再测共享部署，最后逐项加入资源限制。保留请求到达时间，分别改变长上下文比例、输出长度与背景作业强度。每次只改变一个因素，并重复运行。这样才有机会分清：结果来自工具链升级、负载混合，还是资源分区本身。

用合格请求衡量吞吐。建议将有效吞吐定义为单位时间内完整成功、且同时满足既定首 token 延迟和输出间隔目标的请求数。目标值由产品要求确定，不能在看到实验结果后再修改。同时分别报告两类流量的 P50、P95、P99 延迟、错误率、拒绝率和完成量。即使总 tokens/s 上升，若在线请求尾延迟恶化，共享策略也可能不适合该业务。

实验期间尤其要固定请求到达方式。只在上一请求完成后才发送下一请求的测试，可能隐藏真实用户同时到来的排队问题。可以保留一段匿名化的到达时间序列，让不同方案接收相同流量，再观察交互请求与背景任务各自的等待分布。对外报告时说明负载条件，避免把低并发的最好结果当作稳定容量。本文提出的是测量方案，没有宣称已经完成这组硬件实验。

故障和升级决定能否长期运行

把恢复过程也纳入实验。MPS 文档说明其错误包含能力存在边界，共享 GPU 的部分客户端可能一起受到致命 GPU 故障影响。[6] 在隔离的测试环境中，可分别检查容量耗尽、客户端异常退出和服务重启后的恢复时间，并确认重试不会制造重复结果或持续放大流量。对于持续输出请求，还要定义已经返回部分内容后的失败行为，避免只统计最终 HTTP 状态。

升级与启用新能力分开验收。官方发布说明区分了 CUDA 13.x 的小版本兼容与 13.4 新能力的驱动要求：新能力及新平台需要支持它们的 R615 或更新驱动；Rubin 支持仍属开发者预览。[2] 建议先在独立测试节点固定完整的软件版本组合，验证模型正确性和后端兼容，再开展共享性能实验，最后对照既有服务目标决定是否扩大部署。

从 GPU 指标走向模型服务指标

对 AI 平台的实际意义。我们的判断是，这次更新值得优先评估在负载有互补性、任务可以分类且观测数据完整的场景。部署决策应形成一份可复查记录：接受哪些干扰、允许哪些任务被中断、达到什么服务目标、失败时怎样恢复。资源管理接口让这些策略更容易实现；是否节省实际成本，仍要由满足服务目标的完成量与完整运行成本共同回答。

对使用 Token AI Cloud 的 Token Cloud API的团队，最直接的观测对象仍是请求延迟、失败状态和 Token 用量。它们可以提示服务体验是否改变，但不能单独证明底层启用了 MPS、MIG 或某种 GPU 分区。本篇讨论部署者应如何验证资源管理策略，并未披露本站基础设施采用了哪一种方案。把底层机制与用户能感知的结果连起来，同时保留证据边界，才是这次 CUDA 更新值得延伸讨论的地方。

封面是 Token4AI 原创的共享计算预算、显存限制与请求质量示意图，不代表物理 GPU 切片，也不把 MPS 的控制机制画成 MIG 的硬件隔离结构。