Việc chạy mô hình cục bộ giờ đã tốt hơn
(vickiboykis.com)- Ngay cả trên môi trường M2 Mac đời 2022, LLM cục bộ nay đã có hiệu năng đủ thực dụng để dùng cho câu hỏi phát triển, tác vụ code và kiểm tra tài liệu
- Các mô hình cục bộ ban đầu chậm, khó dùng và độ chính xác cho công việc lập trình cũng thấp, nhưng sau GPT-OSS thì tần suất phải đối chiếu lại bằng mô hình API đã giảm xuống
- Với các bản phát hành mới nhất của dòng Gemma 4, vòng lặp coding agent cục bộ hoạt động với khoảng 75% độ chính xác và tốc độ so với các mô hình frontier
- Kết hợp Pi và LM Studio chạy quy trình agent thông qua endpoint suy luận cục bộ, artifact mô hình và cấu hình cô lập Docker
- Mô hình cục bộ vẫn còn độ trễ suy luận, cửa sổ ngữ cảnh nhỏ và giới hạn phần cứng, nhưng có thể trực tiếp quan sát và thay đổi xử lý token, system prompt, lượng tử hóa và harness
Vị trí hiện tại của mô hình cục bộ
- Các mô hình cục bộ ban đầu chậm, khó dùng và không chính xác trong phần lớn tác vụ lập trình
- Đánh giá rằng mô hình cục bộ tụt lại khá xa nhìn chung là đúng theo tiêu chuẩn sử dụng cá nhân cho đến trước khi GPT-OSS ra mắt
- Tiêu chuẩn cá nhân cho một “mô hình đủ tốt” là có còn phải kiểm tra lại bằng mô hình API hay không, và GPT-OSS là mô hình đầu tiên làm giảm mạnh tần suất kiểm tra đó
- Cho đến gần đây, mô hình cục bộ chủ yếu được dùng như một Google nhanh và cá nhân hóa cho các câu hỏi phát triển không cần tính cập nhật mới nhất
- Sau các bản phát hành mới nhất của dòng Gemma 4, vòng lặp coding agent trên máy cục bộ hoạt động ở mức khoảng 75% độ chính xác và tốc độ so với mô hình frontier {p:75}
Mô hình và môi trường chạy đã sử dụng
- Đã chạy nhiều mô hình cục bộ trên môi trường M2 Mac đời 2022 với 64GB RAM và 1TB lưu trữ
- Các mô hình sử dụng gồm Mistral 7B, Gemma 3, OpenAI OSS-20B, Qwen 3 MOE, Qwen 2.5 Coder v.v.
- Cấu hình chạy đã lần lượt đi qua raw llama.cpp cùng Open WebUI, llama-cpp-python, Ollama, llamafiles và LM Studio
- Mô hình cục bộ mặc định được dùng là triển khai
gemma-4-26b-a4bcủa LM Studio
Các ví dụ tác vụ agent cục bộ thực tế
- Đã refactor một script Python từng là notebook thành một repository gồm 5~6 module
- Các module đó được lint để dùng generic type hint theo chuẩn PEP 585
- Cấu hình cục bộ cũng được dùng để hiệu đính bài blog, viết unit test và thiết lập ban đầu repository mô hình two-tower cho hệ gợi ý
- Repository mô hình two-tower do agent tạo từ trạng thái trống còn khá cơ bản, nhưng đã vượt ra ngoài phạm vi từng được cho là khả thi vào năm ngoái
- Mọi quy trình agent đều được chạy trong container Docker với quyền truy cập thực thi bị giới hạn
Sử dụng tài nguyên và các mô hình nhỏ mới nhất
- Các tác vụ đã thực hiện gần với Google cá nhân hóa hoặc tra cứu tài liệu hơn là những công việc mang tính đột phá
- Trong quá trình làm việc, mức sử dụng GPU và RAM tăng cao và K-V cache đã tăng tới 64GB RAM
- Ngay cả những tác vụ đơn giản, kiểu công việc mô hình cục bộ này cũng còn bất khả thi chỉ 6 tháng trước
Gemma-4-12b-qatgây ấn tượng về hiệu năng so với kích thước ngay từ khi mới phát hành- Kiến trúc mô hình đặt ra câu hỏi cần những thỏa hiệp kiến trúc nào khi có ràng buộc về hiệu năng và chi phí
Cấu hình chạy mô hình agent cục bộ
- Để chạy luồng agent cục bộ cần có engine suy luận mô hình cục bộ, agent harness và artifact mô hình cục bộ
- Harness phải được cấu hình để trỏ tới endpoint suy luận cục bộ, và artifact mô hình đã tải xuống phải được cung cấp thông qua engine suy luận
- Cấu hình cục bộ hiện tại dùng Pi làm agent harness và LM Studio làm máy chủ suy luận
- Đã làm theo bài viết thiết lập coding agent Gemma 4 bằng Pi và LM Studio nhưng thay đổi một số thiết lập
- Thay vì
Gemma 26B A4Bnhư trong bài, mô hình dùng làgemma-4-12b-qat, mới hơn, nhỏ hơn và nhanh hơn, trong khi mức giảm độ chính xác không lớn - Vì lý do bảo mật, mọi phiên Pi đều chạy trong container Docker và chỉ được cấp quyền bash, chặn thực thi mã Python và duyệt web
- Với image riêng cho tác vụ nghiên cứu, có kế hoạch cho phép curl
- Do chạy bên trong Docker nên đã chỉnh
models.jsoncủa Pi để Pi có thể giao tiếp với mô hình
- Thay vì
Cách cô lập dựa trên Docker
- Cấu hình Pi đặt
baseUrllàhttp://host.docker.internal:1234/v1, còn API được đặt làopenai-completions - Cấu hình Docker Compose mount
models.json, thư mục làm việc, cấu hình Pi và thư mục session vào container - Script chạy liên kết thư mục làm việc hiện tại thành workspace của container và, nếu cần, thêm file Compose sandbox an toàn hơn
- Pi chạy trong repository đang làm việc và khởi động Docker, nên không thể trực tiếp xóa file hay thư mục trên đĩa vật lý
- Có thể truyền cấu hình
jsonmô hình tùy chỉnh vào trong container nên nhìn chung hoạt động khá tốt trong môi trường thử nghiệm
Những giới hạn còn lại
- Mô hình cục bộ vẫn có thể suy luận chậm, cửa sổ ngữ cảnh còn nhỏ và lượng ngữ cảnh khả dụng bị giới hạn bởi phần cứng hiện có
- Hệ sinh thái đã trở nên dễ dùng hơn nhiều nhờ các công cụ như LM Studio và nút Use This Model của Hugging Face
- Các bản phát hành đầu tiên có thể gặp vấn đề không khớp prompt template, nhưng những vấn đề như vậy thường được vá rất nhanh
- Vẫn còn khó để khẳng định chắc chắn rằng mọi thứ đã sẵn sàng để dùng ngay cho phát triển phần mềm production
Ưu điểm của mô hình cục bộ và khả năng thử nghiệm
- Với mô hình cục bộ, gần như có thể nhìn vào mọi thứ và xem quá trình suy luận token theo thời gian thực
- Có thể trực tiếp kiểm tra luồng token đầu vào và đầu ra
- Có thể thay đổi cửa sổ ngữ cảnh cục bộ và quan sát khi hiệu năng cải thiện hoặc suy giảm
- Có thể đào sâu cách token được xử lý trên GPU, đồng thời thay đổi system prompt và thiết lập lượng tử hóa
- Có thể cho các mô hình đối đầu với nhau hoặc thay đổi thiết lập phía harness rồi quan sát, nên khả năng thử nghiệm tiếp tục mở rộng
1 bình luận
Ý kiến trên Hacker News
Không chắc là tốt. Tôi dùng mô hình cục bộ khá nhiều, nhưng chạy cục bộ vẫn khá đau đầu
Các mô hình dense như Qwen 27B, Gemma 31B khá thông minh nhưng chậm, còn các mô hình Mixture of Experts (MoE) như Gemma 26B, Qwen 35B, North Mini Code 30B thì nhanh nhưng mắc nhiều lỗi
Muốn chạy cho tử tế thì cần rất nhiều bộ nhớ, mà nếu lượng tử hóa thì khả năng gọi công cụ lại yếu đi. Đa số mọi người chạy ở mức lượng tử hóa 4-bit rồi thắc mắc sao nó không tốt, nhưng thực chất khác gì phẫu thuật cắt thùy não cho mô hình. Tôi khuyên dùng lượng tử hóa của Unsloth; với MoE thì nên dùng 6-bit, còn mô hình dense thì 5-bit
Muốn prefill nhanh thì cần năng lực tính toán, muốn decode nhanh thì cần băng thông, còn muốn nhét toàn bộ vào thì cũng cần nhiều bộ nhớ. Chưa kể laptop sẽ biến thành cỗ máy nóng và ồn, rất bất tiện để làm việc
Vậy có tốt không? Không hẳn. Nhưng nó vẫn chạy được
Nói thêm là tôi tin mô hình mở là tương lai và vẫn đang tiếp tục đóng góp cho hệ sinh thái. Tôi muốn mọi người tự tay nghịch các mô hình này và dùng
piđể học cách chúng hoạt động, nhưng đừng kỳ vọng rằng chỉ cần tải mô hình xuống là sẽ thấy nó hay ngay. Để thay thế kiểu “coding agent” mà đa số mọi người muốn thì vẫn phải tinh chỉnh và cấu hình rất nhiềuCác mô hình không chuyên về lập trình thường hay bị kẹt ở chỗ không thật sự gọi công cụ mà chỉ nói “tôi sẽ làm hành động này”, và ngay cả khi tôi hỏi phải chỉnh gì để thay đổi hành vi đó thì cũng không giúp được gì. Qwen còn khăng khăng rằng nó không chạy trong ollama mà đang chạy trên đám mây Alibaba và không có quyền truy cập hệ thống cục bộ
Các mô hình cho lập trình thì cũng chỉ suy nghĩ nhanh hơn tốc độ tôi gõ một chút, và ngay cả khi có thể hiển thị quá trình suy nghĩ thì cũng khá hạn chế
Trải nghiệm “miễn phí” tốt nhất tôi tìm được đến giờ là OpenCode + Big Pickle. Nó không quá thông minh nên kết quả đầu tiên thường sai, nhưng gói miễn phí rất rộng rãi, đến mức tôi dùng thường xuyên vài tiếng một ngày trong khoảng một tháng mà chỉ đụng giới hạn chừng hai lần. Nếu mục tiêu là chạy thật sự cục bộ thì nó không phù hợp, nhưng nếu mục tiêu là “trải nghiệm tốt nhất mà không phải trả phí thuê bao hay token” thì đây là lựa chọn ít tệ nhất tôi thấy cho đến lúc này
Cố chạy bằng Mac bộ nhớ hợp nhất, bộ xử lý AMD AI Max hay thiết bị kiểu DGX Spark thì gần như là tự chuốc lấy khổ. Prefill sẽ bóp nghẹt hiệu năng
Nếu trang bị GPU phù hợp thì sẽ khá hơn nhiều, nhưng vẫn chưa đạt tầm Sonnet hay DeepSeek 4 Flash, còn so với Opus / DeepSeek Pro hay Mythos/Fable/GPT-5.5 thì lại càng chưa tới
Nếu đủ ngân sách, điện năng và làm mát thì bạn có thể vận hành pipeline dữ liệu khá ổn, nhưng với code thì trong đa số trường hợp vẫn hợp lý hơn khi trả tiền cho nhà cung cấp API
Dù vậy, vẫn đáng thử nếu muốn bớt phụ thuộc quá nhiều vào các dịch vụ tập trung
Theo trải nghiệm của tôi, trong các công việc kiểu tuân thủ quy tắc hoặc tự động hóa, nó vượt cả các mô hình Qwen, kể cả loại 100B+, về mức độ hiệu quả. Khả năng hiểu hình ảnh cũng rất tốt và trên benchmark còn cao hơn Opus
Qwen có xu hướng phớt lờ chỉ thị, và nếu không giới hạn rõ ràng định dạng sinh token thì nó thường xuyên xuất ra sai định dạng
Tuy vậy, trên DGX Spark thì Gemma 31B Q4 + MTP chỉ khoảng 20 token/giây, còn Gemma 26B A4B khoảng 60 token/giây nên vẫn khá chậm. Trên các card Nvidia cao cấp thì sẽ chạy nhanh hơn nhiều và cũng đủ bộ nhớ
Với người mới bắt đầu dùng mô hình cục bộ, tôi khuyên nên tập trung vào băng thông bộ nhớ hơn là RAM. Giờ đây các mô hình dưới 100B cũng đã đủ tốt và rất hữu ích cho tự động hóa
Tôi đồng ý rằng với mục đích viết code/sáng tạo thì vẫn chưa có lý do thật sự mạnh để dùng mô hình cục bộ. Nhưng với các việc như rà danh sách cổ phiếu và lọc thông tin nhiễu từ tin tức, hay diễn giải log, phân tích ảnh chụp màn hình, thì mô hình cục bộ giờ đã đủ dùng
Có lẽ có thể biện minh được cho một chiếc Mac Studio M6 với khoảng 256GB RAM để vài người cùng truy cập vào một mô hình đã thống nhất. Laptop có vẻ quá nóng và quá ì cho mục đích này
Tôi đã dùng Qwen3.6-27B khá hài lòng suốt vài tuần, nhưng hiện phải dùng Claude Sonnet 4.6 vì không ở gần phần cứng, và cảm giác như một bước thụt lùi khủng khiếp
Tôi không hiểu sao lại như vậy. Nó có quá nhiều ý kiến mạnh mẽ dù tôi không hề yêu cầu, nói quá nhiều, và nhìn chung có cảm giác ngốc hơn
Chắc chắn đây là mô hình lớn hơn rất nhiều nên sẽ mã hóa được nhiều kiến thức hơn, nhưng nếu không muốn trò chuyện với nó thì cũng chẳng giúp ích gì. Hơn nữa, trò chuyện còn tốn tiền thật
Tôi tự hỏi vì sao mình lại ghét nó đến thế. Có lẽ vì nó dường như xem bản thân không phải là công cụ mà gần như là một thực thể ngang hàng. Nó cư xử như thể ý kiến của mình có trọng lượng
Qwen cũng có thể hành xử như một thực tập sinh quá hăng hái, nhưng nếu bạn bảo nó là đồ ngốc thì nó sẽ hạ cái tôi xuống. Theo trải nghiệm của tôi thì Claude không như vậy
Tóm lại, tôi hoàn toàn đồng ý với tiêu đề
Tôi đã dùng nó gần như hằng ngày suốt một tháng rưỡi qua trên máy M2 Ultra hoặc RTX 5090. Tôi dùng nó cho các tác vụ nhỏ và bình thường ở ggml-org [0]; không có gì ghê gớm, nhưng rõ ràng là một công cụ hữu ích cho maintainer
Có lẽ tôi đã dùng nó nhiều hơn nữa nếu không dành quá nhiều thời gian cho việc review PR. Hiện tại tôi dùng một harness rất nhẹ, gần như chỉ là pi agent đã bỏ mọi thứ đi (
pi -nc --offline) và một prompt hệ thống ngắn để chỉnh cho hợp phong cách của tôi [1]Tốc độ sinh là khoảng 100~150 token/giây trên RTX 5090 và khoảng 40 token/giây trên Mac. Tôi chắc chắn thích chạy trên máy RTX hơn vì nhanh hơn nhiều, nhưng cũng thường chạy trên Mac để kiểm thử thiết lập cục bộ và có trải nghiệm rộng hơn
[0] - https://github.com/search?q=%22Assisted-by%22+user%3Aggml-or...
[1] - https://github.com/ggml-org/llama.cpp/blob/master/.pi/gg/SYS...
Nó có thể kém hơn Opus ở kiểu yêu cầu như “hãy thêm tính năng lớn X”, nhưng tôi không muốn mô hình làm kiểu đó. Tôi muốn mình suy nghĩ còn mô hình thì gõ ra. Qwen 3.6 27B hoàn toàn đủ cho mục đích đó. Theo trải nghiệm của tôi, 35A3B hay dòng Gemma là một bước thụt lùi đáng kể
Thêm nữa, không phải lo giới hạn tốc độ, hạn mức hay hàng chờ giờ cao điểm. Bạn luôn có thể xem toàn bộ quá trình suy nghĩ, không phải lo dữ liệu bị gửi đi đâu, và cũng không có chuyện hiệu năng bị bí mật giảm xuống
Tôi chạy nó bằng llama.cpp trên 2×3090 với thiết lập Q6_K_XL + MTP, đạt prefill 500~1000 token/giây, đầu ra 60 token/giây, và cửa sổ ngữ cảnh 220 nghìn token. Sau khi vượt 160 nghìn token thì nó bắt đầu ngốc đi một chút, và tôi không dùng lượng tử hóa KV
Có thể đây là tác dụng phụ của tính năng suy nghĩ, nhưng tôi ước nó tóm tắt quá trình suy nghĩ ngắn hơn nhiều. Ngay cả trong những tình huống chỉ cần một câu trả lời, các mô hình tối tân vẫn viết ít nhất 5 đoạn và còn cố đề xuất 3~5 hướng đi mới
Dù có yêu cầu chỉ làm từng bước một, mỗi lần chỉ một lựa chọn, đừng chủ động đề xuất hướng đi tiếp theo, thì việc kiểm soát nó bằng prompt vẫn thật sự rất khó
Mà vừa rồi chính tôi cũng đang làm đúng cái điều mình vừa phàn nàn
Lập trình viên đã quen với việc không phải trả tiền cho công cụ. Một chiếc laptop cơ bản (SSD, đa nhân, RAM 16GB) cũng đã cực kỳ mạnh cho phát triển C/C++/Rust, thậm chí cả Python
Nhưng đột nhiên chừng đó lại không đủ, và chúng ta quay lại cảnh dùng máy tính của người khác, thuê công cụ mỗi ngày. Tệ hơn nữa là mỗi ngày lại dùng một mô hình khác nhau, và có những ngày một thế lực kiểu mafia gây áp lực lên nhà sản xuất khiến bạn thậm chí không thể thuê được công cụ tốt
Hầu hết các nghề khác đều phải đầu tư đáng kể cho công cụ. Nếu muốn công cụ tốt, bạn cần 64GB bộ nhớ GPU (ví dụ: 2×5090) và khoảng 96GB RAM. Nếu đang trả 200 nghìn đô cho một kỹ sư chuyên nghiệp, thì việc chi 50 nghìn đô cho công cụ mỗi 2 năm cũng có vẻ khá hợp lý
Đây là xu hướng mà những công ty như Anthropic nên lo ngại. Càng dễ chạy mô hình cục bộ, mức trần giá mà họ có thể thu sẽ càng thấp dần
Có lẽ sẽ không bao giờ hoàn toàn hết người sẵn sàng trả $$$$$ mỗi tháng, nhưng nhiều người sẽ lấy phí tháng nhân 12 hoặc 24 rồi cân nhắc: “Liệu mình có thể xây một mô hình cục bộ rẻ hơn số tiền này và hoàn vốn trong 1–2 năm không?”
Nếu một phần đáng kể khách hàng chọn mua thay vì thuê, các công ty có mô hình kinh doanh xoay quanh cho thuê có thể đột ngột rơi vào tình trạng thiếu khách hàng
Điều đó gần như đã in sâu vào mô hình kinh doanh kiểu Mỹ rồi: thuê ngoài mọi thứ. Không ai muốn tự quản lý phòng máy chủ, và ngay cả khi phải trả gấp 2–3 lần, họ vẫn muốn thuê ngoài cả sự phiền phức lẫn trách nhiệm đó
AI cũng sẽ như vậy thôi. Trả khoản premium đó cho Anthropic hay cho AWS thì cũng như nhau
Tôi làm ở một công ty tương đối nhỏ, và gần đây đã có sự cố liên quan đến hạ tầng cục bộ. Dù tổng thời gian downtime nội bộ trong 5 năm qua vẫn ít hơn rất nhiều so với chỉ một sự cố AWS lớn gần đây, CEO vẫn đang gây áp lực rằng việc tự host hạ tầng là không đáng tin cậy
Ai cũng muốn quăng bỏ việc lặt vặt và trách nhiệm
Có vẻ người dùng phổ thông sẽ có xu hướng trả tiền cho thứ đã được thiết lập sẵn và dùng được ngay. Còn những người thiên về kỹ thuật hơn hoặc quyết tâm hơn thì sẽ tự làm, nhưng tôi tò mò không biết tỷ lệ giữa hai nhóm đó sẽ là bao nhiêu
Tôi không biết trước đây đã có ai từng nảy ra ý tưởng bán những máy kiểu 4 GPU để đội kỹ sư có thể nhét vào đâu đó như trong tủ và chạy mô hình họ muốn chưa
Nó sẽ không hấp dẫn với tất cả mọi người, nhưng trong bối cảnh đã nảy sinh vấn đề niềm tin rằng các hyperscaler hút dữ liệu của mọi người để dùng huấn luyện mô hình, chắc chắn sẽ có nơi coi trọng những máy và mô hình mà họ có thể kiểm soát minh bạch, và nếu cần thì có thể tự đi rút phích cắm
Chỉ với Sonnet 4.6, gói 20 USD/tháng đã gần như đủ để làm việc cả ngày. Và Sonnet vẫn mạnh hơn rất nhiều so với các mô hình có thể tự host trên Mac M2
Có thể tôi sẽ nghĩ khác nếu mọi thứ đều chuyển sang tính phí theo lượng token sử dụng, nhưng xét theo dạng thuê bao thì tôi không thấy hợp lý về mặt tài chính
Nó vui đấy. Nhưng không hợp lý về mặt kinh tế
OpenAI đang gom sạch RAM trên thị trường giao ngay, khiến giá RAM/VRAM tăng gấp 6 lần, còn GPU và máy tính tử tế thì trở nên ngoài tầm với của phần lớn mọi người
Một số ít người giàu có thể mua Mac Studio 512GB hoặc một chiếc RTX Pro 6000 giá 13.000 USD để chạy mô hình cục bộ khá ổn, nhưng đa số sẽ phải dùng API
Đến một lúc nào đó Nvidia có thể nói rằng, “6000 bán chẳng được bao nhiêu, trong khi GPU chỉ dành cho datacenter mang lại lợi nhuận gấp 4 lần, thôi hủy đi.” Khi đó nó sẽ thành món hàng không thể kiếm được, và việc cá nhân chạy cục bộ những mô hình khá ổn nhưng chậm hơn trạng thái tối tân khoảng 1 năm có thể sẽ trở nên bất khả thi
Tôi muốn được xem đoạn mã tạo ra khi dùng cái đó. Tôi muốn dùng mô hình cục bộ và cũng có phần cứng, nhưng nếu so với các mô hình tối tân như GPT 5.5 xhigh hay Opus thì chúng vẫn chưa sẵn sàng để thay thế
Vì chất lượng và các điểm vướng, quy trình làm việc bị chậm đi quá nhiều, thậm chí đôi khi còn làm hỏng cả cú pháp gọi công cụ
Tuy vậy, với những luồng nhỏ hơn và được xác định rõ, hoặc những chỉnh sửa kiểu “hãy đổi chính xác phần này thành như thế này”, thì có vẻ chúng đã đủ dùng. Tôi đang chờ đến lúc chúng trưởng thành đủ để thay thế trình độ tối tân hiện nay, và đó sẽ là thời điểm chuyển đổi
Nếu nói về mô hình cục bộ, không nên đánh giá thấp DiffusionGemma và các diffusion model nói chung trong bối cảnh dùng cục bộ. Vấn đề thường thấy của local là LLM không thể tận dụng phần cứng hiệu quả trừ khi gom các yêu cầu thành batch để chạy đồng thời, mà như vậy thì phải thay đổi hẳn cách tiếp cận. Trong khi đó, diffusion model nhanh hơn nhiều với một prompt đơn lẻ, và chênh lệch đó không hề nhỏ
Hôm nay đúng lúc tôi vừa port hỗ trợ diffusiongemma-26B-A4B-it từ Transformers sang Candle, rồi thêm vài tối ưu hóa nữa, nên trong lúc suy luận nó chạy trên Candle ở mức khoảng 450 token/giây (khoảng 19 vòng lặp/giây), tức là nhanh như bay. Trong thư viện HF Transformers thì nó vào khoảng 180 token/giây (khoảng 11 vòng lặp/giây). Ngay cả khi chạy một LLM có kích thước tương tự bằng vLLM, tôi cũng không nghĩ mình từng vượt quá 250 token/giây với một prompt đơn lẻ, nên đây là điều khá thú vị đối với mô hình cục bộ
Với 2.600 USD, bạn có thể mua hai GPU AMD 9700, mỗi card có 32GB RAM và tiêu thụ khoảng 285W. Cả chi phí lẫn điện năng đều thấp hơn 5090
Nếu dùng bản build VLLM có áp dụng bản vá AITER, bạn có thể chạy Qwen3.6 27B FP8 ở khoảng 45–50 TPS với toàn bộ cửa sổ ngữ cảnh trong các phiên coding thực tế của Opencode hay PI
Tôi thực sự hy vọng sẽ tiếp tục có thêm nhiều dense model cỡ 30B xuất hiện, nhưng riêng Qwen3.6 thôi cũng đã xử lý được khá nhiều tác vụ tác tử
Tuy nhiên, stack ROCm không phù hợp với những ai không sẵn sàng tự đào sâu và vá lỗi thủ công
Tôi thắc mắc vì sao tiêu chí về agent coding “tốt” lại khác nhau nhiều đến vậy tùy từng người
Một mặt, việc chúng ta đã tiến từ mức trí năng kiểu “phát ‘Set a Timer’ trên Apple Music” đến mức có thể vượt qua Turing test quả thật rất đáng kinh ngạc, nhưng xét về tính thực dụng thì các mô hình nhỏ vẫn còn rất xa mới có thể gọi là “tốt” vượt quá mức demo công nghệ
Với tôi, mô hình 7B chỉ như tiếng vọng mờ nhạt của Wikipedia. Mô hình Gemma 4-bit thậm chí còn quá vụng về để tạo JSON gọi công cụ một cách ổn định, hoặc sao chép chỉ một dòng mã để áp dụng bản vá
Qwen cần quá nhiều chỉ dẫn chi tiết và chăm sóc để không rơi vào vòng lặp hủy diệt hoặc đánh mất ngữ cảnh, đến mức nhiều khi phần chỉ dẫn tôi phải đưa còn dài hơn cả đoạn mã cuối cùng nó tạo ra
Có phải tôi đang thiếu một prompt ma thuật nào đó không? Hay là người khác kiên nhẫn hơn rất nhiều, hoặc kỳ vọng thấp hơn rất nhiều?
Với các script nhỏ, glue code, hay thay đổi CRUD đơn giản, những mô hình nhỏ như Qwen3.6-27B có thể hoạt động tốt hơn nhiều so với khi dùng trên các codebase lớn và lộn xộn hơn
Chạy Qwen/Gemma cỡ 27/35B ở FP8 thì tốt hơn gemini-2.5 nhưng kém gemini-3.1. DS4-flash FP8 có thể chạy trên hai máy DGX Spark, và tình hình vẫn đang tiếp tục cải thiện. DiffusionGemma gần đây cho tốc độ sinh token nhanh hơn 4 lần
Tóm lại, có vẻ các mô hình đã dùng quá nhỏ hoặc bị lượng tử hóa quá mạnh
Tôi thích chạy hai mô hình cục bộ. Đó là qwen3.6 27B 8-bit (dense) và qwen3.6 35B 4-bit (mixture of experts)
27B thông minh và đáng tin cậy hơn nhưng chậm hơn. 35B nhanh hơn và vẫn rất thông minh, nhưng kém 27B và hơi kém ổn định hơn một chút. Lý do là kiến trúc mixture of experts (MoE) chỉ kích hoạt một phần tham số nên mô hình chạy nhanh hơn nhiều
Tôi chạy 27B trên MacBook Pro M5 Max + 40 lõi GPU + RAM 128GB. Trên con quái vật này, tôi có thể nạp cả 27B lẫn 35B vào bộ nhớ cùng lúc mà vẫn còn dư cho việc khác. Nhưng vì là laptop nên không thể lúc nào cũng chạy local LLM. Nó quá nóng và ồn
Điều thú vị hơn là chạy mô hình 35B trên MacMini M4 RAM 64GB. Nó nhanh và xử lý được nhiều việc. Ví dụ, nó quét·trích xuất·phân loại email, rồi liên tục theo dõi hộp thư để làm việc. Tôi cũng dùng nó như trợ lý Hermes cá nhân để hỏi những câu như “Lần phóng Starship tiếp theo là khi nào?”, “Hôm nay ở World Cup có những ai thi đấu? Kể thêm vài chuyện lặt vặt nữa”
Kế hoạch tiếp theo là một workstation RTX Pro 6000 Blackwell đặt ở tầng hầm. Tôi muốn chạy Qwen thật nhanh, đồng thời với nhiều thread/prompt/agent. Nếu ngân sách cho phép, tôi muốn cấu hình 2×RTX Pro 6000 để chạy DeepSeek v4 flash và dùng cho nghiên cứu
Hằng ngày tôi vẫn host Qwen3.6:27b, nhưng thật sự muốn host deepseekv4 flash. Nó là một mô hình quá “ngon” so với kích thước/tốc độ/giá thành
Tôi tự hỏi đến bao giờ các công ty sẽ bắt đầu host on-premises các mô hình cho công việc hằng ngày, thay vì trả phí thuê bao cho mọi lập trình viên. Nó đủ tốt và tương đối rẻ
Dù không ai hỏi, nhưng tôi nghĩ không ai trong chúng ta nên dùng các mô hình mới nhất ở đẳng cấp cao nhất để viết code hay gần như bất kỳ việc gì
Thay vào đó, chúng ta nên phát triển mô hình mở cho từng tác vụ cụ thể, và học cách viết code, viết lách, vẽ vời bằng chính những ngón tay xương thịt và bộ não bằng thịt của mình
Các tập đoàn lớn và cơ sở nghiên cứu có thể dùng chúng để sinh mã, toán học v.v. miễn là có chuyên gia kiểm chứng đầu ra có đúng hay không, nhưng ngay cả vậy thì có thể cũng không đáng so với chi phí. Ví dụ, OpenAI năm ngoái lỗ ròng 36 tỷ USD, các mô hình mở đã tiến khá gần, và toàn bộ kế hoạch AI đang cạn dần trò thổi phồng để moi thêm tiền
Có rất nhiều việc có thể làm với các mô hình rất nhỏ, và cũng có nhiều tác vụ không cần mức năng lực tính toán và bộ nhớ điên rồ, nhưng lại có quá ít người thực sự nghiên cứu nghiêm túc theo hướng đó