IBM与Confluent将时间序列基础模型带入实时数据流：预测与异常检测进入Flink

IBM与Confluent在Confluent Cloud上推出Early Access，将IBM Granite时间序列基础模型嵌入Apache Flink数据流，实现实时预测与异常检测，支持制造与金融等行业的在线决策和自动化触发。该方案通过Flink SQL函数调用多种模型，数据留在Confluent Cloud并纳入统一治理，但企业仍需验证误报率和实际效果。

IBM与Confluent宣布，IBM Granite时间序列模型已在Confluent Cloud上开启Early Access。企业可以直接在Apache Flink数据流中调用这些模型，用于预测、异常检测以及一系列相关的时间序列任务，而不必先把数据转移到独立的机器学习平台。

这一合作的重点不只是增加了几个可选模型，而是试图改变时间序列机器学习在企业中的部署方式：模型不再等待数据进入数据仓库后批量运行，而是在业务事件、传感器读数或支付活动发生时，直接在数据流经过的地方处理。

从离线预测到“事件发生时”作出判断

IBM Research在Hugging Face发布的原始文章称，相关能力目前首先面向Confluent Cloud，并运行在AWS环境中；Confluent Platform的本地部署和混合云支持将在后续推出。Early Access阶段不收取费用，企业可以在自己的数据流上测试，并向IBM和Confluent团队反馈结果。

传统的时间序列项目往往需要针对每条重要序列单独建模、调参和维护。由于成本较高，企业通常只覆盖少量最有价值的商品、设备或业务指标，其余对象则依靠安全库存、额外产能或较宽的告警阈值来应对不确定性。

时间序列基础模型的思路有所不同。模型先在大量不同来源的信号上训练，再将学到的模式迁移到此前没有见过的序列上。使用者可以提供一段测量历史，让模型判断接下来可能发生什么、当前行为偏离正常状态的程度，以及过去是否存在相似情况。

IBM表示，相关模型已经先在自身产品和运营中测试，随后与水泥、钢铁、纸浆和造纸、食品、电信等行业的设计合作伙伴共同验证。公司给出的材料称，生产效率提升可达5至10倍；但这些数字属于IBM在项目材料中的披露，公开信息尚未提供足够的独立审计数据来判断其在不同企业环境中的普遍效果。

四种模型通过同一组Flink函数调用

Confluent在其第三季度产品更新文章中介绍，IBM Granite时间序列模型可以通过现有的AI_FORECAST和AI_DETECT_ANOMALIES Flink SQL函数调用。使用者只需改变SQL参数中的模型名称，就可以在不重建数据管道的情况下切换模型。

此次Early Access涉及四个互补的模型：

• PatchTST-FM：适合点预测和概率预测，将时间序列分成片段处理，并可以返回完整的预测分布，而不只是单一数值。
• FlowState：采用状态空间架构，能够处理不同采样频率的数据，适用于从秒级工业控制数据到小时级市场数据等不同时间尺度。
• TTM，即TinyTimeMixer：强调速度和效率，支持多变量预测、控制变量以及仅使用CPU的高吞吐场景。
• TSPulse：面向异常检测、分类、缺失值填补和相似性搜索等非预测任务。

Confluent负责管理模型服务、基础设施扩展和运行时操作。数据留在Confluent Cloud中，推理结果可以写回Kafka主题，供告警系统、仪表板、数据湖、应用程序和AI代理继续使用。平台还将数据模式、血缘关系、访问控制和可回放的Kafka主题纳入同一套治理机制。

这意味着，一个预测结果不必停留在报告中。它可以成为下一步操作的触发器：库存可能耗尽时启动补货，支付行为异常时提高审核级别，设备状态偏离历史模式时生成维护工单。

制造业和金融服务是直接应用场景

IBM给出的示例是一条巧克力生产线。温度、速度和产量每隔几秒进入数据流后，模型可以预测当晚班次的产出，并在短缺真正发生前提醒计划人员；同时，它还可以将当前生产过程与同类产品的历史运行状态比较，以便发现缓慢的漂移。

在制造业中，模型还可以把温度、搅拌速度、投料量和黏度等变量结合起来。通过加入操作人员能够控制的设置，预测模型可以进一步充当模拟器，帮助寻找满足能耗、产量或质量约束的参数组合。IBM把这一能力描述为生产优化，而不只是传统意义上的设备告警。

金融服务是另一个重点场景。对于银行卡或支付交易，异常检测可以在交易仍处于处理流程中时运行。模型关注的不只是某笔交易是否超过固定规则，而是特定账户、卡片或业务渠道的行为节奏是否正在改变。Confluent称，模型可以把检测结果继续传给人工分析人员、阻断系统或其他代理式工作流。

不过，实时处理并不自动等于准确处理。欺诈模式会变化，工业传感器可能缺失或漂移，未来协变量也未必可靠。企业仍需要根据自身数据评估误报率、延迟、覆盖范围和回滚机制，不能仅凭基础模型的通用表现替代现场验证。

IBM的时间序列模型正在形成一个更大的开放组合

IBM Research在另一篇时间序列模型介绍中表示，其时间序列模型组合已经在公开的GIFT-Eval等评测中取得较高排名，并覆盖预测、异常检测、分类和搜索等任务。IBM还称，相关模型累计使用了超过1000亿个来自公开领域或合成生成的数据点进行训练。

IBM Granite时间序列文档显示，FlowState、TTM和TSPulse均属于参数量较小、可以在不依赖GPU的环境中运行的模型系列；模型权重和代码也通过Hugging Face模型集合及granite-tsfm开源仓库提供。研究版本与Granite版本的许可证不同，企业在商业部署前仍需核对具体模型权重的授权条款。

这一方向也与Google近期扩展时间序列基础模型的动作形成背景呼应。AIFlux此前报道的Google Research发布TimesFM 3.0也将多变量序列和协变量处理作为重点。Confluent的更新文章称，Google TimesFM同样被纳入其时间序列模型选择，并与IBM Granite一起通过Flink面向预测和异常检测提供Early Access能力。

模型选择的增加，反映出企业时间序列任务并不存在一个适用于所有情况的“通用最佳模型”。零售目录、工厂传感器、IT延迟和支付交易的频率、噪声、变量关系与错误成本都不同。将多个模型放进同一数据流平台，企业可以在保持接口和管道不变的情况下进行比较。

收购Confluent后，实时数据成为IBM企业AI战略的一部分

此次发布也发生在IBM完成收购Confluent之后。IBM在2026年3月的公告中表示，Confluent拥有超过6500家企业客户，其中包括约40%的《财富》500强企业；IBM将其定位为企业AI和代理系统的实时数据基础。

对IBM而言，Granite模型在Confluent数据流中运行，使模型能力与数据接入、治理和分发结合起来。对Confluent而言，时间序列模型则扩大了数据流平台从“传输和处理事件”到“直接参与业务判断”的范围。

这也是实时企业AI面临的一个核心问题：模型即使能力足够，如果看到的仍是数小时之前的数据，它作出的判断就可能已经错过窗口。把推理放到数据流内部，可以降低数据复制、额外模型服务和跨云传输带来的复杂度，但同时也把模型质量、权限控制、数据治理和运营责任更紧密地放在一起。

目前，IBM Granite时间序列模型在Confluent Cloud上的能力仍处于Early Access。Confluent Platform的本地和混合云版本、更多行业客户的量化结果，以及企业是否能够在生产环境中稳定控制误报与成本，仍是下一阶段需要观察的重点。

来源：Hugging Face上的IBM Research原始文章、Confluent第三季度产品更新、IBM Granite时间序列模型文档。