大数据与AI：实时流处理里把LLM推理嵌进去，Kafka+Spark的方案延迟和吞吐扛不住，有没有更合适的架构选型思路？

一、问题的提出：为什么“流里调模型”第一版总是能跑、第二版就崩

几乎所有做过这类系统的团队都经历过同一个剧本。第一版：Kafka 收数据，Spark Structured Streaming 读流，在 foreachBatch 里对每批数据循环调用一次 LLM API（或者本地部署的推理服务），结果写回下游。数据量小、QPS 低的时候，这套东西跑得很稳，Demo 效果也不错。

第二版：业务方看到效果，要求接入更多数据源、把 QPS 从 5 提到 200、把延迟 SLA 定在 3 秒内。于是问题集中爆发：Spark 的微批间隔（trigger interval）本来设的是 10 秒，一批里塞进几百条记录，串行调用模型，一批就要跑几分钟；把并发度调大，GPU 显存 OOM；调小批次，调度开销又占大头。更麻烦的是，Spark 的背压机制会让上游 Kafka 消费速率自动下降，于是“实时”变成了“近实时”，再变成“准离线”。

这里需要先厘清一个常被混淆的概念。Spark Structured Streaming 的微批（micro-batch）模型本质上是一种“以批的方式模拟流”的执行范式，其设计目标是吞吐与 Exactly-Once 语义，而不是低延迟。官方文档明确说明微批的端到端延迟通常在 100ms 量级起步，实际生产环境受调度、shuffle、checkpoint 影响往往在秒级（来源：Apache Spark 官方 Structured Streaming Programming Guide，2024 版）。而 LLM 单次推理的耗时，在 7B 级模型、输出 200 token 的典型场景下，即使使用 vLLM 这类高吞吐引擎，单请求延迟也在数百毫秒到数秒之间（来源：vLLM 官方博客与 PagedAttention 论文，SOSP 2023）。

两个“秒级”叠加，不是相加而是相乘——因为微批是同步屏障：一批里最慢的那条记录决定整批的完成时间。LLM 解码的 token 生成本质上是长尾分布，少数长输出请求会把整批拖住。这就是第一重共振。

本文评述：很多技术讨论把矛头指向“Spark 不适合做 AI”，这个归因过于粗糙。Spark 在特征工程、状态聚合、窗口计算上依然是成熟选择；真正的问题是把“同步屏障式调度”与“长尾异步任务”放在同一个执行图里。换掉 Spark 而不改变调度范式，换成 Flink 一样会崩——只是崩的形态不同。

1.1 一个典型的失效时间线

为了把问题说得更具体，下面给出一个基于公开资料与工程经验整合的失效时间线（整合性描述，非单一实测数据）：

这张表的关键信息不是具体数字，而是劣化是非线性的。线性劣化可以通过加机器解决，非线性劣化说明系统进入了某个反馈回路——这里是“推理阻塞→背压→批次积压→批次更大→更慢”的正反馈。

二、失效机理拆解：微批调度、长尾解码与背压的三重共振

2.1 第一重：微批的同步屏障

Structured Streaming 的每个微批是一个 job，job 内所有 task 完成后才进入下一批。如果推理调用写在 driver 侧的 foreachBatch 里，那么整批就是完全串行的；即使写在 executor 侧的 mapPartitions 里，每个 partition 内部也是串行，且 partition 数受 Kafka 分区数约束，横向扩展能力有限。

更隐蔽的问题是 checkpoint 与微批的耦合。当一批执行时间超过 trigger interval，下一批会立即排队；积压到一定程度，checkpoint 的完成时间被拉长，而 checkpoint 本身又要写 HDFS/S3，进一步占用 IO。这条链路一旦进入拥塞，恢复非常困难。

2.2 第二重：自回归解码的长尾

LLM 推理的耗时与输出 token 数近似线性。输入相同、输出长度不同的两个请求，耗时可能差 5–10 倍。在同步批处理里，这意味着批的完成时间由最长的那个请求决定，GPU 在等待期间处于低利用率状态。vLLM 的 PagedAttention 论文指出，传统推理系统的 GPU 显存浪费可达 60%–80%，主要来自 KV Cache 的碎片化与预留（来源：Kwon et al., Efficient Memory Management for Large Language Model Serving with PagedAttention, SOSP 2023）。

