OLMo as an open-source base for specialist adaptation

Who this page is for

Read this page when counsel, procurement or a public-sector checklist wrote “the model must be open source” and someone has to say whether they meant the Open Source Initiative’s AI definition or a downloadable weight file. Typical readers are counsel who used those words, a platform owner who already booked another family’s GPUs, and a research or audit lead who must show how a base was derived. The page is not a ranking of OLMo against Llama or Qwen. It is not a claim that a reproduced stack extracts your fields. It is not a tutorial for re-running Ai2’s training job.

If you have not yet chosen a family, start at the models catalogue and the openness comparison. If the constraint is Meta’s community terms after adaptation, go to Llama. If the constraint is an Apache file on commercially common instruct weights, go to Qwen — then come back here if someone still meant OSAID. If the constraint is a Mistral announcement versus a revenue-clause card, go to Mistral. If the constraint is “should we shrink at all?”, go to /slm. OLMo’s job on this site is the artefacts-plus-Apache exhibit, not a quality trophy.

A useful reader can paste the procurement sentence and the task in the same note. If the sentence is “we used an open model” after ops booked Llama, you have two constraints, not one. This page exists so those two constraints stay visible. We will not merge them into a slogan.

This is the OSAID exhibit, not a quality winner

Most commercial bases on this site are open weights. OLMo is the named exception. The Open Source Initiative’s AI definition asks for the preferred form for modification: parameters under OSI-approved terms plus the data information and code needed to derive them. OSI’s open-weights note is the other citation: weights alone are not that form. Ai2 published weights plus training code and data artefacts intended for scientific reproduction. OLMo 2 adds the fully-open family claim: data, training code, recipes, evaluations and intermediate checkpoints. That is why this family is the exhibit when someone meant OSAID.

It is not a published quality winner on insurance submissions or retail attributes. We will not publish an llm.build score for OLMo versus Llama. We will not treat intermediate checkpoints as evidence the 13B card will extract your endorsements. Reproduction artefacts answer “can we study how this base was made?”. They do not answer “does this base beat our current process on unused test documents?”. Those are different questions. File them separately.

Apache-2.0 on the cited 13B card is a clean software licence for a closed product if you keep notices. That licence fact is real and useful. It is not the whole open-source claim. The open-source claim is the published stack. A team that only wanted Apache on parameters can often get that from another family. A team that wanted the preferred form should stay here and still measure the task. Do not pick OLMo to win a leaderboard argument. There is no such argument on this site.

Artefacts are the point. Apache is the notice.

The cited OLMo page states weights plus training code and data artefacts for scientific reproduction. The cited OLMo 2 page states a fully-open family: open training data, open-source training code, reproducible recipes, evaluations and intermediate checkpoints. The cited Hugging Face card, allenai/OLMo-2-1124-13B, states Apache-2.0 on code and model and points at the training repository. Those three sources are the pack this page will stand on. Other sizes exist on Ai2 pages. The identifier you will freeze is the identifier you will write down.

Keep the Apache notice with any redistributed adapter or merged image. That is ordinary Apache hygiene. It is not a naming prefix and it is not a monthly-active-user clause. Teams who already approved a community-licence family sometimes over-copy those duties onto OLMo. Do not. Read the 13B file. If you need the other bargain, read /models/llama. If you need a commercially common instruct checkpoint and you did not mean OSAID, read Qwen. Swapping the exhibit because serving is easier is a new brief, not a loophole.

Intermediate checkpoints and recipes are useful when a research or audit team must show how a base was derived. They are unused if the only requirement is “run a small model on our GPU”. Do not book an OLMo reproduction programme because someone wanted a 13B instruct for attributes. That is the commercially common path wearing an openness costume. Write which sentence you meant.

Qwen3 Apache weights are not this exhibit

Qwen3 open-weight cards are widely used as a commercial base because the official repository states Apache 2.0 on those weights. That is a real licence fact. It is a different fact from Ai2 publishing training data, training code, recipes, evaluations and intermediate checkpoints. Apache on someone else’s parameters is an OSI-approved software licence for those artefacts. It is not, by itself, the preferred form for modifying the system. OSI’s open-weights note exists so this mix-up has a citation.

