In the February 2026 edition: how LinkedIn saved 275,000 GPU hours with full-stack optimization, the JDK 26 initial heap change that could surprise your JVM, and why platform engineering is shifting toward performance. The Optimal is the Akamas newsletter where DevRel Engineer Graziano Casto breaks down Kubernetes performance, reliability, and cost optimization.
Hello everyone! Graziano here.
Hope you survived the last sprint. If you’re reading this, it means your system hasn’t reached thermal throttling yet, or at least, your email client hasn’t.
We’re back with the second edition of The Optimal. We’ve been busy in the lab, so let’s dive straight into the logs.
The Latest Replica
LinkedIn’s AI Stack: A 275,000 GPU-Hour Lesson
If you think your Kubernetes clusters are complex, try managing LinkedIn’s GPU fleet. In this deep dive, they reveal how they saved over 275,000 GPU hours through full-stack optimization.
The “hot take”? Efficiency isn’t just about one layer. They’re optimizing everything from the networking (Infiniband vs. RoCE) to custom “Liger” kernels that fuse GPU operations to reduce overhead. They even use agentic hyperparameter optimization to suggest the most efficient training runs. It’s a masterclass in why “just adding more nodes” is never the answer.
JDK 26: Performance gains and a “Initial Heap” surprise
JDK 26 has officially hit its Release Candidate phase, with the GA locked for March 17. While there’s a lot to love (like G1 GC write barriers dropping from 50 to 12 instructions for a 5-15% throughput boost), there is one change that might break your Slack notifications.
As pointed out in the latest TooMuchCoding Newsletter, JDK 26 is drastically reducing the default initial heap size from 1/64 to 1/500 of RAM.
If you don’t explicitly set your -Xms, your app might suddenly start with a fraction of the memory it used to. Imagine your microservice waking up with only 8MB of heap on a 4GB node: this means your JVM warmup time may increase due to additional GC cycles. You better check your performance and tune it if needed to avoid a bad surprise.
Check the JDK 26 Release Candidates here.
Platform Engineering: It’s time to focus on Performance
Platform engineering has spent years focusing on “Developer Experience” and “Self-Service”. But as this article argues, the next frontier is Performance-Focused Platform Engineering. It’s not enough to give devs a portal to deploy apps; the platform must provide automated guardrails for resiliency and cost. Moving from “Can we deploy?” to “Is it running optimally?” is the shift that separates basic automation from true engineering excellence. This is exactly what we are building with Akamas Insights: a way to embed deep optimization directly into the platform’s DNA.
Commits From The Lab
I want to give you an exclusive look at what our engineers are currently baking. These updates aren’t in the public version yet, but they’re hitting Akamas Insights very soon. Here is what’s coming down the pipe:
Roadmap: HPA-Aware Optimization (Scaling from the Right Foundation)
Most of your critical workloads likely run on HPA or KEDA. But here’s the problem: autoscaling alone doesn’t guarantee performance. If your baseline CPU/Memory requests are misconfigured, HPA simply scales that inefficiency across more replicas. Akamas is bringing native optimization to HPA-governed workloads. We aren’t just “filtering them in” anymore; we are optimizing the foundation. Akamas determines what each pod should look like before scaling begins, aligning CPU, memory, and runtime settings (like JVM/Node.js) with your scaling dynamics.
HPA continues to handle the when, while Akamas ensures the what.
Coming Soon: New Priority Scoring
We are rewriting the way we calculate workload “health”. Previously, Priority was a ratio. A workload could have a critical OOM issue but look “fine” because it passed 19 other minor checks. In the office, we call this the “Polite Killer” paradox: “Sure, he killed a man, but he didn’t steal his wallet or litter, so he’s a good citizen”. Absolutely not.
The worst problem will now drive the entire score. One critical issue = Unhealthy. We’re also weighting cluster scores by cost: a shaky workload on 64 cores will impact your score much more than a tiny 100m pod.
Want to be the first to test these features when they drop?
Get Akamas Insights (Free Trial)!
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
