Gondwana University Students: Using Free Cloud GPUs Wisely for Internship Training Runs

Use free cloud GPUs wisely by treating every session as something that can end without warning: save checkpoints to persistent storage, size your dataset to fit a short session, and downsample whenever a full run cannot finish and be re-run inside your time budget. In a 14-day internship, a well-planned small experiment that finishes beats an ambitious one that dies at 90 percent.

This guide is written for Gondwana University students in Gadchiroli and elsewhere who are doing an AI or machine learning internship on free notebook GPUs rather than a lab cluster. It gives you a resource-planning checklist, a downsampling decision guide, a worked 14-day example and a short list of things to confirm with your own department.

Why free GPU tiers need planning, not just patience

Free GPU access is generous for learning, but it comes with conditions that punish unplanned work. Providers differ, and their limits change, so any number quoted in a blog post can be out of date. What stays constant is the pattern:

• Sessions end. A notebook runtime can be stopped after a maximum duration, after a period of inactivity, or when the provider reclaims capacity.
• Quota is finite. Many free tiers limit GPU hours over a day or week, and heavy use can reduce your priority for the next few days.
• Local disk is temporary. Files saved on the runtime’s own disk usually vanish when the session is recycled.
• Hardware varies. You may get a different GPU, with different memory, from one session to the next.
• Internet and power at home are also limits. A browser tab that disconnects can interrupt your view of a run, and in some setups can interrupt the run itself.

Over 14 days, these constraints matter more than raw model quality. You have perhaps 10 to 12 working days, and the final deliverable is usually a short report, a notebook and a result you can explain. Plan backwards from that.

The free GPU resource-planning checklist for a 14-day AI internship

Work through this table before you start any training. Fill in the right-hand column in a text file or in the first cell of your notebook. It takes fifteen minutes and tends to save days.

Session limits: design runs shorter than the session

Never plan a single run that needs the whole maximum session. Aim for a unit of work that finishes in about half of what the platform allows, so a slow GPU or a slow data load does not push you over. If your measured time per epoch on a sample suggests a full run needs six hours on a platform that allows far less, you have two honest choices: split the run into resumable chunks with checkpoints, or shrink the problem.

Keep the browser tab open and the machine powered, but do not rely on that. Use a script or notebook structure that can restart from the last checkpoint with one cell.

Checkpointing: save more than the model weights

A checkpoint that only stores model weights lets you evaluate, but not resume training properly. A resumable checkpoint stores:

1. The model weights.
2. The optimiser state (momentum and similar buffers).
3. The learning-rate scheduler state.
4. The current epoch and step count.
5. The random-number generator state, if you care about exact reproducibility.
6. The best validation score so far and the path to the best model.

Save to a location that survives the session, then confirm it by deliberately restarting the runtime once on day one and loading the file. A checkpoint you have never loaded is only a hope.

Illustrative pattern in PyTorch style (a sketch to show the structure; adapt it to your framework and test it yourself):

# Illustrative sketch, not executed
import os, torch

CKPT = "/path/to/persistent/storage/run01_last.pt"

def save_ckpt(model, opt, sched, epoch, best):
    torch.save({
        "model": model.state_dict(),
        "opt": opt.state_dict(),
        "sched": sched.state_dict(),
        "epoch": epoch,
        "best": best,
    }, CKPT + ".tmp")
    os.replace(CKPT + ".tmp", CKPT)   # avoid a half-written file

start_epoch, best = 0, 0.0
if os.path.exists(CKPT):
    s = torch.load(CKPT, map_location="cpu")
    model.load_state_dict(s["model"])
    opt.load_state_dict(s["opt"])
    sched.load_state_dict(s["sched"])
    start_epoch, best = s["epoch"] + 1, s["best"]

for epoch in range(start_epoch, total_epochs):
    train_one_epoch(...)
    validate(...)
    save_ckpt(model, opt, sched, epoch, best)

The write-to-temporary-then-rename step matters: if the session is killed mid-save, you still have the previous good checkpoint.

Dataset size: measure before you commit

Three sizes matter, and students often check only one:

• Storage size: how large the files are on disk, including the zipped and unzipped copies.
• Memory size: how large the data is once loaded and converted, for example images turned into floating-point arrays, which can be far larger than the files.
• Time size: how long one pass over the data takes, including loading and augmentation, not only the GPU step.

