Plain-English definitions of the 234 terms you'll meet running local AI — from quantization, VRAM and GGUF to KV cache, Mixture-of-Experts, RAG and tool calling, grouped into 15 topics. New to local LLMs? Start with the GPU & VRAM checker or browse the model library.
Core LLM Concepts · GPUs, VRAM & Hardware · Quantization & Numeric Precision · Model Files, Formats & Distribution · Context Windows & Working Memory · Runtimes, Servers & Local Apps · Inference Speed & Performance · Model Architecture · Prompting, Sampling & Output Control · RAG, Embeddings & Retrieval · Agents, Tools & Reasoning · Training & Fine-Tuning · Evaluation & Benchmarks · Deployment, Scaling & Cost · Licensing, Privacy & Safety
The vocabulary every other section builds on — what a model is, what it reads, and what it produces. (22 terms)
Also called: LLM, language model
A neural network trained on very large amounts of text to predict the next token, which turns out to be enough to summarise, translate, write code, and answer questions. Modern LLMs are transformers with billions of parameters. "Local LLM" means one whose weights you have downloaded and run on your own hardware, with no request leaving your machine.
See also: Parameters (Weights), Inference, Local AI
fundamentals · model · local
The basic unit of text for an LLM. Words, sub-words, or characters. Roughly 1,000 tokens ≈ 750 English words. Tokenization varies by model — GPT-4 uses tiktoken, Llama uses SentencePiece. Pricing for cloud APIs is per token.
See also: Tokenizer, Context Window, Cost per Million Tokens
text · pricing · input · output
The component that converts raw text into token IDs (numbers) before feeding it to the model, and converts model output IDs back to text. Each model family has its own tokenizer — Llama uses SentencePiece, GPT-4 uses tiktoken. Different tokenizers produce different token counts for the same text.
See also: Tokens, Vocabulary Size, Special Tokens
text processing · input · tokens
Also called: weights, model size
The numbers learned during training that define what the model knows. A '7B' model has 7 billion parameters. More parameters = more world knowledge and reasoning ability, but requires more VRAM (roughly 2GB per 1B params at full precision, 0.5GB/B at Q4).
See also: VRAM (Video RAM), Quantization, Active Parameters
model size · vram · quality
Running the model to generate text from an input prompt — the 'use' phase, distinct from training. Inference can be done on CPU or GPU. GPU inference is 5–50x faster. Local inference = running the model on your own hardware without sending data to the cloud.
See also: Prefill, Decode, Tokens per Second (t/s)
runtime · gpu · cpu · local
Also called: pretrained model, foundation model
A model straight out of pretraining, before any instruction tuning. It continues text rather than answering questions, so a base model given "What is the capital of France?" may produce more quiz questions instead of an answer. Base models are the starting point for fine-tuning; for chat use, download the instruct variant instead.
See also: Instruct Model, SFT (Supervised Fine-Tuning), Pretraining
model type · pretraining · fine-tuning
Also called: chat model, instruction-tuned model
A base model that has been fine-tuned to follow instructions and hold a conversation. Filenames and tags mark it with "-Instruct", "-it", or "-chat". This is what you want for almost every local use case — an instruct model expects a chat template with roles, while a base model expects raw text to continue.
See also: Base Model, Chat Template, SFT (Supervised Fine-Tuning)
model type · chat · fine-tuning
Also called: open weights
A model whose trained weights are published for download, so anyone can run, quantize, and fine-tune it locally. Open weights are not the same as open source: the training data and code usually stay private, and the licence may restrict commercial use. Llama, Qwen, DeepSeek, Mistral, Gemma, and gpt-oss are all open-weight families.
See also: Open-Source Model, Apache 2.0, Llama Community License
licensing · open source · model type
A model that ships weights, training code, and enough data documentation under an OSI-approved licence for someone else to reproduce it. Most models called "open source" in marketing are only open-weight. The distinction matters for compliance reviews: an Apache 2.0 weights release still is not a reproducible open-source system.
See also: Open-Weight Model, Apache 2.0
licensing · open source · compliance
Also called: on-device AI, self-hosted AI, private AI
Running AI models on hardware you control — a laptop, desktop GPU, or your own server — instead of calling a hosted API. The payoffs are privacy (no prompt leaves the machine), fixed cost after hardware, offline availability, and no rate limits. The trade-off is that you are capped by your own VRAM and bandwidth.
See also: Self-Hosting, VRAM (Video RAM), Total Cost of Ownership (TCO)
privacy · local · offline
Also called: SLM, tiny model
A language model small enough to run on modest hardware — usually under about 4B parameters, and often under 1B. SLMs like Qwen3 0.6B, Gemma 3 270M, and SmolLM run on phones, laptops without discrete GPUs, and edge devices. They are weaker at open-ended reasoning but excellent at classification, extraction, and routing.
See also: Large Language Model (LLM), Distillation
model size · edge · cpu
The full text sent to a model for one generation — system instructions, conversation history, retrieved documents, and your latest message combined. Everything in the prompt consumes context and, on a cloud API, costs input tokens. On local hardware, a longer prompt means a longer prefill before the first token appears.
See also: System Prompt, Context Window, Prefill
input · context · prompting
Also called: system message
A separate instruction block placed before the conversation that sets the model's role, tone, and rules. Because it sits at the very start of the context, it is the ideal thing to cache: prefix caching makes an unchanged system prompt nearly free on every subsequent request in the same session.
See also: Chat Template, Prefix Caching, Prompt Injection
prompting · chat · context
Also called: prompt template, ChatML
The exact formatting a chat model expects, with special tokens marking where each role's turn starts and ends. Every family has its own — ChatML, Llama 3, Gemma, and Mistral templates are all different. Using the wrong template is the single most common cause of a local model rambling, ignoring instructions, or never stopping.
See also: Special Tokens, Instruct Model, Stop Sequences
chat · formatting · troubleshooting
Also called: BOS, EOS, control tokens
Reserved tokens that carry structure rather than text — beginning-of-sequence (BOS), end-of-sequence (EOS), turn delimiters, and tool-call markers. The runtime must know the model's EOS token to stop generating; a mismatch between the GGUF metadata and the template is why some models produce endless output.
See also: Chat Template, Stop Sequences, Tokenizer
tokens · formatting · troubleshooting
The README published alongside a model's weights, documenting its architecture, training data, intended use, licence, benchmark scores, and known limitations. On Hugging Face it is the repository's main page. Read the licence and the recommended chat template sections before downloading anything for production use.
See also: Hugging Face Hub, Open-Weight Model
documentation · hugging face · licensing
A saved snapshot of a model's weights at a point in training. Released models are simply the checkpoint the authors chose to publish. During fine-tuning you save checkpoints periodically so you can roll back if quality degrades, and pick the one with the best validation score rather than the last one.
See also: Fine-Tuning, safetensors
training · weights · files
Also called: confabulation
A fluent, confident model output that is factually wrong. It is a direct consequence of next-token prediction: the model optimises for plausible text, not truth. Retrieval grounding, lower temperature, and asking for citations reduce it; no local or cloud model eliminates it, so anything consequential needs verification.
See also: RAG (Retrieval-Augmented Generation), Grounding, Temperature
quality · accuracy · risk
Also called: thinking model, chain-of-thought model
A model trained to produce an internal chain of thought before its final answer, trading latency and tokens for accuracy on maths, logic, and code. DeepSeek R1 and the QwQ line popularised it locally. Budget for the extra output: a reasoning model can spend thousands of thinking tokens on one question, and they occupy context like any others.
See also: Chain of Thought, Test-Time Compute, Reasoning Effort
reasoning · model type · latency
Also called: VLM, vision-language model
A model that accepts more than text — usually images, sometimes audio or video — by encoding them into the same token stream. Locally these need a vision projector file alongside the weights, and images consume a surprising number of tokens: a single high-resolution image can cost more context than a page of text.
See also: Multimodal Projector (mmproj), Context Window
vision · model type · images
Training a small "student" model to imitate a larger "teacher" model's outputs, transferring much of its capability into a fraction of the parameters. Most strong small models today are distilled. The name in a filename — for example a "DeepSeek-R1-Distill" variant — tells you it is a smaller base model taught by a larger reasoning model, not the original.
See also: Small Language Model (SLM), Synthetic Data
training · model size · efficiency
Also called: in-context learning
Zero-shot means asking the model to do a task with instructions only; few-shot means including a handful of worked examples in the prompt first. Few-shot reliably improves format adherence on smaller local models, at the cost of the context those examples occupy — and prefix caching makes a fixed example block cheap to reuse.
See also: Prompt, Prefix Caching
prompting · accuracy · context
The physical limits that decide which models you can actually run at home or on a workstation. (21 terms)
The memory on your GPU. This is the critical bottleneck for local LLM inference — the entire model (weights) must fit in VRAM or the GPU falls back to slow CPU RAM. More VRAM = bigger models. RTX 4090 has 24GB; RTX 4060 has 8GB.
See also: GPU Offloading, Out of Memory (OOM), Unified Memory
Check your GPU · Models by VRAM tier
hardware · gpu · memory · bottleneck
Also called: layer offloading, n_gpu_layers, ngl
Splitting a model between GPU and CPU by placing only some layers in VRAM. In llama.cpp this is the `n_gpu_layers` (or `-ngl`) setting. Offloading lets a model larger than your VRAM run at all, but every layer left on the CPU costs speed dramatically — partial offload is typically 3–10x slower than a full fit.
See also: VRAM (Video RAM), Memory Bandwidth, System RAM
Fix: model loads but runs slowly
vram · llamacpp · performance · cpu
Also called: UMA, shared memory
A design where CPU and GPU share one pool of RAM instead of each having its own — the defining feature of Apple Silicon for local AI. A 64GB Mac can allocate most of that to a model, so it runs LLMs that would need a data-centre GPU. The catch is bandwidth: unified memory is far slower than a discrete card's GDDR or HBM, so large models load but generate slowly.
See also: Apple Silicon, Memory Bandwidth, MLX
apple · memory · mac · hardware
Also called: M-series, Mac
Apple's M-series chips (M1 through M5 and their Pro/Max/Ultra variants), which run local LLMs through the GPU and Neural Engine using unified memory. Practical capacity is roughly 70% of total RAM. Max and Ultra tiers have several times the memory bandwidth of the base chip, which is what actually determines tokens per second.
See also: Unified Memory, Metal (MPS), MLX
Fix: Apple Silicon GPU not used · macOS calls an unsigned AI tool damaged
apple · mac · hardware · metal
Also called: GB/s, bandwidth
How fast a GPU can read data from its own memory, in GB/s — the number that actually predicts local token generation speed. Generating each token requires reading the whole active model once, so tokens per second is roughly bandwidth divided by model size in bytes. This is why an 8GB model on a 1,000 GB/s card runs near 100 t/s regardless of the card's raw compute.
See also: Memory-Bound vs Compute-Bound, Tokens per Second (t/s), HBM
GPU database with bandwidth specs
performance · gpu · speed · hardware
Whether a workload is limited by memory bandwidth or by arithmetic throughput. Single-user local generation is memory-bound — the GPU sits idle waiting for weights — which is why bandwidth beats TFLOPS for chat. Prefill and large-batch serving are compute-bound, which is where tensor cores and FLOPS start to matter.
See also: Memory Bandwidth, TFLOPS, Batch Size, Prefill
performance · theory · gpu
NVIDIA's parallel-computing platform and the default path for GPU acceleration in nearly every LLM runtime. Practically, it means an NVIDIA card plus a matching driver and toolkit version. Most local-AI installation failures are CUDA version mismatches between the driver, the toolkit, and the compiled runtime.
See also: ROCm, Compute Capability, Tensor Cores
nvidia · gpu · drivers · setup
Also called: HIP, AMD GPU support
AMD's open compute stack, the CUDA equivalent for Radeon and Instinct GPUs. Support in llama.cpp, Ollama, and vLLM is real but narrower than NVIDIA's: officially supported cards, kernel driver versions, and the HSA override environment variables are the usual friction points on consumer RDNA hardware.
Fix: ROCm not detecting AMD GPU
amd · gpu · drivers · setup
Also called: MPS, Metal Performance Shaders
Apple's GPU API, and the backend llama.cpp and PyTorch use to accelerate models on Mac. Metal support is why a MacBook runs local LLMs at usable speed without any CUDA equivalent. In PyTorch the device is called `mps`; in llama.cpp it is compiled in by default on macOS.
See also: Apple Silicon, MLX
Raising the Metal working-set ceiling
apple · mac · gpu · backend
A cross-vendor graphics and compute API that llama.cpp can use as a GPU backend when CUDA or ROCm is unavailable. It runs on NVIDIA, AMD, Intel Arc, and many integrated GPUs from a single build. Expect a speed penalty versus the vendor-native backend, but it is often the fastest route to any GPU acceleration at all.
See also: CUDA, ROCm, llama.cpp
backend · gpu · cross-platform · intel
Dedicated matrix-multiply units on NVIDIA GPUs since Volta, and the reason modern cards are so much faster at low-precision maths. Each generation adds formats — FP16 and BF16, then FP8 on Hopper and Ada, then FP4 on Blackwell. A quantization format only runs at full speed if the GPU has tensor cores for that precision.
See also: FP8, FP4 (NVFP4 & MXFP4), Compute Capability
nvidia · gpu · hardware · precision
Also called: SM version, CC
NVIDIA's version number for a GPU architecture's feature set — 8.6 for Ampere consumer cards, 8.9 for Ada, 9.0 for Hopper, 12.0 for Blackwell. Runtimes use it to decide which kernels can run. A card below the minimum compute capability of a prebuilt binary will fail to load the model even with a current driver.
See also: CUDA, Tensor Cores
nvidia · gpu · compatibility
Also called: FLOPS
Trillions of floating-point operations per second — a GPU's raw arithmetic throughput, always quoted for a specific precision. It predicts prompt-processing and batch-serving speed well and single-user token generation poorly, because generation is bandwidth-limited. Compare TFLOPS at the same precision or the numbers are meaningless.
See also: Memory-Bound vs Compute-Bound, Memory Bandwidth
performance · gpu · specs
High Bandwidth Memory — stacked DRAM placed next to the GPU die, used on data-centre accelerators like the H100, H200, and MI300 series. It delivers several terabytes per second, an order of magnitude beyond consumer GDDR, which is why one server GPU can serve many concurrent users at speeds a desktop card cannot match.
See also: GDDR, Memory Bandwidth
memory · datacenter · gpu · bandwidth
The graphics DRAM used on consumer GPUs — GDDR6, GDDR6X, and GDDR7 on current cards. Bandwidth is the memory bus width multiplied by the effective clock, so a 384-bit card massively outruns a 128-bit one at the same generation. For local LLM work, bus width and generation matter more than the advertised clock speed.
See also: HBM, Memory Bandwidth
memory · gpu · consumer · bandwidth
Also called: DDR, CPU RAM
Your motherboard's DDR memory, used for CPU inference, for layers offloaded from the GPU, and to stage weights during loading. As a rule, keep at least as much system RAM as the largest model file you intend to load. DDR5 bandwidth is roughly 5–10% of a discrete GPU's, so CPU-resident layers dominate total generation time.
See also: GPU Offloading, mmap, Memory Bandwidth
Fix: Ollama needs more system memory
memory · cpu · hardware
Also called: CUDA out of memory, OOM error
The error you get when a model, its KV cache, and framework overhead exceed available VRAM. The fix order is: reduce context length, quantize the KV cache, drop to a smaller quantization, offload fewer layers, or pick a smaller model. Context length is the usual culprit — the KV cache grows linearly with it while the weights stay fixed.
See also: KV Cache, Quantization, GPU Offloading
error · vram · troubleshooting
Also called: power draw, wattage
Thermal Design Power — the sustained wattage a GPU is built to dissipate, and a good proxy for both PSU sizing and running cost. A 450W card under continuous inference draws close to that figure, so a full-time local setup costs real money in electricity; that draw is a line item in any honest local-versus-cloud comparison.
See also: Total Cost of Ownership (TCO)
Local vs cloud cost calculator
power · cost · hardware · psu
NVIDIA's high-speed direct GPU-to-GPU interconnect, far faster than routing traffic over PCIe. It matters for tensor parallelism, where cards exchange activations every layer. Consumer cards after the RTX 3090 dropped NVLink, so multi-GPU desktop rigs communicate over PCIe and lose throughput on tensor-parallel serving.
See also: Tensor Parallelism, PCIe Bandwidth
multi-gpu · interconnect · nvidia
Also called: PCIe lanes, x16
The link speed between GPU and motherboard, which governs model load time and any traffic between cards. For single-GPU inference it barely matters once the model is resident — even x4 works. It becomes a real bottleneck for multi-GPU tensor parallelism and for setups that stream layers from system RAM each token.
See also: NVLink, Tensor Parallelism
interconnect · multi-gpu · motherboard
A Neural Processing Unit — a low-power accelerator for neural networks built into recent laptop SoCs from Intel, AMD, Qualcomm, and Apple. NPUs excel at small always-on models within a tight power budget. Software support for general LLM inference is still thin, so most local runtimes still target the GPU instead.
See also: Small Language Model (SLM), Apple Silicon
edge · laptop · hardware · accelerator
How models are shrunk to fit consumer GPUs, and what each format costs you in quality. (17 terms)
Reducing the precision of a model's weights (e.g., from 32-bit float to 4-bit integer) to shrink memory usage with minimal quality loss. A 7B model in FP16 needs ~14GB VRAM; in Q4_K_M it needs ~4GB.
See also: Bits per Weight (BPW), Q4_K_M, K-Quants
VRAM at every quantization level
vram · memory · gguf · performance
Also called: BPW, bits per parameter
The average number of bits used to store each parameter, and the single number that predicts a quantized file's size. Multiply parameters by BPW and divide by eight for bytes: 8B parameters at 4.5 BPW is about 4.5GB. Formats are not exactly their nominal bit count — Q4_K_M averages roughly 4.8 BPW because some tensors are kept at higher precision.
See also: Quantization, K-Quants
quantization · file size · vram
The default recommendation for local LLMs: a 4-bit K-quant, medium size, averaging roughly 4.8 bits per weight. It is the point where the size/quality curve bends — perplexity is within about 1% of FP16 while the file is roughly a quarter the size. Go to Q5_K_M or Q6_K if you have VRAM to spare, Q3_K_M only if you must.
See also: K-Quants, Quantization, GGUF
Which GGUF quant should I use?
gguf · quantization · recommended
Also called: Q4_K, Q5_K, Q6_K
llama.cpp's family of block-wise quantization formats, written Q<bits>_K_<size> — for example Q4_K_S, Q4_K_M, Q6_K. Weights are grouped into blocks with their own scale factors, and important tensors (attention and embeddings) are kept at higher precision than the rest, which is why K-quants beat older flat formats at the same file size.
See also: Q4_K_M, I-Quants (IQ), GGUF
gguf · llamacpp · quantization
Also called: IQ quants
llama.cpp's newer importance-aware quantization formats, written IQ2_XS, IQ3_M, IQ4_XS and similar. They use codebook lookups guided by an importance matrix to hold quality at very low bit rates, so IQ3 often beats Q3_K. The trade-off is more compute per token, which costs speed on weak GPUs and CPU-only setups.
See also: Importance Matrix (imatrix), K-Quants
gguf · llamacpp · quantization · low-bit
Also called: imatrix
A profile of which weights matter most, computed by running calibration text through the model and recording activation magnitudes. llama.cpp uses it to allocate precision where it counts during quantization. An imatrix-quantized file is measurably better than the same format without one, at zero extra size or inference cost.
See also: I-Quants (IQ), Calibration Dataset
quantization · llamacpp · quality
A small sample of representative text — typically a few hundred sequences — pushed through a model to measure activation ranges before quantizing. GPTQ, AWQ, and imatrix all need one. Calibrating on text unlike your real workload is a quiet quality killer: a model calibrated only on English prose degrades more on code or other languages.
See also: GPTQ, AWQ, Importance Matrix (imatrix)
quantization · quality · gptq · awq
Also called: half precision, bfloat16
The two 16-bit floating-point formats models are trained and released in. Both use two bytes per parameter, so weights alone need roughly 2GB per billion parameters. BF16 trades mantissa bits for FP32's exponent range, which makes it far more stable in training; FP16 has more precision but overflows more easily. For inference the difference is negligible.
See also: Quantization, Bits per Weight (BPW)
precision · training · vram
Also called: E4M3, E5M2
An 8-bit floating-point format with hardware support from NVIDIA Hopper and Ada onward, and on recent AMD accelerators. It halves memory versus BF16 with very little quality loss and is the default production precision in vLLM and SGLang on modern data-centre cards. FP8 KV cache is a separate, equally useful lever.
See also: Tensor Cores, KV Cache Quantization, vLLM
precision · vllm · datacenter · serving
Also called: NVFP4, MXFP4, FP4
Two competing 4-bit floating-point formats with native hardware support on Blackwell-class GPUs. NVFP4 is NVIDIA's, using small blocks with FP8 scales for higher accuracy; MXFP4 is the Open Compute Project standard, with larger blocks and simpler hardware. Both deliver 4-bit memory savings at close to FP8 quality — gpt-oss shipped natively in MXFP4.
See also: FP8, Tensor Cores, Quantization
precision · blackwell · quantization · 2026
Also called: W8A8, W4A16
Integer quantization formats that map floating-point weights onto 8-bit or 4-bit integers using a scale and zero point. INT8 is nearly lossless and widely supported; INT4 needs group-wise scales and a good calibration set to hold up. GPTQ and AWQ both produce INT4 weights — the difference is in how they choose the scales.
See also: GPTQ, AWQ, Calibration Dataset
precision · quantization · integer
A one-shot post-training quantization method that compresses weights layer by layer, using second-order error information to compensate as it goes. It produces 4-bit GPU-ready weights that run fast in vLLM, ExLlama, and Transformers. GPTQ needs a calibration pass, and is generally a little more calibration-sensitive than AWQ.
See also: AWQ, Calibration Dataset, INT8 & INT4
quantization · gpu · vllm · 4-bit
Activation-aware Weight Quantization — a 4-bit method that identifies the small fraction of weight channels most sensitive to activation magnitude and protects them with per-channel scaling. It generally holds instruction-following quality better than GPTQ at the same bit width and is a common default for serving quantized models in vLLM.
See also: GPTQ, Calibration Dataset
quantization · vllm · 4-bit · serving
Also called: ExLlamaV2 format, exl2
The ExLlama quantization formats, built for fast single-user inference on consumer NVIDIA GPUs. Their distinguishing feature is fractional bit rates — you can target 4.65 bits per weight to fill your VRAM exactly instead of jumping between fixed tiers. EXL3 improves accuracy at low bit widths over EXL2.
See also: ExLlamaV2 / ExLlamaV3, Bits per Weight (BPW)
quantization · nvidia · exllama · consumer
Also called: NF4, load_in_4bit
The library that adds on-the-fly 8-bit and 4-bit quantization to Hugging Face Transformers, via `load_in_4bit` and the NF4 data type. It is the standard way to load a large model onto a small GPU for QLoRA fine-tuning. For pure inference throughput, a pre-quantized GPTQ, AWQ, or GGUF file is faster.
See also: LoRA / QLoRA, Hugging Face Transformers
quantization · transformers · fine-tuning
Also called: KV cache quant, quantized KV
Storing the attention key/value cache at lower precision — typically 8-bit, sometimes 4-bit — instead of FP16. It roughly halves or quarters the memory that long contexts consume, which is often the difference between a 32k context fitting or not. Q8 KV is close to free in quality terms; Q4 keys visibly degrade recall on long documents.
See also: KV Cache, Context Window, Out of Memory (OOM)
Fix: context length KV cache OOM
kv cache · context · vram · quantization
Also called: QAT
Training or fine-tuning a model while simulating quantization error, so the final weights are already robust to being compressed. QAT releases — Gemma has shipped them — beat post-training quantization of the same model at the same bit width. Look for "QAT" in a repository name when choosing between 4-bit versions.
See also: Quantization, Fine-Tuning
quantization · training · quality
What you actually download: file formats, repositories, and the metadata that comes with weights. (11 terms)
The file format used by llama.cpp and Ollama for quantized models. Stands for 'GPT-Generated Unified Format'. A single .gguf file contains the full model weights and metadata. Quantization level is encoded in the filename (e.g., Q4_K_M, Q8_0, F16).
See also: GGML, safetensors, K-Quants
format · ollama · llamacpp · file
The predecessor to GGUF, and still the name of the underlying C tensor library that llama.cpp is built on. As a file format it is obsolete — modern llama.cpp cannot load .ggml files. If you find one in an old tutorial, look for the GGUF re-upload of the same model instead of trying to convert it.
format · legacy · llamacpp
The standard format for distributing unquantized model weights, designed to replace Python pickle. It stores tensors in a flat binary layout with a JSON header, so files memory-map instantly and cannot execute code on load. Anything you download from Hugging Face for use with Transformers, vLLM, or fine-tuning will be safetensors.
See also: PyTorch .bin (Pickle), Sharded Weights, Hugging Face Hub
format · hugging face · security · file
Also called: pytorch_model.bin
The legacy PyTorch checkpoint format, serialized with Python pickle. It is a security risk: loading a .bin file can execute arbitrary code embedded by whoever uploaded it. Prefer safetensors for anything from an untrusted source, and treat a repository that offers only .bin files as a reason for caution.
See also: safetensors
format · security · legacy
Also called: model shards
A model split across several files — model-00001-of-00004.safetensors and so on — with an index JSON mapping tensor names to shards. Sharding keeps individual files under hosting limits and lets loaders stream. You need every shard plus the index; a partial download fails with a missing-tensor error rather than a clear message.
See also: safetensors, Hugging Face Hub
format · download · hugging face
Also called: HF Hub, huggingface.co
The main repository for open-weight models, datasets, and quantized conversions, addressed as `org/model-name`. Practically every local runtime downloads from it. Gated models require accepting a licence and supplying an access token, which is the usual reason an otherwise correct download command returns a 401.
See also: Model Card, Repo ID, safetensors
download · repository · hugging face
The `organization/model` identifier that uniquely names a model on Hugging Face — for example `meta-llama/Llama-3.3-70B-Instruct`. Quantized re-uploads keep the original name with a suffix and a different owner, so the repo ID is how you tell an official release from a community conversion of it.
See also: Hugging Face Hub, Model Card
hugging face · naming · download
Ollama's build recipe — a short text file that names a base model and layers on a system prompt, chat template, sampling defaults, and adapters. `ollama create mymodel -f Modelfile` turns it into a reusable local model. It is the cleanest way to pin one set of parameters for a whole team without editing application code.
See also: Ollama, Ollama Tag, System Prompt
ollama · config · setup
The `model:variant` identifier Ollama uses to pull and run weights — for example `llama3.3:70b` or `qwen3:8b-q4_K_M`. The bare tag `:latest` resolves to a default quantization, usually Q4_K_M, which surprises people who assume they downloaded full precision. Name the quantization explicitly for reproducible setups.
See also: Ollama, Q4_K_M, Modelfile
Windows: the terminal cannot find the ollama command
ollama · naming · quantization
Also called: mmproj, vision projector
A separate weights file that maps image encoder output into the language model's token embedding space. Vision models in GGUF need both the model file and its matching mmproj file — loading the model alone yields a text-only assistant that appears to ignore images. The projector must come from the same conversion as the model.
See also: Multimodal Model, GGUF
vision · gguf · files · multimodal
The architecture manifest in a Hugging Face model repository: layer count, hidden size, attention head counts, vocabulary size, RoPE settings, and maximum position embeddings. Loaders read it to build the model before loading weights. It is also where you verify a model's real trained context length rather than a marketing claim.
See also: Hidden Size, RoPE, Context Window
config · hugging face · architecture
How much a model can read at once, what that costs in VRAM, and what happens when you exceed it. (9 terms)
The maximum number of tokens a model can process at once — its working memory. Llama 3.1 has 128k tokens (~96,000 words). Larger context = more expensive in VRAM. Context is consumed by your prompt, conversation history, and the response.
See also: KV Cache, Effective Context, Context Overflow
memory · tokens · context · performance
Key-Value cache: stores intermediate attention computations so the model doesn't recompute the entire context on every new token. Larger context windows require more KV cache memory. On a 7B model with 8k context, the KV cache can use 1–2GB of VRAM on top of the model weights.
See also: KV Cache Quantization, Grouped-Query Attention (GQA), PagedAttention
memory · attention · vram · performance
Also called: max_tokens, num_predict
The cap on how many tokens a single response may contain, set separately from the context window. Output tokens are drawn from the same context budget as the prompt, so prompt length plus max output must fit inside the window. Setting it too low is why answers get cut off mid-sentence.
See also: Context Window, Stop Sequences
generation · limits · config
Context windows beyond roughly 32k tokens, now common at 128k and reaching 1M in some releases. The constraint locally is almost never the model — it is KV cache VRAM, which scales linearly with context length. Retrieval quality also degrades well before the advertised maximum, so a 128k window rarely means 128k of usable recall.
See also: Effective Context, Lost in the Middle, YaRN
context · vram · limits
The context length at which a model still reliably uses information, as opposed to the maximum it technically accepts. Long-context benchmarks routinely show accuracy falling sharply past a fraction of the advertised window. Treat the number on the model card as a ceiling and validate on your own documents.
See also: Long Context, Needle in a Haystack, Lost in the Middle
context · quality · evaluation
The well-documented tendency of LLMs to use information at the start and end of a long context more reliably than material buried in the middle. The practical response is ordering, not length: put the critical instruction last, place key documents at the edges, and retrieve fewer, better chunks instead of padding the window.
See also: Effective Context, RAG (Retrieval-Augmented Generation), Reranker
context · quality · rag
Also called: truncation, context shift
What happens when a conversation exceeds the context window. Runtimes respond differently — some truncate the oldest turns, some error out, some silently shift the window and drop the system prompt with it. Losing the system prompt to a silent shift is a common cause of an assistant "forgetting" its instructions mid-session.
See also: Context Window, System Prompt
context · troubleshooting · chat
Reusing the computed KV cache for a prompt prefix that has already been processed, so repeated system prompts, few-shot examples, and conversation history do not have to be recomputed. Locally this is prefix caching in llama.cpp, vLLM, and SGLang; on cloud APIs it appears as a discounted cached-input token rate.
See also: Prefix Caching, System Prompt, Prefill
performance · context · cost
The deliberate allocation of a context window across system prompt, retrieved documents, conversation history, tool definitions, and room for the answer. Agent stacks blow their budget on tool schemas more often than on content — verbose tool definitions can eat a large share of the window before any real work starts.
See also: Context Window, Tool Schema, Context Engineering
context · agents · planning
The software that loads weights and serves tokens — from one-command CLIs to production inference engines. (13 terms)
The most popular local LLM runtime. A CLI + REST API that manages model downloads, quantization selection, and inference with a simple interface. Compatible with the OpenAI API format. Run a model with one command: `ollama run llama3.2`. Supports Mac, Windows, and Linux.
See also: llama.cpp, Ollama Tag, OpenAI-Compatible API
runtime · tool · cli · api · setup
The C/C++ inference engine that most consumer local-AI tools are built on, including Ollama and LM Studio. It runs GGUF models across CUDA, ROCm, Metal, Vulkan, and plain CPU, with partial GPU offload when a model does not fit. Using it directly gives you every sampling and cache flag the wrappers hide.
See also: GGUF, llama-server, GPU Offloading
runtime · engine · gguf · cpu
llama.cpp's built-in HTTP server, exposing an OpenAI-compatible endpoint plus a web UI. It is the lightest way to put a GGUF model behind an API for other applications, with direct control over context size, GPU layers, KV cache type, and slot count for concurrent requests.
See also: llama.cpp, OpenAI-Compatible API
runtime · server · api · llamacpp
A desktop application for running local models with a graphical interface — model browser, chat window, and a local OpenAI-compatible server. It handles GGUF and MLX, and shows estimated VRAM fit before you download. The usual first stop for people who want local AI without a terminal.
Fix: LM Studio failed to load model
runtime · gui · desktop · beginner
A high-throughput inference server built for serving many concurrent users, using PagedAttention, continuous batching, and prefix caching. It targets full-precision and GPU-quantized formats — FP8, AWQ, GPTQ, and increasingly FP4 — rather than CPU offload. For one user on one desktop GPU, llama.cpp is simpler; past a handful of concurrent requests, vLLM wins decisively.
See also: PagedAttention, Continuous Batching, SGLang
serving · throughput · production · gpu
A serving engine focused on structured generation and aggressive prefix reuse, built around RadixAttention — a radix-tree KV cache that shares prefixes across requests automatically. It is particularly strong for agent workloads where many calls share a long system prompt or few-shot block.
See also: vLLM, Prefix Caching, Structured Output
serving · throughput · structured output · production
NVIDIA's compiled inference library, which builds a hardware-specific engine for a given model, precision, and batch shape. It delivers the best throughput available on NVIDIA hardware at the cost of a build step and much less flexibility — change the model or the max batch size and you rebuild the engine.
serving · nvidia · production · optimization
Also called: ExLlama
A fast inference library for quantized models on consumer NVIDIA GPUs, paired with the EXL2/EXL3 formats. Its niche is squeezing maximum single-user speed out of a card whose VRAM you want to fill exactly, thanks to fractional bit-rate quantization. No CPU offload — the model must fit.
See also: EXL2 & EXL3, Speculative Decoding
runtime · nvidia · consumer · speed
Apple's array framework for machine learning on Apple Silicon, with an LLM stack (`mlx-lm`) that runs and fine-tunes models using unified memory. MLX builds are typically faster than GGUF on the same Mac and support LoRA fine-tuning locally — the practical route to training on a laptop.
See also: Apple Silicon, Unified Memory, LoRA / QLoRA
apple · mac · runtime · fine-tuning
Also called: transformers
The reference Python library for loading and running models from the Hub. It supports every architecture first, which makes it the way to run a brand-new model on release day before quantized conversions appear. It is the slowest option for serving, so it is a research and prototyping tool, not a production server.
See also: safetensors, bitsandbytes, vLLM
python · library · research
A self-hosted browser front end for local models, typically pointed at Ollama or any OpenAI-compatible endpoint. It adds multi-user accounts, conversation history, document upload with built-in RAG, and model switching — the missing interface layer between a raw inference server and something a team will actually use.
See also: Ollama, OpenAI-Compatible API, RAG (Retrieval-Augmented Generation)
ui · self-hosted · rag · team
A single executable file that bundles model weights with the llama.cpp runtime, producing one artefact that runs on Windows, macOS, and Linux without installation. It is the simplest way to hand a working local model to a non-technical colleague or to run one on a machine where you cannot install software.
runtime · portable · distribution
Also called: /v1/chat/completions
The de facto standard local-inference interface: `/v1/chat/completions` with the same request and response shape as OpenAI's API. Ollama, llama-server, vLLM, SGLang, and LM Studio all expose it, so switching a client from a cloud provider to a local model usually means changing a base URL and a dummy API key.
See also: Ollama, vLLM, llama-server
Fix: Ollama connection refused
api · integration · standard
The metrics and optimizations that separate a usable local setup from a frustrating one. (18 terms)
Also called: t/s, tok/s, TPS
The standard speed metric for local inference: how many tokens the model generates each second. Roughly 5 t/s is painful, 15–20 t/s reads as comfortable real-time, and above 40 t/s is faster than most people read. For single-user generation it is governed by memory bandwidth divided by the size of the active weights.
See also: Memory Bandwidth, Time to First Token (TTFT)
speed · benchmark · metric
Also called: TTFT, first-token latency
How long you wait between sending a prompt and seeing the first token — the latency users actually perceive. It is dominated by prefill, so it grows with prompt length while generation speed stays flat. Prefix caching is the highest-leverage fix, since it removes prefill entirely for a repeated prefix.
See also: Prefill, Prefix Caching, Chunked Prefill
latency · metric · ux
Also called: ITL, TPOT, time per output token
The gap between consecutive generated tokens, the reciprocal of tokens per second. It is the metric that matters once streaming has started: steady 50ms gaps feel smooth, while erratic gaps feel broken even at the same average. Under batching, ITL is where contention between concurrent requests shows up first.
See also: Tokens per Second (t/s), Continuous Batching
latency · metric · streaming
Also called: prompt processing, prompt eval
The first phase of inference, where the model processes the entire prompt in parallel and builds the KV cache. It is compute-bound and fast per token — thousands of tokens per second — but its total cost scales with prompt length, which is why long prompts delay the first token even on fast hardware.
See also: Decode, Time to First Token (TTFT), Chunked Prefill
inference · latency · compute
Also called: generation phase, autoregressive decoding
The second phase of inference, generating one token at a time, each conditioned on everything before it. Decode is memory-bound: every token requires reading the model's active weights from VRAM again. This sequential, bandwidth-limited loop is why generation is orders of magnitude slower per token than prefill.
See also: Prefill, Memory-Bound vs Compute-Bound, Speculative Decoding
inference · speed · memory
Splitting a long prompt into fixed-size chunks — often 512 or 2,048 tokens — so prefill work interleaves with ongoing decoding instead of blocking it. Without it, one user pasting a huge document stalls every other request on the server. It is standard in vLLM and SGLang and trades a little TTFT for far better tail latency.
See also: Prefill, Continuous Batching, vLLM
serving · latency · scheduling · vllm
Also called: automatic prefix caching, APC, RadixAttention
Keeping the KV cache for a shared prompt prefix so later requests skip recomputing it. System prompts, few-shot blocks, RAG context, and multi-turn history all repeat, so hit rates are high in practice. The effect is large: a cached 8k-token prefix can cut time to first token by an order of magnitude.
See also: Prompt Caching, KV Cache, SGLang
serving · latency · kv cache · optimization
Also called: in-flight batching, dynamic batching
A scheduling technique where new requests join the running batch as soon as any sequence finishes, instead of waiting for the whole batch to complete. It keeps the GPU saturated and can multiply serving throughput several times over static batching. It is the core reason vLLM-class servers outperform naive loops under load.
See also: vLLM, Batch Size, PagedAttention
serving · throughput · scheduling
A KV cache allocator that stores attention state in fixed-size blocks, like virtual memory pages, rather than one contiguous slab per sequence. It nearly eliminates the memory fragmentation that forced servers to over-reserve VRAM, so many more sequences fit at once. It is the mechanism behind vLLM's throughput advantage.
See also: KV Cache, vLLM, Continuous Batching
serving · kv cache · memory · vllm
Also called: speculative sampling, assisted generation
A speed technique where a small draft model proposes several tokens ahead and the full model verifies them all in one parallel pass. Accepted guesses cost roughly what the small model cost, and output is mathematically identical to normal decoding. Typical local speedups are 1.5–3x, best on predictable text like code.
See also: Draft Model, Decode
speed · optimization · decoding
The small, fast model that proposes candidate tokens in speculative decoding. It must share the target model's tokenizer, and works best when it is from the same family — a 0.5B drafting for a 32B, for example. Both models occupy VRAM simultaneously, so the draft has to be small enough to be worth its footprint.
See also: Speculative Decoding, Small Language Model (SLM)
speed · decoding · vram
How many sequences the GPU processes together in one forward pass. Because decode is memory-bound, batching is nearly free at first: doubling from one to two concurrent users barely reduces per-user speed while doubling total throughput. Gains flatten once the workload becomes compute-bound or the KV cache fills VRAM.
See also: Continuous Batching, Throughput vs Latency, Memory-Bound vs Compute-Bound
serving · throughput · concurrency
The central serving trade-off: throughput is total tokens per second across all users, latency is the wait experienced by one. Larger batches raise throughput and worsen per-user latency. A single-user desktop should optimise latency; a shared team server should optimise throughput, and they call for different engines and settings.
See also: Batch Size, Inter-Token Latency (ITL), Concurrency
serving · metric · planning
The number of requests in flight at once, and the main input to sizing a shared local deployment. VRAM sets the ceiling, because each active sequence holds its own KV cache. Estimating peak concurrency, multiplying by per-sequence KV cost, and adding weights is how you decide whether one GPU is enough.
See also: KV Cache, Batch Size, Self-Hosting
serving · capacity · vram
Also called: memory mapping, use_mmap
Memory-mapping a model file so the OS pages weights in on demand rather than reading the whole file into RAM first. It makes a second launch of the same model nearly instant, since the pages are still in the file cache. Disable it when running from slow network storage, where page faults are worse than one upfront read.
See also: System RAM, Model Load Time
loading · memory · llamacpp
Also called: cold load, warm-up
How long it takes to move weights from disk into VRAM before the first token can be produced — seconds on NVMe, minutes over a slow network share. Runtimes that unload idle models trade VRAM for this cost on every request. Keeping a model resident is the difference between a snappy assistant and a 30-second pause.
See also: mmap, Cold Start
loading · latency · storage
Moving part of the KV cache to system RAM when it will not fit in VRAM. It lets you run a longer context than the GPU can hold, but every offloaded block crosses PCIe on each attention step, so the slowdown is severe. Quantizing the KV cache is almost always the better first move.
See also: KV Cache Quantization, GPU Offloading, PCIe Bandwidth
kv cache · vram · context · performance
An optimized implementation of the attention algorithm that is significantly faster and more memory-efficient. It processes attention in tiles to minimize HBM (GPU memory) reads/writes. Flash Attention 2 & 3 are standard in most modern local inference frameworks. Enables longer context windows.
See also: Attention (Self-Attention), KV Cache, HBM
performance · memory · attention · optimization
What is inside a transformer, and the attention and routing variants that changed how big models fit in memory. (19 terms)
The neural network architecture behind essentially every modern LLM, introduced in 2017. It stacks identical blocks, each combining self-attention with a feed-forward network, so every token can look at every other token in the sequence. Its parallelism during training is what made scaling to billions of parameters practical.
See also: Attention (Self-Attention), Layer, State Space Model (Mamba)
architecture · fundamentals
The core mechanism in Transformers. For each token in the input, attention computes how much to 'attend to' (focus on) every other token. This is what allows the model to understand relationships between words regardless of distance. Multi-head attention runs several attention operations in parallel.
See also: Transformer, Grouped-Query Attention (GQA), Flash Attention
architecture · transformer · mechanism
Also called: MHA
The original attention design, where each head keeps its own query, key, and value projections. It is expressive but expensive at inference, because the KV cache stores keys and values for every head at every layer. Nearly all recent models replace it with GQA or MLA to shrink that cache.
See also: Grouped-Query Attention (GQA), Multi-Head Latent Attention (MLA)
architecture · attention · kv cache
Also called: GQA
An attention variant where several query heads share one set of key/value heads, cutting KV cache size by the sharing ratio with almost no quality loss. It is why a modern 8B model holds a 128k context in memory that older designs would need many times more VRAM for. Standard across the Llama 3, Qwen, and Mistral families.
See also: Multi-Head Attention (MHA), Multi-Query Attention (MQA), KV Cache
architecture · attention · kv cache · vram
Also called: MQA
The most aggressive form of key/value sharing: all query heads share a single KV head. It gives the smallest possible KV cache, at a measurable cost in quality. GQA is the compromise that largely replaced it, keeping most of the memory saving without the accuracy hit.
See also: Grouped-Query Attention (GQA)
architecture · attention · kv cache
Also called: MLA
DeepSeek's attention design, which compresses keys and values into a low-rank latent vector and reconstructs them on the fly. The KV cache shrinks dramatically compared with GQA while quality holds or improves. It is a large part of why DeepSeek models serve long contexts at unusually low memory cost.
See also: Grouped-Query Attention (GQA), KV Cache
architecture · attention · deepseek · kv cache
Also called: SWA, local attention
Restricting most layers to attend only to a fixed window of recent tokens — commonly 4k — instead of the entire context. KV cache then grows with the window rather than the sequence, making very long inputs affordable. Models usually interleave a few full-attention layers so global information can still propagate.
See also: Long Context, KV Cache, Hybrid Architecture
architecture · attention · long context
An architecture where the model is split into many 'expert' sub-networks. Each token is routed to only 2–8 experts, so total params are huge but active params (and VRAM) are much smaller. DeepSeek R1 has 671B total params but only 37B active at once.
See also: Active Parameters, Expert Router, Dense Model
architecture · vram · deepseek · llama 4
Also called: active params
The subset of an MoE model's parameters actually used for a given token. It sets generation speed, while total parameters set the memory you must have available. A 100B model with 3B active generates roughly as fast as a 3B dense model — but you still need to hold all 100B somewhere.
See also: MoE (Mixture of Experts), Expert Router, Memory Bandwidth
moe · speed · vram
Also called: gating network, MoE router
The small learned network inside each MoE layer that decides which experts handle each token. It is trained with a load-balancing objective so traffic spreads across experts instead of collapsing onto a few. Routing is per token, not per request, so a single sentence can touch a large share of the model.
See also: MoE (Mixture of Experts), Active Parameters
moe · architecture
A model where every parameter participates in every token — the conventional design, as opposed to MoE. Dense models are simpler to quantize, serve, and fine-tune, and at small sizes they are usually stronger per gigabyte. The Llama, Qwen dense line, Gemma, and Mistral small models are all dense.
See also: MoE (Mixture of Experts), Active Parameters
architecture · model type
Also called: rotary embeddings, rope_theta
Rotary Position Embedding — the standard way transformers encode token position, by rotating query and key vectors at frequencies that depend on position. Because it encodes relative distance, it extrapolates better than older absolute schemes, and its base frequency (`rope_theta`) is the parameter that context-extension methods adjust.
See also: YaRN, config.json, Context Window
architecture · position · context
Also called: RoPE scaling, context extension
A RoPE-scaling method that extends a model's usable context far beyond its training length by interpolating position frequencies unevenly, with a short fine-tune. It is how models trained at 4k–32k ship with 128k windows. Applying it at load time without the matching fine-tune degrades quality at short contexts as well as long.
See also: RoPE, Long Context, Effective Context
context · architecture · long context
Also called: transformer block, decoder layer
One transformer block — attention plus a feed-forward network — stacked dozens of times to form the model. Layer count and hidden size together determine parameter count. Layers are also the unit of GPU offload: `n_gpu_layers` decides how many blocks live in VRAM and how many stay on the CPU.
See also: Transformer, GPU Offloading, Hidden Size
architecture · offloading
Also called: d_model, embedding dimension
The width of the vectors flowing through the model, listed as `hidden_size` in config.json. It drives both parameter count and per-token KV cache cost, alongside layer count and head configuration. Together with layers and vocabulary size it is enough to compute a model's memory footprint from first principles.
See also: Layer, config.json, KV Cache
architecture · config · vram
The number of distinct tokens a model's tokenizer can emit — around 128k for Llama 3, over 150k for several recent multilingual models. Bigger vocabularies encode text in fewer tokens, especially for non-English languages and code, which means more content fits in the same context window.
See also: Tokenizer, Tokens, Context Window
tokenizer · architecture · multilingual
The raw, unnormalised scores the model produces for every token in the vocabulary at each step, before softmax turns them into probabilities. Every sampling parameter — temperature, top-p, penalties, grammar constraints — operates on logits. Exposing them is what makes constrained decoding and classification with an LLM possible.
See also: Temperature, Logprobs, Constrained Decoding
generation · sampling · internals
Also called: SSM, Mamba
A non-attention sequence architecture that keeps a fixed-size recurrent state instead of a growing KV cache, so memory stays constant as context grows. Pure state space models trail transformers on recall-heavy tasks, which is why most shipping designs are hybrids that interleave Mamba blocks with attention layers.
See also: Hybrid Architecture, KV Cache, Transformer
architecture · long context · memory
A model that mixes attention layers with cheaper alternatives — state space blocks, sliding-window attention, or linear attention — to keep long-context memory bounded without losing recall. Nemotron and several 2026 open-weight releases use this pattern, and it is the main reason large context windows became affordable to serve.
See also: State Space Model (Mamba), Sliding Window Attention (SWA)
architecture · long context · 2026
The knobs that shape a response — randomness, stopping, formatting, and structured output. (16 terms)
A sampling parameter (0.0–2.0) that controls response randomness. Temperature=0 is deterministic (always picks the most probable token). Temperature=1 is balanced. Temperature>1.5 produces creative/chaotic output. For coding tasks, use 0.1–0.3; for creative writing, try 0.7–1.2.
See also: Top-p (Nucleus Sampling), Min-p, Greedy Decoding
sampling · generation · creativity · output
Also called: top_p, nucleus sampling
A sampler that considers only the most probable tokens whose cumulative probability reaches p — 0.9 or 0.95 typically — and discards the long tail. Unlike top-k it adapts to the distribution, staying narrow when the model is confident and widening when it is not. Most defaults pair it with temperature.
See also: Temperature, Top-k, Min-p
sampling · generation
Also called: top_k
A sampler that keeps only the k highest-probability tokens at each step, then samples among them. It is simple but blunt: a fixed k is too permissive when the model is certain and too restrictive when it is not. Modern configurations prefer top-p or min-p, often disabling top-k entirely by setting it to 0.
See also: Top-p (Nucleus Sampling), Min-p
sampling · generation
Also called: min_p
A sampler that keeps tokens whose probability is at least a fraction of the top token's — 0.05 means "at least 5% as likely as the best option". It scales with model confidence more gracefully than top-p and holds up at higher temperatures, which is why creative-writing setups favour it.
See also: Top-p (Nucleus Sampling), Temperature
sampling · generation · creative
Also called: repeat_penalty
A multiplier that lowers the probability of tokens already present in the context, used to stop a model looping. Values just above 1.0 — 1.05 to 1.15 — help; higher settings degrade output by penalising ordinary words like "the" and breaking code, where repeated syntax is correct.
See also: Frequency & Presence Penalty, Temperature
sampling · quality · troubleshooting
Also called: frequency_penalty, presence_penalty
Two additive OpenAI-style penalties. Frequency penalty scales with how often a token has already appeared, discouraging overuse; presence penalty applies a flat cost the moment a token appears at all, pushing toward new topics. Both are gentler than a multiplicative repetition penalty.
See also: Repetition Penalty
sampling · openai · generation
Always taking the single highest-probability token — equivalent to temperature 0. It gives the most reproducible output and is the right default for extraction, classification, and structured formats. It also makes repetition loops more likely on weaker models, since there is no randomness to break a cycle.
See also: Temperature, Seed, Beam Search
sampling · deterministic · generation
Keeping several candidate continuations alive at once and returning the highest-scoring complete sequence. It helps in translation and other constrained tasks but produces bland, repetitive open-ended text, and costs memory and time proportional to beam width. Most local chat runtimes leave it off.
See also: Greedy Decoding, Speculative Decoding
sampling · decoding · translation
The random-number seed that makes sampling reproducible: the same seed, prompt, settings, and build produce the same output. It does not survive changes in batch size, GPU, or runtime version, because floating-point reduction order changes with them. Useful for debugging, not a guarantee of determinism across machines.
See also: Greedy Decoding, Temperature
sampling · reproducibility · debugging
Also called: stop tokens, stop strings
Strings that halt generation the moment they appear, on top of the model's own end-of-sequence token. They are how you stop a model from writing the next turn of a conversation for you. A model that never stops usually has a chat-template mismatch, not a missing stop string.
See also: Special Tokens, Chat Template, Max Output Tokens
generation · config · troubleshooting
Also called: log probabilities, token probabilities
The log-probabilities the model assigned to the tokens it chose, and optionally to the alternatives it rejected. They are the basis for confidence scoring, cheap classification, and detecting low-certainty answers before showing them to a user. Most OpenAI-compatible local servers expose them.
See also: Logits, LLM-as-a-Judge
generation · confidence · api
Also called: SSE, token streaming
Sending tokens to the client as they are generated instead of waiting for the full response, usually over server-sent events. It does not change total generation time but transforms perceived speed, since the user starts reading after time-to-first-token rather than after the last token.
See also: Time to First Token (TTFT), Inter-Token Latency (ITL)
api · ux · latency
Also called: JSON mode, JSON schema output
Forcing a model to emit valid JSON, or JSON matching a specific schema, by constraining which tokens may be sampled at each step. Because invalid tokens are masked out, the output parses by construction — far more reliable than asking politely and retrying. Supported by llama.cpp, vLLM, SGLang, and Ollama.
See also: Constrained Decoding, GBNF Grammar, Function Calling
api · json · reliability · agents
Also called: guided decoding, grammar-constrained decoding
The general mechanism behind structured output: at each step, a state machine derived from a grammar or schema masks every token that would make the output invalid. It guarantees syntactic correctness at negligible speed cost, and can enforce anything expressible as a grammar — JSON, SQL, a fixed set of labels.
See also: Structured Output, GBNF Grammar, Logits
generation · reliability · json
Also called: GBNF
llama.cpp's grammar format, a BNF variant that describes exactly which strings a model may produce. Writing a grammar lets you pin output to a rigid shape — a date, an enum, a specific record layout — without post-processing. It is the lowest-level and most flexible form of constrained decoding available locally.
See also: Constrained Decoding, Structured Output, llama.cpp
llamacpp · grammar · json
Also called: thinking budget, reasoning tokens
A control on how much internal thinking a reasoning model does before answering, exposed as a level (low/medium/high) or an explicit token budget. Higher effort improves hard maths and code at a direct cost in latency and tokens. Setting it low, or disabling thinking, is the fix when a reasoning model deliberates over trivial questions.
See also: Reasoning Model, Test-Time Compute, Chain of Thought
reasoning · latency · config
Giving a model access to your own documents without retraining it. (14 terms)
A technique to give an LLM access to external documents without fine-tuning. Your documents are split into chunks, embedded into vectors, and stored in a vector database. At query time, the most relevant chunks are retrieved and injected into the prompt as context.
See also: Embeddings, Chunking, Vector Database, Reranker
architecture · documents · search · embeddings
Numerical vector representations of text. Every word or chunk of text is mapped to a list of floating-point numbers that capture semantic meaning. Similar concepts have similar vectors. Used in RAG, semantic search, and clustering. Models like nomic-embed-text or all-minilm create them.
See also: Embedding Dimension, Cosine Similarity, Vector Database
vectors · search · rag · similarity
Also called: vector store, vector DB
A store that indexes embeddings for fast nearest-neighbour search. Options range from libraries embedded in your process (FAISS, Chroma, LanceDB) to servers (Qdrant, Weaviate, Milvus) and Postgres with pgvector. For collections under roughly a million chunks, an embedded library on the same machine is usually enough.
See also: Embeddings, HNSW, RAG (Retrieval-Augmented Generation)
rag · search · infrastructure
Also called: text splitting
Splitting documents into retrievable pieces before embedding them. Chunk size is the highest-leverage decision in a RAG system: too small and context is lost, too large and the embedding blurs across topics. Splitting on structure — headings, sections, function boundaries — beats fixed character counts almost every time.
See also: RAG (Retrieval-Augmented Generation), Embeddings, Reranker
rag · preprocessing · quality
Also called: cross-encoder
A second-stage model that scores retrieved chunks against the query directly, rather than by vector distance, and reorders them. Cross-encoder rerankers like bge-reranker are slower per document but far more accurate. Retrieve 50 candidates, rerank, keep 5 — usually the single biggest quality win in a RAG pipeline.
See also: RAG (Retrieval-Augmented Generation), Top-k Retrieval, Lost in the Middle
rag · quality · search
Also called: BM25 + vector, reciprocal rank fusion
Combining keyword search (BM25) with vector search and fusing the ranked lists. Keyword search nails exact matches — error codes, product SKUs, function names — that embeddings blur together, while vectors catch paraphrases. Hybrid retrieval consistently beats either method alone on real document sets.
See also: Semantic Search, Reranker, Vector Database
rag · search · quality
Searching by meaning rather than exact words, by embedding the query and finding the nearest document vectors. It answers "how do I stop my GPU running out of memory" with a document titled "CUDA OOM errors" even with no shared keywords. It is the retrieval half of RAG, and is useful on its own.
See also: Embeddings, Cosine Similarity, Hybrid Search
search · embeddings · rag
The standard measure of how close two embeddings are: the cosine of the angle between them, from -1 to 1. It compares direction while ignoring magnitude, which is what you want for text. Most vector databases normalise vectors so that cosine similarity and dot product become equivalent.
See also: Embeddings, Vector Database
embeddings · math · search
Hierarchical Navigable Small World — the graph index most vector databases use for approximate nearest-neighbour search. It gives sub-linear query time with high recall, tuned by the `ef` and `M` parameters that trade memory and build time for accuracy. Approximate, not exact: a small recall loss buys an enormous speed gain.
See also: Vector Database, Cosine Similarity
vector database · index · search
Also called: vector dimension
The length of an embedding vector — 384, 768, and 1024 are common, with some models producing 4096. Larger dimensions capture more nuance and cost proportionally more storage and search time. The dimension is fixed per model, so changing embedding models means re-embedding the entire corpus.
See also: Embeddings, Matryoshka Embeddings
embeddings · storage · rag
Also called: MRL, Matryoshka Representation Learning
Embeddings trained so that truncating the vector still leaves a usable representation — take the first 256 dimensions of a 1024-dimension vector and lose only a little accuracy. This lets one model serve a cheap coarse index and an expensive precise one, and cuts storage substantially with minimal quality cost.
See also: Embedding Dimension, Embeddings
embeddings · storage · efficiency
How many chunks a RAG system pulls into the prompt. More is not better: irrelevant chunks dilute attention and push the useful passage into the middle of the context, where recall is weakest. Retrieve broadly, rerank, and pass a small number of high-confidence chunks.
See also: Reranker, Lost in the Middle, Token Budget
rag · config · quality
Constraining a model to answer from supplied sources and to say so when they do not contain the answer. It is the main defence against hallucination in document QA, and it is a prompt-and-evaluation discipline as much as a retrieval one — including asking for span-level citations you can verify programmatically.
See also: Hallucination, RAG (Retrieval-Augmented Generation)
rag · accuracy · quality
Also called: graph RAG, knowledge graph RAG
A RAG variant that first extracts entities and relationships into a knowledge graph, then retrieves over graph structure as well as text similarity. It answers questions that need connections across many documents — "which projects share this dependency?" — that flat chunk retrieval cannot. The cost is an expensive indexing pass.
See also: RAG (Retrieval-Augmented Generation), Chunking
rag · graph · advanced
How models call software, plan multi-step work, and spend extra compute to think. (11 terms)
A system where an LLM chooses actions in a loop — calling tools, reading results, and deciding what to do next — rather than producing one response. Agents need reliable tool calling and long context, which is why local agent work favours models specifically trained for it over general chat models of the same size.
See also: Function Calling, ReAct, Agentic Workflow
agents · tools · automation
Also called: tool calling, tool use
A model capability where, given descriptions of available functions, the model emits a structured call — name plus JSON arguments — instead of prose. Your code executes it and returns the result. It is the foundation of every agent, and a model's tool-calling reliability matters far more than its benchmark scores for agent work.
See also: Tool Schema, Structured Output, Model Context Protocol (MCP)
agents · api · json
Also called: function schema, tool definition
The JSON Schema description of a tool — its name, purpose, and parameters — that goes into the prompt so the model knows what it can call. Schemas are pure context overhead: a dozen verbose tools can consume a large share of the window before any work begins, which is why tool selection and terse descriptions matter.
See also: Function Calling, Token Budget, Model Context Protocol (MCP)
agents · json · context
Also called: MCP
An open standard, introduced by Anthropic in late 2024 and now widely adopted, for connecting models to tools and data through a common client/server interface. One MCP server exposing a filesystem, database, or API works with any MCP-capable client, replacing bespoke integrations per application.
See also: Function Calling, Tool Schema, AI Agent
agents · standard · integration · tools
Also called: reason and act
The reason-act-observe loop that most agents implement: the model states its reasoning, picks an action, sees the result, and repeats until done. Its practical value is debuggability — the reasoning trace shows exactly where a run went wrong, which is otherwise nearly impossible to diagnose.
See also: AI Agent, Chain of Thought, Agentic Workflow
agents · pattern · reasoning
A multi-step process where a model plans, executes, checks its own work, and retries. Compared with a single call it is far more capable and far more expensive: token use per task can be tens of times higher. That cost profile is a strong argument for running agents on local hardware, where tokens are not metered.
See also: AI Agent, Test-Time Compute, Cost per Million Tokens
agents · automation · cost
An architecture that splits work across several specialised agents — planner, researcher, coder, reviewer — coordinating through messages or a shared scratchpad. It helps when subtasks genuinely differ, and hurts when it just adds handoffs: every boundary loses context and multiplies token cost.
See also: AI Agent, Context Engineering
agents · architecture · orchestration
An agent that reads a repository, edits files, and runs tests in a loop. Local coding agents need strong tool calling, long context for large files, and low latency, since a single task can involve dozens of calls. Model choice here is driven by SWE-bench-style results and tool reliability, not general chat quality.
See also: AI Agent, SWE-bench, Function Calling
Best local models for coding agents
agents · coding · developer
Also called: CoT, step-by-step reasoning
Having a model work through intermediate steps before answering, either because it was prompted to or because it was trained to. It measurably improves multi-step arithmetic, logic, and code, and costs output tokens and latency. Reasoning models internalise it; ordinary models can be prompted into it.
See also: Reasoning Model, Test-Time Compute, ReAct
reasoning · prompting · accuracy
Also called: inference-time scaling, test-time scaling
Spending more computation at inference — longer reasoning, multiple sampled attempts, self-verification — to get better answers from the same weights. It is the scaling axis that largely replaced "just train a bigger model", and it is why a mid-size local reasoning model can beat a much larger one given enough thinking budget.
See also: Reasoning Model, Reasoning Effort, Pass@k
reasoning · scaling · 2026
The discipline of deciding what goes into the context window at each step of an agent run — which tools to expose, which history to keep, what to summarise, what to drop. As agents got longer-running, it displaced prompt wording as the main determinant of whether a system works reliably.
See also: Token Budget, Tool Schema, Context Window
agents · context · design
How models are built and specialized — including the methods that fit on a single consumer GPU. (18 terms)
The first and by far most expensive training phase: next-token prediction over trillions of tokens of general text, producing a base model. It costs millions of dollars and thousands of GPUs, which is why almost nobody pretrains from scratch — the open-weight ecosystem exists so you can start from someone else's pretraining run.
See also: Base Model, Continued Pretraining, Fine-Tuning
training · base model · cost
Continuing to train an existing model on your own data so it adopts a format, tone, or domain vocabulary. It is the right tool for behaviour and style, and the wrong tool for facts — for knowledge that changes, retrieval beats fine-tuning on both accuracy and update cost. With LoRA it fits on a single consumer GPU.
See also: LoRA / QLoRA, SFT (Supervised Fine-Tuning), RAG (Retrieval-Augmented Generation)
training · customization · lora
Training a pretrained base model on labeled input-output pairs to make it follow instructions. This is the first step in creating an 'instruct' model from a base model. Examples: training on instruction-response pairs from Alpaca, ShareGPT, or your own domain-specific data.
See also: Instruct Model, Instruction Dataset, RLHF / DPO
training · fine-tuning · instruction · alignment
Parameter-Efficient Fine-Tuning methods. LoRA adds small trainable rank-decomposition matrices to attention layers, updating only ~1% of weights instead of all of them. QLoRA = LoRA on a 4-bit quantized model, enabling fine-tuning of 7B models on a single 6GB GPU.
See also: Adapter Weights, LoRA Rank & Alpha, bitsandbytes
fine-tuning · training · lora · qlora · adapter
Also called: LoRA adapter, PEFT adapter
The small file a LoRA fine-tune produces — typically tens to hundreds of megabytes rather than gigabytes — holding only the trained low-rank matrices. Adapters load on top of the unchanged base model, so you can ship several task-specific adapters against one set of weights, or merge one in permanently.
See also: LoRA / QLoRA, Model Merging
fine-tuning · files · lora
Also called: r, lora_alpha
The two settings that govern a LoRA fine-tune. Rank (r) sets the capacity of the injected matrices — 8 to 16 for style, 32 to 64 for real new capability. Alpha scales the adapter's contribution, conventionally set to r or 2r. Higher rank means more trainable parameters, more VRAM, and more risk of overfitting.
See also: LoRA / QLoRA, Adapter Weights
fine-tuning · lora · hyperparameters
Reinforcement Learning from Human Feedback (RLHF) and Direct Preference Optimization (DPO) are alignment techniques. Both use human preference data (chosen vs rejected responses) to make models more helpful and less harmful. DPO is simpler — no reward model needed.
See also: GRPO, Alignment, SFT (Supervised Fine-Tuning)
alignment · training · preference · safety
Group Relative Policy Optimization — the reinforcement-learning method DeepSeek used to train R1's reasoning. It samples a group of answers per prompt and scores each relative to the group average, removing the need for a separate value network. With a verifiable reward such as unit tests, it trains reasoning without human preference labels.
See also: RLHF / DPO, Reasoning Model
training · reasoning · rl · deepseek
Also called: domain-adaptive pretraining, CPT
Running more next-token training on a base model with a large domain corpus — medical, legal, or a low-resource language — before instruction tuning. It is the method for teaching genuinely new domain knowledge, unlike SFT, and it needs billions of tokens rather than the thousands of examples SFT uses.
See also: Pretraining, Catastrophic Forgetting
training · domain · pretraining
The loss of previously learned capability when a model is fine-tuned narrowly — a model trained hard on one output format often gets worse at everything else. Mitigations are lower learning rates, fewer epochs, LoRA instead of full fine-tuning, and mixing general instruction data into the training set.
See also: Fine-Tuning, LoRA / QLoRA, Learning Rate
training · quality · risk
Also called: mergekit, SLERP merge
Combining two or more fine-tunes of the same base model by arithmetic on their weights, using methods like SLERP, TIES, or DARE. It requires no training compute and can blend a coding fine-tune with a chat fine-tune in minutes. Results are unpredictable, so merges must be evaluated, not assumed.
See also: Adapter Weights, Fine-Tuning
fine-tuning · weights · community
Also called: activation checkpointing
A memory-for-compute trade during training: instead of storing every intermediate activation for the backward pass, recompute them from saved checkpoints. It typically cuts training memory substantially at roughly 20–30% extra compute time, and it is routinely what makes a fine-tune fit on a consumer GPU.
See also: Fine-Tuning, LoRA / QLoRA
training · memory · fine-tuning
Also called: LR
How large a step each optimizer update takes — the hyperparameter most likely to ruin a fine-tune. Too high and the model degrades into repetition; too low and nothing changes. Full fine-tuning uses roughly 1e-5 to 2e-5; LoRA tolerates 1e-4 to 2e-4 because it updates far fewer parameters.
See also: Epoch, Catastrophic Forgetting
training · hyperparameters · fine-tuning
One complete pass over the training dataset. Instruction fine-tunes usually need only one to three: past that, models memorise examples verbatim and lose generality. Watch validation loss rather than counting epochs, and stop when it stops falling.
See also: Learning Rate, Fine-Tuning
training · hyperparameters
A collection of prompt/response pairs used for supervised fine-tuning, in a format such as Alpaca or ShareGPT. Quality dominates quantity — a thousand carefully curated examples routinely beat a hundred thousand scraped ones. Every example must use the target model's chat template.
See also: SFT (Supervised Fine-Tuning), Synthetic Data, Chat Template
training · data · sft
Training examples generated by another model instead of collected from humans. It is how most modern instruction datasets are built, and it is cheap and scalable. The risks are inherited errors and narrowed diversity, so production pipelines filter, deduplicate, and verify synthetic examples before training on them.
See also: Instruction Dataset, Distillation
training · data · distillation
A fine-tuning library with hand-written kernels that roughly doubles LoRA and QLoRA training speed while cutting memory use, on a single GPU. It is the usual answer to "how do I fine-tune an 8B model on a 16GB card", and it also publishes widely used quantized and QAT model conversions.
See also: LoRA / QLoRA, Gradient Checkpointing
fine-tuning · library · lora · speed
A configuration-driven fine-tuning framework: you describe the model, dataset, and method in YAML and it handles the training loop. It supports full fine-tuning, LoRA, QLoRA, and preference methods across many architectures, and its reproducible configs are why community fine-tunes are often shared as an Axolotl file.
See also: LoRA / QLoRA, SFT (Supervised Fine-Tuning)
fine-tuning · framework · config
How model quality is measured, and how to read a leaderboard without being misled by it. (15 terms)
A measure of how well a language model predicts a text sample. Lower perplexity = the model finds the text more predictable = better quality. Used to compare models and quantization levels. A heavily quantized model will have higher perplexity (more uncertainty) than the FP16 original.
See also: KL Divergence, Quantization, Benchmark
evaluation · benchmark · quality · quantization
A standardised test set used to compare models on a task. Benchmarks are useful for coarse ranking and unreliable for predicting performance on your specific workload, because published scores depend on prompt format, sampling settings, and possible contamination. Treat them as a shortlist filter, then evaluate on your own data.
See also: Benchmark Contamination, Eval Harness, LMArena Elo
evaluation · comparison
Also called: MMLU
Multiple-choice knowledge benchmarks across dozens of academic subjects. MMLU is the long-standing standard and is now saturated and heavily contaminated at the top of the leaderboard. MMLU-Pro adds harder questions and ten answer options instead of four, restoring separation between strong models.
See also: Benchmark, Benchmark Contamination, GPQA
benchmark · knowledge · evaluation
Graduate-level Google-Proof Q&A — physics, chemistry, and biology questions written so that a non-expert with web access still fails them. Its Diamond subset is the common reporting split. It resists contamination better than MMLU and is a good discriminator among reasoning models.
See also: Benchmark, Reasoning Model, MMLU & MMLU-Pro
benchmark · reasoning · science
A 164-problem Python benchmark where a model writes a function from a docstring and is scored by hidden unit tests. It is the original code benchmark, now largely saturated and present in most training corpora. Contamination-resistant successors like LiveCodeBench draw problems from contests postdating a model's cutoff.
See also: Pass@k, SWE-bench, Benchmark Contamination
benchmark · coding · python
A benchmark built from real GitHub issues, where the model must produce a patch that makes the repository's tests pass. Because it requires navigating a codebase and using tools, it correlates with practical coding-agent usefulness far better than function-writing benchmarks. SWE-bench Verified is the human-validated subset most results cite.
See also: Coding Agent, HumanEval, Benchmark
benchmark · coding · agents
The American Invitational Mathematics Examination, adopted as a standard reasoning benchmark because each answer is an integer, making scoring unambiguous. New AIME papers each year provide fresh, uncontaminated problems, which is why AIME scores became the headline metric for reasoning models.
See also: Reasoning Model, Test-Time Compute, Benchmark
benchmark · math · reasoning
A benchmark that tests literal instruction following with programmatically checkable constraints — "answer in exactly three bullet points", "do not use the letter e". It measures compliance rather than knowledge, which makes it unusually predictive of whether a model will behave inside an automated pipeline.
See also: Benchmark, Structured Output
benchmark · instruction following · reliability
Also called: Chatbot Arena, Arena Elo
A ranking derived from blind human pairwise comparisons of model responses, scored with an Elo system. It captures preference and style in a way static benchmarks cannot, and it also rewards them — chattier, better-formatted answers score well independently of correctness. Read it alongside task benchmarks, not instead of them.
See also: Benchmark, LLM-as-a-Judge
benchmark · human evaluation · ranking
Also called: pass@1
The probability that at least one of k sampled attempts is correct — the standard metric for code benchmarks. Pass@1 measures single-shot reliability; pass@10 measures whether the model can find the answer given retries. A large gap between them means sampling more and verifying is a cheap accuracy win.
See also: HumanEval, Test-Time Compute
benchmark · coding · metric
Using a strong model to grade another model's outputs against a rubric, in place of human review. It scales evaluation enormously and carries known biases — toward longer answers, toward its own family's style, and toward whichever response appears first. Randomise order and calibrate against human labels on a sample.
See also: Benchmark, LMArena Elo
evaluation · automation · quality
Also called: data contamination, test set leakage
When benchmark questions appear in a model's training data, so its score reflects memorisation rather than capability. It is widespread on older public benchmarks. The defences are private held-out sets, problems published after the training cutoff, and being suspicious of a model that tops a leaderboard but disappoints in use.
See also: Benchmark, MMLU & MMLU-Pro, HumanEval
evaluation · reliability · risk
Also called: NIAH
A long-context test that hides a specific fact in a long document and asks the model to retrieve it, varying both depth and total length. Passing it proves retrieval, not comprehension — multi-fact and reasoning-over-context variants are much harder, and are where advertised context windows usually break down.
See also: Effective Context, Long Context, Lost in the Middle
evaluation · long context · retrieval
Also called: KLD
A measure of how far one probability distribution is from another, used to judge quantization damage by comparing a quantized model's token distribution against the original's. It is more sensitive than perplexity, which can look almost unchanged while specific behaviours have measurably shifted.
See also: Perplexity, Quantization
evaluation · quantization · metric
Also called: lm-eval, lm-evaluation-harness
A framework that runs standardised benchmark suites against a model with consistent prompts and scoring — lm-evaluation-harness is the common one. Using a harness is what makes numbers comparable, since prompt formatting and sampling settings alone can move a score by several points.
See also: Benchmark, LLM-as-a-Judge
evaluation · tooling · reproducibility
Running models for more than one person: parallelism, servers, and what it costs versus a cloud API. (15 terms)
Running models on infrastructure you own or rent exclusively, rather than calling a shared API. It gives you data control, fixed costs, no rate limits, and version stability — a hosted model cannot be deprecated out from under you. The costs are hardware, electricity, and the operational work of keeping it running.
See also: Local AI, On-Premise, Total Cost of Ownership (TCO)
deployment · privacy · infrastructure
A long-running process that holds a model in VRAM and answers requests over HTTP. Keeping weights resident is the point: it removes load time from every request. Production servers add batching, queuing, prefix caching, metrics, and health checks that a bare CLI loop does not have.
See also: vLLM, llama-server, Model Load Time
deployment · serving · infrastructure
Also called: TP
Splitting each layer's weight matrices across multiple GPUs so they compute one token together. It is how a model larger than any single card runs, and how you cut latency across cards. Every layer requires an all-reduce between GPUs, so interconnect speed — NVLink versus PCIe — sets the ceiling.
See also: Pipeline Parallelism, NVLink, Multi-GPU Inference
multi-gpu · scaling · serving
Also called: PP, layer split
Assigning whole layers to different GPUs so a token passes through card one, then card two. Communication is far lighter than tensor parallelism, making it viable over ordinary PCIe or even across machines. It does not reduce single-request latency — it only lets a bigger model fit.
See also: Tensor Parallelism, PCIe Bandwidth
multi-gpu · scaling · serving
Running one model across several GPUs, by splitting layers (pipeline) or splitting each layer (tensor). Two 24GB cards can hold a model a single 24GB card cannot, but they do not double speed — expect meaningfully less than 2x, and less still without a fast interconnect.
See also: Tensor Parallelism, Pipeline Parallelism, NVLink
multi-gpu · vram · scaling
Also called: $/M tokens, token pricing
The standard unit for comparing inference costs, quoted separately for input and output because output is several times more expensive to produce. Comparing it against local inference means converting your hardware amortisation and electricity into the same unit at your actual monthly token volume.
See also: Total Cost of Ownership (TCO), Break-Even Point, GPU-Hour
Local vs cloud cost calculator
cost · cloud · comparison
The rental unit for cloud GPUs — one hour of one accelerator, from well under a dollar for a consumer-class card to several dollars for an H100-class one. It is the right comparison basis when you are serving your own model rather than paying per token, and the basis for estimating a hardware purchase's payback.
See also: Cost per Million Tokens, Break-Even Point
cost · cloud · rental
Also called: TCO
The full cost of running models locally: hardware amortised over its useful life, electricity at your rate, cooling, and the staff time to operate it. TCO is the only honest basis for a local-versus-cloud comparison — the hardware price alone understates it, and ignoring it makes local look free after purchase.
See also: Break-Even Point, TDP, Self-Hosting
cost · planning · enterprise
The monthly token volume at which local inference becomes cheaper than a cloud API, once hardware and electricity are counted. It falls as usage rises: light use never repays a GPU, while sustained high-volume or agentic workloads — which burn tokens by the million — often pay one back within months.
See also: Total Cost of Ownership (TCO), Cost per Million Tokens, Agentic Workflow
cost · planning · roi
Also called: on-prem
Running AI infrastructure in your own data centre or office rather than in a provider's cloud. Organisations choose it for data residency, regulatory obligations, and predictable cost at scale. It is distinct from air-gapped: on-prem hardware usually still has network access.
See also: Air-Gapped Deployment, Sovereign AI, Self-Hosting
enterprise · deployment · compliance
Also called: air gap, offline deployment
Running models on hardware with no network connection to the outside world — the standard for classified, defence, and some clinical environments. Everything must be staged in physically: weights, runtime, dependencies, and updates. Open-weight models are the only practical option, since no API call can leave the enclave.
See also: On-Premise, Open-Weight Model, Data Residency
security · enterprise · compliance
AI capability a country or organisation controls end to end — data, model weights, compute, and operations — without dependence on a foreign provider. It is the driver behind national model programmes and much European enterprise interest in open weights, since only downloadable weights can be operated entirely under local jurisdiction.
See also: Open-Weight Model, On-Premise, Data Residency
enterprise · policy · compliance
The delay when a request arrives and no model is loaded — allocating a GPU, pulling weights, and filling VRAM, which can take from seconds to minutes. It is the central trade-off in serverless GPU hosting: you stop paying for idle time and pay in first-request latency instead.
See also: Model Load Time, Serverless GPU
latency · serverless · deployment
GPU capacity billed per second of actual use, scaling to zero when idle. It suits spiky or occasional workloads where a dedicated instance would sit unused, and it is a poor fit for latency-sensitive interactive use because of cold starts. Sustained load is cheaper on a reserved instance or your own hardware.
See also: Cold Start, GPU-Hour, Break-Even Point
cloud · cost · scaling
Also called: TPM, RPM
A cap a hosted API places on requests or tokens per minute. Rate limits are a recurring reason teams move to local inference: batch jobs and agent loops hit them constantly, and self-hosted models are limited only by your own hardware. The local equivalent is a queue, which delays rather than rejects.
See also: Self-Hosting, Concurrency
cloud · limits · api
What you are legally allowed to do with open weights, and the risks of putting a model in front of users. (15 terms)
A permissive open-source licence with an explicit patent grant, and the most business-friendly licence common for model weights. It allows commercial use, modification, and redistribution with attribution, and imposes no user-count threshold or field-of-use restriction. Qwen and gpt-oss weights ship under it.
See also: MIT License, Open-Weight Model, Llama Community License
licensing · commercial · open source
The shortest and most permissive common licence: do anything, keep the copyright notice, no warranty. Unlike Apache 2.0 it contains no explicit patent grant, which some legal teams care about. DeepSeek has released recent model weights under it.
See also: Apache 2.0, Open-Weight Model
licensing · commercial · open source
Also called: Llama license
Meta's custom licence for Llama weights. It permits commercial use but adds conditions absent from Apache 2.0: attribution requirements, naming rules for derivative models, an acceptable-use policy, and a special-permission threshold for very large deployments. Read it directly rather than assuming it behaves like open source.
See also: Apache 2.0, Open-Weight Model
licensing · meta · commercial
Also called: CC-BY-NC, research-only license
A licence permitting research and personal use only, most often CC-BY-NC. Models under it cannot be used in a product, even internally at a company, without separate permission. It is common for research releases and for some fine-tunes whose training data carries the restriction — always check derivatives, not just the base model.
See also: Apache 2.0, OpenRAIL
licensing · restriction · compliance
Also called: RAIL license
A family of Responsible AI licences that allow commercial use while prohibiting specific applications — surveillance, discrimination, generating disinformation. The restrictions bind downstream users too, so anyone shipping an OpenRAIL model must pass the same use limits on to their own customers.
See also: Non-Commercial License, Open-Weight Model
licensing · ethics · compliance
The European Union's risk-tiered AI regulation, with obligations phased in from 2025 onward. It imposes transparency and documentation duties on general-purpose model providers and stricter requirements on high-risk deployments in areas like hiring, credit, and medical devices. Self-hosting does not remove the obligations of a deployer.
See also: Sovereign AI, Data Residency
regulation · compliance · eu · enterprise
A requirement that data be stored and processed within a specific jurisdiction. It is one of the strongest arguments for local models: a prompt processed on hardware in your own building never crosses a border, which is far simpler to demonstrate to an auditor than a cloud provider's regional-processing commitments.
See also: Sovereign AI, On-Premise, Zero Data Retention
compliance · privacy · enterprise
Also called: ZDR, no-retention
A contractual commitment that a provider does not store prompts or outputs after serving a request. It is the strongest privacy guarantee a hosted API can offer, and it is still a promise about someone else's systems. Local inference makes the question moot, because the data never leaves the machine.
See also: Data Residency, Local AI
privacy · compliance · cloud
An attack where instructions hidden in content the model reads — a web page, a document, a tool result — are followed as if they came from the user. It is the defining security problem for agents, because a model cannot reliably distinguish data from instructions. Mitigate with least-privilege tools, output validation, and human approval for consequential actions.
See also: Jailbreak, Guardrails, AI Agent
security · agents · risk
A prompt crafted to bypass a model's safety training and elicit content it was trained to refuse. Distinct from prompt injection, which targets the application around the model rather than its alignment. Open-weight models are inherently more exposed, since anyone can also modify the weights directly.
See also: Prompt Injection, Alignment, Abliterated Model
security · alignment · risk
Checks placed around a model rather than inside it — input filters, output classifiers, schema validation, and tool permission boundaries. Because alignment training can be bypassed, guardrails are the layer that actually enforces policy in production. Llama Guard and similar small classifiers are commonly used locally for this.
See also: Prompt Injection, Alignment, Structured Output
safety · production · architecture
Training a model to behave according to intended values — helpful, honest, and refusing genuinely harmful requests — usually via preference optimization after instruction tuning. Alignment is a property of the weights, so it can be fine-tuned away by anyone with the open weights, which is why deployed systems need guardrails as well.
See also: RLHF / DPO, Guardrails, Red Teaming
safety · training · alignment
Deliberately adversarial testing of a model or the system around it, looking for jailbreaks, injection paths, data leaks, and harmful outputs before users find them. For agents the target is the whole loop — tools, permissions, and data flow — not the model in isolation.
See also: Jailbreak, Prompt Injection, Guardrails
safety · testing · security
Also called: uncensored model, abliteration
A model modified after training to remove its refusal behaviour, typically by ablating the direction in activation space associated with refusing. Variants labelled "abliterated" or "uncensored" appear widely in community repositories. They also lose some instruction-following quality, and shipping one to end users transfers all safety responsibility to you.
See also: Alignment, Guardrails, Jailbreak
safety · community · risk
Also called: data masking
Stripping or masking personal data before it reaches a model. It is a standard control for cloud APIs and often relaxed for local inference, where the data never leaves the trusted boundary — one of the concrete operational savings of running models yourself, alongside the compliance review it removes.
See also: Data Residency, Local AI, Zero Data Retention
privacy · compliance · preprocessing