Cùng một model, hai tốc độ: bài toán bếp của AI chạy thật

Hai công ty mua cùng một model, chạy trên cùng dòng GPU, trả tiền theo giờ. Một bên khách chờ câu trả lời đủ uống xong miếng nước. Bên kia khách kịp mở tab khác trước khi thấy chữ đầu tiên. Câu hỏi không phải "model nào nhanh", mà là câu ai bán AI ít muốn nghe: chính xác thứ gì tạo ra chênh lệch đó, và mình kiểm tra được trước khi trả tiền không?

TL;DR

• Model là công thức nấu, GPU là bếp, còn kernel là đôi tay của đầu bếp. Cùng một công thức, bếp khác nhau sẽ ra món với tốc độ khác nhau, và phần lớn chênh lệch đến từ cách bếp xử lý bộ nhớ chứ không phải từ số phép tính.
• Các con số đo được nói cùng một điều: FlashAttention v1 đưa phép attention nhanh hơn 7,6x so với cách triển khai PyTorch trên A100 (Dao và cộng sự, 2022); CUDA Graphs của NVIDIA cho thấy khoảng 70% thời gian của một kernel ngắn có thể là chi phí "đi lại" chứ không phải tính toán (NVIDIA, 2019).
• Khi mua AI cho doanh nghiệp, đừng hỏi "dùng model nào". Hãy hỏi engine chạy model đó được tối ưu ở tầng nào: kernel fusion, quản lý bộ nhớ, lập lịch yêu cầu. Đó là ranh giới giữa hai mức giá vé.

Nếu bạn chưa từng viết một dòng CUDA, vẫn có lý do chính đáng để đọc tiếp. Năm 2026, một doanh nghiệp nhỏ Việt Nam đi mua AI theo hai con đường: thuê API theo token, hoặc tự vận hành một inference engine trên máy chủ riêng. Model nào thì ai cũng mua được, còn cách nấu model đó thì mỗi nơi một kiểu. Bài này đi qua bằng chứng đo được cho thấy tốc độ nằm ở đâu, rồi khép lại bằng bốn câu hỏi bạn có quyền đặt cho bất kỳ nhà cung cấp AI nào trước khi ký.

Hãy nghĩ theo phép ẩn dụ bếp núc, vì nó bám sát cấu trúc kỹ thuật hơn bạn tưởng. Model là công thức nấu: viết ra một lần, ai cũng có bản y hệt, tải về giống nhau từng byte. GPU là căn bếp: có kho nguyên liệu (HBM, bộ nhớ ngoài của GPU) và mặt bếp (SRAM, bộ nhớ nằm ngay trên chip). Còn kernel là đôi tay của đầu bếp — những chương trình làm việc trực tiếp trên mặt bếp đó. Như câu nói của chủ doanh nghiệp đã truyền cảm hứng cho bài này: hầu hết người ta không cắt hành bằng thìa. Đầu bếp tốt có dao đúng việc, và biết sắp đặt sẵn nguyên liệu trước khi bắc nồi.

Hai điều sau đây định hình toàn bộ bài. Thứ nhất, theo benchmark của Anyscale (22/06/2023), LLM inference bị bó buộc bởi memory IO (dữ liệu nạp vào từ bộ nhớ), không phải bởi compute (số phép tính). Thời gian đưa dữ liệu đến lõi tính toán lớn hơn thời gian tính trên chính dữ liệu đó. Thứ hai, GPU có đơn vị nhân ma trận chuyên dụng; paper FlashAttention-2 ghi nhận throughput nhân ma trận cao hơn các phép tính phụ khác tới 16x (Tri Dao, 2023). Ghép hai sự thật này lại: phần "đi lại lấy nguyên liệu" và phần "phép tính phụ" mới là nơi tiền của bạn đang rơi.

Kernel fusion là gì: từ "đập khay" sang nấu liền mạch

Kernel fusion nghĩa là gộp nhiều bước tính toán nhỏ thành một kernel duy nhất, để dữ liệu ở lại trên mặt bếp thay vì chạy về kho sau từng bước. Đối lập của nó là một chuỗi kernel nhỏ rời rạc, mỗi kernel làm xong việc của mình lại ghi kết quả ra bộ nhớ ngoài, rồi kernel kế tiếp nạp lại từ đầu.

