When AI students outgrow the sandbox: How DSTI expanded their GPU access with Hivenet

At DSTI, the first signs of a GPU access problem showed up in student work.

Before its partnership with Hivenet, students at DSTI School of Engineering used a controlled AWS educational sandbox. It gave them limited GPU access via educational cloud instances for a limited period. That was enough for small experiments, but it constrained the projects students could take further.

Faculty saw the ceiling quickly. Students could experiment on small tasks, but model limits arrived fast. The environment was controlled, the instances were small, and credits were capped. For students learning modern AI, those limits shaped what they could attempt.

The issue became more urgent for students in apprenticeship programs. They study while working within companies, where classroom knowledge is expected to translate into practical output. When GPU access was not available, some were blocked on work connected to their employers.

That was when DSTI began looking for a longer-term answer.

(This article is based on interviews with DSTI’s administrative and faculty teams after the first phase of the Hivenet rollout.)

The limit was availability

GPU access often gets discussed as a cost problem. For DSTI, cost mattered, but availability created the first pressure.

Students needed an environment they could rely on. The previous setup gave them controlled access, but not the continuity required for larger projects. That made it difficult to move from classroom exercises into real deep learning work.

The faculty lead described the previous setup as “a curated, controlled AWS educational sandbox with limited access to tiny instances and limited credits.” It was the only setup available for GPU-based experimentation, and it was not enough for students trying to run projects.

“Model limits were reached very quickly since students were working in a sandbox environment,” the faculty lead said.

That kind of limit affects the learning itself. Students simplify projects, avoid certain approaches, wait for access, or treat infrastructure as something to work around instead of something they can build with.

For early AI education, a sandbox can help. For students training models, fine-tuning, experimenting with distillation, or applying their skills in company work, the same sandbox can become a constraint.

DSTI needed GPU access that could support real student work without making computing resources unaffordable.

The search for a workable option

DSTI evaluated other providers before choosing Hivenet.

The school found a familiar tradeoff. Most alternatives came back as licensing arrangements for vendor-controlled platforms, with costs DSTI described as “non-negligible” and limited say over the type or configuration of GPU instances.

That did not fit the problem.

DSTI needed an environment that could support teaching across master ’s-level programs, handle student experimentation, and give faculty enough confidence to bring the platform into coursework.

The decision came down to several needs at once.

Price mattered first. DSTI said Hivenet’s pricing was the first thing that caught its attention. In DSTI’s estimate, Hivenet cost roughly one-third as much as the competing offers it had evaluated. That should be read as DSTI’s account of its own evaluation, not as a universal price comparison across every cloud workload.

Sovereignty also mattered. DSTI teaches data sovereignty to its students, so the choice of infrastructure had both an educational and a technical meaning. The school wanted a European partner because the provider itself would become part of the learning environment.

“Being an EU player is also a big plus for us as we are advocating data sovereignty to our students,” DSTI said. “Partnering with someone local is definitely a cause that is close to our hearts.”

Fit mattered too. DSTI needed a setup that could be shaped around its installation requirements, rather than a fixed environment with little room for adaptation.

That combination is where Compute with Hivenet became relevant. Hivenet gave DSTI access to GPU compute, but the value extended beyond hardware alone. DSTI needed affordable access, European alignment, and an environment configured around teaching needs.

DSTI described the offer in one sentence: “Local, tailor-made offering that brings affordable and accessible GPU to you.”

Why sovereignty mattered

The sovereignty angle should be understood in practical terms. DSTI did not choose Hivenet on principle alone. Availability created the original pressure. Price mattered. Setup, flexibility, and support all mattered.

That made Hivenet an even more attractive option.

Institutions work with budgets, course calendars, student expectations, faculty needs, and procurement constraints. A European provider still has to work. It still has to be affordable. It still has to be usable. It still has to make sense in the daily life of a school.

For DSTI, sovereignty was part of the decision because it connects to what the school teaches. A school that trains students in data, AI, cybersecurity, and digital engineering cannot treat infrastructure as invisible. The tools students use should align with the principles they are taught.

When Hivenet and DSTI announced the partnership, the focus was on affordable European GPU computing for students. The interviews behind this article show what that meant in practice: students had outgrown the available environment, and DSTI needed an option that matched both the work and the institution.

From access to actual use

A platform only matters in education if students and faculty use it.

DSTI rolled out Hivenet across the master ’s-level programs using the platform today: Data Science & AI, Data Engineering for AI, Data Analytics, and Cyber Security. The school plans to expand access to bachelor’s students.

The co-design phase mattered because academic infrastructure has to fit a real teaching environment. Faculty need to trust it. Students need to understand it quickly. Administrators need some ability to plan usage. A setup can be technically capable and still fail if it becomes hard to introduce into courses.

DSTI said the implementation phase was smooth. Hivenet advised the school on planning credits and expected usage, and then configured the environment to meet DSTI’s installation needs. Faculty were engaged and motivated to push the platform internally.

From the student side, the time to first use was short enough to preserve momentum. According to the faculty lead, students typically take between a few minutes and an hour to familiarize themselves with the platform and start running jobs.

That detail matters. In a classroom, time lost to setup drains attention from the work students are meant to do. A GPU platform for education has to do more than provide raw access. It has to help students cross the distance between “I have an account” and “my job is running.”

