LLM là gì: giải thích cho developer về token, context window, giá và hallucination

Gọi API AI thì dễ, hiểu vì sao hóa đơn cao, vì sao cùng prompt ra kết quả khác, vì sao model tự tin bịa hàm mới khó. Bài này giải thích LLM cho developer: token, next-token prediction, context window, temperature, reasoning model và cách tính giá.

Bạn thêm tính năng tóm tắt review sản phẩm vào side project, gọi API của Claude hoặc GPT, demo chạy ngon. Một tuần sau có ba chuyện lạ. Hóa đơn API cao hơn con số bạn ước lượng. Cùng một review, hai lần gọi cho ra hai bản tóm tắt khác nhau. Và khi nhờ AI viết code tích hợp, nó tự tin gọi một hàm không hề có trong thư viện.

Cả ba chuyện đều có chung một lời giải thích: cách một LLM hoạt động. Bạn không cần biết toán của transformer để dùng tốt LLM, nhưng cần vài mental model đúng.

LLM là gì

LLM (Large Language Model) là mô hình ngôn ngữ lớn: một mạng neural được huấn luyện trên lượng văn bản rất lớn để làm một việc cốt lõi, dự đoán phần tiếp theo của một đoạn văn bản. Claude, GPT, Gemini, DeepSeek, Qwen đều là LLM.

Mental model dễ nhớ nhất: LLM là một bộ autocomplete cực mạnh. Bạn đưa vào một đoạn văn bản (prompt, lịch sử chat, code), nó viết tiếp. Chatbot, coding agent hay gọi tool đều được xây trên khả năng viết tiếp đó.

Token: đơn vị LLM đọc, viết và tính tiền

LLM không đọc theo ký tự hay theo từ, mà theo token: tokenizer cắt văn bản thành các mảnh, mỗi mảnh ứng với một con số trong từ điển của model.

Mình chạy thử tokenizer o200k_base (tokenizer mà thư viện tiktoken của OpenAI dùng cho các model từ GPT-4o đến GPT-5) với vài chuỗi quen thuộc:

Với tiếng Anh, docs Anthropic quy đổi thô 1 token khoảng 4 ký tự hoặc 0,75 từ, tùy ngôn ngữ và nội dung.

Tiếng Việt thường tốn token hơn tiếng Anh

Mình đếm token cho 3 cặp câu cùng nghĩa, ví dụ "Hãy viết một hàm kiểm tra địa chỉ email của người dùng và trả về thông báo lỗi nếu email không hợp lệ." so với "Please write a function that validates the user's email address and returns an error message if it is invalid.":

Đây là phép thử nhỏ, không phải benchmark, nhưng xu hướng rõ: cùng nội dung, tiếng Việt tốn nhiều token hơn, và tokenizer đời mới xử lý tiếng Việt tốt hơn hẳn đời cũ. Số liệu chỉ đúng cho hai tokenizer của OpenAI trong bảng (đo bằng tiktoken), không áp dụng trực tiếp cho Claude, Gemini hay GPT-6, vì tiktoken chưa công bố tokenizer của GPT-6. Với Claude, bạn tự đo được bằng endpoint đếm token ở phần code bên dưới.

Lưu ý thêm: mỗi model có tokenizer riêng. Theo docs Anthropic, tokenizer từ Claude Opus 4.7 trở đi sinh khoảng 30% token nhiều hơn tokenizer cũ cho cùng văn bản, nên so giá "mỗi triệu token" giữa các model chỉ là so tương đối.

Next-token prediction: LLM sinh chữ thế nào

Khi bạn gọi API, bên trong diễn ra một vòng lặp:

1. Toàn bộ input (system prompt, lịch sử chat, câu hỏi) được đổi thành token.
2. Model tính ra một phân phối xác suất cho token tiếp theo: token nào có khả năng xuất hiện bao nhiêu phần trăm.
3. Một token được chọn từ phân phối đó và nối vào cuối chuỗi.
4. Lặp lại từ bước 2, cho tới khi model sinh token kết thúc hoặc chạm giới hạn max_tokens.

Vòng lặp này giải thích vài hành vi quen thuộc:

• Output sinh lần lượt từng token, nên câu trả lời dài thì chậm, và streaming cho phép hiển thị từng phần ngay khi có.
• Output đắt hơn input. Với tất cả model nhắc trong bài, ở mức giá chuẩn, giá output gấp 5 lần giá input.
• Bị cắt giữa chừng thường là do chạm max_tokens: khi đó stop_reason trong response của Claude API là max_tokens thay vì end_turn.

Training và inference: hai giai đoạn khác nhau

Training là lúc lab AI dạy model: pretraining để học dự đoán token, rồi post-training để biết làm theo chỉ dẫn và dùng tool. Inference là lúc model được dùng: mọi lời gọi API của bạn đều là inference, trả tiền theo token. Hai hệ quả dev hay bỏ qua:

Model có "ngày cắt kiến thức". Nó chỉ biết những gì có trong dữ liệu training. Theo trang models overview của Anthropic, reliable knowledge cutoff của các model Claude hiện tại (Opus 5.5, Sonnet 5.5, Haiku 5.5) là tháng 6/2026. OpenAI ghi knowledge cutoff của GPT-6 Astra và GPT-6.1 Sol là 30/4/2026. Thư viện hay API thay đổi sau mốc đó thì model không biết, nên cần đưa tài liệu hiện hành vào context (dán docs, dùng MCP server tra docs, hoặc xây RAG).

Model không tự học trong lúc bạn chat. Trọng số model cố định khi inference, và Messages API là stateless: mỗi request phải gửi lại toàn bộ lịch sử hội thoại, cảm giác "nó nhớ" chỉ là do lịch sử được gửi lại. Vì vậy cuộc chat càng dài, mỗi lượt càng tốn nhiều input token.

Context window: bộ nhớ làm việc có giới hạn

Context window là số token tối đa model xử lý được trong một request, tính cả input lẫn output. Con số hiện tại của các model phổ biến:

1M token tương đương khoảng 555 nghìn từ tiếng Anh (theo docs Anthropic). Rất rộng, nhưng context càng dài thì request càng đắt, chậm, và độ chính xác có thể giảm (context rot). Cách quản lý context cho coding agent có ở bài Context engineering là gì.

Temperature và sampling: vì sao cùng prompt ra kết quả khác nhau

Ở bước 3, model không nhất thiết chọn token có xác suất cao nhất mà lấy mẫu (sampling) từ phân phối. Temperature điều chỉnh độ "phẳng" của phân phối: temperature thấp làm token xác suất cao càng dễ được chọn (output ổn định hơn), temperature cao làm các lựa chọn ít phổ biến có cơ hội hơn (output đa dạng hơn). top_p và top_k là hai cách khác để giới hạn tập token được chọn.

Đó là lý do cùng một prompt có thể cho hai câu trả lời khác nhau. Nhưng model mới đã thay đổi:

• Với toàn bộ model Claude hiện tại (Opus 5.5, Sonnet 5.5, Haiku 5.5) và các model từ Opus 4.7 trở đi, đặt temperature, top_p hoặc top_k khác giá trị mặc định sẽ nhận lỗi 400. Anthropic khuyên điều khiển hành vi bằng prompt.
• Một số model đời cũ như Haiku 4.5 vẫn nhận các tham số này. Nhưng docs của Anthropic lưu ý temperature = 0 chưa bao giờ đảm bảo output giống hệt nhau.

Cần output ổn định thì dùng structured outputs (ép output theo JSON schema), prompt rõ ràng kèm ví dụ, và validate output bằng code.

Reasoning model: khi LLM "nghĩ" trước khi trả lời

Các model mạnh hiện nay đều có chế độ suy luận: trước khi trả lời, model viết ra một đoạn lập luận (thử cách giải, tự kiểm tra, bỏ hướng sai) rồi mới đưa ra câu trả lời cuối. Với debug, thiết kế hay task agent nhiều bước, chế độ này thường cho kết quả tốt hơn. Ba điều cần nắm:

