- Gemma 4 được chạy trong môi trường Codex CLI cục bộ thay vì đám mây để kiểm chứng hiệu năng gọi công cụ và độ ổn định, qua đó xác nhận lợi thế về chi phí và quyền riêng tư so với GPT-5.4
- Trên Mac (M4 Pro) 24GB với 26B MoE và NVIDIA GB10 128GB với 31B Dense, cùng thực hiện một tác vụ sinh mã giống nhau bằng llama.cpp và Ollama, rồi so sánh hiệu năng theo khác biệt cấu hình
- Tỷ lệ gọi công cụ thành công tăng từ 6,6% lên 86,4%, cho thấy mô hình cục bộ đã có tính thực dụng; trong môi trường GB10 còn đạt được việc sinh mã hoàn chỉnh
- Mac cho tốc độ sinh token nhanh hơn 5,1 lần, nhưng do giới hạn bộ nhớ và thiết lập lượng tử hóa nên cần thử lại nhiều lần, trong khi GB10 chậm hơn nhưng thành công ngay từ lần đầu
- Kết quả cho thấy mô hình cục bộ cũng có thể sinh mã ở mức đủ dùng trong công việc thực tế, và khuyến nghị một cách tiếp cận lai: xử lý cục bộ cho nhu cầu riêng tư, còn tác vụ phức tạp thì chuyển lên đám mây
Động lực chuyển sang mô hình cục bộ
- Vấn đề chi phí: chạy Codex CLI nhiều phiên mỗi ngày, đôi khi song song, khiến phí API cộng dồn
- Yêu cầu quyền riêng tư: một số codebase không được phép gửi lên máy chủ bên ngoài
- Cần đảm bảo độ ổn định: API đám mây có rủi ro throttling, sự cố, hoặc thay đổi giá
- Lý do trước đây chưa thử mô hình cục bộ là vì không hỗ trợ gọi công cụ (tool calling), trong khi giá trị cốt lõi của Codex CLI nằm ở chỗ mô hình có thể đọc file, viết mã, chạy test và áp dụng patch
- Thế hệ Gemma trước đây chỉ đạt 6,6% trong benchmark gọi hàm tau2-bench (thất bại 93/100 lần), nhưng Gemma 4 31B đã nhảy lên 86,4%, đủ để đáng thử nghiệm
Quá trình thiết lập trên Mac
- Bắt đầu với Ollama, nhưng ở v0.20.3 xuất hiện lỗi streaming của Gemma 4: phản hồi gọi công cụ bị định tuyến sai sang reasoning output thay vì mảng
tool_calls
- Khi dùng Gemma 4 trên Apple Silicon, prompt dài khoảng hơn 500 token sẽ bị Flash Attention freeze; prompt hệ thống của Codex CLI dài khoảng 27.000 token nên thực tế không thể dùng
- Chuyển sang llama.cpp, cài bằng Homebrew, và lệnh chạy server cần 6 cờ quan trọng
-np 1: giới hạn 1 slot; nhiều slot sẽ làm bộ nhớ KV cache tăng theo bội số-ctk q8_0 -ctv q8_0: lượng tử hóa KV cache, giảm từ 940MB xuống 499MB--jinja: bắt buộc cho template gọi công cụ của Gemma 4- Cần chỉ định trực tiếp đường dẫn GGUF trong
-m; nếu dùng cờ -hf sẽ tự động tải vision projector 1,1GB và gây crash do OOM
- Trong cấu hình Codex CLI, bắt buộc đặt
web_search = "disabled", vì Codex CLI sẽ gửi kiểu công cụ web_search_preview mà llama.cpp từ chối
Quá trình thiết lập trên GB10
- vLLM 0.19.0 được biên dịch dựa trên PyTorch 2.10.0, nhưng PyTorch có hỗ trợ CUDA cho aarch64 Blackwell (compute capability sm_121) chỉ có ở 2.11.0+cu128, nên xảy ra lệch ABI và phát sinh
ImportError
- Khi build llama.cpp từ mã nguồn với CUDA, việc biên dịch và benchmark đều qua, nhưng llama.cpp lại từ chối kiểu công cụ không phải hàm mà Codex CLI gửi qua
wire_api = "responses"
- Thành công với Ollama v0.20.5; lỗi streaming gặp trên Apple Silicon không tái hiện trên NVIDIA
- Chạy
ollama pull gemma4:31b, sau đó forward cổng 11434 về Mac qua SSH tunnel (vì chế độ --oss của Codex CLI chỉ kiểm tra localhost)
- Dùng
codex --oss -m gemma4:31b, cả sinh văn bản lẫn gọi công cụ đều hoạt động ngay từ lần đầu
- Thiết lập trên Mac mất gần như cả buổi chiều, còn GB10 mất khoảng 1 giờ, tính cả thời gian chờ tải mô hình
Kết quả benchmark
- Cả ba cấu hình đều nhận cùng một tác vụ: dùng
codex exec --full-auto để viết hàm Python parse_csv_summary, có xử lý lỗi, viết test và chạy test
- GPT-5.4 (đám mây): sinh mã có type hint, exception chaining hợp lý, nhận diện kiểu boolean, helper function gọn gàng; 5 test qua ngay lần đầu, hoàn tất trong 65 giây, không cần dọn dẹp thêm
- GB10 31B Dense: không có type hint hay nhận diện boolean, nhưng xử lý lỗi chắc chắn, không có dead code; qua 5 test ngay lần đầu với 3 lần gọi công cụ, mất 7 phút
- Mac 26B MoE: còn sót dead code trong phần triển khai; viết vòng lặp suy luận kiểu rồi bỏ dở, sau đó viết lại phía dưới với chú thích 'Actually, let's simplify'; cần 5 lần thử để viết xong file test
- Mỗi lần lại phát sinh lỗi heredoc khác nhau:
filerypt → file_path, encoding=' 'utf-8' (chèn khoảng trắng), fileint(file_path) v.v.
- Tác vụ mà GB10 hoàn tất trong 3 lần gọi công cụ thì Mac cần tới 10 lần
- Kết quả này là trong môi trường Codex CLI
Q4_K_M trên máy 24GB, không phải kết luận mang tính phổ quát cho toàn bộ Gemma 4 trên Apple Silicon
Phân tích tốc độ: vì sao Mac nhanh hơn dự kiến
- Đo bằng llama-bench ở cùng độ dài ngữ cảnh, Mac có tốc độ sinh token nhanh hơn 5,1 lần so với GB10
- Cả hai máy đều có băng thông bộ nhớ 273 GB/s LPDDR5X, nhưng sinh token là tác vụ bị giới hạn bởi băng thông bộ nhớ
- 31B Dense đọc toàn bộ 31,2 tỷ tham số cho mỗi token (khoảng 17,4GB)
- 26B MoE chỉ kích hoạt 3,8 tỷ tham số mỗi token (khoảng 1,9GB)
- Với cùng băng thông, Mac đạt 52 tok/s, còn GB10 đạt 10 tok/s
- Tốc độ xử lý prompt cũng tốt hơn dự đoán: ở ngữ cảnh 8K, Mac đạt 531 tok/s so với GB10 548 tok/s; kích hoạt thưa của MoE cũng mang lại lợi thế cho xử lý prompt
Bài học chính: tỷ lệ thành công ngay lần đầu quan trọng hơn tốc độ token
- Mac nhanh hơn 5,1 lần về sinh token, nhưng thời gian hoàn tất cuối cùng chỉ rút ngắn 30% (4 phút 42 giây so với 6 phút 59 giây)
- Nguyên nhân chênh lệch thời gian là thử lại: 10 lần gọi công cụ so với 3, 5 lần thất bại khi viết test, và dead code mà mô hình không dọn
- Mô hình đám mây chứng minh điều này còn rõ hơn nữa: nhanh nhất, dùng ít token nhất, không cần pass sửa lỗi, hoàn tất 5/5 trong 65 giây
- Tuy vậy, mô hình cục bộ vẫn thực dụng, vì cả hai máy đều sinh được mã chạy được và qua test
- Khoảng cách chất lượng từ Gemma 3 (gọi công cụ 6,6%) lên Gemma 4 (86,4%) là bước ngoặt then chốt; sự chuyển dịch từ “không dùng được” sang “dùng được” chính là điểm khiến agentic coding cục bộ trở nên thực tế
- Lưu ý về kết quả trên Mac:
Q4_K_M là mức lượng tử hóa cao nhất có thể vừa trong bộ nhớ máy 24GB; nếu chạy lại trên Apple Silicon có nhiều bộ nhớ hơn với mức lượng tử hóa cao hơn thì kết quả có thể khác
- Có thể áp dụng cách tiếp cận lai: dùng
codex --profile local cho tác vụ lặp lại và nhạy cảm về quyền riêng tư, còn tác vụ phức tạp thì dùng cấu hình đám mây mặc định; hệ thống profile của Codex CLI cho phép chuyển đổi chỉ với một cờ
Mẹo thực dụng khi thiết lập
- Apple Silicon: Ollama không dùng được với Gemma 4; khuyến nghị llama.cpp +
--jinja
- Trong profile Codex CLI đặt
web_search = "disabled"
- Chỉ định trực tiếp đường dẫn GGUF bằng
-m, không dùng -hf
- Đặt ngữ cảnh 32.768 (prompt hệ thống của Codex CLI cần tối thiểu 27.000 token)
- Lượng tử hóa KV cache:
-ctk q8_0 -ctv q8_0
- NVIDIA GB10: Ollama v0.20.5 là con đường đầu tiên hoạt động ổn định; dùng
codex --oss -m gemma4:31b, nếu là máy từ xa thì tunnel cổng 11434 qua SSH
- Trong cấu hình provider, cần đặt
stream_idle_timeout_ms tối thiểu 1.800.000, vì trên Mac một chu kỳ gọi công cụ đơn lẻ mất 1 phút 39 giây, khiến phiên bị đóng nếu dùng timeout mặc định
- Khuyến nghị ghim phiên bản llama.cpp; đã có báo cáo giảm tốc 3,3 lần giữa các bản build, khiến benchmark có thể thay đổi chỉ sau một đêm
6 bình luận
Tôi đã thử vận hành Gemma4-31B trong công ty với 2 card H100 thì thấy rằng
Nhìn chung, nếu muốn một mô hình nhỏ gọn và phản hồi nhanh thì Gemma4 có lẽ là đủ. Tôi đã chuyển từ GPT-OSS-120B → Qwen3.5-35B-A3B, rồi giờ ổn định với Gemma4-31B và thấy khá hài lòng. Có lẽ tôi sẽ tiếp tục dùng nó.
Trời, không dùng được tìm kiếm web à! Cấu hình cả searxng rồi mà vẫn không dùng được sao?
https://github.com/ysm-dev/skills/blob/main/skills/web-search/SKILL.md
Hãy thử dùng cái này thay thế skill đó nhé hehe
Mình cũng muốn kiểm tra xem tiếng Hàn có hoạt động tốt không.
Ý kiến trên Hacker News
Gemma 4 26B cho thấy hiệu năng thực sự vượt trội trong số các mô hình có quy mô tham số tương đương
Trong benchmark nội bộ, nó đạt điểm gần với GPT 5.2 và Gemini 3 Pro Preview, nhưng lại yếu ở mảng coding theo kiểu agent và ra quyết định ngoài lập trình
Điểm số giảm ở khả năng dùng tool, cải thiện lặp, quản lý ngữ cảnh lớn, và thậm chí hiệu năng còn thấp hơn trong các tình huống bắt buộc phải dùng tool
Có vẻ như nó đã bị overfit vào các harness hoặc benchmark phổ biến. Dù vậy, tốc độ trên Macbook dòng M vẫn rất ấn tượng
Có thể xem benchmark tại gertlabs.com
Bài toán là “hãy triển khai một bộ tính toán bin fitting 1 chiều trong một trang web duy nhất”; Qwen3.5, Nematron, Step 3.5, gpt-oss đều vượt qua nhưng Gemma thì không
Tuy nhiên trên M5 của tôi, nó mắc các lỗi lập trình đơn giản thường xuyên hơn GPT-OSS. Dù vậy, tổng thể vẫn ở mức khá sát
Có người nói kết quả “chất lượng mô hình quan trọng hơn tốc độ token” là điều đáng ngạc nhiên
Thực ra nghe khá hiển nhiên. Thay vì giới hạn context ở 32k, cũng có thể offload phép toán MoE sang CPU bằng tùy chọn
--cpu-moeNếu chỉ có tốc độ token nhanh thì cuối cùng chỉ khiến ‘AI slop codebase’ bùng nổ
Hiện tôi đang chạy
google/gemma-4-26b-a4btrên M3 Ultra (48GB RAM) với LM Studio và OpencodeTôi phải tăng context lên 65536 nhưng nó hoạt động tốt. Cũng tích hợp dễ dàng với Zed và ACP
Chủ yếu tôi dùng cho review code đơn giản hoặc sinh mã frontend
Prompt hệ thống và overhead của tool đều dưới 2k token nên độ trễ prefill ngắn hơn nhiều
Tốc độ khoảng 100t/s nên gần như tức thì, và tôi ngày càng ít dùng Claude Code hơn
Dùng như chatbot thì ổn, nhưng không phù hợp để tích hợp XCode
Hiện tại tôi đang tận dụng 1500 request miễn phí mỗi ngày qua Google API
Trước khi cập nhật LM Studio 0.4.11+1 thì tool calling không hoạt động, nhưng giờ cả Codex lẫn Opencode đều chạy tốt
Câu “mô hình local không thể gọi tool” là sai
Tôi đã gọi tool ở local từ 2 năm trước rồi, và chuyện Gemma3 chỉ có tỷ lệ thành công 7% trong tool calling là vô lý
Ngay cả Llama3.3 cũng đạt ít nhất 75%
Những mô hình bị lượng tử hóa quá mạnh như Gemma 4 gguf Q4 (16GB) sẽ giảm chất lượng rất nhiều
Nếu có phần cứng GB10 thì tôi khuyên dùng thiết lập spark-vllm-docker hoặc bản tối ưu Qwen 3.5 122B A10B. Khoảng 50tk/s nên cũng khá nhanh
Tôi đã nâng cấp từ M4 Pro (24GB) lên M5 Pro (48GB), và cùng một Gemma 4 MoE (Q4) mà tốc độ t/s nhanh hơn 8 lần
Tốc độ nạp từ đĩa vào bộ nhớ cũng tăng gấp 2
Nên kiểm tra xem bạn có đang dùng bản MLX hay không. Bản lượng tử hóa cộng đồng của mlx-lm gần đây đã được sửa
Tôi thấy 16GB trên Macbook M1 là khá đuối, nhưng trên AMD Framework 13 với 64GB RAM thì chỉ chạy CPU thôi cũng đã đủ nhanh
Tính năng prompt cache rất hữu ích khi chèn các system prompt lớn
Có người đề xuất một ý tưởng harness: chạy phần cứng local 24/7 để tự động hóa thí nghiệm với các mô hình như Gemma 4, còn các quyết định lớn thì giao cho Claude Opus
Mô hình local sẽ thực hiện các thử nghiệm nhỏ và POC, rồi khi bị kẹt sẽ nhờ Opus hỗ trợ
Làm vậy sẽ giúp kiểm soát hoàn toàn prompt caching nên chi phí gần như bằng không
Có thể tham khảo video demo và kho pi-model-switch
Với tác vụ lập trình, lượng tử hóa dưới Q6_K là không có nhiều ý nghĩa
Mức lượng tử hóa thấp hơn sẽ khiến tỷ lệ lỗi code tăng vọt
Nếu bộ nhớ cho phép thì nên dùng mức lượng tử hóa cao nhất có thể
Tôi muốn thấy so sánh chất lượng theo từng kiểu lượng tử hóa như Q4_K_M, Q8_0, Q6_K, v.v. Có lẽ sẽ hữu ích hơn các con số tok/s đơn thuần
Tôi tò mò về so sánh giữa Qwen3.5 và Gemma 4
Đặc biệt là mô hình Qwen3.5-27B-Claude-4.6-Opus vốn tối ưu cho tool calling và đã được tải xuống hơn 500 nghìn lần
Mô hình Qwen thường xuyên cần sửa lỗi trong lúc orchestration, làm giảm năng suất
Tôi chạy bằng trọng số cho Ollama
Bản mới nhất là Qwopus3.5-27B-v3
Tôi đã dùng Gemma 4 vài ngày, thấy nó nhanh và thông minh nhưng vấn đề dùng tool vẫn còn
Giới hạn về trí tuệ chứ không phải tốc độ mới là thứ làm năng suất bị bó hẹp. Nó khá hay rơi vào vòng lặp
Sẽ rất hay nếu có thể phát hiện những tình huống như vậy và “cầu cứu” một mô hình thông minh hơn
Giờ tôi làm việc giống một điều phối viên agent hơn là coder. Vai trò là quản lý nhiều agent chạy song song
chat_template.jinjavàtokenizer_config.jsoncủa gemma-4-31B-itHọ nói đã sửa các vấn đề liên quan đến tool calling, nên tốt nhất là cập nhật mô hình
Việc cấu hình local LLM bằng ollama thì khá dễ, nhưng người ta nói khả năng gọi công cụ bị thất bại khá cao tùy theo từng mô hình mã nguồn mở. Nguyên nhân được cho là do các quy định lỏng lẻo bên trong ollama cùng với vấn đề parser gọi công cụ theo từng mô hình chồng chéo với nhau.
Điểm cốt lõi nhất của Local LLM rốt cuộc vẫn là để chạy được các mô hình cỡ trung đến lớn thì cần phần cứng đắt tiền. MAC Studio bản 32GB vào khoảng hơn 30 triệu won, còn GB10 thì khoảng 50~60 triệu won, nên để cá nhân mua về cho mục đích sở thích(?) thì khá áp lực. Với Local LLM thì chỉ có thể dùng mô hình nhỏ, còn mô hình cỡ trung đến lớn thì ngoài Cloud ra hầu như không có lựa chọn nào khác.