模型推理的输入预处理流水线：CPU 预处理和 GPU 推理解耦的设计与实践

基础设施不需要漂亮话。GPU 应该做它最擅长的事情——矩阵运算，而不是被数据预处理拖垮吞吐量。

一、问题出在哪里：GPU 的空转比想象中更严重

在生产环境的模型推理服务中，GPU 利用率常年低于 60% 的情况并不少见。表面上看是请求密度不够，实际上问题往往出在输入预处理占据了推理链路的大量时间。一个典型的在线推理请求从接收原始输入到返回推理结果，中间经历了：输入校验、Tokenization、Embedding 查表、图像 Resize/归一化、Padding/Batching 组装等步骤。如果这些操作都放在 GPU 推理的同一个进程内串行执行，GPU 在数据就绪之前只能空等。

以文本生成场景为例，使用 HuggingFace Tokenizer 对一个 2048 token 的输入做编码，单次耗时约 3-8ms。看起来不多，但在 batch_size=32、QPS=100 的场景下，Tokenizer 的 CPU 消耗就会成为瓶颈。如果 Tokenizer 和模型推理在同一个进程中，GPU 等待 CPU 处理完 tokenization 的累计空闲时间可以占到单次推理总耗时的 15%-30%。

对于视觉模型，情况更糟。一张 4K 分辨率图像的 Resize + Normalize + ToTensor 操作在 CPU 上需要 20-50ms，而 ResNet-50 的 GPU 推理只需要 2-5ms。预处理时间是推理时间的 10 倍以上——不把这两者解耦，GPU 的算力就是摆设。

sequenceDiagram participant Client as 客户端 participant PreP as CPU预处理服务 participant Queue as 消息队列 participant Infer as GPU推理服务 Client->>PreP: 原始请求(raw input) PreP->>PreP: Tokenization / Resize / Normalize PreP->>Queue: 标准化Tensor数据 Queue->>Infer: 批量拉取标准化数据 Infer->>Infer: GPU推理(纯计算) Infer-->>Client: 推理结果

二、解耦方案的核心设计

解耦的本质是一个生产者-消费者模型，CPU 侧负责生产标准化 Tensor，GPU 侧作为消费者只管推理。这个架构需要解决三个核心问题：

（1）数据传输格式与序列化

CPU 预处理产出的数据需要通过某种管道传给 GPU 服务。常见做法是使用 Protocol Buffers 或 FlatBuffers 序列化 Tensor 数据。但要注意，对于大张量（如图像特征图），序列化/反序列化本身的开销需要评估。实测中，FlatBuffers 的零拷贝特性在处理 1MB+ 的 Tensor 时比 Protobuf 减少约 40% 的传输延迟。

（2）Batching 策略的重新设计

解耦后，Batching 的逻辑从推理引擎内部移到了上游。CPU 预处理服务需要实现动态 Batching——根据当前积压的请求数和延迟目标，动态决定批次大小。常用的策略是max_batch_size+max_wait_time的组合：只要累积的请求达到max_batch_size或者最早的请求等待超过max_wait_time，就立即打包发送。

type DynamicBatcher struct { maxBatchSize int maxWaitTime time.Duration buffer chan *Request } func (b *DynamicBatcher) Run(ctx context.Context) { batch := make([]*Request, 0, b.maxBatchSize) timer := time.NewTimer(b.maxWaitTime) for { select { case req := <-b.buffer: batch = append(batch, req) if len(batch) >= b.maxBatchSize { b.flush(batch) batch = batch[:0] timer.Reset(b.maxWaitTime) } case <-timer.C: if len(batch) > 0 { b.flush(batch) batch = batch[:0] } timer.Reset(b.maxWaitTime) case <-ctx.Done(): return } } }

（3）背压机制

GPU 推理服务是典型的算力受限型服务，处理速度有上限。当请求量超过 GPU 的处理能力时，需要在预处理侧做流量整形。可以通过监控 GPU 推理服务的排队深度，动态调整 CPU 预处理服务的产出速率。

三、技术选型：消息队列还是 gRPC Stream

CPU 预处理和 GPU 推理之间的通信方式直接影响延迟和吞吐。两种主流方案对比：

对于在线推理场景（P99 延迟要求在 100ms 以内），建议使用 gRPC Stream + 共享内存的方案。具体做法是将 CPU 预处理服务和 GPU 推理服务部署在同一个 Pod 内，通过 Unix Domain Socket 或共享内存（如 Plasma Store）传递 Tensor 数据，完全避免网络序列化开销。

对于近线推理（P99 延迟在 500ms-2s），使用 Redis Stream 或 Kafka 作为中间队列更为灵活，可以实现预处理和推理的独立扩缩容。

四、生产环境的数据观察

在某对话式 AI 平台的实际部署中，我们将文本预处理（Tokenizer + Embedding 查表）从推理进程中剥离，部署为独立的 Deployment，通过 gRPC Stream 通信。对比数据如下：

GPU 利用率的提升不是因为做了什么优化，只是让 GPU 不再等 CPU 完成预处理。这项工作没有用到任何新奇的技术，纯粹是把正确的计算放到正确的硬件上。

预处理服务的扩缩容也需要独立考虑。在实际运行中，CPU 预处理服务的 HPA 指标应该基于其自身的请求排队深度，而不是 CPU 利用率——因为 Tokenization 是典型的计算密集型操作，CPU 到 100% 时 P99 延迟已经炸了。我们使用的是 KEDA + Prometheus 自定义指标，当排队深度超过阈值时自动扩容。

五、总结：解耦不是银弹，但是第一性原理

CPU 预处理和 GPU 推理解耦不是一个新概念，但很多团队在快速上线模型的压力下，会选择"先把所有逻辑塞在一个容器里，后面再拆"。这个"后面"通常没有来。

衡量是否需要解耦的决策标准很简单：监控 GPU 的空闲等待时间。如果 GPU 在单个推理周期内有超过 10% 的时间花在等待数据就绪上，就应该把预处理剥离出去。这个准则适用于文本、图像、语音等所有模态。

在实施层面，解耦的关键不在于选择什么中间件，而在于Batching 策略和背压机制的设计。这两个设计不到位，解耦之后可能比不解耦更差——增加了一跳网络延迟，但没有带来吞吐的提升。

最后，如果模型足够小（推理时间 < 10ms），解耦引入的额外通信开销可能反而得不偿失。工程决策始终应该基于测量数据，而不是架构的"美感"。