- Echo kết hợp nhiều mô hình open-weight như GLM-5.2, Kimi K2.7 theo từng yêu cầu để khắc phục giới hạn của cách giao mọi tác vụ cho một mô hình duy nhất
- Với mỗi yêu cầu, hệ thống quyết định lượng tính toán và các mô hình tham gia, đồng thời điều chỉnh cả cách hợp nhất kết quả, nên với prompt đơn giản sẽ dùng ít tài nguyên suy luận hơn
- Trong cấu hình đánh giá đầu tiên, hệ thống luôn vượt mô hình đơn lẻ tốt nhất trong nhóm và đạt kết quả tổng thể tương đương Fable với chi phí suy luận chỉ khoảng một phần ba
- Ngay cả các mô hình nhìn chung yếu hơn cũng có năng lực bổ sung đủ hữu ích trong một số bài toán hoặc tổ hợp nhất định, nhưng vẫn còn những trường hợp phân bổ và hợp nhất sai
- Nhóm đã công bố giao diện chat và API tương thích OpenAI, đồng thời đang thử nghiệm xem cách tiếp cận này có còn hiệu quả với các tác vụ coding và agent, nơi việc đo chất lượng khó hơn nhiều hay không
Chọn mô hình và hợp nhất kết quả
- Trong các thử nghiệm ban đầu, nhóm đưa GLM-5.2, Kimi K2.7 và các mô hình khác vào cùng một bộ đánh giá, rồi đo kết quả với giả định rằng họ biết trước mô hình nào hữu ích cho từng bài toán và cách kết hợp đầu ra nào là phù hợp
- Hệ thống giả định này cho hiệu năng cao hơn rất nhiều so với bất kỳ mô hình đơn lẻ nào trong nhóm
- Vì chỉ có thể xác định các quyết định tốt sau khi đã xem kết quả nên không thể dùng trực tiếp khi triển khai thực tế, và Echo là nỗ lực nhằm khôi phục một phần lợi thế đó mà không cần thông tin trước
- Tùy theo đặc tính của yêu cầu, hệ thống chọn lượng tính toán cần thiết, các mô hình tham gia và cách hợp nhất kết quả
- Với prompt đơn giản, hệ thống phân bổ lượng suy luận tương đối ít
- Với các bài toán khác, hệ thống cấu hình để nhiều mô hình xử lý các phần khác nhau
- Năng lực của các mô hình mang tính bổ sung lẫn nhau, nên ngay cả mô hình có hiệu năng tổng thể thấp hơn rõ rệt vẫn có thể rất hữu ích trong một số bài toán hoặc tổ hợp nhất định
Kết quả đánh giá và thử nghiệm công khai
- Trong cấu hình đánh giá đầu tiên, hệ thống ghi nhận hiệu năng luôn cao hơn mô hình đơn lẻ tốt nhất, đồng thời đạt kết quả tổng thể gần tương đương Fable với chi phí chỉ khoảng một phần ba
- Với một số yêu cầu, hệ thống vẫn đưa ra quyết định sai về phân bổ tính toán hoặc kết hợp mô hình, và hiện nhóm đang phân tích các trường hợp thất bại này
- Với các tác vụ coding và agent, việc đo chất lượng của từng quyết định khó hơn nhiều, nên nhóm đang thử nghiệm riêng xem cách tiếp cận tương tự có còn duy trì hiệu quả hay không
- Để thử nghiệm bên ngoài, nhóm cung cấp giao diện chat Echo và API tương thích OpenAI
- Nhóm cũng công bố video giới thiệu cách hoạt động và phương pháp đánh giá, kết quả của từng mô hình, chi phí và các giới hạn hiện tại, đồng thời kêu gọi phản hồi về các trường hợp thất bại bất thường hoặc các ví dụ phân bổ tài nguyên trái với trực giác
1 bình luận
Ý kiến trên Hacker News
Đây là một dark pattern điển hình: hiển thị ô nhập Message Echo trông như có thể nhận phản hồi, rồi chuyển người dùng sang trang đăng ký
Ngay từ hành động đầu tiên mà trang web dẫn dắt đã bị chặn lại, nên tôi rời đi ngay và sẽ không quay lại
Với tư cách người làm sản phẩm AI, đây cũng là một lựa chọn có thể hiểu được
Cảm ơn tất cả những ai đã dùng Echo và gửi phản hồi; chính vì những lý do như thế này mà chúng tôi ra mắt sớm
Chúng tôi sẽ tiếp tục công bố các đánh giá thể hiện chính xác hơn khoảng cách với mức tốt nhất hiện nay, bao gồm cả các benchmark coding và agent khó hơn, đồng thời sẽ mở rộng dashboard đánh giá công khai. Các vấn đề được phát hiện trong UI dashboard đánh giá và quy trình đăng ký đã được sửa trên môi trường production
Dùng thử Echo không cần thẻ tín dụng, và mỗi tài khoản được cung cấp 10 USD credit miễn phí để dùng cho API và chat
Rộng hơn việc định tuyến mô hình đơn thuần, chúng tôi đang khám phá cách phân bổ hiệu quả tài nguyên suy luận giữa các mô hình open-weight. Không chỉ quyết định dùng mô hình nào, mà còn quyết định đưa bao nhiêu tính toán vào mỗi yêu cầu và kết hợp các kết quả trung gian ra sao
Bản thân ensemble đã được biết đến từ trước cả random forest, nhưng điểm cốt lõi của Echo là mô hình hóa và tận dụng nó mà không phải trả chi phí cho toàn bộ ensemble ở mỗi yêu cầu. Dù có những điểm tương tự về mặt khái niệm với Fusion hay Fugu, cấu trúc và mục tiêu tối ưu hóa là khác nhau
create passwordyêu cầu ký tự đặc biệt, nhưng mật khẩu được tạo mặc định của Google Password Manager không có ký tự đặc biệtTổ hợp chữ và số dài hai chữ số có vẻ đã đủ, nhưng bản thân ý tưởng thì rất hay
too many authentication attemptsNếu không có tính minh bạch, tôi không biết việc dùng mô hình open-weight đem lại lợi ích gì cho người dùng cuối
Mô tả
kết quả ngang Fable với chi phí bằng một phần bacó vẻ không hấp dẫn lắm với người dùng gói 200 USD/tháng được trợ giá mạnhKhông biết gói này sẽ được duy trì đến bao giờ, nhưng trong thời gian đó thì mức giá bằng một phần ba API công khai cũng không hấp dẫn lắm
Một phần là vì nhiều sub-agent chạy đồng thời và Claude quên chỉ thị dùng mô hình rẻ hơn nên có nhiều instance Fable chạy, nhưng tính phí theo token thì rất khó chịu nổi. 200 USD/tháng đã đắt, nhưng 200 USD chỉ qua một đêm thì thật vô lý
Nếu một người dùng trả 200 USD/tháng dùng lượng API credit trị giá 10.000 USD, biên lợi nhuận trên mỗi người dùng là -98%, không giúp gì cho lợi nhuận
Vẫn có thể tiếp tục sử dụng, nhưng sẽ cần credit trả theo mức dùng và không được tính vào giới hạn sử dụng của gói đăng ký
Tôi sẽ không ngạc nhiên nếu trong vài năm tới, khái niệm mô hình tốt nhất bị đẩy thành một ngách
Trong hầu hết hệ thống vận hành, người chiến thắng có thể là orchestrator biết khi nào dùng mô hình rẻ, khi nào chuyển sang mô hình mạnh và khi nào kết hợp nhiều đầu ra
Xu hướng lớn là mô hình tích hợp trên thiết bị, thậm chí có thể là mô hình nằm trong die của chip và người dùng thay chipset vài năm một lần. Trong môi trường như vậy, các nhà cung cấp cloud lớn sẽ bị thiệt
Một trong những kết luận thú vị nhất là việc chọn mô hình có thể quan trọng hơn kích thước mô hình
Ngành này lâu nay tập trung vào các mô hình lớn hơn, nhưng nếu định tuyến yêu cầu một cách thông minh tới tổ hợp các mô hình chuyên biệt phù hợp, có vẻ có thể đạt cải thiện lớn hơn nhiều với chi phí thấp hơn nhiều
Các mô hình yếu hơn không phải đã trở nên vô dụng; chúng xuất sắc ở những miền khác nhau, và khi kết hợp với mô hình khác thì giá trị có thể tăng mạnh. Tuy nhiên, tôi tò mò liệu điều này có còn đúng với tác vụ coding và agent, nơi việc chọn mô hình phù hợp khó hơn nhiều hay không
Tác vụ agent và coding phức tạp hơn do tính phân đoạn. Cần quyết định khi nào, như thế nào, và ở tầng trừu tượng nào — phiên, mục tiêu, tác vụ, lượt hội thoại hay lời gọi công cụ — sẽ dùng từng mô hình; hiện chúng tôi đang tích cực nghiên cứu việc này
Thực tế tôi đã phát hiện vài lỗi về trải nghiệm người dùng
Thinkingcứ hiển thị mãi khiến trông như bị treo hoặc gặp vấn đề mạng, và panel bên trái để nhập prompt không thể mở rộng hay chỉnh kích thước. Khi yêu cầu tạo code, đầu ra liên tục bị cắt rồi bắt đầu lại từ đầu, không thể tiếp nối cuộc hội thoại trước đóNếu không thể biết trước độ phức tạp của vấn đề và không có đảm bảo rằng các lượt hội thoại sau sẽ được gửi tới cùng một mô hình, cách này sẽ không hoạt động tốt
Nếu gửi cùng một cuộc hội thoại tới nhiều mô hình theo kiểu round robin, cache sẽ bị phá vỡ, và có khả năng còn tốn kém hơn một hệ thống có tính đến cache
Tôi đã dùng Anthropic Opus 4.8 và Fable 5 một thời gian, cũng thử các model OpenAI mới nhất, nhưng tất cả đều tạo ra quá nhiều đầu ra không cần thiết.
Tôi bắt đầu thử các model khác không phải vì giá mà vì chất lượng, và trong lĩnh vực công việc của tôi, GLM 5.2 vượt trội Fable 5 về mọi mặt. Những trường hợp nó không hoàn thành được tác vụ mới là điều đáng ngạc nhiên.
Kimi K2.7 cần chỉ dẫn nhiều hơn một chút nhưng cho cảm giác dùng tốt hơn Opus 4.8, còn K3 thì tôi chưa thử. Các model OpenAI mới nhất có năng lực thiết kế và triển khai phần mềm tệ đến mức phi lý.
Đây là đánh giá chỉ giới hạn trong lĩnh vực công việc của tôi, vốn có nhiều phân tích dữ liệu, học máy và kỹ thuật phần mềm.
Không có benchmark, cũng không có thông tin về model được dùng, chỉ có video do AI tạo và trang đăng ký.
Nó làm tôi nhớ đến câu đùa kiến trúc: “biến monolith thành microservice để mọi sự cố đều giống như một vụ án mạng bí ẩn”.
Hiện công khai 907 hàng đã lưu thuộc 7 nhóm benchmark, có thể xem prompt, output, đánh giá và bản ghi chi phí; sẽ bổ sung thêm.
Bản thân chính sách định tuyến theo từng request là sản phẩm nên chúng tôi không công khai, nhưng có thể công bố một phần danh sách các model open-weight có thể dùng, ngày phiên bản, tỷ lệ phân bổ tổng thể và thiết lập đánh giá, trong phạm vi không tiết lộ bí quyết cho từng request. Video mới cũng đang được làm.
Không phải benchmark tốt, nhưng ít nhất là có tồn tại.
Tiếc là trông giống một nỗ lực để nói với nhà đầu tư rằng “OpenRouter đã thành unicorn nên tôi cũng có thể vibe-code thứ tương tự”, hơn là giải quyết một vấn đề thực sự.
Việc gọi là
ngang Fablecũng tạo cảm giác lười biếng về mặt trí tuệ hoặc thiếu trung thực.Tôi tự hỏi có phải đây là tái tạo Dogpile.com, thứ từng tổng hợp kết quả từ Ask Jeeves, AltaVista và Lycos hay không. Thời gian có vẻ như đang quay vòng.
Chúng tôi cũng đã triển khai cách tương tự: https://trustedrouter.com/blog/prometheus-2-new-draco-state-...
Các sản phẩm AI gateway khác như OpenRouter, JusCode, Fireworks gần đây cũng khuyến nghị cấu hình tương tự, nên rất có khả năng nó có phần hữu ích.