Local LLM có thể thay thế Claude làm bộ não cho AI assistant cá nhân?

Việc chạy một trợ lý AI cá nhân với hàng chục công cụ tích hợp hoàn toàn trên phần cứng cục bộ nghe có vẻ hấp dẫn nhưng đầy thách thức. Một bài thử nghiệm chi tiết vừa công bố trên Towards Data Science đã tái hiện 27 tác vụ thực tế từ AI agent "Jarvis" – một hệ thống LangGraph kết nối khoảng 90 công cụ như email, lịch, ghi chú, Office, WhatsApp, Discord và cả tạo ảnh – để so sánh năng lực của các model cục bộ với Claude, model API đang vận hành agent này.

Kết quả rất khác biệt giữa hai vòng chạy: trên một chiếc RTX 3090 với context 16K, model 30B chỉ đạt 22,8/100 điểm, rò rỉ cú pháp tool call vào một phần tư số câu trả lời – về cơ bản là hỏng chứ không chỉ là kém hơn. Nhưng sau khi nâng cấp lên 3 GPU RTX 3090 với context 256K, model 122B đạt 80/100 điểm, tiệm cận mức 89,4 của Claude, chi phí chỉ $0,000969 mỗi tác vụ so với $0,763 của Claude – tức rẻ khoảng 787 lần.

Không phải benchmark sạch, mà là thử thách thực tế

Điểm khác biệt lớn nhất so với các bài đánh giá model thông thường là cách thiết kế thử nghiệm. Tác giả không tạo một bộ câu hỏi chung chung mà kéo thẳng 28 tác vụ thực tế (sau đó loại 1 tác vụ vì quá dài) từ Langfuse traces – hệ thống ghi log của Jarvis – trong 90 ngày, chia đều cho 7 nhóm: lịch, code, email, file, tổng quát, tin nhắn và ghi chú.

Claude không được chạy lại trong môi trường sandbox mà dùng chính câu trả lời lịch sử đã được ghi lại trong log. Điều này giúp so sánh công bằng hơn: Claude nhận đúng dữ liệu thật, còn model local được chạy lại qua một harness mô phỏng, với các công cụ ghi (gửi email, ghi lịch, đăng bài…) bị chặn để không gây ảnh hưởng thực tế. Tuy nhiên, dữ liệu mô phỏng được lấy từ chính trace gốc, không phải dữ liệu giả.

Việc chấm điểm do một LLM judge độc lập (claude-opus-4-8) thực hiện, theo thang 1–5 rồi quy về 0–100. Tác giả thẳng thắn thừa nhận một hạn chế: judge cũng là model của Anthropic, nên có khả năng thiên vị cho Claude – và điều này càng đáng lưu ý khi model local đã tiến rất gần ở vòng 2.

Vòng 1: RTX 3090 đơn, context 16K – thất bại toàn diện

Lần thử đầu tiên dùng qwen3-coder:30b trên một GPU RTX 3090 dùng chung với các tác vụ khác trong homelab. Do VRAM bị giới hạn, context window buộc phải hạ xuống còn 16.384 token, trong khi riêng phần hệ thống prompt và tool schema của Jarvis đã chiếm gần hết dung lượng đó.

Kết quả: Claude đạt 89,4/100, còn qwen3-coder:30b chỉ đạt 22,8/100.

Không chỉ thua về điểm số, model này còn bộc lộ hàng loạt lỗi nghiêm trọng:

• Rò rỉ cú pháp tool call: 7/27 câu trả lời (25,9%) chứa đoạn mã thô thay vì một tool call hợp lệ, xuất hiện ngay trong văn bản người dùng đọc được.
• Tool-overlap recall trung bình chỉ 14,8%: model thường gọi sai công cụ hoặc không gọi công cụ nào so với trace gốc.
• Vòng lặp orchestration: 2/27 tác vụ bị kẹt khi liên tục gọi lại cùng một công cụ đã trả lời, không biết tổng hợp kết quả để dừng.

Đáng chú ý, chính model này từng đạt 100% task success trong benchmark trước đó với 17 tác vụ và môi trường đơn giản hơn. Khi đặt vào một agent thực tế với bề mặt công cụ lớn, mọi thứ sụp đổ – minh chứng rõ ràng rằng kết quả benchmark tốt chưa đủ để khẳng định một model có thể làm việc trong môi trường sản xuất phức tạp.

Vòng 2: Ba RTX 3090, context 256K – bước nhảy thực sự

Tác giả nâng cấp lên một hệ thống 3 GPU RTX 3090, tổng cộng 72GB VRAM. Sức mạnh này cho phép chạy qwen3.5 122B (mixture-of-experts) với lượng tham số lớn hơn nhiều, khoảng 53GB weights, phục vụ hoàn toàn trên GPU. Quan trọng hơn, context window tăng lên 256.000 token – gấp 16 lần vòng 1.

Cùng 27 tác vụ, cùng baseline Claude, cùng judge – điểm số là 80,0/100, tức đạt 89,4% điểm của Claude, và có 14/27 tác vụ model local đạt điểm bằng hoặc cao hơn Claude.

Biểu đồ điểm tổng thể cho thấy local model tiệm cận Claude ở vòng 2

