Summary

  • San Diego Supercomputer Center's Expanse user guide states that the system delivers 5.16 peak petaflops, but names no benchmark, numeric precision, measurement date or workload class for that figure, and does not attribute it to any single partition.
  • The same guide caps a principal investigator's Expanse allocation at 15 million core-hours and 75,000 GPU-hours, and allows Science Gateways requesting in the Maximize tier to ask for up to 30 million core-hours — a ceiling on what may be requested, not a record of what anyone received.
  • The AI-specific hardware appears separately from the headline: 34 Dell XE9640 servers carrying NVIDIA H100 GPUs on partitions named nairr-gpu, listed alongside 728 standard AMD EPYC nodes and 52 NVIDIA V100 GPU nodes. Nothing on the retrieved page ties 5.16 petaflops to those 34 servers.
  • Voyager, the Habana-based system, is documented as an NSF-funded testbed that began a three-year phase in early 2022, open to select focused projects, with allocation handled by contacting HPC consulting and scheduling by Kubernetes. Its page states no peak floating-point figure at all.
  • Four documents that would close the loop were not obtained: the NSF award record was blocked, the ACCESS allocation-tier policy was not retrieved, no independent sustained-performance result was found, and the TOP500 address that surfaced in search resolves to an Inspur NF5468M5 cluster rather than to Expanse.

Two numbers that are not the same number

The sentence that travels is short. Expanse, the San Diego Supercomputer Center's ACCESS cluster, is described in the centre's own user guide as "designed by Dell and SDSC delivering 5.16 peak petaflops" (SDSC Expanse User Guide). It is the kind of line that ends up in a slide, a funding summary, a university press release and a journalist's second paragraph, and it is accurate as far as it goes.

What does not travel is the sentence two sections further down the same page: the maximum allocation for a principal investigator on Expanse is 15 million core-hours and 75,000 GPU-hours, and Science Gateways requesting in the Maximize tier can request up to 30 million core-hours. Those two statements are not in tension. They are answers to different questions. The first describes the machine's installed capability as its operator characterises it. The second describes how much of the machine any one researcher is permitted to ask for.

Between them sits a third quantity that neither statement addresses, and that no document retrieved for this article supplies: how much of that peak a real workload actually sustains. A peak figure and an hour ceiling cannot be converted into one another, and neither converts into delivered throughput without data that the accessible public record does not contain. The gap between them is not a scandal. It is a documentation structure, and it has consequences for anyone planning research capacity off the headline.

What the Expanse page actually says

The guide describes Expanse as a dedicated cluster in the Advanced Cyberinfrastructure Coordination Ecosystem: Services and Support — ACCESS — designed by Dell and SDSC, and states that it is an NSF-funded system operated by the San Diego Supercomputer Center at UC San Diego, available through the ACCESS programme. It gives job scheduling as SLURM.

On hardware, the page's inventory is specific in a way that repays reading rather than skimming. Expanse's standard capacity is given as 728 nodes with AMD EPYC processors, and its GPU capacity as 52 nodes with NVIDIA V100 cards. Separately — as its own item, not folded into that inventory — the page describes an Expanse AI resource of 34 Dell XE9640 servers with NVIDIA H100 GPUs, available through partitions named nairr-gpu.

That separation matters more than it might appear. The 5.16 petaflops figure is a system-level statement about Expanse. The 34 H100 servers are a distinct, later-described resource. The retrieved page does not say that the headline figure measures those servers, does not give a partition-level peak for them, and does not restate the headline as an AI-training number. Anyone who quotes 5.16 petaflops as "SDSC's AI capacity" has performed a substitution the source does not authorise.

The correct reading is narrower and less quotable: the centre operates a large CPU-and-V100 system whose peak it states, plus a much smaller H100 resource it describes in unit terms only.

This is worth stating precisely because the substitution is so easy to make and so hard to detect afterwards. A reader who encounters "34 H100 servers" and "5.16 petaflops" in the same document will tend to bind them together. The document does not bind them. It lists them in different places, at different levels of abstraction, with different units — servers on one hand, a floating-point rate on the other — and leaves the relationship unstated.

Voyager: a configuration with no peak, behind a gate

