NVIDIA MPS 助力 ASR 推理成本降低 75%，GPU 实例从 16 台缩减至 4 台

GPU 利用率不足是 ASR 大规模推理的核心痛点。以 NVIDIA Parakeet TDT 0.6B V2 模型为例，单次推理请求仅占用 L40S GPU 142 个流式多处理器（SM）中的约 15% 至 20%，其余算力在每次前向传播期间完全闲置。CUDA 默认的时间片机制进一步加剧了这一浪费——各进程轮流独占 GPU，上下文切换带来额外开销，无法实现并发执行。这使得单张 GPU 在可接受延迟范围内仅能处理约 62 个请求每秒，Heidi Health 因此需要部署 16 台 GPU 实例才能满足峰值流量与延迟 SLA 要求。

NVIDIA 提供了三种 GPU 共享机制以应对多租户场景：默认时间片轮转、MIG（多实例 GPU）以及 MPS（多进程服务）。时间片方式隔离性强但无法并发；MIG 通过硬件物理分区实现固定隔离，适合多租户场景；MPS 则通过单一 GPU 上下文管理所有 CUDA 工作，支持不同进程的内核并发执行，无需修改现有代码。对于 ASR 这类小模型高并发的工作负载，MPS 是最优选择，可通过 CUDA_MPS_ACTIVE_THREAD_PERCENTAGE 环境变量灵活配置每个进程的 SM 分配比例。

在具体部署配置上，转录实例采用 25% SM 分配，运行 4 个并发 MPS 进程，每个进程占用约 2.5 GB 显存（总显存 48 GB）；说话人分离实例则采用 12% SM 分配，运行 8 个并发进程，每个约占 1.8 GB 显存。模型层面，计算密集型的 Conformer 编码器（24 层、1024 隐藏维度）通过 ONNX Runtime 配合 TensorRT 执行提供程序运行，利用算子融合与 FP16 精度校准大幅提升吞吐；而 RNN-T TDT 解码器则保留 PyTorch CUDA 原生运行，以适应变长 token 生成的灵活性需求。

NVIDIA Triton 推理服务器负责请求调度与批处理管理。转录任务采用动态批处理策略，在可配置的 50 毫秒延迟窗口内积累请求后统一分发，优先批大小设置为 4、8、16；说话人分离任务则采用序列批处理，服务端维护每段录音的流式状态，客户端通过关联 ID 发送 15 秒音频块，会话在 600 秒无活动后自动过期。每个 Triton 模型实例与一个 MPS 分区一一对应，实现批处理调度与 GPU 分区层的自然集成。

整套推理流水线部署在 Amazon EC2 g6e.4xlarge 与 g7e.4xlarge 实例（搭载 NVIDIA L40S，48 GB 显存）上，通过 Docker Compose 编排三个容器化组件协同运行。最终基准测试结果显示，该方案在每 GPU 92.1 RPS 的负载下，均值延迟低于 650 毫秒，P99 延迟低于 1000 毫秒，GPU 实例总数从 16 台压缩至 4 台，基础设施成本降低 75%。这一实践为需要在严格延迟约束下大规模部署语音识别服务的企业提供了可复用的工程参考路径。

要点

• CUDA 默认时间片机制导致 ASR 推理中约 80% 的 GPU 算力闲置，MPS 通过并发内核执行消除这一浪费，无需修改现有 CUDA 代码。
• 结合 MPS 并发共享、ONNX Runtime + TensorRT 模型优化以及 Triton 动态批处理，可将 GPU 实例需求从 16 台降至 4 台，成本降幅达 75%。
• 转录与说话人分离任务可针对各自特性独立配置 MPS SM 分配比例，实现精细化资源管控。
• 该方案在每 GPU 92.1 RPS 负载下仍维持亚秒级延迟（P99 < 1000 ms），验证了生产环境的可行性。
• MPS 最适合单 GPU 上运行多个小模型的高并发场景，与 MIG 的硬件物理隔离方案形成互补，企业应根据隔离需求与并发特性选择合适机制。