24GB VRAM và cuộc đổi gió local AI

24GB VRAM và cuộc đổi gió local AI

Local AI không còn là cuộc thi nhét model to nhất vào GPU. Tín hiệu thị trường mới: chọn đúng model, đúng workload, đúng chi phí vận hành.

“Anh có con 4090 rồi, giờ nên chạy model nào cho đáng tiền?”

Câu này mình nghe hơi nhiều dạo gần đây, thường xuất hiện sau 11 giờ đêm, khi một tech lead vừa chốt xong budget workstation và bắt đầu rơi vào vùng áp thấp của bảng benchmark. Qwen mới, Gemma mới, Mistral 3, DeepSeek tối ưu tốc độ, rồi bên kia là Kimi K3, GLM-5.2, DeepSeek V4 Pro với MoE nghìn tỷ tham số. Nhìn một lúc là thấy trời kéo mây.

Nhưng tranh luận thật sự không phải “model nào mạnh nhất?”. Với team đang build hệ thống AI, câu hỏi đáng tiền hơn là: workload nào xứng đáng chạy local trên một GPU 24GB, workload nào nên đẩy lên API hoặc hạ xuống model nhỏ hơn?

Sau bài này, mình muốn bạn đổi một cách nghĩ: 24GB VRAM không phải sân chơi hobby nữa, nhưng cũng không phải vé vào mọi bài toán production. Nó là một tầng triển khai riêng, cần quyết định riêng.

Sơ đồ minh họa cho bài 24GB VRAM và cuộc đổi gió local AI

Sơ đồ tóm tắt ý chính của bài viết.

Cuộc tranh luận: model to nhất hay model vừa khít nhất?

Một vài năm trước, dân local LLM hay có phản xạ rất dễ thương: kiếm model 70B, quantize xuống, nhét cho vừa GPU, rồi tự hào vì “chạy được”.

Giờ cách nghĩ đó bắt đầu lỗi thời.

Nguồn chính về local LLM trên một GPU 24GB chỉ ra một tín hiệu khá rõ: với RTX 3090 hoặc RTX 4090, tầng 24GB đã đủ cho các model 20B–35B hiện đại chạy nghiêm túc hơn, đặc biệt cho coding, chat, agent nhẹ và tác vụ nội bộ. Điểm đáng chú ý không nằm ở card nào “oách” hơn, mà ở việc model bạn chọn có để lại đủ chỗ cho context và runtime hay không.

Ở đây có ba khoản ăn VRAM:

Quantization — nén trọng số model để giảm bộ nhớ — là cần, nhưng không nên được dùng như băng keo dán mọi vết nứt. Q4_K_M thường là điểm cân bằng phổ biến giữa chất lượng và dung lượng. Lên Q5_K_M hoặc Q6_K có thể giữ chất lượng tốt hơn nhưng ăn VRAM hơn. Q8_0 hoặc BF16 với model cỡ 30B thì thường không còn thoải mái trên một GPU 24GB.

Nói thẳng ra thì: chạy vừa không có nghĩa là chạy ổn.

Biến số một: VRAM không chỉ chứa model

Đây là chỗ nhiều team hiểu sai. Bạn nhìn file model thấy vừa 24GB, hí hửng deploy, rồi đến khi prompt dài hơn, agent gọi thêm tool, hoặc user giữ phiên chat lâu hơn, hệ thống bắt đầu hụt hơi.

Ví dụ cụ thể: giả sử team bạn muốn làm coding assistant nội bộ. Một model 32B ở mức nén phù hợp có thể nằm trong GPU 24GB, nhưng nếu bạn muốn context dài để nhét nhiều file, lịch sử chat, diff, requirement và log lỗi, KV cache sẽ tăng theo. Lúc đó model “vừa” trên giấy có thể thành “chật” trong vận hành.

