IBM and Confluent have integrated the Granite Time Series models directly into Confluent Cloud to run forecasting and anomaly detection on data while it’s still in motion. The approach avoids having to move that time-series data to a separate machine learning platform first, and lets the models be called from Apache Flink using SQL. The technology is now available in Early Access, initially on Confluent Cloud on AWS.
Granite Time Series on Confluent in 30 seconds
- IBM and Confluent are bringing time-series models directly into stream data processing.
- The
AI_FORECASTandAI_DETECT_ANOMALIESfunctions let the models be called from Flink SQL. - The first release includes four IBM models ranging from 1 to 260 million parameters, designed to run without a GPU.
- Results can flow back into Kafka to feed alerts, applications, lakehouses, or AI agents.
- It’s in Early Access: it shouldn’t yet be treated as a feature with the guarantees of a fully available service.
The announcement is architecturally more interesting than simply adding another set of AI models to a cloud service. What IBM and Confluent are trying to do is bring inference closer to where events are processed, shortening the usual path between generating data, storing it, analyzing it, and then acting on it.
That can matter in systems where a few minutes of delay change how useful a prediction actually is: financial transactions, industrial telemetry, inventory, application performance, network traffic, or sensor data.
Still, some of the claims around the announcement are worth tempering. The integration doesn’t mean every company will automatically solve its problems “in seconds,” nor does it prove on its own that a streamhouse is always cheaper than a lakehouse architecture. The concrete news is narrower: certain time-series inference operations can now run directly inside the flow managed by Confluent.
From storing first and analyzing later to running AI on the stream
Many analytics architectures follow a familiar path.
An application, sensor, or enterprise system generates events. That data is moved to an intermediate system, ends up in a data warehouse, data lake, or lakehouse, and only afterward does another process use it to train models, run inference, or generate reports.
That design still makes sense for plenty of workloads.
The problem shows up when the value of the data drops quickly over time.
A temperature anomaly on an industrial machine matters while it can still be acted on. A potentially fraudulent transaction is far more useful if it’s flagged before it completes. An unexpected latency spike should be caught while it’s affecting an application, not when it shows up in the next day’s report.
The IBM and Confluent integration is meant to shrink that gap.
Confluent provides the continuous flow of events and Apache Flink handles the processing. The Granite Time Series models can use that data to generate forecasts or detect anomalies without first deploying a separate model serving service.
The results don’t have to stop there, either.
They can be written back to Apache Kafka topics, where other consumers can pick them up: alerting systems, dashboards, applications, analytics repositories, or AI agents.
That turns inference into just another stage of the event pipeline.
Two SQL functions hide most of the complexity
One of the more interesting decisions here is the interface chosen.
Confluent exposes the models through two Flink SQL functions:
AI_FORECAST for generating predictions and AI_DETECT_ANOMALIES for flagging values that stray from expected behavior.
For example, a series of CPU utilization metrics can feed AI_FORECAST. The function takes the value, its timestamp, and various configuration parameters, and returns several future values along with quantiles that represent the uncertainty.
Anomaly detection follows similar logic. AI_DETECT_ANOMALIES compares observed values against prediction intervals and returns information such as the actual value, the forecast, upper and lower bounds, and a flag indicating whether the data point is considered anomalous.
None of this turns machine learning into two magic commands.
Data quality, sampling frequency, the temporal context used, confidence thresholds, and above all what decision the system makes afterward still matter just as much.
A wrong alert can simply be annoying. An inference used automatically to block a payment, change an industrial process, or adjust a price needs considerably stricter controls.
The simplification is in how the model is consumed, not in the disappearance of the usual challenges of working with predictive models.
Four small models, no GPU required
Another difference from much of today’s conversation about AI is the size of these models.
IBM and Confluent have initially selected four Granite Time Series models: PatchTST-FM-r1, FlowState-r1.1, TTM-r3, and TSPulse.
They don’t all target exactly the same goal.
| Model | Primary focus |
|---|---|
| PatchTST-FM-r1 | Probabilistic forecasting, distributions, and quantiles |
| FlowState-r1.1 | Point forecasting and data at different frequencies |
| TTM-r3 | Balance between efficiency and performance across many series |
| TSPulse | Anomalies, classification, similarity search, and gap imputation |
All four models have between 1 and 260 million parameters and are designed to run without a GPU. TTM-r3, for instance, is built to process large numbers of series at a contained cost using CPU alone.
That’s a very different approach from using a large language model to analyze any kind of signal.
A time series has specific characteristics: chronological order, periodicity, trend, seasonality, and relationships between consecutive observations. A specialized, relatively small model can be enough for certain problems without needing billions of parameters.
From an infrastructure standpoint, that matters.
Inference on operational data can generate an enormous volume of calls. If every sensor, server, transaction, or product needs a continuous prediction, the cost per inference ends up being just as important as the model’s accuracy.
Avoiding GPUs also makes it easier to fit this kind of analysis inside pipelines that process large volumes of events.
Data can stay inside Confluent Cloud
There’s another technical consequence worth noting.
The models used by AI_FORECAST and AI_DETECT_ANOMALIES are managed by Confluent and hosted inside Confluent Cloud. The documentation specifies that these functions currently don’t support remote models from other providers or models managed directly by the customer.
That cuts out some infrastructure pieces.
There’s no need to send every event to an external inference endpoint, manage additional credentials, or deploy another service just to host the model.
IBM and Confluent argue this approach can reduce dedicated infrastructure and avoid certain data ingress and egress costs. It also lets inference follow the schema, lineage, and access-control policies already in place on the platform.
Kafka also brings an interesting property for enterprise systems: events can be retained and replayed.
An automated decision doesn’t have to turn into a black box that can’t be reconstructed.
If the corresponding stream is kept, an organization can review what information the system received, investigate an incident, later evaluate the model’s behavior, or re-run inference over historical data.
For regulated use cases or decisions with operational impact, that traceability can matter just as much as the prediction itself.
From predictive maintenance to server performance
Enterprise examples are easy to picture because virtually any modern infrastructure produces time series.
An industrial environment generates temperatures, speeds, pressures, and production levels. A store logs sales and inventory. A financial platform watches transactions. An application continuously generates latency, errors, and resource usage.
There are obvious applications for IT operations, too.
CPU, memory, IOPS, storage latency, traffic, request counts, response times, open connections, and HTTP errors are all time series.
A conventional system can trigger an alert when CPU usage crosses 90%.
A time-series model could try to catch something different: that a machine’s current behavior looks abnormal even though it hasn’t crossed any fixed threshold yet.
It could also estimate when a given capacity level will be reached.
The difference between the two approaches matters for observability. Rules respond to previously defined conditions. Forecasting tries to anticipate what will happen, and anomaly detection looks for patterns that stray from what’s expected.
That doesn’t mean traditional thresholds should disappear.
In critical infrastructure, it probably makes more sense to combine deterministic rules, conventional observability, and predictive models than to replace one with the other.
Fraud can be caught while a payment is still in transit
IBM points to financial services as an example.
A transaction can be evaluated while it’s still moving through the system. If its behavior strays from expected patterns, the inference result can immediately feed the next action: blocking it, requesting a review, or providing extra context to another AI system.
This is where one of the more interesting possibilities of combining streaming and AI comes in.
The model’s output doesn’t have to be the end of the process.
It can become another event.
A detected anomaly can be published to Kafka. A second system can enrich it with customer information. An agent can analyze that context. Another service can finally carry out an action.
The architecture starts to look less like “send data to an AI” and more like embedding inference inside an event-driven distributed system.
The lakehouse isn’t going away because AI joins streaming
Still, it’s worth drawing an important distinction from some of the messaging around this announcement.
Running inference directly on streaming data doesn’t automatically remove the need for a data lake, a warehouse, or a lakehouse.
These are different problems.
Organizations still need historical storage for analytics, training, compliance, research, reporting, and plenty of workloads that don’t require an immediate response.
Streaming is especially valuable when it matters to act on an event while it’s still current.
Both models can coexist.
In fact, IBM explains that the resulting inferences can be distributed from Kafka to both operational systems and lakehouses.
That’s why it’s more accurate to talk about bringing intelligence closer to the data flow than about replacing one analytics architecture with another.
Still Early Access
The other important caveat is around availability.
Granite Time Series on Confluent Cloud is currently in Early Access.
Initial availability is on Confluent Cloud on AWS. IBM and Confluent say support for on-premises Confluent Platform deployments and hybrid environments is planned to follow.
Confluent’s own documentation also specifies that features included in the Early Access program carry no service-level commitment and are considered proof-of-concept functionality under its terms of service.
That matters especially for applications that could end up feeding into critical processes.
The technology can already be tried, but there’s still a gap between experimenting with predictions on a stream and turning them into a production dependency with strict availability requirements.
The IBM and Confluent announcement is interesting on its own terms, without needing to be framed as an immediate revolution.
Enterprise AI has mostly been associated in recent years with language models, chatbots, and agents. Time series are a reminder that a huge share of corporate data takes a different shape: values that keep changing over time.
Servers, factories, networks, stores, vehicles, markets, and financial systems generate that kind of information nonstop.
Applying small models directly to those flows can end up being far more useful for certain companies than deploying yet another chatbot.
And that’s probably the most significant part of the announcement: artificial intelligence is starting to shift from applications that wait for a human question toward infrastructure that continuously watches what’s happening and produces a signal before anyone even has to ask.
Frequently Asked Questions
What did IBM announce with Confluent?
IBM Granite Time Series is integrating with Confluent Cloud to run forecasting and anomaly detection directly on streaming data through Apache Flink. Initial availability is in Early Access on Confluent Cloud on AWS.
Which Granite Time Series models will be available?
The initial lineup includes PatchTST-FM-r1, FlowState-r1.1, TTM-r3, and TSPulse. They range from 1 to 260 million parameters and are designed to run inference without needing a GPU.
How is the AI used from Apache Flink?
Confluent provides the Flink SQL functions AI_FORECAST and AI_DETECT_ANOMALIES. They let users select models and configure forecasting or anomaly detection directly from SQL queries, without separately deploying the infrastructure that serves those models.
Can this technology replace a lakehouse?
Not necessarily. Streaming with inference lets teams act quickly on events, while lakehouses and other repositories remain useful for historical storage, analytics, and other workloads. IBM and Confluent’s own architecture allows streaming results to feed back into these systems.
