Flink Forward Asia 2026 大会深度笔记与开发者思考

jingling5552026-06-27 8:12

1. 大会总览

1.1 这场大会在讲什么？

Flink Forward Asia 2026 传递了一个非常明确的信号：

Apache Flink 正在从「实时数仓 / ETL 引擎」，演进为「AI 时代的多模态流式编排平台」。

过去 Flink 的主战场是：

  • 结构化日志、指标、交易流水
  • SQL 聚合、窗口、Join
  • 毫秒～秒级延迟的实时计算

现在要进入的新战场是：

  • 视频、音频、图像 等多模态数据流
  • CPU 预处理 + GPU 推理 的混合 Pipeline
  • VLM / LLM / TTS 等大模型服务的实时编排
  • Agentic 场景下的感知、认知、记忆

1.2 三位讲者的分工

讲者 身份 核心贡献
王峰 阿里云智能集团研究员、开源大数据平台负责人 Flink 战略演进、三层能力升级、Pipeline 架构、阿里云落地案例
陈川 NVIDIA 互联网解决方案架构高级总监 CUDA 加速栈、Flink×GPU 工程框架、本地/远程推理优化
李博杰 AI 独立研究者 Agent 理论框架：「一个 Agent = 一个 Flink 作业」

三者形成完整叙事链：

复制代码 
基础设施演进（王峰）→ 硬件加速落地（陈川）→ Agent 抽象模型（李博杰）

2.1 三层演进路线图

Flink 的 AI 化不是单点功能，而是 API 层、算子层、算力层 的系统升级：

层级 从 → 到 目标用户 关联 FLIP
API 层 SQL → DataFrame 数据工程师 → 算法工程师 FLIP-591：PyFlink 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 推理时，批次 N+1 可能在 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
  • 模型服务：阿里云百炼 / PAI（Qwen VLM、LLM、TTS）
  • 硬件加速：NVIDIA GPU

4.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 API，Async I/O

4.4 数据流（端到端）

  1. 直播视频进入 → FFmpeg 硬解码
  2. GPU 抽帧、压缩 → 图像送 VLM
  3. VLM 理解 + 弹幕 → LLM 生成解说词
  4. 本地 LLM 风格改写 → TTS 生成音频
  5. 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、nvJPEG
  • TensorRT-LLM 加速本地小模型
  • 适合：延迟敏感、高吞吐、重复计算

GPU Remote Optimized（远程）

  • VLM / LLM / TTS 远端推理服务
  • 适合：大模型、弹性扩缩、成本优化
Flink 特性 在 AI 解说中的作用
Source Connector 接 HLS 直播流
UDF GPU 抽帧、自定义处理
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 四大支柱

  1. 统一多模态实时编排 --- 视频切片、关键帧、解说文本、TTS 音频、业务事件进同一 Pipeline
  2. 解决时间对齐与状态压力 --- Event Time + segment_id + 有状态计算
  3. 加速关键路径 --- GPU 编解码、图像处理、推理加速
  4. 沉淀可复用社区能力 --- Connector、Operator、UDF、Runtime 优化路径

6.3 演进方向

复制代码 
实时数据处理  ──→  实时理解与内容生成
(ETL/风控/指标)      (解说/资讯/问答/Agent)

7. 李博杰：AI Agent 的「两朵云」

7.1 「两朵云」是什么？

不是云厂商，而是挡在 真正 AI Agent 前面的两大难题：

云朵 含义 核心矛盾
第一朵云：流式与环境交互 像人一样实时看、听、操作、对话 既要几百毫秒响应，又要深度思考
第二朵云：自主从经验中学习 越用越聪明，但不反复训练模型 经验怎么存、怎么取、怎么更新

7.2 与现有 AI 的差距

我们已经习惯：

  • 会写代码、做研究的 AI（Deep Research、Coding Agent）
  • 「你等我一下」的回合制交互

我们很少见到：

  • 像打电话一样 边说边听边打断 的 AI
  • 看着屏幕实时操作 的 AI
  • 记住你的偏好、越用越顺手 的 AI

8.1 核心映射

Agent 环节 Flink 概念 本报告方案
感知（世界→模型） Source + Event Time + 序列化 AOI 观测接口、Sema 语义传输
认知（实时+深思考） 批流一体 Interactive ReAct、Latent Bridge
记忆（经验存储复用） 有状态流处理 + Checkpoint UserAsCode、Engram、PreAct

8.2 PART 1 · 感知

现状问题
问题 表现 数据
定时截屏 每 3～5 秒看一眼，中间变化全丢 VideoWebArena：AI 13.3% vs 人类 73.9%
无音频 会议、提示音、告警听不到 音频任务几乎全部失败
解法：AOI + Sema
  • AOI（观测接口） ：事件触发，不是定时轮询
    • 屏幕无变化 → 零开销
    • 有语义变化 → 才抽关键帧
    • 有声音 → 才做语音理解
  • Sema（语义传输）：高效序列化，只传有意义的信息
