为什么 100 万个租户的限流，传统 Topic 撑不住？RocketMQ 旧版每个 Topic 约 1KB 元数据存储于内存，百万级 Topic 光元数据就要吃掉 1GB 堆内存，且 Broker 要维护所有队列的偏移量，消费线程按队列轮询，队列数越多线程切换越频繁，单机 TPS 随 Topic 数量线性下降。LiteTopic 的核心突破在于将元数据从 1KB 压缩到约 50 字节，且通过『就绪集合』事件驱动取代轮询——两者本质差异，是『存所有』和『只存活跃的』之间的架构取舍。

百炼网关实现毫秒级动态调速的关键，是 LiteTopic 消费侧的 Suspend 机制。当消费回调返回 `Suspend N` 毫秒，Broker 就在 N 毫秒内暂停对该 LiteTopic 的拉取调度——其他 LiteTopic 的拉取完全不受影响。这与线程 `Sleep` 的本质区别在于：Sleep 是阻塞线程，共享线程池里一个租户超时，其他租户的消费线程也会被饿死；Suspend 在 Broker 端直接标记该队列『不可调度』，释放消费线程去处理其他队列，实现『限流一个租户，不传染其他租户』的物理隔离。

Apache RocketMQ 5.5.0 已将 LiteTopic 开源，这意味着阿里云百炼的这套方案不只是内部优化，而是标准化的基础设施能力。当前能看到的关键变量是：Anthropic MCP 和 Google ADK 都在今年的 Roadmap 中强调『有状态 Agent 会话』需要持久化通信通道。如果 LiteTopic 成为 AI Agent 异步通信的事实标准，RocketMQ 将从一个『消息队列』进化为『AI 运行时总线』——但挑战是 Pulsar 的租户隔离和 Kafka 的流处理生态也在快速对齐。拐点要看 2026 年下半年，谁先拿下主流推理框架的默认集成。

百炼网关将限流比降低 10 倍，但『物理隔离』的代价是每个 User+Model 组合都要创建独立 LiteTopic——百万级租户下，队列数量轻松破千万。一个问题值得追问：LiteTopic 的单队列模型（每个 Topic 只能被一个消费者线程处理）在极端流量下，会不会成为新的瓶颈？当某个热门模型的请求量远超单个消费线程的处理能力，『物理隔离』反而变成『单线程瓶颈』。百炼的隐藏解可能是：对热门模型做 User 聚合，再通过 LiteTopic 的『就绪集合』动态调度——但这需要精细的流量探测与线程池分配策略，比单纯物理隔离复杂一个量级。