Khi bạn nhập một đoạn văn vào ChatGPT, Claude hoặc DeepSeek, mô hình bắt đầu trả lời từng chữ chỉ trong vài trăm mili giây—quá trình đó nghe có vẻ đơn giản, nhưng thực tế là một trong những mảng kỹ thuật tinh vi nhất của điện toán hiện đại. Bài viết này tổng hợp phần phân tích toàn bộ quy trình suy luận hoàn chỉnh của kỹ sư AI Akshay Pachaar: từ tokenization, embedding, attention, đến hai giai đoạn prefill/decode, KV cache, lượng tử hóa, và vì sao DeepSeek V4 lại cắt giảm dung lượng cache xuống chỉ còn 10% so với ban đầu.
Mô hình tâm trí cốt lõi: LLM chỉ là “đoán token tiếp theo”, rồi lặp lại liên tục
Về bản chất, mô hình ngôn ngữ lớn chỉ làm một việc: dự đoán token tiếp theo. Nó nhận vào chuỗi token bạn đưa, tính phân phối xác suất của token tiếp theo, lấy mẫu để tạo ra một token, nối token đó vào cuối chuỗi đầu vào, rồi dự đoán token tiếp theo—không ngừng lặp cho đến khi mô hình xuất hiện ký hiệu kết thúc hoặc đạt giới hạn.
Vấn đề then chốt của toàn bộ quy trình suy luận không phải “nó dự đoán như thế nào”, mà là “vì sao token thứ hai lại nhanh hơn token thứ nhất rất nhiều?”. Câu trả lời này dẫn tới hai khái niệm quan trọng nhất trong dịch vụ LLM hiện đại: prefill và decode hai giai đoạn, cùng với KV cache.
Step 1：Tokenization biến chữ thành con số
Mạng nơ-ron không “đọc” chữ—nó chỉ đọc vector. Vì vậy, prompt của bạn trước hết sẽ trải qua tokenization, được cắt thành từng mảnh “token”, và mỗi token tương ứng với một ID số nguyên. Hầu hết LLM hiện đại dùng BPE (Byte Pair Encoding, mã hóa theo cặp byte): bắt đầu từ các ký tự gốc, lần lượt gộp các cặp ký tự xuất hiện thường xuyên nhất, cuối cùng thu được bảng từ vựng khoảng 50 nghìn token.
Bước này ảnh hưởng lớn hơn nhiều so với tưởng tượng của đa số người. Những ngôn ngữ có tỷ trọng thấp trong dữ liệu huấn luyện của tokenizer sẽ bị cắt thành nhiều token hơn, chi phí suy luận tăng và tốc độ chậm đi. Tiếng Trung và chữ Hán phồn thể trong nhiều tokenizer thiên về tiếng Anh, mỗi ký tự thường bị tách thành 2 đến 3 token—đây là một trong những nguyên nhân căn bản khiến chi phí suy luận cho người dùng Trung Quốc thường cao.
Step 2：Embedding biến ID thành vector, rồi nhúng thông tin vị trí
Mỗi ID token số nguyên sẽ tra cứu một bảng “embedding” khổng lồ. Nếu từ vựng mô hình là 50K, chiều ẩn là 4096, thì kích thước bảng là [50000, 4096]. Mỗi token lấy một hàng vector, chính là biểu diễn 4096 chiều của nó.
Những vector này không phải ngẫu nhiên—khi huấn luyện, mô hình sẽ đẩy các token có nghĩa gần nhau vào những vùng không gian tương tự: king và queen nằm gần nhau theo một hướng, python (ngôn ngữ) và javascript gần nhau theo hướng khác, python và snake (rắn) lại gần nhau theo hướng thứ ba.
Thông tin vị trí cũng được đưa vào ở bước này, vì cơ chế attention bản thân nó không biết token nào đứng trước token nào đứng sau. Các mô hình chủ đạo hiện nay thường dùng RoPE (Rotary Position Embedding, mã hóa vị trí xoay): xoay vector theo vị trí token, nhúng trật tự vào chính vector.
Step 3：Self-Attention là lõi của Transformer
Chuỗi vector tiếp theo đi vào 32 lớp (hoặc nhiều hơn) transformer; mỗi lớp làm hai việc: dùng self-attention để trộn thông tin giữa các token, rồi dùng feed-forward để trộn thông tin trong nội bộ từng token.
Cách self-attention hoạt động như sau: mỗi token thông qua ba ma trận trọng số đã học được Wq, Wk, Wv để tạo ra query (truy vấn), key (khóa) và value (giá trị). Với query của từng token, nó tính tích vô hướng với key của tất cả các token khác, tạo ra trọng số “token này nên kéo bao nhiêu thông tin từ các token khác”, rồi dùng trọng số đó để trộn có gia quyền các value.
Đó là “phép thuật” của attention: mỗi token tự quyết định nó cần nhìn vào những vị trí nào trong ngữ cảnh, rồi kéo thông tin hữu ích vào vector của mình. Khi xếp chồng 32 lớp, mô hình có thể theo dõi các tham chiếu xuyên qua hơn hàng nghìn token. Feed-forward ngay sau attention thì gánh phần lớn “tri thức” của mô hình; attention chịu trách nhiệm vận chuyển thông tin, còn feed-forward xử lý thông tin.
Prefill và Decode：cùng một GPU, hai nút thắt hoàn toàn khác nhau
Đây là phần ranh giới quan trọng nhất của bài viết. Sinh ra một phản hồi 200 chữ thực chất là hai tác vụ có tính chất hoàn toàn khác nhau, chạy trên cùng một GPU.
Giai đoạn Prefill—khi bạn gửi prompt, mô hình trước tiên phải cho toàn bộ các token đầu vào đi qua một lượt, rồi mới sinh được token đầu tiên. Bước này có thể “song song hóa” cho mọi token đầu vào: Q, K, V của từng token được tính đồng thời, và attention là phép nhân ma trận lớn với ma trận lớn. GPU sinh ra cho loại tính toán này: các đơn vị tính (Tensor Cores) hoạt động hết công suất, và nút thắt nằm ở “năng lực tính toán”. Chỉ số độ trễ của giai đoạn này là TTFT (Time to First Token, độ trễ đến token đầu tiên).
Giai đoạn Decode—sau khi token đầu tiên ra đời, mô hình chuyển sang chế độ khác. Khi sinh token thứ 51, nó chỉ cần tính Q, K, V của token mới này; 50 token trước đó đã có sẵn K, V nên không cần tính lại. Vấn đề là: lượng tính cho mỗi token nhỏ, nhưng GPU vẫn phải nạp trọng số toàn mô hình và toàn bộ lịch sử KV từ bộ nhớ GPU, làm một phép tính nhỏ rồi trả kết quả lại. Nút thắt vì thế chuyển từ “tính toán” sang “băng thông bộ nhớ”. Chỉ số độ trễ của giai đoạn này là ITL (Inter-Token Latency, độ trễ giữa các token), nó quyết định cảm giác “gõ chữ” của mô hình nhanh hay chậm.
Vì vậy, prefill là compute-bound (bị giới hạn bởi tính toán), decode là memory-bound (bị giới hạn bởi bộ nhớ)—cùng một mô hình, cùng một phần cứng, nhưng đặc tính hiệu năng hoàn toàn khác nhau.
KV Cache：chìa khóa tối ưu để suy luận LLM khả thi
Ở giai đoạn Decode, việc “không tính lại K, V của token quá khứ” dựa vào KV cache. Mỗi lớp transformer duy trì hai tensor: lưu toàn bộ K và V của các token lịch sử; token mới được tính ra K, V rồi append vào, và khi attention diễn ra thì trực tiếp đọc toàn bộ lịch sử.
Nếu không có KV cache, để sinh câu trả lời 1,000 token thì mỗi bước đều phải tính lại toàn bộ chuỗi đang lớn dần, làm độ phức tạp bùng nổ theo kiểu bậc hai. Có KV cache, sinh dài có thể nhanh hơn từ 5 lần trở lên. Nhưng cái giá là: cache nằm trong bộ nhớ GPU; cứ mỗi token sinh thêm thì cache lại tăng thêm một phần. Với mô hình cỡ 13B, mỗi token chiếm khoảng 1MB; ngữ cảnh 4K sẽ tiêu tốn 4GB bộ nhớ, chỉ để lưu cache đó.
Đây là nguyên nhân thật sự của “ngữ cảnh dài thì chậm và đắt”—không phải mô hình “không theo kịp”, mà là cache làm đầy bộ nhớ. Khi bộ nhớ bị ăn hết, số người dùng có thể phục vụ đồng thời trên một GPU sẽ giảm mạnh. Các kỹ thuật tối ưu phổ biến gồm: lượng tử hóa cache thành INT8 hoặc INT4, dùng sliding window để loại bỏ các token quá cũ, dùng grouped-query attention (GQA) để nhiều attention head dùng chung K, V, hoặc như PagedAttention của vLLM dùng cơ chế chia trang cache (tương tự như quản lý bộ nhớ trong hệ điều hành).
Cuộc cách mạng cache của DeepSeek V4：giảm xuống 10% so với ban đầu với ngữ cảnh 1M
Lượng tử hóa và phân trang biến KV cache thành “chi phí cố định” để tối ưu. Dòng V4 mà DeepSeek dự kiến cuối năm 2025 đi theo hướng thậm chí quyết liệt hơn: thiết kế lại attention từ đầu, khiến cache ngay từ đầu đã nhỏ.
V4 áp dụng cơ chế lai, kết hợp hai biến thể attention thưa và dày, và cả hai đều vận hành trên luồng KV đã được nén mạnh. Với ngữ cảnh hàng triệu token, V4-Pro báo cáo rằng dung lượng KV cache chỉ bằng khoảng 10% so với thế hệ trước, và chi phí tính toán trên mỗi token chỉ khoảng 27%. Ý nghĩa không chỉ là “DeepSeek lại rẻ hơn”, mà là KV cache đã trở thành nút thắt cần tối ưu trong toàn bộ lĩnh vực LLM—khi bản thân cơ chế attention được thiết kế lại để thu nhỏ cache, điều đó cho thấy “điều kiện giới hạn” của cả cộng đồng kỹ thuật đã bị dời hẳn.
Thông tin thực dụng hơn cho độc giả Đài Loan là: DeepSeek V4-Flash đã có trên Ollama Cloud và máy chủ tại Mỹ (xem bài báo abmedia 4/24), Claude Code, OpenClaw đều có thể kết nối chỉ bằng một cú nhấp để kiểm chứng lợi thế của attention thế hệ mới trong tình huống ngữ cảnh dài.
Quantization：đổi độ chính xác lấy tốc độ và bộ nhớ
Huấn luyện cần độ chính xác cao, còn suy luận thì không. Phần lớn triển khai chính thức chuyển FP16 hoặc BF16 thay cho FP32, ngay lập tức tăng gấp đôi bộ nhớ và throughput. Cách quyết liệt hơn nữa là lượng tử hóa trọng số thành INT8, thậm chí INT4.
Về trực giác bằng con số：mô hình 7B tham số ở FP32 cần 28GB, FP16 cần 14GB, INT8 cần 7GB và INT4 chỉ cần 3,5GB. Vì vậy card đồ họa trên laptop phổ thông cũng có thể chạy được mô hình 7B. Các phương pháp như GPTQ và AWQ sẽ chọn hệ số co giãn cho từng kênh, nhằm giảm thiểu tổn thất chất lượng do nén có mất mát—INT4 được thiết kế tốt, trong đa số benchmark chỉ kém bản gốc trong phạm vi tối đa khoảng 1 điểm phần trăm.
Gom tất cả bước lại: hành trình trọn vẹn của một prompt
Ghép toàn bộ các khâu trên, lộ trình đầy đủ của một lần suy luận là：（1）Tokenize—chữ biến thành ID số nguyên。（2）Embed—ID biến thành vector, nhúng thông tin vị trí。（3）Prefill—mọi lớp tính toán song song cho toàn bộ token đầu vào, thuộc kiểu compute-bound, KV cache được tạo, và token đầu ra đầu tiên sinh ra。（4）Decode loop—mỗi lần chỉ chiếu (project) token mới bằng Q, thực hiện attention với K, V trong cache, chạy feed-forward, lấy mẫu để xuất token, ghi K, V mới trở lại cache, thuộc kiểu memory-bound。（5）Detokenize—đổi token ID trở lại ký tự, và stream đầu ra lên màn hình.
Các framework dịch vụ như vLLM, TensorRT-LLM, Text Generation Inference đặt thêm ở ngoài vòng lặp này: continuous batching (token của người dùng khác nhau có thể xen kẽ trong cùng một bước GPU), speculative decoding (mô hình nhỏ tạo bản nháp trước, mô hình lớn xác nhận), và quản lý bộ nhớ tinh xảo—đó là cách phục vụ hàng chục người dùng trên một GPU.
Gợi ý thực hành cho developer：bạn nên quan tâm TTFT hay ITL？
Khi nắm rõ toàn cảnh quy trình suy luận, vài phán đoán thực tế sẽ tự hiện ra：
Prompt dài sẽ làm TTFT tăng, output dài sẽ làm ITL tăng—chúng gây áp lực từ các nguồn khác nhau, nên đừng dồn tài nguyên tối ưu vào sai chỉ số. Context không phải miễn phí; tăng gấp đôi ngữ cảnh không chỉ tăng gấp đôi tính toán, mà còn làm giảm khả năng chứa batch khi KV cache bị nén. Lượng tử hóa là nút điều chỉnh “đòn bẩy” lớn nhất hiện nay: chuyển FP16 sang INT8 thường cắt giảm được khoảng một nửa độ trễ với mức suy giảm chất lượng cực nhỏ. Utilization của GPU (tỷ lệ sử dụng) cũng thường gây hiểu nhầm—prefill giai đoạn đầu có thể kéo GPU lên đầy, còn decode giai đoạn sau có thể chỉ dùng khoảng 30%; giải pháp không phải là thêm năng lực tính toán, mà là bộ nhớ nhanh hơn hoặc cache nhỏ hơn.
Transformer thu hút nhiều ánh nhìn vì kiến trúc, nhưng hiệu năng suy luận thật sự nằm trong những “chi tiết nhàm chán”: cấu hình bộ nhớ, quản lý cache, và độ rộng bit. Khi ai đó nói “mô hình này chậm”, câu hỏi tiếp theo không nên là “đổi GPU”, mà là “chậm ở phần ‘bắt đầu’ hay chậm ở phần ‘streaming’?”. Câu trả lời sẽ quyết định toàn bộ lộ trình tối ưu.
Bài viết hướng dẫn đầy đủ về suy luận LLM：cuộc cách mạng cache của KV cache và DeepSeek V4 lần đầu tiên xuất hiện tại 鏈新聞 ABMedia.
