# Courses with GPUs Nuvolos supports two workflows for courses with GPUs: the first approach is **GPU Lab Sessions** and the second is **On-Demand GPU Courses**. {% hint style="info" %} You need [credits](/pricing-and-billing/pricing-structure.md#credits) to use this feature. {% endhint %} ## Enable GPUs in your course 1. Make sure you have enough credits in the resource pool [mapped to the space](/pricing-and-billing/resource-pools-and-budgets.md#resource-pool-mappings). 2. Make sure you have [enabled credit-based sizes](/administration/space-management/hpc-spaces.md#enable-credit-based-application-sizes) in your teaching space. Now you can decide which flow to use in your course. ## GPU Lab Sessions GPU Lab Sessions are exactly what their name implies: your students can use GPU-enabled machines to practice GPU programming **during planned sessions.** The experience is like having a virtual lab where, for example, each student in course GPU101 can use a remote machine with a Tesla T4 card between 10:00-12:00 on Mondays, for 8 weeks. Such GPU Lab Sessions have the following properties that make them appealing: 1. Easy to explain to students 2. Equal opportunity for all students to use machines with the exact same specifications in the exact same time windows 3. All students start with the exact same environment (JupyterLab, VSCode, etc.), but they can make persistent changes to the installed packages and settings. 4. Ideal for exams or courses where access is only needed during specific time windows 5. Predictable, flat pricing. Once you know all the times and durations of all lab sessions, your total cost is fixed. In this workflow, every space administrator can launch GPU-enabled machines **in the Master instance anytime**. This way, instructors can work on the course material directly in the course space. However, students cannot start GPU-enabled machines themselves: instructors need to define lab sessions for them. This means students only need to sign in to Nuvolos when the lab session starts, and they'll find an already running, GPU-enabled Nuvolos application. ### Schedule a GPU Lab Session You can schedule a lab session using the [Schedule for startup](/user-guides/education-guides/configuring-student-applications.md#scheduled-startup-of-student-applications) feature. For that, you need to have an application that you have [already distributed](/features/nuvolos-basic-concepts/distribution.md) to all course participants. To schedule a session on machines with GPU: 1. Make sure you have distributed the application for all students in the space 2. Click the [Schedule for startup](/user-guides/education-guides/configuring-student-applications.md#scheduled-startup-of-student-applications) button 3. Turn on the **Scale resources** toggle, select your desired GPU size (available in teaching spaces with credit-based sizes enabled), and configure the **Stop after selected minutes** field. {% hint style="info" %} Since machines with GPU consume credits to run, scheduled startups with GPUs need to define the length of each session in minutes. After the set amount of minutes relative to the prestart schedule, every machine with GPU is automatically shut down in the space (including the machine(s) of the instructor(s)).\ \ Example: if the scheduled start is at 10:05 and stop after selected minutes is 120 minutes, all prestarted apps (including the instructors app) will be shut down at 12:05. {% endhint %} #### Limitations of GPU Lab Sessions * In teaching spaces, only smaller GPUs are enabled, such as the Tesla T4 and ⅙ A10. Check the Schedule for start menu for current offers in sizes. * Currently up to 90 concurrent students are supported only. Please reach out to support to clarify GPU sizes/attendee lists larger than this. * Stop after selected minutes can only be set between 30 and 360 minutes. * The total cost of a session with N students will be around N\*\[session length in hours]\*\[hourly price of GPU machine] + warmup premium, where the warmup premium means that applications are started 30-10 minutes ahead of time to allow for longer machine provisioning times due to higher machine checkout frequency around course start time. * Scheduled startups using GPU machines will not consider past user activity and will start up a GPU machine for every user in the course space. * Any running applications started by students will be restarted at the scheduled startup time and moved to GPU machines automatically. ## On-demand GPU courses {% hint style="info" %} The Credit Quota screen is activated when you [enable credit based sizes](/administration/space-management/hpc-spaces.md#enable-credit-based-application-sizes). {% endhint %} The other available workflow is the On-demand GPU course approach. As the name implies, in this case students can start up GPU-enabled machines **on demand, not according to a fixed schedule**. This has the following nice properties: 1. More flexible as GPU Lab Sessions: students can decide when they want to use the machines. 2. Equal opportunity for all students to use machines with the exact same specifications for exactly the same total runtime 3. All students start with the exact same environment (JupyterLab, VSCode, etc.), but they can make persistent changes to the installed packages and settings. 4. Ideal for assignments or courses where students are expected to practice outside course hours. 5. Predictable, capped pricing. You define at most how much credits your students are allowed to spend. This gives a predicable cap on your expenses. ### Configure On-demand GPU access In this workflow, every space administrator can launch GPU-enabled machines **in the Master instance anytime**. This way, instructors can work on the course material directly in the course space. Students can also start GPU-enabled machines themselves, provided that the instructors have distributed such app(s) for them and they have not reached their spending limit. #### Enabling a GPU size for students As mentioned, instructors can change between sizes in the Master instance anytime. This is not true for students: they are not allowed to change machine sizes, to enforce uniform access to resources for all students. The recommended setup is to share multiple applications, often of the very same version with the students: 1. Create app(s) with **Included sizes** (e.g. 1 CU) and distribute them to all students. These app(s) will enable them to work on the source code without utilizing credits until they really need them. 2. Create app(s) with **Credit-base sizes** (e.g. T4 Tesla) and distribute them to all students. These app(s) will enable students to execute the code using a GPU. {% hint style="info" %} To save on storage, we recommend that instructors already install all the packages the students will likely need. This way, repeated installation of large libraries (e.g. Tensorflow, Pytorch, etc.) can be skipped by the students. If you want your students to use multiple sizes, you need to distribute an app for each size. {% endhint %} ### Credit quota schedules Credit quota schedules are available to all projects which have [enabled credit based sizes](/administration/space-management/hpc-spaces.md). You can set credit quotas on the **Course Configuration > Student Credit Quotas screen.** Each quota has: * An amount - the total amount of credits to be used. * An end-date - the date by which the amount can be used. * A reset flag - deciding how to interpret the amount. See in the Fixed and Tiered credit quota schedules for more details. **End-date consistency requirements:** * End-dates in the schedule have to be in monotonous order. * If you change an end-date it cannot be put in the past or moved beyond a next end-date in the schedule. #### The current quota As the lecturer, you have the right to create a *schedule* or *timetable* of quotas, which fully determines the progress of maximal credit spending in the course. The **current quota** is the quota currently in effect. This is the quota in the schedule which has the nearest End Date that is past Today's date (inclusive). As an example if today is 2026-03-23, and we have: 1. Quota 1: 2026-03-23, 2 Credits, 2. Quota 2: 2026-03-25, 3 Credits, then the **current quota is** is **Quota 1 -** the current maximum amount each instance could spend up to today is 2 credits. #### Cross-instance quota usage Quotas apply on the project (course) level to all instances uniformly. This means that a quota of one credits by a given date means, that each instance (separately) in the course is able to use up to one credit by that date. The **Usage across instances** subscreen of **Course configuration > Student Credit Quotas** gives you a full overview of how quota utilisation progresses. {% hint style="info" %} To calculate the total credit allowance of a course up to a given date, you need to calculate the cumulative quota multiplied by the number of instances in the course up to that date. The exact calculation depends whether a fixed or tiered system is being used. {% endhint %} #### Fixed credit quota schedule Fixed schedules allow you to define maximum credit usage between specific dates, by setting **Reset counter** to "Yes". To use on-demand GPU access, you can define a **fixed credit quota schedule** like the following: | Credit quota | End date | Reset counter | | ------------ | ---------- | ------------- | | 1.2 | 2025-09-15 | Yes | | 1.2 | 2025-09-22 | Yes | | 0.6 | 2025-09-29 | Yes | In the above example, every student instance (whether it be [individual ](/administration/space-management/invite-to-a-space.md#inviting-students)or [group](/user-guides/education-guides/setting-up-group-projects.md)) can 1. consume up to 1.2 credits from the creation of the space until 2025-09-15 EOD 2. consume up to 1.2 credits more from 2025-09-16 to 2025-09-22 EOD 3. consume up to 0.6 credits more from 2025-09-23 to 2025-09-29 EOD 4. from 2025-09-30, students cannot start GPU-enabled sizes anymore {% hint style="info" %} End-of-day (EOD) means 23:59:59 in UTC time zone {% endhint %} This means, every student instance can consume **at most 3 credits** until 2025-09-29. The actual usage will be typically less because * in case an instance has 0 credit usage until 2025-09-16, then it may only consume up to 1.8 credits. This is because counter reset is true for all rows, meaning that consumption is reset to 0 on these dates, and a new period begins. {% hint style="info" %} Counter reset also stops any running apps at midnight in the student instances with a credit-based size. {% endhint %} #### Tiered credit limit schedule Tiered schedules allow you to define maximum credit usage up to specific dates, by setting **Reset counter** to "Yes". You can also define a **tiered credit limit schedule** for the students. Consider a similar schedule as before, but now with **Counter reset set to No**. | Credit limit | End date | Reset counter | | ------------ | ---------- | ------------- | | 1.2 | 2025-09-15 | No | | 2.4 | 2025-09-22 | No | | 3.0 | 2025-09-29 | Yes | In the above example, every student instance (whether it be [individual ](/administration/space-management/invite-to-a-space.md#inviting-students)or [group](/user-guides/education-guides/setting-up-group-projects.md)) can 1. consume up to 1.2 credits from the creation of the space until 2025-09-15 EOD 2. consume up to 2.4 credits from the creation of the space until 2025-09-22 EOD 3. consume up to 3.0 credits from the creation of the space until 2025-09-29 EOD 4. from 2025-09-30, students cannot start GPU-enabled sizes anymore The difference compared to a fixed credit limit schedule is that unused credits are not lost in intermediate dates. An instance that becomes active only in the last week can still utilize all 3 credits. ### GPU Lab session in an On-demand GPU course It is possible to schedule a lab session in an On-demand GPU course, but keep the following in mind: * you need to **explicitly select** the GPU resource in the schedule configuration. If you don't enable **Scale resources** during schedule time, the applications will be started without GPUs! * lab session credit spendings for your students **will also be counted** against their credit limit, just like any other sessions they start themselves. Plan your credit limit schedule accordingly. {% hint style="info" %} Using a GPU Lab session in an On-demand GPU course can cause credit imbalance for students because * student apps are started up in sequence, so different students will incur different credit costs * if a student's app is started by the system scheduler, it will also be stopped automatically by the system scheduler. Students who started their applications themselves before the lab session can keep working without interruption, but they will also be responsible for stopping the application themselves {% endhint %} For these reasons, if you plan to use lab session on your On-demand GPU course, it's best to set a separate limit for the lab session's day. Example: | Credit limit | End date | Counter reset | | ------------ | ---------- | ------------- | | 1.2 | 2025-09-16 | Yes | | 0.36 | 2025-09-17 | Yes | | 1.2 | 2025-09-23 | Yes | | 0.36 | 2025-09-24 | Yes | In this example, there is a planned lab session day on 2025-09-17 and 2025-09-24, with a dedicated budget just enough to support the lab session's duration. ### Student view of credit quotas and usage Students can see their available quota and current usage on the top right corner of their **Applications screen**. ### FAQ #### What happens if an instance reaches the quota? If an instance reaches a quota before the quota end-date, then further credit utilisation is blocked. All running scaled applications are stopped and will not start until either a new current quota takes effect or the current quota is increased. #### Can I set quota for a specific student? No. Credit quotas may only be set on the course level and apply to all students and instances uniformly. #### Does the quota apply to me as a lecturer? Yes. We suggest testing crucial teaching material in a separate project. #### How do I estimate the total credit usage of my course after I set the quota for my course? The total credit usage is still unknown, but you can calculate the **maximum budget used** by multiplying the number of instances with the total quota allowance. The calculation differs for tiered and fixed schedules. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.nuvolos.com/user-guides/education-guides/courses-with-gpus.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.