> ## Documentation Index > Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt > Use this file to discover all available pages before exploring further. # LLM vs SLM Open vs Closed Weights > Describes how model size and whether weights are open or closed independently affect capability, control, cost, and operational tradeoffs when deploying language models. Okay — as we learned, behind every AI tool you use there is a model, and that model is ultimately just a file. Those files can differ greatly in size, who controls them, and how you interact with them. A dark lecture slide with a faint red "LECTURE" header and bold white title reading "LLM vs SLM — Open vs Closed Weights." A smaller subtitle below says "Two questions decide everything that follows." One model file might be hundreds of gigabytes stored in a vendor's data center that you never download or inspect. Another might be a few gigabytes and run locally on the laptop in front of you. These are both "models," but they behave very differently. Two primary, independent questions determine which model is the right fit: 1. How big is the model? 2. Who holds or maintains the model file? Many people conflate these into a single idea ("bigger is always better"), but they are independent axes. A model can be small and locked behind a cloud API, or enormous and downloadable for local use. Treat these as separate design decisions: size affects capability, cost, and latency; access affects control, compliance, and operational responsibility. A presentation slide titled "Two Questions, Not One" explaining that model size and openness are separate issues. Three red panels numbered 01–03 summarize: "How big is it?" (measured in parameters), "Who holds the file?" (open weights vs closed API), and "They're independent" (size and openness are unrelated). ## Model size (what "big" means) "Size" is shorthand for parameter count. There is no formal industry cutoff, but a practical breakdown is: | Category | Approx. parameter count | Typical tradeoffs / uses | | - | -: | - | | Small language models (SLMs) | \~1B–15B | Fast, low-cost, often runnable on laptops/workstations; great for narrow tasks like structured extraction, predictable completions, or classification. | | Mid-size models | \~20B–100B | Better general-purpose capability with balanced latency and cost; useful when more reasoning or coverage is needed than SLMs provide. | | Frontier / Large language models (LLMs) | 100B+ | Broad knowledge and multi-step reasoning; higher latency and cost, often hosted by vendors or requiring substantial infra. | Also watch for Mixture-of-Experts (MoE) architectures: a model marketed as 100B parameters may only activate a small fraction (for example, \~5B) per token. Headline parameter counts do not always equal compute used at inference time. The image is a slide titled "The Size of the Model" explaining that size refers to parameter count. Below it are three red chip icons and brief descriptions for Small (SLM, ~1B–15B), Mid-Size (~20B–100B) and Frontier models (100B+). In practice: * Larger models tend to deliver broader capability and stronger multi-step reasoning, but they cost more and can be slower. * Smaller models trade breadth for speed, lower cost, and the ability to run in constrained environments (on-device, air-gapped, or low-latency edge scenarios). * "Small" does not mean "bad" — it means "narrower." For many production tasks (ticket routing, structured extraction, consistent-form summarization), a well-chosen SLM or mid-size model is cheaper, faster, and fully adequate. Teams often default to the largest available model because it feels safe or prestigious. That reflex can increase latency, cost, and operational complexity unnecessarily. ## Who holds the model file? (Open vs closed weights) The second independent axis is access and control. * Closed weights: you rent access via a vendor API. You never possess the trained model file; prompts and responses traverse the network to the provider, which controls model versions and updates. * Open weights: the trained parameter file is published. You can download it, run it locally, inspect or fine-tune it, and control the version you use. That brings data residency, customization, and version stability advantages — with added hosting, maintenance, and compliance responsibilities. A dark-themed slide titled "Model Access — Do you rent it, or hold it?" Contrasting two options with a photo of server racks for "You rent it" and a desktop PC with monitors and cables for "You hold it," plus short explanatory text. Renting (closed weights) delivers a managed experience: automatic updates, scaling, and less ops work. Holding (open weights) delivers control: self-hosting, custom fine-tuning, and predictable behavior — at the cost of infrastructure and security responsibilities. Important distinction: open weights ≠ open source. "Open weights" means the trained parameter file is published — not necessarily the training data, training code, or the exact pipeline used to produce the model. Reproducing a published model from scratch is usually impossible without the original dataset and pipeline. Licenses vary: some open-weight models use permissive licenses (e.g., Apache 2.0), while others limit commercial use or impose additional constraints. Always read the license before building a product on a model. A dark-themed presentation slide with the headline "Open-Weight does NOT mean Open Source" explaining that the terms are different. On the right are three white info cards with red icons listing points like published trained parameters, unreleased training data/code, and variable licensing terms. Open weights let you run and modify a published model file, but they typically do not include the original training data or the full training pipeline. Check license terms and export/compliance restrictions before using a model in production. ## Putting the axes together: a 2×2 model access map Every real model falls into one of four corners. Use the table below to identify tradeoffs quickly. | Size \ Access | Closed weights (API) | Open weights (self-hostable) | | - | - | - | | Large (LLM, 100B+) | Frontier models you rent via an API — high capability, higher cost, vendor-managed. | Frontier-class models available for local download and operation — growing option; gives control but requires infra. | | Small (SLM, \~1B–15B) | Fast, hosted tiers behind vendor APIs — convenient for production, less control. | Compact models runnable on your hardware — low latency, low cost, maximum control. | When vendors sell closed models they often expose tiers (fast, balanced, frontier) rather than explicit parameter counts. The vendor maps a tier to a particular model configuration behind the scenes. ## How to choose: practical guidance * Prioritize openness (self-hosting) when you must guarantee data residency, avoid sending sensitive data to third parties, or require long-term version stability. * Prioritize size (larger models) when you need broad knowledge, complex reasoning, or capabilities only found in frontier models. * For many production workflows (routing, structured extraction, lightweight summarization), a small or mid-size model — open or closed — will be more cost-effective and performant than an oversized LLM. * Consider MoE and activation strategies: a headline parameter count alone may mislead about inference compute and cost. Keep the two independent questions in mind: openness governs control and compliance; size governs cost and performance. Those considerations will influence architecture, procurement, and operational decisions. If your application handles sensitive or regulated data, prioritize openness (self-hosting or a compliant deployment) and carefully review licenses and vendor policies before sending any data to third-party APIs. Further reading and references: * Review model licenses before production use (e.g., check Apache 2.0 or vendor-specific terms). * Explore self-hosting frameworks and inference stacks if you need open weights and local control. * Track developments in MoE and efficient inference to understand real-world compute costs. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.