这里必须引入一个关键概念：连续批处理（continuous batching，又称 iteration-level scheduling）。它的核心思想是：批不是静态的，而是在每个解码 step 动态重组——完成的请求立即退出，新请求立即加入。Orca 系统最早系统化提出这一思路（来源：Yu et al., Orca: A Distributed Serving System for Transformer-Based Generative Models, OSDI 2022），vLLM、TensorRT-LLM、TGI 等主流引擎均已实现。

笔者认为：连续批处理不是一个“优化项”，而是生成式推理的“基础设施级前提”。任何把 LLM 推理嵌入流处理的架构，如果推理层不具备连续批处理能力，那么无论上游是 Spark 还是 Flink，吞吐都会被静态批的同步屏障锁死。这一点在选型时应当作为硬性门槛，而非加分项。

2.3 第三重：背压的跨层传导

Spark 的背压机制（spark.streaming.backpressure.enabled）会根据上一批的处理速率动态调整下一批的消费量。设计初衷是保护系统不被打爆，但在“推理慢”的场景下，它会把推理的慢翻译成消费的慢，于是 Kafka lag 增长，下游实时性丧失。更糟的是，背压的调节是滞后的、基于历史批次的，容易产生振荡。

Flink 的 credit-based 流控在机制上更精细，但同样无法解决“算子内部是长任务”的问题——因为流控管的是网络缓冲，管不了算子内部的阻塞调用。这就是为什么“换成 Flink 就好了”往往是一厢情愿。

三、分析主线：语义分层调度框架的提出

综合上述三重共振，可以抽象出一个更本质的判据：一个计算任务是否应该与流处理算子共享调度器，取决于它的“时间尺度”与“失败语义”是否与流处理一致。

流处理算子的典型特征是：单次执行毫秒到秒级、可重放、幂等或可补偿、状态可 checkpoint。LLM 推理的典型特征是：单次执行百毫秒到数十秒、有随机性（temperature>0 时不可重放）、资源强耦合（GPU 显存）、失败重试代价高。二者在四个维度上都不匹配。

由此本文提出语义分层调度（Semantic-Tiered Scheduling, STS）框架，其核心是把链路按“语义复杂度”分为三层：

分层的关键不是物理拆分，而是调度权的归属：L1 由流引擎调度，L3 由推理服务调度，二者之间用异步消息与优先级队列连接，流引擎对 L3 只做“投递”与“超时兜底”，不做“等待”。这样背压就不会跨层传导——L3 慢只会让队列变长，L1 依然按自己的节奏消费。

本文评述：STS 框架并非全新发明，它借鉴了微服务架构中“同步调用转异步消息”的经典解耦思路，也借鉴了数据库领域“OLTP/OLAP 分离”的分层思想。其价值在于把“流 + AI”这个模糊命题，转化为一个可判定的分层决策问题：先判断任务属于哪一层，再决定用什么组件，而不是一上来就争论 Spark 还是 Flink。

四、候选架构全景对比与选型决策矩阵

4.1 五类候选方案

方案 A：Kafka + Spark 内嵌推理（基线）。即问题描述中的现状。优点是链路短、运维简单；缺点是前述三重共振。适合 QPS < 10、延迟 SLA > 10s 的场景。

方案 B：Kafka + Flink + 异步推理算子。Flink 的 Async I/O 算子（AsyncDataStream.unorderedWait）允许在算子内并发发起外部调用而不阻塞，配合 checkpoint 的 in-flight 数据管理，能显著改善吞吐。但 Async I/O 的并发上限受算子并行度与内存约束，且 Flink 的 checkpoint 对齐在长任务下仍会引入停顿。适合 QPS 10–100、延迟 SLA 2–10s 的场景。

方案 C：流引擎 + 独立推理服务（Ray Serve / Triton / vLLM）。流引擎只做 L1/L2，L3 通过消息队列投递给独立推理服务。这是 STS 框架的直接实现。优点是解耦彻底、推理层可独立扩缩容、可复用连续批处理；缺点是链路变长、需要处理结果回填与超时。适合 QPS > 50、延迟 SLA < 5s 的场景。

