消息队列选型：Kafka、Pulsar 和 NATS 在 AI 场景下的差异
消息队列选型：Kafka、Pulsar 和 NATS 在 AI 场景下的差异
一、AI 工作流对消息队列的特殊要求：不止"发出去就行"
传统业务系统的消息队列关注点是吞吐量和可靠性——订单消息不能丢、支付消息要精确一次。但 AI 场景有自己特殊的需求维度：大模型推理请求的负载均衡策略、多步推理 Pipeline 的有状态路由、长时间任务（分钟级）的进度跟踪、以及 GPU 任务与 CPU 任务的混合调度。
Kafka 以日志式存储和高吞吐著称，Pulsar 靠存算分离和多租户打入云原生市场，NATS 以极致轻量和边缘部署见长。三者在传统场景的对比已有大量资料，本文重点分析它们在 AI 推理 Pipeline、分布式训练任务调度、模型更新通知这三个 AI 特有场景下的适配程度。
二、分区固定 vs Topic 弹性 vs 无状态 JetStream：三种模型的 AI 适配度
Kafka 的分区模型在 AI 场景下的问题：消费者组内的消费者数量不能超过分区数。比如你设置了 4 个分区，那么同时处理推理请求的 Worker 最多只有 4 个。如果要增加到 8 个 GPU Worker，必须带数据迁移地增加分区数。这在高频扩缩容的 AI 推理场景下是一个结构性约束——GPU 弹性伸缩要求消费者能立即加入消费，而不是等运维人员改分区。
Pulsar 的存算分离更适合 AI：Broker（计算）和 BookKeeper（存储）分离后，消费者数量不受分区数限制。同一个 Topic 可以有 20 个共享订阅的消费者同时拉取，而且支持 Sticky 模式——同一个推理请求的分步处理可以路由到同一个 Worker，避免状态丢失。
NATS 的 JetStream：用 Subject 层级做路由，例如inference.gpu0.qwen2.72b，消费者通过通配符订阅inference.gpu0.*。这天然适配 GPU 编号到推理请求的映射。NATS 的请求-响应模式（Request-Reply）可以在不引入额外中间件的情况下实现推理请求的同步等待和超时控制。
三、AI 场景下的关键能力评分
3.1 推理请求分发
| 能力维度 | Kafka | Pulsar | NATS |
|---|---|---|---|
| 消费者弹性扩缩容 | 受分区数限制 | 无限制，共享订阅 | 无限制，队列订阅 |
| 请求级负载均衡 | 按分区粘性 | 支持 Round Robin + Sticky | Round Robin |
| 同步 Request-Reply | 需手动实现回复 Topic | 需手动实现 | 内置支持 |
| P99 延迟（1KB 消息） | 5-15ms | 3-10ms | 0.5-2ms |
| 故障恢复时间 | 秒级（ISR 切换） | 秒级（Bookie 切换） | 毫秒级（Raft 切换） |
3.2 大消息传输（模型更新包）
AI 场景中一个被低估的需求：模型更新通知往往伴随模型权重的传输。微调后的 LoRA adapter 可能是几十 MB，全量模型更新是几十 GB。
| 能力维度 | Kafka | Pulsar | NATS |
|---|---|---|---|
| 默认消息大小限制 | 1 MB | 5 MB | 1 MB（JetStream） |
| 可配置最大消息 | 可调（不推荐 >10MB） | 无硬限制 | 8 MB（可调） |
| 大文件传输推荐方式 | 外挂对象存储 + 消息引用 | 外挂对象存储 + 消息引用 | Object Store（内置） |
关键结论：不要在消息队列里直接传输模型权重文件。三者都应在消息体中只放模型文件路径/URL，实际文件走对象存储（S3/MinIO）。NATS 内置的 Object Store 能力可以在不引入额外组件的情况下完成这个模式。
3.3 长时间任务跟踪（训练任务）
分布式训练通常持续数小时甚至数天。任务状态需要被持续追踪，而且消费者连接可能因为网络抖动断开后重新接入。
| 能力维度 | Kafka | Pulsar | NATS |
|---|---|---|---|
| 消息回溯 | 基于时间/offset | 基于时间/MessageID | 基于序列号 |
| 消费者重连后进度恢复 | 自动（offset 提交） | 自动（ack 确认） | 自动（JetStream Ack） |
| 死信队列 | 不支持（需手动） | 内置 DLQ | 内置（JetStream） |
Pulsar 的 Ack 机制是逐条确认而非 offset 提交，意味着消费失败的单独消息可以被重试而不影响后续消息的处理。在训练任务调度中，某个 GPU 节点的偶发 OOM 不应让整批任务重跑。
四、运维维度的成败关键
Kafka 在 AI 场景下的额外负担：
- ZooKeeper/KRaft 的运维复杂度在需要频繁创建/删除 Topic 的 AI 实验环境中会被放大。每次模型实验都可能创建一组新 Topic 来隔离不同版本的数据流。
- 分区重分配（rebalance）期间，消费者组的消费能力短暂下降。如果这个时间窗口恰好与 GPU 推理高峰重合，请求排队延迟会显著上升。
- 精确的消息顺序保证在 AI 推理 Pipeline 中反而成为性能拖累——大多数推理请求不需要严格顺序，但需要最高的并发分发效率。
Pulsar 的"重量级"代价：
- 组件太多：Broker + BookKeeper + ZooKeeper。最小生产环境的资源消耗就在 16GB 内存以上。对于只有 3-5 个 AI 微服务的小型团队，这是资源的严重浪费。
- 配置参数的复杂度较高：bookkeeper 的 journal 和 ledger 配置、broker 的负载均衡策略、消息保留策略，每个参数出错都可能导致生产故障。
- 社区文档 AI 场景的案例相对较少，遇到特定问题需要深入源码排查。
NATS 的"太简单"问题：
- JetStream 的持久化消息在极端情况下（如磁盘满）的行为需要特别关注。默认配置下，磁盘满后 JetStream 直接拒绝写入而非降级。
- 缺乏 Kafka Connect 那样丰富的生态连接器。如果团队依赖 ELK/Prometheus/Flink 等大数据生态的现成连接器，NATS 需要自行开发。
- 消息回溯能力弱于 Kafka——Kafka 可以按时间回溯到任意时间点，NATS 受限于保留策略内的流数据。
结论
按场景推荐：
| AI 场景 | 首选 | 理由 |
|---|---|---|
| 高吞吐推理请求分发 | NATS | 延迟最低，消费弹性最好 |
| 分布式训练任务调度 | Pulsar | Ack 粒度细，死信队列原生 |
| 模型更新 + 数据 pipeline | Kafka | 生态最全，连接器丰富 |
| 多团队 AI 平台统一消息 | Pulsar | 多租户隔离最成熟 |
| 单团队 AI 服务间通信 | NATS | 部署最简单，运维成本最低 |
一个务实的组合策略：推理请求路由用 NATS（低延迟、高弹性），数据 Pipeline 和模型更新链路用 Kafka（生态成熟），训练任务调度用 Pulsar（Ack 粒度细）。混合架构的代价是运维多一套组件，但比"一个框架硬撑所有场景"的隐性故障风险要可控得多。
消息队列在 AI 基础设施中从来不是主角，但它一旦出问题，所有上游服务都会被拖垮。选型时把 80% 的测试时间花在故障场景上，而不是正常工作的基准测试上——断网、磁盘满、消费者挂掉后再重连，这些才是真实的考评维度。