Model AI local kiến trúc MoE 30B: Tham số active nói lên điều gì và không nói lên điều gì?
Khi chọn ai local model, con số “30B” trên tên model rất dễ tạo cảm giác đây là một model khổng lồ luôn phải kích hoạt toàn bộ 30 tỷ tham số mỗi lần sinh token. Với kiến trúc mixture-of-experts, cách đọc này chưa đủ. Điểm đáng chú ý trong đợt cập nhật Ollama v0.32.9 ngày 11/08/2026 là NVIDIA Nemotron 3.5 Lightning được bổ sung như một model mixture-of-experts 30B nhưng chỉ có 3B tham số active, đi kèm hỗ trợ kiến trúc Nemotron 3.
Nói ngắn gọn: tham số active cho biết lượng tham số được kích hoạt trong một bước suy luận, không phải toàn bộ quy mô tham số mà model đang sở hữu. Đây là dữ kiện hữu ích để đánh giá kỳ vọng hiệu năng của model MoE, nhưng GearVN không khuyên dùng nó như tiêu chí duy nhất để quyết định model có chạy tốt trên máy của bạn hay không.
Mục lục bài viết1. Tham số active nói lên điều gì?2. Điều tham số active không nói lên3. Nên đo model MoE bằng chỉ số nào?4. Lượng tử hoá quan trọng không kém kiến trúc5. Những tín hiệu mới từ hệ sinh thái Ollama và llama.cpp6. Chọn AI local model: Nên nhìn theo checklist nào?
1. Tham số active nói lên điều gì?
Với model MoE, tổng tham số và tham số active trả lời hai câu hỏi khác nhau. Tổng tham số cho biết quy mô tổng thể của hệ thống chuyên gia. Tham số active cho biết tại một thời điểm suy luận, model chỉ dùng một phần chuyên gia liên quan để xử lý token. Vì vậy, một model 30B với 3B tham số active không nên được hiểu giống một model dense 30B luôn dùng toàn bộ trọng số cho mọi bước sinh.
Minh họa model AI local kiến trúc MoE 30B
Trong bối cảnh local AI, thông tin này giúp người dùng có cơ sở ban đầu để đặt kỳ vọng: model MoE có thể được thiết kế để giảm lượng tính toán kích hoạt trong mỗi bước so với việc dùng toàn bộ tham số. Tuy nhiên, nó không tự động chứng minh model sẽ nhanh hơn trên mọi phần cứng, không tự nói lên chất lượng câu trả lời và cũng không đủ để suy ra mức VRAM hoặc RAM cần thiết.
2. Điều tham số active không nói lên
Tham số active không thay thế benchmark thực tế. Dossier hiện có không cung cấp số tokens/giây tuyệt đối cho bất kỳ cấu hình máy cụ thể nào, cũng không có điểm chất lượng như MMLU, GPQA hay SWE-bench cho Nemotron 3.5 Lightning, Muse Glimmer, Qwen3.5 hoặc Laguna 2.1. Vì vậy, người chọn model không nên kết luận chỉ từ nhãn “30B/3B active”.
Ngoài ra, số tham số cũng không cho biết điều kiện triển khai thực tế. Không có dữ liệu trong nguồn để suy ra yêu cầu VRAM, RAM tối thiểu, giá phần cứng hay cấu hình khuyến nghị cho các model được nhắc đến. Đây là lý do khi tư vấn máy chạy AI local, GearVN luôn tách riêng ba lớp: kiến trúc model, định dạng/lượng tử hoá và số đo trên workload thật.
3. Nên đo model MoE bằng chỉ số nào?
Với người đang tự chọn model để chạy cục bộ, benchmark cần phản ánh đúng trải nghiệm sử dụng. Tài liệu llama-bench cho biết công cụ này báo kết quả theo tokens/giây, kèm trung bình và độ lệch chuẩn qua nhiều lần lặp, mặc định 5 lần. Điểm quan trọng là phép đo này không tính thời gian tokenization và sampling, nên cần hiểu đúng phạm vi khi so sánh kết quả.
llama-bench cũng tách hai chế độ đo khác bản chất: prompt processing với nhãn pp, mặc định 512 token, và text generation với nhãn tg, mặc định 128 token. Chế độ kết hợp pg tồn tại để đo cả hai pha. Nếu bạn dùng model cho tóm tắt tài liệu dài, pha xử lý prompt rất quan trọng. Nếu bạn dùng cho chat dài hơi, tốc độ sinh token sẽ ảnh hưởng rõ hơn đến cảm giác phản hồi.
Chế độ đo prompt processing của llama-bench (Nguồn: st.)
Ở cấp benchmark chuẩn hoá hơn, MLPerf Client v1.6 phát hành ngày 06/04/2026 đo workload LLM chạy cục bộ trên PC qua nhiều backend như Windows ML, llama.cpp trên Windows và macOS, MLX với Metal, và llama.cpp với Metal. Bộ đo này báo cả tính đáp ứng lẫn thông lượng; trong đó time to first token là thời gian chờ trước token đầu tiên, giá trị thấp hơn sẽ tốt hơn.
4. Lượng tử hoá quan trọng không kém kiến trúc
Khi triển khai local, định dạng và lượng tử hoá có thể thay đổi đáng kể trải nghiệm. GGUF được thiết kế để triển khai một file duy nhất, hỗ trợ nạp bằng mmap và tự chứa đầy đủ thông tin cần thiết để load model, bao gồm cả tokenizer. Điều này khiến GGUF trở thành một phần quan trọng trong hệ sinh thái chạy model cục bộ.
GGUF cũng định nghĩa nhiều họ lượng tử hoá khác nhau, từ nhóm legacy như F32, F16, Q4_0, Q5_0, Q8_0; nhóm K-series như Q2_K, Q4_K, Q6_K; đến nhóm IQ và các định dạng như BF16, MXFP4, TQ1_0, TQ2_0. Về bản chất, lượng tử hoá là bài toán đánh đổi dung lượng lấy độ chính xác, nên cùng một model nhưng khác bản lượng tử hoá có thể cho trải nghiệm khác nhau.
Minh họa AWQ và GGUF
AWQ là một hướng khác: phương pháp lượng tử hoá trọng số có nhận biết activation, hỗ trợ INT3/INT4 với activation 16-bit, thường được mô tả là W4A16. Repo AWQ công bố nhanh hơn FP16 khoảng 2,7 lần trên RTX 4090 và 2,9 lần trên Jetson Orin với LLaMA-3-8B; công trình này đạt Best Paper Award tại MLSys 2024. Tuy nhiên, không nên lấy con số đó để so sánh trực tiếp với GGUF nếu không cùng điều kiện đo.
5. Những tín hiệu mới từ hệ sinh thái Ollama và llama.cpp
Đợt release tháng 8/2026 cho thấy hệ sinh thái local AI đang thay đổi nhanh. Ngoài Nemotron 3.5 Lightning trong Ollama v0.32.9, Ollama v0.32.6 ngày 04/08/2026 cải thiện hiệu năng GPU Apple cho Qwen3.5 bằng speculative decoding qua MTP head tự động, đồng thời chuẩn hoá định dạng streaming /v1/chat/completions khớp OpenAI. Cũng trong bản này, tính năng sinh ảnh thử nghiệm bị gỡ tạm thời.
Ollama v0.32.4 ngày 25/07/2026 tối ưu decoding cho Qwen3 MoE với expert ở mức lượng tử hoá hỗn hợp, cải thiện khoảng 4–9%. Đây là ví dụ tốt cho thấy hiệu năng MoE không chỉ đến từ số tham số active, mà còn phụ thuộc runtime, cách decode và cách triển khai expert đã lượng tử hoá.
Ở hướng đa phương thức, Muse Glimmer là model 30B của Meta được định vị cho agent workload. Ollama hỗ trợ ban đầu model này qua MLX engine trên Apple Silicon ở v0.32.7 ngày 10/08/2026, sau đó mở rộng ra mọi nền tảng gồm NVIDIA và AMD ở v0.32.8 cùng ngày. Ollama cũng định vị Muse Glimmer cho coding agent và trợ lý cá nhân chạy dài.
Phía llama.cpp, bản b10369 ngày 12/08/2026 tích hợp Pocket-TTS cho sinh audio, với thời gian sinh mỗi frame giảm khoảng 80% trên CUDA và khoảng 50% trên CPU. Bản b10356 ngày 11/08/2026 nâng hỗ trợ ROCm từ 7.2.1 lên 7.14 và là bản production đầu tiên dùng hệ thống build TheRock. Những cập nhật này cho thấy khả năng local AI không chỉ dừng ở chat văn bản, mà đang mở rộng sang audio và hỗ trợ phần cứng đa dạng hơn.
6. Chọn AI local model: Nên nhìn theo checklist nào?
6.1. Xác định workload trước khi nhìn tên model
Nếu nhu cầu là chat cá nhân, tóm tắt tài liệu, coding agent hay RAG nội bộ, cách đánh giá sẽ khác nhau. Model MoE 30B với 3B active có thể hấp dẫn, nhưng workload mới là thứ quyết định bạn cần ưu tiên tốc độ sinh token, thời gian phản hồi đầu tiên, độ dài context, khả năng gọi công cụ hay chất lượng lập luận.
6.2. Đo riêng prompt processing và text generation
Với tài liệu dài, hãy quan tâm prompt processing. Với hội thoại và trợ lý cá nhân, hãy quan tâm text generation và time to first token. Việc chỉ nhìn một con số tokens/giây tổng quát có thể làm sai lệch kỳ vọng, nhất là khi các công cụ đo không tính cùng một thành phần trong pipeline.
6.3. Kiểm tra định dạng và bản lượng tử hoá
Cùng một model, bản F16, Q8, Q4 hoặc các biến thể K-series/IQ có thể khác nhau về dung lượng, tốc độ và độ chính xác. Khi so sánh model local, hãy ghi rõ định dạng, mức lượng tử hoá, backend chạy và phần cứng dùng để đo.
6.4. Kiểm tra bề mặt tích hợp
Ollama phục vụ REST API cục bộ mặc định tại http://localhost:11434, với các endpoint như POST /api/generate, POST /api/chat và POST /api/embed. POST /api/chat hỗ trợ tool calling qua tham số tools chứa định nghĩa hàm; model có thể sinh tool call có cấu trúc và kết quả được đưa lại vào lịch sử hội thoại. POST /api/embed tạo embedding từ một hoặc nhiều đoạn văn bản, phù hợp cho phần truy hồi của stack RAG chạy cục bộ.
Ollama cũng có nhóm endpoint quản trị model gồm GET /api/tags để liệt kê model đã có, GET /api/ps để xem model đang nạp trong bộ nhớ, cùng POST /api/show, POST /api/pull, POST /api/create và DELETE /api/delete. Với người dùng muốn dựng workflow nghiêm túc, những endpoint này quan trọng không kém tốc độ model.
6.5. Cân nhắc công cụ agent và framework
Continue là coding agent phát hành dưới ba dạng: CLI @continuedev/cli trên npm, extension VS Code qua Marketplace và OpenVSX, cùng plugin JetBrains. Tuy nhiên, repository continuedev/continue hiện ở trạng thái read-only và không còn được bảo trì tích cực; dự án cấp phép Apache 2.0. Với framework, LangChain là lựa chọn MIT license để xây dựng agent và ứng dụng LLM, cung cấp giao diện chuẩn cho model, embedding, vector store và retriever, kèm LangGraph cho luồng agent có kiểm soát.
Kết luận: Tham số active là tín hiệu, không phải câu trả lời cuối
Với model AI local kiến trúc MoE 30B, con số 3B tham số active là một tín hiệu đáng chú ý: nó giúp hiểu rằng model không kích hoạt toàn bộ 30B tham số trong mỗi bước suy luận. Nhưng để chọn model đúng, bạn vẫn cần đo theo workload, phân biệt prompt processing và text generation, kiểm tra time to first token, định dạng lượng tử hoá, backend runtime và bề mặt tích hợp.
Nếu đang chọn model cho máy cá nhân hoặc workstation chạy local AI, cách tiếp cận an toàn là: đừng chỉ hỏi “Model này bao nhiêu B?”, mà hãy hỏi “Model này active bao nhiêu, chạy bằng backend nào, lượng tử hoá ra sao, đo pp/tg thế nào và có tích hợp được vào workflow của mình không?”. Đó mới là cách đọc đúng khi thị trường local AI chuyển nhanh sang MoE, agent workload và các runtime tối ưu theo phần cứng.
