Large Language Model (LLM)

A large language model (LLM) is a neural network — almost always a transformer — trained on enormous quantities of text (and increasingly code, images, and audio) to predict the next token in a sequence. That simple training objective, applied at the scale of hundreds of billions or trillions of parameters and trillions of training tokens, produces models that can write, summarize, translate, reason step-by-step, and hold conversations. Claude, GPT-4/GPT-5, Gemini, and Llama are all LLMs, though they differ in architecture details, training data, and how they're aligned to be helpful and safe. For SaaS builders, the LLM is the reasoning engine behind nearly every "AI feature" shipped today — support chatbots, copilots embedded in existing tools, content generators, and autonomous agents. What matters practically is that an LLM is a probabilistic next-token predictor, not a database: it doesn't "look up" facts, it generates the statistically likely continuation of your prompt given everything it learned during training. This is why LLMs hallucinate, why grounding them with retrieval (RAG) matters, and why prompt design has an outsized effect on output quality. Under the hood, a request to an LLM API is a list of messages (system prompt, user turns, assistant turns) plus parameters like temperature and max tokens; the model returns a completion, streamed token by token. A concrete example: a support-ticket triage feature might send `{"model": "claude-sonnet-4.5", "system": "Classify tickets into billing, bug, feature-request, or other. Reply with only the category.", "messages": [{"role": "user", "content": "My card was charged twice for the same invoice."}]}` and receive back `"billing"` in under a second. Builders choosing an LLM weigh cost per token, latency, context window size, and whether the vendor allows fine-tuning or requires prompt-only customization. Open-weight models (Llama, Mistral) can be self-hosted for data control; closed models (Claude, GPT) are accessed via API and updated by the vendor. Choosing an LLM for a SaaS feature is rarely a one-time decision — most production teams route different tasks to different model tiers within the same family (a fast, cheap model for simple classification; a frontier model for complex reasoning) and re-evaluate as new versions ship, since a model that was state-of-the-art six months ago may now be beaten on both cost and quality by a newer release. Builders should also budget for the fact that LLM output is non-deterministic by default (even at low temperature, exact byte-for-byte reproducibility isn't guaranteed across calls) and versioned (a provider deprecating an older model snapshot can silently change your product's behavior), so pinning model versions and monitoring output quality over time is standard production practice, not paranoia.