方案 D：流引擎 + 推理网关 + 动态批处理。在 C 的基础上，推理网关承担请求聚合、优先级排序、超时熔断。NVIDIA Triton 的 dynamic batching 与 sequence batching 是典型实现（来源：NVIDIA Triton Inference Server 官方文档，2024）。适合多模型混布、需要细粒度 SLA 的场景。

方案 E：流原生推理（Stream-Native Inference）。把推理调度直接做进流引擎的运行时，例如 Flink 的 ML 算子、Spark 的 Pandas UDF + GPU 调度。目前生态尚不成熟，适合研究与小规模试点。

4.2 选型决策矩阵

需要强调：这张矩阵里的数字是量级参考，不是精确基准。实际表现高度依赖模型大小、输出长度分布、硬件型号与网络拓扑。选型的正确姿势是先用自己的流量画像做小规模压测（见第六节），再对照矩阵定位。

五、参考架构落地：五层结构与关键接口设计

5.1 五层结构

基于 STS 框架，给出一个可直接落地的参考架构（方案 C/D 的融合形态）：

┌─────────────────────────────────────────────────────────┐
│  L0 接入层    Kafka / Pulsar（原始事件流）                │
└──────────────────────────┬──────────────────────────────┘
                           ▼
┌─────────────────────────────────────────────────────────┐
│  L1 快通道    Flink/Spark 规则过滤、聚合、小模型分类       │
│              输出：待推理请求（含优先级、deadline）        │
└──────────────────────────┬──────────────────────────────┘
                           ▼
┌─────────────────────────────────────────────────────────┐
│  L2 检索层    向量库（Milvus/Qdrant）+ 特征存储           │
│              输出：组装好的 prompt 上下文                 │
└──────────────────────────┬──────────────────────────────┘
                           ▼
┌─────────────────────────────────────────────────────────┐
│  L3 推理层    推理网关（优先级队列/超时熔断）             │
│              → vLLM/TensorRT-LLM 集群（连续批处理）       │
└──────────────────────────┬──────────────────────────────┘
                           ▼
┌─────────────────────────────────────────────────────────┐
│  L4 回填层    结果 topic → 流引擎 join → 下游存储/服务    │
└─────────────────────────────────────────────────────────┘

这个结构的关键设计点有三个：

第一，请求消息必须携带 deadline 与优先级。没有 deadline 的请求在推理网关里无法做超时熔断，会无限堆积。建议在 L1 输出时打上 enqueue_ts、deadline_ts、priority 三个字段。

第二，L4 回填必须支持“迟到结果”。推理可能超时或被丢弃，流引擎在 join 时要有超时窗口与降级策略（如返回默认文案、走规则兜底），不能让下游无限等待。

第三，L1 与 L3 之间用独立的 topic 隔离。不要复用原始事件 topic，否则推理积压会污染主链路。建议按优先级分 topic（高优/普通/低优），推理网关按 topic 做差异化调度。

5.2 关键接口示例

推理请求的 schema 建议如下（JSON 示意）：

{
  "request_id": "evt-9f3a...",
  "trace_id": "trace-...",
  "priority": "high",
  "enqueue_ts": 1718000000123,
  "deadline_ts": 1718000003123,
  "model": "qwen2.5-7b-instruct",
  "prompt": "...",
  "max_tokens": 256,
  "temperature": 0.2,
  "cache_key": "ctx-hash-...",
  "callback_topic": "llm.result.high"
}

其中 cache_key 用于前缀缓存（prefix caching）命中，callback_topic 用于结果回填路由。这两个字段在实际工程中能显著降低延迟与成本，后文详述。

六、容量估算与压测：把“扛不住”量化成数字

6.1 容量估算的基本公式

推理集群的 GPU 需求可以用一个简化的吞吐模型估算（模拟公式，用于量级估算）：

所需 GPU 数 ≈ (峰值 QPS × 平均输出 token 数) / (单卡 token 吞吐 × 目标利用率)