Hình dung trong bếp. Bạn cần luộc rau, phi thơm tỏi, xào thịt. Cách rời rạc là sau mỗi công đoạn, đầu bếp bê nồi xuống, mang ra kho, cất, rồi quay lại lấy nguyên liệu cho công đoạn kế. Cách gộp là chuẩn bị hết trên mặt bếp, làm liền tay từ đầu tới cuối. Cùng số động tác cắt gọt, cùng một bếp, hai tốc độ ra món hoàn toàn khác nhau.

Chi phí "bê khay qua lại" không phải ẩn dụ suông. NVIDIA Technical Blog (09/2019) đo trên Tesla V100 với CUDA 10.1: một kernel ngắn chạy mất 2,9 micro giây, nhưng khi tính cả launch (khởi chạy kernel) và đồng bộ hoá sau mỗi lần chạy, thời gian hiệu dụng là 9,6 micro giây mỗi kernel. Nói cách khác, khoảng 70% thời gian là phí phục vụ, không phải nấu ăn. CUDA Graphs (đặt trước menu cả bữa: ghi sẵn toàn bộ thứ tự order để bếp chạy liền không dừng chờ) giảm thời gian đó về 3,4 micro giây.

Bảng này là bản đồ cho phần còn lại của bài: mỗi hàng bếp núc đều có một con số đo được bên cạnh.

FlashAttention: mise en place cho phép tính đắt nhất của Transformer

Trong mọi câu trả lời của model ngôn ngữ, attention (cơ chế chú ý) là phép tính đắt nhất, và nó là nơi kernel fusion chứng minh giá trị đầu tiên. FlashAttention của Tri Dao (Stanford, 2022) làm đúng chuyện của một đầu bếp chuẩn bị mise en place: chia nguyên liệu thành từng phần nhỏ, đưa lên mặt bếp lần lượt, nấu gọn, không chất đống khay N×N trong kho.

Kỹ thuật cụ thể: thay vì ghi ma trận attention N×N lên HBM rồi đọc lại, FlashAttention chia Q/K/V thành block, nạp vào SRAM trên chip, tính softmax tăng dần ngay tại đó, và fuse toàn bộ phép attention thành một kernel duy nhất. Kết quả đo trên A100 với FP16: attention computation nhanh hơn 7,6x so với triển khai PyTorch trên GPT-2 với chuỗi 1K token (Dao và cộng sự, 2022). End-to-end, training GPT-2 cùng chuỗi nhanh hơn 3x so với baseline HuggingFace kết hợp Megatron-LM.

Con số phản ánh rõ nhất bản chất vấn đề không phải là tỷ lệ tăng tốc ở trên. Đó là bộ nhớ: phân tích IO complexity trong paper cho thấy FlashAttention cần ít hơn tới 9x lượt truy cập HBM so với cách chuẩn, và bộ nhớ dành cho attention giảm từ 17.024 MB xuống 836 MB ở chuỗi 4.096 token (bảng trong paper, A100). Lưu ý một chi tiết: FlashAttention phải tính lại một phần (recompute) nên nó làm nhiều phép tính hơn, vậy mà vẫn nhanh hơn. Nếu thêm phép tính mà nhanh hơn, thì điều đã bị giảm chắc chắn không phải là phép tính. Đó chính là lượng truy cập bộ nhớ.

Dòng FlashAttention tiếp tục tiến hoá theo đúng logic mặt bếp. FlashAttention-2 (Tri Dao, 2023) chỉ đạt 25-40% công suất lý thuyết trên A100 cho FA1, nguyên nhân nằm ở cách phân chia việc giữa các thread, nên FA2 sắp xếp lại cách chia việc: khoảng 2x nhanh hơn FA1, đạt 50-73% công suất tối đa, đưa training per-GPU lên 225 TFLOPs/s. Đến FlashAttention-3 (2024, nhóm Colfax, Meta, NVIDIA, Georgia Tech, Princeton), FA2 chỉ đạt 35% công suất trên H100, và FA3 dùng warp-specialization cùng FP8 để đạt 1,5-2,0x nhanh hơn FA2, tương đương 740 TFLOPs/s FP16 ở 75% công suất. Ba thế hệ, một nguyên tắc: tổ chức lại việc trên mặt bếp, không đợi phần cứng mới.

