‘The GPU never reads the same text twice’: Belgian startup Corbenic wants to turn your server’s SSD into AI memory, but its 14x speedup owes more to reading less
Corbenic AI’s Galahad beta saves a model’s KV cache to encrypted local NVMe so servers can skip rereading text after GPU memory is cleared or after a restart Founder Sietse Schelpe tells TechRadar Pro no special hardware is needed, but the paper credits most of the 14x speedup to Blaise, a retrieval component, not SSD loading LMCache, Nvidia Dynamo and CMX, WEKA and Phison already persist KV cache to storage; Galahad’s edge is exact, fail-closed reuse in one small library Belgian startup Corbenic AI says it can stop GPUs from rereading documents they have already processed, and its founder told TechRadar Pro the trick needs nothing more exotic than the NVMe drive already sitting in the server. Galahad, which entered beta on October 1 2026 , saves a model’s key-value (KV) cache, the attention state built while a model reads a prompt, to encrypted local storage and reloads it the next time the same text appears. In an email to TechRadar Pro , Corbenic introduced Galahad with the line "the GPU never reads the same text twice," and founder and CEO Sietse Schelpe summed it up as "the SSD a server already has becomes part of the AI’s working memory." Catering to a market with plenty of alternatives in tow The timing of Corbenic’s announcement is impeccable; with data centers on course to absorb more than 70% of high-end memory chips in 2026 , getting more work out of existing hardware is an easy sell. But Corbenic’s own paper shows its headline 14x speedup owes more to reading less text than to loading saved work, and the company is walking into a field where Nvidia, Phison, and a well-funded open source project already offer something similar. Galahad’s approach is slightly different: In standard serving, a model answering a second question about a document recomputes that document’s attention state from the first token, a step called prefill. Engines such as vLLM and SGLang already reuse that state while it sits in GPU memory, but Corbenic’s paper notes it is evicted under memory pressure and lost whenever the process restarts. Galahad’s KV component, Taliesin, writes each block of text’s state to disk under a fingerprint of the exact input bytes, the model, and the tenant, then loads it when those bytes reappear. Schelpe stressed that the stored copy only comes into play once GPU memory has been cleared or the server has restarted. "So the choice is not SSD or RAM. It is SSD or computing it all again on the GPU," he told TechRadar Pro, adding that the load "happens once, before the first word of the answer." He volunteered two limits: short texts are not stored because recomputing them is already fast, and network storage is much slower than a local NVMe drive. The paper sets a fail-closed rule on top: "serve without memory, never with wrong memory ," so any record that fails a check is simply recomputed. No special hardware is required, according to Schelpe, just Linux, an Nvidia GPU and a standard NVMe SSD. Asked about CXL, he said, "we tried faster storage, and it didn’t make Galahad faster," which matches the paper’s H100 test, where a RAM disk and a local disk delivered near-identical throughput. On enterprise drives such as Phison’s Pascari line, whose maker has been pitching flash as the answer to AI’s memory bottleneck , he was refreshingly careful: "we haven’t measured them, so I won’t quote numbers." Schelpe told TechRadar Pro that loading stored state from a fast SSD "is much quicker" than rereading, and that "is where our 14× comes from: 0. 59 seconds per question on vLLM." The paper’s own tables tell a more complicated story. The 0. 59-second result comes from a recall test with 100 facts hidden in a 96,726-token list, run on Gemma 4 31B, and it used Taliesin plus Blaise. Blaise is a second component that keeps the documents as text and hands the model only the section a question needs, about 668 tokens instead of the whole corpus. The paper itself credits Blaise with lifting the gain on llama. cpp from 3. 1x to 14. 5x. With Taliesin alone, vLLM took 15. 56 seconds per question, slower than its 8. 11-second baseline, and SGLang took 22. 02 seconds against 10. 29. Only llama. cpp got faster on KV reuse alone, at 3. 01 seconds against 9. 25. Those comparisons are lopsided in both directions: the baseline used a 12,000-token window that saw only the last 12% of the corpus and answered 10 of 100 questions, while Taliesin let the model attend to everything and answered 98 of 100…