Đặc biệt cẩn thận với MoE, Mixture-of-Experts — kiến trúc có nhiều “chuyên gia” bên trong, mỗi token chỉ kích hoạt một phần. Nghe rất tiết kiệm ở mặt compute, nhưng về VRAM thì không đơn giản. Với nhiều MoE model, bạn vẫn phải để toàn bộ experts trong bộ nhớ, không thể chỉ tính active parameters — số tham số thực sự được dùng mỗi token.

Đây là lý do các model MoE cực lớn như Mistral Large 3 với 675B total parameters và 41B active parameters, hay nhóm Kimi K3, DeepSeek V4 Pro, GLM-5.2 ở tầng rất lớn, không nên bị nhầm với bài toán “một GPU 24GB ở góc văn phòng”. Chúng là tín hiệu thị trường quan trọng, nhưng không cùng mặt phẳng triển khai với workstation local.

Tầng 24GB giống một ngày lặng gió đủ đẹp để ra khơi gần bờ: rất hữu ích, nhưng đừng lái thẳng vào tâm bão MoE nghìn tỷ tham số rồi trách thuyền nhỏ.

Biến số hai: tốc độ đang trở thành lợi thế chiến lược

DeepSeek công bố DSpark với mức tăng tốc phản hồi theo tuyên bố của họ là 60–85%. Điểm đáng đọc không chỉ là con số. Cơ chế bên dưới là speculative decoding — dùng model nhỏ đề xuất token, rồi model lớn kiểm tra theo lô để tăng tốc sinh văn bản.

Hiểu nôm na: thay vì để một người viết từng chữ rồi người khác kiểm từng chữ, bạn để một người phụ soạn trước vài cụm, người chính duyệt nhanh cả cụm. Nếu đoán đúng nhiều, tốc độ tăng đáng kể; nếu đoán sai nhiều, lợi ích giảm.

Tín hiệu thị trường ở đây khá rõ: khi chip đắt, GPU khan, hoặc bị ràng buộc bởi kiểm soát xuất khẩu, tối ưu inference trở thành vũ khí cạnh tranh. Không chỉ Trung Quốc hay EU quan tâm chuyện này. Team Việt Nam cũng nên để ý, vì rất nhiều đội không có luxury để scale bằng cách “thêm GPU là xong”.

Vấn đề là hiệu quả hơn không tự động làm tổng chi phí giảm. Khi inference rẻ hơn, team thường dùng nhiều hơn: context dài hơn, agent chạy nhiều bước hơn, user thử nhiều hơn. Đây là cái bẫy rất đời: trời vừa tan sương, cả công ty kéo nhau ra đường.

Vì vậy, khi đọc một release tăng tốc, câu hỏi không phải “có nhanh không?”, mà là:

Khi nào chọn local 24GB, khi nào chọn API lớn?

Mình sẽ đặt tranh luận này thành một bảng quyết định, vì nhìn benchmark quá lâu dễ bị chóng mặt.

| Tình huống | Local 24GB hợp lý khi | API/model lớn hợp lý khi |
|---|---|---|
| Coding assistant nội bộ | Repo vừa phải, cần privacy, chấp nhận tinh chỉnh prompt và routing | Cần reasoning mạnh, context rất dài, nhiều ngôn ngữ/framework lạ |
| Chatbot kiến thức công ty | Tài liệu nhạy cảm, traffic vừa, RAG đã kiểm soát tốt | Cần độ ổn định cao, SLA rõ, multilingual phức tạp |
| Agent automation | Task ngắn, tool calling được ràng buộc chặt | Workflow dài, nhiều bước suy luận, cần recovery tốt |
| Experiment sản phẩm | Muốn test nhanh chi phí cố định trên máy có sẵn | Cần đánh giá năng lực frontier trước khi chốt hướng |
| Fine-tune/adapter nhẹ | Dataset nhỏ, mục tiêu hẹp, kiểm soát data | Cần huấn luyện lớn hoặc alignment phức tạp |

Có một điểm dễ bị bỏ qua: license. Các model permissive như Apache 2.0 hoặc MIT giúp team dễ thử, dễ nhúng, dễ tùy biến hơn trong môi trường doanh nghiệp. Mistral 3 nhấn mạnh hướng release open-weight với nhiều kích cỡ, từ model nhỏ dense 3B/8B/14B đến Large 3. Qwen, Gemma, DeepSeek cũng đang xuất hiện trong các so sánh local vì fit tốt hơn cho một số workload.

