Japan’s ABCI 3.0 shows why an AI cloud needs a job and data lifecycle

AIST’s launched AI cloud and version-specific guides reveal the scheduling, persistence and migration decisions behind a usable experiment.

The launch of a research AI cloud is often reported through its accelerator inventory. For users, an equally consequential part of the story is the operating model: where they prepare a program, how it enters a queue, which storage survives the job and how an infrastructure generation is retired. Japan’s ABCI 3.0 provides published evidence for examining those questions beyond a proposed national capacity total.

ABCI stands for AI Bridging Cloud Infrastructure. The sources reviewed on 16 October 2026 include AIST’s launch confirmation, the version-specific system and job guides, storage instructions and the operator’s history of service changes. Together they describe a shared computing service. They do not establish that an applicant has access, that a queue is empty or that a particular model has been trained successfully there.

A launch confirmation is stronger than a planned date

[AIST’s Japanese-language announcement dated 20 January 2025](https://www.aist.go.jp/aist_j/news/announce/au20250120.html) says that AIST and AIST Solutions began general provision of ABCI 3.0 at noon that day. That is a reported launch, rather than an equipment order awaiting delivery. The translation here retains that scope; it does not convert general provision into unrestricted access for every overseas applicant.

The [ABCI 3.0 system overview](https://docs.abci.ai/v3/en/system-overview/) describes 766 compute nodes with 6,128 NVIDIA H200 accelerators. It also warns that some resources may not be provided for operational or maintenance reasons. The inventory is therefore system architecture, not a reservation a reader can rely on. Peak hardware specifications should not be mistaken for an observed training rate or the time a user spends waiting.

For a project team, this is an important change in the evidence it can seek. A proposed facility supports a planning discussion. A launched facility with operating documentation supports a more concrete examination of workload fit. Neither alone proves scientific value or commercial impact; those require evidence from the work actually performed with the resources.

The front door and the heavy work are separate

The version-specific system guide distinguishes shared interactive nodes from GPU compute nodes. The interactive nodes support preparation, editing and job submission and have no GPU. It warns users against heavy processing there because those resources are shared. GPU programs are submitted through the job-management system. This is a service architecture, not the same interaction model as an unrestricted workstation in the cloud.

The [job-execution guide](https://docs.abci.ai/v3/en/job-execution/) separates interactive On-demand jobs, batch Spot jobs and advance Reserved service. It describes logical resource partitions, resource limits and job priorities. Here, “Spot” names ABCI’s batch service; the guide is the authority for its behaviour. The word should not import another provider’s auction, discount or interruption rules without evidence.

This operating model makes preparation a practical skill. A job should describe its inputs, software, required resources and expected outputs before it consumes a shared allocation. If it needs more memory than requested or spends its time preparing data inefficiently, a powerful cluster will not resolve the mistake automatically. These are workload-planning implications, not measurements of congestion or user performance on ABCI.

Temporary storage is useful precisely because it is temporary

The [storage guide](https://docs.abci.ai/v3/en/storage/) distinguishes home, group, local and cloud storage. It recommends staging frequently used files to local scratch and avoiding unnecessary pressure on shared filesystems, including excessive small-file access. These instructions connect data layout to shared-service behaviour. They do not establish a universal speedup for repackaging a dataset.

The same guide warns that ordinary job-local scratch is removed when the job finishes and that required files must be copied to a persistent area within the job. It gives a similar warning for temporary BeeOND storage. Keeping a model checkpoint in scratch and recording its path in a notebook would not preserve that checkpoint after cleanup. Persistence needs an explicit destination and a successful transfer.

This boundary matters even for modest experiments. A failed output-copy step can leave a run marked complete while the useful result has disappeared. A responsible workflow would distinguish calculation finished, output saved and result reviewed. Those states should be visible to the person responsible for the experiment, rather than collapsed into one reassuring message.

The previous generation supplies a migration lesson

The operator’s [operation-status history](https://abci.ai/en/about_abci/info.html) records the retirement of ABCI 2.0 interactive nodes and cloud storage on 30 March 2025, and a notice setting 30 September 2025 as the old group storage’s discontinuation date. Its notices asked users to migrate necessary data themselves. These are historical transition records, not confirmation of every deletion, a current instruction to move files or evidence that any particular user lost data.

That history adds something a hardware launch cannot: a concrete reminder that a research cloud has a lifecycle. Access, storage and software environments can change across generations. Teams need an inventory of what must be retained, what can be discarded and which dependencies are required to interpret an old result. Keeping everything indefinitely is not the only alternative to losing the experiment’s meaning.

A publication or internal review should therefore reference the environment actually used, not just “ABCI.” The relevant record includes input rights and versions, the code revision, selected resource class and the outputs retained. If the team later repeats the experiment on another system, it can explain what changed. That is a reproducibility practice, not a promise of identical numerical results across machines.

Fictional, unrun example: inspecting a materials-image dataset

Imagine a fictional materials laboratory in Sendai studying images of manufactured surfaces. Its organisation, images and proposed workflow are invented. The exercise compares methods for identifying visible defects in synthetic training material; it does not establish an industrial inspection deployment, safety certification or a result obtained on ABCI.

The team prepares a manifest that separates training images from a held-back evaluation collection. It records the generator or permitted source for each input. Before requesting a long run, it checks that its data preparation finishes and that a small job can save a checkpoint and an error report to persistent storage. A test that finishes but leaves no readable evidence would fail this acceptance condition.

For the proposed larger job, the laboratory stages permitted input data to temporary storage, writes intermediate files there and saves selected results to its approved persistent area. It retains a log of the copy outcome and checks the saved files before releasing the temporary workspace. This is a planning example; no job, transfer or benchmark was executed for this article.

The review then asks which surface patterns the method confuses and whether the evaluation collection reflects the intended future task. More compute is justified only if it helps answer that question. A student can practise the same lifecycle locally with synthetic images, a deliberately interrupted run and an explicit save check, without implying access to a national research system.

Judge the usable workflow alongside the machine

ABCI 3.0’s reported launch and detailed documentation make it possible to discuss an operating AI cloud rather than an unbuilt aspiration. The most useful next evidence would come from admitted projects: reproducible experiments, reviewed limitations and applications with observed results. Until then, its architecture, scheduling rules and storage lifecycle are already instructive. They show that access to accelerators becomes useful through a complete job and evidence lifecycle, not through hardware ownership alone.