Why Training Institutions Choose Open Source Over Token-Billed Platforms ​

We · November 2026

This is the seventh article in the "Open Source & Commercial Use" series. The previous six look at the open-source side: Why Companies Open Source covers the motives, Big-Tech Model Licenses in Practice covers the clauses, and Do Schools and Research Labs Need to Worry About Licenses? covers the obligations that show up in teaching. This one looks at the other side of the table: why an institution that has to make a decision usually ends up back on the open-source path — and what that path then charges it.

We don't evaluate any institution, we don't compare the output quality of specific platforms, and this is not legal advice. The cost section describes structure only, never figures: platform pricing changes monthly, and any specific number should be re-checked on the day you sign.

1. The conclusion first: three reasons, and "cheaper" isn't one of them ​

When we talk to institutions running AIGC courses, the most common opening line is "we use open source because it's cheap." But once you separate out three sets of books, cheap usually isn't the decisive factor — in some scenarios open source isn't cheap at all. What pulls people back to the open-source side is three other things.

Teachability. What a course can teach is something that can be taken apart, reproduced and inspected. With a local program, a student can see which directory the model file sits in, what a parameter actually changes, and why this step is slow; a teacher can set homework like "drop the sampler from 20 steps to 8 and compare the two images." A wrapped API can't do that: it absorbs the whole process into a black box, and the student receives a result rather than a process.

This is not an argument about output quality. Commercial platforms produce better results on many tasks, and we're not comparing that. The argument is about course shape: if the assessment is "hand in an image," anything works; if the assessment is "explain why this image looks the way it does," a black box won't hold up.

Cost shape. Billing per token, per generation or per concurrent seat is a variable cost: the more you enrol, the more you pay, roughly in line. Local deployment is an up-front fixed cost: machines bought, environment installed, and after that one student or a hundred cost about the same — electricity plus depreciation.

That difference sets the shape of the margin. Under variable cost, a price increase or an enrolment spike eats margin directly. Under fixed cost, extra students add almost nothing, but the first payment goes out before the revenue does, and the machines stay there whether or not the class fills up.

So the question isn't which one is cheaper. It's which risk you'd rather carry: paying a little more forever without laying anything out, or laying out a lot up front and then being nearly marginal-free.

Asset ownership. Several things a student produces locally are files they can walk away with: a LoRA weight of a few tens of megabytes, a voice model they trained, a workflow they tuned. They live on the student's own machine and still open after the course ends without a platform account.

Output on a platform is usually not a file, it's a record: stored under an account, governed by the terms of service — whether you can download it, whether you can sell it, whether it still exists when the service stops. This matters most for students who take client work after graduating: if what they made depends on an account they've stopped paying for, they didn't actually take anything with them.

2. "Cheaper" is where this goes wrong: local is not free ​

Now the other side of the same ledger, because without it this article is a pitch. Here is what an institution choosing open source actually pays, and these items routinely exceed budget:

Every row here is people, not software fees. It's also why we keep our own claim narrow: the two rows we can compress are setup/support labour and failure rate — installing the environment, aligning versions, making errors rarer. We can't compress hardware purchasing, and we can't stand in for the course.

In one line: open source isn't free; it swaps "pay a little on every call" for "invest a block of labour and hardware in advance." If a programme is short, the cohort small, and the course only teaches as far as "produce a result," that swap probably doesn't pay off.

3. The student side: the same decision, a different set of books ​

Institutions count margin. Students count something else, and the two ledgers frequently disagree.

The three hardest items on the student side:

Thin margins, many small orders. Most students enrolling in an AIGC course are already on a tight budget. If the course additionally requires a few thousand yuan on a machine with a discrete GPU, or a monthly subscription, that money isn't written into the tuition — but it is written into "can I actually get through this." Whether an older machine still works is the thing students care most about before enrolling and least want to judge themselves.

Complaints about second charges. A large share of public complaints about AIGC courses aren't about teaching quality; they're about "keep paying after you enrol": extra compute credit, extra models, extra money for advanced modules. Students are far more sensitive to a structure of continuing charges than to differences in teaching, because the charges are felt every month.

Skills have to be portable. What a student trades their time and money for is a capability that lives with them. If every operation happens inside a web page, then when the course ends and the account stops, they have no work, no environment, and no reproducible process. On the local path, at least the environment and the output are on their own disk.

And one more thing that never makes it into marketing material but shows up in every support queue:

A student who can't install the software doesn't blame the software. They blame themselves.

This is the largest hidden cost of local deployment and the one institutions should handle first. Same machine, same installer — an error message almost always reads like "you did something wrong." It converts directly into frustration, an urge to withdraw, and a bad review. Inverted, that's also why "can it be installed" decides the experience more than "which model is stronger" on the local path.

4. When the two ledgers disagree, split by stage ​

Put the two sets of interests side by side and they aren't the same:

There's no "correct answer" in this table, only choosing per stage. The split we've seen hold up best:

• Enrolment and trial lessons on the cloud. A trial needs a result in ten minutes; it must not stall on installation. A packaged platform is the right call at this stage.
• Teaching locally. You need things that can be taken apart, modified and inspected, and process-based homework.
• Post-course work and client delivery locally. The work belongs to the student, the environment belongs to the student, and the institution doesn't carry the "they kept charging me" complaint.

That hybrid isn't a compromise. It's using each side where it's strongest. The other way round: an institution that runs everything on a platform loses control of the teaching process; one that runs everything locally hands its conversion rate to the student's own computer.

5. When a commercial platform is the right choice ​

Don't turn open source into dogma. In these situations, the platform is the correct answer:

1. Video and digital-human work. Large models, high VRAM floors, high failure rates — local delivery cost frequently exceeds the subscription. This doesn't mean skipping the theory: get a minimal example running locally, leave volume production to the platform.
2. Courses that teach only as far as "produce a result." If the assessment is the deliverable, a black box isn't a teaching problem.
3. Work that needs a deliverable, dependable service. Corporate training, SLA requirements, demos that must behave identically on every machine — local can't promise identical behaviour across machines.
4. Topics where models churn fast. If your content follows upstream releases, the maintenance cost of self-hosting stays above the cost of renting.
5. When the lab itself doesn't meet the bar. Old machines, insufficient memory and disk, not enough bandwidth — pushing local here converts straight into a refund rate.

One more thing worth flagging separately: some "local software" is on the cloud by default. It installs on your machine and then calls an online LLM and online speech synthesis when it runs. The low VRAM requirement isn't there because the maths is fast; it's there because the maths isn't happening locally. That isn't a trick — it's often sensible design — but it means "can this run locally" has to be asked application by application, not inferred from "this software is open source." Before an institution writes "runs entirely locally" into its materials, it should confirm the critical path is actually offline.

6. The license row institutions will get asked about ​

Choose the open-source side and you inherit a licensing question, and it's a different kind of question from a subscription. Three things:

Software, model and output are three layers. The software carries an open-source license (MIT, Apache, GPL and friends). The model weights carry a second, separate license. Whether the generated output can be registered for copyright and whether it must be labelled is a third question. None of the three covers the others.

"Open source" doesn't mean "commercial use allowed." Different files in the same repository under different licenses is normal: a model family often ships a smaller variant under Apache 2.0 while the development or larger variant is under a non-commercial research license, and sometimes different sizes in the same generation differ. The series already covers this clause by clause in Big-Tech Model Licenses in Practice, and Do Quantized, LoRA, or Fine-Tuned Models Still Fall Under the Original License? covers whether the adapter your student trained counts as a derivative.

Teaching and delivering are different risk levels. Demonstrating a model once in class and teaching students to use it for paid client work are not the same thing. Wherever a course says "you can take this and sell it," the license row has to be checked first. The full scenario list is in Do Schools and Research Labs Need to Worry About Licenses?.

Our advice is plain: put "can this model be used commercially" into the syllabus instead of waiting for a student to ask. For any specific model release, the LICENSE file in the repository governs; translations have no legal effect, and neither screenshots nor hearsay count.

7. Two checklists ​

Eight questions an institution should have answered before deciding:

1. Is the assessment "hand in a deliverable" or "explain the process"?
2. How does the cost per student move with enrolment — linearly, or up front?
3. How much setup and support labour are you budgeting, and has it been converted to money?
4. What happens to the machines that fail, who handles them, and how fast?
5. After the course, does the student walk away with files or with account records?
6. Do the models used in the course allow the student to deliver commercial work?
7. Which stages are genuinely better on the cloud — and are you willing to say so in your materials?
8. Would you disclose the machine requirements word for word, the way you disclose the refund policy?

Four questions a student should ask before enrolling:

1. Is my machine Windows or Mac, Apple silicon or Intel?
2. Does the course require inference or training? The thresholds often differ by several times.
3. What's the process if installation fails, is it defined, and does the cost land on me?
4. Besides tuition, do I pay again — compute, membership, models, software?

8. Where we sit ​

Our claim in all of this is deliberately narrow: it installs, it runs, it errors less. We don't build courses, we don't judge which platform produces better output, and we don't promise any amount of client work afterwards.

We do three things: install a local environment correctly for your system and hardware; align application and model versions to something reproducible; and make the common errors rarer and legible when they happen. Whether an institution should go local or platform, and which model a course should use, are questions of course design and budget — the answer stays with the institution.

If one of those three things is exactly what's blocking you, the two closest articles on this site are Why Is Your Locally Deployed AI App So Slow? — the difference between "it runs" and "it runs in time for homework" — and the application catalogue, where each entry carries its own system requirements. Both are about the ceiling of one specific machine, which is the other face of the same ledger.

Editorial note: we do not evaluate institutions, do not compare platform output quality, and do not quote prices. License statements follow each repository's LICENSE file as of November 2026 and do not constitute legal advice.