Ask HN: Có ai đã thay thế Claude/GPT bằng mô hình cục bộ cho việc lập trình hằng ngày chưa?

 (news.ycombinator.com)
6 điểm bởi GN⁺ 9 giờ trước | 2 bình luận | Chia sẻ qua WhatsApp
  • Ngày càng có nhiều lập trình viên rời bỏ hoàn toàn các mô hình đám mây vì quyền riêng tư dữ liệu và khả năng dùng LLM miễn phí; với bộ harness lập trình ngoại tuyến được container hóa và sandbox hóa, họ có thể làm việc mà không cần gọi ra mạng bên ngoài
  • Các mô hình chủ lực là Qwen3.6 35B-A3B (chỉ 3b tham số hoạt hóa nên rất nhanh) và mô hình dense 27B, với sự đánh đổi giữa độ chính xác khi lập trình và tốc độ sinh token
  • Tổ hợp được nhắc đến nhiều nhất là Pi harness và llama.cpp; việc gọi công cụ (tool calling) lần đầu tiên hoạt động ổn định trên mô hình cục bộ đã cải thiện đáng kể trải nghiệm sử dụng
  • So với Claude Opus, mô hình cục bộ khác biệt ở mức "junior cần được hướng dẫn vs senior cùng thiết kế"; prompt chính xác và chia nhỏ công việc là điều bắt buộc
  • Hiện tại mô hình cục bộ được đánh giá ở mức khoảng 8~18 tháng trước so với frontier, nhưng mang lại lợi ích thực tế là miễn phí, riêng tư và không phải lo hạn mức

Các trường hợp chuyển sang mô hình cục bộ và cấu hình phần cứng

  • Chạy Qwen3.6 35B-A3B bằng Pi harness trên Mac Studio 128GB hoặc MacBook RAM 36GB, đã hoàn tất việc thiết kế lại toàn bộ trang chủ và blog của website dựa trên Django + Wagtail
    • Khi phát triển Wagtail ít phổ biến mà không có truy cập Internet, mô hình không phải lúc nào cũng biết cách làm
    • Với tác vụ phức tạp thì dùng Qwen3.5 122b, nhưng do có 10b tham số hoạt hóa nên khá chậm
  • Trong môi trường bộ nhớ hợp nhất Strix Halo 128GB, Pi được cô lập trong container, chỉ cho phép truy cập thư mục làm việc mà không có credential
    • Chat và dịch dùng Gemma 4 31B, âm thanh dùng Gemma 4 12B
    • Có nhiều mô hình như Qwen 3.5 122B-A10B, Nemotron 3 Super 122B-A12B, Step 3.7 Flash, GPT-OSS 120B, nhưng cho lập trình thì 35B-A3B là tối ưu nhất
  • Trên máy dual RTX3090 lắp từ 5 năm trước, các mô hình Qwen·Gemma đạt ~150tok/s với lượng tử hóa UD-Q4_K_XL, và xử lý toàn bộ ngữ cảnh 300k trong VRAM
    • Đã thay thế gói Claude $100/tháng, và với mục đích cá nhân thì yếu tố miễn phí được ưu tiên
    • Đã làm nhiều dự án như launcher Android TV, cổng quản trị k8s, tích hợp Home Assistant, quản lý thực phẩm·thực đơn
  • Với RTX 6000, dùng kết hợp Qwen 3.6 27b + Open Code, xử lý được 90% công việc lập trình nhưng các tác vụ rất phức tạp và tinh chỉnh UI vẫn quay lại Codex
    • Ở ngữ cảnh 256k, chất lượng và tốc độ giảm khi vượt 100k, và trở nên nghiêm trọng sau 150k
  • Trên RTX 5090, dùng Qwen 3.6 27b (lượng tử hóa Q6) + llama.cpp, giới hạn GPU từ 600W xuống 450W để đảm bảo độ yên tĩnh
    • Mở rộng sang công việc hằng ngày như commit branch·tạo PR, đối soát hóa đơn Stripe CLI, phân tích tải Elasticsearch

Các loại mô hình và đặc tính hiệu năng

  • Sự khác biệt giữa MoE và mô hình dense ảnh hưởng trực tiếp đến chất lượng lập trình
    • Qwen3.5-122B thực tế là MoE 122B-A10B, chỉ kích hoạt 10B; còn Qwen3.6-27B là mô hình dense với toàn bộ 27B luôn hoạt động
    • Có thể xấp xỉ chất lượng tương đương dense bằng trung bình nhân của tham số hoạt hóa và tổng tham số trong MoE, sqrt(35×10)≈18.7
    • MoE cho chất lượng thấp hơn so với dense cùng kích thước nhưng nhanh hơn, và có thể chạy MoE lớn bằng cách offload sang RAM CPU
  • Mức lượng tử hóa ảnh hưởng đến hiện tượng lặp và độ chính xác
    • Lượng tử hóa Q8 chậm hơn nhưng giảm vòng lặp, giúp tiết kiệm tổng thời gian
    • Rất nhạy với lượng tử hóa phần K của KV cache; dùng F16 K + Q8 V làm giảm mạnh hiện tượng lặp
  • Việc thêm GPU kép không nhằm tăng tốc suy luận mà để mở rộng dung lượng VRAM
    • Gemma-4 31B dense và 26B MoE đều có chất lượng tương tự khi lượng tử hóa Q4, nhưng MoE nhanh hơn khoảng ~3 lần (150tok/s vs 46tok/s)

Giới hạn của mô hình cục bộ và chiến lược ứng phó

  • Cần prompt chính xác

    • Nếu để mô hình tự giả định, nó sẽ chọn đường ngắn nhất (ví dụ: CSS trong HTML) và tạo ra kết quả không tối ưu về mặt kiến trúc
    • Nếu không chỉ rõ kiến trúc, nó sẽ sửa nhanh nhưng bẩn; nếu không yêu cầu xóa các câu debug thì chúng sẽ bị giữ lại
    • Claude Opus có thể suy luận ý định người dùng, còn Qwen nhỏ chỉ làm đúng phần được chỉ định, nên phải "kích hoạt" tri thức thiết kế một cách tường minh

  • Lỗi vòng lặp và công cụ chỉnh sửa

    • Thường gọi sai công cụ chỉnh sửa, và thay vì thử lại thì tiêu tốn token suy nghĩ để đọc lại file
    • Việc tự thử lại trực tiếp thường sửa được lệnh chỉnh sửa, nhưng mô hình lại giả định vấn đề nghiêm trọng hơn nên tiêu token không cần thiết
    • Cách chỉnh sửa dựa trên hash (tham chiếu hash của từng dòng mã) có thể giảm lỗi chỉnh sửa, nhưng sau khi chất lượng ngữ cảnh cạn kiệt thì vẫn sụp theo cách khác
    • Dùng quy tắc AGENTS.md để hạn chế rewrite thay vì edit giúp cải thiện phần nào

  • Quản lý cửa sổ ngữ cảnh

    • Cửa sổ 65.000 là không đủ, chỉ cần đọc cấu trúc file mã cũng có thể vượt quá; cần từ 200k trở lên
    • Qwen3.6-35b xử lý ổn 256k context ở mức 128k trên VRAM 16gb
    • Qwen3.6-27B hỗ trợ ngữ cảnh 1 triệu token, nhưng trên DGX Spark với KV cache f16 cần khoảng 100GB bộ nhớ

Vấn đề caching prompt và lưu giữ suy luận

  • Mô hình hybrid của Qwen gặp vấn đề prompt caching, không xử lý được nên mỗi lượt đều phải xử lý lại toàn bộ ngữ cảnh
    • Phần lớn mô hình cục bộ chưa được huấn luyện để giữ lại toàn bộ suy luận giữa các lượt, nên sau chuỗi gọi công cụ dài phải xử lý lại dù phần suy luận đã bị loại bỏ
    • Qwen 3.6 được huấn luyện để giữ suy luận, và có thể cải thiện việc tái sử dụng cache với chat-template-kwargs = {"preserve_thinking": true}
  • LLM hiện đại không chỉ dùng full attention mà còn dùng local attention (sliding window, state space model Mamba-2)
    • Full attention có chi phí O(n²) lớn và yếu với dạng suy luận mà giá trị thay đổi theo thời gian
    • Local attention lưu snapshot để khi tính lại cache có thể bắt đầu từ snapshot cuối cùng, dù việc lưu giữ vẫn bị giới hạn nếu snapshot quá lớn
    • Từ Qwen 3.5 trở lên dùng Gated DeltaNet, xen kẽ attention và lớp SSM
  • Vulkan lại nhanh hơn ROCm một cách nghịch lý, và việc giữ llama.cpp ở bản mới nhất rất quan trọng để xử lý vấn đề reprocessing
  • Hiện tượng tokenizer phân kỳ, nơi token tự hồi quy được parse khác đi ở giai đoạn prefill, rất khó giải quyết

