Privacy detection in telemetry has two main requirements. The model needs to find sensitive data, and it needs to fit inside a production pipeline. That balance is critical for capabilities like background detection in Cribl Guard, where purpose-built AI models need to detect sensitive data continuously across high-volume telemetry without becoming the bottleneck.
We have written before about why telemetry needs a different kind of privacy model. Sensitive values in telemetry data rarely appear as clean sentences. They hide inside nested fields, serialized payloads, query parameters, and vendor-specific formats. The Cribl Privacy models found in Cribl Guard are custom models trained specifically for that messy, semi-structured data and engineered to run efficiently where telemetry is processed.
With the Cribl Privacy 2.1 model family, we focused on the second part of the problem: making privacy detection much more efficient.
Across the Cribl Privacy 2.1 model family, throughput increased by 64% to 163%, while average memory use fell by 13% to 24%. Overall F1 accuracy held steady or improved, and CPU utilization remained roughly unchanged.
In practical terms, 2.1 can inspect considerably more telemetry using the same CPU allocation and less memory. For production AI workloads processing telemetry at scale, that efficiency matters just as much as model accuracy.
Model quality now includes model economics
2026 has seen a rapid expansion in scaling AI workloads across enterprises, which has meant the economics of running AI are increasingly top of mind for technology leaders.
The leading frontier labs are no longer measuring progress only by which model gets the highest benchmark score. They are also looking at how much useful work a model completes for a given amount of compute. OpenAI describes this as “useful intelligence per dollar” and recently reported lower serving costs and higher token-generation efficiency from changes across its inference stack. Anthropic gives developers effort controls for balancing intelligence, speed, and cost. Google describes its Flash models as points on a cost-to-quality Pareto frontier.
We apply the same principle to AI for streaming telemetry. Our unit of work is how much telemetry a model can inspect, how accurately it can identify sensitive data, and how much CPU and memory it consumes along the way.
There is rarely one model that wins on every dimension. The goal of the Cribl AI Research Lab is not simply to optimize for a single benchmark. It is to move the entire performance frontier forward: better detection quality, higher throughput, and lower resource consumption.
What else changed in Cribl Privacy 2.1
Model pruning / distillation
The most significant change is a new pruning and distillation process that lets us reduce model size while preserving detection quality.
Prune: We score each neuron in the feed-forward layers of the model by how much it contributes to detection accuracy, then keep only the most important ones, often shrinking those layers by 75% or more and dropping the rest.
Distill: That smaller “student” model is then trained against the original frozen “teacher,” learning to match both its internal representations and its final predictions so it can recover nearly the same detection quality while running at a much smaller size and higher throughput.
This is one of the core challenges our AI team works on: not simply making models more accurate, but making them practical to deploy against massive, continuously moving telemetry workloads.
Iterating on customer feedback
Aside from model architecture, we’ve also enriched our training data using feedback from Guard customers. The 2.1 models have an improved understanding of some commonly used log types and telemetry patterns. This feedback loop between production deployments and model development helps us continue improving performance on the data our customers actually encounter.
If you are a Guard user and have data you’d like to share to help improve our models, please reach out!
Evaluation methods
We compared Privacy 2.0 and 2.1 (Base and Fast) under identical conditions on quiet, production-like EC2 hosts so that differences reflect the models, not changes in the underlying machine.
For each model we measured three things: detection quality (precision, recall, F1 on a fixed labeled telemetry set), throughput (how much data the model can process per second under a single-threaded, production-shaped workload), and resource use (CPU and memory during steady-state inference). Throughput numbers discard warmup runs and use the median of repeated timed runs.
Headline results at the primary operating point: throughput rose 64%–163%, average memory fell 13%–24%, F1 held steady or improved, and CPU stayed roughly around one full core. The models are faster because they do more useful work per unit of CPU, not because we gave them more compute.
Absolute rates will vary by hardware; the customer-relevant claim is the relative gain under matched conditions.
Just as importantly, CPU utilization did not scale with the speed improvements in the 2.1 models. The throughput gains come from architectural improvements that allow the models to extract more useful work from roughly the same CPU allocation.
Choosing the right model
There is no single best model for every telemetry pipeline.
Fast is designed for workloads where scanning more data quickly is the priority. Base provides a balance of detection quality, throughput, and memory use. And Pro, coming soon, is being designed for workloads where maximizing detection accuracy is the priority.
Rather than forcing every workload onto one model, the Cribl Privacy family is designed around different points on the accuracy, throughput, and resource-efficiency curve.
Cribl Privacy 2.1 moves those operating points forward, allowing customers to process more telemetry with less memory while maintaining or improving detection quality.
What’s next
So… what’s next? At the Cribl AI Research Lab, we’ve already started work on the next generation of purpose-built telemetry models: Cribl Privacy 3.0.
This new family will include a brand-new member, cribl-privacy-3.0-pro, as well as additional personalization controls that let users tune detections for their environments and use cases. The Pro model will be a larger, more accurate model intended for lower-volume, accuracy-sensitive workloads where deeper detection is worth the additional compute.
There is a lot more work ahead in exploring how model architecture, training data, inference optimization, and customer-specific context can push the performance frontier for telemetry AI even further.
Come join the herd in the lab!
Building AI for telemetry means solving a different class of problems than building models for clean natural-language inputs. We’re working with massive volumes of messy, semi-structured machine data, tight latency and compute constraints, and models that need to perform continuously in real production environments.
Interested in working on purpose-built AI models and inference systems for some of the world’s largest telemetry workloads? If problems like these sound interesting, we'd love to hear from you.
