Một LLM API Call hoạt động như thế nào? Giải thích trong 4 bước

Mỗi ngày bạn gửi đi hàng chục, có khi hàng trăm request tới OpenAI, Anthropic, hay Google Gemini. Nhưng từ lúc bạn gõ fetch('https://api.openai.com/v1/chat/completions', ...) cho đến lúc nhận được response chuyện gì thực sự đang diễn ra bên trong? Một bài viết gần đây của Jasmin trên Dev.to đã tóm gọn toàn bộ quá trình này chỉ trong 4 bước trực quan, và mình thấy đây là cách giải thích dễ hiểu nhất mà mình từng đọc.

Tại sao developer cần hiểu điều này?

Nếu bạn chỉ dùng LLM API như một black box gửi prompt, nhận text thì mọi thứ ổn cho đến khi nó không ổn. Latency cao bất thường? Token count phình lên không kiểm soát? Response bị cắt giữa chừng? Nếu không hiểu pipeline bên dưới, bạn sẽ debug như mò kim đáy bể.

Theo kinh nghiệm của mình, phần lớn bug liên quan đến LLM API không nằm ở code gọi API, mà nằm ở việc developer hiểu sai cách model xử lý input. Hiểu flow giúp bạn optimize prompt, giảm chi phí, và xử lý edge case tốt hơn rất nhiều.

Bước 1: Tokenization Cắt text thành miếng nhỏ

Khi bạn gửi một prompt lên API, điều đầu tiên xảy ra không phải là model "đọc" text của bạn. Thay vào đó, một tokenizer sẽ chạy trước để tách chuỗi text thành các token những đơn vị nhỏ hơn mà model thực sự hiểu được.

Một token không nhất thiết là một từ. Nó có thể là một phần của từ, một ký tự đặc biệt, hoặc thậm chí cả một từ ngắn. Ví dụ, từ "understanding" có thể bị tách thành ["under", "standing"] hoặc ["understand", "ing"] tùy tokenizer.

Điều mình thấy hay là: tiếng Việt thường tốn nhiều token hơn tiếng Anh cho cùng một ý nghĩa. Một câu tiếng Việt 10 từ có thể tốn 20-30 token, trong khi câu tiếng Anh tương đương chỉ tốn 10-15 token. Đây là lý do chi phí API khi làm sản phẩm tiếng Việt thường cao hơn bạn nghĩ.

Bước 2: Embedding Chuyển token thành vector

Sau khi có danh sách token, mỗi token được map sang một embedding vector một mảng số nhiều chiều (thường 4096 hay 8192 dimensions với các model lớn). Vector này đại diện cho "ý nghĩa" của token trong một không gian toán học.

Đây là bước mà "ngôn ngữ tự nhiên" chính thức trở thành "toán". Từ đây trở đi, model không còn làm việc với chữ nữa nó chỉ làm việc với số.

Nếu bạn từng dùng text-embedding-ada-002 hay text-embedding-3-small của OpenAI để làm semantic search hoặc RAG, thì bạn đã trực tiếp sử dụng output của bước này rồi đó.

Bước 3: Inference Model "suy nghĩ"

Đây là phần nặng nhất, tốn tài nguyên nhất, và cũng là phần mà GPU hàng chục nghìn đô đang gánh. Các embedding vector đi qua hàng chục (hoặc hàng trăm) transformer layers, mỗi layer bao gồm:

• Self-attention: Model xác định token nào nên "chú ý" tới token nào. Đây là cơ chế cho phép model hiểu ngữ cảnh ví dụ, trong câu "Con mèo ngồi trên bàn, nó rất dễ thương", model cần hiểu "nó" đang refer tới "con mèo".
• Feed-forward network: Xử lý thêm thông tin sau attention.
• Normalization và residual connections: Giữ cho gradient ổn định qua nhiều layer.

Output cuối cùng của bước này là một probability distribution một danh sách xác suất cho mỗi token có thể xuất hiện tiếp theo.

Theo kinh nghiệm của mình khi monitor API calls, bước inference này chiếm khoảng 80-90% tổng latency. Đây cũng là lý do tại sao prompt dài hơn = chậm hơn = đắt hơn. Mỗi token trong prompt đều phải đi qua toàn bộ pipeline attention.

Bước 4: Decoding Chọn token tiếp theo

Sau khi có probability distribution, model cần chọn token tiếp theo. Và đây là lúc parameter temperature mà bạn hay set trong API call phát huy tác dụng.

• Temperature = 0: Luôn chọn token có xác suất cao nhất (greedy decoding). Deterministic, nhưng có thể nhàm chán và lặp lại.
• Temperature = 1: Sample theo đúng phân phối xác suất. Đa dạng hơn nhưng đôi khi "sáng tạo" quá mức.
• Temperature > 1: Phân phối phẳng hơn, random hơn. Thường không nên dùng trừ khi bạn biết mình đang làm gì.

Sau khi chọn được một token, token đó được append vào sequence, và toàn bộ quá trình từ bước 2-4 lặp lại cho đến khi model output token <EOS> (end of sequence) hoặc chạm max_tokens.

Đây chính là lý do response được stream từng chunk mỗi chunk thường là một hoặc vài token vừa được generate. Khi bạn dùng stream: true trong API call, bạn đang nhận token ngay khi nó được decode, thay vì đợi toàn bộ response.

Những điều rút ra cho công việc hàng ngày

Optimize token count là optimize tiền. Mỗi token input và output đều có giá. Hiểu tokenization giúp bạn viết prompt ngắn gọn hơn mà vẫn đủ ý. Dùng tool như tiktoken để đếm token trước khi gửi.

Streaming không chỉ là UX trick. Khi bạn hiểu rằng model generate từng token một, việc dùng streaming response trở nên hiển nhiên user thấy response nhanh hơn vì không phải đợi toàn bộ sequence được decode xong.

Temperature và top_p không phải magic number. Chúng trực tiếp ảnh hưởng đến bước decoding. Cho code generation thì temperature: 0 hoặc 0.1 thường cho kết quả ổn định nhất. Cho creative writing thì 0.7-0.9 sẽ đa dạng hơn.

Context window không miễn phí. Self-attention có complexity O(n²) theo sequence length. Prompt 1000 token không chỉ tốn gấp đôi prompt 500 token nó tốn gấp 4 lần compute cho attention layer. Đây là lý do các provider charge theo token và tại sao bạn nên giữ context gọn nhất có thể.

Tiếp theo là gì?

Cộng đồng đang push mạnh vào việc optimize từng bước trong pipeline này. Các kỹ thuật như speculative decoding (dùng model nhỏ để draft, model lớn để verify) đang giảm latency đáng kể. Quantization (giảm precision của weights) cho phép chạy model lớn trên hardware nhỏ hơn. Và các kiến trúc mới như Mamba hay RWKV đang thách thức sự thống trị của transformer bằng cách giảm complexity của attention xuống O(n).

Hiểu flow cơ bản này không biến bạn thành ML engineer, nhưng nó cho bạn đủ context để đưa ra quyết định kỹ thuật tốt hơn khi build sản phẩm trên LLM. Và trong thời đại mà gần như mọi sản phẩm đều đang tích hợp AI, đó là một lợi thế không nhỏ.