Tranh luận về hiệu quả kinh tế của chi phí·điện năng

  • 2x RTX3090 giá khoảng $4400, tương đương 3,6 năm Claude $100/tháng, chưa tính điện và các linh kiện khác
    • Ngay cả sau 3,6 năm, giá GPU dung lượng lớn có thể vẫn được giữ ở mức cao
    • Ở những nơi điện đắt, điểm hòa vốn có thể chỉ khoảng 1 năm
  • Mức tiêu thụ điện thấp hơn dự đoán
    • Chạy tối đa 1.2kw tốn khoảng $0.12/giờ, và còn rẻ hơn nếu kết nối điện mặt trời
    • Tải suy luận khác với chơi game nên vấn đề điện năng là nhỏ; hệ thống idle khoảng 200W, suy luận ở mức 350-450W
  • Về thời điểm mua phần cứng
    • Hiện tại chưa phải thời điểm mua tốt; dự đoán 24-36 tháng nữa sẽ là đợt phù hợp tiếp theo
    • M4 Pro Mac mini RAM hợp nhất 48gb giá khoảng ~$2k được khuyến nghị như thiết bị suy luận tiết kiệm, có thể dùng ~150tok/s trong 10 năm tới
    • AMD R9700 VRAM 32gb giá khoảng ~$1200-1400 phù hợp cho AI hơn 2x 9070
  • Thuê dịch vụ (đăng ký cloud) cũng là chiến lược hợp lý; không phải ai cũng có thể bỏ nhiều tiền vào phần cứng

Đánh giá so với mô hình frontier

  • Mô hình cục bộ liên tục được đánh giá ở mức "chất lượng của mô hình top cách đây 8~12 tháng"
    • Trên benchmark, Qwen 3.6 35B-A3B vượt Claude 4 Opus, nhưng cũng có khả năng một số mô hình mã nguồn mở đã bị benchmark-maxxing
    • Trong một bài test YouTube Browser OS, Qwen 3.6 tạo ra nhiều tính năng hoạt động hơn Claude 4 Opus
    • Tuy vậy đó là theo chuẩn frontier của 1 năm trước; cũng có phản biện mạnh rằng MoE 3B hoạt hóa không thể so với Opus·Sonnet mới nhất
  • Sự bất đồng về định nghĩa "cấp độ Opus" là cốt lõi của tranh luận
    • Tên gọi này được dùng từ Claude 3 Opus năm 2024, nhưng vẫn còn khoảng cách lớn với các mô hình mới như Opus 4.8·4.6
    • Từ Opus 4.5·GPT 5.2 vào tháng 11 năm ngoái, các mô hình frontier đã có bước nhảy theo từng bậc; thông thường "cấp Opus" ám chỉ từ 4.5 trở đi
    • Những mô hình open-weight lớn nhất cần phần cứng cấp máy chủ 8x H100; các mô hình dùng tại gia vẫn chưa đạt tới
  • Một số người đánh giá mô hình cục bộ nằm giữa Haiku 4.5 và Sonnet 4.5, và cho kết quả tốt nếu được micromanage
  • Khoảng cách giữa frontier và local có thể sẽ luôn tồn tại, nhưng với nhiều người dùng thì local đã đủ thực dụng

Chiến lược harness và workflow

  • Pi harness được khuyến nghị nhiều nhất, mang tính chất bộ kit phát triển agent; được ví như "neovim dành cho vscode của Claude"
    • Cung cấp công cụ mặc định (truy cập file·chỉnh sửa·bash), có thể thêm adapter MCP và mở rộng tìm kiếm web
    • Dùng lệnh /tree để quay lại ngữ cảnh trước lần gọi công cụ thất bại, và /new để khởi tạo lại ngữ cảnh
  • Workflow phân tầng·phân vai giúp bù đắp hạn chế
    • Dùng mô hình frontier để viết spec·thiết kế·kế hoạch thực thi, còn mô hình cục bộ để hiện thực hóa
    • Kết nối agent theo vai trò (project manager·schema agent·coding agent), rồi dùng orchestrator và Playwright để chỉ chuyển lỗi sang bước tiếp theo
    • Chia công việc thành TODO mang tính nguyên tử và chỉ rõ file tham chiếu để tiết kiệm ngữ cảnh
  • OpenCode đôi khi thay đổi system prompt ở mỗi lượt nên không tương thích với KV cache; cấu hình hỗ trợ local LLM còn thủ công và phức tạp
  • Ollama bị chỉ trích vì bổ sung mô hình cloud và thương mại hóa; khuyến nghị dùng llama.cpp·llama-swap, còn trên macOS thì llm-mlx nhanh hơn 10-15%

Các trường hợp chia sẻ cấu hình cụ thể

  • Trong môi trường AMD 7900xtx 24gb + 5950x + 64gb DDR4, chạy Qwen3.6-27B-MTP-UD-Q4_K_XL bằng llama.cpp Vulkan
    • Các cờ chính: -ngl 99 (offload toàn bộ layer lên GPU), -c 80000 (context 80K), --cache-type-k q8_0 --cache-type-v q8_0 (KV cache 8-bit), -fa on (flash attention), --spec-type draft-mtp (MTP draft)
    • Sampling: --temp 0.6 --top-p 0.95 --top-k 20 --min-p 0.0 (giá trị khuyến nghị cho lập trình với Qwen)
    • Hiệu năng: sinh token ~65t/s, xử lý prompt ~600t/s, cold start ~30 giây
    • Tổ hợp Crush harness + Headroom + Exa MCP web search đã khiến người dùng hủy gói Claude Code cá nhân
  • Trên V100 32GB, dùng Qwen3.6-27B-UD-Q4_K_XL + Pi, áp dụng fork llama-cpp-turboquant và patch MTP
    • Với context 200.000, --spec-type mpt --cache-type-k turbo3 --cache-type-v turbo3 cho 45-60 t/s
  • Trên Strix Halo 128GB, Qwen3.6-35B-A3B đạt xử lý prompt ~800tps và sinh token 50tps, gần như không tiêu thụ điện khi idle
    • Có tiếc nuối vì chưa có bản 122B; trong môi trường bộ nhớ hợp nhất, mô hình dense chậm do giới hạn băng thông bộ nhớ
  • Cũng có phàn nàn về việc thiếu chi tiết, kêu gọi nêu rõ cấu hình lượng tử hóa·tham số·ngữ cảnh·GPU·VRAM·harness

Bài viết liên quan

2 bình luận

 
b89kim 1 giờ trước

Khi dùng Pi-coding-agent+Qwen3.6-27B-MTP-GGUF thì hiệu năng vào khoảng Sonnet 4.5. Đủ để làm các app đơn giản, và khi cần thì thỉnh thoảng tôi gắn thêm API miễn phí như GLM5.1. Mức tiêu thụ điện của GPU cỡ 4090/5090 đúng là khá lớn, nhưng nếu agent được thiết kế bài bản thì cũng không có nhiều việc phải chạy theo đơn vị giờ.
 