If the GPU sits idle waiting for the data loader, you are burning quota without learning anything. Watch GPU utilisation during a short test; if it is low, fix loading (cache a prepared copy, reduce expensive augmentation, use more loader workers within what the runtime allows) before running anything long.

Decision guide: when to downsample your training data or model

Downsampling is not a failure. It is how you iterate fast and then spend your scarce full runs only on settings that already look promising. Use this guide at each decision point.

Four ways to downsample, in order of preference

1. Sample the rows, preserving class balance. Take a stratified subset so every class appears in sensible proportion.
2. Reduce input size. Smaller image resolution or shorter text length cuts compute sharply, though it may change what the model can learn.
3. Shrink the model. A smaller backbone or fewer layers; or freeze most of a pretrained network and train only the head.
4. Reduce epochs with an early-stopping rule. Stop when validation stops improving rather than running a fixed large count.

Always record what you reduced. A line such as “tuned on a 10 percent stratified sample, final run on the full training split” makes your report honest and easy to defend in a viva or review.

Worked example: a 14-day image-classification plan on a free GPU

This is an illustrative plan, not a record of a real run. Suppose an intern is asked to build a plant-leaf disease classifier from a public image dataset of 40,000 images, using a free notebook GPU. All timings below are hypothetical numbers chosen to show the reasoning.

1. Day 1: setup and measurement. The intern reads the platform’s current limits and records them. They copy the dataset once into persistent storage, then restart the runtime on purpose and confirm the files and a test checkpoint survive.
2. Day 2: sanity test. They overfit 100 images to confirm the data loading, labels and training loop work. Loss falls close to zero, so the pipeline is plausible.
3. Day 3: timing. On a 5 percent sample, one epoch takes, hypothetically, 40 seconds. A full epoch would therefore take about 13 minutes, and a 20-epoch run about 4.5 hours. That is too close to a session limit, so full-data experiments are ruled out until the end.
4. Days 4 to 6: model comparison on a 10 percent stratified sample. Two backbones and two learning rates are compared with short runs and checkpoints after each epoch.
5. Day 7: mid-point review. They write a half-page note: best setting so far, what was downsampled, remaining quota.
6. Days 8 to 9: scaling up. The best configuration runs on 50 percent of the data, split into two resumable chunks that each fit comfortably inside a session.
7. Days 10 to 11: final run. The chosen configuration runs on the full training split with checkpoints each epoch. One reserve window is left in case a session is lost.
8. Day 12: evaluation. Test-set metrics, a confusion matrix and a few failure cases are produced from the best checkpoint.
9. Days 13 to 14: write-up. The notebook is cleaned, the config and seed are saved, and the report states dataset sizes, hardware observed, and every downsampling choice.

The important design choice is the reserve window on days 10 and 11. Free sessions fail for reasons you cannot control, so a plan with no slack is a plan that will miss its deadline.

Daily habits that protect your free GPU hours

• Develop on CPU first. Debug shapes, data loading and metric code on a tiny sample before switching on the GPU.
• Switch the GPU off when you are only reading or writing. Disconnect or end the runtime after a run completes rather than leaving it idle.
• Log as you go. Print or save loss and metric values each epoch to a file in persistent storage, so a lost session still leaves a record.
• Use mixed precision where your framework supports it. It often reduces memory use and speeds up training, but check that your results remain stable.
• Keep a run log. One row per run: date, configuration, data size, time taken, result. This becomes the backbone of your report.
• Keep one account per person and follow the provider’s terms. Do not try to bypass limits with multiple accounts or automated keep-alive tricks; it risks losing access at the worst moment.

Gondwana University AI interns: what the published ordinance covers and what to confirm for GPU-based project work

If you are a Gondwana University student planning a GPU-heavy internship project, the first thing to know is where the university’s published internship rules actually apply. The one official document verified for this article is the university’s Ordinance No. 17 of 2017, which governs the credit-based LL.B. programme. It is a university-wide ordinance made by the Management Council, but it is written for law students: it asks for at least 12 weeks of internship across the programme, caps any one semester’s internship at four continuous weeks, and requires a diary in a prescribed format that feeds into a 6-credit Clinical paper in semester 6.

