Yêu cầu VRAM cho LLM: Bảng tổng hợp 2026 (Mọi mô hình, Mọi mức lượng tử hóa)

Yêu cầu VRAM cho LLM: Bảng tổng hợp 2026 (Mọi mô hình, Mọi mức lượng tử hóa)

Đây là con số khiến nhiều người bất ngờ: DeepSeek-V3.2 có 671 tỷ tham số, nhưng chỉ có 37 tỷ tham số được kích hoạt cho mỗi token. Vậy nó thực sự cần bao nhiêu VRAM? Câu trả lời là toàn bộ 671 tỷ, tương đương khoảng 382 GB ở mức lượng tử hóa Q4. Yêu cầu VRAM của LLM hiếm khi tuân theo trực giác, và khoảng cách giữa "tham số đang hoạt động" với "những gì bạn phải tải vào bộ nhớ" chính là nơi ngân sách phần cứng thường bị thâm hụt. Hướng dẫn này cung cấp cho bạn bảng tổng hợp đầy đủ (mọi mô hình nguồn mở lớn, mọi mức lượng tử hóa, dung lượng GB cụ thể và loại GPU phù hợp) cùng công thức giúp bạn tự tính toán dung lượng cho bất kỳ mô hình nào chỉ trong khoảng mười giây.

Những điểm chính

• VRAM cho trọng số ≈ số tham số × byte mỗi tham số: FP16 = 2.0, Q8 = 1.0, Q5_K_M ≈ 0.68, Q4_K_M ≈ 0.57. Hãy cộng thêm bộ đệm KV (KV cache) và khoảng 15-20% dự phòng.
• Các mô hình Hỗn hợp Chuyên gia (Mixture-of-Experts - MoE) như DeepSeek, GLM-5.2, Qwen3-235B phải tải mọi chuyên gia vào VRAM. "Tham số đang hoạt động" giúp tăng tốc độ, không tiết kiệm bộ nhớ.
• Bộ đệm KV là chi phí ẩn. Llama 3.3 70B cần khoảng 2.6 GB bộ đệm ở ngữ cảnh 8K và khoảng 41 GB ở ngữ cảnh 128K, bên cạnh dung lượng cho trọng số.
• Q4_K_M là lựa chọn mặc định hợp lý: chất lượng gần như đầy đủ với chỉ khoảng một phần tư dung lượng so với FP16.
• Mô hình 12B như Gemma 4 vừa vặn với card 8 GB ở mức Q4. Mô hình dày đặc 70B cần khoảng 40 GB. Các mô hình MoE tiên phong 671B cần một máy chủ nhỏ.

Yêu cầu VRAM cho LLM theo từng mô hình: Bảng tổng hợp

Câu trả lời ngắn gọn: ở mức Q4_K_M, các mô hình nhỏ (dưới 14B) phù hợp với card consumer 8-12 GB, các mô hình tầm trung (24-32B) cần 16-24 GB, mô hình dày đặc 70B cần khoảng 40 GB, và các mô hình MoE tiên phong nhảy vọt lên hàng trăm gigabyte vì mọi chuyên gia đều phải được lưu trữ trong bộ nhớ. Dưới đây là bức tranh toàn cảnh trong một bảng duy nhất. Tất cả các con số đều là dung lượng bộ nhớ cho riêng trọng số, được tính toán dựa trên số lượng tham số của từng mô hình và đối chiếu với các thẻ mô hình chính thức từ Meta AI, Qwen và Hugging Face.

Có hai điều cần rút ra từ bảng này. Thứ nhất, lượng tử hóa là đòn bẩy lớn nhất bạn có: chuyển từ FP16 xuống Q4 giảm dung lượng đi khoảng 4 lần với mức suy giảm chất lượng hầu như không nhận thấy. Thứ hai, các dòng MoE trông rất khắc nghiệt vì đúng là như vậy. Qwen3-30B-A3B chỉ kích hoạt 3B tham số mỗi token, nên nó chạy nhanh như một mô hình nhỏ, nhưng bạn vẫn cần giữ toàn bộ 30B trong bộ nhớ để sẵn sàng truy cập mọi chuyên gia. Muốn biết chi tiết đằng sau những con số này? Bài phân tích sâu Gemma 4 12B và bài tổng hợp các LLM nguồn mở tốt nhất năm 2026 của chúng tôi đã đề cập đến các điểm chuẩn và giấy phép.

