Hugging Face, the GitHub of AI, and why teachers can browse it too

At an IT committee meeting, a panel head asks: "I hear some schools use open source models so they do not have to send data to an overseas company. Where do those models actually come from? How would we know who made one and whether it can be trusted?"

It is an excellent question, and the answer usually points to the same website.

Picture a resource cupboard shared by the whole world

Imagine every teacher on earth put their worksheets, lesson plans and marking rubrics into one public library. Each item comes with a page explaining who made it, which year group it suits, how often it has been trialled and what to watch out for. You may download it, adapt it, and put your improved version back, provided you follow the conditions the original author set.

Hugging Face is that library for AI models. It is currently the main public place where models are stored and shared, with over two million models publicly available. Engineers call it "the GitHub of AI" because it offers version history, branches, downloads and collaboration in the same way.

For a teacher the important point is not the technical architecture but this: when somebody tells you a model is good, you can go and read that model's own page instead of relying on what you were told.

There are actually three kinds of thing on the site

It looks chaotic at first because three categories live side by side:

• Models: the actual model files, plus a page of documentation. This is the main part.
• Datasets: the data used for training or evaluation. What is most worth a school's attention here is the realisation that a model learned from this kind of material, which helps explain where bias comes from.
• Spaces: small web apps other people have built, letting you try a model straight in the browser with nothing to install. This is the easiest area for teachers and the best one for classroom demonstrations.

If you only have ten minutes, start with Spaces. Find a text generation or speech recognition demo and try it yourself. It teaches more than ten articles.

What a teacher should look at

Open any model page and check four things, in this order:

1. The licence. This is the one item you cannot skip. Some models are free for commercial use, some are restricted to research, some cap the size of organisation that may use them. Using a model in class, or letting pupils reach it through the school website, needs the licence checked first.
2. The size. The page shows the parameter count, for example 8B (eight billion). This decides what hardware a school needs to run it. See the rise of small language models.
3. Whether anyone maintains it. Look at the last update date and the discussion tab. A model untouched for two years with unanswered questions does not belong in a school workflow.
4. How thorough the documentation is. That page is called the model card, and it is the subject of the next lesson, reading a model card and what GGUF and Safetensors mean.

Open source means three different things here

The most common misunderstanding is treating "open source" as a single state. There are at least three layers:

• Open weights: you can download the model files and run them, but the training data and training code are not published. Most models described as open source fall into this category, including the main models from Meta and Alibaba.
• Open with conditions: downloadable, but the licence adds restrictions, such as forbidding certain uses or requiring larger organisations to apply separately.
• Fully open: weights, data, code and training records all published. There are few of these, and they come mostly from research institutions.

When writing a funding application or a school policy, it is more accurate to write "open weight model" than "open source model".

An example from the classroom

A secondary school's Chinese panel wanted to trial AI support for marking compositions, but the panel head insisted student work must not leave the campus network. The IT coordinator did three things.

First, he filtered Hugging Face for models that support Chinese, sit under 8B parameters, and carry a licence permitting institutional use, then shortlisted three.

Second, he used the Spaces demos to paste in three old compositions with names removed, comparing the quality of feedback across the three models. This step required no installation at all and fitted into one free period.

Third, he printed the chosen model's page together with its licence terms and gave both to the principal as an appendix to the procurement recommendation. It was the first time the principal had seen a model choice backed by documents she could check, rather than by a vendor's assurance.

Three months later that model was running on a school server through Ollama, and student compositions never left the campus network. The whole thing started with one person willing to open a website and look.

What this means for your classroom

1. You can now verify claims. The next time a vendor or a colleague mentions a model name, you can read its page and judge whether the description is overstated. This is especially useful for panel heads and IT coordinators.
2. Demonstrations no longer wait for the IT department. Spaces lets you try models in a browser, so at a professional development workshop you can show live how the same prompt produces different answers from different models.
3. The licence belongs in school policy. If the school intends to rely on an open weight model long term, archive the licence terms and note them in the IT use policy. Funding reviews do ask about this.
4. Never trial with real student data. Spaces demos are run by third parties and what you paste may be logged. Use de-identified or invented content. The same principle returns in defending against jailbreaks and prompt injection.

A small experiment to run now

Paste this into any Spaces demo or AI tool, then try the same text on two or three models. The differences appear quickly:

You are a Hong Kong primary Chinese teacher. Below is a Primary 4 pupil's diary entry. Give feedback in three sentences: one praising something specific that works, one naming a single thing to improve, one suggesting what to practise next.
Do not rewrite the entry. Where you are unsure, write "teacher to verify".
[paste a short de-identified sample]

Same input, same instruction, and yet the tone and rigour differ noticeably. That difference is not random. It comes from how each model was trained and aligned, covered in alignment with RLHF and DPO.

What comes next

What that documentation page actually contains, and what GGUF and Safetensors in the filenames mean, is the subject of reading a model card and what GGUF and Safetensors mean. To revisit how a model works inside, go back to the Transformer architecture in plain language. To compare the current line-ups of the major providers, see the model database.