For an AI, computer science, IT or data science student, that ordinance does not set your rules. It dates from 2017 and may have been updated, so treat it as context, not as a template for your programme. Its useful lesson is practical: where a university does regulate internships, it tends to care about documentation, such as a diary, an evaluator and a defined duration. A GPU training log, saved configs and a dated run table are exactly the sort of evidence that would support any such requirement.

Whether a free, online, 14-day internship can be recorded for your programme, and in what form, is something your department must tell you. Do not assume that credit, a particular duration or a particular document is required or accepted. Free-tier computing is also your own responsibility: a university may not provide GPUs, and you should not assume lab access is available for internship work.

Use these steps to settle it in writing:

1. Ask your head of department or internship coordinator whether your programme (name it exactly) has a current internship or project regulation, and request the document or circular number.
2. Ask in an email whether a short online internship is allowed to be recorded, and what proof they want, such as an offer letter, a completion certificate or a diary.
3. Ask whether any report format, supervisor sign-off or faculty guide is required, and by what date.
4. Ask whether the university or your college offers GPU or lab access for AI projects, and what the booking process is.
5. Check the current academic calendar for your semester so your 14 days do not collide with examinations.
6. Keep the replies. A saved email is your evidence if a rule is later questioned.

Where a free 14-day internship fits into this plan

A short, structured internship pairs well with this kind of planning because the clock is fixed. If you are looking for one, CareerSwami’s free two-week online internship comes with a free offer letter and a free completion certificate after successful completion. Whichever programme you pick, apply the same discipline: decide your compute budget on day one and design your project to fit it.

Pre-run verification list: the five checks before pressing train

1. Have I measured seconds per epoch on a small sample?
2. Is my checkpoint path persistent, and have I reloaded a checkpoint after a restart?
3. Is my dataset prepared once, in storage that survives the session?
4. Will this run finish in well under the maximum session, or can it resume cleanly?
5. Do I know exactly what I will write in the report about data size and downsampling?

If any answer is no, fix that first. The cost of a wasted five-hour run is far higher than the cost of a ten-minute check.

Frequently Asked Questions

How often should I save a checkpoint on a free GPU?

Save at least once per epoch, and more often if an epoch takes long. A reasonable rule is to save as often as the amount of work you would be unhappy to repeat. Write to persistent storage and keep the last good file plus the best-scoring one.

What dataset size is safe for a free GPU session?

There is no universal number, because limits and hardware vary. Measure instead: time one epoch on a small sample, scale up to the full dataset, and make sure a complete run fits well inside a session, or can be resumed from checkpoints. Also check that the data fits in memory once loaded.

Is it acceptable to report results from a downsampled dataset?

Yes, if you say so clearly. State the sample size, how it was chosen (for example stratified), and which run used which data. Avoid presenting a number from a small subset as if it were a full-data benchmark.

My session disconnected mid-training and I lost everything. What went wrong?

Most likely the checkpoint was saved only to the temporary runtime disk, or no checkpoint was written at all. Move the save path to persistent storage, save the optimiser and epoch too, and test a restart on day one so the recovery step is already proven.

Should I use several free accounts to get more GPU time?

No. It can breach the provider’s terms and risk losing access mid-project. Plan within one account’s limits by downsampling, using smaller models and tuning on CPU first.

How do I choose a subset that does not distort my results?

Use stratified sampling so class proportions match the full data, fix a random seed, and repeat with two or three seeds if results look unstable. For imbalanced data, keep the minority class whole and reduce the majority class.

How many full training runs should a 14-day internship plan for?

A sensible target is one baseline, one improved run and one reserve run, with everything else done on small samples. The reserve run protects you against a lost session near the deadline.

Do I need my university’s permission to use free cloud GPUs for an internship project?

The published LL.B. ordinance does not address AI or computing projects, so ask your own department in writing about any rules for your programme. Separately, read the cloud provider’s terms of use to confirm your workload is allowed.

Related Artificial Intelligence guides

• Jiwaji University Students: A Mid-Internship Review Template to Self-Assess and Reset Goals
• University of Kota Students: Preparing for AI Internship Coding Screens with a Practice Plan
• F.S. University Students: Writing a Model Card for Your AI Internship Project
• All Artificial Intelligence internship guides