Nhưng license tốt không thay cho observability. Với production, bạn vẫn cần log latency, token throughput, VRAM headroom, tỷ lệ timeout, chất lượng output và fallback path. Local không có nghĩa là miễn phí; nó chỉ đổi bill cloud thành bill vận hành.

Framework cho builder: ba tầng model, không một ngai vàng

Nếu là mình, mình sẽ không hỏi “model nào thắng?”. Mình sẽ chia hệ thống thành ba tầng:

Tầng 1: Local utility model
Model chạy trên 24GB cho việc lặp nhanh: autocomplete, classify, rewrite, trích xuất trường, agent nội bộ tác vụ ngắn. Mục tiêu là latency ổn, dữ liệu không rời máy chủ, chi phí dự đoán được.

Tầng 2: Hosted strong model
Model API hoặc cluster lớn hơn cho tác vụ cần reasoning sâu, multilingual khó, hoặc context rất dài. Mục tiêu là chất lượng và độ tin cậy, không phải rẻ nhất mỗi request.

Tầng 3: Specialized accelerator
Các kỹ thuật như speculative decoding, caching, batching, routing, hoặc model nhỏ phụ trợ. Mục tiêu là giảm lãng phí inference, nhất là khi traffic tăng.

Hình dung thế này: team bạn có một sản phẩm SaaS B2B cần AI đọc ticket support và đề xuất phản hồi. Trong một buổi chiều, bạn có thể làm thử như sau:

  1. Chọn 20 ticket thật đã ẩn thông tin nhạy cảm.
  2. Chạy một model local 20B–35B ở quantization phù hợp để phân loại intent và đề xuất câu trả lời ngắn.
  3. Gửi cùng bộ ticket đó lên model mạnh hơn qua API cho các case khó.
  4. Ghi lại 5 chỉ số: latency, VRAM còn trống, tỷ lệ câu phải sửa, token dùng, và lỗi nghiêm trọng.
  5. Tạo rule routing đơn giản: case dễ xử lý local, case mơ hồ đẩy lên model mạnh.

Không cần dựng cả platform. Chỉ cần đủ dữ liệu để biết workload nào đáng ở tầng nào.

Ai hưởng lợi, ai bị ép đổi cách làm?

Người hưởng lợi đầu tiên là các team có GPU 24GB sẵn: studio AI nhỏ, công ty outsource, nhóm product nội bộ, lab trường đại học. Họ có thể chạy workload thật mà không phải gửi mọi thứ ra ngoài.

Người hưởng lợi thứ hai là các vendor model open-weight. Khi model 20B–35B đủ tốt cho nhiều tác vụ, họ có cửa đi vào doanh nghiệp qua đường “tự host được”, không cần cạnh tranh trực diện với frontier API ở mọi mặt trận.

Người bị ép đổi cách làm là các team SaaS đang dùng AI như một lớp trang trí đắt tiền. Câu chuyện Figma khá đáng chú ý ở đây: khi AI dựa vào model bên ngoài, inference cost có thể bóp margin, nên sản phẩm phải tối ưu luồng làm việc, giảm token thừa, và giữ human judgment ở trung tâm. Đây không chỉ là chuyện design tool. Bất kỳ app AI nào cũng sẽ gặp áp lực tương tự nếu mỗi tương tác đều gọi model lớn.

Kết luận của mình: đừng để release ồn ào quyết định kiến trúc của bạn. Hãy để workload, VRAM headroom, latency và quyền kiểm soát dữ liệu quyết định.

24GB VRAM không phải đích đến. Nó là một trạm khí tượng tốt: đủ gần mặt đất để đo thời tiết thật, đủ rẻ để lắp nhiều nơi, và đủ tỉnh táo để nhắc bạn mang áo mưa trước khi deploy.

---
Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng

Nguồn tham khảo