GN⁺ 9 giờ trước
Ý kiến trên Hacker News

  • Greenpants: Quyền riêng tư dữ liệu và LLM miễn phí là điều quan trọng, nên tôi đưa Pi coding harness vào container·sandbox và dùng hoàn toàn ngoại tuyến
    Tôi dùng Qwen3.6 35B trên Mac Studio 128GB hoặc MacBook 36GB; vì tham số hoạt động là 3B nên khá nhanh. Tôi đã thiết kế lại toàn bộ trang chủ và blog bằng Django + Wagtail, nhưng Wagtail ít được biết đến hơn nên khi không có Internet, agent không phải lúc nào cũng nắm rõ
    Với việc phức tạp hơn, tôi cũng dùng Qwen3.5 122B, nhưng vì hoạt động ở 10B nên chậm hơn nhiều. So với các mô hình lớn như Claude, bạn phải đặt câu hỏi thật chính xác, và các giả định bị để trống thường bị xử lý theo con đường dễ nhất, dẫn đến những lựa chọn kiến trúc chưa ổn như nhét CSS vào HTML
    Việc gọi công cụ chỉnh sửa cũng hay sai và dễ rơi vào vòng lặp. Qwen3.6 35B giống một junior có kiến thức tổng quát nhưng phải liên tục được dẫn dắt, còn Claude Opus thì gần với một senior có thể cùng bạn suy nghĩ về kiến trúc. Nếu Opus cho cảm giác tăng tốc 15 lần thì Qwen chạy hoàn toàn ngoại tuyến khoảng 5 lần, nhưng xét là miễn phí thì vẫn rất ấn tượng

    • lambda: Tôi cũng chạy Pi trong container theo cách tương tự, rồi kết nối nó với llama.cpp ở container khác
      Tôi cho phép truy cập mạng nhưng chặn thông tin xác thực, và chỉ cho truy cập thư mục làm việc cùng ~/.pi. Tôi dùng laptop Strix Halo với 128GiB bộ nhớ hợp nhất, và vì không thích lập trình bằng công cụ độc quyền nên chưa thể so sánh nghiêm túc với các mô hình frontier
      Tôi vẫn còn hoài nghi về AI nên dành nhiều thời gian phá thử mô hình và xem điểm mạnh điểm yếu hơn là dùng thật, nhưng với agent coding thì tôi chọn Qwen 3.6 35B-A3B thường xuyên nhất. Chat thông thường·dịch thuật thì hay dùng Gemma 4 31B, còn âm thanh thì thường dùng Gemma 4 12B
      Tôi cũng giữ Qwen 3.5 122B-A10B, Qwen 3.6 27B, Nemotron 3 Super 122B-A12B, Step 3.7 Flash, Minimax M2.7, GPT-OSS 120B, nhưng trong cấu hình kiểu này thì Qwen 3.6 35B-A3B hiện khá gần với sweet spot cho lập trình
    • geophile: Trải nghiệm của tôi gần như y hệt. Bạn phải lập kế hoạch cực kỳ cẩn thận, chia việc thành các bước nhỏ độc lập, và phần thiết kế cũng phải do con người viết thật rõ ràng
      Nếu để qwen tự điền các chi tiết thì nó sẽ rơi vào vòng lặp ngay trước lúc viết. Vấn đề không chỉnh sửa được cũng rất lạ, nên tôi đã sửa AGENTS.md để hạn chế chỉnh sửa theo hướng viết lại thay vì biên tập, và điều đó có giúp một chút
    • adyavanapalli: Với công cụ chỉnh sửa, có thể cân nhắc cách tiếp cận dựa trên hash: băm từng dòng mã và khi thay thế thì tham chiếu bằng hash đó
      Bạn có thể xem cách làm tại https://blog.can.ac/2026/02/12/the-harness-problem/. Tôi chưa benchmark đúng nghĩa, nhưng cảm giác là lỗi chỉnh sửa đã giảm, dù có thể khác nhau tùy môi trường

  • horsawlarway: Với mục đích cá nhân, tôi đã hủy gói Claude 100 đô mỗi tháng và thay bằng pi harness trỏ tới unsloth studio cùng các mô hình Qwen·Gemma
    Trên cỗ máy dual RTX3090 tôi lắp từ khoảng 5 năm trước, tôi chạy unsloth/Qwen3.6-35B-A3B-MTP-GGUF và unsloth/gemma-4-26B-A4B-it-GGUF với lượng tử hóa UD-Q4_K_XL; cả hai đều xử lý khoảng 150tok/s và toàn bộ ngữ cảnh 300k trong VRAM
    Nó không tốt bằng Claude, nhưng miễn phí, và với nhu cầu cá nhân thì khác biệt đó không thành vấn đề lớn. Tôi cũng gắn OpenClaw vào cùng máy chủ suy luận đó, và đó là một trường hợp sử dụng khá hợp với mô hình cục bộ
    Ví dụ, tôi làm launcher thay thế cho Android TV, cổng quản trị cho dịch vụ k8s, tích hợp·tự động hóa Home Assistant, quản lý đi chợ·thực đơn, và workflow tạo tài sản 3D bằng ComfyUI. Nếu là phần mềm kiếm tiền thì tôi vẫn khuyên dùng nhà cung cấp trả phí, nhưng mô hình cục bộ cũng làm được khá nhiều thứ rất hay

    • rootlocus: Hai chiếc RTX3090 giá khoảng 4.400 đô, nghĩa là ngay cả khi chưa tính tiền điện và linh kiện khác thì cũng tương đương 3,6 năm Claude 100 đô/tháng
    • kpw94: Nếu bạn đang chạy gemma với lượng tử hóa UD-Q4_K_XL thì cũng nên xem thử mô hình QAT như unsloth/gemma-4-26B-A4B-it-qat-GGUF
      Tham khảo https://huggingface.co/unsloth/gemma-4-26B-A4B-it-qat-GGUF và https://blog.google/innovation-and-ai/technology/developers-.... Bản cập nhật ngày 9 tháng 6 cũng đã thêm hỗ trợ MTP
    • twothreeone: Tôi cũng đã chạy chính unsloth/Qwen3.6-35B-A3B-MTP-GGUF trên một chiếc 3090 đơn, ngữ cảnh 128k, lượng tử hóa Q4_K, và đạt khoảng 40~60tok/s
      Điều khó chịu nhất là chất lượng đầu ra trong các tác vụ lập trình thực tế có độ phức tạp trung bình. Tôi cứ phải liên tục chuyển qua lại giữa “đẩy bằng prompt” và “tự triển khai”, nên gánh nặng chuyển đổi nhận thức khá lớn, và cứ vài phút lại phải tự đánh giá xem là do mình giao việc sai hay do mô hình chưa đủ tốt
      Nó cũng không giỏi chuyển từ chi tiết triển khai cấp thấp sang thiết kế cấp cao, đến cả bảng biểu cũng không render trơn tru. Tôi không gặp những vấn đề này với Claude, nên hiện giờ khó coi đó là phương án thay thế, dù tôi hy vọng vài tháng nữa sẽ khả thi. Tôi đã thay Claude CLI bằng aider, nhưng lựa chọn này cũng chưa chắc là tối ưu nhất

  • bluejay2387: Tôi xử lý khoảng 90% việc lập trình bằng Qwen 3.6 27B cùng Open Code, kỹ năng tùy chỉnh và Semble
    Nó không thông minh bằng CC hay Codex, nhưng vẫn làm xong được phần lớn công việc. Tôi có RTX 6000 nên TPS đủ nhanh, mà GPU này vốn cũng dùng cho việc khác
    Ban đầu tôi chỉ thử xem có thể tiến gần các mô hình frontier đến mức nào, nhưng nó đủ tốt nên tôi cứ tiếp tục dùng. Với các việc thật sự phức tạp hoặc tinh chỉnh UI thì tôi vẫn quay lại Codex, và có vẻ UI là điểm yếu nhất của Qwen
    Tôi không hẳn khuyến nghị vậy. Không nhiều người có RTX 6000, và chi phí của nó bằng vài năm thuê bao MAX CC hoặc Codex. Dù vậy, hướng này có vẻ có triển vọng và vài năm nữa có thể sẽ thực sự thực dụng
    Với ngữ cảnh 256k, tôi đặt compact target ở 75%, và khi cuộc trò chuyện vượt 100k thì chất lượng lẫn tốc độ bắt đầu giảm, sau 150k thì thành rất có vấn đề. Tôi cũng đã thử Qwen 3.5 122B, nhưng khả năng code kém hơn hẳn 3.6 27B. Gemma 4 31B thì tốt cho việc khác, nhưng code vẫn thua Qwen, còn Nemotron Super 120B cũng code kém hơn Qwen, điều này khá bất ngờ

    • heipei: Tôi chạy Qwen 3.6 27B Q6 bằng llama.cpp trên RTX 5090, và giờ chỉ dùng pi agent
      Vì là chạy cục bộ nên tôi hoàn toàn không phải bận tâm đến giá token, hạn ngạch, múi giờ hay độ nhạy của dữ liệu. Tôi giới hạn điện GPU từ 600W xuống 450W thì ngay cả lúc suy luận máy vẫn rất êm
      Tôi dùng nó không chỉ để code mà còn cho nhiều việc lặt vặt hằng ngày. Tôi giao cho nó các việc như commit vào branch rồi tạo PR, lấy hóa đơn chưa thu và quá hạn bằng Stripe CLI để đối chiếu với CSV ngân hàng, tóm tắt nguyên nhân tải hiện tại bằng thông tin xác thực Elasticsearch, hoặc kiểm tra codebase có hỗ trợ X hay không và chỗ triển khai nằm ở đâu
    • bo1024: Qwen3.5-122B thực ra là Qwen3.5-122B-A10B
      A10B là mô hình mixture-of-experts nên mỗi lần chỉ kích hoạt 10B tham số, còn Qwen3.6-27B là mô hình dense với toàn bộ 27B tham số luôn được kích hoạt. Vì vậy trong nhiều tác vụ, mô hình dense 27B có thể tốt hơn 122B-A10B
    • user43928: Ở chỗ làm tôi bị buộc phải dùng Qwen 3.6 27B và cảm thấy nó gần như vô dụng
      Tự làm còn hơn, vì nó viết triển khai rất tệ hoặc debug hoàn toàn sai. Ngoài một chức năng tìm kiếm thông minh hơn chút thì mọi thứ dưới Sonnet đều có cảm giác là lãng phí thời gian
      Việc dùng Codex để tinh chỉnh UI cũng thấy lạ. Codex nổi tiếng là làm UI tệ và còn thua rất xa Claude Opus. Altman cũng đã đăng là họ đang cải thiện phần này trong model tiếp theo

  • pierotofy: Tổ hợp Llama.cpp + Qwen3.6-35B(MTP) + OpenCode khá có năng lực trên một chiếc RTX 3090 đơn, và nhanh hơn phần lớn các mô hình đám mây
    Chất lượng cho cảm giác như đang dùng mô hình top đầu của 8~12 tháng trước. Cấu hình được tôi ghi lại tại https://github.com/pierotofy/LocalCodingLLM/

    • jacobgold: Nếu là “chất lượng mô hình top đầu của 8~12 tháng trước” thì quá ổn cho mục đích hobby, nhưng để lập trình viên chuyên nghiệp dùng làm công cụ chính cho coding agent thì theo tôi ngưỡng quyết định đã đến từ khoảng 6 tháng trước, khi Opus 4.6 xuất hiện
    • trueno: Tôi có MacBook Pro M4 Max 128GB và muốn nghịch thử mấy thứ này, nhưng không có nhiều thời gian
      Tôi khá muốn nghe trải nghiệm của người dùng Mac với cấu hình tương tự. Tôi thấy tranh luận về local khá nhiều nhưng mốc tham chiếu cứ thay đổi liên tục và các thuật ngữ cũng chưa quen. Tôi muốn biết một cách khách quan cảm nhận về những gì mất đi và có được khi chuyển sang local
    • atomicnumber3: Giờ tôi hoàn toàn không còn muốn dùng Claude nữa

  • codinhood: Có lẽ câu hỏi này sẽ không nhận được nhiều câu trả lời “thật” đâu. Hiện tại chi phí cơ hội của việc không dùng mô hình mới nhất và tốt nhất là quá lớn
    Dù có khảo sát hằng tháng thì kết luận vẫn vậy. Thời gian, công sức và chi phí để đưa mô hình local cùng các công cụ code xung quanh lên gần mức Sonnet/Opus của Claude Code hiện vẫn chưa đáng
    Nếu điều đó đã đáng thì nó đã đủ mang tính phá vỡ để thành tin tức rồi. Không phải tôi phủ nhận khả năng ai đó đã giải được, nhưng đây giống dao cạo Occam để tránh lao vào một hang thỏ quá sâu

    • pyeri: Con tàu FOMO của chi phí cơ hội đó rồi cũng sẽ có điểm bão hòa, và theo tôi thì đã qua rồi
      Các mô hình cỡ Mythos là đỉnh cao hiện nay về suy luận, nhưng với miền bài toán mà đa số lập trình viên đang cố giải thì chúng không hữu ích hơn bao nhiêu. Mức quanh 4.8 của dòng Sonnet/Opus hiện tại nhiều khả năng sẽ là mặt bằng được doanh nghiệp dùng rộng rãi
      Mô hình local thì chưa tới đó, nhưng có thể dùng các dòng DeepSeek, Kimi, GPT, MiniMax với giá rẻ qua API như NVIDIA, OpenRouter, Groq, và chúng khá gần mức Sonnet
    • mark_l_watson: Có vẻ kết luận cũng giống vậy. Tôi đang định chuyển sang một hệ thống phân tầng đi từ local, sang API thương mại kiểu OpenCode + DeepSeek v4 flash, rồi đến DeepSeek v4 Pro
      Làm vậy thì vẫn xử lý được các việc cần thiết, đồng thời có thể dần chuyển nhiều thứ hơn sang local. Ngay trên cùng phần cứng, thiết lập local giờ đã tốt hơn nhiều so với 2 tháng trước, và nếu so với 6 tháng trước thì là cải thiện rất lớn
    • gunapologist99: Thay vì Occam thì có lẽ nên nghĩ theo Pareto
      Nếu thật sự tin rằng chỉ vài năm nữa sẽ đạt tới đó, thì tốt hơn là bắt đầu nghịch từ bây giờ; đặc biệt với các dự án ngắn hoặc nhỏ, hay các dự án lớn nhưng được mô-đun hóa tốt, bạn có thể sẽ khá bất ngờ

  • sosodev: Câu hỏi này có phạm vi về năng lực và kỳ vọng quá rộng. Nếu chỉ chạy model 8B mà lại mong vibe coding hay one-shot thì khá khó
    Nếu có thể chạy được model cỡ khoảng 30B, thì với các tác vụ có phạm vi phù hợp và được định nghĩa rõ ràng, nó làm khá tốt. Hiện trong tầm này, Gemma4-31B và Qwen3.6-27B có vẻ là tốt nhất
    Nếu muốn suy luận nhanh hơn thì có thể chuyển sang model MoE, nhưng với đa số tác vụ thì chất lượng giảm thấy rõ. Các tác vụ phạm vi nhỏ thì one-shot hoặc vibe coding cũng làm được, nhưng vẫn tốt hơn nhiều nếu có hướng dẫn
    Nếu muốn năng lực cấp frontier thì cần ít nhất 128GB bộ nhớ và năng lực tính toán lớn hoặc rất nhiều kiên nhẫn. Đa số mọi người thiếu tiền hoặc thiếu kiên nhẫn. Sự kiên nhẫn với model local không chỉ là ngồi chờ token, mà còn bao gồm cả công sức cấu hình và vận hành nó cho phù hợp với workflow và phần cứng của mình

    • argee: Trên MacBook M4 Pro, RAM 48GB, tôi dùng Gemma 4 26B A4B để học Rust và xử lý nhiều câu hỏi khác nhau
      Tôi không tin nó sẽ one-shot tốt ngoài những thay đổi cực nhỏ trong IDE hay harness. Dù vậy, nếu con người vẫn cầm lái, nhìn đường và chạy dưới giới hạn tốc độ, thì nó nhanh và đủ tốt như một copilot cho các tác vụ ngữ cảnh nhỏ đến vừa
      So với vài năm trước thì thật đáng kinh ngạc, và nếu không có nó thì có lẽ tôi gần như đã không dùng AI để code. Tôi không thích cảm giác bị chậm lại hay bí vì mất kết nối Internet
    • user43928: Tôi đã bảo các model nhỏ, đặc biệt là GPT 5.4 Mini, chuyển một thay đổi code 10~20 dòng sang file khác, nhưng đến lần thử thứ hai nó vẫn sửa code và chèn bug vào
      Tôi không kỳ vọng độ tin cậy hoàn hảo, nhưng nghĩ rằng nếu chỉ ra điểm khác nhau thì ít nhất đến lần thứ hai nó phải làm đúng. Thực tế, nó còn tự tin nói rằng code đã giống nhau, trong khi lại thêm một bug tinh vi khác
      Tôi không biết loại công việc nào đủ đơn giản để mấy model rác rưởi như thế này xử lý được. Chúng có thể giả vờ có năng lực trong vài phút, nhưng kết quả cuối cùng vẫn sai. Cùng lắm tôi xem chúng phù hợp với tìm kiếm thông minh hơn hoặc tự động hoàn thành

  • mgsram: Sau khoảng 1 năm dùng LLM local, giờ tôi đã ổn định với tổ hợp Qwen3.6 27B dense GGUF, OpenCode và llmster (LM Studio) trên Mac Studio RAM 512GB
    Tôi cũng đã thử Qwen 3.6 35B-A3B, nhưng độ chính xác của model dense cao hơn một bậc, đổi lại là phải hy sinh token/giây. Qwen3.6 27B thường cho khoảng 25~40tok/s
    Ban đầu tôi dùng cho các công cụ đơn giản, nhưng 3~4 tháng gần đây tôi thực sự dùng nó cho coding cấp production trong stack phần mềm ô tô C/C++ và các công cụ Python. Tốc độ thấp cũng lại giúp tôi tiến hành với nhịp độ phù hợp hơn
    Với phát triển mới hoặc viết lại, tôi cùng Sonnet tạo ra thiết kế, kiến trúc, suy luận và kế hoạch thực thi chi tiết, rồi chia nhỏ chúng ra để đưa vào prompt một cách chính xác. Với công việc trên code có sẵn thì cần phán đoán, và khi cảm thấy giới hạn của model local thì tôi quay lại Claude Code
    Gần đây với Qwen 3.6 tôi đã làm việc viết lại toàn bộ một dịch vụ quản lý nguồn điện viết bằng C dựa trên mã C++ hiện có, một parser đặc tả Excel phức tạp, và một công cụ dịch nội dung CJK sang tiếng Anh để đưa vào KG

  • 3abiton: Mọi người đều nhắc đến Qwen, nên tôi cũng đang chạy Qwen 3.6 35B Q8(MTP) với Strix Halo và llama.cpp
    Nó cho khoảng 40~50t/s và hiệu năng thực sự rất tốt. Tôi đã dùng trực tiếp với forge-code trong zsh, và ở ngữ cảnh dài trên 150k thì chất lượng giảm xuống và bắt đầu quên

  • wsintra2022: Đọc các bình luận ở đây thật khó phân biệt ai là bot của phía các nhà cung cấp AI đang cố can ngăn dùng local, và ai là người thực sự từng có trải nghiệm tệ với model AI local
    Chạy Qwen 3.6 27B 8k quantized trên Mac Studio 64GB không phải kiểu siêu năng lực vạn năng cấp frontier, mà đơn giản là tốt. Nó miễn phí, riêng tư, và điều kỳ diệu là khiến một kỹ sư dày dạn từ lười thành còn lười hơn nữa
    Tôi dùng llama.cpp và opencode để lên kế hoạch thay đổi code rồi cho nó thực thi, sau đó nằm võng, rửa bát hoặc làm việc khác. Tôi vào kiểm tra bằng tmux và ssh. Chính điểm này mới thực sự đáng kinh ngạc

    • epolanski: Trong ngành “engineering” phần mềm, khá nhiều ninja MIT Leetcode vẫn viết ra thứ slop React+Tailwind rò rỉ bộ nhớ, không dùng được, nên mức chuẩn cơ bản vốn đã rất thấp

  • garethsprice: Trên Ada 4000 với VRAM 20GB, tôi dùng OpenCode + OhMyOpenCode + Qwen 3.6 35B-A3B Q_4_KM, tốc độ sinh ra khoảng 55tok/s
    Vì OpenCode gắn vào rất nhiều ngữ cảnh nên cảm giác thực tế chậm hơn con số đó. Pi cũng được nhắc đến nhiều nên tôi định sớm xem thử
    Tôi dùng Opus để lập kế hoạch, rồi để agent local làm theo, sau đó dùng Opus để kiểm chứng. Chưa phải local 100%, nhưng các model này đang dần trở thành một phần của workflow production
    Hiện tại có thể vẫn chưa đáng làm, trừ khi bạn là người thích vọc và sẵn sàng bỏ thời gian tiền bạc như một sở thích. Nó không tốt bằng Opus hay các model frontier khác, nhưng trong phạm vi mà công việc lặp đi lặp lại ngày càng nhiều thì nó “đủ tốt”
    Không cần Rolls Royce thì vẫn có thể đi siêu thị bằng chiếc Corolla cũ. Nhờ vậy mà các workflow mới vốn quá tốn kém nếu dùng frontier LLM trở nên khả thi. Tôi đã để nó chạy fuzz test qua đêm như một người dùng thật với Chrome devtools MCP, thậm chí còn kiểm tra cả ảnh chụp màn hình bằng multimodal, và nghĩ đến chi phí Claude+kèm screenshot thì thật đáng kinh ngạc
    Câu “chậm hơn frontier 12~18 tháng” có vẻ đúng. Sau 12~18 tháng nữa, có lẽ sẽ chạy được model local cỡ Opus với giá dưới 5.000 USD, nhưng các model frontier lúc đó cũng sẽ còn tiến xa hơn

  • arjie: Không hẳn là local, cũng không phải coding tương tác, nhưng tôi đang chạy DeepSeek V4 Flash bằng hai chiếc RTX Pro 6000 Blackwell
    Tốc độ thô là 160tok/s nhưng đây là model suy luận. Mục đích của tôi là tự động viết code và tự động review cho các hệ thống khác. Khi thỉnh thoảng để Pi viết code thì nó rất nhanh, nhưng vì thói quen nên tôi chủ yếu vẫn tiếp tục dùng CC và Codex

    • akersten: Tôi tò mò không biết bạn kiếm RTX Pro 6000 Blackwell ở đâu
      Những trang tôi tìm thấy либо đều hết hàng, либо chỉ bán cho doanh nghiệp, hoặc trông rất đáng ngờ
    • leptons: Tôi tò mò không biết đã đo mức tiêu thụ điện năng của dàn này chưa. Tôi khá quan tâm chi phí mỗi tháng sẽ là bao nhiêu

  • stymaar: Chạy Qwen3.6-35B-A3B trên Strix Halo 128GB Bosgame M5
    VRAM thì quá dư đối với model này, nhưng Qwen chưa phát hành bản Qwen3.6 122B phù hợp nhất với phần cứng của tôi. Bù lại, tiền điện gần như không đáng kể. Vốn là chip laptop nên lúc nhàn rỗi gần như không tốn bao nhiêu, ngay cả khi xử lý prompt cũng chỉ hơn 120W một chút
    Qwen3.6 hiệu quả bất ngờ, nên tôi chỉ thỉnh thoảng dùng Claude, khoảng 10% tổng nhu cầu. Ngay cả gói rẻ nhất cũng vẫn dưới hạn mức. Tốc độ khoảng 800tps khi xử lý prompt, 50tps khi sinh token, và không dùng speculative decoding

    • manmal: Không biết bạn đã thử bản dense 27B chưa. Nó tốt hơn nhiều cho coding

  • Kostic: Tôi nối VSCode với llama.cpp để chạy Qwen 3.6 27B hoặc Gemma 4 31B cho nhu cầu cá nhân, đủ tốt để bỏ hẳn các gói cloud subscription
    Qwen chạy trên GPU đầu tiên với ngữ cảnh q4@176k, MTP đạt khoảng 70~50tok/s nên khá ổn cho coding. Gemma dùng cả hai GPU, ngữ cảnh q8@64k và xử lý phân tích cảm xúc tài liệu, tóm tắt, hiệu đính, dịch ở 25tok/s
    Hơi chậm cho workflow theo lô nhưng vẫn dùng được. Có lẽ còn tăng thêm nếu llama.cpp hỗ trợ MTP trong chế độ tensor split
    Ở chỗ làm thì tôi vẫn dùng frontier LLM vì không phải tự trả chi phí, và dĩ nhiên là tốt hơn. Hy vọng khoảng 1 năm nữa sẽ có model 30B đạt mức Sonnet 4.6/Opus 4.5
    Xử lý prompt bắt đầu ở 800t/s rồi giảm xuống 400t/s. Prompt mở đầu thường là 16k~24k token nên mất 60~90 giây để xử lý; không lý tưởng nhưng chấp nhận được

  • jodoherty: Dùng Gemma 4 31B trên RTX Pro 6000 Blackwell qua Pi cho toàn bộ tác vụ agent coding
    Tôi thấy nó hữu ích, và side project này khá giống cách tôi scoping và xử lý project ở chỗ làm: https://git.theodohertyfamily.com/wg-wrap.git/tree/README.md https://git.theodohertyfamily.com/wg-wrap.git/tree/CASE_STUD...
    Cần áp dụng kiến trúc cẩn thận và rất nhiều TDD. Xử lý phần khó từ sớm rồi bọc lại bằng giao diện đơn giản, dễ dùng để loại bỏ rủi ro kỹ thuật
    Có project nhanh hơn 2~3 lần so với tự viết, còn với những project nhàm chán hoặc phạm vi rộng thì giúp gom ý tưởng và thử nghiệm nhanh, tiết kiệm 5~10 lần thời gian
    Thiết lập của tôi luân phiên giữa vLLM dùng nvidia/Gemma-4-31B-IT-NVFP4 và llama.cpp dùng unsloth/gemma-4-31B-it-qat-GGUF có MTP. Công suất GPU bị giới hạn ở 400W. Hiện cấu hình llama.cpp cho ra 60~150t/s tùy theo tỷ lệ chấp nhận MTP draft, còn prefill là 1500~4000t/s tùy độ dài và độ sâu ngữ cảnh

  • jborak: Tôi chạy Qwen3.6 27B MTP Q6_K trên llama.cpp bằng bốn chiếc RTX 5070 và AMD Threadripper 1950X thế hệ đầu, và nó hoạt động tốt như Pi hằng ngày
    Tốc độ khoảng 50~60tok/s. Tôi cũng kết nối các app khác như OpenWeb UI, và gần đây đặt cổng LLM Bifrost làm điểm vào mặc định để truy cập model
    Tôi cũng đã thử Qwen3.6 35B A3B, nhưng 27B hợp hơn cho coding. Là model dense nên chậm hơn, nhưng chất lượng có vẻ tốt hơn nhiều. 35B A3B đạt 130~140tok/s ở non-MTP nên nhanh điên rồ
    Không nhất thiết phải cần bốn chiếc 5070 để chạy Qwen3.6 27B; ba chiếc, thậm chí có thể hai chiếc cũng đủ. Chỉ là nếu dùng MTP để tăng tốc 27B thì draft model cần ngữ cảnh riêng nên tốn thêm bộ nhớ
    Cũng cần nhớ là system prompt của công cụ sẽ được nạp vào model ở mỗi cuộc trò chuyện. Khi mới bật Pi thì phản hồi ban đầu rất nhanh, nhưng khi tương tác qua Hermes CLI thì mỗi prompt mang theo rất nhiều ngữ cảnh như skills, tools... và chúng tồn tại đến hết cuộc trò chuyện nên chậm hơn hẳn
    Quyền riêng tư là một điểm hay, nhưng việc không có quota và không phải lo mức sử dụng cũng rất tốt. Nếu tương lai là “loop engineering” thì với model cloud bạn sẽ đốt token và tiền. Hệ thống của tôi tiêu thụ 200W khi nhàn rỗi, 350~450W dưới tải suy luận cao, và decoding không quá hiệu quả nên GPU thực ra hay ngồi không hơn bạn nghĩ. Những tiến bộ kiểu diffusion có thể giúp tăng tốc decoding và tận dụng GPU nhàn rỗi tốt hơn

    • zakisaad: Tôi tò mò vì sao bạn lại chọn 5070 cho cấu hình 4 card
      Ấn tượng ban đầu của tôi là nó thiên về năng lực tính toán nhưng thiếu VRAM, nên hợp cho game thủ hơn là chạy LLM. Desktop của tôi cũng dùng 5070

  • cuttysnark: Tôi đã có chút thành công với model local bằng cách xâu chuỗi nhiều agent thành workflow
    Mỗi agent dùng prompt khác nhau và model ollama khác nhau tùy vai trò. Agent quản lý dự án hoặc schema (qwen3:14b) không dùng cùng model với agent coding (qwen2.5-coder:7b)
    Giữa mỗi bước có orchestrator và tác vụ Playwright, cố gắng phơi bày lỗi cho agent đã tạo ra khối mã trước đó. Chỉ những khối không lỗi mới được chuyển sang bước tiếp theo
    Cải tiến lớn nhất là đưa vào định nghĩa dịch vụ backend-for-agents để agent schema chỉ tạo manifest dựa trên tác vụ rồi chuyển cho agent tiếp theo. Tóm lại là định nghĩa workflow để tách nhỏ agent chỉ làm những việc cực kỳ cụ thể, rồi chuyển tiếp sang bước sau. Làm vậy giúp chúng không bị lạc hướng, đồng thời tạo ra điểm để con người can thiệp vào những luồng đã thành công 25% hay 90%

    • pianopatrick: Tôi nghĩ sẽ hay nếu có benchmark và cuộc thi cho workflow kiểu này để biết cái gì thực sự hiệu quả
      Kiểu như “chỉ dùng GPU tiêu dùng này, với model và workflow bạn muốn, xem giải được benchmark xyz tốt đến đâu”. Có thể làm thành “The Local AI challenge”, cho người tham gia tối đa 1 giờ rồi chấm theo tỷ lệ trả lời, độ chính xác và tổng thời gian
    • sowbug: Tôi tò mò liệu bạn đã thử cho các agent cạnh tranh với nhau chưa
      Ví dụ giao cùng một tác vụ coding cho hai model, hoặc cho cùng một model với seed khác nhau, rồi để một reviewer chọn kết quả tốt hơn. Cũng có quan điểm cho rằng não người hoạt động như hàng nghìn cột vỏ não tí hon nhìn tình huống hơi khác nhau rồi bỏ phiếu theo đa số

  • HappySweeney: Tôi có Optane và rất nhiều RAM, nên đã thử dùng một mô hình gần với full model ở tốc độ khoảng 0,7t/s để viết hàm qua đêm
    Bài test hiện tại là chuyển một hàm Scala thành hàm chuyển vị ma trận bit dùng AVX512. Các mô hình đám mây xử lý dễ dàng, nhưng Kimi 2.6 và GLM 5.1 thì thất bại thảm hại

  • etoxin: Vẫn chưa thay thế được. Trong dự án công việc tôi dùng openspec, và để bắt chước thiết bị cục bộ mà không tốn quá nhiều tiền, tôi trả phí để dùng các phiên bản được host của những mô hình cục bộ nổi tiếng mới nhất
    Phần lớn các mô hình cục bộ nhỏ vẫn không làm tool calling tử tế, nhưng các mô hình lớn hơn thì giờ đã làm khá ổn. Một điểm phía local vẫn chưa tính đến là các kỹ sư làm việc hiệu quả thường chạy nhiều CLI chat cùng lúc với git worktree. Tôi thường mở 3 worktree và 3 CLI chat

  • blurbleblurble: Hiện tại tôi thấy giới hạn nằm ở tính khả dụng của các harness thay thế hơn là ở bản thân mô hình, vì chúng kỳ lạ là lại thiếu các tính năng như quản lý hàng đợi, ngắt, sub-agent và mục tiêu

    • coder543: Hoàn toàn đồng ý. Việc OpenCode không thực sự cố hỗ trợ local LLM cho ra hồn cũng rất khó chịu
      Vẫn có thể làm cho OpenCode chạy được, nhưng việc cấu hình rất thủ công và thô. Tôi đã viết một script tự động chuyển cấu hình llama-server sang cấu hình OpenCode, có giúp ích nhưng vẫn chưa lý tưởng
      Tôi đã nghiêm túc cân nhắc việc làm thêm một coding harness nữa vào thời gian rảnh. Tôi có vài ý tưởng để làm nó tốt hơn
    • horsawlarway: Pi ổn đấy
      Tôi đã dùng CLI agent của Claude, Cursor, Pi, các harness tùy biến tự làm, cả gastown nữa, và Pi đơn giản là đủ dùng. Nó làm được việc cần làm, bộ công cụ mặc định ổn, tích hợp tốt với công cụ khác, và khiến tôi phải bận tâm ít hơn
      Nếu bạn có thể chạy các model quanh mức 30B ở tốc độ chấp nhận được thì nhiều người sẽ khá ngạc nhiên với Pi. Gắn thêm các extension như https://pi.dev/packages/pi-mcp-adapter?name=mcp và https://pi.dev/packages/pi-web-access?name=search thì còn có MCP access tới công cụ web, tìm kiếm perplexity, https://browsermcp.io/ để điều khiển Chrome, và https://github.com/mozilla/firefox-devtools-mcp cho Firefox
      Nó không tốt bằng các mô hình top-tier được trợ giá, nhưng miễn phí và vẫn có năng lực. Cá nhân tôi cũng dùng https://pi.dev/docs/latest/sdk rất vui, trong khi các nhà cung cấp khác tính hàng nghìn đô mỗi tháng cho kiểu truy cập API này
    • Insanity: Tôi đã nghe nhiều điều tốt về pi.dev nhưng vẫn chưa thử. Nó có thể giải quyết được một phần những tính năng còn thiếu mà bạn nhắc tới

  • _bobm: Khi nói đến mô hình Claude/GPT, phải nghĩ xem “mô hình” đó thực sự là gì
    Cứ nhớ cách GPT có thể gửi từng phần suy nghĩ một, rồi còn gắn cả phần tóm tắt bằng Markdown header cho chính khối suy nghĩ đó. Nếu quan sát endpoint API và hành vi đầu ra, các mô hình gọi là SOTA không hề đơn giản như vẻ ngoài, và về mặt hạ tầng thì hoàn toàn không cùng loại để so với local model
    Vận hành ở quy mô này đòi hỏi lượng orchestration khổng lồ, và các ràng buộc đó dẫn tới những đổi mới không được nói ra. Tôi không nghĩ là không thể bắt kịp, nhưng việc phục vụ local model bằng llama hay vLLM mới chỉ ở mức bảng chữ cái A, B, C mà thôi
    Thứ thực sự cần là tái tạo lại phần orchestration được ám chỉ ở trên. “Mô hình” SOTA không phải một mô hình đơn lẻ mà là orchestration sâu của nhiều mô hình hoạt động cùng nhau. Vì vậy một mô hình đơn lẻ sẽ không theo kịp cho đến khi nó tái tạo được orchestration đó trong quá trình huấn luyện và kiến trúc
    Tôi cho rằng bản thân một mô hình trong cấu hình orchestration được đưa cho người dùng phổ thông cũng không vượt trội quá nhiều so với Qwen 3.6. Khi đổi góc nhìn, bạn sẽ bắt đầu thấy quy mô của “phép màu”

    • XCSme: Tôi không hiểu vì sao bạn nghĩ mô hình SOTA là một orchestration sâu của nhiều mô hình
      Tôi cũng muốn thấy ví dụ cụ thể về việc GPT gửi phần suy nghĩ kèm tóm tắt Markdown header

  • cheekygeeky: Kỹ sư phần mềm của chúng tôi là một trong những người thông minh nhất tôi từng gặp, và anh ấy dùng OpenCode và Tmux với các mô hình mã nguồn mở
    Anh ấy thích DeepSeek nhất cho việc code và gọi nó là “khá tốt”. Chạy trên i9, 128GB RAM và hai chiếc 3090. https://www.msn.com/en-us/news/technology/china-s-open-deeps...

  • pianopatrick: Sẽ rất hay nếu có benchmark và cuộc thi cho kiểu workflow này để biết cái gì thực sự hiệu quả
    Kiểu như “chỉ dùng GPU consumer này, với mô hình và workflow tùy chọn, giải benchmark xyz tốt đến đâu”. Tôi muốn thấy một cuộc thi kiểu “The Local AI challenge”, nơi người tham gia có tối đa 1 giờ và được chấm điểm theo tỷ lệ trả lời, độ chính xác và thời gian hoàn thành

  • bravetraveler: Tôi dùng gần như hoàn toàn theo kiểu “ăn tự nhiên”, và mọi mức sử dụng LLM ít ỏi của tôi đều là local
    Trên hệ thống Strix 128GB, các biến thể Qwen hoặc Gemma ít dense hơn cho tốc độ đầu ra 50~80 tok/s. Tôi không có ý định đăng ký Anthropic/OpenAI hay bên nào khác, và kể cả nếu đây là local model cuối cùng thì tôi cũng không cần. Việc dùng công cụ trong mô hình bù được cho nỗi lo về tính cập nhật

  • GodelNumbering: Với tư cách là người nói chuyện với LLM cả ngày, tôi thấy tổ hợp mô hình frontier mã nguồn mở + harness tốt đã là đủ dùng rồi
    Triển khai local sẽ cần thêm một hoặc hai thế hệ phần cứng nữa mới có thể chuyển hẳn sang. Tuy vậy, vì các hãng phần cứng đang ưu tiên rất mạnh mảng datacenter, nên có thể thời điểm đó sẽ không đến sớm

  • milchek: Đã thử trên MacBook Pro 36GB nhưng không đạt thành công đáng kể khi vượt quá các tác vụ rất cơ bản
    Ngay cả khi dùng mô hình nhỏ thì ngữ cảnh cũng nhanh cạn và lại chậm. Để đạt hiệu năng tạm ổn có vẻ cần 128GB bộ nhớ, khiến chi phí phần cứng tăng mạnh
    Cuối cùng chỉ là bài toán nên trả tiền thuê bao cho các mô hình frontier hay đổ số tiền đó vào thiết bị. Tất nhiên nếu quyền riêng tư là quan trọng thì gần như không còn lựa chọn nào khác ngoài chi tiền cho phần cứng cao cấp

  • acc_297: Tôi tò mò liệu có ích không nếu áp dụng RLHF một cách thường xuyên cho mô hình cỡ trung ở mỗi prompt để tinh chỉnh theo thói quen sử dụng cá nhân
    Tôi không rõ việc tự tinh chỉnh mô hình sẽ làm hỏng hay cải thiện nó. Nếu kiên trì phản hồi thì sẽ tốt nếu có thể giảm bớt các tật của mô hình phổ dụng như nịnh quá mức, dài dòng, hay cái thói khó chịu là cứ cố giải thích bằng ví dụ so sánh, nhưng tôi không biết chỉ phản hồi prompt của một cá nhân có đủ hay không
    Tôi cũng nghe nói các agent nội bộ của công ty được tinh chỉnh bằng tài liệu nội bộ đôi khi vẫn hành xử kỳ quặc và không nhất thiết hữu ích hơn mô hình chuẩn. Sẽ hay nếu có thể chỉnh sửa mọi phản hồi của agent rồi tinh chỉnh dựa trên khác biệt giữa bản gốc và bản đã sửa
    Cá nhân tôi sẽ bỏ bớt rất nhiều tính từ và gọt câu trả lời về phần cốt lõi, nhưng nhìn vào công trình của các nhà nghiên cứu alignment như Owain Evans thì tôi lo kiểu điều chỉnh này có thể đẩy mô hình sang những xu hướng khó lường

    • htrp: Cursor đang làm chuyện đó. Có lẽ họ dùng Fireworks làm nhà cung cấp: https://cursor.com/blog/real-time-rl-for-composer
    • rolisz: Tôi muốn thử điều tương tự với agent OpenClaw
      Công trình của Owain Evans hình như là SFT. Có người trên Twitter nói RL ít dễ dính hiện tượng mà ông ấy chỉ ra hơn, nên tôi muốn tự thử nghiệm

  • heisenbit: Cần làm khá nhiều việc cấu hình, nhưng trong quá trình đó tôi học được rất nhiều
    Trên M4 MBP 48GB tôi chủ yếu dùng qwen/qwen3.6-35b-a3b mlx, và chỉ còn vừa đủ tài nguyên cho Docker dev-container cùng các tác vụ cơ bản. Tôi chạy nó bằng LM Studio và dùng trong VSCode
    Việc thay đổi system prompt để cải thiện tích hợp công cụ đã tạo ra khác biệt lớn. Trước đó nó thường tái tạo lại mã thay vì áp dụng thay đổi, nên thường phá nhiều hơn giúp
    Tôi chủ yếu dùng chế độ nguồn điện thấp để tránh tiếng ồn và nhiệt, kể cả khi đang cắm sạc. Hiệu năng tối đa nhanh hơn khoảng gấp đôi nhưng điện năng tiêu thụ thì hơn gấp đôi
    Những gì làm được chỉ cỡ tái cấu trúc đơn giản một trang, còn tách Pinia store thì thất bại. GPT-5.4 xử lý việc này không vấn đề gì. Tôi nghĩ nếu chỉnh thêm hướng dẫn dùng công cụ và các công cụ hỗ trợ xung quanh thì hiệu năng còn có thể tăng thêm

  • nfrankel: Tôi đã thử và về lý thuyết thì nó hoạt động: https://blog.frankel.ch/tokensparsamkeit-coding-assistants/#...
    Kết quả tùy thuộc vào mô hình, và cuối cùng giới hạn vẫn là máy tính. Thiết bị của tôi tiếc là không kham nổi

  • K0balt: Tôi có kết quả khá tốt với qwen 3.6 27b dense
    Tùy tác vụ, nó tương đương Claude Haiku 4.5, thậm chí đôi lúc có thể ngang mức Sonnet

    • kadoban: Tôi tò mò bạn dùng công cụ nào để vận hành quy trình đó
    • kandros: Với các tác vụ lập trình thì tôi thà hỏi anh hàng thịt còn hơn dùng Haiku

  • jderekw: Thiết bị hằng ngày của tôi là AMD Lemonade
    Tôi bắt đầu với Ollama rồi chuyển sang LMStudio, còn bây giờ thì chuẩn hóa trên AMD Lemonade vì nó giúp theo dõi cRAM, CPU, GPU và gRAM. Nhờ tính năng đa mô hình của Lemonade, tôi có thể dễ dàng chạy stack LLM, speech-to-text, NPU và tạo ảnh
    Nền tảng này cũng chạy được trên chipset Nvidia, Apple, Intel và AMD

  • redox99: Các mô hình như Qwen 35B có thể chạy tại nhà thì không hề gần với Opus hay GPT 5.5
    Các mô hình mở ở tầm đó cỡ khoảng 1T tham số, nên có thể quên chuyện chạy ở nhà đi. Nó giống như lái một chiếc xe cà tàng cũ kỹ; có thể sẽ có nhiều người tự thuyết phục rằng miễn đi từ A đến B là ổn, nhưng thật ra không ổn
    Trừ khi bạn tuyệt đối cần quyền riêng tư, làm cho vui, hoặc ở tình huống đặc biệt như trên máy bay, còn không thì không có lý do hợp lý nào cả. Nếu đến cả 20 đô cho Codex đã được trợ giá mạnh mà bạn cũng không muốn trả, thì dùng API của các mô hình Trung Quốc vẫn vượt xa mấy mô hình nhỏ này

    • pbasista: Tôi muốn biết nhận định “các mô hình có thể chạy tại nhà như Qwen 35B không hề gần với Opus hay GPT 5.5” dựa trên sự thật khách quan hay benchmark nào
    • xgulfie: Đâu cần Ferrari để đi làm

  • sj_tech: Trên Mac Mini 128GB tôi dùng Qwen 3.6 35B A3B cho agent coding qua GitHub Copilot Extension for VSCode
    Nó ổn so với kích thước mô hình, nhưng khi vấn đề quá lớn thì tôi thấy nó rơi vào vòng lặp. Dùng để giao cho nó những việc mình vốn đã biết làm nhằm tiết kiệm thời gian thì tốt

  • julianlam: Trên Framework 13 với 32GB RAM tôi chạy Qwen 3.6 35B-A3B bằng llama.cpp và đạt 15tok/s
    Nó xuất mã và văn bản nhanh hơn tốc độ tôi có thể đọc

  • moezd: Hiện tại vẫn chưa. Nếu không có game thuần Apple hoặc GPU đủ ổn thì dù có nhiều RAM và luồng cũng chỉ đạt khoảng 30~50tok/s, mà đó còn là khi đã tắt thinking
    Nếu không có các tối ưu kiểu này thì mô hình sẽ ngốn MCP, skills và mô tả agent thoải mái, rồi bạn sẽ ngồi nhìn sơn khô trước khi thấy token đầu tiên xuất ra
    Việc phục vụ mô hình cục bộ đòi hỏi phải tiết kiệm mọi token trong cửa sổ ngữ cảnh, hoàn toàn ngược với hướng mà Claude/GPT/Copilot đang đẩy cả ngành đi theo

    • amarshall: thinking không làm thay đổi tốc độ xuất. Tốc độ xuất trung vị của các mô hình Anthropic vào khoảng 40~60t/s

  • mitchell_h: Tôi đã thử nhưng cửa sổ ngữ cảnh không đủ lớn

    • coder543: Qwen3.6-27B hỗ trợ cửa sổ ngữ cảnh 1 triệu token
      Tất nhiên bạn cần phần cứng đủ để chạy với cửa sổ ngữ cảnh như vậy, và trên DGX Spark của tôi, nếu dùng mô hình q4_k_xl với toàn bộ KV cache f16 thì cần khoảng 100GB bộ nhớ
    • lysace: Tôi cũng có kết quả tương tự. RTX 4070 của tôi chỉ có 12GB, nên tôi tò mò liệu 24/32GB có cải thiện đủ để thật sự hữu ích hay không
    • deadbabe: Chỉ cần prompt trực diện hơn thay vì ném ra như một câu hỏi mở

  • drnick1: Tôi tò mò không biết mô hình coding tốt nhất hiện nay có thể chạy trên GPU cao cấp dành cho người dùng là gì.
    Giả sử có RTX 3090/4090 thì cũng muốn biết nên khuyến nghị stack nào. Có phải kiểu kết hợp như Llama.cpp + OpenCode không

  • bijowo1676: Tôi thấy một cách làm khá thú vị là dùng các mô hình frontier đắt tiền để viết và cập nhật tài liệu Markdown như đặc tả ứng dụng, yêu cầu sản phẩm, kiến trúc, rồi để các mô hình rẻ hơn hoặc mô hình cục bộ triển khai theo những đặc tả đó.
    Markdown nén thông tin tốt hơn hàng trăm tệp mã nguồn nên dễ đưa vào cửa sổ ngữ cảnh, nhưng để gọt giũa những phần còn thô thì cần pass thứ hai, thứ ba. Tôi muốn biết có ai đã thử làm theo cách này chưa

  • grmnygrmny2: Tôi có cảm giác phản đối về mặt đạo đức với việc dùng sản phẩm của OpenAI hay Anthropic nên cũng ngại luôn cả việc áp dụng LLM.
    Mô hình cục bộ giải quyết được phần lớn sự phản đối về mặt đạo đức đó, nên tôi đã dùng chúng khoảng một tháng cho công việc và dự án cá nhân. Phần cứng tôi có là các máy Mac 32GB và một PC gaming 3080 10GB, nên giới hạn chỉ tới mức Qwen3.6-35B-A3B với nhiều kiểu lượng tử hóa khác nhau, nhưng như vậy là đủ.
    Tốc độ khoảng 200~400 PP, 20~30 TG, và tôi cũng mất chút thời gian để học cách dùng cho hiệu quả. Có việc thì phải trông chừng hoặc định hướng cho nó, nhưng nhìn chung khá hữu ích.
    Tôi chưa từng dùng CC nên không thể so sánh, nhưng nó đóng vai trò trợ lý tốt hoặc lập trình cặp tốt, từ C++ nhúng cho tới Vue. Nếu chạy được 27B thì sẽ tốt hơn, và đôi khi có những lúc mô hình này có vẻ như sắp hiểu được điều gì đó rồi lại không làm được, nhưng khá hiếm.
    Nó giúp tiết kiệm rất nhiều thời gian trong nhiều tác vụ, và ngay cả với chỉ dẫn khá mơ hồ nó cũng làm tốt việc đào sâu bug rồi sửa chúng. Tôi dùng Pi làm harness.