In the September 2026 edition: why Europe’s shift to distributed cloud hides an efficiency bill, how to produce the world’s cheapest inference tokens, and what the CPU shortage means for software teams – plus Akamas Insights becomes Vivo and Offline Optimization becomes Studio. The Optimal is the Akamas newsletter where DevRel Engineer Graziano Casto breaks down Kubernetes performance, reliability, and cost optimization.
Hello everyone! Graziano here.
If you’re reading this, we are officially wrapping up September 2026 and conference season is warming up. We’ve been busy optimizing clusters in the lab (and renaming a couple of things, more on that below). Quick health check before we start: if your cluster’s average CPU utilization is lower than your phone battery at 6 p.m., you’ll probably have to change something. Grab a coffee and let’s look at the logs for this month.
The Latest Replica
Everybody in Europe Is Going Distributed. Almost Nobody Is Reading the Invoice.
Full disclosure: this one is by our CEO, Luca Forni, so discount our enthusiasm accordingly. Most talk about Europe’s shift to distributed and sovereign cloud centers on compliance and resilience. Luca asks what happens to efficiency, and his answer is the “copy-paste multiplier.” The same app, configured once years ago, gets deployed to five environments with different hardware, while the Helm chart carries identical settings everywhere. A harmless CPU limit starts throttling, and a connection pool that was fine at 2 ms of database latency chokes at 8 ms. Smaller sovereign catalogs also make “just add hardware” harder, so the workload has to fit the infrastructure. And tuning by hand doesn’t scale: 20 parameters with 5 values each is already about 95 trillion configurations. The takeaway: measure cost per transaction, not CPU utilization, and make performance targets part of the deployment.
Producing the World’s Cheapest Tokens
In this QCon San Francisco talk, Meryem Arik argues that most companies overpay for inference by 2x to 5x because their stack doesn’t match what the use case actually needs. For work that can wait (overnight agents, data labeling, bulk summarization), the levers are unglamorous. Push batch sizes as high as they’ll go. Move to newer GPUs if you can keep them busy: an H100 to B200 move cut cost by about 75% at similar latency in the benchmark she cites. And stop provisioning for peak when a queue will do, which took her example from roughly 8 GPUs to 2. One deep-research workload went from roughly 350K a year at real-time API prices to around 13K on a stack built for batch. The takeaway is one we repeat a lot: there is no universally “right” configuration, only the right one for the workload in front of you. Defaults tuned for someone else’s latency target are expensive.
What the CPU Shortage Means for Software Teams
For most of the cloud-native era, CPU was the resource you never had to plan for: you just autoscaled into more of it. Katelyn Lesse makes the case that this era is over. Server orders are now quoted at around six months instead of a week or two, and prices are up roughly 10 to 20% since March. Agents are a big reason why, since everything around inference (harness loops, tool calls, sandboxes, CI builds) runs on CPUs. Intel has said AI-forward data centers moved from about one CPU per eight GPUs to one per four. The line that should make every platform team wince: average Kubernetes CPU utilization is reportedly around 10%, because headroom gets planned for estimated peaks and rarely revisited. When new cores take six months to arrive, the fastest capacity you can add is the capacity you’re already paying for and not using.
Commits From The Lab
All three pieces above land on the same idea: a configuration that made sense once, somewhere else, is rarely the right one for the workload and infrastructure you have today. Closing that gap is what our products do, and starting this month they have new names.
Akamas Insights is now Akamas Vivo. Vivo is continuous, full-stack Kubernetes optimization for live production. It reads the metrics your observability stack already collects from Prometheus, Dynatrace or Datadog, with no agents and no code changes. It then recommends pod requests and limits, JVM, Node.js and .NET runtime settings, HPA and KEDA settings, and node groups and instance types as one set of changes. You review and apply them, or automate with guardrails through GitOps.
Akamas Offline Optimization is now Akamas Studio. Studio is where you tune before you ship. It drives your existing load-testing tools and scores each run against the goals and constraints you set, such as maximizing throughput while holding latency under a hard SLO. It then uses reinforcement learning to choose the next full-stack configuration to try.
Same products, new names, and the names are a hint: Vivo works on what’s live, Studio is where you rehearse. Old links redirect, so nothing you’ve bookmarked breaks.
Try Akamas Vivo (Free Trial) to see how much of your cluster is sitting idle.
The Diff
Numbers beat opinions, so here’s what the first 12 days of data looked like on a live proof of concept. This one is still in progress, so treat the savings below as estimates, not results. We’ll report the measured before and after once tuning lands.
A large European consumer marketplace on AWS: 2,120 cores allocated, 263 actually used.
The team runs a dozen production Kubernetes clusters and already had an optimization approach in place. The PoC started with one cluster of about 1,600 workloads, and the 12-day baseline put average CPU utilization at 12%. The gap sits in two layers. At the workload layer, pods requested 1,398 cores on average and used 263, across a mixed Java and .NET estate where runtime settings shape what a pod really needs. At the cluster layer, nodes provided 2,120 cores against those 1,398 requested, headroom that Karpenter could be tuned to reclaim. A third finding was about speed: on the default node pool, the best price-performance instance type scored about 2.1x the current one on a performance index. It costs roughly 60% more per month in raw terms, but about 23% less once adjusted for performance.
Akamas Vivo’s baseline estimate for that one cluster is up to about $23.5K a month from workload rightsizing and about $9K a month at the node-pool level. That adds up to roughly $410K a year before any cloud discounts. It also flagged 523 of 1,587 workloads as running under stress, and those get tuned for reliability, not just trimmed. The takeaway: an existing optimization setup doesn’t mean an optimized cluster, and the savings only show up when you fix workloads and nodes together.
Catch Us
Want to meet the Akamas team in person? We’re regularly at conferences and meetups across the Kubernetes and Java ecosystems. See where we’ll be next on our Events page, and follow me on LinkedIn for the talks and sessions I’ll be at.
Keep those CPUs cool and your latencies low.
Stay optimized,
Graziano Casto, DevRel @ Akamas
