过去几年，云上GPU大多以整卡租用的形式交付，一张卡绑定一个实例，用完即释放。这种做法在长期训练任务中尚可接受，但面对参数规模中等、请求并发波动剧烈的推理场景，整卡独占往往意味着利用率长期徘徊在两三成。于是，把加速卡从「设备」抽象为「资源池」的思路开始流行。
三条技术路径并行
算力池化目前有三条主要路径。一是硬件级切分，借助GPU厂商提供的多实例能力，把一张卡划分为若干显存与算力相对隔离的实例，粒度最细、隔离最硬；二是软件级切分，通过驱动层时间片轮转或显存超额分配，让多个容器共享同一张卡，成本更低但存在互相干扰；三是把算力做成远程服务，应用侧不再直接持有设备，而是通过统一接口提交任务，由平台决定落在哪块卡上。
三条路径并非互斥。不少平台在边缘侧用软件切分提高密度，在核心集群用硬件切分承载对稳定性敏感的在线服务，再用远程调用层做统一入口，按业务等级分流。
调度器决定实际收益
切分只是第一步，真正决定收益的是调度。拓扑感知是基础：同一节点内的卡间互联带宽远高于跨节点，若调度器把需要频繁通信的推理副本分散到不同机器，池化带来的收益很快会被网络开销吃掉。其次是弹性伸缩，推理流量具有明显的昼夜差异，平台需要根据队列长度和响应时延，在分钟级甚至秒级调整实例数量。
更深一层的变化是混部。把在线推理与离线批处理、数据预处理放在同一批加速卡上，用低谷时段填补空闲算力。这要求平台具备优先级抢占、显存配额与故障隔离能力，否则一个失控任务就可能拖垮整个节点。
落地仍需跨过几道坎
- 隔离与性能的平衡：细粒度切分可能带来吞吐损耗，需要在密度和稳定性之间取舍。
- 故障域收敛：共享同一张卡的实例会相互波及，需要更细的健康检查与快速驱逐机制。
- 计量与计费：按卡时计费难以反映真实消耗，按显存占用、算力配额或Token计量正在被探索。
- 可观测性：显存占用、算力利用率、排队时延等指标需统一采集，才能支撑调度决策。
结语
算力池化不只是资源复用，它把云上加速卡的交付方式从「卖设备」推向「卖能力」。当切分、调度、隔离与计量形成闭环，企业才可能在有限预算下获得更平滑的推理吞吐。对云厂商而言，谁能在保证稳定性的前提下把利用率做得更高，谁就更接近下一阶段算力生意的定价权。