Access and intake

Access to Spike begins with a project discussion, not an account checklist. The SCC uses the intake to understand whether Spike is the right platform, whether the project is ready to use it, and whether capacity is available during the requested period.

Submit the request

Researchers (Spike 1)

Start by submitting the Spike application form in the TU/e Service Desk. This is the first step for every new Spike request. If your department already tracks the proposal in Research Cockpit, include that reference in the form; do not create a second application or wait for a separate Cockpit step.

A useful request gives the AI engineer enough context for a productive first conversation. Include:

• The research goal and the TU/e department or institute involved;
• A proposed project name;
• The people responsible for the project and the full list of users who will need access;
• What the code does today, where it currently runs, and how close it is to a meaningful HPC test;
• The expected number and type of GPUs, run duration, and rough project window;
• The estimated dataset size, its current location, whether it is ready to transfer, and the outcome from Data classification on Spike;
• The software stack and whether a working container already exists;
• Why Spike may be a better fit than the resources you already use.

Exact numbers are not required at this stage. A reasoned estimate is more useful than an ambitious guess.

Companies (Spike A)

Commercial access to Spike A is provided through Supercomputing Brabant and hosted/operated by TU/e as a founding major partner, giving commercial R&D teams access to dedicated NVIDIA Blackwell B300 hardware and VAST Data parallel storage.

The commercial onboarding process follows a structured lifecycle:

1. Exploration and use-case intake (Verkenning)

Every commercial engagement begins with Niels te Poel, Business Developer for Supercomputing Brabant:

• Primary contact: Niels te Poel (ntepoel@bom.nl), Business Developer, Supercomputing Brabant.
• Initial exploration: An introductory conversation to explore your organization’s business challenge and prospective AI application.
• Use-case definition: Outline the core problem, project objectives, target application, and current readiness phase.
• Confidentiality: A Non-Disclosure Agreement (NDA) is established where required before exchanging proprietary code, architectural details, or sensitive datasets.

2. Technical and data intake

Following the initial exploration, a technical alignment session is convened with:

• The Business Developer (Supercomputing Brabant)
• The Project Manager
• A Supercomputing Brabant (SCB) Engineer
• A Data Steward (evaluating compliance, data sensitivity, and governance)

During this session, the team conducts an in-depth assessment across six pillars:

• Technical feasibility & compute: Suitability for NVIDIA Blackwell B300 GPU acceleration, memory requirements, and Run:AI scheduling presets;
• Storage architecture: Total all-flash VAST Data NVMe capacity needed, parallel ingestion throughput, and protocol requirements (multi-protocol NFS or S3-compatible endpoints);
• Software stack: Framework compatibility (PyTorch 2.5+, TensorRT-LLM, Megatron-LM), CUDA 12.8+ compiler flags, and rootless Podman container readiness;
• Data sensitivity & privacy: Evaluation of data classification by the Data Steward to identify any special handling, anonymization, or regulatory requirements;
• Security and IP protection: Clear boundaries ensuring your proprietary models, weights, datasets, and intellectual property remain strictly company-isolated;
• Authorized user list: Upfront agreement on the finalized list of company engineers requiring access, ensuring TU/e Non-Payroll (NOP) account registration can proceed without delay.

3. Go / No-Go decision

Following technical and data assessment, the Business Developer and the Project Manager make a formal Go / No-Go determination regarding workload allocation on Spike A.

This decision confirms technical viability, cluster capacity, reservation schedules, and operational readiness before legal agreements are finalized.

4. Contracting and governance

Once a positive Go decision is reached, formal agreements are executed:

1. Service Level Agreement (SLA): Specifies contracted Blackwell B300 GPU quotas, reservation windows, availability targets, and support boundaries.
2. Data Processing Agreement (DPA): Executed where the Data Steward assessment indicates processing of proprietary, confidential, or personal datasets.

Dual Gate Approval

Technical onboarding and account creation proceed only once both the Business Developer and the Project Manager have signed off and the commercial agreements are executed.

5. TU/e NOP account registration (VPN & network access)

External commercial partner engineers connect to the Spike infrastructure via the TU/e network and VPN using TU/e Non-Payroll accounts (NOP accounts, also known as Nopper accounts).

While agreements are being finalized, each company engineer from the finalized authorization list completes the User Account Registration Form:

Required user information

• Full name
• Correspondence language: Dutch or English
• Date of birth: (DD / MM / YYYY)
• Nationality
• Private phone number: (Including country code)
• Personal email address
• Company or organization

Information about the use of personal data

• Data Controller: Eindhoven University of Technology (TU/e) is responsible for processing personal data collected through this form.
• Purpose of processing: TU/e collects and uses this information solely to create and administer your user account, manage access to the AI SIB computing environment, verify and maintain account details, and communicate regarding account-related matters, security, and technical support.
• Required information: This information is required to complete account registration. Without it, TU/e cannot create or maintain the requested account.
• Access and disclosure: Access is strictly limited to authorized TU/e personnel who require the information for administration, security, or support. Data is not used or disclosed for unrelated purposes.
• Security: Appropriate technical and organizational measures are applied to protect personal data against unauthorized access, loss, alteration, or unlawful use.
• Privacy rights: Users may request access, correction, erasure, or restriction of processing, or object to processing by contacting privacy@tue.nl.
• Legal basis: Legitimate interest in creating and administering user accounts, managing infrastructure access, maintaining security, and providing account support.
• Confirmation: Each user must sign and confirm the accuracy of the provided information.

