- Đang tìm một mô hình có thể hội thoại cơ bản trên 5060ti + 16GB VRAM. Nếu có thể thì càng nhanh và hoạt động gần thời gian thực càng tốt
Tổng hợp câu trả lời
- Nhiều mô hình 8B~14B, 30B tham số có thể chạy hiệu quả trên 16GB VRAM, tiêu biểu được khuyến nghị gồm Qwen3, DeepSeek-R1, Mistral, Gemma3
- Chạy LLM cục bộ có ưu điểm về hiệu năng, chi phí và quyền riêng tư, nhưng hiệu năng thực tế và độ phù hợp của mô hình vẫn đòi hỏi thử nghiệm và tinh chỉnh riêng
- Kích thước tệp mô hình, mức quantization (lượng tử hóa) (Q4~Q6, v.v.), tải phân tán giữa GPU·RAM và các mẹo tối ưu phần cứng khác được chia sẻ rất sôi nổi
- Có nhiều công cụ như Ollama, LM Studio, llama.cpp, OpenWebUI, mỗi công cụ đều có ưu và nhược điểm về khả năng tiếp cận, độ linh hoạt và sự tiện lợi trong quản lý mô hình
- Nguồn thông tin cộng đồng (ví dụ: Reddit LocalLLaMA) hữu ích để cập nhật tin mới và mẹo thực chiến, nhưng cũng cần cẩn thận vì có nhiều phóng đại và thông tin sai lệch
Các LLM được đề xuất chính và mẹo sử dụng
- Qwen3: Có nhiều biến thể tham số như 8B/14B/30B; các mô hình 8B~14B có thể dùng thoải mái trên 16GB VRAM. Hiệu năng reasoning (suy luận) tốt, và nhờ kiến trúc MoE (Mixture of Experts) nên một số mô hình lớn vẫn có thể vận hành bằng cách offload sang RAM
- DeepSeek-R1-0528-Qwen3-8B: Được đánh giá là có năng lực reasoning nổi bật trong số các mô hình 8B mới nhất. Với bản 8B, phù hợp khi lượng tử hóa Q4~Q6 trên 4GB~8GB VRAM
- Mistral Small 3.1: Bản 14B hoặc 24B được khuyến nghị; chất lượng hội thoại tốt và tương đối ít censorship hơn. Đặc biệt có tính năng nhập hình ảnh
- Gemma3: Mô hình do Google cung cấp, mạnh về hội thoại trực quan. Tuy nhiên bị đánh giá là khá thiên về kiểu HR nên có nhiều disclaimer. Hallucination cũng xuất hiện tương đối thường xuyên
- Devstral: Mô hình lớn dựa trên Mistral. Từ 30B trở lên có thể chậm trên 16GB VRAM
- Dolphin, Abliterated: Các phiên bản ít censorship hơn, hữu ích trong những tình huống không mang tính routine
Tối ưu phần cứng và môi trường chạy
- Thiết lập quantization (lượng tử hóa): Các mức như Q4, Q5, Q6; mức lượng tử hóa càng thấp thì dùng càng ít VRAM (Q4 ≒ tham số/2, Q6 ≒ tham số*0.75). Tuy nhiên cần lưu ý khả năng suy giảm chất lượng
- Ước tính dung lượng VRAM: Ví dụ - 8B Q4 cần 4GB, 14B Q4 cần 7GB, 30B Q4 cần khoảng 15GB VRAM
- Offload sang RAM: Khi thiếu VRAM có thể chuyển một phần layer sang bộ nhớ CPU. Tuy nhiên phải chấp nhận tốc độ chậm hơn
- Lượng tử hóa KV cache: Khi tăng context window, nên dùng nén cache ở mức q4
Công cụ và frontend
- llama.cpp: Chạy nhanh và linh hoạt trên nhiều nền tảng. Hỗ trợ REST API và frontend React đơn giản. Có thể tải mô hình phân tán giữa VRAM và RAM
- Ollama: Cài đặt dễ và chuyển đổi mô hình thuận tiện, dễ tích hợp với frontend GUI. Tuy nhiên có giới hạn về hỗ trợ mô hình mới nhất và kích thước context
- LM Studio: Thuận tiện để quản lý mô hình trong môi trường GUI. Có tính năng dự đoán mức độ phù hợp với VRAM
- OpenWebUI: Chỉ là frontend. Cần backend như llama.cpp, vllm, v.v. Có thể quản lý và thử nghiệm nhiều mô hình cùng lúc
- KoboldCPP, SillyTavern: Frontend chuyên cho roleplay/kể chuyện/trò chơi, v.v.
Cộng đồng và thông tin thực chiến
- Reddit LocalLLaMA, HuggingFace, Discord: Tin tức mô hình mới, cách dùng, benchmark, kinh nghiệm thiết lập, v.v. được chia sẻ rất sôi nổi. Tuy nhiên cần chú ý đến thông tin sai lệch hoặc hiện tượng groupthink
- Các trang benchmark: livebench.ai, aider.chat cung cấp điểm số và bảng xếp hạng mới nhất theo từng mô hình
Mục đích sử dụng và trải nghiệm thực tế
- Quyền riêng tư, tiết kiệm chi phí: Với dữ liệu nhạy cảm/vấn đề riêng tư hoặc khi dùng lặp lại nhiều lần, mô hình cục bộ có tính ứng dụng cao hơn so với cloud
- Mức độ tự do trong thử nghiệm và tinh chỉnh: Linh hoạt hơn mô hình API trong fine-tuning theo miền chuyên biệt, chiến lược sampling, prompt engineering, v.v.
- Các trường hợp ứng dụng: Nhiều ví dụ thực chiến như RAG (tạo sinh kết hợp truy xuất), kết nối cơ sở dữ liệu cục bộ, tự động hóa agent, trợ lý offline
Câu hỏi và mẹo thường gặp
- Ước tính kích thước mô hình: Số tham số × bit (quantization)/8 = xấp xỉ lượng VRAM yêu cầu (GB). Cũng cần tính đến overhead và context window
- Đặc điểm theo từng mô hình: Qwen3 mạnh về reasoning/lập trình, Gemma3 mạnh về trực giác/hội thoại, Mistral ít censorship, Dolphin/abliterated là các bản uncensor, v.v.
- So sánh hiệu năng: Khuyến nghị tự benchmark và chạy các bài test tùy chỉnh để tìm mô hình phù hợp với mình
Kết luận và lời khuyên thực tế
- Không có "mô hình tốt nhất" tuyệt đối; tùy phần cứng, mục đích và sở thích mà nên thử nhiều mô hình 8B~14B mới như Qwen3, Mistral, Gemma3
- Vì việc khớp thông số như kích thước tệp mô hình, lượng tử hóa, kích thước context là rất quan trọng, nên cách hiệu quả nhất là tự thử nhiều mô hình và tận dụng mẹo từ cộng đồng
1 bình luận
Ý kiến Hacker News
Nếu muốn chạy LLM cục bộ, bạn có thể nhận được rất nhiều trợ giúp từ cộng đồng localllama trên reddit
Thực ra không có mô hình LLM nào có thể gọi là “tốt nhất” một cách tuyệt đối; mỗi mô hình đều có ưu và nhược điểm riêng, nên bạn phải tự thử nhiều cái
Ví dụ, mô hình DeepSeek-R1-0528-Qwen3-8B được phát hành hôm nay và cho thấy hiệu năng suy luận logic tốt nhất ở kích thước 8B
Ngoài ra, dòng Qwen3 cũng mới ra gần đây, cung cấp cách tiếp cận hybrid, hiệu năng tốt và nhiều kích cỡ phù hợp với các loại phần cứng khác nhau
Qwen3-30B-A3B có thể chạy với tốc độ ổn ngay cả trên CPU
Ngay cả mẫu mini 0.6B cũng khá nhất quán, tạo cảm giác rất ấn tượng
Khi dùng llama-cpp, tôi từng thấy trường hợp offload một số tensor sang CPU mà vẫn giữ được hiệu năng tốt
Thông thường trong llama-cpp bạn chỉ định số layer được đưa lên GPU (
-ngl), nhưng nếu các tensor đó không phải phần tính toán nặng thì có thể tiết kiệm bộ nhớ GPU bằng cách offload sang CPU mà không làm giảm tốc độTôi cũng từng đọc bài báo về việc chỉ nạp các neuron “hot” từ CPU (liên kết arxiv) và hy vọng sau này có thể dùng AI thật hay ngay tại nhà
Có một điều cần lưu ý với những ai chưa quen dùng Reddit
Trên Reddit, bao gồm cả LocalLlama, có rất nhiều thông tin sai hoặc tin giả được ưa chuộng, và tỷ lệ upvote/downvote không đảm bảo độ chính xác của thông tin
Những bình luận đúng nhưng giải thích khô khan lại có thể kém phổ biến, còn những giải thích sai nhưng thú vị, giàu cảm xúc hoặc hợp với ý kiến đám đông thì thường dễ nổi hơn
Người đã lăn lộn trên web lâu năm như tôi thì có thể tự lọc đại khái, nhưng nếu bạn mới bước vào những không gian có xu hướng tư duy bầy đàn mạnh như vậy thì nên tiếp nhận thông tin một cách cẩn trọng
Dạo này mô hình nào cũng đã đạt mức cơ bản đủ dùng, nên cuối cùng cảm giác giống như đi tìm “tính cách mô hình” hợp gu của mình hơn
OP cứ tải lần lượt rồi dùng thử là được
Với 16GB bộ nhớ, dùng llama.cpp và offload một phần sang DDR5 thì có thể chạy tới mô hình 30B (thậm chí cả dense model) ở tốc độ “tạm ổn”; nếu offload tensor thì còn tốt hơn
Qwen có vài điểm hơi hụt nếu xét như mô hình hội thoại
Mistral Nemo, Small và dòng Llama 3.X đến nay vẫn là những lựa chọn rất tốt
Gemma 3s thì tốt nhưng hơi khó đoán
Nếu muốn mức GPT-4 ngay tại nhà thì tôi đề xuất QwQ
Và chắc vẫn còn vài mô hình ổn khác mà tôi quên mất
Tôi tò mò không biết có mô hình nào được khuyên dùng để kết hợp với các công cụ lập trình như aider hay roo không
Trải nghiệm của tôi là tìm được mô hình thật sự dùng tool giỏi là khá khó
DeepSeek-R1-0528-Qwen3-8B là mô hình được tạo bằng cách chưng cất chain-of-thought của DeepSeek-R1-0528 vào Qwen3-8B Base; trên AIME 2024 nó cao hơn Qwen3-8B hơn 10% và đạt mức tương đương Qwen3-235B-thinking
Đây là một ví dụ nữa cho thấy distillation hiệu quả đến mức nào
Có lẽ đây cũng là lý do gần đây nhiều công ty OpenAI và phòng nghiên cứu che giấu chain-of-thought (COT) (bài tham khảo)
Tôi tò mò phần lớn mọi người đang dùng local LLM nhiều nhất vào việc gì
Nếu phần cứng không thật sự mạnh thì khó mà vượt được các mô hình độc quyền như Gemini hay Claude, nhưng có vẻ những mô hình nhỏ như vậy vẫn hữu ích; tôi chỉ muốn biết các trường hợp sử dụng cụ thể là gì
Không muốn giao dữ liệu cho bên thứ ba
Có khá nhiều người không muốn gửi prompt hay câu hỏi của mình ra bên ngoài
Tôi thường thử dùng mô hình cục bộ trước cho hầu hết prompt của mình, và bất ngờ là trong hơn một nửa số trường hợp, kết quả đã đủ tốt
Mỗi lần không phải dùng dịch vụ đám mây tôi lại thấy khá mãn nguyện
Tôi nghĩ tương lai của local LLM sẽ là nhanh chóng quyết định công việc nào nên xử lý theo cách nào rồi ủy quyền thật nhanh
Chẳng hạn chọn ngay công việc nào có thể xử lý bằng hệ thống cục bộ như MCP, công việc nào cần gọi API hệ thống như lịch hay email, hay công việc nào nên chuyển cho mô hình đám mây tối ưu nhất
Tôi hình dung nó như một Siri hoạt động tử tế
Hiện tôi đang thử nghiệm với một coding agent cục bộ tự làm dựa trên Devstral
Điểm tôi thích hơn Codex là nó có thể truy cập toàn bộ phần cứng, nên làm được những việc Codex không làm được như bật VM hay gửi yêu cầu mạng
Ngoài ra nó nhanh hơn Codex rất nhiều từ khâu thiết lập cho tới tạo patch
Dĩ nhiên kết quả chưa bằng Codex, nhưng Devstral dùng cho thay đổi nhỏ hay refactor thì khá ổn, và tôi kỳ vọng khi phần mềm tiếp tục tiến hóa thì sẽ dần xử lý được cả các thay đổi lớn hơn
Về nguyên tắc tôi cố gắng hạn chế dùng cloud hết mức có thể
Ví dụ gần đây có tin OpenAI đang làm một kiểu mạng xã hội để chia sẻ nội dung trò chuyện ChatGPT
Chạy cục bộ cũng giúp tôi hiểu rõ hơn cơ chế hoạt động bên trong của AI nên giá trị của tôi trên thị trường cũng tăng lên
Tôi cũng có thể thoải mái thử nghiệm các backend dùng LLM như web search, agent v.v., không phải gánh chi phí cloud, và tôi vốn đã có sẵn desktop chơi game từ thời LLaMa đầu tiên ra mắt
Dự án LocalScore của Mozilla cũng đáng để ý
Đây là dịch vụ so sánh, phân tích mức độ các mô hình khác nhau chạy tốt ra sao trên nhiều loại phần cứng
Tôi đồng ý với ý kiến đề xuất subreddit LocalLLama
Nó không phải nơi chọn ra “mô hình tốt nhất”, nhưng lại rất hữu ích để đặt câu hỏi, tìm hướng dẫn, cập nhật tin tức hay công cụ mới và so sánh nhiều mô hình
Cuối cùng vẫn là quá trình tự mình thử nhiều mô hình và điều chỉnh tham số để tìm ra thứ phù hợp nhất với mục đích của bản thân
Nếu là người dùng Hacker News, bạn cũng có thể cân nhắc bỏ qua Ollama hay LMStudio
Chúng có thể chậm tiếp cận các mô hình mới nhất, và nhiều khi bạn chỉ được chọn trong số những mô hình mà chúng đã kiểm thử
Ngoài ra còn thiếu cảm giác “mở nắp ra xem” cách mọi thứ hoạt động bên trong
Chỉ riêng llamacpp cũng đã hỗ trợ phần lớn các mô hình mới, và khi cần thì được cập nhật rất nhanh
Tôi thích tải mô hình từ huggingface rồi dùng định dạng GGUF (quantization thấp để tiết kiệm bộ nhớ)
Nhìn kích thước file GGUF là có thể ước lượng mô hình có vừa VRAM hay không (ví dụ: GGUF 24GB thì 16GB khó kham, 12GB thì được — nhưng nếu tăng context thì RAM tiêu thụ cũng tăng theo)
Cũng cần chú ý context window; đa số mô hình cũ chỉ có context 8K, và ngay cả khi đặt lên 32K thì hiệu quả cũng không tăng nhiều
llamacpp có thể tải binary cho Linux, Windows, macOS hoặc tự build, và cũng có thể chia mô hình giữa VRAM/RAM
Nó có frontend React đơn giản (
llamacpp-server) và cũng cung cấp REST API kiểu OpenAINhờ vậy có thể kết nối với nhiều frontend như oobabooga (
textgeneration webui)Nếu thấy llamacpp hơi thô thì Koboldcpp cũng là backend đáng cân nhắc (dù bên trong vẫn dựa trên llamacpp)
Điểm hấp dẫn của Ollama là có thể lấy trực tiếp bất kỳ GGUF nào từ HuggingFace và chạy kiểu
ollama run hf.co/unsloth/DeepSeek-R1-0528-GGUF:Q8_0Một trong những ưu điểm của Ollama là có thể dễ dàng load/unload mô hình lên GPU, nên trong các frontend như librechat hay openwebui bạn có thể đổi mô hình rất nhanh chỉ bằng dropdown
Tôi muốn nhấn mạnh sự tiện lợi của việc đổi mô hình mà không cần thao tác dòng lệnh
Ollama biến desktop thành máy chủ LLM và còn cho phép thiết bị từ xa trong cùng WiFi truy cập
Khi đổi mô hình, Ollama cũng hỗ trợ swap rất mượt mà mà không cần hạ server xuống
Với llama.cpp, nếu dùng CLI thì bạn phải tắt server, đổi cờ rồi chạy lại, nên khá bất tiện cho việc thử nghiệm hay phát triển ứng dụng nhanh
Trong số ứng dụng tôi tự làm, có cái bắt buộc phải đổi qua lại giữa 1B, 8B, 30B chỉ bằng tham số request web mà không cần khởi động lại server
Tôi chỉ có 8GB VRAM, nhưng gắn OpenWebUI làm frontend cho Ollama để tải nhiều mô hình cùng lúc và thử luân phiên theo kiểu round robin
Tôi cũng liên tục theo dõi chất lượng câu trả lời để về lâu dài chọn được mô hình phù hợp hơn với mục đích của mình
OpenWebUI mang lại một trải nghiệm sử dụng khá độc đáo
Với tư cách người dùng AMD 6700XT (12GB VRAM), sau khi thiết lập local ROCm thành công, tôi chạy Ollama với tăng tốc GPU rất ổn
Việc kết nối instance OpenWebUI chạy bằng Docker với local Ollama server cũng chỉ cần đặt một biến ENV là xong
Đây không phải môi trường production mà chỉ là môi trường thử nghiệm cá nhân, nhưng cho mục đích nói ở trên thì nó hoạt động rất tốt
Cũng nên biết là OpenWebUI gần đây đã đổi giấy phép nên không còn là mã nguồn mở nữa
Dòng Qwen3 (và cả R1 qwen3-8b distill) hiện đứng đầu về coding và suy luận logic
Tuy nhiên vì có nguồn gốc từ Trung Quốc nên bị kiểm duyệt mạnh ở các vấn đề chính trị
Nếu cần hiểu biết phổ thông toàn cầu và thông tin cập nhật hơn thì nên chọn Gemma3
Rất có thể chỉ sau một tháng, thông tin trong bài này đã lỗi thời, nên hãy xem benchmark mới nhất trên livebench.ai hoặc bảng xếp hạng aider.chat
Không chỉ mô hình mà cả tool, router, MCP, thư viện và SDK đều liên tục tiến hóa
Nếu tôi phát triển một mình và không có đồng nghiệp hay cộng đồng xung quanh để chia sẻ thông tin, tôi rất cần lời khuyên về cách tiếp thu thông tin và theo dõi xu hướng mới nhất
Nguồn thông tin tốt nhất là HuggingFace
Dòng Qwen nhìn chung đều ổn trên nhiều mặt, và tôi khuyên dùng mẫu Qwen/Qwen3-14B-GGUF Q4_K_M
Nó chỉ dùng khoảng 7-8GB VRAM nên khá nhẹ, và tôi khuyên dùng llama-server hoặc LM Studio
Llama 3.3 cũng là lựa chọn tốt
Devstral quá lớn nên hầu như chỉ có thể thử bản quantized
Gemma hay từ chối nhưng lại hữu ích cho một số mục đích cụ thể như Medgemma
Các mẫu Dolphin “Uncensored” của Eric Hartford và các mẫu abliterated phù hợp nếu bạn cần mô hình ít từ chối cho các việc như tạo trò đùa hoặc công việc bảo mật, quốc phòng (không nhất thiết cần cho sử dụng hàng ngày)
Với dtype bf16, có thể ước lượng dung lượng mô hình unquantized bằng số tham số x2
Nếu dùng mô hình quantized Q4_K_M (4-bit) thì nhu cầu VRAM sẽ bằng khoảng một nửa số tham số
Cũng nên tính thêm overhead như activation, nên tốt nhất hãy thử từ các mô hình nhỏ hơn khá nhiều so với mốc 16GB
llama-server hỗ trợ GUI và cả tùy chọn
-hfđể tải mô hìnhLM Studio cũng dễ cài đặt và quản lý mô hình
Nếu muốn phản hồi nhanh thì nên bật server một lần rồi để nhiều truy vấn dùng chung mô hình đó (nếu mỗi câu hỏi lại load lại mô hình thì sẽ chậm)
Với mốc 16GB, Mistral Small 3.1 bản Q4 quant hoặc Qwen3-14B bản FP8 đều chạy khá thoải mái
Tuy nhiên tùy mức dùng VRAM, nếu cần context length dài thì Qwen3-14B Q4 quant tuy hiệu năng kém hơn FP8 nhưng lại dư bộ nhớ hơn
Mistral Small hỗ trợ cả đầu vào hình ảnh, còn Qwen3 mạnh hơn về toán và lập trình
Không khuyến nghị hạ xuống thấp hơn Q4 vì hiệu quả sẽ giảm
Nếu mục tiêu là context dài thì Qwen3-8B Q4 quant sẽ hợp hơn, còn Qwen3-30B-A3 thì 16GB VRAM có lẽ hơi thiếu một chút (vì các mô hình nặng theo GGUF thường chiếm hơn 15GB)
Dense model (dùng toàn bộ tham số) có hiệu năng trên mỗi tham số tốt hơn sparse model (mô hình thưa), nhưng tốc độ chậm hơn; với GPU cỡ 5060 thì 14B là khá thoải mái
Nếu dùng kiến trúc Blackwell thì mô hình quantized bằng NVFP4 còn nhanh hơn FP8, dù chất lượng giảm rất nhẹ; nhưng Ollama chưa hỗ trợ nên cần dùng vLLM riêng
Các mô hình NVFP4 pre-quantized chưa được hỗ trợ rộng, nên khuyến nghị tự quantize bằng công cụ như llmcompressor
Tốt nhất là cứ chọn LLM mình muốn trước, rồi chỉ dùng các công cụ kiểu này khi cần tối ưu hiệu năng
Gần như không thể có một đáp án khách quan, rõ ràng tuyệt đối cho LLM; điều quan trọng nhất vẫn là tự thử nhiều mô hình mới nhất trên những công việc thật sự có ý nghĩa với bản thân
Tùy loại tác vụ mà chất lượng kết quả có thể khác biệt cực lớn
Tôi thường thắc mắc mọi người ước tính mức dùng VRAM như thế nào
Trong thông tin mô hình có thể tải như file gguf chẳng hạn, thường không ghi rõ nhu cầu VRAM/bộ nhớ nên khá bất tiện
Một cách rất gần đúng là coi số tham số (đơn vị B) tương đương với dung lượng bộ nhớ tính theo GB
Ví dụ theo mức quantization:
FP16 = 2 x 8GB = 16GB (mô hình 8B)
Q8 = 1 x 8GB, Q4 = 0.5 x 8GB = 4GB
Thực tế sẽ hơi khác một chút nhưng thường không lệch quá nhiều, và còn phải cộng thêm bộ nhớ cho context length v.v.
Nguyên lý là số lượng giá trị float x số bit của kiểu dữ liệu (4, 8, 16...)
Ngoài quantization, nếu muốn tính chính xác cả KV cache v.v. thì nên dùng trình tính VRAM