Skip to content

Timeslot-based GPU access

Machine park (on-premise) w/ NVIDIA GPUs

  • vertex.ti.bfh.ch (2 x H200 142 GB GPUs)
  • peak.ti.bfh.ch (2 x H100 95 GB GPUs)
  • apex.ti.bfh.ch (2 x A100 80 GB GPUs)
  • zenith.ti.bfh.ch (1 x RTX A6000 49 GB GPU); limited access (reserved)
  • zenara.ti.bfh.ch (1 x RTX A6000 49 GB GPU); limited access (reserved)
  • chronos.ti.bfh.ch (2 x Titan RTX 24 GB GPU); limited access (reserved)
  • curta.ti.bfh.ch (1 x Intel CPU E7-8860 @ 2.20GHz, 128 cores; RAM: 1.5 TB; use numactl to control cores)

Switch.ch nodes (cloud)

In case of high and/or fluctuating demand, we're also offering a setup with Switch virtual machines (2 x H100 95 GB GPUs).

Request access

Request access via this online form.

Resources

You will receive an email as soon as your account was added to the MLMP infrastructure. The MLMP comprises the following three components:

System access

Depending on your system load and system utilization, we will provide you with access to one or more of our systems. Check our email to see which systems you were given access for.

MS Teams Team

The MLMP Team on Microsoft Teams is the single channel for us to communicate any planned downtime of systems, system failures and similar. You are obliged to regularly check for new messages!

MLMP Calendar

You will get access to the MLMP calendar where you have to reserve your timeslots as described on the next page.

How to run your code on MLMP infrastructure

1. Scheduling your compute slot

GPU resources are collaboratively used by multiple users. Therefore, scheduling your GPU usage slot is essential.

Scheduling Rules:

  • You must use the MLMP Outlook calendar for resource scheduling.
  • Book only one GPU per person.
  • Book slots strictly within the following blocks:
  • Monday to Wednesday
  • Thursday to Friday
  • Saturday to Sunday
  • ⚠️ You cannot book two consecutive slots. For example, a slot from Wednesday to Friday is not allowed.

Booking template

A booking template is available every Sunday in the MLMP calendar. Check this for guidance.


2. Compulsory code configuration for fair usage

Before running your code, please ensure to apply the following configurations:

  • Tag your process using setproctitle
  • Restrict CUDA access to the one GPU you entered in the calendar reservation

Code configuration template

Refer to the provided script cuda_test.py for details how to configure this in your code!

Adhere to these rules!

These configurations ensure smooth operation in our collaborative environment. Repeated violation will result in revoking your access to the MLMP.


3. Connecting to the server

Access is provided via SSH using your BFH credentials (BFH username and password).

  • Ensure you're connected to the BFH network (non-campus networks require the BFH VPN)
  • Connect via SSH:
ssh <your-BFH-username>@<system>.ti.bfh.ch

Upon successful login, carefully follow the instructions provided in the "Message of the Day" (MOTD).

3.1 Setting Up OPKSSH

Future access will be provided through opkssh, here's a quick guide on how to set it up given that you had already filled out the online form:

  1. Follow the installation instructions on the opkssh GitHub page for your OS. On Linux:

    wget -qO- "https://raw.githubusercontent.com/openpubkey/opkssh/main/scripts/install-linux.sh" | sudo bash
    

    On Windows, restart your shell after installation so the PATH is updated.

  2. Create the config file

    opkssh login --create-config
    

    This creates: - Windows: C:\Users\<USER>\.opk\config.yml - Linux/macOS: ~/.opk/config.yml

  3. Edit the config file. REPLACE the contents of the original with the following:

    default_provider: eduid
    
    providers:
    - alias: eduid
        issuer: https://login.eduid.ch/
        client_id: bfh_oidc_client_43155  
        scopes: openid profile email offline_access
        access_type: offline
        redirect_uris:
        - http://localhost:3000/login-callback
        - http://localhost:10001/login-callback
        - http://localhost:11110/login-callback
    
    4. Login
    opkssh login -i ~/.ssh/bfh_opkssh_access      # opens browser
    

    opkssh login

    This command generates the ssh key pair and assigns a name and location, in this case the name will be 'bfh_opkssh_access' and location ~/.ssh/

  4. And connect:

    ssh -o "IdentitiesOnly=yes" -i ~/.ssh/bfh_opkssh_access <shortname>@<server>
    

    • Note that ~/.ssh/bfh_opkssh_access is a linux path, if your on Windows Powershell it would look something like this: $HOME\.ssh\bfh_opkssh_access.
    • bfh_opkssh_access is the name of your keys, DO NOT replace this.
    • The generated keys are stored in ~/.ssh/ with the name bfh_opkssh_access and expire after the configured period (e.g. 24h). After expiry, just run opkssh login -i ~/.ssh/bfh_opkssh_access again.
    • The placeholder <shortname> refers to your BFH shortname (e.g. pnl1).
    • The placeholder <server> refers to the server you were given access to, you will know this once the admins assign you a specific GPU machine.

4. Check for unauthorized processes

Before you start your code, ensure that your slot is not taken by someone else by accident (or ignorance):

  • Run nvidia-smi to see an overview of the availabe GPUs and processes.
  • Make sure that "Memory usage" of the GPU you are about to use is 0MiB! If this value is not zero, this usually means that someone else is computing on this GPU.
  • In that case, please make a screenshot from the output (including the processes) and inform the MLMP team via email.
  • Additionally, if the person has correctly tagged their process, feel free to contact them directly.

5. Docker and Pyenv Environment

Our infrastructure is Docker-based and purely collaborative. This means:

  • No root privileges (neither inside nor outside Docker).
  • Docker launch script provided: sudo docker-run-pyenv.sh.

Follow the script instructions exactly or consult additional resources available for pyenv.

No local installations!

You are obliged to use this pyenv-based docker image. Do not attempt to use your own local installations.

Typical Workflow Docker

1. Create your personal Docker Instance (first time only):
sudo docker-run-pyenv.sh

This command build and initializes your personal container

2. List Docker instances:
sudo sudo docker-ps.sh

Displays all containers and their UUIDs

Alternative

You can use the sudo docker-start.sh to list YOUR docker instance UUID.

3. Start (or reactivate) your existing container:
sudo docker-start.sh <UUID>

Use this command to restart a previously created container. Replace <UUID> with your actual container UUID, as shown in step 2, above.

4. Connect to a running container:
sudo docker-bash.sh <UUID>

This command connects you to a currently running container.

5. Stop your container
sudo docker-stop.sh <UUID>
6. Remove your container (if needed)
sudo docker-rm.sh <UUID>

6. Installing Python Packages

After launching Docker and activating your Python environment via pyenv, install necessary packages using pip:

pip install numpy torch notebook

7. Running Jupyter Notebook

To launch a Jupyter Notebook:

  • Change directory to your workspace:
cd ~/workspace
  • Check your personal port assignment:
cat HOST_PORT.txt
  • Start Jupyter Notebook server:
jupyter notebook --ip=*
  • Note the access token displayed in the terminal after starting the Jupyter Notebook.

8. Accessing Jupyter via Web Browser

  • Open your web browser.
  • Go to the URL provided (replace system with your system name and <port> with your actual assigned port):

http://<system>.ti.bfh.ch:<port>

  • Enter the noted access token into the prompted field.

Support

If you encounter any issues or need clarification, please reach out by sending an email.


Happy Computing!