The centre's other AI-relevant system has the opposite documentation problem. Voyager's user guide describes it as an NSF-funded system developed in collaboration with Supermicro and Intel's Habana Lab, operated by the San Diego Supercomputer Center at UC San Diego, which began a three-year testbed phase in early 2022 (SDSC Voyager User Guide). Its configuration is given as 42 Supermicro X12 Gaudi training nodes carrying 336 Habana Gaudi training processors, plus two nodes carrying 16 first-generation Habana inference processors. Scheduling is by Kubernetes.

The page states no peak floating-point figure for Voyager at all. So the two systems fail in complementary directions: one publishes a peak with no sustained counterpart, the other publishes a configuration with no peak. Neither page closes the loop, and a reader trying to compare them is left holding two different kinds of number.

Voyager's access model is stated plainly, and it is the more consequential disclosure on the page. Under the heading Resource Allocation Policies, the guide lists the current status as Testbed Phase. The three-year testbed phase, it says, will be available to select focused projects, as well as workshops and industry interactions. It adds that the testbed phase will be followed by a two-year allocation phase to the broader NSF community and user workshops. During the testbed, the page directs enquirers to contact HPC consulting at SDSC.

That is a gate, described without euphemism. It is not a published competition with stated criteria, a review panel, a decision timeline or a success rate. It is an institutional routing of requests to staff, for a phase explicitly limited to selected projects. There is nothing improper about a testbed operating this way — a testbed exists to serve focused collaborations, and its operators need discretion to do that. But the practical consequence for an outside researcher is that the binding constraint is not queue position. It is whether the request is considered at all.

The two-year broader allocation phase is described as a following step. No document retrieved for this article establishes that the transition has occurred. It may well have; the retrieved page simply does not say so, and treating a stated plan as a completed fact is precisely the kind of drift this article is about.

Why an hour ceiling and a petaflop figure cannot be converted

It is tempting to try to make the numbers speak to each other. If a principal investigator may request 75,000 GPU-hours, and the system has a stated peak, then surely one can compute something about the researcher's share of the machine. One cannot, and the reasons are worth setting out because the same reasoning applies to every academic AI system documented this way.

A peak floating-point rate is an instantaneous property. It describes a rate at which the hardware can, under the supplier's stated assumptions, perform arithmetic. It says nothing about duration. An allocation ceiling is the opposite: it is a quantity of time-integrated resource, expressed in core-hours or GPU-hours, with no rate attached. To turn one into the other you would need to know the partition the hours are drawn from, its per-unit peak, the duration over which the hours are consumed, and the workload's achieved efficiency on that partition.

Three of those four are absent from the retrieved documentation, and the fourth — achieved efficiency — is the one that measurement exists to supply.

The gap is not academic pedantry. A researcher planning a training run needs to know how long a job will take on the hardware they can actually get, not how fast the hardware would go if the workload were perfectly efficient and the allocation unlimited. The two questions differ by a factor that only a sustained measurement can pin down. When the accessible record contains a peak and a ceiling but no measurement, the researcher is left to guess the factor, and guessing it optimistically is the natural error.

There is a second, subtler conversion error available here. A core-hour and a GPU-hour are different currencies, and the guide's ceiling states both without offering an exchange rate. Fifteen million core-hours and 75,000 GPU-hours are not two ways of saying the same thing; they are two separate budgets for two different kinds of node. A project that needs GPU time cannot spend its CPU budget instead. Reading the ceiling as a single pool of "compute" would overstate what any one project can draw on either side.

The four doors that stayed shut

An honest account of what this article can establish has to include what it could not. Four documents would have closed the loop, and all four were unavailable in this retrieval.

The first is the funder's own record. The NSF award page associated with Expanse returned no text: access was blocked (NSF Award Search record 1928224). That single failure removes a whole class of claims from the table. No obligated amount, no performance period, no award-specific statement of purpose, no deliverable list, no reporting obligation and no compliance finding can be asserted here. The correct formulation is that the award terms were not verified. It is emphatically not that no award exists — the centre's own guide states the system is NSF-funded, and the ACCESS portal names the Office of Advanced Cyberinfrastructure awards under which the programme operates (ACCESS Allocations portal). A blocked page is a fact about retrieval, not about funding.