其中：
  单卡 token 吞吐 由模型大小、量化精度、批大小决定
  目标利用率 建议取 0.6–0.75（留出突发余量）

以 7B 模型、FP16、A10G 单卡为例，vLLM 在连续批处理下的输出吞吐量级在数百到一千 token/s（来源：vLLM 官方 benchmark 页面，2024；具体数值随输入输出长度比变化）。若峰值 QPS 为 100、平均输出 200 token，则所需 token 吞吐为 20000 token/s，对应约 20–40 张卡。这个数字会随输出长度分布剧烈变化，所以必须用真实流量画像而非平均值来估算。

6.2 压测方法：三步走

第一步，采集流量画像。从生产日志中提取输入长度、输出长度、QPS 时间分布的 P50/P90/P99。输出长度分布是长尾的主要来源，务必单独统计。

第二步，单机基准测试。用 vLLM 的 benchmark 工具或 Locust 对单卡/单节点做吞吐-延迟曲线，找到“延迟拐点”——即吞吐上升但 P99 开始陡增的临界点。这个拐点决定了安全水位。

第三步，全链路压测。用影子流量（shadow traffic）回放真实分布，观察端到端 P99、队列深度、GPU 利用率、Kafka lag 四个指标。重点看“拐点之后系统的行为”——是优雅降级还是雪崩。

笔者认为：压测中最容易被忽略的是“输出长度分布”。很多团队用固定 max_tokens 压测，得到漂亮的吞吐数字，上线后遇到真实的长尾输出立刻崩盘。正确的做法是按真实分布采样，并且专门构造 1% 的超长输出请求，观察系统是否会被拖垮。

七、工程细节：KV Cache 复用、动态批处理与背压治理

7.1 前缀缓存：被低估的延迟杀手

在流式场景中，大量请求共享相同的前缀（系统提示词、few-shot 示例、检索到的固定上下文）。前缀缓存（prefix caching）把这段前缀的 KV Cache 保留在显存中，后续请求直接复用，跳过 prefill 阶段。vLLM 的 Automatic Prefix Caching 与 SGLang 的 RadixAttention 都实现了这一机制（来源：SGLang 论文，Efficiently Programming Large Language Models using SGLang，2024）。

在流处理场景中，前缀缓存的命中率往往很高——因为同一个业务流的系统提示词是固定的。实测中，命中前缀缓存可以把首 token 延迟（TTFT）降低一个数量级（量级描述，具体倍数依赖前缀长度与硬件）。这要求 L2 检索层在组装 prompt 时把稳定内容放在前面、动态内容放在后面，这是一个简单但收益巨大的工程约定。

7.2 动态批处理的参数调优

推理网关的动态批处理有几个关键参数：最大批大小（max batch size）、最大等待时间（max queue delay）、最大 token 数（max num tokens）。三者的权衡是：批越大吞吐越高但延迟越大；等待时间越长批越容易凑满但延迟增加。建议按优先级分池配置——高优池用小批+短等待，低优池用大批+长等待。

7.3 背压治理：从“被动阻塞”到“主动丢弃”

解耦之后，背压不再跨层传导，但队列会无限增长。治理策略是主动丢弃 + 降级：当队列深度超过阈值，低优先级请求直接走规则兜底（返回模板文案），并记录丢弃指标。这比让整个管道卡死要好得多。业界常用的做法参考了 SRE 的“负载丢弃”（load shedding）原则（来源：Google SRE Book，2016）。

八、成本、可观测性与常见踩坑清单

8.1 成本结构

推理成本主要由 GPU 时长决定，而 GPU 利用率由批大小与缓存命中率决定。一个常被忽略的事实是：在低利用率下，独立推理服务可能比直接调用云 API 更贵。因此选型时要算清楚“自建 vs API”的盈亏平衡点。粗略估算（模拟测算）：当 QPS 低于某个阈值（取决于模型大小与 API 单价），API 更划算；超过阈值后自建的边际成本优势显现。

8.2 可观测性四件套

必须监控的指标：队列深度（按优先级）、TTFT 与 TPOT（每 token 输出时间）、GPU 利用率与显存占用、缓存命中率。这四个指标能覆盖 90% 的线上问题定位。OpenTelemetry 的 trace 透传（trace_id 贯穿 L0–L4）是排查长尾请求的关键。

