Every blueprint ships with source code, sample data, and step-by-step instructions — ready to run on your Cloudera Platform
-
Blueprint Card
Overview
This blueprint is a reference implementation for running AI workloads on Cloudera. A Cloudera AI Workbench application calls two models hosted on Cloudera AI Inference Service through an OpenAI-compatible API. It authenticates with the platform’s built-in workload token instead of separately managed API keys. Because the triage and investigation pipeline runs on your own Cloudera endpoints, security data stays inside the governed platform. The application itself is a lightweight client and needs no GPU.
The architecture follows a tiered model-routing pattern built to control cost and reduce alert fatigue. In the first stage, Qwen2.5-7B-Instruct, a small and efficient model, scores every raw event as low, medium, or high risk, processing events in parallel batches and returning structured JSON. In the second stage, Nemotron-3-Super-120B, a larger reasoning model, receives the events marked high risk. It correlates them across log sources into an incident report with a timeline, the affected users and hosts, MITRE ATT&CK technique mappings, a risk score, and prioritized response actions. Because the larger model sees only a small share of the traffic, compute goes where it adds the most value, and analysts get a short list of findings instead of a flood of alerts.
The pipeline runs on synthetic telemetry from identity, firewall, endpoint, and cloud audit logs. One multi-stage attack is hidden among routine activity and a noisy but harmless port scanner, which tests whether triage can separate real threats from false positives. The repository also includes tools for evaluating the platform. An eval scorecard measures detection accuracy against ground-truth labels, and load tests measure latency and throughput under sustained traffic. A cost model estimates self-hosted fixed costs against per-token pricing from commercial model APIs, and a benchmark runs the same model on Cloudera AI Inference and Fireworks AI. Together, these tools let technical teams and decision-makers measure how Cloudera’s model-serving stack performs from end to end.
Demo
The demo runs as an application inside Cloudera AI Workbench. It opens on a home page that explains the pipeline and offers a one-click health check, which sends a short request to both inference endpoints to confirm they are reachable and authenticated.
On the Triage & Investigate page, the user selects which log sources to load from the bundled synthetic telemetry: identity, firewall, endpoint, and cloud audit logs. Qwen2.5-7B-Instruct then scores every event and returns a risk level, a threat category, and a one-sentence reason. The results are shown with the highest-risk events first. Next, the user reviews the events triage marked high risk, adjusts the selection if needed, and escalates them to Nemotron-3-Super-120B. Nemotron correlates the events across sources into an incident report a security analyst can act on without reading raw logs. The report includes a timeline, the users and hosts involved, MITRE ATT&CK techniques, a risk score, and recommended response actions. A summary panel tracks the work completed, such as events triaged and investigations finished, instead of raw token counts.
The remaining pages show how the platform behaves beyond a single run. Traffic Generator and Live Stream send sustained, real traffic to the endpoints to show latency and throughput under load. Evals scores triage accuracy against ground-truth labels and can be rerun after any prompt or model change. Benchmark compares the same model running on Cloudera AI Inference and on Fireworks AI. Watch the demo
Key Features
Two-stage model routing: Qwen2.5-7B-Instruct quickly scores every raw event for risk. Only the high-risk events go to Nemotron-3-Super-120B for a deep investigation that correlates them across log sources, which keeps compute costs in line with the value of each event.
Outcome-based metrics: the demo tracks the security work actually completed, such as events triaged, cases escalated, and investigations finished, instead of raw request or token counts.
Live load testing: a configurable traffic generator and a live dashboard that sustains a target number of events per second show how the endpoints handle real, concurrent traffic.
Repeatable evals: a scorecard measures attack detection and false positives against ground-truth labels and can be rerun after any prompt or model change.
Cross-platform benchmark: the same model runs on both Cloudera AI Inference and Fireworks AI, comparing latency, throughput, and triage quality across serving platforms.
Use Case
Screen all telemetry at low cost: a small, fast model scores every event from identity, firewall, endpoint, and cloud logs, so teams can cover their full log volume without sending every line to an expensive model.
Focus deep analysis where it matters: only high-risk events go to a larger reasoning model, which keeps compute spending in line with the value of each event and cuts the noise that buries real threats.
Turn alerts into action: the investigation model correlates escalated events across sources into an evidence-based incident report. The report has a timeline, the affected users and hosts, MITRE ATT&CK mappings, a risk score, and response steps, so analysts can act without re-reading raw logs.
Keep security data governed: both models run on Cloudera AI Inference Service inside your own environment, so sensitive telemetry doesn’t go to third-party APIs.
Prove it before you deploy: a built-in scenario hides a multi-stage attack, from phishing to cloud data exposure, among routine activity and a harmless port scanner. Evals then measure how well triage catches the real threat without false alarms.
Architecture
The diagram shows the full Cloudera pattern this scenario is based on. Cloudera DataFlow (NiFi) and Cloudera Streaming (Kafka) ingest security logs in real time into an Iceberg lakehouse. There the data is queried in place, and the results are written back to a new Iceberg table. A single SDX governance layer spans both data and AI, with Ranger enforcing access policies and Atlas tracking lineage and the data catalog.
This blueprint implements the AI services layer of that architecture. A Cloudera AI Workbench application calls two models on Cloudera AI Inference Service through an OpenAI-compatible API, authenticated with the workload’s own token. In this demo, a bundled synthetic dataset stands in for the streaming and lakehouse layers. In a full deployment, the same pipeline would read directly from governed Iceberg tables.
Your form submission has failed.
This may have been caused by one of the following:
- Your request timed out
- A plugin/browser extension blocked the submission. If you have an ad blocking plugin please disable it and close this message to reload the page.