Công thức tính VRAM: Tự tính toán cho bất kỳ mô hình nào

Để xác định dung lượng cho bất kỳ mô hình nào, hãy nhân số lượng tham số với số byte mỗi tham số tương ứng với mức lượng tử hóa của bạn, sau đó cộng thêm một chút cho bộ đệm KV và chi phí vận hành. Chỉ có vậy. Trọng số là thành phần chiếm ưu thế, và phép tính đủ đơn giản để thực hiện ngay trên mặt sau của một tờ giấy ăn.

Phương trình cốt lõi cho trọng số:

VRAM_weights (GB) = parameters (billions) × bits_per_weight ÷ 8

Các giá trị bit mỗi trọng số bạn cần (đây là tỷ lệ hiệu quả cho các tệp GGUF k-quant, vốn có thêm một chút siêu dữ liệu khối bên cạnh độ sâu bit danh nghĩa):

Ví dụ minh họa, Gemma 4 12B ở mức Q4_K_M: 11.95 × 4.5 ÷ 8 = khoảng 6.7 GB cho trọng số. Con số này khớp với mức khoảng 6.6 GB được trích dẫn trong thẻ mô hình chính thức và giải thích tại sao nó vừa vặn với card 8 GB, chừa chỗ cho ngữ cảnh khiêm tốn. Áp dụng phép tính tương tự cho mô hình 70B ở mức Q4, ta có 70 × 4.5 ÷ 8 = 39.4 GB, đó là lý do tại sao quy tắc "bạn cần hai card 24 GB hoặc một card 48 GB cho mô hình 70B" luôn được nhắc đi nhắc lại.

Bức tranh toàn cảnh bổ sung thêm hai yếu tố nữa: tổng VRAM ≈ trọng số + bộ đệm KV + ~15-20% dự phòng. Phần dự phòng bao gồm các bộ đệm kích hoạt, ngữ cảnh CUDA và phân mảnh bộ nhớ; GPU của bạn cũng dành riêng khoảng nửa gigabyte cho driver, vì vậy đừng bao giờ lên kế hoạch sử dụng 100% dung lượng VRAM ghi trên thông số kỹ thuật.

Tại sao Bộ đệm KV là con số khiến bạn gặp rắc rối

Bộ đệm KV lưu trữ các khóa (keys) và giá trị (values) attention cho mọi token đã có trong ngữ cảnh, và nó tăng tuyến tính theo độ dài ngữ cảnh. Với các prompt ngắn, nó chỉ là sai số làm tròn. Nhưng khi đẩy lên ngữ cảnh dài, nó có thể sánh ngang hoặc thậm chí vượt quá chính dung lượng trọng số. Đây là lý do phổ biến nhất khiến một mô hình lẽ ra "vừa vặn" lại báo lỗi hết bộ nhớ (out-of-memory) ngay giữa chừng quá trình sinh văn bản.

Công thức, tính cho mỗi token:

KV_cache_per_token (bytes) = num_layers × 2 × kv_dim × precision_bytes
kv_dim = num_kv_heads × head_dim   (grouped-query attention shrinks this)

Lấy ví dụ Llama 3.3 70B: 80 lớp, 8 đầu KV, kích thước đầu 128, nên kv_dim là 1024. Ở FP16, ta có 80 × 2 × 1024 × 2 = 327.680 byte mỗi token, khoảng 0.31 MB. Nhân với độ dài ngữ cảnh, câu chuyện đã rõ ràng: ở 8K token, bộ đệm khoảng 2.6 GB, ở 32K là khoảng 10 GB, và ở 128K nó phình to lên khoảng 41 GB. Con số cuối cùng này nằm ngoài 40 GB trọng số, nên một "mô hình 40 GB" âm thầm trở thành vấn đề 80 GB ngay khi bạn lấp đầy cửa sổ ngữ cảnh.