Vòng đời của một yêu cầu: vì sao cùng model mà hai engine khác nhau một bậc

Một câu trả lời AI không sinh ra trong một kernel. Nó đi qua cả một dây chuyền: engine nhận yêu cầu, lập lịch các yêu cầu cùng lúc, quản lý bộ nhớ cho ngữ cảnh, rồi mới tới các kernel tính toán. Mỗi chặng đều có nhân vật bếp núc riêng, và mỗi chặng đều đã được đo trên cùng một model, cùng phần cứng.

Đoạn hay nhất của câu chuyện là Orca (OSDI 2022, nhóm SNU và FriendliAI). Trên GPT-3 175B, chỉ bằng cách đổi cách lập lịch, xử lý theo từng bước sinh token thay vì chờ cả lô xong, Orca đạt throughput cao hơn NVIDIA FasterTransformer tới 36,9x ở cùng mức độ trễ (Yu và cộng sự, 2022). Ba mươi sáu phẩy chín lần. Cùng model, cùng GPU. Toàn bộ chênh lệch nằm ở cách bếp nhận order.

Anyscale đo lại mảnh lập lịch này một cách tách bạch (22/06/2023): continuous batching (bếp nấu liên tục: đĩa xong món nào dọn món đó, nồi mới vào ngay) đóng góp 8x throughput so với batching kiểu cũ. Model implementation tối ưu đóng góp thêm 4x. Cộng dồn trên workload mô phỏng production là 23x. Không có phép màu nào trong dãy số đó, chỉ là từng tầng tối ưu cộng lại.

Tầng bộ nhớ thì sao? KV cache (bộ nhớ đệm ngữ cảnh, như gia vị pha sẵn dùng lại cho mỗi bàn) là nơi tiền điện và RAM của bạn chảy đi. Paper PagedAttention (SOSP 2023, UC Berkeley) kiểm kê các hệ serving trước đó: chỉ 20,4-38,2% bộ nhớ KV cache thực sự chứa token của khách, phần còn lại lãng phí vì cấp phát khối lớn trước. PagedAttention chia bộ nhớ như tủ lạnh chia ô cố định, cấp phát theo nhu cầu, đưa lãng phí về dưới 4%, và throughput serving cao hơn 2-4x so với FasterTransformer và Orca (Kwon và cộng sự, 2023). Blog ra mắt của vLLM (20/06/2023) đo trên LLaMA-13B/A100: 24x so với HuggingFace Transformers và 3,5x so với TGI.

Bạn có thấy cấu trúc chung chưa? Mỗi tầng, từ lập lịch qua bộ nhớ tới kernel, là một lần ai đó tổ chức lại bếp và tăng tốc đo được một bậc. Một engine hiện đại như vLLM hoặc TensorRT-LLM xếp chồng các tầng này: kernel fused, KV cache phân trang, continuous batching, CUDA Graphs, quantization FP8/INT4 (TensorRT-LLM docs xác nhận đầy đủ các thành phần này; docs không công bố số benchmark, nên chúng tôi không trích số cho nó).

Insight: bộ nhớ có hóa đơn, và hóa đơn có số dư

Phần nhiều bài viết dừng ở "fuse là nhanh hơn". Nhưng bằng chứng thú vị nhất trong đống research lần này lại đến từ chiều ngược: những quyết định về bộ nhớ có giá cả, và giá đó đo được bằng con số cụ thể.

Paper vAttention (ASPLOS 2025, Microsoft Research) đo kernel paged của vLLM chậm hơn tới 2,8x so với kernel FlashAttention-2, và kernel paged làm prefill của FA2 chậm hơn 37%, FlashInfer chậm hơn 42% so với kernel non-paged cùng thư viện. vAttention giữ bộ nhớ ảo liền mạch qua CUDA VMM API và đạt throughput cao hơn tới 1,23x so với cách phân trang. Đây là lớp chi tiết mà một CTO SMB không cần biết cách cài đặt, nhưng cần biết là nó tồn tại: vì hai engine cùng quảng cáo "PagedAttention" có thể chênh nhau một cách đo được, phụ thuộc cách họ cài nó.

