> For the complete documentation index, see [llms.txt](https://docs.nuvolos.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.nuvolos.com/how-to-guides/workflows-for-instructors/courses-with-gpus.md).
# GPU courses
## Enable GPU access for your course
**Outcome**\
You enable credit-based application sizes and confirm that your course can run GPU-enabled applications.
**Before you start**
* You hold the Space Administrator role on the course.
* You have enough credits in the resource pool mapped to the space. See [Billing › Resource pools and budgets](/billing/resource-pools-and-budgets.md) to verify.
* You have decided between GPU Lab Sessions and On-Demand GPU (see below).
Nuvolos supports two GPU workflows for courses: GPU Lab Sessions (instructor-scheduled) and On-Demand GPU (students start GPU applications themselves within a credit quota). Both require enabling credit-based application sizes in the space.
To enable credit-based sizes for your course, see [Administration › Space management](/administration/space-management.md).
## Schedule a GPU Lab Session
**Outcome**\
You schedule a fixed time window during which all students have GPU access, with predictable per-session pricing.
**Before you start**
* GPU access is enabled for your course (see above).
* You have an application distributed to all students.
* You have decided the session length in minutes.
In a GPU Lab Session workflow, every student gets a GPU-enabled machine during a planned session - for example, *every Monday between 10:00–12:00 on Tesla T4 cards*. Students sign in at the scheduled time and find an already-running, GPU-enabled application waiting for them. Students cannot start the GPU-enabled application themselves.
### Why GPU Lab Sessions work well
* Easy to explain to students - they just show up at the scheduled time.
* Equal opportunity - all students use machines with the same specifications during the same window.
* All students start with the same environment, but can make persistent changes to packages and settings.
* Ideal for exams or for courses where GPU access is only needed in specific windows.
* Predictable, flat pricing - once you know times and durations, your total cost is fixed.
### Schedule the session
{% stepper %}
{% step %}
In the Master Instance, open the applications view.
{% endstep %}
{% step %}
Click the ... Actions menu next to the application and select **Schedule for startup**.
{% endstep %}
{% step %}
Turn on the **Scale resources** toggle.
{% endstep %}
{% step %}
Select your desired GPU size.
The dropdown shows the credit-based sizes available in your space.
{% endstep %}
{% step %}
Configure the **Stop after selected minutes** field.
This determines how long the application runs before automatic shutdown.
{% endstep %}
{% step %}
Save the schedule.
{% endstep %}
{% endstepper %}
{% hint style="info" %}
Stop-after-minutes must be between **30 and 360 minutes**. The application stops automatically at the end of the configured duration, including the instructor's own application. Example: if scheduled start is at 10:05 and stop-after is 120 minutes, all GPU applications shut down at 12:05.
{% endhint %}
### Limitations of GPU Lab Sessions
* In course spaces, only smaller GPUs are available, such as Tesla T4 and ⅙ A10. Check the **Schedule for start** menu for the current offer.
* Currently up to **90 concurrent students** are supported. For larger classes or larger GPU sizes, contact Nuvolos support.
* Scheduled startups using GPU machines do not consider past user activity - every student in the space gets a GPU application started for them.
* Any applications already running when the session starts are restarted and moved to GPU machines automatically.
The total cost of a session is approximately *N students × session length (hours) × hourly GPU price + warmup premium*, where the warmup premium accounts for applications starting 30–10 minutes ahead of schedule due to longer machine provisioning at peak times.
## Set up an On-Demand GPU course
**Outcome**\
Students can start GPU-enabled applications themselves within a credit budget you control.
**Before you start**
* GPU access is enabled for your course (see [Enable GPU access for your course](#enable-gpu-access-for-your-course) above).
* You understand that students cannot change application sizes - every GPU size you want them to use needs its own distributed application.
* You have decided on a credit budget for the course.
In On-Demand workflows, students start GPU-enabled applications themselves when they need them. This is more flexible than Lab Sessions and ideal for assignments or homework. The instructor controls the credit budget so total cost is capped.
### **Why On-Demand GPU works well**
* Students decide when to use machines - more flexible than fixed windows.
* Equal opportunity - every student gets the same total runtime within the same credit quota.
* All students start with the same environment but can persist their own package changes.
* Predictable, capped pricing through credit quotas.
### **Distribute the right Applications**
Since students cannot change application sizes themselves, the recommended setup is to distribute **multiple applications** - typically the same software at different sizes:
* A version with an **Included size** (for example, 1 NCU) so students can work on source code without consuming credits.
* A version with a **credit-based size** (for example, Tesla T4) for code execution with GPU.
If you want students to choose between multiple GPU sizes, distribute one application per size.
{% hint style="info" %}
To save on credits and storage, install all packages students will likely need in the Master Instance before distributing. This avoids repeated installation of large libraries (such as TensorFlow or PyTorch) in every student instance.
{% endhint %}
## Configure a Credit quota schedule
**Outcome**\
You set the credit budget available to student instances, distributed over the course timeline.
**Before you start**
* Credit-based sizes are enabled in the space.
* You have decided on either fixed or tiered quota distribution (see below).
Credit quotas are set on the **Course Configuration → Student Credit Quotas** screen. Each quota row has three properties:
* **Amount** - the total Credits available.
* **End date** - the date by which the amount applies.
* **Reset flag** - determines how the amount accumulates across periods (see fixed vs tiered below).
### End-date consistency requirements
* End-dates must be in monotonous order.
* You cannot move an end-date into the past or past the next end-date in the schedule.
### Fixed quota schedule
**(Reset = Yes)**
Fixed schedules let you define maximum credit usage between specific dates. At each end-date, unused credits are lost and a new period begins.
Example fixed schedule:
| | |
|---|
| Credit limit | End date | Reset counter |
| 1.2 | 2025-09-15 | Yes |
| 1.2 | 2025-09-22 | Yes |
| 0.6 | 2025-09-29 | Yes |
Under this schedule, each student Instance can:
* Consume up to 1.2 credits from space creation until 2025-09-15 EOD.
* Consume up to 1.2 *more* credits from 2025-09-16 to 2025-09-22 EOD.
* Consume up to 0.6 *more* credits from 2025-09-23 to 2025-09-29 EOD.
* From 2025-09-30 onwards, cannot start credit-based applications.
End-of-day (EOD) is 23:59:59 UTC. Counter reset also stops any running credit-based applications at midnight in student Instances.
### **Tiered quota schedule**
**(Reset = No until final period)**
Tiered schedules let you define maximum credit usage up to specific dates without resetting between periods. Unused credits roll forward - an instance that becomes active only in the last week can still use the full final allowance.
Example tiered schedule:
| | |
|---|
| Credit limit | End date | Reset counter |
| 1.2 | 2025-09-15 | No |
| 2.4 | 2025-09-22 | No |
| 3.0 | 2025-09-29 | Yes |
Under this schedule, each student instance can:
* Consume up to 1.2 credits from space creation until 2025-09-15 EOD.
* Consume up to 2.4 credits *total* from space creation until 2025-09-22 EOD.
* Consume up to 3.0 credits *total* from space creation until 2025-09-29 EOD.
* From 2025-09-30 onwards, cannot start credit-based applications.
### Cross-instance quota usage
Quotas apply at the **space level** but enforce **per instance**. A quota of 1 credit by a given date means each instance independently can use up to 1 credit by that date. The **usage across instances** subscreen of **Course Configuration → Student Credit Quotas** gives you the full overview.
To calculate the total credit allowance of a course up to a given date: cumulative quota × number of instances in the course up to that date. The exact calculation depends on whether you use fixed or tiered.
### **Current quota - concept**
The **current quota** is whichever row in your schedule has the nearest end-date that is past today's date (inclusive). For example, if today is 2026-03-23 and your schedule has rows ending 2026-03-23 (2 Credits) and 2026-03-25 (3 Credits), the current quota is the 2026-03-23 row - 2 credits is the maximum each Instance could spend by today.
## Use a GPU Lab Session inside an On-Demand course
**Outcome**\
You schedule a one-off lab session inside a course that otherwise uses On-Demand GPU, ensuring the session's Credit usage does not exhaust the students' regular budget.
**Before you start**
* You have an On-Demand GPU course set up with a Credit quota schedule.
* You want to schedule a single lab session inside that course.
Two important caveats when running a Lab Session in an On-Demand course:
* You must explicitly select the GPU resource in the schedule configuration. Without enabling Scale resources, the Application will start without GPU.
* Lab session Credit spending counts against students' regular Credit limit — exactly like any session they start themselves. Plan accordingly.
{% hint style="info" %}
Lab sessions inside On-Demand courses can cause credit imbalance between students. Student applications are started in sequence, so different students incur different credit costs based on the order. If a student's application is started by the system scheduler, it is also stopped by the system scheduler at the end - but students who started their applications themselves before the lab session continue working uninterrupted (and are responsible for stopping their own application).
{% endhint %}
Recommended pattern: set a dedicated quota row for the lab session's day, separate from the regular quota. Example schedule with lab session days on 2025-09-17 and 2025-09-24:
| | |
|---|
| Credit limit | End date | Reset counter |
| 1.2 | 2025-09-16 | Yes |
| 0.36 | 2025-09-17 | Yes |
| 1.2 | 2025-09-23 | Yes |
| 0.36 | 2025-09-24 | Yes |
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## 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/how-to-guides/workflows-for-instructors/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.