The second is the allocation policy. The ACCESS portal returned its funding acknowledgement and a statement that it provides allocations at no cost to researchers, but not the tier thresholds or the review procedure. A second ACCESS address was unreachable. So the distance between the 30-million-core-hour request ceiling and an actual award is unquantified here. Tier names appear in the Expanse guide — the Maximize tier is named in the Science Gateway sentence — but the rules that govern entry to a tier were not obtained, and mapping a named tier to a stated ceiling would be inference dressed as quotation.

The third is any independent measured sustained result. None was obtained for Expanse or for Voyager. This is the most important of the four, because it is the one that would convert the article from an observation about documentation into a measurement of performance. Its absence means the size of any peak-to-delivered gap remains unmeasured rather than merely unstated — a distinction that matters, since an unmeasured gap is not evidence of a large one.

The fourth is a benchmark record, and it failed in an instructive way. A TOP500 system address surfaced during retrieval. It resolves not to Expanse but to an Inspur NF5468M5 cluster with Xeon Gold 6230 processors and NVIDIA Tesla V100 cards (TOP500 system record 179831). A plausible-looking measurement record, retrieved in response to a query about a different machine, describing a different machine.

The benchmark that belonged to another machine

That last failure deserves its own section, because it is a small demonstration of the article's own thesis.

The sequence is mundane and entirely typical. A search for sustained performance data returns a system record from a benchmarking list. The record contains exactly the fields one wants: a system name, a processor description, a vendor, an interconnect. Everything about its shape says "measurement". Only the identity is wrong. A writer in a hurry, holding a query about Expanse and a page full of LINPACK-adjacent fields, could attach a real sustained figure to the wrong supercomputer and never notice.

Had that happened here, the resulting article would have been more satisfying and less true. It would have had a number on both sides of the comparison — a peak of 5.16 petaflops and a sustained result from a list — and the ratio between them would have looked like analysis. It would instead have been an artefact of retrieval, in which two unrelated machines were silently merged into one claim.

The general lesson extends beyond this article. Capacity figures are assembled from search results far more often than from identified documents, and the failure mode is not fabrication. It is misbinding: a real benchmark attached to the wrong system, a real award attached to the wrong programme, a real allocation ceiling read as an award. The defence is procedural and unglamorous — name the document, name the system, check that the two agree, and when they do not, say so rather than reaching for the nearest number that fits.

What a researcher can and cannot conclude

Put the sourced pieces together and a usable picture emerges, though a narrower one than the headline suggests.

A researcher can conclude that Expanse exists, is NSF-funded, is operated by SDSC at UC San Diego, and is available through ACCESS; that its operator states a peak of 5.16 petaflops without naming the basis; that a principal investigator may request up to 15 million core-hours and 75,000 GPU-hours, with a higher core-hour ceiling for Science Gateways in the Maximize tier; that its standard capacity is 728 AMD EPYC nodes and 52 V100 GPU nodes, with a separate 34-server H100 resource on nairr-gpu partitions; and that scheduling is by SLURM. The centre's directory entry is at San Diego Supercomputer Center in the directory.

A researcher can conclude, separately, that Voyager is an NSF-funded Habana-based system with 336 Gaudi training processors across 42 nodes and 16 first-generation inference processors across two nodes, scheduled by Kubernetes, in a testbed phase from early 2022 limited to select focused projects, with a stated intention to follow it with a two-year broader allocation phase.

A researcher cannot conclude from the accessible record how much sustained performance either system delivers on any workload; whether the 5.16 figure describes the H100 resource, the V100 partition, the CPU partition or some weighted whole; how many hours a typical applicant receives relative to the ceiling; how long a request takes to decide; what proportion of requests succeed; or whether the Voyager transition has happened. Nor can any claim be made about what a specific named researcher obtained, was refused, or could obtain — the record contains no individual allocation decision, no queue position, no wait time and no run outcome.

That list of negatives is longer than the list of positives, which is uncomfortable for a piece about AI capacity and is also the finding. The asymmetry is not evidence of concealment. Peak metrics are salient, comparable and cheap to publish; allocation ceilings, review rules and sustained measurements are none of those things, and institutions publish what is cheap. The result is a public record that reliably answers the question nobody is deciding and only partially answers the one everybody is.