6. Technical onboarding and realization (Realisatie)

Once agreements are executed and NOP accounts are active, project realization begins:

1. Infrastructure provisioning: An SCB engineer configures:
   • Your isolated commercial Run:AI project with contracted Blackwell B300 quotas;
   • High-throughput VAST Data parallel storage volumes mounted at /data or /vast;
   • Your private, company-isolated Harbor container registry project.
2. Hands-on onboarding session: An SCB engineer leads a working session with your technical team to verify VPN connectivity, test Podman container builds and image pushes, validate VAST storage I/O, and launch your first workloads on Blackwell B300 nodes.
3. Ongoing realization support: Your team maintains direct, intimate collaboration with dedicated Supercomputing Brabant (SCB) engineers throughout project execution to fine-tune distributed performance and maximize GPU utilization.

Projects with external collaborators

External collaborators can be included in a Spike project, but they need an approved TU/e sponsored or guest identity before SCC can grant Run:ai and Harbor access. Mention external users in the initial request so the identity process can start before onboarding; it can take longer than adding an existing TU/e account.

Provide SCC with the collaborator’s name, home institution, role in the project, TU/e project sponsor, and expected access period. Do not send passport copies, dates of birth, nationality details, or other identity documents to SCC or attach them to a Spike ticket. TU/e HR and identity-management services collect any information they require through their own approved process. SCC continues onboarding after the institutional identity and project approval are confirmed.

Is Spike the right fit?

Spike is TU/e’s most capable GPU platform. It is intended for work that benefits from capabilities such as:

• Distributed training across several GPUs or nodes;
• Unusually large GPU-memory requirements;
• Blackwell-specific features such as driver-level FP4 precision;
• The NVIDIA AI Enterprise software stack;
• GPU Direct Storage and high-throughput data pipelines;
• Container-based research workflows;
• Runs that exceed the practical capacity or time limits of other available platforms.

A project does not need to meet every condition. The intake is where SCC and the research team decide whether the expected benefit justifies using scarce Spike capacity. A workload that runs comfortably on one conventional GPU may be better served elsewhere.

For the current institutional criteria, see Is Spike-1 the right fit for your project?.

The intake conversation

An SCC AI engineer will discuss the research objective, technical readiness, data, software environment, required scale, and project schedule with you. The conversation is collaborative: its purpose is to find the right computing route and to make sure a Spike allocation can be used well.

The outcome is one of three practical next steps:

1. Onboarding is scheduled when the project is eligible, ready, and capacity is available.
2. The project joins the waiting list when it is a good fit but the cluster is full during the requested period.
3. Another route is recommended when Snellius, the TU/e Umbrella cluster, or SURF Research Cloud better matches the workload, or when the project needs more preparation first.

Prepare for onboarding

Onboarding takes part of a day and is a working session with an AI engineer. Come with:

• Code you understand and can run in a known environment, close enough to HPC readiness that a meaningful test does not depend on weeks of further development;
• The dataset you plan to use, ready to transfer, with its size and sensitivity classification understood;
• The agreed project name and complete list of users;
• An estimate of the full dataset size and a confirmed sensitivity classification;
• The command or entry point for a small test run;
• A list of required packages, system libraries, and accelerator dependencies;
• A plan for durable input, output, and long-term storage;
• Enough Linux and terminal experience to diagnose your own application.

Together you will cover the Spike-specific parts: project access, Harbor and containers, storage and data transfer, Run:ai environments, resource selection, workload submission, logs, and cleanup. Some adjustment to containers and the B200 GPUs is expected; that is part of the onboarding work.

Data and access window

Spike access is granted for a defined project window. Plan how results and other important data will leave the platform before that window closes.

Also account for planned maintenance. Spike normally has a broader summer maintenance window and a year-end window for required updates. Exact dates, scope, and expected downtime are announced to active projects in advance; plan checkpoints and data transfers around the communicated window.

Directly identifiable personal data, unreviewed special-category personal data, and direct participant or end-user processing do not enter through normal Spike onboarding. Pseudonymized data remains personal data and requires an explicit, recorded review. Complete Data classification on Spike with your Data Steward and SCC AI Engineer before transfer.

Support after onboarding

The handover does not end when an account works. An SCC AI engineer remains the technical contact while the team starts its first workloads. Use that contact to review resource choices, container and data-flow problems, failed or slow runs, and opportunities to use the system more efficiently.

Next steps

• Classify project data before transfer →
• Check project access after onboarding →
• Prepare the workload environment →
• Plan project storage →
• Load data onto the platform →
• Submit a training workload →