Early AccessConfluent Cloud for Apache FlinkAWS first, Confluent Platform nextModels and agents
Forecast, detect and optimize inside the stream.
IBM Granite Time Series models now run natively on Confluent Cloud for Apache Flink. One SQL call scores every event as it arrives, and Streaming Agents act on the result. No model training, no feature engineering, no separate ML stack.
No charge for the models during Early Access. Switch between four models with one SQL parameter. Open weights on Hugging Face, 44M+ downloads.
AI_DETECT_ANOMALIES · tempering_line
actual value forecast mean prediction interval is_anomaly = TRUE
Output ROW, latest events
Flink SQL for this panel
Simulation runs in your browser to show the shape of the output. It is not model inference. The SQL is real and runs on Confluent Cloud for Apache Flink with Early Access enabled.
44M+downloads of IBM Granite Time Series models on Hugging Face, across 10 models since the 2024 launchJoint IBM and Confluent announcement, September 2026
#1zero-shot model under a commercial-friendly license on GIFT-Eval, CRPS and MASEPatchTST-FM-r2 model card, as of August 31, 2026
#1on the TSB-AD anomaly detection leaderboard, univariate and multivariateTSPulse paper, arXiv 2505.13033
1M to 385Mparameters. CPU inference, no GPU requiredHugging Face model cards, October 2026
5 to 10×productivity gains reported with design partners in cement, steel, pulp and paper, food and telecommunicationsIBM Research, Hugging Face blog
Time series foundation models, running where the data already moves.
IBM Granite Time Series models are hosted inside Confluent Cloud and called from Flink SQL like any other function. This chapter covers the architecture, the SQL, the model portfolio, the public benchmarks and what ships next.
How it works
Granite reads the signal. Confluent supplies the context, the governance and the delivery.
Confluent Cloud provides native inference: the models are hosted by Confluent and called from Flink SQL. Inference results are written to Kafka topics and shared with fanout, consumable by alerting systems, dashboards, lakehouses and AI agents.
What Confluent brings
The live state of the business, and reach to every system that acts
Native inference hosted in Confluent Cloud, called from Flink SQL. No model serving, scaling or runtime to operate.
Flink stateful processing: lookback windows keyed per series, checkpointed and fault tolerant.
Fresh, enriched context from sensor telemetry, payment activity and application metrics, joined in the stream.
Governance built in: schemas, lineage and RBAC apply to inference pipelines like any other topic.
Results on Kafka topics with fanout to alerts, dashboards, lakehouses through Tableflow, and Streaming Agents.
Confluent Cloud first, Confluent Platform next for on-premises and hybrid environments.
What IBM brings
Compact foundation models that understand how signals behave
Four complementary Granite Time Series models: PatchTST-FM, FlowState, TTM and TSPulse, each matched to a different decision.
Zero-shot forecasting and anomaly detection on series the models have never seen, with probabilistic outputs.
Small by design: 1M to 385M parameters, CPU inference, open weights on the Hugging Face Hub under Apache 2.0 and OpenMDW licenses.
Proven in IBM's own products and operations first, then with design partners in cement, steel, pulp and paper, food and telecommunications.
A growing set of functions on the models, so optimization and semantic intelligence arrive as capabilities you call rather than projects you build.
IBM's enterprise AI governance framework, with model provenance and licensing transparency. Confluent joined IBM in March 2026.
Flink SQL
The whole project is one call.
Both functions are windowed aggregates: OVER (ORDER BY event_time RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW). Add PARTITION BY to keep one model context per card, SKU, host or asset. Change the model value and the same statement runs any of the four Granite models, or TimesFM, with no pipeline redesign.
Twelve steps ahead on a meter reading stream with the default model. The result is a ROW with a forecast array (one entry per horizon step, each with mean, q10, q50 and q90) and a metadata JSON string.
AI_FORECAST · ttm
SELECT
event_time,
load_kw,
AI_FORECAST(
load_kw,
event_time,
JSON_OBJECT('model' VALUE 'ttm', 'horizon' VALUE 12)
) OVER (
PARTITION BY meter_id
ORDER BY event_time
RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
) AS forecast
FROM meter_readings;
A 99 percent prediction interval on service latency. Each row returns actual_value, forecast_value, lower_bound, upper_bound, is_anomaly and a rolling rmse. Fields are null until minContextSize points have arrived.
AI_DETECT_ANOMALIES · flowstate
SELECT
event_time,
response_ms,
AI_DETECT_ANOMALIES(
response_ms,
event_time,
JSON_OBJECT(
'model' VALUE 'flowstate',
'minContextSize' VALUE 20,
'maxContextSize' VALUE 512,
'confidencePercentage' VALUE 99.0
)
) OVER (
PARTITION BY host_id
ORDER BY event_time
RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
) AS anomaly
FROM server_metrics;
The fraud pattern: a sense of normal per card, scored while the payment is in flight, and only the flagged rows written to an alerts topic that a case system, a dashboard or a Streaming Agent consumes.
CREATE TABLE AS SELECT · ttm
CREATE TABLE card_alerts AS
SELECT
card_id,
event_time,
amount,
anomaly.forecast_value AS expected,
anomaly.lower_bound,
anomaly.upper_bound,
anomaly.rmse
FROM (
SELECT
card_id,
event_time,
amount,
AI_DETECT_ANOMALIES(
amount,
event_time,
JSON_OBJECT('model' VALUE 'ttm', 'confidencePercentage' VALUE 99.5)
) OVER (
PARTITION BY card_id
ORDER BY event_time
RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
) AS anomaly
FROM card_payments
)
WHERE anomaly.is_anomaly = TRUE;
The planner's pattern: a seven-day probabilistic forecast per SKU with PatchTST-FM, unnested to one row per horizon step so replenishment can read the 90th percentile as a reorder point.
AI_FORECAST + UNNEST · patchtstfm
SELECT
s.sku,
s.event_time AS as_of,
step.`timestamp` AS forecast_day,
step.q10 AS floor,
step.q50 AS expected,
step.q90 AS reorder_point
FROM (
SELECT
sku,
event_time,
AI_FORECAST(
units_sold,
event_time,
JSON_OBJECT(
'model' VALUE 'patchtstfm',
'horizon' VALUE 7,
'maxContextSize' VALUE 730
)
) OVER (
PARTITION BY sku
ORDER BY event_time
RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
) AS f
FROM daily_sales
) AS s
CROSS JOIN UNNEST(s.f.forecast) AS step (`timestamp`, mean, q10, q50, q90);
An operator who only cares about high spikes: a tight upper bound and a tolerant lower one. Both override the symmetric confidencePercentage for their side.
AI_DETECT_ANOMALIES · asymmetric
SELECT
event_time,
vibration_mm_s,
AI_DETECT_ANOMALIES(
vibration_mm_s,
event_time,
JSON_OBJECT(
'model' VALUE 'patchtstfm',
'maxContextSize' VALUE 2048,
'upperBoundConfidencePercentage' VALUE 90.0,
'lowerBoundConfidencePercentage' VALUE 99.9
)
) OVER (
PARTITION BY asset_id
ORDER BY event_time
RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
) AS anomaly
FROM motor_telemetry;
Technical reference: parameters, output fields and per-model limits
Configuration parameters, JSON_OBJECT in the third argument
Parameter
Default
Meaning
model
ttm
ttm, flowstate, patchtstfm or timesfm-2.5. Hosted by Confluent. Both functions.
horizon
5
Future steps to forecast. AI_FORECAST only.
minContextSize
20
Points required before output starts. Output fields are null until then.
maxContextSize
512
Most recent points used for prediction. Older points are truncated.
Asymmetric overrides for one side of the interval.
rmseWindowSize
5
Rolling window for the RMSE of predictions.
Output ROW
Field
Type and meaning
AI_FORECAST
forecast
ARRAY<ROW<timestamp, mean, q10, q50, q90>>, one entry per horizon step
metadata
STRING. JSON with model name, requested horizon, frequency and input lengths
AI_DETECT_ANOMALIES
is_anomaly
BOOLEAN. TRUE when actual_value falls outside the bounds
forecast_value
DOUBLE. The model's prediction for this point
lower_bound, upper_bound
DOUBLE. The prediction interval
actual_value, timestamp, rmse
The observed value, its TIMESTAMP(3), and the rolling error
Model value
Horizon
Context size
Notes
ttm
Up to 96
52 to 512
Selects the TTM variant that best matches the requested horizon and context automatically. Fast, general-purpose default.
flowstate
Greater than 6
At least the horizon, up to 4,096
Combined context and horizon under 4,102. Reads seconds-level and hourly data alike.
patchtstfm
Up to 8,176
16 to 8,064
Combined context and horizon up to 8,192. Long horizons and full predictive distributions.
timesfm-2.5
Capped at the model limit
Capped, rounded down to a multiple of 32
Google Research model, also available in both functions.
Inputs: value DOUBLE, finite, nulls skipped. timestamp TIMESTAMP(3), not null, evenly spaced for best results. The config must be constant within a query. Billing in CFUs as part of compute pool usage. Early Access features are for evaluation and non-production testing. Full reference in the Confluent documentation linked below.
The portfolio
Every decision asks the future a different question. So the answer is a portfolio.
A planning cycle needs a range of outcomes. A trading desk needs the most accurate number from data at every rate. A fleet of a hundred thousand series needs a cost that stays rational. A security team needs the moment a stream stops behaving like itself, and what happened the last time it did.
Probabilistic forecasting
PatchTST-FM
Reads a series the way a language model reads text, patch by patch, each variable in its own channel so one noisy signal cannot drag the rest down. Returns a full distribution, so a planner can set reorder points off the 90th percentile.
Params
385M (r2)
Context
Up to 8,192 points
Flink
'model' VALUE 'patchtstfm'
License
OpenMDW, commercial-friendly
Proof
#1 zero-shot model under a commercial-friendly license on GIFT-Eval, CRPS and MASE. #2 among all zero-shot replicable models (Aug 31, 2026)
A state-space model that keeps a running summary updated with every point. Its dynamics are continuous in time, so one model reads seconds-level SCADA and hourly market data alike and harmonizes mixed sampling rates for long horizons.
Params
9.1M (r1)
Context
Up to 4,096 points
Flink
'model' VALUE 'flowstate'
License
Apache 2.0
Proof
Leading point forecasting (MASE) on GIFT-Eval among zero-shot, replicable models without data leakage at release (IBM Research, March 2026)
Tiny Time Mixers drop attention for small mixing networks along time and across variables, so a model around a million parameters covers a hundred thousand series nightly on CPU. The default model in both Flink functions.
Params
1.4M (r3)
Context
52 to 512, variant auto-selected
Flink
'model' VALUE 'ttm'
License
Apache 2.0
Proof
Thousands of inferences per second on CPU. The most downloaded Granite Time Series family on the Hub across releases
Pairs time and frequency views in one small multi-task model. Multi-head triangulation correlates deviations across prediction heads for robust anomaly detection. Its embeddings are robust to shifts in time, magnitude and noise, which answers the question every operator asks: have we seen this before.
Each family comes from peer-reviewed research, with weights, code and benchmark reproductions published alongside.
2024TTMTiny Time Mixers: fast pre-trained models for zero and few-shot forecasting. NeurIPS 2024. Lightweight MLP-Mixer backbone, channel independent, tiny footprint.
2025FlowStateSampling-rate-equivariant forecasting. ICML 2026. State-space encoder with a functional basis decoder, so one model generalizes across sampling rates.
2026PatchTST-FMRevisiting the generic transformer. Patched transformer backbone trained supervised and self-supervised, scaling with generic attention.
2026TSPulseTiny pre-trained models with disentangled representation. ICLR 2026. Time and frequency embeddings with dual decoders, one backbone for many tasks.
Which model should you start with?
Answer three questions. There is no single best model, and switching costs one parameter, so start with the fit and benchmark the alternatives on your own stream.
What do you need from the stream?
What shape should the answer take?
What does the data look like?
Start withTTM'model' VALUE 'ttm'
A million-parameter model covers thousands of series on CPU and is the default in both functions. Benchmark FlowState next if accuracy on long horizons matters.
Then compare: flowstate
Benchmarks
Small was a decision, not a compromise.
The models are built to run on CPU inside the stream, and they hold their own on the public leaderboards. Positions move as new models land, so the live leaderboards are linked and every claim below carries its date.
Parameters by model, log scale
Every model available in AI_FORECAST and AI_DETECT_ANOMALIES. Smaller runs cheaper on shared CPU and scales to more series per compute pool.
IBM Granite Time SeriesGoogle TimesFM
Source: Hugging Face model cards (ibm-granite, google/timesfm-2.5-200m-pytorch), October 2026.
TSPulse, gain over the prior best per task
Relative improvement reported in the TSPulse paper, with a model 10 to 100 times smaller than the ones it compares against.
Zero-shot imputation+50%
Similarity search+25%
TSB-AD anomaly detection+20%
UEA classification+5 to 16%
Source: TSPulse: Dual Space Tiny Pre-Trained Models for Rapid Time-Series Analysis, arXiv 2505.13033. Bar for classification drawn at the top of its range.
Throughput
TTM delivers 10 to 60× faster accelerator throughput than the larger models it is compared against, and thousands of inferences per second on CPU. Small is what makes per-event scoring across thousands of series affordable.
GIFT-Eval, forecasting
97 tasks from 55 datasets across 7 domains, short to long horizons. PatchTST-FM-r2 is the top zero-shot model under a commercial-friendly license on CRPS and MASE and #2 among all zero-shot, replicable models (Aug 31, 2026). FlowState led point forecasting among zero-shot, replicable models without data leakage at release (March 2026).
TSPulse ranks first on both the univariate and multivariate leaderboards, outperforming statistical baselines by 24 percent and larger foundation models by at least 33 percent, with about a million parameters and GPU-free inference.
Public benchmarks pick a shortlist. Your data picks the model. During Early Access, run the same statement with each model value and compare the rolling rmse field and the flagged rows on your topics. The IBM and Confluent teams work through the results with you.
Agents run the loop. Experts approve at every gate.
Two layers of agents, both on Confluent. At build time, coding agents work through Confluent's managed MCP servers, scoped by your RBAC and written to the audit log. At run time, the loop becomes Streaming Agents in Flink SQL. Every pass learns from live data, and a person signs off before anything changes.
Stage 1
Data prep
Streams profiled and aligned.
Topics, schemas and samples through Confluent MCP, then Flink SQL joins, windows, resampling and gap fill. Schema Registry contracts guarantee the shape of every stream.
Gate: validate the data and the demand drivers
Stage 2
Model use
Zero shot first. Fine-tune if it pays.
TTM for throughput, PatchTST-FM for long context and probabilistic output, TSPulse for detection and search. LoRA fine-tuning only when the backtest shows it pays.
Gate: approve the model choice
Stage 3
Benchmark
Backtest, champion-challenger.
Rolling backtests on MASE, WAPE and CRPS against a seasonal naive baseline and the incumbent model, with champion-challenger before promotion.
Gate: sign off accuracy and bias
Stage 4
Deploy
A versioned Flink SQL function.
CREATE TOOL wraps AI_FORECAST or AI_DETECT_ANOMALIES, CREATE AGENT binds a model, prompt and tools, AI_RUN_AGENT executes per event and agents chain. Under RBAC, billed as Flink compute.
Gate: approve the release and its guardrails
Stage 5
Learn
Drift watched, retuned.
Actuals joined to forecasts in the stream, bias and drift tracked, and a drafter-critic reflection reviews before any retune is triggered.
Gate: review drift before retraining
Build time
Coding agents, through managed MCP
Claude Code, Codex or IBM Bob agents build the pipeline through Confluent's managed MCP servers: global for environments, clusters, connectors and metrics, regional for topics, schemas and sample messages. Time series MCP tools cover profiling, backtesting and deployment, and the playbooks ship as skills so the same workflow runs in whichever assistant the team already uses.
Run time
Streaming Agents, in Flink SQL
The loop runs as Streaming Agents on the enriched topics. Agents chain the way a fraud pipeline does, risk assessor to investigator to decision, with operator gates and governance built in. The result is days to a governed forecast rather than months, and an architecture that keeps improving because every model or agent release lands in the same loop and scales with the stream.
Roadmap
Cloud first for exploration. Platform next for where the plant lives.
Early Access is a feedback loop. The functions, the models and the packaging below are shaped with design partners and clients on real enterprise use cases, so scope and timing can change.
Available now, Early Access
Forecasting and anomaly detection
AI_FORECAST and AI_DETECT_ANOMALIES with Granite TTM, FlowState and PatchTST-FM, plus Google TimesFM 2.5
Confluent Cloud for Apache Flink on AWS
No charge for the models during Early Access. Flink compute billed in CFUs
Open weights and notebooks on Hugging Face and GitHub for work outside the stream
Next in Early Access
Optimization and semantic intelligence
TSPulse for anomaly detection, embeddings and similarity search in the stream
Three new Flink functions on the models: TS_EMBED, TS_SEARCH and TS_OPTIMIZE
Production optimization: forecasts conditioned on controllable settings, optimized against a stated KPI inside constraints
Semantic intelligence: embed each window as it arrives, search history for precedents, classify and fill gaps
Enablement materials, demo datasets and client working sessions
On the road to general availability
Hardening, hybrid and agents
Production readiness: performance, scale, compliance and a support model
Confluent Platform for on-premises and hybrid estates, where most industrial deployments run
Forecasts and anomalies as triggers for Streaming Agents, served through MCP and agent skills
Continued model iteration with design partners: multivariate, new architectures, new data sources
The value is the time between an event and knowing about it.
Why scoring in the stream beats scoring in the warehouse for the decisions that pay for speed, told from the side of the people who own those decisions.
Why the stream
The decision window closes faster than the batch job runs.
Most forecasting and detection still runs on old economics: one bespoke model per series and months of expert work on each. So teams model the few hundred series where the money is and cover the rest with safety stock, extra headroom and wider tolerances, acted on after the window has closed. That margin is the cost of a decision nobody could forecast, paid every cycle.
A pump caught drifting today is a work order. The same pump next week is an outage. Scoring in the stream moves the decision to the left of this curve.
A time series foundation model changes the economics. Trained once across vast, varied signals, it generalizes to a series it has never seen. Give it a window of measurements and it returns what comes next, how far behaviour sits from normal, which history looks like this one, and which settings best serve a target. A demand planner, a fraud analyst or a process engineer can put it to work on their own streams.
Forecasting and detection are stateful. The next value only means something against recent history, and an anomaly only exists against a running sense of normal. Flink manages that state, keyed per series and fault tolerant, so every model call gets the history it needs without a separate data store or a database hit per event.
Score in the stream. Train, backtest and evaluate at rest.
The lakehouse stays the right place for bulk historical scoring, backtesting and fine-tuning. Tableflow lands inference results from Kafka topics as Iceberg or Delta Lake tables for exactly that, so the two estates share one lineage.
Demand planner, grocery retail
She plans the head of the catalogue. The tail sits on the shelf as working capital.
Pain
One model per SKU, refit by hand, so planning never reaches the long tail. New launches start with no history at all.
Wants
One shared model across 100,000 SKUs nightly on CPU, returning a distribution rather than a single line, so service level becomes a policy she can state out loud.
Outcome
Reorder points off the 90th percentile. Fewer stockouts and markdowns. Freed working capital, usually the largest line in the business case.
Fraud lead, retail bank
Rules are enumerable, so adversaries enumerate them. Labels are scarce and stale.
Pain
Tightening a rule declines more honest customers. Bespoke models wait for labelled cases that arrive late, and false alarms cost more than the crime.
Wants
A sense of normal per card, scored while the payment is in flight, that transfers to new products and corridors on day one.
Outcome
The alarm fires before the money moves. The same customer on an honest holiday sails through. Every score becomes a trigger: block, escalate with the closest past cases attached, or hand to an agent.
Process engineer, consumer goods plant
Statistical models drift. Rule-based control holds a setpoint but never improves it.
Pain
Months of bespoke modelling per line, and recommendations nobody can interrogate, so optimization stays in pilots and the plant runs on margins.
Wants
A forecast conditioned on the settings the crew controls, so it becomes a simulator and an optimizer searches it against a KPI he names, inside his constraints.
Outcome
Months become days. One point on an operation turning over hundreds of millions is a seven-figure line, and the person who knows the line steers it.
Productivity, accuracy, responsiveness
Three dials move when the model meets the stream.
The client pain point is the same everywhere: forecasting, anomaly detection and optimization still mean one bespoke model at a time and months of expert work on each, so decisions are made on safety margins after the window has closed.
Dial
The problem today
With Granite models in the stream
Impact
Productivity
Bespoke models, months of expert work, hard to scale
Zero-shot models reused across use cases, value in days
10× faster time to value 5× lower skill required
Accuracy
Rules and classic ML plateau, and lost accuracy is lost margin
Benchmark-leading models, with savings validated in the millions
5 to 10% accuracy improvement
Responsiveness
Mission-critical operations hedge with safety margins
Scored live in the stream, decided in the window, adaptive
Days to seconds from signal to decision
Impact figures as reported across IBM design-partner engagements in cement, steel, pulp and paper, food and telecommunications. Results vary by process and data.
The journey
From bespoke and batch to the autonomous enterprise.
Most teams start bottom left: bespoke models on batch data. Moving right brings time series foundation models and agents. Moving up brings real time. The destination is top right: real-time decision intelligence with foundation models and governed agents on Confluent.
Time series foundation models and Confluent move teams along both axes at once.
In the warehouse or in the stream
SQL-native forecasting exists in every warehouse. The difference is where it runs.
BigQuery AI.FORECAST, Snowflake ML functions and Databricks ai_forecast score tables at query or job time. That is the right tool for backtesting and bulk scoring. Decisions that pay for speed need the score on the event, while the event is still in flight.
Dimension
Warehouse ML functions
IBM Granite Time Series on Confluent
Where inference runs
On tables, when a query or a scheduled job runs
On each event as it arrives, inside Confluent Cloud for Apache Flink
Model choice
Typically one built-in model per function
A portfolio switched with one SQL parameter: ttm, flowstate, patchtstfm, plus Google timesfm-2.5
History and state
Lookback window rebuilt per query
Flink keeps per-series state, keyed and fault tolerant, so each call sees its own history
Where results land
A result table
A Kafka topic with fanout to alerts, dashboards, the lakehouse through Tableflow, and Streaming Agents
Governance
Warehouse access controls
Same schemas, lineage and RBAC as every other topic. Replayable topics support audit, model evaluation and rerunning inference on history
Infrastructure to run
None
None. Confluent hosts the models, with no provider credentials, no GPUs to provision and no cloud ingress or egress fees
Best for
Backtesting, bulk scoring, fine-tuning, reporting
Scoring in flight and turning the result into an action within the decision window
Warehouse function names belong to their vendors and are listed for orientation. Capabilities change, check each vendor's documentation.
Proof in production
Three engagements where Granite Time Series models run on live operational data.
Telecommunications
Network operations with TSPulse anomaly detection
IBM Network Intelligence runs domain-trained time series foundation models with ultra-low latency inference on streaming metrics, events and logs from IP, radio and broadband networks. Anomalies become observations, agentic root cause analysis grounded in operating guides and config knowledge confirms or discards each one, and a ticket is opened only when a cause is confirmed.
Flow
Datapoints to observations to validated investigations to confirmed issues with remediation plans
Modes
Assist and agentic, human in the loop or autonomous remediation
Cement production
Process and quality models per mill
Traditional regression meant 8 to 10 models per cement grade and 24 to 30 models per mill, six months to deliver one mill. With two foundation models, one for process parameters and one for qualities, fine-tuned per mill, one mill takes 8 to 10 weeks and the same model captures every grade.
93% to 99%accuracy
$2 per tonEBITDA improvement
$10s to 100s Mfinancial benefit from savings and added production
Financial services
Multivariate asset forecasts with Granite TTM
A fintech fuses market indicators, estimated ESG signals, news sentiment and control inputs, fine-tunes one TTM per asset class, and deploys it for multi-horizon forecasts with uncertainty estimates behind investment strategies and portfolios. Inference runs on CPU.
About 10%RMSE improvement over the current approach
One modelper asset group, rapid adaptation to new assets and markets
Results as reported by the engagements. Client identities withheld.
What you get
Native inference, governed by default, billed as the Flink you already run.
Real-time where the data lives
Forecast and detect at the moment business conditions change, without extracting time series into a separate ML platform or warehouse.
Zero configuration
Confluent manages model serving, infrastructure, scaling and runtime. There is no provider credential to manage and no glue between pipelines and the model.
Cost efficiency
No dedicated model-serving infrastructure or GPUs to provision, and zero cloud ingress or egress fees. Compute is billed in CFUs as part of your Flink compute pool.
Enhanced security
Data stays within Confluent Cloud for inference and follows RBAC and privacy policies across the platform.
Built-in governance
Durable, replayable topics support auditing, troubleshooting, model evaluation and rerunning inference against historical data.
Fresh context
Models act on what is happening now rather than stale batch data, which makes predictions more reliable and more actionable.
Faster time to value
From a streaming topic to a working forecast and anomaly detection pipeline in minutes, in SQL your team already writes.
Model choice
Confluent is model-agnostic. Benchmark Granite models and Google TimesFM on your own stream and pick the best fit per workload.
Four lanes, and the industries already running them.
Every lane follows the same pattern: the model reads a stream it has never seen, the result lands on a topic, and the signal becomes a trigger for a system, an agent or a person.
Where the value lands
Four lanes, one pattern: the signal becomes a trigger.
All four compress the time between an event and knowing about it. In the stream that gap shrinks from days to seconds, and the result feeds the systems, agents and people that act: investigate, triage what matters, and loop in a human with context already gathered.
IT infrastructure
Predicting storage, network and compute utilization to prevent outages.
Supply chain
Forecasting demand to manage inventory and reduce carrying costs.
Financial services
Revenue prediction, fraud detection and risk assessment.
Manufacturing and industrial
Predictive maintenance and anomaly detection in physical processes.
Forecasting and planning
One model is a model factory
A two-year SKU and a three-month one in the same job, a launch with no history starting from the SKUs it resembles, 100,000 series nightly on CPU, the same play across categories and regions. Because each forecast lands on a topic, replenishment fires from it, and allocation and pricing read the same numbers.
Call
AI_FORECAST with patchtstfm for quantiles, ttm for scale
Reads
Orders, point of sale, inventory movements, promotions and weather as drivers
Outcome
Fewer stockouts and markdowns, revenue protected on the shelf, working capital freed
Worked example: demand forecasting at a national grocery retailer
Thousands of stores, about 100,000 SKUs, fresh and ambient, on a weekly promotion cycle. The planning cycle runs continuously on Confluent: sense sell-out, stock, promotions and events as they happen, forecast every SKU and store with AI_FORECAST, plan safety stock from the P10 to P90 band, execute when the reorder point is hit and the purchase order is raised in the stream, and learn as actuals feed back with planners reviewing by exception.
Today
On Confluent
Nightly extract, lagging shipments
Sell-out and demand drivers as they happen
One model per category, days to retrain
Zero shot, every SKU in every store
Weekly forecast to DC replenishment
Hourly, with reorder point and purchase order in the stream
Safety stock by rule of thumb
P10 to P90, a service level choice
Planners crunch numbers in spreadsheets
Planners review by exception
Outcome: forecast accuracy up 5 to 10 points, fewer stockouts, expedites and waste.
RetailConsumer goodsLogisticsEnergy demand
Anomaly detection
Protection starts on day one
The model keeps a sense of normal per card, per host or per asset and scores every event through the same call while it is still in flight. Because it also forecasts, it flags the drift toward trouble before the event. What the model learned elsewhere transfers to new products, corridors and asset types with no labelled case.
Call
AI_DETECT_ANOMALIES, PARTITION BY the entity, asymmetric bounds where only one direction matters
Reads
Payments, sessions, service latency, cell-site KPIs, vibration and temperature
Outcome
Block the payment before the money moves, open the work order before the failure, catch the outage before customers do
Worked example: sales anomaly detection at a multi-store retailer
Every store and SKU scored daily against a forecast band, with no labelled data and no second pipeline. AI_DETECT_ANOMALIES runs in streaming mode with confidencePercentage 99.9 and 512 days of context, so weekend peaks are expected rather than flagged. In the demo, a running job scored 1,096 days and flagged three.
Cause
Flag
Action
Stockout
Actual below the lower bound while demand holds
Replenish or expedite the store the same day
Pricing or promotion error
A spike or dip lines up with a price change
Check the price file, fix before the next day
Promotion did not land
The expected lift in the band never arrives
Rebalance stock and marketing before it ends
Broken data feed
Zeros or flat values where the band expects sales
Route to data operations, no false stock decision
Outcome: same-day flags with the bounds that explain them.
Banking and paymentsIT and telecom operationsIndustrial assetsSecurity
Production optimization
A forecast conditioned on what you control becomes a simulator
Energy at this mixing speed, throughput at this temperature and dosing rate, viscosity in spec or not. An optimizer searches that space against a KPI the engineer names, respects the constraints, and explains what it recommends. It re-optimizes as inputs change: a new supplier, a different batch, this quarter's objective.
Call
Forecasting functions today. Optimization functions on the models are next in Early Access
Reads
Line and process telemetry, setpoints, quality measurements, energy meters
Outcome
Months of bespoke modelling become days. One point on a line turning over hundreds of millions is a seven-figure line
How it is delivered: workbench plus runtime on Confluent
Process optimization in steel, cement, paper and other manufacturing processes runs 2 to 5× faster, with a much lower expert entry barrier. Two components:
Solution workbench: an app-guided interface for data preparation, model training, serving and inference, and multi-cycle process optimization, on managed compute (OpenShift clusters or Ray).
Runtime deployment: Granite-based forecasting operators on Confluent with exogenous and control variables for multivariate streams, bring your own tuned or trained model, and an optimization operator. Sensor streams arrive from SCADA and historians through Kafka and Flink, and setpoint recommendations flow back the same way to operators and process engineers.
Outcome: proven direct impact on top or bottom line, with the cement engagement above as the reference.
ManufacturingProcess industriesOil, gas and utilitiesData centers
Semantic intelligence
Have we seen this before?
Every lane ends on the same question. Embeddings capture the shape of a window in time and frequency, so two episodes that look alike land close together whatever their scale or offset. Each window is embedded as it arrives and matched against past episodes and their outcomes, so what comes back is a precedent rather than a score.
Call
TSPulse embeddings, search and classification. Semantic intelligence functions are next in Early Access
Reads
Any stream with history: the runs that drifted this way and what fixed them, the demand curves a new SKU resembles, the confirmed cases a session rhymes with
Outcome
The context an agent retrieves before it acts. Faster triage, fewer repeat incidents
How it is delivered: semantic operators and a real-time time series context
Pre-built, fast Granite-based semantic operators applied on streaming data: anomaly detection, forecasting, time series vector embedding, time series search and semantic tagging. Forecasts and alerts land in Apache Iceberg, embeddings land in Kafka and a vector database such as pgvector, and analyst dashboards, data scientists and AI applications consume them.
An in-memory semantic time series store enabled by Confluent.
Real-time time series context for streaming agents and applications.
Time series RAG use cases enabled by embeddings: the runs that drifted this way and what fixed them, matched as they arrive.
Lead with the decision, not the model. Start with one stream the client already has on Confluent, enroll them in Early Access, and bring the IBM and Confluent teams into a working session on their own topic. What they find on their own streams shapes what ships next.
Open, free of charge, and a working statement in minutes.
Enroll in Early Access, point a Granite model at one topic you already have, and work directly with the IBM and Confluent teams. What you find on your own streams shapes what ships next.
Get started
From a topic to a forecast in minutes.
Early Access is free of charge for the models and open to Confluent Cloud organizations on AWS. Enroll, open a Flink SQL workspace, and run the statements below on a table of your own.
Enroll in Early Access
Submit the Confluent sign-up form with your organization ID. Confluent enables the AI functions on your organization and the IBM and Confluent teams reach out to plan your first stream.
Any topic with a timestamp and a numeric value works. Start with a table you already have, or create one and insert a few minutes of readings to see the output shape before you connect real data.
Tip: switch the catalog and database from the read-only examples to your own cluster before running CREATE TABLE.
Run the call and route the result
Run AI_FORECAST or AI_DETECT_ANOMALIES as an OVER aggregate. Write the result to a topic with CREATE TABLE AS SELECT and let your alerting, dashboard, lakehouse or agent consume it.
Then change the model value and compare.
Quickstart on a test table
Creates a sensor table, inserts an hour of readings with one injected spike, then runs anomaly detection with the default model. Copy all three statements into a Flink SQL workspace and run them in order.
The first 19 rows return null output fields because minContextSize defaults to 20.
A yellow MISSING_PARTITION_BY warning is a performance hint. For one test series it is safe to ignore. Add PARTITION BY for real multi-series topics.
The injected 10:45 reading should return is_anomaly = TRUE.
Flink SQL · quickstart
-- 1. A table with a timestamp and a value
CREATE TABLE sensor_test (
sensor_id STRING,
temp_c DOUBLE,
event_time TIMESTAMP(3),
WATERMARK FOR event_time AS event_time - INTERVAL '5' SECOND
);
-- 2. An hour of readings, one spike at 10:45
INSERT INTO sensor_test VALUES
('line-1', 31.4, TIMESTAMP '2026-10-16 10:00:00.000'),
('line-1', 31.6, TIMESTAMP '2026-10-16 10:01:00.000'),
('line-1', 31.5, TIMESTAMP '2026-10-16 10:02:00.000'),
-- ... one row per minute, values between 31.2 and 31.9 ...
('line-1', 34.9, TIMESTAMP '2026-10-16 10:45:00.000'),
-- ... back to normal through 10:59 ...
('line-1', 31.5, TIMESTAMP '2026-10-16 10:59:00.000');
-- 3. Score every reading against its own history
SELECT
event_time,
temp_c,
AI_DETECT_ANOMALIES(
temp_c,
event_time,
JSON_OBJECT('model' VALUE 'ttm', 'confidencePercentage' VALUE 99.0)
) OVER (
PARTITION BY sensor_id
ORDER BY event_time
RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
) AS anomaly
FROM sensor_test;
Describe one decision you want scored in flight. We will come back with the right model, a sample statement for your topic and a working session with the IBM and Confluent teams. Nothing is sent from this page: build the note, copy it, and send it to your IBM or Confluent account team, or enroll directly in Early Access.
Early Access features are for evaluation and non-production testing. They are provided without support, SLA or indemnification while Confluent and IBM gather feedback, and general availability follows. Many clients run them on a copy of a production topic to validate value before GA.
What does it cost?
There is no charge for the models during Early Access. Flink compute for the statements you run is billed in CFUs as part of your compute pool, like any other Flink SQL. There are no model-serving instances to pay for and no cloud ingress or egress fees for inference.
Which clouds and deployments?
Early Access runs on Confluent Cloud for Apache Flink on AWS. Confluent Platform follows, bringing the same models and capabilities to on-premises and hybrid environments, which is where most industrial deployments live.
Can I bring my own model?
Not through AI_FORECAST and AI_DETECT_ANOMALIES, which use models hosted and managed by Confluent. For a custom or remote model, register it with CREATE MODEL and call it with ML_PREDICT. During Early Access you can also ask your Confluent representative for additional time series models to be made available.
Where does my data go?
Inference runs inside Confluent Cloud, in the same environment as your Flink statements, and follows the RBAC and privacy policies already applied to your topics. Nothing is extracted to a separate ML platform.
What about multivariate series?
Each AI_FORECAST or AI_DETECT_ANOMALIES call scores one value column, and PARTITION BY gives every entity its own context. For multivariate robust detection today, ML_DETECT_ANOMALIES_ROBUST accepts a ROW of metrics. Cross-channel modelling through fine-tuning is part of the Granite Time Series library, and multivariate functions are one of the most common requests shaping the roadmap. Tell us yours.
How is this different from ML_FORECAST and ML_DETECT_ANOMALIES?
ML_FORECAST and ML_DETECT_ANOMALIES fit an ARIMA model per stream and expose p, d and q. AI_FORECAST and AI_DETECT_ANOMALIES use pretrained foundation models: no training phase, zero-shot on an unseen series, quantiles in the output, and a model choice you can benchmark with one parameter.
Under which licenses are the models released?
TTM, FlowState and TSPulse are released under Apache 2.0. PatchTST-FM-r2 is released under the OpenMDW license, which is commercial-friendly. Weights, architecture, inference pipeline and the code to reproduce the benchmark results are on Hugging Face and GitHub.
Can I run the models outside Confluent?
Yes. The open weights run on your own CPUs through the granite-tsfm library, which is the right place for backtesting, bulk historical scoring and fine-tuning. The Confluent integration removes the serving, the wiring and the state management for scoring in the stream.
What you find on your own streams teaches the models what to become next.
Enroll in Early Access, point a Granite model at one topic, and work directly with the IBM and Confluent teams. No charge for the models during Early Access.