Buying a phone, you don't memorize every model in the market — you learn the categories: flagship vs budget, iOS vs Android, and how to match one to a need. The LLM world is the same. Model names change every few months; the categories don't. This is a deliberately short lesson: learn the map, the trade-offs, and the one interview question that comes from it — "which model would you choose for X, and why?"
The two camps: closed API vs open-weight
Every LLM you can use falls into one of two camps. Closed (API) models: the provider hosts the model; you send requests over the internet and pay per token. You never see the weights. Open-weight models: the weights file is published — download it, run it on your own servers (or a cloud GPU you control), fine-tune it, ship it offline.
Note the careful term: open-weight, not fully "open-source." You get the weights, usually under a license with conditions — but rarely the training data or full recipe. Interviewers appreciate the precision.
The big names (as of this course's writing)
| Family | Maker | Camp | Known for |
|---|---|---|---|
| GPT series | OpenAI | closed API | the mainstream default; strong all-rounder |
| Claude | Anthropic | closed API | long documents, coding, careful reasoning |
| Gemini | closed API | multimodality, Google ecosystem integration | |
| Llama family | Meta | open-weight | the most popular self-host base |
| Mistral models | Mistral AI | open-weight (mostly) | small models that punch above their size |
| Qwen, DeepSeek & others | various | open-weight | fast-moving open ecosystem, strong price/quality |
Don't memorize versions — they'll be outdated by your interview. Learn the camps and what each family is known for; that knowledge survives every release cycle.
Open vs closed — the trade-offs that decide projects
| Closed API | Open-weight (self-hosted) | |
|---|---|---|
| Quality ceiling | highest available | close behind, improving fast |
| Setup effort | an API key and ten minutes | GPUs, serving stack, an ops engineer |
| Data location | leaves your infrastructure | stays fully inside |
| Cost shape | pay per token, forever | fixed infra cost, cheap per token at scale |
| Customization | prompts, limited fine-tuning options | full control — any fine-tuning, any modification |
| Who upgrades it | the provider, automatically | you, manually |
Selection-round radar: "When would a company self-host an open model instead of using an API?" Expected answer, three beats: data privacy/regulation (data can't leave — hospitals, banks, government), customization (deep fine-tuning), and economics at scale (huge volume makes fixed infra cheaper than per-token billing). Then the counterweight: self-hosting costs engineering effort that a small team shouldn't spend early.
Model size and context windows
Within each camp, models come in sizes — often named by parameter count (a "7B" model has ~7 billion weights). Bigger generally means smarter, slower and pricier. The practical wisdom production teams live by: use the smallest model that meets your quality bar. Routing is everywhere: a small cheap model handles the easy 90% of requests (classification, extraction, short answers), the flagship handles the hard 10%. Saying that sentence in an interview signals production maturity.
The other headline spec is the context window — the maximum tokens (input + output) one request can hold, from a few thousand to a million-plus depending on the model. Bigger windows fit more documents and longer conversations, but remember from lesson 5: you pay per token every call, and models attend less sharply when the relevant line is buried in a haystack — which is why RAG (lesson 9) stays essential even in the big-window era.
Multimodal models
Multimodal = handles more than one data type: send an image with your text ("what's wrong with this circuit?"), get text back; some models also hear audio or generate images. Don't confuse it with multilingual (many human languages) — a small distinction interviewers genuinely check. Modern flagships are multimodal by default, which unlocked use cases like screenshot debugging, invoice photo extraction and video Q&A.
How to choose — the checklist that answers the interview question
"Which model would you pick for this project?" Walk the checklist out loud: 1) Data rules — can data leave our infrastructure? No → open-weight, self-hosted, decision over. 2) Quality bar — does the task genuinely need a flagship, or does a small model pass? Prototype with a strong API model first, then downsize. 3) Cost at volume — do the per-token math at expected scale. 4) Latency — chat UX wants fast first tokens; batch jobs don't care. 5) Special needs — long documents, images, strict formats, fine-tuning plans. There's no universal best model — there's a best model per constraint set, and interviewers want to hear the constraints, not a brand name.
Common mistakes
- Answering "which model?" with a favourite brand instead of constraints (data rules, cost, latency, quality bar).
- Saying "open-source" when you mean open-weight — weights ≠ training data ≠ license freedom.
- Assuming self-hosting is free — GPUs and the engineer running them are very real costs.
- Memorizing model version numbers instead of categories — versions expire; categories don't.
- Confusing multimodal (data types) with multilingual (languages).
Quick recap
| Concept | One-liner |
|---|---|
| Closed API | provider hosts, you pay per token; best quality, least control |
| Open-weight | download and self-host; full control, real ops cost |
| When to self-host | privacy/regulation, deep customization, economics at scale |
| Model size | smallest model that meets the quality bar; route hard cases up |
| Context window | max tokens per request — working memory, not knowledge |
| Multimodal | multiple data types (text+image+audio) — not multiple languages |
Practice Zone — PYQs from real selection rounds
Six MCQs and two scenario tasks — including the hospital-data question that appears in some form in most GenAI system interviews.
An open-weight model is one where:
Asked in
Which of these is accessed as a closed model behind an API (weights not downloadable)?
Asked in
A company would typically choose an open-weight, self-hosted model over a closed API mainly when:
Asked in
A model's context window is:
Asked in
Why would a team deliberately pick a smaller model over the biggest one available?
Asked in
A multimodal model is one that:
Asked in
Scenario tasks:
A hospital chain wants an internal assistant that answers doctors' questions using patient records. Regulation says patient data cannot leave their own data centre. Recommend: closed API model, or open-weight self-hosted? List two follow-up requirements your choice creates.
Asked in
Your startup's feature makes 2,000 LLM calls/day (~1,000 tokens each). The closed API costs ₹0.25 per call at this size. A self-hosted open model needs a GPU server at ~₹60,000/month plus an engineer's time. Which do you pick today, and at what point would you reconsider?
Asked in
FAQ
Which single model should I learn for interviews?
None exclusively — the APIs all look alike (messages in, message out), so skills transfer. Build something with any major API and be able to discuss the trade-offs between camps; that's what gets tested.
Can open models run on my laptop?
Small ones, yes — quantized 3B–8B models run on a decent laptop with tools like Ollama, and it's a great learning exercise. Production self-hosting of larger models needs server GPUs and a serving stack (e.g. vLLM).
Are bigger models always better?
Better on hard reasoning, usually — but slower and costlier, and for narrow tasks (classify, extract, route) a small model is often indistinguishable in quality and 10–100× cheaper. Hence the production rule: smallest model that passes your quality bar.
Next lesson: the knobs on the machine — Lesson 5: Temperature, Top-p, Tokens & Context →