单次推理只用两成算力，Heidi靠NVIDIA MPS把16块GPU砍到4块

• 4727
• 2026-08-29

GPU利用率卡在15%到20% 在Amazon EC2上跑自动语音识别（ASR）推理，最头疼的不是模型不够快，而是GPU根本喂不饱。一次ASR推理请求通常只占用一块GPU算力的15%到20%，但NVIDIA CUDA默认的时间切片机制强制进程排队访问，剩下80%的硬件资源只能干等着。 Heidi Health是一家AI医疗护理伙伴，每周处理超过240万次临床咨询，覆盖190个国家。为了在流量高峰时保持亚秒级转录延迟，这家公司不得不部署16块GPU实例来扛住压力。 从16块GPU降到4块 此前，Heidi针对临床语音识别微调了NVIDIA Parakeet TDT 0.6B V2模型。现在的问题变成了：模型训好了，怎么高效地把它跑起来。 答案是把NVIDIA CUDA多进程服务（MPS）和NVIDIA Triton推理服务器组合起来，部署在Amazon EC2 GPU实例上。这套方案把GPU基础设施需求直接削减了75%，从16块实例降到4块，同时保持每块GPU每秒92.1个请求（RPS）的吞吐，延迟依然控制在亚秒级。 时间切片为什么浪费算力 在Parakeet TDT 0.6B V2模型上，单次ASR推理请求大约只用到NVIDIA L40S GPU上142个流式多处理器（SM）中的15%到20%。每次前向传播时，其余80%的SM都处于空闲状态。 CUDA默认的时间切片行为进一步放大了这种浪费：每个进程独占GPU访问权，进程之间轮流切换，上下文切换还会带来额外开销，根本不存在并发执行。结果就是，单块GPU在可接受延迟下（平均小于650毫秒，p99小于1000毫秒）只能处理大约62 RPS。Heidi当前的生产部署需要16块GPU，才能在满足延迟服务等级协议（SLA）的前提下应对峰值流量。 三种GPU共享机制怎么选 为了填补利用率缺口，团队评估了NVIDIA硬件上可用的三种GPU共享机制，它们在隔离性、并发性和运维复杂度上各有取舍： NVIDIA CUDA MPS：CUDA API的二进制兼容替代实现，允许多个进程无需修改代码即可并发共享GPU。 时间切片：进程轮流独占GPU，上下文切换带来开销，没有并发执行。 多实例GPU（MIG）：将GPU物理分区，提供更强的隔离性，但灵活性和资源利用率受限。 对比之下，MPS直接消除了空闲SM的浪费。默认时间切片下进程排队等待，而MPS让多个进程的CUDA操作真正并发执行，把原本闲置的算力填满。 模型层优化与请求调度 除了GPU共享机制，方案还叠加了模型级优化和请求调度。模型层面通过ONNX和TensorRT进行转换与加速，减少推理时的计算开销。请求调度则交给Triton推理服务器，由它统一管理并发请求的分发与排队。 这些组件在Amazon EC2上集成后，形成了一条完整的推理链路：MPS负责让多个进程并发占用GPU，Triton负责把请求高效地喂给模型，ONNX和TensorRT负责压缩单次推理的计算成本。最终效果是，同样的硬件上吞吐从大约62 RPS提升到92.1 RPS，同时把所需GPU数量从16块压缩到4块。 对ASR推理部署的启示 Heidi的案例说明了一个关键问题：当单次请求的GPU利用率很低、但延迟要求又很严格时，单纯堆硬件并不是最优解。默认的时间切片机制会让大部分算力闲置，而MPS提供了一条无需修改代码就能并发共享GPU的路径。 对于同样面临低利用率、高并发、严格延迟约束的ASR推理场景，这套组合方案提供了一个可参考的落地思路：先识别利用率缺口，再选择合适的共享机制，最后用推理服务器和模型优化把吞吐拉上去。 特别