Serverless computing and high-performance computing started from opposite assumptions about what a workload looks like. Function-as-a-Service platforms were built for short, stateless, independently triggered invocations — a request comes in, a function runs for a few hundred milliseconds, state goes back to external storage, the instance may vanish. HPC and AI training workloads are the reverse: long-running, tightly coupled, state-heavy, and often intolerant of the cold-start latency and communication overhead that FaaS platforms treat as acceptable tradeoffs for their core web-backend use case. A January 2026 systematic literature review puts a number on how much research has gone into closing that gap, and the number is 122 papers.
What the Review Actually Covers
“High-Performance Serverless Computing: A Systematic Literature Review on Serverless for HPC, AI, and Big Data,” posted to arXiv in January 2026 by Valerio Besozzi, Matteo Della Bartola, Patrizio Dazzi, and Marco Danelutto, works through 122 research articles published between 2018 and early 2025. That range matters: 2018 is roughly when FaaS platforms had matured enough for researchers to start seriously asking whether they could carry compute-intensive workloads at all, and early 2025 is recent enough to capture the current wave of serverless-for-AI-training proposals. The review’s own artifact repository describes its scope as covering “architectural trends, workloads, optimization techniques, and benchmarking practices” across the corpus, organized into an eight-category taxonomy spanning nine distinct use-case domains, with an accompanying trend and collaboration analysis showing how the research community around this question has grown.
The motivating premise is a convergence that is visible outside the literature too: cloud providers are folding HPC-grade capability — hardware accelerators, high-speed interconnects — directly into their standard infrastructure, while the HPC community is separately experimenting with cloud-native operational patterns to get better elasticity and utilization out of expensive accelerator fleets. Serverless sits at the intersection of both trends, which is exactly why a field that started as a niche question eight years ago now has enough published work to warrant a systematic review rather than an individual survey paper.
Why the Fit Was Never Obvious
The core mismatch a reviewer of this literature has to keep track of is state. A FaaS invocation is designed to be disposable — no guaranteed persistent memory between calls, no guaranteed placement on the same physical node twice, no cheap way to keep large in-memory datasets warm across a burst of invocations. HPC and distributed-training workloads depend on exactly the opposite: an MPI collective operation, a distributed gradient reduction, or a checkpoint-restart cycle all assume some degree of addressable, coordinated state across a known set of workers. Cold-start latency compounds this. A function platform that takes hundreds of milliseconds to spin up a fresh execution environment is a rounding error for a web request and a serious tax on a workload where thousands of short-lived function invocations coordinate in a tight loop.
This is the part of the literature this site’s own coverage has approached before from the container-orchestration side — the WebAssembly-at-the-edge piece covered a related bet that a lighter-weight execution unit than a container could solve some of the same cold-start and density problems that FaaS platforms face for HPC workloads, from a different angle. The instinct in both cases is the same: shrink the unit of scheduling until spinning up a fresh instance stops being expensive enough to matter, rather than trying to make the existing unit cheaper to keep warm.
An Active Field, Not a Settled One
What the review’s own framing signals, more than any single finding, is that this remains an open research question rather than a solved engineering problem. The authors describe serverless as “a promising execution model” for compute-intensive applications and frame their contribution as guidance for “the development of next-generation serverless solutions for parallel compute-intensive applications” — language that positions the 122-paper corpus as evidence of a field still working out its fundamentals, not one converging on a standard architecture. That framing is consistent with what shows up on the ground: production serverless-for-HPC deployments remain the exception, typically built around specific accelerator-aware runtimes or bespoke orchestration layers rather than off-the-shelf FaaS products, precisely because the state-management and cold-start problems the review catalogs have not been generically solved.
The scale of the research effort — eight years, 122 papers, an eight-category taxonomy needed just to organize the findings — is itself informative. A research area this active, this recently, on a problem this fundamental to distributed systems, is a reasonable signal that the underlying tension between “disposable execution unit” and “coordinated long-running computation” is not going to resolve through incremental platform tweaks. It is more likely to produce a distinct architectural pattern purpose-built for compute-intensive serverless, rather than today’s web-backend FaaS model simply absorbing HPC as one more workload type.
What This Means for Anyone Evaluating FaaS for Compute-Intensive Work
The practical reading for infrastructure teams weighing serverless against traditional cluster scheduling for AI or HPC workloads is not “wait until it matures” — the review makes clear this has been an active research question for eight years with no single dominant solution emerging. It is closer to: treat any serverless-for-HPC claim from a vendor or a paper as workload-specific until proven otherwise. The state-management strategy that works for a stateless inference endpoint will not automatically extend to a training job with tightly coupled collective communication, and a platform’s marketing claim of “serverless-native AI training” is worth checking against which of the review’s underlying problems — cold starts, state externalization, communication topology — it actually addresses versus routes around.
The review’s own bibliography is a reasonable starting point for that diligence. A corpus organized across an eight-category taxonomy and nine separate use-case domains is granular enough to locate the specific subset of prior work closest to a given deployment’s actual bottleneck, rather than treating “serverless for HPC” as a single research question with a single answer.