Máy dev có nên thành bãi chạy model?

Máy dev có nên thành bãi chạy model?

Ollama MLX nhanh hơn trên Apple Silicon, nhưng quyết định thật không phải “có chạy được không” mà là workload nào đáng kéo về máy dev.

Có một câu hỏi mình thấy nhiều team bắt đầu hỏi lại, nhất là khi MacBook trong công ty ngày càng mạnh: nếu model local đã nhanh hơn, liệu có nên kéo một phần AI workload khỏi cloud về máy dev không?

Câu trả lời ngắn: có thể. Nhưng nếu bạn quyết định chỉ vì thấy benchmark đẹp hoặc một release note nói “nhanh hơn”, rất dễ biến máy dev thành một khu rừng trồng dày đặc: cây nào cũng sống, nhưng ánh sáng không tới được tầng dưới.

Điểm đáng bàn trong cập nhật MLX của Ollama không nằm ở chuyện “Apple Silicon chạy LLM ngon hơn”. Cái đó ai dùng local model một thời gian cũng cảm được. Điểm đáng bàn là: local inference đang bớt giống đồ chơi demo và bắt đầu có vai trò rõ hơn trong kiến trúc AI của team builder.

Sơ đồ minh họa cho bài Máy dev có nên thành bãi chạy model?

Sơ đồ tóm tắt ý chính của bài viết.

Thứ đang diễn ra: local không còn chỉ là chỗ test prompt

Ollama cập nhật MLX engine để tận dụng Apple Silicon tốt hơn: dùng unified memory — vùng nhớ dùng chung giữa CPU và GPU — cùng MLX — framework machine learning tối ưu cho Apple — và backend Metal — lớp tăng tốc GPU của Apple. Kết quả họ công bố là model phản hồi nhanh hơn, dùng ít memory hơn, và có chất lượng tốt hơn trong một số cấu hình.

Phần thú vị hơn là hỗ trợ NVFP4. Đây là một định dạng 4-bit được tối ưu theo model, nhằm giữ chất lượng tốt hơn so với một số kiểu quantization — nén trọng số model để giảm memory và tăng tốc — phổ biến. Theo Ollama, với Gemma 4 12B, NVFP4 giảm khoảng một nửa mức mất chất lượng so với q4_K_M khi so với bf16, trong phép đo perplexity mà họ đưa ra.

Ngoài ra, Ollama nói engine MLX mới nhanh hơn tới 20% nhờ fuse một số operation vào Metal kernel qua JIT compiler của MLX, và tối ưu sampling chạy trên GPU. Cùng lúc, bản Ollama 0.30 cũng cải thiện đường GGUF qua llama.cpp, hỗ trợ rộng hơn cho NVIDIA, Vulkan, AMD, Intel và nhiều model GGUF hơn.

Nói thẳng ra thì: hệ sinh thái local model đang tách thành hai tầng tán khá rõ. Một tầng tối ưu sâu cho Apple Silicon qua MLX. Một tầng rộng hơn qua GGUF và llama.cpp để chạy được trên nhiều phần cứng.

Mổ xẻ: câu hỏi không phải “nhanh không?”, mà là “nhanh ở đoạn nào?”

Nếu bạn build agent, phần tốn tiền và tốn thời gian thường không chỉ là generate câu trả lời. Agent workload có một điểm rất khó chịu: mỗi lần gọi tool, request mới lại phải gửi lại transcript, system prompt, tool definitions, file đã đọc, kết quả trung gian… Tức là model phải xử lý lại nhiều context lặp.

Ở đây xuất hiện hai khái niệm đáng chú ý.

Prefix caching là cache phần đầu prompt đã xử lý, để model không phải nhai lại từ đầu mỗi lần. Nó giống như trong rừng, một con đường mòn đã được dẫm sẵn: đi lại nhanh hơn, miễn là bạn vẫn đi cùng hướng.

Nhưng agent thật hiếm khi đi thẳng lâu. Nó rẽ sang subagent, quay lại session cũ, mở task song song, nhảy qua file khác. Vì vậy Ollama nhắc tới snapshot — lưu trạng thái model tại các điểm quan trọng để resume về sau. Nếu prefix caching chỉ hợp với dòng chảy tuyến tính, snapshot hợp hơn với workload có nhiều nhánh.

Đây là phần nhiều team dễ hiểu sai: local model nhanh hơn không tự động làm agent production tốt hơn. Nó chỉ giúp nếu bottleneck của bạn nằm ở prompt processing, context lặp, latency vòng lặp, hoặc chi phí thử nghiệm nội bộ.

Ví dụ cụ thể: giả sử team bạn có một coding agent nội bộ chuyên đọc repo, đề xuất patch nhỏ, chạy test, rồi sửa tiếp. Nếu mỗi lượt đều phải gửi lại system prompt dài, danh sách tool, và vài file source, snapshot/prefix caching có thể đáng quan tâm hơn chuyện model generate nhanh thêm vài token mỗi giây. Ngược lại, nếu workload của bạn là batch summarization chạy ban đêm, ưu tiên lại là throughput, queueing và chi phí GPU, không phải trải nghiệm local trên Mac.

