Phi SLM as a base for task-focused fine-tuning

Who this page is for

Read this page when the statement of work already points at a Phi checkpoint, or when someone has written “use a small Microsoft model” and you have to turn that slogan into a card, a licence line and a task. Typical readers are counsel who were told the weights are MIT and therefore easy, a platform owner who will store adapters next to a frozen base, and a specialist who will judge whether a queue label or a SKU attribute is actually right. The page is not a tutorial for training scripts. It is not a ranking of Phi against Gemma, Qwen or a compact Llama. It is not the commercial argument for shrinking every workload.

If you have not yet chosen a family, start at the models catalogue and the openness comparison. If the only requirement is a reproduced training stack, go to OLMo. If the only requirement is an Apache file on commercially common instruct weights, go to Qwen or the current Mistral 3 announcement. If the only requirement is Meta’s community bargain after adaptation, go to Llama. If the only question is whether a smaller model is the engagement at all, go to /slm. Phi’s job on this site is the two cited MIT cards as bases for a written, narrow task.

A useful reader already has a one-sentence job a specialist would recognise: route this submission family into the queues we already operate; fill these catalogue attributes from supplier text; extract these fields under review. If that sentence is still “try Phi because it punches above its size”, you are on the wrong page until the job exists. We will not invent the job from a Microsoft brochure.

Cite the cards, not a “small models win” slide

Microsoft published the phi-4 and Phi-4-mini-instruct cards with public exam numbers. Those numbers are a vendor measurement on public tests. They are not a result on insurance submissions. They are not a result on retail SKU attributes. They are not unused test documents from your desk. If the brief is “use Phi because small models win” or “use Phi because it punches above its size”, rewrite it as “use this card, this MIT notice, this task, this review path”. Until those four things are named, you do not have a Phi project. You have a slide.

The commercial /slm page is where “should we shrink at all?” lives. This page will not steal that question. A team that has not written a quality bar against the current process is not ready to pick a 14B or a mini instruct card. Shrinking is a later decision, taken after the task is narrow enough to fail in public. Phi is one candidate family when that decision is already on the table, or when procurement already named these weights.

Other Phi generations exist. This page will not generalise MIT, size or behaviour from a blog post about an older Phi, and it will not invent a later card. The citations are the microsoft/phi-4 card and the microsoft/Phi-4-mini-instruct card, plus OSI’s Open Source AI Definition and open-weights note. If someone arrives with a different Phi identifier, that identifier is a new read. Family name is a filing label.

MIT is the licence story, not the quality story

The cited phi-4 card describes a 14B dense decoder-only model released under the MIT licence. The cited Phi-4-mini-instruct card states the model is licensed under MIT and that the card does not restrict or modify that licence. For a closed product and for handing over adapters, MIT is a short conversation: keep the copyright notice and the permission notice. That is a better licence conversation than a bespoke community agreement for teams that want the fewest special clauses. It is still a conversation. It is not a quality ranking.

MIT on the weights does not publish the preferred form for modifying an AI system. The Open Source Initiative’s AI definition asks for parameters under OSI-approved terms plus the data information and code needed to derive them. OSI’s open-weights note is the other citation: published parameters are not the whole artefact. You can download, run and adapt these Phi cards. You do not, from those cards alone, receive Microsoft’s training stack. If someone required OSAID open source, Phi is usually the wrong exhibit even though MIT is an OSI-approved software licence on the released files.

Write the distinction into the brief before anyone books GPUs. “MIT, so we are open source” is three ideas glued together: you can download parameters, you can often commercially adapt them if you keep notices, and the project meets OSAID. Only the first two can be true here. A later adapter file does not convert the family into a reproduced stack. A smaller parameter count does not convert it either.

Do not copy naming prefixes, “Built with” lines or monthly-active-user thresholds onto these cards. Those duties live on another family’s page. Keep the MIT notice. That is the hygiene. If counsel already approved a community-licence family and is now “just swapping to Phi”, make them read the new files. Swapping families is a new legal read, even when the new read is shorter.

Two cited cards, two footprints, one task test

Phi-4-mini-instruct is the smaller instruct card. It enters an SLM conversation because of footprint, not because a slide said mini models are the future. microsoft/phi-4 is the 14B dense decoder-only card. It sits in the small-LLM / large-SLM band: still compact next to a 70B-class teacher, still a real serving plan on a private box. Neither card is a routing engine. Neither card is a catalogue classifier. The class label in the table below is a hosting hint. It is not a quality rank.

Pick the card from hardware you actually operate and from a written quality bar on unused test documents. Do not pick the mini because it is cheaper on a spreadsheet that assumed it would meet the bar. Do not pick 14B because a listicle said the dense model won a public exam. A Phi that almost meets the bar is not a saving. It is unfinished work that still needs a larger model, a retrieval setup, or a human queue. Compare the candidate with the current process. The current process is the baseline, not last year’s Microsoft table.

Instruct versus base matters for the first prompt you write, not for the licence. The mini card is published as instruct. The 14B card is the dense decoder-only exhibit cited here. Write the identifier you will actually freeze. A fine-tune that silently swaps templates or tokenisers is a different serving plan. Operators who load a random quant pack often drop the MIT notice and the template together.

Size bands change serving, not the MIT notice

Compact instruct cards change batch size, latency and where you can place the box. A 14B dense card changes them again. The MIT notice does not change because the parameter count changed. Size is not a quality ranking on this site. Size is not a reason to skip unused test documents. Size is not a reason to treat public exam scores as your queue result.

