Đừng chọn model cho Hermes chỉ bằng giá token

Một bài chia sẻ mới trong cộng đồng Hermes đang gây chú ý vì tác giả nói đã thử nhiều model qua khoảng 6 tỷ token, với tiêu chí chính là hiệu quả chi phí. Con số đó nghe rất lớn, nhưng phần đáng bàn hơn không phải bảng xếp hạng tuyệt đối. Điểm đáng lấy về là cách anh em nên đánh giá model cho agent workflow: không chỉ nhìn giá mỗi token, mà phải nhìn tổng chi phí để hoàn thành một việc thật.

Bảng xếp hạng trong bài nói gì

Tác giả thử nhiều nhóm việc như web scraping, research analytics, software development, tăng cường inference và các cron job nhiều bước. Theo trải nghiệm của họ, thứ tự model đáng dùng cho Hermes là:

1. GPT 5.5
2. Kimi K2.6
3. GLM 5.1
4. Minimax M2.7
5. Qwen 3.6 Max
6. Các model Gemini

Với local model, họ đánh giá Qwen 3.6 35B A3B là lựa chọn tốt nhất. Qwen 3.6 27B dense cũng ổn, nhưng quá chậm cho workflow của họ.

Về subscription, tác giả ưu tiên:

• OpenAI 20 USD
• Opencode Go 10 USD
• Minimax 10 USD
• Kimi 20 USD
• GLM 18 USD, hoặc rất tốt nếu còn gói cũ rẻ hơn

Đây là một góc nhìn cá nhân, không phải benchmark chuẩn hóa. Nhưng nó phản ánh một vấn đề rất thật: trong agent workflow, model rẻ chưa chắc là model tiết kiệm.

Vì sao giá mỗi token dễ đánh lừa anh em

Khi dùng AI theo kiểu hỏi đáp đơn giản, giá mỗi triệu token là chỉ số khá dễ hiểu. Nhưng với Hermes hoặc các agent workflow nhiều bước, chi phí thật thường nằm ở mấy thứ khác:

• số vòng retry
• thời gian chờ
• khả năng giữ đúng kế hoạch qua nhiều tool call
• chất lượng output đủ dùng ngay hay phải sửa nhiều
• mức độ kẹt vòng lặp
• khả năng tự phục hồi khi context xấu

Một model rẻ hơn 5 lần nhưng làm task lâu hơn 10 lần, hoặc phải chạy lại nhiều lần, có thể đắt hơn trong thực tế. Đặc biệt với các job scraping, phân tích dữ liệu, coding và cron automation, thời gian hoàn tất cũng là chi phí.

Điểm mình thấy đáng chú ý trong bài là ví dụ GLM 5.1 mất rất lâu cho một bài phân tích thống kê, trong khi GPT 5.5 hoàn thành dưới một giờ. Nếu anh em chỉ tính tiền token thì sẽ bỏ qua phần chi phí cơ hội: 18 tiếng chờ, rủi ro job treo, và công giám sát.

Cách đọc bảng xếp hạng này cho đúng

Mình sẽ không đọc nó như câu trả lời “model nào tốt nhất cho tất cả mọi người”. Nên đọc theo 3 lớp.

1. Model mạnh nhất chưa chắc tối ưu nhất

GPT 5.5 được tác giả khen rất mạnh ở software development, scraping, analysis và multi-step cron job. Nhưng nếu workload của anh em là tác vụ nhẹ, ít tool, ít rủi ro, dùng model mạnh nhất cho mọi thứ có thể là lãng phí.

Một chiến lược hợp lý hơn là chia tầng:

• model mạnh cho planning, code, phân tích khó, job nhiều bước
• model rẻ hơn cho tóm tắt, phân loại, viết nháp, kiểm tra đơn giản
• local model cho tác vụ lặp lại, ít rủi ro, cần riêng tư hoặc chạy nhiều

2. Quota và latency quan trọng không kém chất lượng

Kimi được xếp cao, nhưng tác giả nhắc đến giới hạn quota theo khung giờ. GLM có vẻ mạnh nhưng bị phàn nàn về loop. Minimax thì rẻ và ổn, nhưng cần prompt tốt hơn.

Đây là những điểm rất vận hành. Một model có chất lượng tốt nhưng quota bó quá chặt sẽ khó làm backbone cho job tự động. Một model rẻ nhưng hay loop sẽ khiến hệ thống phải có guardrail tốt hơn.

3. Local model nên được dùng đúng vai

Qwen 3.6 35B A3B được nhắc là local option tốt. Nhưng local không tự động thắng cloud. Anh em phải tính thêm:

• phần cứng đang có
• tốc độ sinh token
• độ ổn định khi chạy lâu
• context window thực tế
• khả năng tool use
• công vận hành môi trường local

Local rất đáng theo dõi, nhất là cho workflow cần kiểm soát dữ liệu hoặc chạy nhiều. Nhưng nếu một job quan trọng cần xong nhanh và ít lỗi, cloud model mạnh vẫn có chỗ đứng rõ ràng.

Một framework nhỏ để chọn model cho Hermes

Thay vì hỏi “model nào ngon nhất”, anh em có thể chấm từng model theo 6 tiêu chí:

Nếu chấm theo bảng này, anh em sẽ dễ ra quyết định hơn nhiều so với nhìn một bảng giá API.

Gợi ý routing thực dụng

Với các workflow kiểu Hermes, mình sẽ bắt đầu bằng một routing khá đơn giản:

• Dùng model mạnh nhất cho job có rủi ro cao: coding, research sâu, scraping phức tạp, tác vụ nhiều bước.
• Dùng model tầm trung cho việc viết lại, phân loại, trích xuất, tóm tắt log.
• Dùng model rẻ hoặc local cho batch job dễ kiểm tra, có thể retry an toàn.
• Ghi log theo từng task: model, số token, thời gian, số lần retry, kết quả đạt hay không.
• Sau 1-2 tuần, tối ưu bằng dữ liệu thật của mình thay vì nghe bảng xếp hạng chung.

Điểm cuối là quan trọng nhất. Mỗi người có workload khác nhau. Một model rất tốt cho coding chưa chắc tốt cho email outbound. Một model ổn cho tóm tắt chưa chắc đủ tốt cho browser automation.

Checklist nhanh trước khi đổi model chính

Trước khi chuyển toàn bộ Hermes workflow sang một model mới, anh em nên test tối thiểu:

• 5 job coding hoặc sửa file có kiểm thử rõ
• 5 job research có nhiều nguồn và yêu cầu trích dẫn
• 5 job tool-use nhiều bước, có khả năng lỗi giữa chừng
• 5 job dài context để xem model có giữ mục tiêu không
• 1 job chạy định kỳ như cron để đo độ ổn định qua thời gian

Mỗi job nên ghi lại thời gian, token, số lần can thiệp tay và chất lượng output. Sau đó mới quyết định model nào làm chính, model nào làm phụ.

Kết luận

Bài thảo luận này đáng đọc vì nó kéo cuộc nói chuyện về đúng chỗ: hiệu quả chi phí trong agent workflow không phải là giá token thấp nhất, mà là chi phí thấp nhất để hoàn thành một kết quả đáng tin.

Nếu anh em đang chạy Hermes nghiêm túc, mình nghĩ hướng đi tốt là không thần tượng một model duy nhất. Hãy xây routing, logging và benchmark nhỏ cho workload của mình. Model mạnh dùng đúng chỗ sẽ tiết kiệm hơn model rẻ dùng sai chỗ. Còn khi thị trường đổi giá, đổi quota hoặc đổi policy, hệ thống có routing tốt sẽ xoay sở nhẹ hơn nhiều.