Chiều ngược thứ hai là quantization (nén model xuống ít bit hơn, như nguyên liệu cô đặc). SpQR (Dettmers và cộng sự, 2023) nén 3-4 bit với dequant ngay trong kernel, tức "pha loãng nguyên liệu ngay tại mặt bếp", chạy model 33B trên một GPU consumer 24 GB, không suy giảm chất lượng, nhanh hơn 15% so với baseline 16-bit, nén bộ nhớ hơn 4x. AQLM (2024) với kernel GPU riêng cho quant 2 bit đạt tốc độ ngang hoặc vượt FP16 trên các model Llama 2. Điều đáng chú ý: nén làm giảm chữ số, nhưng kernel phải biết "pha loãng đúng lúc" để món không nhạt. Kỹ thuật này nằm trong kernel, không phải trong model.

Điều mà phần lớn nội dung AI cho doanh nghiệp bỏ qua: những quyết định này không nằm trong bảng giá API. Bảng giá chỉ nói giá mỗi token. Nó không nói bạn đang trả cho bao nhiêu lượt đi kho vô ích, bao nhiêu khay bị đập qua lại, bao nhiêu ô tủ lạnh trống. Chỉ khi bạn tự vận hành, hoặc khi bạn biết phải hỏi đúng câu, ranh giới giá đó mới hiện ra.

Takeaway: bốn câu hỏi đặt cho nhà cung cấp AI trước khi ký

Về mặt kỹ thuật, các con số trong bài đến từ môi trường phòng thí nghiệm: A100, H100, GPT-3 175B, benchmark tự báo cáo của từng nhóm. Máy chủ của bạn không phải A100, workload của bạn không phải ShareGPT. Nhưng cấu trúc câu hỏi thì dùng được ở mọi quy mô, vì nó hỏi về cấu trúc bếp chứ không hỏi về thương hiệu.

Khi một vendor đến chào AI chạy thật (chatbot hỗ trợ khách, agent xử lý chứng từ, trợ lý nội bộ), hãy đặt bốn câu hỏi sau:

1. Engine nào đang chạy model, và tầng nào đã tối ưu? Kernel fusion, quản lý KV cache, continuous batching, CUDA Graphs. Một engine hiện đại nên trả lời được cả bốn. Nếu câu trả lời là "chúng tôi dùng model mới nhất", đó là câu trả lời về công thức, không phải về bếp.
2. Con số throughput đo trên phần cứng nào, model nào, đo bởi ai? Mỗi con số trong bài này đều có ngữ cảnh đo rõ ràng. Một con số "nhanh hơn gấp X" không có ngữ cảnh (hardware, model, đơn vị, ai đo) không phải là bằng chứng, đó là quảng cáo. Các benchmark tự báo cáo của vendor là điểm khởi đầu, không phải điểm kết thúc.
3. Tính giá theo token hay theo giờ GPU, và đo bằng chỉ số nào? Nếu engine lãng phí 60-80% bộ nhớ KV cache như các hệ cũ trước vLLM (blog vLLM, 2023), thì dù giá mỗi token có rẻ, bạn đang trả cho token không tồn tại. Yêu cầu số liệu bộ nhớ, không chỉ số liệu tốc độ.
4. Có thoát được khóa nhà cung cấp không? Engine mở như vLLM, SGLang, llama.cpp chạy được trên phần cứng bạn sở hữu. Nếu một ngày hợp đồng tăng giá hoặc dịch vụ chậm đi, khả năng đem workload về máy mình là lá chắn đàm phán thật.

Đây là tệp khách của 5ac: doanh nghiệp Việt muốn AI chạy thật, không chạy demo, với chi phí đo được. Nếu bạn đang cân nhắc tự vận hành, hai bài của chúng tôi đi thẳng vào bài toán này: so sánh cách triển khai LLM local cho bức tranh chọn phương án, và kinh nghiệm chạy model trên DGX Spark cho phần hạ tầng thật. Còn nếu bạn giữ hướng đi qua API, bài kiểm soát chi phí token khi orchestration giúp bạn biết mình đang trả tiền cho cái gì.

Câu hỏi thường gặp về GPU kernel fusion

Nguồn tham khảo

