In this article we're going to help you build the vocabulary you need to compare AI models before you start designing infrastructure around them. We'll talk about what a model is and the main types enterprises use, how to read names and packaging when you self-host, and what size, tokens, and context mean for cost and fit. We'll also talk about common ways to align a model with your domain, including prompts, retrieval-augmented generation (RAG), and fine-tuning. Finally we'll cover some of the practical constraints that usually dictate what ends up on your model shortlist: budget, compliance, and whether your team can actually run the model in production.What is an AI model?An AI model is a mathematical system trained on vast amounts of data to recognize patterns, make predictions, or generate content. Think of it as a sophisticated pattern-matching engine that has learned from billions of examples to perform tasks like understanding language, generating text, analyzing images, or writing code. At its core, an AI model consists of:Parameters: Numerical values, weights and biases, that encode the knowledge learned during training. These parameters determine how the model processes input and generates output.Architecture: The structure and design of the model, such as a transformer, convolutional neural network (CNN), or diffusion model, that defines how information flows through the system.Training data: The dataset used to teach the model patterns and relationships. The quality and diversity of training data significantly impact model performance.When you use an AI model, you provide input in the form of text, images, and so on, and the model processes it through its learned parameters to produce output. The model doesn't remember specific training examples but instead generalizes patterns it learned during training to handle new, unseen inputs.The most prominent category for enterprise text work is large language models (LLMs), which are trained to understand and generate human language. LLMs are the foundation for most text-based tasks, making them ideal for chatbots, content generation, analysis, and general-purpose AI applications. They represent the most versatile category of AI models and are often the starting point for most enterprise AI initiatives.Beyond general-purpose LLMs, there are many specialized models tailored to particular data types and tasks, such as vision models for images, multimodal models that combine text with images or other media, code models optimized for programming, embedding models that convert text into vectors for semantic search and retrieval, and domain-specific models for fields like medicine, law, finance, or science. These specialized models provide stronger performance, better safety, or more relevant behavior for their target use cases than a generic model used alone. Many modern models blur these categories.Key concepts for comparing modelsWhen you evaluate or shortlist models, understanding a few technical concepts helps you match capability to your use case and infrastructure. The following topics are the main ones to review before selecting a model.Model sizeA model's size means how many parameters it has, usually expressed in millions or billions. Larger models tend to reason better and handle nuance, but they need more memory, run more slowly, and cost more per token on managed APIs. The right size is a trade-off between quality and what your budget and platform can support.In practice, parameter count is shorthand for model size. For most models, that number is a fair proxy for how much memory you need when you self-host, what inference costs on managed APIs, and roughly how capable the model is. That rule has exceptions worth noting, such as mixture of experts (MoE).MoE designs still carry a large total parameter count, but only part of the network runs on each token because a request router selects a small set of expert modules for the job. When you evaluate MoE, lean on parameter count for storage and load-time memory, and assess per-request compute and cost on their own rather than assuming they move in lockstep with total parameter count.Model size also shapes which deployment options are realistic for your estate. Those limits are environment-specific and should be validated against your target architecture.TokensText isn't fed to the model word-by-word, it's split into sub-word units called tokens. For English, 1 token is roughly three-quarters of a word on average. Tokens matter because providers price APIs per token. Larger models usually cost more per token and run more slowly because each token triggers computation across most of the model's parameters. MoE is again an exception, for the same reasons I discussed in the model size section. Only a subset of the network runs per token, so per-token cost and latency don't follow total parameter count as closely, even though API pricing is still per token.Context windowThe context window is the maximum number of tokens the model can take in for a single request (your prompt plus conversation history plus, for generation, the output being produced). An 8K window holds on the order of 6,000 words, 32K roughly 24,000 words, 200K can span long documents or transcripts. A larger window supports long chats and document-heavy workflows but usually increases latency, memory use, and cost. Context window size is independent of parameter count so a smaller model can still offer a very large window.Task specializationAfter base training, a model is rarely deployed unchanged. Model vendors usually ship task-tuned variants for common interaction patterns, such as instruction-following for chat, code, and vision, including assistants calling external tools (agents), or a base checkpoint meant for further customization on your side. Enterprises then align the model with their domain through additional layers, which can be combined. The main task specialization techniques are as follows:Fine-tuning: This technique updates model weights on proprietary data so tone, format, and terminology stay consistent. Low-rank adaptation (LoRA) and similar parameter-efficient methods are one way to fine-tune. They train small adapter layers while keeping most of the base weights frozen, which typically costs less compute and storage than updating every parameter.Prompt engineering: This technique guides behavior at inference time without changing weights and doesn't require updating parameters. It uses instructions, examples, and templates in the request to steer output.RAG: This method also leaves weights unchanged—at query time it retrieves relevant documents or records from your knowledgebase and adds them to the prompt as context. RAG fits workloads with frequently changing knowledge, a need for citations, or a desire to avoid retraining. RAG requires an embedding pipeline, the process that ingests documents, chunks them, converts chunks to vectors with an embedding model, and loads them into a retrieval store (a vector database or search index used to find relevant chunks for each question).Many teams stack these approaches, for example selecting a vendor variant such as instruction-following (often having the suffix -instruct in the name of the model), adding RAG for current documentation, using LoRA or full fine-tuning for stable behavior, and prompt templates for task-specific guardrails.Packaging for self-hostingIf you run models on your own infrastructure, you download and load weight files rather than calling an API. Three packaging choices affect whether a model fits your hardware and how fast it runs:Quantization reduces the number of bits used to store each weight (such as 4-bit or 8-bit instead of 16-bit). That shrinks disk size and GPU memory so the same model can run on smaller hardware, usually with a small trade-off in output quality. Tags like q4 or q8 in a model name indicate the quantization level.Precision is the floating-point type used for weights during inference. fp16 (16-bit) and bf16 (brain float 16) are common on GPUs, fp32 (32-bit) is higher precision but heavier. Precision and quantization are related ideas since they're both concerned with how numbers are stored, but quantization is an intentional compression step, while precision describes the native numeric format of the weights.File format is how those weights are packaged on disk. GGML Unified Format (GGUF) is widely used with Ollama and llama.cpp while safetensors is the standard on Hugging Face. The format must match what your inference server expects when it loads the model.Language focus (for example, English-only versus multilingual) and license terms (commercial use, redistribution) also matter when you host weights yourself rather than consuming a managed API.How this shows up in model namesVendors and open source publishers often compress these concepts into the name itself. Once you know the notions above, names become shorthand rather than jargon. For example, Llama-3-8B-Instruct-v0.1-q4 reads as an 8-billion-parameter Llama 3, instruction-tuned, release 0.1, 4-bit quantized for efficient self-hosting. Mixtral-8x7B-Instruct reads as a mixture-of-experts model with 8 7B experts in an instruction-tuned variant. GPT-4.1-mini reads as a compact, lower-cost offering within the GPT-4.1 family.Decision factorsTechnical concepts explain what a model can do but enterprise constraints determine which option you should choose. Once you understand size, tokens, context, and specialization, the shortlist is usually narrowed by a small set of operational and organizational factors. The following are the most common ones architects weigh before committing to a model.Financial and scale constraintSize and token economics usually decide how far up the capability ladder a workload can go. For managed APIs, high-volume traffic often favors a lower-cost model tier when quality remains acceptable, even if prompts need more refinement. For lower-volume, quality-critical work, a higher-capability tier may justify the premium.On self-hosted deployments, high volume shifts the question toward infrastructure break-even and total cost of ownership, not model size alone. The better fit matches task requirements, token volume, quality needs, and budget, since effectiveness depends on training data quality, architecture efficiency, and fine-tuning at least as much as on parameter count.Privacy and complianceHealthcare, finance, legal, and government workloads often impose strict rules on where data is processed, who can access it, and how long it is retained. Self-hosted models keep prompts, retrieved context, and outputs inside your infrastructure, which simplifies data residency and audit boundaries for regulations such as Health Insurance Portability and Accountability Act (HIPAA), General Data Protection Regulation (GDPR), and Payment Card Industry Data Security Standard (PCI DSS).Managed APIs aren't automatically ruled out, because many providers offer enterprise terms, zero-retention options, private connectivity, and region-specific endpoints, but those claims need validation against your data classification and logging practices. Model selection is typically a joint decision with security and legal stakeholders, not only with the application team.Operational readinessModel choice is also a choice about what your organization can run day-to-day. Managed APIs shift most operational work to the provider, including scaling, patching, and model updates, which suits teams focused on application integration rather than GPU infrastructure.Self-hosted models require capacity to provision hardware or cloud GPU capacity, deploy inference servers, monitor latency and errors, rotate model versions, and respond to incidents. Approaches such as fine-tuning, RAG, or agentic workflows add further ownership of training pipelines and tool integrations. A capable open model isn't a practical choice if current skills and staffing can't operate it reliably in production.Final thoughtsThe concepts in this article map to properties you can measure. Parameter count and precision drive memory footprint and disk size, tokens drive API cost and latency, the context window sets how much input each request can carry, and quantization and file format decide whether a model fits your hardware and inference server. Once you can read them together, a name like Llama-3-8B-Instruct-q4 tells you the family, size, tuning, and memory profile before you download anything.Selecting a model is then a filtering exercise. Task requirements and quality targets define the candidates, and the shortlist emerges from budget, token volume, compliance, and whether your team can run the choice in production.What this article doesn't settle is where the model runs and who operates it. Those questions are covered in our next 2 articles: Beyond the model: Architecting production-grade enterprise AI systems (compute, model storage, inference and serving, integration) and Managing enterprise AI at scale: Hosting, deployment patterns, and Day 2 operations (managed APIs versus self-hosting, the platform that implements the stack, and Day 2 operations).