Running models in school with Ollama and LM Studio

Short answer: running a model on campus is technically easier than people expect — install a tool, download a model, type one command and it works. The hard part is everything nobody mentions afterwards: who maintains it, who backs it up, where it sits on the network, and who sees it when a student use goes wrong. This lesson covers both halves.

It starts with "let's just try it"

On the staff development day before term began, a Physics teacher asked the IT team over lunch: "I hear you can install AI on a computer and use it with no internet at all. Is that real?"

The IT coordinator demonstrated it on his own office machine that afternoon. From starting the download to the model's first reply took under twenty minutes. The reaction in the room was: "That's it?"

Yes, and no. Getting it running really does take twenty minutes. Getting 800 students using it reliably is a different project. This lesson walks both stretches of the road.

Two tools, one analogy

If the model is a photocopier:

• Ollama is the control panel on the back, operated by typed commands. You tell it what to do one line at a time. Not pretty, but reliable, callable by other programs, and suited to running continuously for the whole school.
• LM Studio is the touchscreen on the front of the same machine. Buttons, dropdowns, and a way to search and compare models in the interface. Suited to a teacher trying things on an office computer without memorising any commands.

Both do the same underlying job: download an already-quantised model file (quantisation is lesson 21, the GGUF format is lesson 12) and run it on your graphics card. Only the interface, and who it is for, differs.

The twenty-minute hands-on

Here is the most basic Ollama flow. The commands are the same on Windows, macOS and Linux:

# 1. pull a small model (a few minutes the first time, depending on your line)
ollama pull llama3.2:3b

# 2. chat with it directly; type /bye to leave
ollama run llama3.2:3b

# 3. see which models are on this machine and how much space each uses
ollama list

# 4. see whether a model is currently loaded in memory
ollama ps

# 5. remove it afterwards to free disk space
ollama rm llama3.2:3b

To let other machines on campus (or the Edor.ai platform) reach this server, Ollama exposes a local service port. A quick check that it is alive:

# confirm the service responds
curl http://localhost:11434/api/tags

# test generation with one prompt
curl http://localhost:11434/api/generate -d '{
  "model": "llama3.2:3b",
  "prompt": "Explain buoyancy to a Primary 5 class in three sentences",
  "stream": false
}'

In LM Studio there is no typing: search for the model name in the app, press download, pick it in the chat tab and start. To let other programs call it, switch on the local server option in settings.

Hardware expectations, as ranges rather than promises

This is where schools are most often misled. There is no universal "X gigabytes is enough" rule, because the requirement depends at once on model size, bit width and context length:

• Three billion parameters at 4-bit: in the region of 4 GB to 6 GB of graphics memory. Many schools already have teacher or multimedia-room machines that clear this.
• Seven to eight billion at 4-bit: roughly 6 GB to 10 GB. This is the sweet spot where teachers find daily use comfortable.
• Reading a long document at once: memory needs rise further and faster than expected. The same model taken from a 4K to a 32K context can consume several more gigabytes.
• A machine with no discrete graphics card: it will still run on the CPU, but far more slowly. Fine for a demonstration, not for serving students.

The other dimension routinely forgotten is how many people use it at once. One model on one card serving one teacher feels fluent; the same card serving thirty students means queueing. Supporting a full class at the same time requires concurrency planning, or a decision to keep student-facing work in the cloud.

An example from the classroom

One secondary school put its on-campus model to a very specific use: English vocabulary and sentence-pattern practice.

The reasoning was deliberate. The task is highly repetitive (high volume, each exchange short), low risk (no grades, no personal data) and undemanding on precise reasoning. Those three conditions together describe the ideal use of an on-campus quantised model.

What they did: one machine with a single consumer graphics card in the server room, running an eight-billion-parameter model at 4-bit; in the Edor.ai admin panel, the English vocabulary practice module was switched to the local Ollama provider, and everything else stayed on the cloud.

Three months of observation:

• The teacher interface was indistinguishable, and most staff did not know the model behind it had changed.
• When an external fibre fault took the whole school offline for half a day, vocabulary practice carried on while other online tools stopped. That accident turned out to be the most persuasive demonstration of all.
• Student conversations still went through the platform's safety gating and teacher monitoring. Running the model on campus does not mean the gate can be removed — see AI guardrails.

Four things nobody mentions

1. Updates. Both the models and the tools update. With nobody responsible, in two years you have a system no one dares touch. Put a check date on the school calendar.
2. Backups. Model files can be re-downloaded; your settings, prompt templates and records cannot. Plan the backup strategy at the same time.
3. Network placement. Which segment does this machine sit on, who can reach it, and is anything exposed externally? An inference server accidentally open to the internet is a real security risk.
4. Power and cooling. A graphics card at sustained full load draws power and generates heat. Confirm the server room can handle it before you commit.

What this means for your classroom

1. Trial before purchase. A small model on an existing computer, tried by a few colleagues for a fortnight, tells you more than any vendor deck.
2. Choosing the right task matters more than choosing the right model. Repetitive, short, low-risk, ungraded work belongs on campus; marking, long reasoning and outward-facing documents still deserve the best model plus teacher review.
3. Offline capability is a genuine classroom safeguard. On the half-day the network fails, you will be glad something does not need the outside world.
4. Local does not mean safe. Keeping data on campus answers "where does it go", not "what did the student ask and what did the AI say". Gating and monitoring remain compulsory.

How this works inside Edor.ai

Edor.ai lists local Ollama as one of its switchable providers, alongside OpenAI, Azure OpenAI, Anthropic and Poe. An administrator enters the campus server address and can point selected modules at the on-campus model, with the teacher and student interfaces unchanged.

Three points are worth stressing. First, mixing is normal: a school does not have to move everything in-house and can decide module by module. Second, the safety mechanisms still apply: even with inference happening on campus, four-layer gating, teacher monitoring and the ai_audit_logs audit trail keep working, and usage and safety actions appear in the same report. Third, a full on-premises deployment of the whole platform, not just the model, is also supported with identical features — see on-premises versus cloud deployment.

In summary

Running a model on campus is no longer a research-lab privilege; one computer and twenty minutes gets you started. But between "it runs" and "the whole school relies on it" lie networking, permissions, updates and backups — unglamorous work that decides whether the project survives. Plan it as a small IT system, not a weekend experiment.

The next lesson narrows the scope further, from the campus server to the device in a student's hand: on-device AI and Apple Intelligence. The previous lesson is quantisation.