If the deployment target is a small private box, the mini instruct card may be the candidate, not the 14B. That is a hosting decision. Measure it on the same unused pack. If the deployment target is a shared GPU already serving an 8B-class or 14B-class model, starting at mini because “Phi is the SLM brand” is how you spend a month proving a miss you could have predicted from the task shape. The /slm page owns the shrink question. This page owns which Phi grant you thought you had.

When a small Phi is the wrong shrink

Do not start with Phi because a slide said “SLMs are cheaper”. Start with Phi when the task is classification, extraction or constrained drafting, the review path is named, and you can afford to lose if unused test documents say keep a larger model or keep the current process. Those are the jobs where a 14B or a mini instruct card can be a candidate. They are still jobs you measure. They are not jobs the card has already won.

Open-ended advice is the wrong shrink. A model that answers “what should we do with this customer?” or “what cover should we offer?” is not a routing or attribute job. Changing policy text is the wrong shrink. Rewriting a wording, inventing an endorsement, or “improving” a clause is not classification. Work that still needs unused headroom — long context across a binder, multi-document reconciliation, advice a handler is not allowed to automate — should stay on a larger LLM, a retrieval setup, or a human queue. Shrinking first wastes the pilot.

A wrong shrink also looks like this: the team wanted cheaper tokens, picked Phi, and left the job as “help with submissions”. Help is not a label set. Help is not an exception path. Help has no unused pack because nobody can say what a good answer is. Send that brief back. The /slm page will tell you whether shrinking is even the engagement. This page will not launder an unscoped job through a MIT file.

What changes in an adaptation run

A typical Phi specialist run freezes the named microsoft/phi-4 or microsoft/Phi-4-mini-instruct base and trains adapters. The artefact you store is the adapter or a merged copy, the exact checkpoint identifier, the MIT notice, the tokenizer and chat template, and notes from unused test documents. MIT does not change because the optimiser ran. Inference location does not change because adapters exist. Public exam scores on the Microsoft cards do not become your queue result because you trained.

If the team later wants a student in another family, MIT on these cards 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 permission to use the teacher outputs, a written quality bar on the teacher first, and a read of the student family’s file. The distillation page owns the method. This page owns which Phi grant you thought you had, and the warning that a published Microsoft student or a later Phi generation is a different artefact.

Merging simplifies a single-task image for one queue or one attribute schema. Keeping adapters separate helps more than one product on one frozen Phi base. Choose from the operating plan. The LoRA page is the artefact conversation. Do not ask this page for QLoRA mechanics; that method has its own URL. This page is the MIT notice and the task-candidate warning that ride with the artefact.

Insurance: submission routing into a queue you already have

Retail: SKU attributes, not a catalogue oracle

When Phi is the wrong first base

Pick another family when procurement required a reproduced training stack. MIT on Microsoft weights is not that exhibit. Pick another family when the organisation already operates a different stack and the only reason for Phi is a “small models win” brochure. Pick another family when the proposed identifier is an older Phi generation nobody has read, and there is no budget for a second legal pass. Those are constraint problems. They are not solved by a better adapter rank.

Phi is also the wrong first conversation when the job is open-ended advice, changing policy text, or any workflow that still needs unused headroom a 14B or mini card is being asked to fake. It is the wrong first conversation when nobody will operate GPUs this year and the only available path is a closed API that happens to say Phi on the SKU. Be honest. A downloadable MIT checkpoint sitting in object storage is not a production plan. The inference page is the operating conversation. The /slm page is the shrink conversation. This page is the card conversation.

What handover must include

A useful Phi handover is the adapter or merged weights, the exact base identifier, the MIT notice, tokenizer and template files, and evaluation notes from unused test documents. It is not a claim that the fine-tune is open-source AI, that inference is now private, that small models won, or that a public exam score transferred to your book.

Operators still need the base weights and a path that allows the stack. Merging simplifies a single-task image. Keeping adapters separate helps more than one queue or catalogue on one frozen Phi card. Choose from the operating plan. If the identifier was not one of the two cited cards, add the actual licence line from that generation. Do not inherit MIT by family name from a blog about an older Phi.

Procurement questions that belong in the brief

Which Hugging Face identifier will we freeze: microsoft/phi-4, microsoft/Phi-4-mini-instruct, or something else? Does that file state MIT, and does the mini card still say it does not modify the licence? Are we redistributing adapters or only serving internally? Where will prompts and logs sit? Did anyone mean OSAID when they said open source? Is the job routing, attributes or extract under review — or is it open-ended advice? Have we reserved unused test documents the model will not train on? Did we already decide we should shrink, or did a slide decide for us?

Those questions are more useful than a philosophy debate about whether Microsoft is “open enough”. The openness comparison exists so you can point at OSI’s definition without repeating it here. The /slm page exists so “should we shrink?” has one URL. This page exists so the two cited MIT cards, the exam-score warning and the wrong-shrink list have one URL.

Sources

1. Microsoft, phi-4 model card (Accessed September 2026). The phi-4 card describes a 14B dense decoder-only model released under the MIT licence.
2. Microsoft, Phi-4-mini-instruct model card (Accessed September 2026). The Phi-4-mini-instruct card states the model is licensed under MIT and that the card does not restrict that licence.
3. 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.
4. 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