Có hai lối thoát thực tế. Attention truy vấn nhóm (Grouped-query attention - mà mọi mô hình gần đây đều sử dụng) đã cắt giảm đáng kể kv_dim so với thiết kế multi-head cũ, nên các mô hình hiện đại thân thiện hơn nhiều so với Llama 2. Và hầu hết các engine suy luận có thể lượng tử hóa bộ đệm KV xuống 8-bit hoặc 4-bit, giảm một nửa hoặc một phần tư kích thước của nó với cái giá chất lượng nhỏ. Nếu bạn phục vụ ngữ cảnh dài trong môi trường production, bài so sánh vLLM và SGLang sẽ đề cập backend nào quản lý bộ nhớ này hiệu quả nhất với attention phân trang.

Mô hình MoE: Tại sao "Tham số đang hoạt động" không cứu được VRAM

Đây là cái bẫy khiến nhiều người tốn kém nhất. Một mô hình Hỗn hợp Chuyên gia (Mixture-of-Experts) như DeepSeek-V3.2 (671B tổng, 37B đang hoạt động, chia sẻ kiến trúc V3) hoặc GLM-5.2 (744B tổng, 40B đang hoạt động) định tuyến mỗi token qua một tập hợp con nhỏ các chuyên gia của nó. Tiếp thị thường nhấn mạnh vào con số đang hoạt động vì nó mô tả tốc độ: bạn chỉ trả chi phí tính toán cho 37B tham số mỗi token, nên suy luận nhanh so với kích thước mô hình. Nhưng mọi chuyên gia phải nằm trong bộ nhớ, sẵn sàng được chọn, nghĩa là ngân sách VRAM của bạn được xác định bởi tổng số tham số, không phải số đang hoạt động.

Vì vậy, cách đọc trung thực bảng trên là: GLM-5.2 chạy với tốc độ của mô hình 40B nhưng chiếm dụng bộ nhớ của mô hình 744B. Đó là lý do tại sao các mô hình nguồn mở tiên phong này cần máy chủ 8 GPU hoặc máy có bộ nhớ thống nhất lớn, mặc dù một lượt chuyển tiếp (forward pass) đơn lẻ khá rẻ. Qwen3-235B-A22B có cùng cấu trúc ở quy mô nhỏ hơn, nhanh mỗi token nhưng nặng nề khi lưu trữ.

Điểm sáng của MoE xuất hiện trên phần cứng bộ nhớ thống nhất. Một Mac Studio với 512 GB bộ nhớ thống nhất có thể chứa mô hình 671B ở mức Q4 và vẫn chạy ở tốc độ khả dụng chính xác vì chỉ có 37B được kích hoạt, nên nhu cầu băng thông bộ nhớ mỗi token vẫn ở mức hợp lý. Nếu bạn mới bắt đầu chạy các mô hình này cục bộ, hãy bắt đầu với hướng dẫn cài đặt LLM cục bộ trước khi chi tiền cho phần cứng.

Nên chọn mức lượng tử hóa nào?

Đối với hầu hết mọi người, Q4_K_M là lựa chọn mặc định đúng đắn: nó giữ chất lượng gần như đầy đủ trong khi cắt giảm dung lượng FP16 đi khoảng 4 lần. Chỉ nâng lên Q5_K_M hoặc Q8 nếu bạn có dư VRAM và nhiệm vụ nhạy cảm về chất lượng, và chỉ dùng FP16 khi bạn tinh chỉnh (fine-tuning) hoặc đánh điểm chuẩn so với tham chiếu. Dưới mức Q4, chất lượng suy giảm nhanh chóng, nên Q3 và thấp hơn chỉ là giải pháp cuối cùng để ép một mô hình vào card thực sự quá nhỏ.

Một lưu ý: chất lượng lượng tử hóa không giống nhau across các mô hình. Các mô hình rất nhỏ (dưới 4B) chịu ảnh hưởng của Q4 nhiều hơn các mô hình lớn, vì chúng có ít sự dư thừa để hy sinh. Trên mô hình 70B, khó phân biệt Q4 và Q8 trong hầu hết các tác vụ. Trên mô hình 1.7B, khoảng cách là rõ rệt.

Bạn thực sự cần GPU nào?

Khớp cột Q4 của bảng tổng hợp với một card có một chút dư địa cho bộ đệm KV. Dưới đây là ánh xạ thực tế từ phần cứng consumer giá rẻ đến trung tâm dữ liệu, cùng với tầng mô hình mà mỗi lớp có thể chạy thoải mái ở mức Q4.

