What is LLM?
An LLM (Large Language Model) is a parameterized neural model that estimates probabilities over token sequences and uses those probabilities to score, transform, or generate language-conditioned outputs. Its observed behavior belongs to a complete inference configuration, not to a model name alone.
Quick Facts
| Full Name | Large Language Model |
|---|---|
| Created | 2018 (GPT-1), scaled significantly from 2020 (GPT-3) |
| Specification | Official Specification |
How It Works
Training objective and adaptation
Pretraining compresses statistical regularities from a token corpus into parameters by optimizing a prediction objective. It does not store a verified database or grant an independent notion of truth. Supervised fine-tuning, preference optimization, reinforcement learning, retrieval, tools, and system prompts can change behavior, but each creates its own data, evaluation, and governance requirements.
Inference is a configured computation
At inference time, text or multimodal inputs are encoded into tokens, processed with learned parameters and supplied context, and decoded according to a sampling or reasoning policy. Output also depends on tokenizer and chat-template versions, context truncation, provider routing, tool results, cache behavior, and runtime limits. An API alias is therefore not a reproducible model identity.
Capabilities and boundaries
LLMs can transform text, extract structured fields, generate code, classify, summarize, translate, plan tool calls, and synthesize retrieved evidence. They can also fabricate support, omit constraints, mishandle negation or long context, expose sensitive inputs, follow prompt injection, loop on tools, and vary across attempts. Retrieval, low temperature, fine-tuning, or a larger context window can reduce selected errors but cannot guarantee correctness.
Evaluation contract
A defensible evaluation pins the release identity, dataset hash, split, prompt, tool permissions, retrieval version, harness commit, grader, sampling settings, and token, tool, and time budgets. Report task-level success and uncertainty, then segment safety, abstention, long-context, multilingual, tool-failure, and high-impact slices. Public benchmark scores from different harnesses should not be merged into a universal ranking.
Cost and serving
Compare cost per accepted task, including input and output tokens, cache behavior, retries, fallbacks, tools, validation, and human repair. For self-hosting, total stored parameters determine the raw weight lower bound; active parameters in a sparse model do not describe total memory. Add quantization metadata, KV cache, runtime workspaces, replicas, idle capacity, operations, and incident response.
Release and governance
A production release should have a signed evaluation artifact, explicit quality and risk gates, shadow replay, bounded canary, rollback thresholds, drift monitoring, and an owner. Preserve model and prompt lineage without logging secrets or hidden chain-of-thought. Re-evaluate after a model alias, weight, tokenizer, prompt, tool schema, retrieval corpus, policy, or runtime changes.
Key Characteristics
- Estimates probabilities over token sequences from learned parameters and supplied context
- Has behavior that depends on the exact model, tokenizer, prompt, decoding policy, tools, retrieval, and runtime
- Can be adapted through parameter updates, preference optimization, retrieval, tools, and control policies
- Requires task-specific evaluation because fluency and public benchmarks do not establish reliability
- Trades off quality, latency, context use, memory, cost, privacy, security, and operability
- Needs versioned release evidence, monitored deployment, and rollback for production use
Common Use Cases
- Extracting structured fields from documents with schema validation and calibrated abstention
- Answering questions over authorized evidence with retrieval, citations, and source verification
- Generating and reviewing code inside a sandbox with tests, tool budgets, and human approval
- Classifying, routing, summarizing, or translating high-volume text against measured quality thresholds
- Operating multi-step agents with least-privilege tools, bounded retries, and effect auditing
- Supporting high-impact professional decisions only with traceable evidence and accountable human review
Example
Loading code...Frequently Asked Questions
How is an LLM different from a traditional NLP model?
Many traditional NLP systems are optimized for a bounded task, while an LLM is broadly pretrained and can be adapted through prompts, retrieval, tools, or parameter updates. The boundary is not absolute: a smaller task-specific model can be more accurate, cheaper, private, and easier to verify. Compare exact releases on representative failure cases.
Does an LLM understand or store facts like a database?
An LLM learns parameters that support conditional token prediction; it is not a verified fact store. It may reproduce, combine, distort, or fabricate information. Systems that require current or auditable facts should retrieve authorized sources, preserve citations, validate outputs, and allow abstention.
Why is a model name not enough to reproduce an LLM result?
Results also depend on revision or weight digest, tokenizer, chat template, prompt, decoding and reasoning settings, tools, retrieval data, provider routing, and runtime limits. Record these fields with the dataset and harness version before comparing or releasing a system.
How should an LLM be evaluated for production?
Define acceptance and prohibited failures first, then evaluate a pinned release on a versioned, representative dataset under fixed tools and budgets. Measure task success, uncertainty, safety slices, p95 latency, retries, and cost per accepted task; shadow and canary the candidate with rollback thresholds.
Can an LLM run locally without a cloud API?
Some open-weight releases can. Feasibility depends on the exact artifact, license, total parameters, precision, context length, KV cache, batch size, inference engine, hardware, throughput target, and operational controls. Test the final quantized artifact and include patching, monitoring, access control, and failover in total cost.