VRAM và HBM quan trọng thế nào trong hạ tầng vận hành AI: từ inference đến fine-tuning

Khi thảo luận về hạ tầng cho AI, con số được nhắc đến đầu tiên thường là FLOPS — "GPU này mạnh hơn GPU kia bao nhiêu lần". Nhưng trong vận hành thực tế, đặc biệt với inference — phần chiếm phần lớn chi phí hạ tầng AI sau khi đã có model — hai yếu tố khác thường quyết định trước: VRAM (bộ nhớ GPU có thể chứa được gì) và băng thông bộ nhớ, mà HBM (High Bandwidth Memory) là công nghệ chủ đạo trên GPU datacenter. Một GPU với FLOPS cao nhưng VRAM không đủ để nạp model, hoặc băng thông không đủ để "nuôi" compute unit, sẽ không đạt được hiệu năng lý thuyết — đôi khi chậm hơn một GPU "yếu hơn" trên giấy nhưng có cấu hình bộ nhớ phù hợp hơn với bài toán. Bài viết này phân tích vì sao VRAM và HBM quan trọng, và cách chúng tôi tính toán sizing GPU khi thiết kế hạ tầng AI cho một Pilot Build.

VRAM — nút thắt đầu tiên của inference

Trước khi GPU tính toán được bất cứ điều gì, toàn bộ (hoặc phần lớn) trọng số của model phải được nạp vào VRAM. Đây là điều kiện cứng — không phải vấn đề tối ưu hóa: nếu model không vừa VRAM, nó không chạy được trên GPU đó, chấm hết.

Một model 7B tham số ở độ chính xác FP16 cần khoảng 14GB chỉ để chứa trọng số — chưa tính bất cứ thứ gì khác. Quantize về INT4/INT8 (như đã đề cập trong bài viết về Qwen3-VL) giảm con số này xuống còn khoảng 4-5GB, đủ để chạy trên một GPU phổ thông 16-24GB VRAM
KV cache — bộ nhớ tạm lưu trạng thái attention cho mỗi token đã sinh — tăng theo cả độ dài context và số lượng request xử lý đồng thời (batch size). Với context dài (hàng chục nghìn token, phổ biến khi dùng RAG với nhiều tài liệu), KV cache có thể chiếm VRAM nhiều hơn chính trọng số model
Nếu tổng VRAM cần (trọng số + KV cache + overhead framework) vượt VRAM có sẵn, hệ thống phải offload một phần sang RAM hệ thống (CPU) — và vì băng thông giữa CPU và GPU thấp hơn băng thông VRAM nội bộ rất nhiều, độ trễ có thể tăng 10-50 lần, biến một response "vài trăm ms" thành vài giây

HBM là gì, và khác gì GDDR

VRAM không phải một loại bộ nhớ duy nhất — công nghệ chế tạo quyết định băng thông, và băng thông quyết định việc compute unit của GPU có được "nuôi đủ dữ liệu" để hoạt động ở công suất tối đa hay không.

HBM (High Bandwidth Memory) xếp nhiều die nhớ thành một ngăn xếp (stack), kết nối với GPU die qua một interposer silicon với hàng nghìn đường tín hiệu song song — cho băng thông rất cao (HBM3 đạt khoảng 3+ TB/s mỗi GPU) nhưng đắt và phức tạp hơn để sản xuất
GDDR (dùng trên GPU consumer/gaming) đạt băng thông thấp hơn (GDDR6 khoảng 1 TB/s) nhưng rẻ hơn và dễ tích hợp — đủ cho phần lớn workload đồ họa, nhưng thường là điểm nghẽn với các mô hình AI lớn
Nhiều workload AI — đặc biệt inference với batch size nhỏ — là memory-bound, không phải compute-bound: GPU "chờ" dữ liệu từ bộ nhớ nhiều hơn là chờ phép tính hoàn thành. Đây là lý do GPU datacenter (H100, A100, MI300 — dùng HBM) có giá chênh lệch rất lớn so với GPU consumer (RTX — dùng GDDR), dù FLOPS lý thuyết không chênh lệch tương ứng

Hệ quả thực tế: hai GPU có FLOPS gần bằng nhau nhưng cấu hình bộ nhớ khác nhau (HBM và GDDR, hoặc dung lượng VRAM khác nhau) có thể cho throughput inference chênh lệch vài lần với cùng một model — đo bằng FLOPS không phản ánh đúng hiệu năng thực tế cho AI.

Sizing GPU cho production — câu hỏi cần trả lời trước

Model nào, ở độ chính xác/quantization nào? — quyết định VRAM cố định cho trọng số (ví dụ 7B INT4 ≈ 5GB, 13B INT4 ≈ 8GB, 70B INT4 ≈ 40GB)
Context length tối đa và số request đồng thời? — quyết định VRAM cho KV cache, thường tăng tuyến tính theo cả hai; với context 32K token và batch 8, KV cache có thể vượt 10GB tùy kích thước model
Throughput cần bao nhiêu request/giây, hay độ trễ tối đa cho một request là bao nhiêu? — quyết định có cần batch nhiều request lại (tăng throughput, tăng VRAM cần) hay phục vụ từng request riêng (giảm độ trễ, ít VRAM hơn nhưng GPU thường không được khai thác hết)
Có cần fine-tune trên cùng hạ tầng? — fine-tune (đặc biệt full fine-tune, không phải LoRA) cần VRAM cho gradient và optimizer state, thường gấp 3-4 lần VRAM cần cho inference cùng model

Khi nào cần multi-GPU

Khi model không vừa VRAM của một GPU — phổ biến với model 30B+ tham số hoặc kiến trúc MoE (mixture-of-experts) như đã nhắc trong bài viết về Qwen3-VL — cần chia model ra nhiều GPU:

Tensor parallelism — chia mỗi layer của model thành nhiều phần, mỗi GPU tính một phần, kết quả được gộp lại — yêu cầu băng thông giao tiếp giữa GPU rất cao (NVLink, không phải PCIe) vì các GPU phải đồng bộ liên tục trong mỗi layer
Pipeline parallelism — chia model theo chiều layer, mỗi GPU giữ một nhóm layer liên tiếp — yêu cầu băng thông giữa GPU thấp hơn nhưng có thể tạo "bubble" (GPU chờ nhau) nếu không cân bằng tải tốt
Trong thực tế, nhiều framework serving (vLLM, TensorRT-LLM) hỗ trợ kết hợp cả hai — nhưng thêm GPU không tuyến tính hóa hiệu năng nếu băng thông kết nối giữa GPU (hoặc giữa node) trở thành điểm nghẽn mới

Kết luận

Sizing GPU cho một hệ thống AI production không nên bắt đầu từ câu hỏi "GPU nào mạnh nhất trong tầm giá", mà từ: model và quantization nào, context length và concurrency thực tế là bao nhiêu, và workload là memory-bound hay compute-bound. Right-sizing VRAM và băng thông tránh cả hai cực — thiếu (out-of-memory, fallback sang CPU làm chậm hệ thống) và dư (chi phí GPU lãng phí cho dung lượng/băng thông không bao giờ dùng tới). Đây là một phần của việc thiết kế hạ tầng mà chúng tôi thực hiện cho mọi Pilot Build trong lớp AI & ML — chọn GPU dựa trên bài toán cụ thể, không phải dựa trên benchmark chung.