Apple Silicon xứng đáng được nhắc đến đặc biệt vì bộ nhớ thống nhất thay đổi hoàn toàn phép tính. Mac không tách biệt VRAM khỏi RAM hệ thống, nên một máy M-series 128 GB có thể tải các mô hình mà lẽ ra cần nhiều GPU rời, đánh đổi thông lượng đỉnh cao để có khả năng chứa trọng số khổng lồ trên một máy tính để bàn. Đối với các backend khai thác tối đa bất kỳ card nào trong số này, bài tổng hợp các công cụ tốt nhất để chạy LLM cục bộ của chúng tôi đã đánh điểm chuẩn sự khác biệt tốc độ thực tế.

Cách chúng tôi tính toán VRAM cho các triển khai khách hàng

Tại Techsy, chúng tôi triển khai các mô hình nguồn mở cho khách hàng đủ thường xuyên để việc tính toán VRAM trở thành cuộc hội thoại đầu tiên, trước khi chọn mô hình, trước khi viết prompt, trước bất cứ thứ gì. Phương pháp của chúng tôi cố tình nhàm chán, vì chế độ thất bại (lỗi OOM trong production dưới tải ngữ cảnh thực) rất đắt đỏ. Dưới đây là quy trình chúng tôi thực sự áp dụng.

Chúng tôi bắt đầu từ phép tính trong bảng, sau đó đo lường. Sau khi tải mô hình, chúng tôi kiểm tra dấu chân bộ nhớ thực tế thay vì tin vào ước tính:

# What the GPU is actually holding
nvidia-smi --query-gpu=memory.used,memory.total --format=csv

# For an Ollama-served model, its real memory + how much sits on GPU vs CPU
ollama ps

# llama.cpp: control the split explicitly and cap context to bound KV cache
llama-server -m model-Q4_K_M.gguf --n-gpu-layers 999 --ctx-size 8192

Bài học lặp đi lặp lại: các đội ngũ tính toán cho trọng số và quên bộ đệm KV, rồi tự hỏi tại sao một mô hình tải ổn lại chết sau ba yêu cầu dài trong buổi demo. Chúng tôi tính toán cho trọng số cộng với bộ đệm KV ở ngữ cảnh tối đa mà ứng dụng thực sự sử dụng, cộng thêm dự phòng, và chúng tôi giới hạn --ctx-size để một yêu cầu失控 không thể làm sập máy. Đối với bất kỳ thứ gì hướng tới khách hàng, chúng tôi thà chạy một mô hình 32B đã lượng tử hóa không bao giờ sụp đổ hơn là một mô hình 70B FP16 bị OOM dưới tải.

Nếu bạn đang cân nhắc giữa việc tự lưu trữ một mô hình nguồn mở hay ở lại với API hosted, sự đánh đổi đó (chi phí phần cứng và gánh nặng vận hành so với giá mỗi token và quyền kiểm soát) chính xác là những gì đội ngũ của chúng tôi phạm vi hóa trong một dự án tích hợp AI. Nếu việc có người chạy các con số dựa trên khối lượng công việc thực tế của bạn sẽ hữu ích, hãy nhận tư vấn miễn phí và chúng tôi sẽ cùng bạn tính toán.

Về tác giả

Mert Batur Gurbuz là Đồng sáng lập của Techsy.io, nơi đội ngũ phát triển các tác nhân AI, hệ thống tự động hóa và pipeline voice/SDR cho khách hàng B2B. Anh ấy đang học tại Đại học Birmingham và viết về ngăn xếp công cụ LLM mà đội ngũ Techsy thực sự sử dụng trong production.

Thông tin xác thực: Đồng sáng lập, Techsy.io, Đại học Birmingham. Kết nối trên LinkedIn.

Câu hỏi thường gặp

Tôi cần bao nhiêu VRAM để chạy mô hình 70B?

Một mô hình dày đặc 70B như Llama 3.3 70B cần khoảng 40 GB VRAM cho trọng số ở mức Q4_K_M, vì vậy hãy lên kế hoạch cho một card 48 GB (RTX 6000 Ada) hoặc hai card 24 GB. Cộng thêm vài gigabyte cho bộ đệm KV nếu bạn sử dụng ngữ cảnh dài, điều này đẩy yêu cầu thực tế lên 48 GB hoặc hơn.

