A large language model (LLM) is a neural network trained on a huge amount of text to do one thing extremely well: predict the next token given the tokens before it. Everything else you see an LLM do, from answering questions to writing code, emerges from repeating that single prediction step many times. If you are asking what is a large language model from a developer's point of view, the short answer is a very capable, probabilistic text-completion function you call over an API.

This guide explains how LLMs work without the math, what their real limits are, and how to reason about them when you build software on top of them.

What is a large language model, really?

Strip away the marketing and an LLM is a function with this shape:

f(sequence of tokens) -> probability distribution over the next token

To generate a reply, the system samples one token from that distribution, appends it to the input, and calls the function again. It keeps going until it emits a stop token or hits a length limit. That loop is called autoregressive generation.

The "large" part refers to two things: the number of learned parameters (the weights inside the network, often in the billions) and the amount of training data. Scale turned out to matter. As models grew, they started handling tasks nobody explicitly trained them for, such as translation, summarization, and step-by-step reasoning, simply because those patterns exist in the text they learned from.

For the broader landscape of where LLMs sit relative to classic ML and deep learning, see AI vs machine learning vs deep learning vs generative AI.

How does a large language model work?

Tokens, not words

LLMs never see raw characters or whole words. Text is first split into tokens, which are frequent chunks of characters. A common word may be one token, while a rare word or a long identifier may be split into several. Tokens matter to developers because pricing, context limits, and latency are all measured in them. Our tokenization guide goes deeper on how tokenizers are built.

Embeddings and the transformer

Each token is mapped to a vector of numbers called an embedding. Those vectors flow through a stack of transformer layers. The key idea in a transformer is attention: at every layer, each token can look at every earlier token and decide how much it matters for the current prediction. That is how the model connects a pronoun to the noun it refers to, or a closing bracket to the function it closes, even when they are far apart.

After the final layer, the model produces a score for every token in its vocabulary. Those scores are turned into probabilities, and the next token is chosen.

Sampling and temperature

How the next token is picked is a knob you control:

  • Temperature scales the probabilities. Low values make output more deterministic; higher values make it more varied.
  • Top-p (nucleus) sampling restricts choices to the smallest set of tokens whose combined probability reaches p.
  • Max tokens caps the length of the response.

For extraction, classification, or code, keep temperature low. For brainstorming, raise it a little.

How are LLMs trained?

Training usually happens in stages:

  1. Pretraining. The model reads a massive corpus and learns to predict the next token. This is where it absorbs grammar, facts, coding patterns, and a rough model of the world. It is by far the most expensive stage.
  2. Instruction tuning. The model is fine-tuned on examples of instructions paired with good responses, so it behaves like an assistant instead of a document autocompleter.
  3. Preference tuning. Humans or other models rank candidate answers, and the model is adjusted to prefer the higher-ranked style. This improves helpfulness and reduces harmful output.

The result is a model whose knowledge is frozen at its training cutoff. It does not learn from your conversations unless someone retrains or fine-tunes it.

LLM vs traditional software

Aspect Traditional code Large language model
Behavior Deterministic Probabilistic
Specification Explicit logic you write Instructions and examples in a prompt
Failure mode Exceptions, wrong branches Plausible but wrong output
Knowledge Whatever you encode Training data up to a cutoff
Testing Unit tests with exact asserts Evaluation sets and scoring
Cost model CPU time Tokens in and out

The biggest mental shift is the failure mode. A bug in normal code usually looks broken. A bad LLM answer often looks perfectly confident. That is why validation and evaluation matter so much.

What are the limitations of large language models?

  • Hallucination. The model optimizes for likely text, not true text. When it lacks the facts, it can produce fluent fabrications.
  • Stale knowledge. Anything after the training cutoff is unknown unless you supply it in the prompt.
  • Context window limits. The model can only attend to a fixed number of tokens at once. Long documents must be chunked, summarized, or retrieved selectively.
  • Weak arithmetic and exact recall. Models can reason about math but are unreliable at long exact calculations. Hand those to real code.
  • Prompt sensitivity. Small wording changes can shift results, so prompts deserve version control and tests.

Most production patterns exist to work around these limits. Retrieval-augmented generation injects fresh, relevant documents into the prompt to reduce hallucination; see what is RAG and our longer article, RAG explained. Tool calling lets the model delegate math, search, or database queries to code.

How do developers use an LLM in an application?

In practice you call a hosted model or a self-hosted one through a chat-style API. Here is a minimal TypeScript example using a generic OpenAI-compatible endpoint:

type Message = { role: "system" | "user" | "assistant"; content: string };

async function complete(messages: Message[]): Promise<string> {
  const res = await fetch(`${process.env.LLM_BASE_URL}/v1/chat/completions`, {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      Authorization: `Bearer ${process.env.LLM_API_KEY}`,
    },
    body: JSON.stringify({
      model: process.env.LLM_MODEL,
      messages,
      temperature: 0.2,
      max_tokens: 400,
    }),
  });
  if (!res.ok) throw new Error(`LLM request failed: ${res.status}`);
  const data = await res.json();
  return data.choices[0].message.content;
}

const answer = await complete([
  { role: "system", content: "You are a concise assistant for backend engineers." },
  { role: "user", content: "Explain idempotency keys in two sentences." },
]);
console.log(answer);

A few habits make this production-ready:

  • Keep secrets in environment variables, never in client code.
  • Validate output, especially if you parse JSON or act on it.
  • Log prompts, token counts, and latency so you can debug and control spend.
  • Build a small evaluation set of real inputs and expected qualities before you change models or prompts.

When cost becomes a concern, the techniques in how to reduce LLM API costs apply directly. For writing better instructions, see prompt engineering best practices.

When should you use an LLM, and when not?

LLMs shine when the input is messy natural language and the output can tolerate some variation: summarizing tickets, drafting replies, extracting fields from free text, classifying intent, or explaining code. They are a poor fit when you need guaranteed exactness, strict audit trails, or very low latency at tiny cost, such as computing a tax amount or validating a checksum. A good rule is to let the LLM handle the fuzzy language part and let ordinary code handle anything that must be exactly right.

Key takeaways

  • A large language model predicts the next token; generation is that prediction repeated in a loop.
  • Tokens drive cost, latency, and context limits, so learn to think in tokens.
  • Transformers use attention to relate every token to earlier ones, which is what makes long-range understanding possible.
  • Training has stages: pretraining for knowledge, then instruction and preference tuning for assistant behavior.
  • LLMs fail confidently, so validate outputs and ground them with retrieval or tools.
  • Use LLMs for fuzzy language tasks and keep exact logic in regular code.

Frequently asked questions

Is a large language model the same as AI?

No. An LLM is one type of AI model focused on text. AI is the broad field, machine learning is a subset, and LLMs are a specific kind of deep learning model built on the transformer architecture.

Do LLMs understand what they say?

They build rich internal representations of language that let them reason in useful ways, but they are trained to produce likely text, not verified truth. Treat their output as a strong draft that still needs checking for anything important.

What is a context window?

The context window is the maximum number of tokens the model can consider in one request, including your prompt and its reply. Anything outside that window is invisible to the model, which is why long documents are chunked or retrieved selectively.

Can I train my own large language model?

Pretraining from scratch requires enormous data and compute, so most teams do not. Instead they use an existing model and adapt it with prompting, retrieval, or fine-tuning. See RAG vs fine-tuning for how to choose.