• FlashAttention (Dao và cộng sự, 2022) — cơ chế tiling + fuse một kernel; 7,6x attention trên GPT-2 seq 1K; 3x training GPT-2; ít hơn tới 9x lượt truy cập HBM; bộ nhớ attention 17.024 MB → 836 MB ở seq 4.096.
• FlashAttention-2 (Tri Dao, 2023) — FA1 đạt 25-40% max FLOPs/s; FA2 khoảng 2x nhanh hơn, 50-73%; 225 TFLOPs/s per A100; matmul nhanh hơn non-matmul tới 16x.
• FlashAttention-3 (Shah và cộng sự, 2024) — FA2 35% utilization trên H100; FA3 1,5-2,0x nhanh hơn, 740 TFLOPs/s FP16 (75% util); đo trên H100 SXM5, clock 1830 MHz, trung bình 100 lần.
• PagedAttention / vLLM (Kwon và cộng sự, SOSP 2023) — hệ cũ dùng 20,4-38,2% KV cache cho token thật; PagedAttention lãng phí dưới 4%; throughput 2-4x so với FasterTransformer và Orca.
• Orca (Yu và cộng sự, OSDI 2022) — iteration-level scheduling; 36,9x throughput so với FasterTransformer trên GPT-3 175B, cùng mức latency.
• Continuous batching (Anyscale, 22/06/2023) — 23x tổng trên workload mô phỏng; 8x nhờ continuous batching; 4x nhờ model implementation; LLM inference bị bó buộc bởi memory IO.
• CUDA Graphs (NVIDIA Technical Blog, 09/2019) — kernel 2,9 µs so với 9,6 µs launch + sync; CUDA Graphs giảm về 3,4 µs; đo trên Tesla V100, CUDA 10.1.
• vLLM launch blog (UC Berkeley, 20/06/2023) — 24x so với HuggingFace Transformers, 3,5x so với TGI; KV cache LLaMA-13B tới 1,7 GB; lãng phí 60-80%; chia sẻ KV giảm 55% bộ nhớ → 2,2x throughput.
• vAttention (ASPLOS 2025, Microsoft Research) — kernel paged của vLLM chậm hơn tới 2,8x so với FA2; prefill FA2 chậm hơn 37%, FlashInfer 42%; vAttention cao hơn tới 1,23x.
• SpQR (Dettmers và cộng sự, 2023) — quant 3-4 bit + dequant-in-kernel; 33B trên 1 GPU consumer 24 GB; nhanh hơn 15% so với FP16; nén hơn 4x.
• AQLM (Egiazarian và cộng sự, 2024) — quant 2 bit + custom GPU kernel; tốc độ ngang hoặc vượt FP16 trên Llama 2 7/13/70B.
• SGLang / RadixAttention (Zheng và cộng sự, 2023) — tái dùng KV cache qua radix tree; throughput cao hơn tới 6,4x so với hệ tiên tiến khi đó.
• Liger Kernel (LinkedIn, 2024) — fuse RMSNorm/RoPE/loss: +20% throughput training, giảm 60% GPU memory; đo trên LLaMA 3-8B, 8x A100, FSDP1.
• TensorRT-LLM docs (NVIDIA) — xác nhận Paged Attention, in-flight batching, CUDA graph, quant FP8/INT4; tài liệu không công bố số benchmark nên bài này không trích số cho TensorRT-LLM.
• llama.cpp build docs (ggml-org) — nhiều backend kernel từ một codebase; BLAS chỉ tăng prompt processing ở batch lớn, không đổi tốc độ generation.

Ghi chú vị thế: các con số hiệu năng trong bài là benchmark do từng nhóm nghiên cứu tự báo cáo trên phần cứng cụ thể (A100, H100, V100, GPT-3 175B, LLaMA-13B), chưa được kiểm định độc lập trên hạ tầng của bạn. Bài giữ nguyên ngữ cảnh đo ở mọi vị trí số xuất hiện.

Về tác giả: James Marcus, Agent Content Lead tại 5ac.vn, simulating the thinking style and expertise of James Marcus (content strategy researcher, data-driven storytelling). Viết cho những doanh nghiệp Việt muốn AI chạy thật, không chạy demo.

Bài viết liên quan

• So sánh cách triển khai LLM local
• Kinh nghiệm chạy model trên DGX Spark
• Kiểm soát chi phí token khi orchestration