Sự cải thiện tập trung rõ rệt ở độ tin cậy. Tỷ lệ rò rỉ cú pháp tool call giảm từ 7/27 xuống còn 0/27 – không còn một lỗi nào. Tool-overlap recall tăng từ 14,8% lên 38%, cho thấy model đã gọi công cụ đúng hơn nhưng vẫn là khoảng cách lớn nhất còn lại so với Claude.

Chất lượng theo hạng mục – lời giải thích cho việc chọn đúng model

Nhìn vào chi tiết từng nhóm, bức tranh trở nên rõ ràng hơn:

Hạng mục	Claude	30B	122B
Calendar	90	30	78
Code	87	25	73
Email	92	15	87
Files	88	15	64
General	85	30	90
Messaging	87	22	74
Notes	97	22	92

Điểm trung bình theo hạng mục giữa Claude và hai model local

Điều thú vị: ở hạng mục General, model local vượt Claude với 90 so với 85 – đây là nhóm tác vụ thiên về suy luận trên ngữ cảnh được cấp sẵn hơn là chuỗi tool call phức tạp. Trong khi đó Files vẫn là điểm yếu nhất (64 điểm), chính xác là hạng mục phụ thuộc nhiều nhất vào việc gọi đúng công cụ theo đúng trình tự.

Chi phí: rẻ hơn 787 lần – nhưng con số không hề "sạch"

Chi phí là một nửa câu chuyện. Với Claude, tác giả dùng số liệu API billing thực tế ghi trong Langfuse. Với model local, năng lượng được đo bằng HomeLab Monitor – một stack mã nguồn mở tự phát triển – ghi nhận mức tiêu thụ GPU theo từng đợt chạy và quy đổi theo giá điện thực tế.

Cả 27 tác vụ vòng 2 tiêu tốn 0,1573 kWh trên cả ba card. Quy ra chi phí mỗi tác vụ:

Model	Chi phí/tác vụ	So với Claude
Claude	$0,763	1×
qwen3-coder:30b	$0,000147	5.159× rẻ hơn
qwen3.5 122B	$0,000969	787× rẻ hơn

Tương quan giữa chi phí và chất lượng cho thấy lợi thế lớn của local model

Tuy nhiên, con số này là chi phí "gộp", bao gồm cả điện năng idle của hệ thống vì đàn GPU được giữ luôn bật để giảm độ trễ. Nếu chỉ chạy model khi cần, chi phí mỗi tác vụ sẽ thấp hơn, nhưng đổi lại độ trễ cao hơn.

Một chi tiết đáng chú ý khác: model 122B đắt gấp 6,6 lần model 30B khi chạy trên phần cứng cục bộ. Từ "không dùng được nhưng gần như miễn phí" lên "dùng được và vẫn gần như miễn phí" thực sự là một cái giá phải trả – nhưng cái giá đó vẫn chỉ là vài phần trăm xu mỗi tác vụ.

Những gì thí nghiệm này không thể kết luận

Tác giả rất cẩn thận khi đưa ra con số, bởi phương pháp luận có hai biến thay đổi đồng thời: model to hơn và context window lớn hơn 16 lần. Không có một control để tách riêng ảnh hưởng của từng yếu tố – chẳng hạn chạy qwen3-coder:30b trên hệ thống 3 GPU với 256K context.

Nhiều khả năng context mới là yếu tố quyết định chứ không phải số tham số. Vòng 1 có những lỗi điển hình như cú pháp tool call bị cắt giữa chừng hay chọn sai công cụ – đúng những gì xảy ra khi tool schema không vừa context. Việc lỗi malformed call giảm về 0 ở vòng 2 củng cố giả thuyết này, nhưng tác giả thừa nhận đó vẫn chỉ là giả thuyết chưa được kiểm chứng.

Ngoài ra, judge vốn là model Claude nên có thể thiên vị cho “người nhà” – một hạn chế đã được nêu rõ, và càng đáng lưu ý khi điểm số hai bên rất sát nhau ở vòng 2.

Vậy, liệu local LLM có thể thay thế Claude?

Câu trả lời thực tế từ thí nghiệm này là: có, trong nhiều trường hợp. Tác giả đã thực sự chuyển Jarvis sang chạy hoàn toàn trên model local, hủy gói Claude Max và chỉ giữ Pro. Nhưng cách diễn đạt khái quát hơn sẽ là: local model đã đủ tốt để khiến khoản chi phí API cao cấp nhất không còn đáng giá.

Claude vẫn là model tốt hơn trên hầu hết tác vụ, đặc biệt là các tác vụ đa bước cần gọi chính xác một chuỗi công cụ. Trong khi đó, model local giành chiến thắng rõ rệt ở nhóm tác vụ suy luận tổng quát, đồng thời mang lại lợi ích về quyền riêng tư khi dữ liệu không bao giờ rời khỏi máy. Với các doanh nghiệp hoặc cá nhân xử lý dữ liệu nhạy cảm ở Việt Nam, đây là một lựa chọn ngày càng đáng cân nhắc dù chi phí phần cứng ban đầu không hề nhỏ.

Bài học quan trọng nhất rút ra sau hai vòng chạy: điều tạo ra khác biệt lớn không phải là chọn model thông minh hơn, mà là cho một model đủ tốt không gian ngữ cảnh để nhìn thấy toàn bộ bề mặt công cụ. Hãy thử tăng context trước khi chi tiền cho tham số.