Ba lựa chọn cho team builder

Thay vì hỏi “có nên dùng Ollama MLX không?”, mình sẽ đặt thành ba quyết định kiến trúc.

| Lựa chọn | Hợp với ai | Điểm mạnh | Cái giá phải trả |
|---|---|---|---|
| Local-first trên Apple Silicon | Team dev dùng Mac, cần prototype agent, review code, RAG nhỏ | Latency thấp, dữ liệu không cần rời máy, dễ thử nhiều model | Khó chuẩn hóa môi trường, giới hạn bởi máy từng người |
| GGUF đa phần cứng | Team có máy dev lẫn workstation khác nhau | Chạy được rộng hơn, tận dụng llama.cpp ecosystem | Tối ưu không sâu bằng từng nền tảng cụ thể |
| Cloud inference / edge inference | Sản phẩm có user thật, cần SLA, scale, quan sát tập trung | Dễ kiểm soát vận hành, billing, monitoring | Chi phí lặp context cao nếu thiết kế agent kém |

Cloudflare tuyển thêm team Ensemble AI cũng gợi ý cùng một hướng: cuộc chơi không chỉ là model to hơn, mà là inference rẻ hơn, nhỏ hơn, hiệu quả hơn. Họ nói tới model compression và cả hướng kiến trúc như NdLinear — lớp thay thế linear layer để giữ cấu trúc đa chiều thay vì ép phẳng quá sớm. Bạn không cần áp dụng ngay NdLinear vào stack của mình, nhưng tín hiệu rất rõ: chi phí inference đang thành phần lõi của thiết kế sản phẩm, không còn là dòng footnote trong hóa đơn cloud.

Điều đáng giữ: portability là giá trị thật

Một chi tiết mình thích trong cập nhật MLX là khả năng import model tối ưu cho datacenter rồi chạy với Ollama MLX trên desktop. Nếu làm được trơn tru, đây là mảnh ghép quan trọng: cùng một họ model có thể đi từ môi trường server về máy dev mà không phải đổi toàn bộ workflow.

Đừng xem portability — khả năng di chuyển model giữa môi trường — như chuyện tiện tay. Với team builder, nó quyết định tốc độ debug.

Hình dung thế này: production đang fail một case tool calling. Nếu bạn phải reproduce qua cloud log, xin quyền truy cập, chờ batch job, rồi đoán tiếp, vòng debug rất dài. Nhưng nếu có thể kéo model hoặc bản tương đương về máy, chạy lại prompt, soi context, thử format tool schema khác, bạn rút ngắn chuỗi phản hồi cực nhiều.

Ở hướng ngược lại, các release như Hermes Desktop hay Cursor Design Mode cho thấy một nhánh khác của thị trường: agent không chỉ cần model mạnh, mà cần surface tốt hơn. Surface ở đây là nơi người dùng tương tác với agent: desktop app, IDE, browser, GUI, voice, annotation. Cursor dùng visual prompts cho frontend work; Hermes Desktop đưa agent core lên GUI đa nền tảng. Nghĩa là local inference chỉ là một loài trong hệ sinh thái. Nó sống khỏe khi ghép đúng với memory, session, tool output, UI và observability.

Điều nên bỏ qua: FOMO “mọi thứ phải local”

Có vài thứ không nên kéo về máy dev chỉ vì giờ chạy được.

Thứ nhất, workload có compliance hoặc audit nghiêm túc. Local nghe có vẻ riêng tư hơn, nhưng nếu không có logging chuẩn, policy rõ, và cách thu hồi dữ liệu, bạn chỉ đang phân tán rủi ro sang từng laptop.

Thứ hai, agent cần shared memory giữa nhiều người dùng. Nếu mỗi máy giữ một ký ức riêng, hành vi agent sẽ lệch nhau. Debug lúc đó giống khảo sát rừng mà mỗi người dùng một bản đồ khác.

Thứ ba, benchmark không khớp workflow. Một model chạy nhanh trên prompt ngắn chưa chắc tốt cho agent có transcript dài, nhiều tool call, nhiều file read. Với builder, metric nên đo là time-to-complete task, số lần tool call lỗi, memory peak, context reuse, và chi phí mỗi task hoàn tất.

Quyết định của mình: dùng local như tầng thí nghiệm, không phải toàn bộ khu rừng

Nếu là mình, mình sẽ chia như sau:

Sau bài này, điều mình muốn bạn nghĩ khác là: đừng chọn nơi chạy model theo độ ồn của release; hãy chọn theo vị trí bottleneck trong vòng đời agent. MLX nhanh hơn là tin tốt. NVFP4 đáng để thử. Snapshot đáng để soi nếu bạn build agent nhiều nhánh. Nhưng quyết định đúng vẫn là quyết định gắn với workload, team, phần cứng và cách bạn đo lỗi.

Model local giờ không còn là cây cảnh trên bàn dev nữa. Nhưng muốn thành rừng sản xuất, bạn vẫn phải biết cây nào trồng trong vườn ươm, cây nào đem ra chịu mưa gió.

---
Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng

Nguồn tham khảo