Running models on campus with Ollama and LM Studio

On the last Friday before term, the IT coordinator installed Ollama on a spare multimedia-room machine in the corner of the staff room. The Physics teacher beside him asked: "If the fibre line goes down, can this still run vocabulary drills for my class?" Seventeen minutes later the model explained buoyancy in three sentences. He said: "That's it? Then why are we still waiting on a vendor quote?"

Running a model on campus is technically easier than most schools expect, but between "it works" and "the whole school can rely on it" sits a full chain of IT management. This is the hands-on lesson in the local deployment module, following quantisation in lesson 21; the next lesson narrows the scope to the device in a student's hand.

---

The institutional range and the tasting hob

The same quantised model can be served through two tools. The difference is who operates it and where it lives.

Ollama is the institutional range in the central kitchen: plain controls, fired by commands and APIs, but steady heat and able to run all day. It belongs in the server room, where Edor.ai or other campus systems can place orders on a schedule. LM Studio is the induction hob in the staff room: buttons, previews, and the freedom to swap pans (models) while you taste. It suits a panel head or the IT team comparing candidates before anything goes live.

Underneath, both do the same job: download a quantised GGUF weight file (format details in lesson 12) and run inference on a graphics card or the CPU. Choosing Ollama or LM Studio is not a religious war; it is the split between tasting recipes and feeding the school.

Getting it running on an old machine

The example below uses Ollama. The commands are identical on Windows, macOS and Linux. Allow twenty minutes the first time.

# 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
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 campus machines or Edor.ai reach this server, Ollama exposes port 11434 locally. A quick self-test:

curl http://localhost:11434/api/tags

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 a model in the app, download it, and open the chat tab. To let other programs call it, switch on the local server option in settings. Many IT teams use LM Studio to let the English panel try two eight-billion-parameter models, then pull the winner onto the server with Ollama.

Four admin checks before you call it live

Once it runs, do not report to the principal that the whole school is ready. Confirm at least four things: which VLAN the machine sits on, whether the firewall has accidentally exposed 11434 externally, who checks for updates each month, and whether model files and settings sit in the backup schedule. Model files can be re-downloaded; your prompt templates and configuration cannot.

The memory bill and the queue

There is no simple rule like "eight gigabytes is enough". You need model size, bit width, context length and concurrent users in the same sum.

Three billion parameters at 4-bit quantisation needs roughly 4 GB to 6 GB of graphics memory — many schools already have teacher or multimedia-room machines that clear that bar. Seven to eight billion at 4-bit sits around 6 GB to 10 GB, the band where subject teachers usually find daily use comfortable. The same model taken from a 4K to a 32K context can consume several more gigabytes, faster than people expect.

A machine with no discrete graphics card will still run on the CPU, but far more slowly. Fine for a demonstration, not for serving students. The other dimension is concurrency: one card serving one teacher feels fluent; the same card serving thirty students at once means queueing. To support a full class doing AI practice at the same time, plan for multiple cards, a queue, or keep high-concurrency work in the cloud.

Getting an old machine to run only proves the kitchen can light the burners. Feeding eight hundred people still means counting hobs, dish speed, and what happens when the power fails.

Mixed deployment in practice

One Band 2 secondary school split the work deliberately. English vocabulary and sentence-pattern practice — repetitive, short, ungraded, no personal data — was judged suitable for an on-campus model. The IT team ran an eight-billion-parameter 4-bit model on a single consumer card in the server room, and the Edor.ai admin panel pointed only the English vocabulary module at local Ollama. Composition feedback and long analysis stayed on the cloud.

Three months later the observations were concrete. Most teachers noticed no interface change. When an external fibre fault took the school offline for half a day, vocabulary practice carried on while other online tools stopped — an accident that became the most persuasive on-campus argument of the term. Student conversations still passed through the platform's four-layer gating and teacher monitoring. A model on campus does not mean the gate can be removed; lesson 24 covers that in detail.

Edor.ai lists local Ollama alongside OpenAI, Azure OpenAI, Anthropic and Poe as a switchable provider. An administrator enters the campus address and routes modules individually, with usage and safety actions in the same report. A full on-premises deployment of the whole platform — not just the model — is also supported; see on-premises versus cloud deployment.

Where people go wrong

• Rolling out to the whole school the day it runs once. A trial with no record of who used it, for what, and where it stalled leaves procurement to guesswork. Self-check: after a fortnight, can you name at least two scenarios that only the on-campus model solves? If not, you are not ready to buy a server.
• Pushing grading and long reasoning onto a small on-campus model. Quantised campus models suit short, repetitive, low-risk work. DSE composition marking and cross-topic reasoning still deserve a flagship cloud model plus teacher review. Self-check: if the AI gets it wrong, is the consequence "students laugh" or "a number appears on a report card"?
• Assuming local deployment makes data automatically safe. Keeping data on campus answers where it goes, not what the student asked or what the AI answered. Gating, monitoring and ai_audit_logs still need to be on. Self-check: with gating switched off, can the IT team reconstruct last week's lesson conversation from the audit trail?

Try it once

What to do: On your office or IT-room machine, install Ollama, pull llama3.2:3b, test it with a prompt you would actually use in class (for example, "Explain adding fractions to a Primary 4 class in under 100 words, no analogies"), then hit /api/generate once with curl and note the response time.

What to hand in: A short record — three lines is enough — with the output of ollama list, the first part of the curl response, and the seconds from question to first token on your phone stopwatch.

How you know it worked: The model completes three small prompts you choose from different subjects, each within 30 seconds; curl returns valid JSON containing a response field. If it takes longer, note whether the limit is hardware or model size. That record is itself the evidence you take to the principal for hardware.