If procurement said “Apache is enough”, a Qwen3 card or the current Mistral 3 announcement can be the shorter operational path. If procurement said “open source” and pointed at OSAID, Qwen3 Apache is the wrong exhibit even when the licence string matches the 13B OLMo card. Write which sentence they meant. Do not file both as “we used an Apache model”. The string matched. The stack did not.

The same warning applies in reverse. Do not tell an ops team that picking OLMo 2 13B gives them the serving recipes, community, and instruct behaviour they already have on a Qwen or Llama stack. It gives them the openness exhibit. Serving, templates and operator familiarity are a different plan. Put both cards on one page if both constraints are real. Measure the same unused pack. Then choose. Do not pretend the choice was only about quality. We will not publish a winner that lets you avoid the choice.

Size bands change serving, not the exhibit

The cited card is 13B. Other OLMo sizes exist on Ai2 pages. A 13B dense model is a real serving plan on a private box. It is not a 70B-class teacher and it is not a 1B-class handheld default. Pick the identifier from hardware you actually operate and from a written quality bar on unused test documents. Do not pick 13B because it is the card this page cites. Do not pick a different Ai2 size because a listicle said it won a public exam. Size is not a quality ranking on this site.

Research LLM sizes are often the reason ops push back. That push-back is legitimate. It is not a reason to relabel Llama as open source. It is a reason to write two constraints in one brief: the OSAID-shaped exhibit, and the box you can run. The commercial /slm page is where “should we shrink at all?” lives. This page is where “did we mean artefacts or a slogan?” lives.

Reproduction artefacts are not a specialist model

You can study how OLMo 2 was trained. That does not extract your policy fields or fill your catalogue attributes. Fine-tuning or adapters still need examples, unused test documents, and a comparison with the current process. A recipe that reproduces a base does not reproduce your desk. An intermediate checkpoint is a scientific artefact. It is not an unused pack from your wording family.

Audit teams sometimes want the stack so they can show a regulator or an internal committee how the base was derived. That is a good reason to be here. Write that reason down. Then write the task. If the task is still missing, you have a research programme, not a specialist adaptation. We will not pretend a training-code repository is a go / no-go on extracts.

Fine-tuning OLMo does not automatically publish a new training stack. Your adapters are a derivative you created. Apache-2.0 usually lets you keep them closed if you keep notices. You did not become OSAID-complete on the specialist model just because the base was the exhibit. You also did not create sovereignty. Inference location is still the box you name.

What changes in an adaptation run

A typical OLMo specialist run freezes the named allenai/OLMo-2-1124-13B base — or another Ai2 identifier you have actually written down — and trains adapters. The artefact you store is the adapter or a merged copy, the exact checkpoint identifier, the Apache notice, a pointer to the training repository if audit asked for the exhibit, tokenizer files, and notes from unused test documents. Apache does not change because the optimiser ran. The published stack does not become your specialist model because adapters exist.

If the team later wants a student in another family, Apache on the 13B card is a more ordinary distillation conversation than a community licence that forbids improving a different large language model. That is still not a weekend merge. You still need a quality bar on the teacher first and a read of the student family’s file. The distillation page owns the method. This page owns the exhibit you thought you were preserving when you adapted.

Merging simplifies a single-task image. Keeping adapters separate helps more than one product on one frozen OLMo base. Choose from the operating plan. The LoRA page is the artefact conversation. Do not ask this page for QLoRA mechanics. This page is the OSAID-shaped pack that rides with the artefact — and the warning that Qwen3 Apache is still a different exhibit.

Insurance: counsel said open source, ops booked Llama

Retail: reproducible stack versus a common instruct for attributes

When OLMo is the wrong first base

Pick another family when the organisation already standardised on Llama or Qwen operations and the only use of “open source” was a slogan. Pick another family when the serving plan is a size the card in front of you does not cover and nobody will fund a re-plan. Pick another family when the team wanted a commercially common instruct checkpoint and will not read a training repository. Those are constraint problems. They are not solved by a better adapter rank.