• Thinking tính tiền như output. Cả Anthropic và OpenAI đều ghi rõ token suy luận được tính là output token, kể cả khi bạn không nhìn thấy nội dung.
• Bạn thường không thấy phần suy nghĩ. Trên Opus 5.5, Sonnet 5.5 và Haiku 5.5, thinking bật sẵn và mặc định display: "omitted" (khối thinking trả về rỗng). Muốn xem bản tóm tắt, đặt display: "summarized".
• Điều khiển bằng effort. Claude dùng output_config.effort với các mức low, medium, high, xhigh, max; Opus 5.5 và Haiku 5.5 mặc định medium, Sonnet 5.5 mặc định high. Opus 5.5 không tắt được thinking, muốn rẻ hơn thì hạ effort. OpenAI dùng tham số reasoning.effort. Task đơn giản như phân loại thường chỉ cần effort thấp; task code và agent nhiều bước thì effort cao đáng tiền hơn.

Vì sao LLM "bịa" (hallucination)

Hallucination là khi model đưa ra thông tin sai nhưng rất tự tin: một hàm không tồn tại, một option CLI không có, một package npm sai tên. Nguyên nhân gốc nằm ở next-token prediction: model được tối ưu để viết tiếp một cách hợp lý, và câu trả lời sai vẫn có thể rất hợp lý về mặt ngôn ngữ. Bài nghiên cứu "Why language models hallucinate" của OpenAI (9/2025) chỉ ra thêm: cách training và đánh giá hiện nay thưởng cho việc đoán hơn là thừa nhận không chắc chắn, giống học sinh đi thi đoán bừa còn hơn bỏ trống.

Nó hay xảy ra khi hỏi về thứ sau knowledge cutoff, chi tiết hiếm, hoặc context thiếu thông tin. Cách giảm rủi ro:

• Đưa sự thật vào context: dán docs hiện hành, file type definition, schema database.
• Cho model đường lui: ghi rõ trong prompt "nếu không chắc, nói không biết". Cách viết prompt tốt hơn có ở bài Prompt cho lập trình.
• Kiểm chứng bằng máy: chạy type check, test, lint. Code bịa API thường chết ngay ở bước compile.
• Kiểm tra package trước khi cài: đúng tên, đúng tác giả, có lượt tải thật.

Giá theo token: tính thử chi phí một request

Giá API tính theo triệu token, tách riêng input và output. Bảng dưới lấy từ trang pricing chính thức (08/10/2026), kèm chi phí một request ví dụ: review code với 20.000 token input và 2.000 token output.

Cách tính: (20.000 × giá input + 2.000 × giá output) / 1.000.000. Nhân với 10.000 request mỗi ngày thì chênh lệch giữa các model là rất lớn. Con số thực tế còn lệch khỏi bảng vì:

• Thinking cộng vào output: phần suy luận không hiển thị vẫn được tính tiền.
• Tokenizer khác nhau: cùng một đoạn text ra số token khác nhau giữa Claude, GPT và Gemini.
• Giá thay đổi: Gemini 3.8 Flash lên $1,50 / $7,50 từ 1/1/2027; OpenAI tính giá long context cao hơn cho GPT-6 khi input vượt 272K token (ví dụ GPT-6.1 Sol lên $4 / $15); Anthropic tính giá chuẩn trên toàn bộ context 1M cho Opus 5.5 và Sonnet 5.5, riêng Haiku 5.5 đắt hơn khi prompt vượt 100K token.
• Có cách giảm giá: đọc từ prompt cache chỉ tốn 10% giá input hoặc thấp hơn tùy model Claude (Opus 5.5 là 5%); Batch API giảm 50% cho việc không cần kết quả ngay.

Muốn so sánh model theo chất lượng code thay vì chỉ theo giá, xem bài So sánh model AI lập trình 2026.

Code: gọi API và xem token usage

Ví dụ dưới dùng SDK chính thức @anthropic-ai/sdk (bản 0.132.0 lúc viết): đếm token trước khi gửi, gọi Claude Sonnet 5.5, rồi đọc usage thật và tính tiền.

npm install @anthropic-ai/sdk
export ANTHROPIC_API_KEY="..."   # lấy key tại platform.claude.com
node llm-demo.mjs

// llm-demo.mjs
import Anthropic from "@anthropic-ai/sdk";

const client = new Anthropic(); // tự đọc ANTHROPIC_API_KEY từ biến môi trường
const MODEL = "claude-sonnet-5-5";
const PRICE = { input: 2, output: 10 }; // USD cho 1 triệu token (bảng giá 08/10/2026)

