Flink 能调用大模型吗？流式数据做实时 AI 推理怎么设计？
面试怎么回答
能调用，本质是调一个慢、贵、有限流、会失败的外部服务。设计上用 Async I/O 异步并发调用并控制容量和超时，新版本 Flink 在 SQL 层也开始提供模型推理函数，但底层同样要考虑这些问题。先用规则或小模型过滤只把需要的数据送大模型，能批量的合并成一次请求，重复输入走缓存。调用侧令牌桶限流，高峰允许延迟增加而不是疯狂重试。失败的有限重试，最终失败和格式不合格的进侧输出流事后补处理，模型不可用时降级到规则或小模型并打标。每条结果记录模型和提示词版本。毫秒级场景、数据量极大单条价值低或者小时级时效的需求，不适合在流里调大模型。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
实时场景越来越多地需要大模型：实时给用户评论做情感分类、实时识别工单的问题类型并分派、实时判断内容是否违规。这些都需要在流处理链路里调用模型。面试官问这题，想看你能不能把一个慢、贵、有限流的外部服务，稳妥地接进高吞吐的流处理作业。
能调用，但难点在哪
在 Flink 里调用大模型，本质上是调用一个外部服务，和维表 Join 调用外部接口类似，但更难：
- 延迟高：一次调用几百毫秒到几秒，同步调用会让吞吐降到很低，产生严重反压；
- 限流：有每分钟请求数和 Token 数的上限；
- 成本：每条数据都调用，费用和数据量成正比；
- 不确定性：会失败、会超时、输出格式可能不符合预期。
设计要点
1. 异步调用
用 Flink 的 Async I/O，同时发起多个请求，不阻塞处理线程。控制最大并发数（capacity），配合超时设置。新版本的 Flink 也开始在 SQL 层面提供模型定义和推理函数（如 ML_PREDICT），具体能力以所用版本的文档为准，底层同样需要考虑异步、限流和超时。
2. 批量和过滤
- 不是每条数据都需要大模型：先用规则或小模型过滤，比如只有长度足够、包含关键词的评论才送去分析；
- 能批量的合并成一次请求（多条短文本一起分类），减少调用次数。
3. 缓存
相同或高度相似的输入（重复的工单模板、热门的商品评论）缓存结果，避免重复调用。
4. 限流和背压
- 在调用侧做令牌桶限流，平滑请求；
- 流量高峰时允许延迟增加，而不是疯狂重试导致被限流更严重。
5. 失败处理
- 超时和可恢复错误：有限次数的重试；
- 最终失败的数据：输出到侧输出流（死信队列），不阻塞主流程，事后补处理；
- 输出格式校验，不合格的走同样的失败处理。
6. 降级
模型服务不可用时，切换到规则或小模型给出一个基础结果，并打上标记，事后用大模型补处理。
7. 结果的可追溯
每条结果记录模型版本、提示词版本和调用时间。
什么时候不该在流里调大模型
- 对延迟要求极高（毫秒级）的场景：用小模型或规则；
- 数据量极大而单条价值低：先离线批量处理验证价值；
- 对时效要求其实是小时级的：用离线批量推理更便宜。