What the AI framing adds, and what it obscures

There is a specific reason this documentation gap matters more now than it would have five years ago, and it is the word "AI".

Academic AI capacity is currently being counted, compared and funded at a pace that outruns the documentation. The unit of comparison that circulates is the accelerator count or the peak figure, because those are the numbers that appear in announcements. But the quantity that determines whether a research group can train a model is the product of three institutional facts: whether its request is eligible at all, how many hours it is granted, and how efficiently the granted hours convert into completed work. A peak figure encodes none of them.

On the evidence retrieved here, SDSC's record illustrates all three. Voyager's testbed phase makes eligibility the first gate, and a discretionary one. Expanse's per-investigator ceiling makes the award the second gate, and an unquantified one, since the ceiling is not the award. The absence of any sustained measurement leaves the third factor entirely to the reader. Three gates, and the public documentation addresses one of them in detail.

What the AI framing also obscures is scale. The H100 resource described on the Expanse page is 34 servers. Set against 728 standard CPU nodes and 52 V100 nodes, it is a small and clearly delineated part of the installation, described in units rather than in performance. That is not a criticism of the resource; a 34-server H100 partition is a substantial thing to operate. It is a caution about arithmetic. When an institution's AI capability is reported as a system-level peak, the reader has no way to know what fraction of the machine the AI partition represents, and the answer here appears to be a modest one.

The control surface: who sets which number

The useful way to hold this material together is to separate the parties who set the numbers.

The hardware supplier and the system integrator set the peak specification. It is their number in the sense that it derives from the parts they installed and the assumptions they published; the operator restates it. It is the number most likely to be quoted, because it is a single figure with no conditions attached in ordinary use.

The operator and the scheduler set the delivered throughput. That number is not published in the material retrieved here, and it is the one that would require measurement rather than specification. Its absence is the central documentary fact of this article.

The funder and the allocation body set who may compute, through eligibility rules, review procedure and ceilings. Here the ceiling is published and the procedure is not, which leaves the gate visible in outline and opaque in operation.

Three parties, three numbers, and the public record carries the first in full, the third in part, and the second not at all. Any statement that treats the first as a summary of the other two has quietly promoted a specification into a measurement.

Dated evidence boundaries

Everything above is bounded by what this retrieval could reach on 17 and 18 October 2026, and the boundaries should be stated as findings rather than apologies.

The NSF award record for the Expanse award number could not be read; access was blocked, so award terms are unverified and no claim about obligated funds, period or reporting is made. The ACCESS allocation-tier policy text was not retrieved; the portal yielded its funding acknowledgement and its no-cost statement, and a second address was unreachable, so tier thresholds and review procedure are not asserted. A TOP500 address surfaced in search resolves to an Inspur NF5468M5 cluster rather than Expanse, so no sustained LINPACK result, no Rmax, no Rpeak, no ranking and no efficiency figure is attributed to either SDSC system.

And no independent measured sustained result was obtained for either system, so the article states that none was verified — not that none exists.

Current queue behaviour, current caps, current hardware status and current access conditions all require fresh evidence. Policies change; partitions are added and retired; a testbed phase ends. A reader relying on this article for a decision should re-check the primary pages, which are linked here precisely so that they can be checked.

What would change the picture

It is worth being concrete about the evidence that would move this from a documentation finding to a performance finding, because the absence is specific rather than general.

A matched independent benchmark would do it: a sustained result identifying the exact system, the partition, the workload, the numeric precision and the methodology. A verified TOP500 entry for Expanse, as opposed to one for a different machine, would support a ranking claim and give the peak figure a measured counterpart. A retrieved award record would permit statements about obligated amount, performance period, purpose, deliverables and reporting terms — though not, by itself, about benchmarked performance, since an award document describes an obligation rather than a result.

A published allocation notice or an aggregated, anonymised record of awarded hours would let the distance between the 30-million-core-hour request ceiling and a typical award be quantified. And current policy text would settle whether Voyager's stated two-year allocation phase has begun.

Each of those is obtainable in principle and none was obtained here. Until one of them is, the honest summary of SDSC's AI capacity is a specification with a rationing rule attached and no measured middle term — which is a less satisfying answer than a ratio, and a more defensible one.