关键发现

用一句话描述当前屏幕，写入上下文 --- 单项带来约 +18pp 提升。

本质：把「转瞬即逝的画面」变成「持久文本」= 短期记忆。

效果
  • 动态任务 +17～48pp（相对纯截图）
  • Claude 成功率 82%，静态任务不下降
  • 音频任务 12/12 全部完成

8.3 PART 2 · 认知

核心矛盾：实时 ⊥ 智能
路径 延迟 智能 代表
实时但浅 ~200ms 弱 端到端语音模型
强但不实时 300～500ms+ 强 SOTA LLM + Observe-Think-Act
解法：快慢分离 = 批流一体
路径 Flink 类比 职责
前端 / 流 Stream Processing 小模型、~200ms、维持对话节奏、编排分流
后端 / 批 Batch Processing SOTA 大模型、深度规划、后台异步执行

打游戏类比：只有快 → 会躲不会赢；只有慢 → 会规划但第一下就被打；需要两者兼备。

Interactive ReAct：边听边想

利用 人声速度（5～10 token/s）≪ LLM 速度（~200 token/s） 的空隙：

  • 用户还在说 → AI 已在推理、调工具
  • 用户说完 → 答案往往已备好（<0.5s 响应）

技术本质：观测是 事件流 ，动作是 交错 token 输出 ，工具调用是 Async I/O。

Latent Bridge：快慢模型通信

吃豆人实验对比三种信道：

信道 方式 得分
F（仅快） 快模型独立决策 最低
T（文本） 慢模型写字指令 中等（408）
L（Latent） 慢模型传潜向量 最高（628）

结论：文本压缩丢信息，隐空间直连 是更好的快慢桥梁。

8.4 PART 3 · 记忆

核心类比

记忆 = Flink 有状态流处理（State Backend + Checkpoint）

两类记忆
类型 回答什么 例子
声明式 用户是谁？事实是什么？ 护照过期日、偏好设置
过程性 怎么做？ 订国际机票的完整操作流程
三种实现
方案 类型 机制 类比
UserAsCode 声明式 结构化事实 + 可执行约束 数据库 + 规则引擎
User as Engram 声明式 写入模型参数稀疏槽位 背下来的知识
PreAct 过程性 成功轨迹 → 状态机缓存 老司机熟路
UserAsCode 进阶：为什么 bag-of-facts 不够？

向量检索擅长 召回事实，但不擅长：

  • 跨多条记录做计算（如统计国际旅行次数）
  • 约束校验（如护照有效期 < 6 个月则告警）
  • 主动预先算出风险
python 复制代码 
# UserAsCode 示例：确定性约束执行
for trip in user.trips:
    if trip.international:
        days_left = passport.expiry_date - trip.departure_date
        if days_left < 180:
            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 响应延迟、任务成功率
维度 传统 Flink AI 多模态 Flink
数据类型 Row/JSON/Avro 视频帧、音频 chunk、Embedding
算子 Map/Filter/Aggregate GPU UDF、Async Model Call
状态大小 KB～MB 级 可能 GB 级（帧缓存、Memory）
延迟要求 秒级可接受 百毫秒～秒级，音画同步
外部依赖 DB/Cache VLM/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 纯文本对话（无多模态）
工业质检（流式） 简单规则 ETL

11. 个人思考与判断

合理，但有边界。

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 未来 1～2 年展望

  1. FLIP-591/592/593 逐步落地，PyFlink DataFrame + GPU 算子进入生产
  2. Flink + NVIDIA 加速库成为多模态流处理的标准组合
  3. Agentic Operator 成为 Flink 新算子类别，内置 VLM/LLM 调用模板
  4. 记忆方案（UserAsCode/PreAct）仍在探索期，工程化程度有限
  5. 竞争：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 走向规模化的关键窗口期。

热门推荐
012026年6月AI大模型全景报告：GPT-5.6、Claude Opus 4.8、Gemini 3.5，中美AI三足鼎立谁主沉浮？022026年6月AI行业全景：从百模大战到Agent元年，这30天发生了什么？032026 年 AI 编程工具终极横评：Cursor vs Claude Code vs Copilot vs Windsurf04飞书长连接_事件订阅（接收消息，审批任务状态变更）05Trae国际版与国内版深度测评：AI原生IDE的双生花06GitHub 镜像站点07【AI】2026 年具身智能模型和世界模型总结082026年AI架构实战：彻底解决OpenAI接口超时与封号，Python调用GPT-5.2/Sora2企业级架构详解（附源码+压测报告）09Claude Code、Codex、Cursor三分天下：2026年AI编程Agent生态全景剖析102026 AI 编程工具终极实战指南：Cursor vs Claude Code vs Copilot，开发者该怎么选？