Belgian Startup Says Server SSDs Can Cut AI Rereading Time
Corbenic AI's Galahad beta saves model memory to local NVMe drives, but its reported 14x speedup owes more to a retrieval component than to storage.
Belgian startup Corbenic AI says it can stop GPUs from rereading documents they have already processed, using the solid-state drives already installed in many servers. According to TechRadar Pro, the company's Galahad beta saves a model's key-value cache, the intermediate memory a language model builds while reading text, to encrypted local NVMe storage. The cache can then be reloaded after GPU memory is cleared or after a server restarts, so the model does not have to process the same text again.
Founder Sietse Schelpe told TechRadar Pro that the approach needs no special hardware. He described the standard NVMe drive in a typical server as sufficient for the job. The publication's reporting, however, notes that the paper describing the work credits most of the reported 14x speedup to a retrieval component called Blaise rather than to loading data from the SSD.
TechRadar Pro also reports that several other systems already save key-value cache to storage. The outlet names LMCache, Nvidia Dynamo, and products from WEKA and Phison as examples. In that context, the company's stated edge is narrower: it offers what it describes as exact, fail-closed reuse of cached results, packaged in one small library.
The available reporting does not give detailed benchmark conditions, pricing, or a release date for Galahad beta beyond its beta status. Readers should treat the 14x figure as the company's result in its own paper rather than an independently verified gain in production.
Background
Large language models process text in stages. When a model reads a prompt, it computes internal representations for each token, and it stores many of these in a structure called the key-value cache. Later tokens can then attend to earlier ones without recomputing everything from scratch. This cache lives in GPU memory, which is fast but limited and expensive. When a session ends, a GPU is reset, or a server restarts, that memory is typically emptied, and the work must be redone.
For long documents, repeated system prompts, or large shared contexts, this rereading can consume a large share of compute time. Engineers have responded with several techniques. Some reuse cache across requests that share a common prefix. Others offload cache to CPU memory or to storage tiers so it survives beyond a single GPU session. Storage offload trades some latency for capacity, because reading from disk is slower than reading from GPU memory, but it can be far faster than recomputing the work.
Solid-state drives using the NVMe interface offer high throughput and low latency compared with older storage, which is why they have become a natural target for this kind of caching. Security also matters here. Cached data reflects the content of user documents, so encrypting it at rest and ensuring that a cache is only reused when it exactly matches the original input are important design concerns. A cache that is reused in the wrong context can leak information or produce incorrect output, which is why the term fail-closed, meaning the system refuses to reuse anything it cannot verify, is relevant here.
Why it matters
The story points to a practical question for anyone running AI systems: how much of the cost of inference is wasted on work that has already been done. If a company serving many requests with overlapping documents can keep that work on hardware it already owns, the savings could be meaningful. Even modest reductions in repeated computation can affect power use, hardware needs, and response times.
The story also shows how crowded this space has become. The reporting names several established projects and vendors that already persist cache to storage, which suggests that the idea itself is no longer novel. A smaller company's argument has to rest on simplicity, correctness guarantees, or ease of adoption rather than on the core concept.
There is a wider lesson about reading performance claims. A headline speedup can come from one component of a system, while the feature in the headline gets less credit. For buyers and engineers, the useful question is which part of the pipeline produced the gain, under what workload, and whether the result holds when the system is deployed rather than benchmarked.
Finally, the security dimension deserves attention. Keeping cached model state encrypted on local drives, and refusing reuse when inputs do not match exactly, addresses real risks. Whether those protections work as described will depend on implementation details that independent testers will need to examine.
What to watch
Watch for independent benchmarks of Galahad that use realistic workloads and report the conditions under which the speedup appears. The distinction between the storage layer and the retrieval component will matter most here.
Look for details on how the company handles encryption keys, cache invalidation, and access control on shared servers. Those choices determine whether the fail-closed claim holds in multi-tenant environments.
Track how competing projects respond, including open-source tools such as LMCache and products from larger infrastructure vendors. Their adoption will show whether storage-backed cache becomes a standard feature or remains a niche option.
Finally, watch for pricing and a general release timeline. A beta label means the design may still change, and early users will be the first to show whether the approach holds up.
Viewpoints
Commentary from our columns: three angles on this story.
The Skeptic open questions and weak points
The headline promises a fourteen-fold gain from an ordinary drive, but the detail that matters sits lower in the story. According to the reporting, the paper credits most of that speedup to a retrieval component, not to loading cache from the SSD. That changes the claim. A reader could easily walk away believing that storage is the breakthrough, when the evidence points elsewhere.
Other questions remain open. The available reporting does not describe the workloads used in the benchmark, the hardware, or how the comparison was set up. Without those details, a number like fourteen times is hard to place. Faster than what, on which prompts, and for how long?
The competitive picture also deserves a hard look. Several established projects already save cache to storage, so the novelty must lie in exactness and simplicity. Those are real virtues, but they are claims to test, not facts to accept. A beta label is a fair reminder that the software is still being shaped. Careful buyers should ask for reproducible results before treating this as a shortcut around expensive memory.
The Builder the engineer's view
From an engineering standpoint, the appeal is easy to understand. Key-value cache is expensive to rebuild, and an NVMe drive already sitting in a server is a resource many teams have idle. Moving that cache out of GPU memory and onto disk, then reloading it after a reset, is a sensible pattern. The hard parts are not glamorous: serialization formats, matching cache entries to exact inputs, and making sure a reload is faster than recomputation.
The fail-closed design is the detail I would examine first. A cache that reuses results when it should not will produce wrong answers quietly, which is worse than a slow answer. A library that refuses to reuse anything it cannot verify is the right instinct. Whether it lives up to that depends on the matching logic and tests, not on the slogan.
I would also want to see the measurements broken down by stage. If the retrieval component drives most of the gain, teams should know that before they redesign their storage. Good engineering starts with an accurate picture of where time goes, and a clear benchmark gives everyone that picture.
The Rulebook privacy, safety and regulation
Any system that stores model cache on disk is holding material derived from user input, and that deserves careful handling. The reported design encrypts cached data at rest, which is a sensible starting point. The real questions are operational. Who holds the keys? How long does cache persist? Can one customer's cached context ever be reached by another?
Fail-closed reuse also has a regulatory dimension. If a cache reuse error exposed content from one session in another, the consequences could fall on the operator, not just the software vendor. Organizations handling sensitive records will need written answers, not marketing language, about deletion, retention, and access logs.
None of this suggests bad intent. It does suggest that the security claims should be verified by independent review before adoption, particularly in regulated settings. Encryption on a local drive is only as strong as the system around it.
===VIEWPOINTS===