Llama, Qwen hoặc DeepSeek cần bao nhiêu VRAM?

Nó phụ thuộc hoàn toàn vào biến thể. Llama 4 Scout cần khoảng 62 GB ở Q4, Qwen3-32B khoảng 18 GB, và Qwen3-8B dưới 5 GB. DeepSeek-V3.2, một MoE 671B, cần khoảng 382 GB vì mọi chuyên gia đều phải được tải. Luôn kiểm tra tổng số tham số, không phải số đang hoạt động, đối với các mô hình MoE.

Tôi có thể chạy LLM trên GPU 8GB không?

Có, rất thoải mái. Một card 8 GB như RTX 4060 chạy các mô hình lên đến khoảng 12B tham số ở mức Q4_K_M. Gemma 4 12B vừa vặn trong khoảng 6.8 GB, chừa chỗ cho ngữ cảnh khiêm tốn. Đối với bất kỳ thứ gì lớn hơn, bạn要么 lượng tử hóa mạnh hơn, giữ ngữ cảnh ngắn, hoặc chuyển sang card lớn hơn.

GPU 24GB như RTX 4090 chạy được gì?

Card 24 GB xử lý các mô hình dày đặc lên đến khoảng 32B ở mức Q4_K_M với dư địa cho ngữ cảnh hợp lý, nên Qwen3-32B và Mistral Small 3.2 24B chạy rất ổn. Nó cũng chạy được MoE Qwen3-30B-A3B, vốn tải 30B trọng số nhưng sinh văn bản với tốc độ của mô hình 3B nhờ kích hoạt thưa.

Lượng tử hóa có làm giảm chất lượng mô hình không?

Ở mức Q4_K_M trở lên, mất mát chất lượng là nhỏ và thường không nhận thấy được trong các tác vụ thực tế, đặc biệt đối với các mô hình trên 13B. Khoảng cách widen khi bạn đi xuống thấp hơn và khi mô hình nhỏ hơn, nên Q4 trên mô hình 70B gần như miễn phí trong khi Q4 trên mô hình 1.7B thì nhận thấy rõ. Q8 hầu như không mất mát nếu bạn có đủ bộ nhớ.

Mô hình MoE có cần ít VRAM hơn mô hình dày đặc không?

Không, và đây là hiểu lầm phổ biến nhất. Mô hình Hỗn hợp Chuyên gia phải giữ mọi chuyên gia trong VRAM, nên bộ nhớ của nó được xác định bởi tổng số tham số. Con số tham số đang hoạt động chỉ mô tả tốc độ suy luận. GLM-5.2 chạy với tốc độ của mô hình 40B nhưng cần bộ nhớ của mô hình 744B.

Bộ nhớ thống nhất có giống với VRAM không?

Về chức năng, để tải mô hình, thì có. Apple Silicon và một số hệ thống khác chia sẻ một pool bộ nhớ giữa CPU và GPU, nên một máy Mac 128 GB có thể tải các mô hình mà lẽ ra cần nhiều GPU rời. Sự đánh đổi là băng thông: bộ nhớ thống nhất thường cung cấp thông lượng đỉnh thấp hơn so với GPU trung tâm dữ liệu cao cấp, nên số token trên giây thấp hơn.

Tôi có thể offload một phần mô hình vào RAM hệ thống hoặc CPU không?

Có. Các engine như llama.cpp và Ollama cho phép bạn giữ một số lớp trên GPU và phần còn lại trong RAM hệ thống với cờ như --n-gpu-layers. Nó cho phép bạn chạy một mô hình quá lớn so với VRAM của bạn, nhưng mỗi lớp trên CPU làm chậm quá trình sinh văn bản đáng kể, vì vậy hãy sử dụng nó để làm cho mô hình khả thi, không phải để chạy nhanh.

Làm thế nào để tính VRAM cho một mô hình không có trong bảng?

Nhân số lượng tham số (tính bằng tỷ) với số bit mỗi trọng số cho mức lượng tử hóa của bạn, sau đó chia cho 8. Đối với Q4_K_M, sử dụng khoảng 4.5 bit, nên mô hình 40B cần 40 × 4.5 ÷ 8 = khoảng 22.5 GB cho trọng số. Cộng thêm khoảng 15-20% dự phòng plus bộ đệm KV của bạn cho yêu cầu thực tế.