8.3 踩坑清单

• 坑 1：在 Spark 的 foreachBatch 里同步调用推理，且没有超时控制——单条慢请求拖垮整批。
• 坑 2：推理结果直接写回主 topic，导致下游消费者被大量结果消息淹没。
• 坑 3：prompt 拼接时把动态内容放在前面，前缀缓存命中率接近 0。
• 坑 4：没有 deadline 字段，超时请求在网关里堆积，最终 OOM。
• 坑 5：用固定 max_tokens 压测，上线后被长尾输出打崩。
• 坑 6：忽略 checkpoint 与推理的耦合，微批积压导致 checkpoint 超时、作业重启。

九、前沿预判：流原生推理与推理下沉

往前看两三年，有两个方向值得关注。

方向一：流原生推理。Flink 社区在 ML 算子方向持续投入，Spark 也在推进 GPU 调度与 Pandas UDF 的推理支持。如果流引擎能把“异步推理 + 连续批处理”做进运行时，那么方案 B 与方案 C 的界限会模糊。但目前生态仍不成熟，短期内不建议作为主力方案。

方向二：推理下沉到存储/检索层。随着向量数据库内置 rerank、摘要等轻量推理能力，一部分原本要送 LLM 的请求可以在检索层就地解决。这与 STS 框架的 L2 层演进方向一致——把“能不下发到 L3 的请求”尽量拦在 L2。

本文评述：这两个方向的共同逻辑是“把计算推到离数据更近的地方”，与边缘计算、存算一体的思路一脉相承。但要注意，推理下沉的前提是模型足够小、任务足够确定；对于开放式生成任务，集中式推理集群在成本与调度效率上仍有优势。分层不是消灭，而是各归其位。

十、结论与可执行路线图

回到最初的问题：Kafka+Spark 的方案延迟和吞吐扛不住，有没有更合适的架构选型思路？答案是：有，但关键不在“换组件”，而在“换调度范式”。把推理从流算子中解耦出来，用语义分层调度把快慢通道分开，再用连续批处理与缓存把推理层效率拉满，这是当前工程条件下最稳妥的路径。

给出一条可执行的路线图：

1. 第 1 周：采集流量画像，统计输入/输出长度分布与 QPS 曲线，明确 SLA。
2. 第 2–3 周：单机基准测试，找到延迟拐点，确定安全水位与 GPU 数量。
3. 第 4–6 周：搭建 L3 独立推理服务（vLLM/TensorRT-LLM），实现优先级队列与 deadline 熔断。
4. 第 7–8 周：改造 L1 输出为异步投递，L4 实现迟到结果处理与降级。
5. 第 9–10 周：全链路影子压测，验证拐点行为与降级策略。
6. 第 11 周起：灰度切流，监控四件套指标，逐步放量。

最后提醒一句：架构选型没有银弹，只有权衡。STS 框架的价值不在于给出唯一答案，而在于把“流 + AI”这个模糊命题拆成可判定、可度量、可演进的决策序列。先把分层想清楚，再谈组件。

延伸阅读与教程链接

• Apache Spark Structured Streaming 官方编程指南：spark.apache.org/docs/latest/structured-streaming-programming-guide.html
• Apache Flink Async I/O 文档：nightlies.apache.org/flink/flink-docs-stable/docs/dev/datastream/operators/asyncio/
• vLLM 官方文档与 benchmark：docs.vllm.ai
• NVIDIA Triton Inference Server 文档：docs.nvidia.com/deeplearning/triton-inference-server/
• Ray Serve 文档：docs.ray.io/en/latest/serve/index.html
• SGLang 项目与 RadixAttention 介绍：github.com/sgl-project/sglang

主要参考文献

说明：本文涉及的吞吐、延迟、GPU 数量等数值，除标注来源者外，均为基于公开文献与工程经验的整合性估算或模拟测算，用于说明量级与趋势，不代表任何特定系统的实测结果。涉及数据集的部分，本文未使用专有数据集；引用的基准测试数据均来自对应文献的公开描述，未做额外预处理。