Technical Guide for Applications for EuroHPC JU AI for Industrial Innovation Calls

Purpose

This document helps applicants identify which EuroHPC JU AI for Industrial Innovation call (AI Factory call) best matches their project and provides guidance on the technical information needed to assess project viability on LUMI-G. A well-documented application accelerates the review process and increases the probability of approval. Applications are submitted via the EuroHPC JU AI Factories access calls page.

Guidance on call selection

Call selection depends on multiple factors: GPU-hours, GPUs per job, user experience, workload type, and scalability evidence. The selected call determines the evaluation process and the expected level of technical justification.

Choosing the right call

• EuroHPC AI Factory Playground: first-time users, porting code to LUMI-G (AMD) hardware, prototyping and getting ready for large-scale runs, small-scale training, moderate batch inference workloads.
• EuroHPC AI Factory Fast Lane: experienced users, medium-scale training or large-scale batch inference.
• EuroHPC AI Factory Large Scale: projects requiring a large total number of GPU-hours, either due to large model size, extensive hyperparameter sweeps, or a high volume of independent jobs.

AI Factory (AI for Industrial Innovation) calls

Call	GPU-hours	Scaling benchmarks required	Resource and job allocation plan required
Playground	≤ 5,000	❌	❌
Fast Lane	5,001 – 50,000	✅	Number and size of jobs (#GPUs, duration, …)
Large Scale	> 50,000	✅	Number and size of jobs + estimated usage per month

The “Resource and job allocation plan required” column tells you what kind of information is expected in the application to justify the requested compute amount. More details on this below in Section Scalability and performance.

Quick selection guide

Essentially, apply for the Playground call if any of the following applies to you:

• your software stack has not been previously demonstrated on LUMI-G and needs testing and potentially further development to establish readiness for using the requested compute, or
• any single run you plan requires more than 4 GPUs (one LUMI-G node) but you do not have data on how your workload scales with increased GPU count, or
• you need at most 5,000 GPU-hours in total.

Otherwise choose the Fast Lane or Large Scale call depending on your total compute resource needs.

Eligibility

As per the EuroHPC JU Access Policy, we have to reject applications when the following criteria are not met:

• Your organization must be a startup, SME or other industrial organization. AI for Industrial Innovation calls are not open for academic use or public sector organizations.
• Your organization must have a valid VAT number.
• Your organization must be incorporated in a Horizon 2020 country.
• You do not have another ongoing EuroHPC JU project.

Technical assessment: key sections and fields

The evaluation team will assess technical feasibility based on two core sections of the proposal:

• AI Factory selection
• Code details and feasibility

Below, we explain in detail what information you should fill in the fields in those two sections for the best chance of passing the technical review.

AI Factory selection

This section collects the key resource data that defines the technical scope of the request: the target cluster (LUMI-G), a short list of the software libraries that will be used, the total GPU-hours for the project, the maximum number of GPUs per job, and the associated storage and data transfer requirements. Field labels are self-explanatory.

Code details and feasibility

This section contains information on the software your application requires to run successfully. The reviewers use the provided information to determine whether the application can run efficiently on the LUMI-G HPC infrastructure.

Code details

In this section you should provide details on every significant component of your software stack and in that way expand on the short list you provided in the previous section.

Software project stacks typically consist of common third-party frameworks and libraries (like PyTorch, JAX, HuggingFace, Megatron, vLLM, etc.) and some more or less extensive custom code. The custom code can range from simple training scripts that make use of an existing framework for actual computation to extensive new feature implementations and optimizations on top of existing libraries that you want to test in the project, or be auxiliary components to the machine learning tasks, e.g. data generation.

Complete this section for every distinct software component used in the project or experimental phase of it: fill this once for your main training (or inference) loop. Add an additional entry using the “+ Code details” button for each of (but not limited to) the following cases:

• you have compute-intensive pre-processing using dedicated separate code (custom or third-party),
• you use separate software for an evaluation phase (e.g. PyTorch for training and vLLM for a compute-heavy inference phase),
• you use simulation software to create training or testing data.

a. Name and version of the code:

Provide the code name and, if applicable, the version or release identifier.

b. Webpage and other references:

Provide links to the code repository, documentation, or relevant publications. References that include technical data (e.g. compilation steps (if required), hardware requirements (CPU/GPU), dependencies, scalability tests, or performance validation) are particularly valuable for the evaluation.

c. Description of the code:

Provide a brief description of the role of the software component in your project.

For machine learning code, specify the ML framework (PyTorch, TensorFlow, JAX) and the key libraries or packages required. If applicable, include distributed training libraries (e.g. DeepSpeed, FSDP, Horovod) and optimization strategies (e.g. FlashAttention, activation checkpointing, mixed precision). Include the minimum version numbers that you need.

If you know that all of the libraries you need are available via the LUMI AI Factory AI Software Environment, you should also point that out here – or otherwise state how you plan to install your missing dependencies.

For other code (e.g. simulation, custom kernel implementations), please state the main programming language, software dependencies and compilation steps (if required).

Scalability and performance

d. Describe the scalability and performance of the application:

(Select the subsection that corresponds to your project category):

Playground projects – ≤5,000 GPU-hours

Detailed scaling data is not required, but please provide a basic description of any tests already performed. Tests may have been performed on other hardware.

Example 1 (has test data):

“We tested our model on a single MI250X GPU for 2 hours using 10% of the dataset. Training converged after 50 epochs. We expect full training on one node (4 GPUs / 8 GCDs) to take approximately 8 hours.”

Example 2 (no test data):

“We have only tested on a local workstation with 1 GPU (Nvidia RTX 4080). This allocation will allow us to test our application and measure performance on AMD MI250X GPUs to establish scaling behaviour for up to 16 GPUs (4 nodes) in preparation for a larger allocation request.”

Fast Lane projects – 5,001–50,000 GPU-hours

Please provide an approximate list of the jobs you plan to run, including, for each job type, a descriptive title, its typical size (number of GPUs and runtime), and the number of such jobs. This should serve as your main justification for the requested compute.

For example (but you don’t have to use a table form for this):

Job	Estimated GPU Count	Estimated Duration	Number of Jobs	Total GPU-hours
Hyperparameter evaluation	8 GPUs (2 nodes)	4 hours	120	3,840
Full-scale training	32 GPUs (8 nodes)	24 hours	1	768
Ablation training	32 GPUs (8 nodes)	24 hours	16	12,288
Model variant evaluation on several datasets	4 GPUs (1 node)	2 hours	160	1,280
Total	—	—	—	18,176

To justify the given job sizes, provide scaling test results for LUMI-G hardware relevant for your scale in terms of throughput measurements (samples/sec or tokens/sec) and projected efficiency at the target GPU count. If you have only limited scaling data, you may extrapolate to your desired scale if the data you provide supports the extrapolation.

Example for a multi-node training run:

“We tested on 4, 8 and 16 MI250X GPUs using PyTorch FSDP with a fixed dataset of 1M images. Throughput increased from 1,200 to 4,225 samples/sec, corresponding to 88% scaling efficiency at 16 GPUs (4 nodes). Based on these results, we project 80–85% scaling efficiency up to 32 GPUs, expecting a single full-scale training run to take 24 hours on the full data (34M images, ~20 epochs) for 768 GPU-hours per run.”

Alternatively, you can provide your previous scaling results in table form, for example:

GPUs	Throughput (samples/sec)	Speedup	Efficiency	MFU
4	1,200	1.00x	100%	38%
8	2,280	1.90x	95%	37%
16	4,225	3.52x	88%	36%

Example for many small parallel runs (≤ 2 nodes / 8 GPUs), e.g. hyperparameter tuning or inference runs with different models:

“The hyperparameter evaluation runs consist of 120 independent jobs, each using 8 GPUs for 4 hours on average. We have tested a representative job; runtime is stable (±5%). We will use job arrays to manage the workflow and ensure high queue utilisation. No strong scaling across larger GPU counts is required, as each job does not scale beyond 8 GPUs.”

Large Scale projects – >50,000 GPU-hours

Provide the same information as for a Fast Lane project, but with quantitative scaling data or performance justification at the scale appropriate to your workload on LUMI-G hardware, without extrapolation.

Additionally, please provide a usage schedule for how you plan to allocate your compute budget over the duration of your project.

For example:

We plan the following resource usage over the duration of the project:

• Month 1: Initial data transfer and software setup, 1,000 GPU-hours
• Month 2: Hyperparameter sweeps, 15,000 GPU-hours
• Month 3-4: Main training and ablation runs, 35,000 GPU-hours
• Month 5-6: Evaluation, 10,000 GPU-hours

e. Optimization of the work proposed:

Use this field to tell us about tests or optimizations you plan on conducting, if any. Describe concrete optimization actions, not scientific or business impact. Include:

• Which specific code component will be optimized
• Which technique will be used (FSDP, FlashAttention, checkpointing, data loading, etc.)
• How this will benefit future work (quantify if possible)

(Select the subsection that corresponds to your project category):

Playground projects – ≤5,000 GPU-hours
Example:

“We will learn to use PyTorch DDP for multi-GPU training. We will experiment with different batch sizes, gradient accumulation steps, and NCCL settings to understand their impact on training speed. The results will inform future projects requiring distributed training.”

or

“We will use this project to port our existing codebase for Nvidia to the LUMI AMD hardware, fixing compatibility issues where necessary. We will also evaluate runtime and scaling characteristics for future projects.”

Fast Lane projects – 5,001–50,000 GPU-hours
Example:

“We will optimize the data loading pipeline, which currently consumes 30% of training time. We will implement pre-sharded datasets and increase data loader workers from 4 to 16 per GPU. This will reduce overhead to <10%, enabling faster training in future runs.”

FAQ

• I am confused about the number of GPUs on a LUMI-G node. Can you please explain?
  • Each LUMI-G node has 4 AMD Instinct MI250X GPUs, each consisting of two Graphics Compute Dies (GCDs). From a software point of view, these are represented as 8 distinct processors, so from the SLURM scheduler you can allocate 8 “GPUs” per node. However, terminology for access applications and usage billing treats each MI250X as one GPU, so one GPU hour corresponds to using one MI250X for one hour and each LUMI-G node has 4 GPUs.
• I have substantial pre- and post-processing tasks that do not require a GPU. Via the AI Factory calls I can only apply for GPU-hours. What can I do?
  • Projects created for AI Factory calls by default also receive 1,000 CPU hours that can be used on LUMI-C. If you expect that you require more, please mention this in the application – e.g. in the “Description of the code” for that software component – and we will try to accommodate your reasonable needs if CPU resources are available. Please avoid reserving CPU-only jobs on LUMI-G.
• I need to run a small coordinator app (e.g. MLFlow, wandb server or similar tooling) for my ML training. The AI Factory calls do not appear to allow requesting cloud-like resources. What can I do?
  • Any project with access to LUMI-G also has access to the LUMI-K Kubernetes platform, so you can run some auxiliary services there. Note, however, that resources of LUMI-K are constrained and there are no GPUs available there. Any compute-heavy tasks must be run on LUMI-G. You can find more information about LUMI-K on https://docs.lumi-supercomputer.eu/runjobs/lumi-k/getting-started/lumi_k_what_is/ .