Benchmark model Ollama trên máy của bạn: llama-bench, MLPerf Client và số liệu nào đáng tin

Nếu bạn đang tự đo hiệu năng ollama models trên PC cá nhân, câu hỏi quan trọng không chỉ là “model này chạy được bao nhiêu tokens/giây?”. Một bài benchmark đáng tin cần nói rõ đang đo giai đoạn nào, dùng định dạng model nào, backend nào, và số liệu đó có tính những phần như tokenization hay sampling hay không.

Với người dùng GearVN đang dựng Local AI tại nhà, cách đọc đúng là: dùng công cụ đo chuyên biệt để tách workload, ghi lại điều kiện chạy, sau đó so sánh trong cùng một môi trường. Bài viết này tập trung vào ba nhóm số liệu nên quan tâm: tokens/giây, time to first token và ảnh hưởng của lượng tử hoá.

Mục lục bài viết

1. Vì sao benchmark Ollama không nên chỉ nhìn một con số?

2. llama-bench: Công cụ gọn để tách đúng giai đoạn suy luận

3. MLPerf Client: Nhìn thêm TTFT và tính đáp ứng

4. GGUF và lượng tử hoá: Cùng model nhưng hiệu năng có thể rất khác

5. Các model mới làm benchmark càng cần ghi rõ phiên bản

6. Đừng quên benchmark trải nghiệm tích hợp thực tế

7. Bảng checklist khi tự benchmark ollama models

1. Vì sao benchmark Ollama không nên chỉ nhìn một con số?

Ollama thay đổi khá nhanh theo từng bản phát hành. Ví dụ, Ollama v0.32.3 ngày 23/07/2026 mở rộng hỗ trợ GPU sang CUDA trên Windows ARM64 và B200 qua CUDA 12, đồng thời bổ sung chat, thinking và tool calling cho Laguna 2.1. Đến v0.32.4 ngày 25/07/2026, Ollama 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%.

Ollama thay đổi liên tục theo từng bản phát hành

Sang tháng 8/2026, các bản phát hành tiếp tục có thay đổi đáng chú ý. 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 của /v1/chat/completions khớp OpenAI. Ollama v0.32.10 ngày 12/08/2026 ở trạng thái pre-release còn đổi mặc định repeat_penalty từ 1.1 xuống 1.0 cho các model không khai báo tham số này, và cải thiện prefill NVFP4 trên MLX khoảng 7–8% ở một số model.

Điều đó có nghĩa là hai bài test cùng một máy nhưng khác phiên bản Ollama, khác backend hoặc khác model file có thể cho kết quả khác nhau. Vì vậy, khi bạn ghi nhận kết quả, hãy ghi kèm phiên bản runtime, tên model, định dạng lượng tử hoá và chế độ đo.

2. llama-bench: Công cụ gọn để tách đúng giai đoạn suy luận

llama-bench là lựa chọn thực dụng khi bạn muốn đo hiệu năng theo cách có cấu trúc. 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 là 5 lần. Điểm rất quan trọng: phép đo của llama-bench không tính thời gian tokenization và sampling.

Ví dụ về syntax của llama-bench (Nguồn: st.)

Vì không tính tokenization và sampling, kết quả từ llama-bench nên được hiểu là hiệu năng lõi của phần suy luận trong điều kiện đo cụ thể, không phải toàn bộ trải nghiệm người dùng từ lúc bấm gửi prompt đến lúc nhận câu trả lời hoàn chỉnh.

Prompt processing, text generation và chế độ kết hợp

llama-bench tách hai chế độ đo có bản chất khác nhau. Chế độ prompt processing, thường được ghi là pp, mặc định đo 512 token prompt. Chế độ text generation, thường được ghi là tg, mặc định đo 128 token sinh ra. Ngoài ra còn có chế độ kết hợp pg.

Ví dụ về 2 chế độ đo của llama-bench (Nguồn: st.)

Đây là điểm nhiều người dễ bỏ qua khi so sánh ollama models. Một model có thể xử lý prompt dài nhanh nhưng sinh token mới không quá nhanh, hoặc ngược lại. Với tác vụ hỏi đáp tài liệu dài, prompt processing quan trọng hơn. Với chatbot trả lời dài, text generation lại ảnh hưởng rõ hơn đến cảm giác “máy đang gõ nhanh hay chậm”.

3. MLPerf Client: Nhìn thêm TTFT và tính đáp ứng

Nếu bạn muốn tiếp cận benchmark theo hướng chuẩn hoá hơn cho PC cá nhân, MLPerf Client v1.6 là một mốc đáng chú ý. Bản này phát hành ngày 06/04/2026 và đo workload LLM chạy cục bộ trên PC qua các backend gồm Windows ML, llama.cpp trên Windows và macOS, MLX với Metal, và llama.cpp với Metal.

Bản báo cáo của MLPerf Client v1.5 (Nguồn: Steam)

MLPerf Client không chỉ nhìn thông lượng mà còn báo tính đáp ứng. Trong đó, time to first token, hay TTFT, là thời gian chờ trước khi token đầu tiên xuất hiện; giá trị càng thấp càng tốt. Với trải nghiệm chat thực tế, TTFT thấp giúp người dùng cảm thấy model phản hồi nhanh hơn, ngay cả khi tốc độ sinh token sau đó chưa phải cao nhất.

Khi nào ưu tiên tokens/giây, khi nào ưu tiên TTFT?