Hivenet’s public documentation covers the practical steps for creating a first Compute instance, and its reference docs list the current GPU types and sizes. For DSTI, the important point was that this infrastructure could become part of the teaching environment without taking over the teaching itself.

What changed for students

Once students had more usable access to GPUs, the category of work changed.

DSTI students are now mainly running deep learning training jobs on Hivenet. One demanding example from the faculty lead was fine-tuning Flan-T5-large on a 10,000-row dataset for a language translation task.

Students are also working across a mix of inference, fine-tuning, training, and teacher-student distillation.

That range shows a shift in ambition. The partnership did not simply make old exercises faster but gave students room to work on projects that were previously out of reach.

“GPU access has allowed them to work on real deep learning projects, which were otherwise impossible for them to do,” the faculty lead said.

That is the central educational change. Students can now attempt real deep learning work. They can move closer to the conditions they will face in research, engineering teams, and applied AI roles.

In AI education, that difference matters. Students do not learn practical judgment by staying inside small examples forever. They learn it when models take time to train, when data has to be prepared, when configuration matters, when jobs fail, and when choices about scale and method have consequences.

Compute access supports teaching by letting students run the kinds of work they are studying.

The hackathon as a test

The clearest public example came through the DIRISI Hackathon.

According to DSTI, students were selected to participate alongside a small group of institutions recognized for their AI programs. The challenge involved training deep learning models on time-series data to predict network anomalies. Students needed a GPU environment to build and train their solution, and DSTI gave them access to Hivenet.

They placed second overall, according to DSTI.

This is the strongest example of success because it created a clear before-and-after. DSTI was the same institution that had students constrained by a limited sandbox, and could now support students training deep learning models for a demanding applied challenge.

The Hackathon is not the whole story, either for us at Hivenet or for DSTI. Most student learning is less public than a competition result. It shows, however, what becomes possible when students have access to infrastructure that matches the level of work being asked of them.

A sandbox can introduce concepts. A usable GPU environment lets students test those concepts under pressure.

The friction that remains

The partnership worked well enough for DSTI to renew, but the experience still has practical friction.

DSTI’s faculty lead pointed to one area where students need more support: SSH connections and key creation. Less experienced students can slow down during setup, especially if they are not used to this type of environment.

That detail has real teaching consequences. In a technical course, a student blocked by the SSH setup is blocked before the learning task begins. If enough students hit the same point, it can change the rhythm of a class.

Hivenet’s docs include guidance on generating and adding SSH keys on Linux, along with other setup steps, and the interface already provides quick tips. DSTI’s feedback is that students less familiar with these workflows would benefit from more detailed documentation and support.

As with all partnerships, ours with DSTI is still a working deployment, with the normal setup details that come with real infrastructure. In education, those details matter because students arrive with different levels of technical confidence.

The goal is to reduce that friction so students can spend less time negotiating access and more time doing the work.

Why DSTI renewed

DSTI has already renewed the partnership with Hivenet. The school described the renewal as “a show of mutual trust.”

The clearest internal signal, according to DSTI, is usage. The school also described “genuine excitement” in the student body. Those are not benchmark numbers, but they are meaningful in an academic environment. A platform that students avoid has failed, even if it looks good in a procurement process. A platform students use changes what faculty can assign and what students believe they can attempt.

DSTI now plans to expand the partnership to bachelor’s students. It also expects to bring Hivenet into additional AI-related courses, including Artificial Neural Networks and Data Ethics.

That’s important because not every ethics course requires GPU compute. For DSTI, the broader question is about coherence. Students are learning AI, data, cybersecurity, and sovereignty inside a real technical environment. The infrastructure is part of that world.

That is why the partnership is more than just a cheaper way to rent GPUs. For DSTI, it is part of the school’s ability to teach modern AI without asking students to work within limits that no longer match the field.

What the DSTI case shows

DSTI’s story is not a universal template. Different institutions have different needs. Some require managed notebooks. Some need dedicated clusters. Some need strict compliance controls. Some need occasional access to GPUs for a small group of advanced students.

But the pattern is recognizable.

Students are being asked to learn AI in more practical ways. Faculty are being asked to prepare them for work that depends on real infrastructure. Institutions are being asked to control costs while maintaining sovereignty, compliance, and availability. A controlled sandbox that works for small tasks may not hold when students move into more demanding AI work.

For DSTI, the limit became visible when students started asking for help. They needed access that could support coursework, experimentation, and apprenticeship-related work. Faculty needed an environment that could support real deep learning projects. The institution needed a provider that made sense financially and aligned with its European position.

DSTI chose Hivenet because those needs came together in one workable arrangement.

The value of the partnership is clearest in the movement of the story: students went from hitting limits in a sandbox to running deep learning training jobs, fine-tuning models, using GPU access in a national hackathon, and preparing for broader access across the school.

That is a useful lesson. In AI education, infrastructure shapes what students can build, what faculty can teach, and whether a school’s technical environment matches the work it asks students to do.

When students outgrow the sandbox, GPU access becomes part of the education.

---

Explore Compute with Hivenet for academic AI programs, or talk to Hivenet about GPU access for teaching, research, and student workloads.