Bước vào bất kỳ thread nào về LLM local, cãi vã luôn xoay quanh GPU. Benchmark VRAM, card 24 GB, CUDA với ROCm, và chuyện 3060 còn là card của dân hay không. Trong khi đó, con số thực sự quyết định mô hình của bạn chạy được hay không lại nằm ở khe khác — không benchmark, không marketing: máy đó có bao nhiêu RAM.
VRAM bán giấc mơ. RAM quyết định mô hình có khởi động được không — và khi chạy rồi thì còn lại bao nhiêu ngữ cảnh.
Tôi đã kiểm chứng trên chính chiếc máy trước mặt khi viết bài này: desktop Ryzen với 32 GB RAM và GeForce RTX 3060 12 GB VRAM. Tải llama3.1:8b — trang tải ghi 4,9 GB. Hãy xem nó thực sự chiếm trước bao nhiêu:
Toàn bộ lập luận nằm gọn trong một màn hình. Một «mô hình 4,9 GB» đã chiếm trước 7,0 GB trước khi trả lời câu prompt đầu tiên — thuế ngữ cảnh 43% — và giữ lấy 7.963 trên 12.288 MiB VRAM. Trọng số chưa bao giờ là ngân sách. Ngân sách là ngữ cảnh.
Những gigabyte dôi ra từ đâu ra
Ghi chú bộ nhớ của llama.cpp viết rõ phép tính mà các trang tải về bỏ qua: tổng bộ nhớ = trọng số mô hình + KV cache + bộ đệm tính toán. Chỉ hạng tử đầu là cố định. KV cache tăng tuyến tính theo độ dài ngữ cảnh, bộ đệm tính toán tăng theo batch. Ollama bọc llama.cpp nên cùng một định luật — vì thế ollama ps báo 7,0 GB cho thẻ 4,9 GB với cửa sổ 32.000 token, tất cả nằm thường trú trên GPU.
Mô hình lượng tử hóa không phải là thỏa hiệp. Đó là lời thừa nhận rằng bộ nhớ mới luôn là ngân sách thật.
Đó cũng là lý do bậc thang lượng tử hóa GGUF tồn tại. Q4 không phải tôn giáo; Q4 là cách để phép tính bộ nhớ hạ cánh được xuống phần cứng mà người ta thực sự có. Và vì thế hai setup 8B «giống hệt nhau» chẳng giống nhau chút nào: cùng một mô hình, độ dài ngữ cảnh khác, máy khác.
Bảng mà không ai điền trước khi mua
Ba hạng mô hình, hai loại bộ nhớ, một card 12 GB và 32 GB RAM — cấu hình mà hàng nghìn lập trình viên thực sự đang có:
| Hạng mô hình (Q4) | Tải về | Đã nạp + ctx 32k | Trên 12 GB VRAM | Trên 32 GB RAM |
|---|---|---|---|---|
7–8B (llama3.1:8b) | 4,9 GB | 7,0 GB (đo thực tế) | 100% GPU, dùng ~8 GiB | gần như không thấy |
13–14B (qwen2.5:14b) | 9,0 GB | ~12 GB | offload bắt đầu | vẫn ổn |
27–32B (gemma3:27b) | 17 GB | ~20 GB trở lên | CPU gánh trọng số | lý do duy nhất để nó chạy |
Đọc lại hai dòng cuối. Chỉ với VRAM, một mô hình 14B với ngữ cảnh thật đã là công việc offload chia đôi, còn 27B là bất khả thi. Trên 32 GB RAM, cả hai chỉ là chậm. Khoảng cách ấy — giữa bất khả thi và chậm — là toàn bộ khác biệt thực dụng giữa VRAM và RAM. Vừa VRAM thì nhanh. Vừa RAM thì chạy được. Không vừa cái nào, bạn đang swap sang NVMe và thời gian mất luôn ý nghĩa.
Offload đi qua PCIe, và FAQ của Ollama nói thẳng cái giá: những layer không vừa trong GPU chạy trên CPU, và thông lượng sụp đổ khi phần GPU co lại. Không ai chủ động chọn sự đánh đổi đó. Nó đến lặng lẽ, layer này đến layer khác, và triệu chứng chỉ là «mô hình local bị thổi phồng quá đà».
Cuốn sổ thật thà
Những gì vỡ hoặc làm tôi bất ngờ khi viết bài này, theo thứ tự:
- Chính con số 43%. Tôi tưởng mô hình 8B chiếm «cỡ đúng dung lượng tệp». Nó chiếm trước 7,0 GB so với 4,9 GB tải về. Nếu nó làm tôi bất ngờ, nó sẽ làm bất kỳ ai đọc spec sheet thay vì
psbất ngờ y hệt. - Phiên chụp màn hình. Lần chụp đầu tôi bắt nhầm cửa sổ. Lần thứ hai thành công — chính là ảnh phía trên. Bằng chứng là một quy trình làm việc, không phải cảm hứng; và vòng lặp pull → chụp →
ollama rmgiữ cho ổ đĩa thật thà. - Cái không vỡ: GPU chưa từng tràn. 8B với ngữ cảnh 32k trên 12 GB thực sự thoải mái. Card vẫn ổn. Mất hiệu chuẩn là những lời bàn quanh chiếc card.
Điều này không có nghĩa GPU không quan trọng — dòng 100% GPU trong ảnh chính là lý do việc sinh văn bản cảm giác tức thì. Ý là GPU mới là câu hỏi thứ hai. Lựa chọn Ollama hay llama.cpp đến sau khi bạn biết cái gì vừa, không phải trước.
Quy tắc đáng giữ lại
RAM cần = tệp mô hình + KV cache cho ngữ cảnh thật của bạn + 4 GB để vẫn là một chiếc máy tính. Với 7–8B ở Q4, 16 GB là thoải mái. Với 14B–32B, 32 GB ngừng là xa xỉ và trở thành bản thân vấn đề. Mua VRAM cho tốc độ bạn muốn ở ngữ cảnh bạn dùng; mua RAM cho tất cả những gì sẽ tải lên trong tương lai.
Nhìn
ollama psmột lần, và tôn giáo spec sheet lặng lẽ kết thúc.
Thế nên, hai câu hỏi. Khi lắp máy tiếp theo, bạn mua VRAM cho những benchmark sẽ đăng — hay mua RAM cho những mô hình thực sự sẽ chạy? Và nói thật: mấy mô hình bạn tải lúc 2 giờ sáng, bạn xóa bao nhiêu trước bữa sáng? Tôi đã xóa, ngay trong lúc viết bài. Hãy bình luận bảo tôi rằng tôi không một mình — và máy bạn đang đứng bên nào của ranh giới RAM/VRAM.
FAQ
Cần bao nhiêu RAM để chạy LLM local?
Kích thước tệp mô hình, cộng ngữ cảnh, cộng phần của desktop bạn. 16 GB là thoải mái cho mô hình 7–8B ở Q4; 32 GB mới là thứ biến mô hình 14–32B từ bản demo thành công cụ hằng ngày.
VRAM hay RAM quan trọng hơn với LLM local?
VRAM quyết định tốc độ khi mọi thứ vừa nằm trong nó. RAM quyết định mô hình có chạy được không và bao nhiêu ngữ cảnh còn sống sót. Offload qua PCIe ở giữa là vùng chậm mà không ai thích.
Vì sao mô hình đã tải dùng nhiều bộ nhớ hơn dung lượng tải về?
KV cache và bộ đệm tính toán lớn dần theo độ dài ngữ cảnh. Tài liệu bộ nhớ của llama.cpp ghi rõ phép tính: trọng số + KV cache + bộ đệm tính toán — và trang tải về chỉ ghi số đầu tiên.
— mrsaynothing
— mrsaynothing
Ý kiến đã load-test trước khi xuất xưởng. Phần lớn là vậy.
Thảo luận bài này trên dev.to dev.to ↗
Nhận bài tranh luận tiếp theo qua email
Một email mỗi bài viết. Đồng ý cũng được, mổ xẻ cũng được.
cái này là gì?SSH Permission Denied (publickey): Cách sửa thật
Thích kiểu viết này? Tôi build như vậy để kiếm sống. thuê tôi