• Chat ngắn, hỏi đáp nhanh: nên quan tâm TTFT vì độ trễ token đầu tiên ảnh hưởng trực tiếp đến cảm giác phản hồi.
• Sinh nội dung dài: nên quan tâm tốc độ text generation, vì phần lớn thời gian nằm ở quá trình sinh token sau token đầu tiên.
• Tóm tắt hoặc RAG với tài liệu dài: nên theo dõi prompt processing vì hệ thống phải nạp và xử lý nhiều token đầu vào.

• So sánh nhiều cấu hình: nên giữ nguyên prompt, số token sinh, phiên bản runtime, backend và model file để tránh so sánh lệch điều kiện.

4. GGUF và lượng tử hoá: Cùng model nhưng hiệu năng có thể rất khác

Với hệ sinh thái local AI, định dạng và mức lượng tử hoá ảnh hưởng lớn đến kết quả benchmark. 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.

GGUF định nghĩa nhiều họ lượng tử hoá, gồm nhóm legacy như F32, F16, Q4_0, Q4_1, Q5_0, Q5_1, Q8_0, Q8_1; nhóm K-series như Q2_K, Q3_K, Q4_K, Q5_K, Q6_K, Q8_K; nhóm IQ như IQ2_XXS, IQ3_XXS, IQ4_NL; cùng các định dạng BF16, MXFP4, TQ1_0 và TQ2_0. Các lựa chọn này cho phép đánh đổi dung lượng lấy độ chính xác.

Vì vậy, nếu bạn chỉ ghi “chạy model 8B” hay “chạy model 30B” thì chưa đủ. Một bài benchmark nên ghi rõ file GGUF đang dùng ở mức lượng tử hoá nào. Hai file cùng tên model nhưng khác lượng tử hoá có thể khác nhau về dung lượng, tốc độ và chất lượng đầu ra.

AWQ có phải là đáp án thay thế mọi phép đo?

AWQ là phương pháp lượng tử hoá trọng số có nhận biết activation, hỗ trợ INT3 và INT4 với activation 16-bit theo dạng W4A16. Repository của MIT Han Lab công bố AWQ 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ố đó để suy ra mọi model, mọi backend hoặc mọi máy đều sẽ nhanh tương tự. Khi tự benchmark tại nhà, hãy xem AWQ như một hướng tối ưu cần đo lại trong điều kiện của bạn, không phải một hệ số tăng tốc cố định.

5. Các model mới làm benchmark càng cần ghi rõ phiên bản

Ollama v0.32.9 ngày 11/08/2026 bổ sung NVIDIA Nemotron 3.5 Lightning, một model mixture-of-experts 30B với 3B tham số active, kèm hỗ trợ kiến trúc Nemotron 3. Muse Glimmer, model đa phương thức 30B của Meta được định vị cho agent workload, được Ollama hỗ trợ ban đầu 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.

Các mốc này hữu ích khi bạn đọc hoặc tự công bố kết quả benchmark. Nếu một model vừa được thêm hỗ trợ hoặc vừa được tối ưu trong runtime, kết quả của bản cũ và bản mới có thể không còn tương đương. Với model định vị cho agent workload như Muse Glimmer, ngữ cảnh sử dụng cũng có thể khác chatbot thông thường, nhất là với coding agent hoặc trợ lý cá nhân chạy dài.

6. Đừng quên benchmark trải nghiệm tích hợp thực tế

Benchmark lõi là cần thiết, nhưng một setup Local AI hoàn chỉnh còn có API, công cụ coding, RAG và agent. 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 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 sinh embedding từ một hoặc nhiều đoạn văn bản, đảm nhiệm phần truy hồi của một stack RAG chạy cục bộ.

Ollama cũng có nhóm endpoint quản trị model như GET /api/tags để liệt kê model đã có, GET /api/ps để xem model đang nạp trong bộ nhớ, cùng các endpoint POST /api/show, POST /api/pull, POST /api/create và DELETE /api/delete. Những phần này không thay thế benchmark tokens/giây, nhưng giúp bạn kiểm tra hệ thống có phù hợp để vận hành lâu dài hay không.

Coding agent và framework agent cũng cần được xem trong bối cảnh

Continue là coding agent phát hành dưới ba dạng: CLI @continuedev/cli trên npm, extension VS Code trên 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.

LangChain là framework xây dựng agent và ứng dụng LLM, cấp phép MIT, 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. Nếu bạn benchmark Ollama để dùng cho RAG hoặc agent, hãy đo thêm tác vụ đầu cuối như truy hồi, gọi tool và sinh câu trả lời, thay vì chỉ đo một prompt ngắn.

7. Bảng checklist khi tự benchmark ollama models

Kết luận: Số liệu đáng tin là số liệu có ngữ cảnh

Khi benchmark ollama models, tokens/giây là điểm khởi đầu tốt nhưng chưa đủ. Với llama-bench, hãy tách prompt processing và text generation, đồng thời nhớ rằng công cụ này không tính tokenization và sampling. Với MLPerf Client, hãy nhìn thêm TTFT để hiểu cảm giác phản hồi ban đầu. Với GGUF hoặc AWQ, hãy ghi rõ mức lượng tử hoá thay vì chỉ ghi kích thước model.

Cách làm an toàn nhất là đo nhiều lần, giữ nguyên điều kiện, ghi rõ phiên bản và đọc kết quả theo use case. Nếu mục tiêu là chatbot, ưu tiên TTFT và tốc độ sinh. Nếu mục tiêu là RAG, chú ý prompt processing và embedding. Nếu mục tiêu là agent hoặc coding assistant, hãy benchmark cả luồng tích hợp, vì hiệu năng thực tế không chỉ nằm ở một con số tokens/giây.