1. 大会总览1.1 这场大会在讲什么Flink Forward Asia 2026 传递了一个非常明确的信号Apache Flink 正在从「实时数仓 / ETL 引擎」演进为「AI 时代的多模态流式编排平台」。过去 Flink 的主战场是结构化日志、指标、交易流水SQL 聚合、窗口、Join毫秒秒级延迟的实时计算现在要进入的新战场是视频、音频、图像等多模态数据流CPU 预处理 GPU 推理的混合 PipelineVLM / LLM / TTS等大模型服务的实时编排Agentic场景下的感知、认知、记忆1.2 三位讲者的分工讲者身份核心贡献王峰阿里云智能集团研究员、开源大数据平台负责人Flink 战略演进、三层能力升级、Pipeline 架构、阿里云落地案例陈川NVIDIA 互联网解决方案架构高级总监CUDA 加速栈、Flink×GPU 工程框架、本地/远程推理优化李博杰AI 独立研究者Agent 理论框架「一个 Agent 一个 Flink 作业」三者形成完整叙事链基础设施演进王峰→ 硬件加速落地陈川→ Agent 抽象模型李博杰2. 王峰Flink 向多模态与 AI 演进2.1 三层演进路线图Flink 的 AI 化不是单点功能而是API 层、算子层、算力层的系统升级层级从 → 到目标用户关联 FLIPAPI 层SQL → DataFrame数据工程师 → 算法工程师FLIP-591PyFlink DataFrame API算子层结构化文本分析 → 多模态算子文本 ETL → 语音/图像/视频处理FLIP-593内置多模态算子算力层CPU → GPU通用计算 → AI 加速计算FLIP-592加速器资源支持开发者解读如果你现在是 Flink SQL 开发者未来需要关注PyFlink DataFrame这是算法同学进入 Flink 生态的入口。多模态算子意味着不必每个团队自己写 FFmpeg 胶水代码而是标准化 GPU 算子进入 Flink 生态。GPU 调度从「外挂脚本」变成Flink 资源管理的一部分影响 TaskManager 部署、资源隔离、弹性扩缩容设计。2.2 关键判断在多模态场景下Flink 有很好的潜力和机会。原因不是 Flink 会训练模型而是 Flink 擅长连续数据流的编排事件时间语义有状态计算与容错背压与流量控制这些恰恰是 AI 实时应用解说、监控、质检、数字人的刚需。3. Pipeline 执行架构3.1 架构图CPU → Network → GPU → Network → CPU → Network → GPU → Network → CPU这不是简单的「先 CPU 后 GPU」而是多级流水线并行批次 N 在 GPU 推理时批次 N1 可能在 CPU 预处理批次 N-1 在写输出全链路保持流动避免 GPU 空转3.2 三大优势优势技术含义业务价值全链路 Pipeline 并行多阶段 overlap 执行提高 GPU 利用率降低端到端延迟网络直传数据跨节点直传减少落盘 I/O避免 GPU 被慢 I/O 拖累秒级 Checkpoint快速状态快照与恢复故障后少浪费昂贵 GPU 算力3.3 开发者要点传统 AI 推理架构常见模式Kafka → 批处理服务 → 对象存储 → 另一个推理服务 → 再写回Pipeline 架构追求的是Source → [CPU UDF] → [GPU UDF] → [Async Model API] → [GPU Mux] → Sink └──────────── 同一 Flink Job 内流水线化 ────────────┘关键转变从「多个独立服务拼起来的数据管道」到「一个 Flink Job 统一编排的 Pipeline」。4. 体育赛事 AI 解说案例4.1 技术栈流编排阿里云 Flink模型服务阿里云百炼 / PAIQwen VLM、LLM、TTS硬件加速NVIDIA GPU4.2 五层架构┌─────────────────────────────────────────────────────────┐ │ 多模态数据层输入视频流 | 用户弹幕 | 输出视频流 │ ├─────────────────────────────────────────────────────────┤ │ 多模态接入层HLS/RTMP Source Sink (FFmpeg NV Codec) │ ├─────────────────────────────────────────────────────────┤ │ 多模态算子层抽帧 | 图像压缩 | 音视频合并 (GPU) │ ├─────────────────────────────────────────────────────────┤ │ Agentic 算子层视觉理解 | 解说合成 | 风格改写 | TTS │ ├─────────────────────────────────────────────────────────┤ │ 模型服务Qwen VLM | Qwen LLM | Qwen TTS (百炼/PAI) │ └─────────────────────────────────────────────────────────┘4.3 算子颜色编码部署规划参考颜色类型典型任务部署建议 绿色Flink GPU 算子抽帧、压缩、混流GPU TaskManager 蓝色Flink CPU 算子路由、编排、逻辑CPU TaskManager 黄色本地模型风格改写等小模型本地 GPU TensorRT-LLM 红色远程大模型VLM/LLM/TTS百炼/PAI APIAsync I/O4.4 数据流端到端直播视频进入 → FFmpeg 硬解码GPU 抽帧、压缩 → 图像送 VLMVLM 理解 弹幕 → LLM 生成解说词本地 LLM 风格改写 → TTS 生成音频GPU 音视频合并 → HLS 推流输出4.5 开发者启示这个案例不是 Demo 级别的「调 API」而是暴露了真实生产系统的核心难点多路流对齐视频段、理解结果、文本、音频异构算力调度CPU/GPU/云端 API延迟与成本平衡什么放本地、什么调云端5. 陈川NVIDIA CUDA 加速框架5.1 框架全景HLS Source (mediastream) │ ▼ 视频切片 (Event Time) │ ▼ Extract UDF (GPU Optimized) ├── NVDEC (硬解码) ├── Sample (抽帧) ├── CV-CUDA (缩放/预处理) └── nvJPEG (压缩) │ ▼ Flink Agentic Operator (动态调度) ├── VLM → 事件 ├── LLM → 解说稿 ( 风格/长度/合规护栏) ├── Memory 管理 ├── TTS → 音频 └── 用户输入 (弹幕/互动) │ ▼ Mux/Remux (NV Codec) → HLS Sink (新直播流)5.2 分工原则组件职责Flink流式编排、时间语义、状态管理、Join、背压、容错NVIDIA媒体处理热点 推理热点的低延迟加速5.3 两类 GPU 优化GPU Local Optimized本地GPU FFmpeg、NVDEC/NVENC、CV-CUDA、nvJPEGTensorRT-LLM 加速本地小模型适合延迟敏感、高吞吐、重复计算GPU Remote Optimized远程VLM / LLM / TTS 远端推理服务适合大模型、弹性扩缩、成本优化5.4 Flink 流式主干能力清单Flink 特性在 AI 解说中的作用Source Connector接 HLS 直播流UDFGPU 抽帧、自定义处理Keyed State按比赛/频道/segment 存状态Event-Time Window按比赛时间切片Async I/O调 VLM/LLM/TTS 不阻塞流水线Backpressure推理慢时自动减速上游segment_id对齐视频、理解、文本、音频5.5 开发者要点segment_id 是多模态实时系统的「主轴」没有它会出现画面进球了解说慢三秒TTS 音频和当前画面不匹配重试/乱序后结果张冠李戴这是 Flink 相比「脚本 消息队列」的核心优势原生的事件时间与有状态 Join。6. NVIDIA × 阿里云协作总结6.1 一句话Flink 让多模态流可编排、可对齐、可恢复NVIDIA 让处理与推理热点低延迟、高吞吐、可扩展。6.2 四大支柱统一多模态实时编排— 视频切片、关键帧、解说文本、TTS 音频、业务事件进同一 Pipeline解决时间对齐与状态压力— Event Time segment_id 有状态计算加速关键路径— GPU 编解码、图像处理、推理加速沉淀可复用社区能力— Connector、Operator、UDF、Runtime 优化路径6.3 演进方向实时数据处理 ──→ 实时理解与内容生成 (ETL/风控/指标) (解说/资讯/问答/Agent)7. 李博杰AI Agent 的「两朵云」7.1 「两朵云」是什么不是云厂商而是挡在真正 AI Agent前面的两大难题云朵含义核心矛盾第一朵云流式与环境交互像人一样实时看、听、操作、对话既要几百毫秒响应又要深度思考第二朵云自主从经验中学习越用越聪明但不反复训练模型经验怎么存、怎么取、怎么更新7.2 与现有 AI 的差距我们已经习惯会写代码、做研究的 AIDeep Research、Coding Agent「你等我一下」的回合制交互我们很少见到像打电话一样边说边听边打断的 AI看着屏幕实时操作的 AI记住你的偏好、越用越顺手的 AI8. 一个 Agent就是一个 Flink 作业8.1 核心映射Agent 环节Flink 概念本报告方案感知世界→模型Source Event Time 序列化AOI 观测接口、Sema 语义传输认知实时深思考批流一体Interactive ReAct、Latent Bridge记忆经验存储复用有状态流处理 CheckpointUserAsCode、Engram、PreAct8.2 PART 1 · 感知现状问题问题表现数据定时截屏每 35 秒看一眼中间变化全丢VideoWebArenaAI 13.3% vs 人类 73.9%无音频会议、提示音、告警听不到音频任务几乎全部失败解法AOI SemaAOI观测接口事件触发不是定时轮询屏幕无变化 → 零开销有语义变化 → 才抽关键帧有声音 → 才做语音理解Sema语义传输高效序列化只传有意义的信息关键发现用一句话描述当前屏幕写入上下文 — 单项带来约18pp提升。本质把「转瞬即逝的画面」变成「持久文本」短期记忆。效果动态任务 1748pp相对纯截图Claude 成功率 82%静态任务不下降音频任务 12/12 全部完成8.3 PART 2 · 认知核心矛盾实时 ⊥ 智能路径延迟智能代表实时但浅~200ms弱端到端语音模型强但不实时300500ms强SOTA LLM Observe-Think-Act解法快慢分离 批流一体路径Flink 类比职责前端 / 流Stream Processing小模型、~200ms、维持对话节奏、编排分流后端 / 批Batch ProcessingSOTA 大模型、深度规划、后台异步执行打游戏类比只有快 → 会躲不会赢只有慢 → 会规划但第一下就被打需要两者兼备。Interactive ReAct边听边想利用人声速度510 token/s≪ LLM 速度~200 token/s的空隙用户还在说 → AI 已在推理、调工具用户说完 → 答案往往已备好0.5s 响应技术本质观测是事件流动作是交错 token 输出工具调用是Async I/O。Latent Bridge快慢模型通信吃豆人实验对比三种信道信道方式得分F仅快快模型独立决策最低T文本慢模型写字指令中等408LLatent慢模型传潜向量最高628结论文本压缩丢信息隐空间直连是更好的快慢桥梁。8.4 PART 3 · 记忆核心类比记忆 Flink 有状态流处理State Backend Checkpoint两类记忆类型回答什么例子声明式用户是谁事实是什么护照过期日、偏好设置过程性怎么做订国际机票的完整操作流程三种实现方案类型机制类比UserAsCode声明式结构化事实 可执行约束数据库 规则引擎User as Engram声明式写入模型参数稀疏槽位背下来的知识PreAct过程性成功轨迹 → 状态机缓存老司机熟路UserAsCode 进阶为什么 bag-of-facts 不够向量检索擅长召回事实但不擅长跨多条记录做计算如统计国际旅行次数约束校验如护照有效期 6 个月则告警主动预先算出风险# UserAsCode 示例确定性约束执行fortripinuser.trips:iftrip.international:days_leftpassport.expiry_date-trip.departure_dateifdays_left180:alerts.append({severity:critical,message:f护照{passport.number}有效期不足...})Flink/DB 类比append-only log periodic checkpoint changelog checkpoint。9. 开发者视角技术栈与架构映射9.1 完整技术栈┌──────────────────────────────────────────────────────────────┐ │ 应用层 │ │ AI 解说 | 视频监控 | 实时质检 | 数字人 | Computer Use Agent │ ├──────────────────────────────────────────────────────────────┤ │ Agent 抽象层 (李博杰) │ │ 感知(AOI/Sema) | 认知(快慢分离/ReAct/Latent) | 记忆(三方案) │ ├──────────────────────────────────────────────────────────────┤ │ Flink 编排层 (王峰) │ │ DataFrame API | 多模态算子 | GPU 资源调度 | Pipeline │ │ Event Time | State | Async I/O | Checkpoint | Backpressure│ ├──────────────────────────────────────────────────────────────┤ │ 加速层 (陈川/NVIDIA) │ │ NVDEC/NVENC | CV-CUDA | nvJPEG | TensorRT-LLM │ ├──────────────────────────────────────────────────────────────┤ │ 模型服务层 │ │ 百炼/PAI (Qwen VLM/LLM/TTS) | 本地小模型 | 自建推理集群 │ ├──────────────────────────────────────────────────────────────┤ │ 基础设施层 │ │ K8s | GPU 节点 | 网络 | 对象存储 | CDN/HLS │ └──────────────────────────────────────────────────────────────┘9.2 模块清单模块技术选型参考关键指标视频接入FFmpeg NVDEC, HLS/RTMP Source解码延迟、协议兼容帧处理CV-CUDA, nvJPEG, GPU UDF抽帧率、压缩比、吞吐视觉理解Qwen-VL / GPT-4V, Async I/O准确率、P99 延迟文本生成Qwen-Max / Claude, 护栏幻觉率、合规语音合成Qwen-TTS / CosyVoice首包延迟、自然度混流输出NVENC, Mux/Remux音画同步误差状态管理Flink Keyed State, segment_id对齐准确率记忆UserAsCode / RAG / Engram召回率、约束执行正确率快慢认知小模型 SOTA Latent Bridge响应延迟、任务成功率9.3 与传统 Flink 开发的差异维度传统 FlinkAI 多模态 Flink数据类型Row/JSON/Avro视频帧、音频 chunk、Embedding算子Map/Filter/AggregateGPU UDF、Async Model Call状态大小KBMB 级可能 GB 级帧缓存、Memory延迟要求秒级可接受百毫秒秒级音画同步外部依赖DB/CacheVLM/LLM/TTS API容错Checkpoint 恢复 模型调用幂等、segment 对齐资源CPU 内存CPU GPU 网络带宽10. 落地挑战与工程建议10.1 核心挑战挑战描述可能方案多模态对齐视频、文本、音频时间轴一致segment_id Event Time Watermark延迟抖动模型 API 延迟不稳定Async I/O 背压 快慢分离GPU 利用率推理间隙 GPU 空转Pipeline 并行 批处理叠加成本控制大模型 API 按 token 计费本地小模型 远程大模型分层幻觉与合规AI 生成内容不可控LLM 护栏 长度检查 人工审核兜底状态膨胀Memory/上下文持续增长分层记忆 TTL 压缩故障恢复GPU 节点宕机Checkpoint 模型调用幂等设计10.2 架构建议1. 先对齐再优化第一优先级不是 GPU 加速而是segment_id 对齐机制。没有对齐加速越快乱得越快。2. 快慢分离是标配任何需要「实时交互 深度推理」的场景都应考虑前端小模型或规则做即时响应后端大模型做异步深思考Latent Bridge 或结构化消息做快慢通信3. 记忆要结构化不要把所有经验塞进 prompt事实 → UserAsCode / RAG技能 → PreAct 轨迹缓存内化知识 → Engram若技术成熟4. 可观测性多模态 Pipeline 的 Debug 难度远高于 SQL Job需要每个 segment 的全链路 trace各阶段延迟分布解码/抽帧/VLM/LLM/TTS/混流GPU 利用率与显存监控模型调用的 token 消耗与错误率10.3 适用场景适合 ✅不适合 ❌实时 AI 解说/配音离线批量视频分析直播监控 实时告警训练数据预处理数字人实时互动对延迟不敏感的报表Computer Use Agent纯文本对话无多模态工业质检流式简单规则 ETL11. 个人思考与判断11.1 Flink 做 AI 编排是否合理合理但有边界。Flink 的优势在于成熟的事件时间、状态、容错语义统一的流式编程模型社区生态与运维工具链Flink 不擅长模型训练与微调极低延迟50ms的端到端语音复杂的 Agent 规划逻辑更适合上层框架判断Flink 定位为AI 应用的「数据面」编排引擎而非AI 应用的「控制面」Agent 框架。李博杰的「一个 Agent 一个 Flink 作业」是概念映射实际落地可能是 Flink Agent Framework如 LangGraph的组合。11.2 与现有方案对比方案优势劣势Flink 多模态 Pipeline对齐/状态/容错原生支持学习曲线、GPU 生态尚在建设Kafka 微服务灵活、团队熟悉对齐/状态需自建运维复杂Ray Serve / Triton推理优化成熟流式语义弱需额外编排纯 FFmpeg Python简单快速难以扩展、无容错、对齐困难11.3 未来 12 年展望FLIP-591/592/593逐步落地PyFlink DataFrame GPU 算子进入生产Flink NVIDIA加速库成为多模态流处理的标准组合Agentic Operator成为 Flink 新算子类别内置 VLM/LLM 调用模板记忆方案UserAsCode/PreAct仍在探索期工程化程度有限竞争Kafka Streams、Spark Structured Streaming、自研框架会跟进多模态能力11.4 给开发者的行动建议阶段建议现在关注 FLIP 进展试用 PyFlink DataFrame API短期用 Flink Async I/O 远程模型 API 搭建 POC验证对齐机制中期评估 GPU TaskManager 部署集成 NVDEC/CV-CUDA长期参与社区多模态算子建设沉淀领域 Connector/UDF结语Flink Forward Asia 2026 释放的核心信号是流式处理引擎正在成为 AI 实时应用的基础设施就像当年 Spark 成为批处理基础设施一样。对开发者而言这意味着如果你做实时 AI 应用值得把 Flink 纳入技术选型如果你已是 Flink 开发者多模态 GPU Agent 是下一阶段的必修项如果你做 AI Agent感知/认知/记忆的设计可以借鉴 Flink 的 Source/批流一体/State 抽象大会展示的不是遥远的愿景而是已经在阿里云落地的体育解说案例和NVIDIA 的 CUDA 加速框架。接下来一到两年将是这套架构从 Demo 走向规模化的关键窗口期。