const messages = [
  {
    role: "user",
    content: "Giải thích closure trong JavaScript trong 3 câu, kèm một ví dụ ngắn.",
  },
];

// 1. Đếm token input trước khi gửi (miễn phí, là số ước lượng)
const counted = await client.messages.countTokens({ model: MODEL, messages });
console.log("Input ước lượng:", counted.input_tokens, "tokens");

// 2. Gọi model
const res = await client.messages.create({
  model: MODEL,
  max_tokens: 4000,
  messages,
});

for (const block of res.content) {
  if (block.type === "text") console.log(block.text);
}

// 3. Đọc usage thật và tính tiền
const { input_tokens, output_tokens } = res.usage;
const cost = (input_tokens * PRICE.input + output_tokens * PRICE.output) / 1_000_000;

console.log({ input_tokens, output_tokens, stop_reason: res.stop_reason });
console.log(`Chi phí request: ~$${cost.toFixed(5)}`);

Khi chạy, để ý:

• countTokens miễn phí (có giới hạn request mỗi phút) và trả về số ước lượng, đủ để chặn prompt quá dài trước khi gửi.
• Trên Sonnet 5.5, thinking bật mặc định, nên output_tokens có thể lớn hơn đáng kể so với đoạn text in ra.
• Nếu bật prompt caching, usage có thêm cache_read_input_tokens và cache_creation_input_tokens, tính theo giá cache riêng, cần cộng vào công thức.
• Đổi content sang bản tiếng Anh cùng nghĩa rồi so input_tokens để tự thấy chênh lệch tiếng Việt với tokenizer của Claude.

Open-weight hay closed model

Closed model (Claude, GPT, Gemini) chỉ dùng được qua API hoặc app của nhà cung cấp: không cần phần cứng, trả theo token, dữ liệu gửi lên server nhà cung cấp. Open-weight model (các dòng DeepSeek, Qwen, Kimi hay gpt-oss của OpenAI) công bố trọng số để bạn tự chạy: dữ liệu ở trong hạ tầng của bạn, nhưng phải tự lo GPU, cài đặt, scale, và mỗi model một license cần đọc kỹ trước khi dùng thương mại.

Với phần lớn dev cá nhân và startup nhỏ, API closed model là lựa chọn nhanh nhất. Open-weight đáng cân nhắc khi dữ liệu không được rời hạ tầng công ty, khi lượng request rất lớn và ổn định, hoặc khi cần chạy offline.

Checklist cho dev khi làm việc với LLM

• Log usage của mọi request ngay từ ngày đầu, đặt max_tokens hợp lý và luôn kiểm tra stop_reason.
• Muốn output ổn định thì dùng structured outputs và validate bằng code, đừng trông vào temperature.
• Coi mọi output của LLM là bản nháp cần kiểm chứng: type check, test, review.

Tóm lại

LLM là cỗ máy dự đoán token tiếp theo. Từ ý đó suy ra gần hết những gì dev cần biết: tiền tính theo token, output khác nhau giữa các lần gọi, context có giới hạn, và model có thể bịa khi thiếu thông tin. Nhưng dù LLM mạnh đến đâu, người quyết định code nào được merge vẫn là bạn.

Nếu bạn đang làm frontend và muốn đủ vững để review code AI sinh ra, khóa React PRO của HoleTex dạy React tới mức đó. Còn nếu muốn rèn tư duy giải thuật để đánh giá được lời giải của AI, thử luyện thuật toán trên HoleTex Algo.

Bài liên quan

• Context engineering là gì: quản lý ngữ cảnh để AI agent code đúng
• So sánh model AI lập trình 2026
• AI agent là gì
• Prompt cho lập trình: cách viết prompt để AI code đúng ý
• Chạy AI local với Ollama

Nguồn tham khảo: Pricing (platform.claude.com), Models overview (platform.claude.com), Thinking (platform.claude.com), Effort (platform.claude.com), Claude Sonnet 5.5 (platform.claude.com), What's new in Claude Haiku 5.5 (platform.claude.com), Token counting (platform.claude.com), Pricing (developers.openai.com), Models (developers.openai.com), Reasoning models (developers.openai.com), Gemini API pricing (ai.google.dev), Why language models hallucinate (openai.com), tiktoken (github.com). Cập nhật 2026-10-08.