OLMo is also the wrong first conversation when someone wants a quality winner. We will not publish one. It is the wrong first conversation when ops booked Llama and counsel will, on a written read, accept that community bargain — in that case the Llama page is the first URL, and this page is the exhibit you did not need. It is the wrong first conversation when the team will not operate GPUs this year. A downloadable Apache checkpoint plus a public training repo is not a production plan. The inference page is the operating conversation.

What the extra artefacts are actually for

Open training data, training code, recipes, evaluations and intermediate checkpoints are the reason OLMo is the exhibit. They are not a bonus archive you must unpack before a specialist extract will work. An audit team uses them to show how a 13B base was derived: which data mixture, which recipe, which intermediate step. A production team that only loads allenai/OLMo-2-1124-13B and trains adapters still benefits from being able to point at those pages. Pointing is not re-running.

Re-running the stack is a different engagement. It needs people who can operate that recipe, storage for the data artefacts, and a reason that “we could have reproduced it” is not enough. Most insurance and retail briefs do not have that reason. They have a counsel sentence about open-source AI and a task that still needs labels. Do not staff a reproduction programme to decorate an extract pilot. Do not skip the 13B card because the recipes look intimidating.

Intermediate checkpoints matter when someone must show a derivation path or compare an earlier step with the release you will adapt. They do not matter when the only operator question is “which file do we freeze this quarter?”. Write which of those two sentences is true. If both are true, you have two workstreams: the specialist adapter, and the assurance trail. Mixing them into one GPU booking is how the pilot loses a quarter.

What handover must include

A useful OLMo handover is the adapter or merged weights, the exact base identifier, the Apache licence file from the cited 13B card or the release you actually used, a pointer to the OLMo and OLMo 2 artefact pages if the exhibit was the reason you are here, tokenizer files, and evaluation notes from unused test documents. It is not a claim that the fine-tune is itself an OSAID system, that inference is now private, or that a public exam transferred to your book.

Operators still need the base weights and a path that allows the stack. Audit still needs the artefact URLs if openness was load-bearing. Merging simplifies a single-task image. Keeping adapters separate helps more than one product on one frozen 13B base. Choose from the operating plan. The LoRA page is the artefact conversation. This page is the stack that rode with the artefact — and the sentence that Qwen3 Apache is still something else.

Procurement questions that belong in the brief

Did “open source” mean OSAID’s preferred form, or an OSI-approved software licence on weights? Which Ai2 URL and which Hugging Face identifier will we freeze? Does that identifier still state Apache-2.0 on code and model? Are we redistributing adapters or only serving internally? Where will prompts and logs sit? Has ops already booked another family? If yes, which constraint wins? Have unused test documents been reserved? Is anyone treating Qwen3 Apache as this exhibit?

Those questions are more useful than a debate about whether a research lab is “more open” than a commercial lab. The openness comparison exists so you can point at OSI’s definition without repeating it here. This page exists so the artefact pack, the 13B Apache card and the counsel-versus-ops collision have one URL.

Sources

1. Allen Institute for AI, OLMo (Accessed September 2026). OLMo is published with model weights plus training code and data artefacts intended to support scientific reproduction.
2. Allen Institute for AI, OLMo 2 (Accessed September 2026). OLMo 2 is described as a fully-open family: open training data, open-source training code, reproducible recipes, evaluations and intermediate checkpoints, not weights alone.
3. Ai2, OLMo-2-1124-13B model card (Accessed September 2026). The OLMo 2 13B card states the code and model are released under Apache-2.0 and points to the OLMo training repository.
4. Open Source Initiative, Open Source AI Definition 1.0 (Accessed September 2026). An open-source AI system must provide the preferred form for modification, including parameters under OSI-approved terms plus the data information and code needed to derive them.
5. Open Source Initiative, Open Weights (Accessed September 2026). Open weights are the published parameters of a trained network. Weights alone are not the preferred form for modifying the system.

Questions we hear first