Chạy AI local trên Mac: 298GB model hay 14ms quyết định?

Bạn mở Hugging Face, thấy Mistral Large 4 đã mở weights, và định kéo nó về con MacBook đang mở sẵn. Vài phút sau bạn nhìn bảng dung lượng repo và hiểu rằng câu hỏi không phải "tải được không" mà là "chạy ở đâu cho đúng".

Hai con số trong cùng một ngày — một model nghìn tỷ tham số và một decision model 14 mili-giây trên Apple Silicon — đủ để chọn đúng lớp hạ tầng trước khi tốn băng thông.

Mistral Large 4: dung lượng là rào cản thật sự

Theo bài hướng dẫn tự host, bản open weights của Mistral Large 4 lên Hugging Face ngày 29/10/2026, giấy phép MIT có sửa đổi, ở hai định dạng FP8 và NVFP4 cùng các bản GGUF từ cộng đồng. Vẫn là model Mistral phục vụ qua API: khoảng 1,05 nghìn tỷ tham số tổng, ~49 tỷ active mỗi token, ngữ cảnh 1 triệu token.

Dung lượng trên đĩa, cộng từ danh sách file của từng repo ngày 02/11/2026:

Bản	Dung lượng
FP8 (chính thức)	~1.061 GB (hơn 1 TB)
NVFP4 (chính thức)	~610 GB
GGUF Q4_K_M	~635 GB
GGUF Q2_K	~381 GB
GGUF IQ2_XXS	~298 GB

Bản nhẹ nhất vẫn là 298 GB. Không laptop nào đưa con số đó vào bộ nhớ, nên "chạy local" ở đây nghĩa là một node nhiều GPU, không phải máy cá nhân.

Ba đường chạy, và ngưỡng để chọn đường thứ ba

Bài hướng dẫn liệt kê ba lựa chọn: gọi thẳng Mistral API với model id mistral-large-4 ở mức 0,70 USD cho 1 triệu input token (0,07 USD nếu cached, 2,10 USD output); dùng nhà cung cấp hosted như OpenRouter, endpoint của NVIDIA hay Microsoft Foundry; hoặc tự host weights bằng vLLM, SGLang, Transformers, llama.cpp.

Bài viết khuyên bắt đầu từ đường 1 hoặc 2, chỉ tự host khi có lý do cụ thể: dữ liệu không được rời mạng nội bộ, một bản fine-tune bạn phải sở hữu, hoặc khối lượng đủ giữ một node 8 GPU bận liên tục. Với phần lớn đội ở VN, ngưỡng đó chưa tới.

Một chi tiết dễ làm hỏng tích hợp cũ: bản phát hành đổi các mức reasoning thành low, medium, high, thay cho none trước đây. Nếu code của bạn còn gửi reasoning_effort: "none", bài viết lưu ý Transformers sẽ chạy nó như high — tức là âm thầm đốt token chứ không báo lỗi. Các con số benchmark kèm theo (Terminal-Bench 4.0 từ 28% lên 41%) đều do Mistral công bố, và bài viết ghi rõ chưa có bản tái lập độc lập tính đến 02/11.

Phần lớn quyết định trong pipeline không cần tới LLM

Ở đầu kia của phổ, tác giả laya-mlx lập luận rằng nhiều pipeline agent đang dùng LLM 8B trở lên chỉ để phân loại intent, kích hoạt function hay trả lời một câu hỏi đúng/sai. Dự án này chạy các typed decision model trên MLX — framework native của Apple — và tuyên bố mỗi quyết định mất 7–14 ms trên chip M3 Max, không phụ thuộc PyTorch, output có kiểu dữ liệu chặt thay vì JSON tự do, và chạy hoàn toàn offline. Đây là con số do chính tác giả công bố, chưa có kiểm chứng độc lập. Cài đặt gọn: pip install laya-mlx.

Về mặt kiến trúc, đây là lớp routing rẻ đặt trước LLM đắt: phân loại và chọn nhánh không cần sinh token từng chữ, phần sinh nội dung vẫn gọi API. Cách chia tầng này giữ dữ liệu nhạy cảm ở máy và cắt chi phí per-token cho phần lớn lượt gọi — với điều kiện bạn tự đo lại độ chính xác của lớp decision trên dữ liệu của mình.

Làm gì tiếp

Đếm tỷ lệ lượt gọi LLM trong hệ thống chỉ để ra một nhãn hay một boolean — đó là phần đẩy xuống on-device được ngay. Với Mistral Large 4, mặc định nên là API cho tới khi dữ liệu hoặc khối lượng đẩy bạn sang tự host. Và nếu còn chạy bản preview, sửa reasoning_effort trước khi hóa đơn token tháng này về.