At the 70th edition of The IT Press Tour in Palo Alto, Hammerspace laid out new customer wins, a plain-spoken case against copy-and-migrate AI storage, and a teaser for a batch of announcements coming at Supercomputing in November.
If you walked into Hammerspace’s session at the 70th IT Press Tour expecting a polished pitch about yet another “AI storage” box, you walked into the wrong room. Floyd Christofferson, the company’s VP of Product Marketing, spent his time explaining the opposite: that the last thing most enterprises need is a new pile of storage. What they need, he said, is to stop copying data around long enough to put the data they already own to work.
And he came with receipts. Christofferson walked us through a planned ~30 PB Hammerspace deployment in AWS at a major hyperscale AI research lab, a European healthcare AI project headed from 128 GPUs to more than 1,000, a 144-node GPU cluster on Oracle Cloud Infrastructure (OCI) for a global communications company, and a university that cut storage costs by roughly 48% by reclaiming NVMe it didn’t realize it was wasting. He also made it clear that more is on the way: Hammerspace will be in attendance at SC26, the Supercomputing event taking place in Chicago this November.
The 70 Percent Problem Nobody Puts on a Slide
Christofferson opened with a story from the Storage Developers Conference in Santa Clara the week before. The CTO of the Berkshire Hathaway companies, he said, told the room something most vendors avoid saying out loud: in the enterprise, roughly 70% of AI projects fail. Not at the proof of concept. Those go great, because the data is curated, the scope is small, and everyone is in a good mood. They fail on the way to production.
Why? He gave three reasons, and anyone reading this who has run a data center will nod along. Companies can’t justify the cost of duplicating infrastructure. They can’t stomach the risk and complexity of migrating or copying data. And they have existing operations that can’t be interrupted just because someone in the business wants to try an agent.
That CTO, by his account, also delivered a lecture to the vendors in the audience: don’t bring me a net new storage system for AI when I have a business to run and you can’t tell me the return on investment.
Here’s the thing: the industry’s default answer is exactly that. Buy a shiny AI-specific platform, copy the data you want to expose, and you’re good. Christofferson ran through what that does to data sovereignty, to cost, and to the investments already made in existing storage. His presentation put it more bluntly: AI isn’t compute-constrained, it’s data-constrained.
The File System Is the Trap
To understand what Hammerspace does differently, you have to accept a premise that sounds almost too simple. When you buy storage, you are also buying a file system, and that file system is welded to the hardware. Fill it up and you get a second one, then a third, then ten. Add a cloud region and you’ve got another. The industry has spent thirty years building tiering tools, hierarchical storage managers, gateways, and migration utilities to paper over that one fact.
Hammerspace’s answer is to lift the file system out of the infrastructure entirely. Users and applications see one orchestrated global namespace through NFS, SMB, S3, or a CSI driver for containers, while the data underneath sits wherever it makes sense on whatever storage is already in place. Nothing gets installed on the storage itself, and no agents run on it.
Standard Linux, no special client
This is where Hammerspace’s story gets technical, and where I think it gets interesting. For roughly eight or nine years, the company has been pushing parallel file system capabilities into the mainline Linux kernel: NFSv4.2 with Flex Files (going back to 2019), attribute delegations, fast failover, LOCALIO, NFS Direct, and more. Christofferson noted that Hammerspace’s CTO is the Linux NFS client kernel maintainer, and that other maintainers are on staff as well.
The payoff is a line he delivered with a notable smile on his face: Hammerspace’s client “is already installed in every data center on the planet.” It’s a little tongue-in-cheek, but the point is real. Any standard Linux distribution already has the pieces, so there’s nothing proprietary to roll out to GPU servers, whether they sit in your data center, a neocloud, or a hyperscaler.
He was also honest about the hard parts. The pNFS N-to-1 capability, the thing classic HPC needs when hundreds of thousands of cores write to a single file, has to go through the IETF and the Linux community. “Like trying to solve peace in the Middle East,” he said. AI workloads, by contrast, lean on many-to-many access, which the current kernel work already handles.
Anvil, DSX, and data that moves while you’re using it
Architecturally, there are two pieces in one software load. The Anvil metadata servers hold the file system metadata, essentially the brains. The DSX (data services) nodes present protocol access, move data, and can even act as data stores. Because the metadata is separate from the data, applications talk to the metadata server and then read in parallel.
Because Hammerspace is the file system, data can move between storage systems, from slow to fast, or from one site to another, while users are working with it. Christofferson pointed to live data mobility, a capability the company introduced into pNFS. A policy engine (Hammerspace calls the policies “objectives,” a desired state rather than a script) decides where each file’s actual contents live, based on performance, cost, or protection level.
“We’re a new file system, but migrations go away. The migration for Hammerspace is changing a mount point.”
— Floyd Christofferson
That migration claim is the one I’d poke at in a trial, and it’s the one the customer stories lean on.
Tier 0: The Storage You Already Paid For
If one idea carried the afternoon, it was Tier 0. Every GPU server ships with local NVMe. In NVIDIA’s terminology that’s G3. On a single node it’s fine. Across a hundred or a thousand nodes, it’s a scattering of isolated pockets that are unshared, largely unprotected, and mostly idle. As NVMe densities grow, that means a growing pile of stranded capacity.
Hammerspace’s approach is to fold that local NVMe into the same global namespace as every other tier and manage it with policy. Christofferson’s math on speed was straightforward: local NVMe is about 2.5 times faster than a 400 Gb network, and in the cloud, where network bandwidth is far more modest, the comparison slide showed networked options running from about 10x to as much as 62x slower than local access. On top of that, you already own the media. His observation was that filling the empty NVMe slots in an off-the-shelf GPU server costs less than buying external networked flash and upgrading the network to feed it.
Vanderbilt University: 10 petabytes nobody knew they had
Vanderbilt’s ACCRE facility is the cleanest example. It supports around 2,750 researchers across nine schools and colleges and some 350 campus departments, runs a 750-node compute cluster with 80 GPU nodes, and was juggling roughly 40 PB across multiple systems. The university had a budget problem and a goal: cut storage costs and move to a more composable model built on commodity hardware.
Hammerspace came in and unified the lot. The result was a roughly 10 PB cluster that includes Tier 0 storage built from GPU-server NVMe, 500 TB of Tier 1, and petabytes of archive, all under one namespace with automated orchestration. Christofferson said the team reclaimed close to 10 PB of local NVMe, so the Tier 1 SSDs they’d planned to buy never got bought. Storage costs dropped by about 48%.
What I liked most was the less obvious win. Researchers on grant-funded projects can now be provisioned storage that fits their work without anyone touching the underlying infrastructure or disturbing other users.
A global communications company on OCI
A similar pattern played out at a global communications technology company. It needed to push on-premises data into Oracle Cloud to reach GPUs there. The deployment is a 2 PB Hammerspace cluster with two Anvil metadata servers and six DSX nodes, with Tier 0 across a 144-node GPU cluster. Data is processed on Tier 0, checkpoints flow down to OCI Object Storage for long-term retention, and applications talk NFSv4.2 pNFS as well as NFSv3. His summary: fastest time-to-value, and lower cost because the customer didn’t have to buy as much high-performance capacity inside OCI.
More Receipts: Cloud Labs, Neoclouds, and a Glacier Escape
The remaining examples show how far the same architecture stretches. I’ve kept some details light because a few of these customers aren’t being named yet.
A hyperscale AI research lab leaves Lustre behind
This one is the headliner for anyone who runs GPU clouds. The lab had ongoing operational headaches with Amazon FSx for Lustre and needed to move workloads between on-premises and multiple clouds. Its researchers also prefer NFS to S3. The plan is roughly 30 PB across multiple Hammerspace clusters in AWS, with an extension into the customer’s own data center, creating a “data fabric” across public cloud and on-prem.
Christofferson said Hammerspace beat FSx for Lustre in a head-to-head test. In the AWS pilot, checkpoint loads ran 36% faster and large-file operations ran 3x faster. Hammerspace’s S3 connector presents an NFS mount point to users over object storage in the cloud, so the researchers never see the plumbing, and they can shift workloads across GPUs and even clouds without noticing.
A three-site neocloud and a life sciences escape from Glacier
A neocloud offering inference-as-a-service needed a three-site global namespace for a client. Each site gets two metadata servers and two DSX nodes, inference clusters mount Hammerspace over NFS in each region, and data moves between sites through a shared object bucket. Metadata sync is asynchronous but lands within seconds, which means a colleague in Croatia, Singapore, or Los Angeles sees the same file system.
Then there’s a US life sciences research organization serving researchers across 26 labs. It had 5 PB of aging PowerScale and 2 PB in AWS Glacier, with archive retrievals taking 12 hours or more. With Hammerspace, the organization is shifting its data toward Glacier Instant Retrieval, staging it by policy instead of by hand, and retiring the old storage without taking anyone offline.
The Three Clocks of AI Economics
Christofferson’s most memorable framing was what Hammerspace calls the three clocks of AI economics. Everyone in the industry talks about time to first token. He argued that’s the wrong clock to start with, because getting a proof of concept to answer quickly is a very different problem than keeping a production pipeline fed.
- Time to Very First Token. How long until the AI environment is ready at all? Traditional routes mean buying new storage (3 to 6+ months), deploying proprietary clients, and finishing bulk migration before anyone can use anything. Hammerspace’s pitch is to assimilate existing data in place, with standard clients and zero migration. The company claims over a 10x reduction in time to AI-ready data compared with siloed AI storage.
- Time to First Token. Once a request lands, how long does it wait for data? Policy-driven placement stages data ahead of demand, and parallel access speeds reads when the workload needs them.
- Time per Token. While the pipeline runs, are the GPUs fed? This is where Tier 0 and orchestration earn their keep.
That third clock is where the numbers get uncomfortable. Hammerspace’s slides put average GPU usage today at around 18%, against 87% with intelligent orchestration, and claim that every 10% improvement is the equivalent of 10,000 GPUs’ worth of value. Those are the company’s figures and your mileage will vary. Christofferson’s own version was simpler: if your GPU is 30% busy, 70% of your investment is burning a hole in your wallet.
“The AI race won’t be won by the company with the most GPUs. It will be won by the company with the fewest idle GPUs.”
— Hammerspace
“It’s Not a New Layer,” and Other Fair Questions
The IT Press Tour crowd is not shy, and a few of the exchanges were worth the price of admission.
One journalist pushed on the obvious objection: aren’t you just adding another layer to my infrastructure? Christofferson’s answer was one of the better ones I’ve heard. Yes, it’s a file system, and a new one. But customers already pass through multiple file systems today, plus a stack of point tools for migration, tiering, and gateways, plus a human running scripts overnight. Hammerspace consolidates all of that into one automated layer.
“Sure, it’s a layer, but it’s not a new layer. It’s replacing a manual, complex existing layer that was already there.”
— Floyd Christofferson
The question of protection came up too. Hammerspace isn’t a backup product, a migration tool, or a cloud gateway, he said, but it does all of those jobs as a side effect of managing data. Policies can require, for instance, that data carrying a certain metadata tag be protected to nine nines, automatically replicated, and audited. Global snapshots across NetApp, Isilon, and object storage can be stored wherever is cheapest. “We’re not storage, but we do storage things,” he said. “We’re not data management, but we do data management things.”
Then there’s the supply crunch. With SSDs and memory pricey and hard to get, customers are rediscovering hybrid HDD and SSD designs. Christofferson’s line: tiering is back, “except it’s not tiering like your grandpa’s tiering. It’s active data orchestration.”
On competition, he was relaxed about recent moves by NetApp into parallel NFS. If anything, he said, it validates pNFS as the parallel file system for AI, since the client is already in the kernel. NetApp has offered pNFS since 2011, but with NFSv4.1 rather than v4.2 with Flex Files, and he argued that a client capability alone isn’t the point. Orchestration, multi-site data services, and native protocol bridging all have to be engineered into the platform. His claim: Hammerspace has a 10-year engineering head start and five or six years of shipping products. (That’s Hammerspace’s view, of course, and I’d expect the competition to disagree.) He also mentioned that Los Alamos’ Gary Grider has been looking at pNFS with Hammerspace orchestration to reduce dependency on Lustre.
Why This Briefing Stuck With Me
Christofferson has been wrestling with the same problem for decades: a post-production facility in New York running SGI machines, then Pathfire, where he built a system that beamed syndicated TV content by satellite to a thousand stations, then SGI itself. Different decade, same headache: data trapped in silos, humans moving it by hand. His take is that AI finally makes the headache too expensive to ignore, because nobody is going to duplicate an entire IT estate to run one application.
He is also candid that Hammerspace didn’t predict AI. The company simply spent nearly a decade building a standards-based, orchestrated file system, and then the market arrived at its door. Hammerspace did work on training with Meta’s Llama 2 and Llama 3 efforts, but the pitch now is aimed at the harder, less glamorous problem: inference and agentic workflows running on the messy enterprise data that already exists, including 40-year-old seismic archives. One engineer at a hyperscale customer reportedly called the technology “black voodoo magic.” Christofferson’s reply: there’s science behind it.
If you run infrastructure for AI, here’s my advice. Keep an eye out for Hammerspace around SC26. They have a few announcements that will be released around the event. Christofferson hinted that the next layer is about connecting to AI pipelines and making deployment simpler. In the meantime, ask yourself a blunt question about your own environment: how much NVMe is sitting idle in your GPU servers, how many copies of your data exist, and how many months stand between your first pilot and production? If the answers make you wince, Hammerspace is worth a call.
##
