Model Routing: Cách giảm chi phí LLM mà không đánh đổi chất lượng

Phần lớn team ra mắt tính năng LLM đầu tiên theo cùng một cách: chọn model mạnh nhất có thể, nối dây vào, xong. Cách này nhanh nhất để ship. Vấn đề chỉ lộ ra sau đó, trên hoá đơn - mọi request đều trả giá của model đắt nhất, bất kể request đó có thật sự cần mức năng lực ấy hay không.

Model routing giải quyết việc này bằng cách đặt lại một câu hỏi trước mỗi request: model rẻ nhất nào vẫn xử lý đúng được việc này?

Vì sao dùng LLM không routing lại tốn kém

Nhà cung cấp LLM tính phí theo token, và model càng lớn thì giá mỗi token càng cao vì cần nhiều tham số và nhiều tính toán hơn cho mỗi request. Mức phí cao đó đổi lấy năng lực thật - nhưng chỉ những tác vụ thật sự cần năng lực đó mới đáng trả giá cho nó.

Hình dung một tính năng phân loại phản hồi khách hàng xử lý 500.000 request mỗi tháng. Một phần request chỉ là "ticket này thuộc billing hay shipping" - phân loại đơn giản. Phần khác là "đọc 5 ticket liên quan này và giải thích chúng có cùng mô tả một lỗi hệ thống hay không" - cần suy luận thật sự. Nếu mọi request đều đi qua cùng một model đỉnh, bạn đang trả giá của model suy luận cho công việc phân loại. Đó chính là phần lãng phí mà routing sinh ra để loại bỏ.

Model routing thực chất là gì

Router đứng giữa ứng dụng của bạn và cả dàn model. Thay vì code gọi thẳng một model, request được đưa cho router, router đánh giá request cần gì rồi chuyển tới model rẻ nhất có thể xử lý được - kèm đường escalate lên model mạnh hơn nếu đoán sai.

Router đứng giữa request và các model

Router chọn tier rẻ nhất vẫn trả lời đúng, sau đó validate trước khi trả kết quả.

Request đến

"Phân loại ticket hỗ trợ này là billing, technical hay account-related."

Router

Model nhỏViệc thường quy, dễ đoánModel trung bìnhPhân tích tổng quátModel mạnhViệc phức tạp hoặc rủi ro cao

Phân loại, trích xuất, format lại, viết lại trực tiếp.

Validate

Câu trả lời cuối

Đây không phải là mixture-of-experts (MoE). Routing trong MoE xảy ra bên trong một model, giữa các nhóm tham số nội bộ, người gọi không thấy được. Model routing ở tầng ứng dụng xảy ra bên ngoài mọi model, quyết định request đi tới model nào ngay từ đầu.

Con số đứng sau khoản tiết kiệm

Giả sử model mạnh nhất tốn $0,03 mỗi request trung bình, model tầm trung tốn bằng 1/5 số đó, model nhỏ tốn bằng 1/20 số đó. Giờ giả sử bạn khảo sát traffic thật và thấy 80% request đủ đơn giản cho model nhỏ, 15% cần model tầm trung, chỉ 5% thật sự cần model đỉnh.

Chi phí trung bình mỗi request trở thành:

(0,80 × 0,0015) + (0,15 × 0,006) + (0,05 × 0,03) = 0,0033

Con số này chỉ bằng khoảng 11% so với việc gửi mọi request tới model đỉnh - giảm gần 9 lần, mà không đụng tới 5% request thật sự cần đầy đủ năng lực. Mức tiết kiệm phụ thuộc vào độ lệch của traffic thật: workload càng nghiêng về tác vụ đơn giản, máy móc, phần tiết kiệm càng lớn.

Router đánh giá độ khó trước khi trả lời như thế nào

Phần khó không nằm ở phép tính - mà ở việc ước lượng độ khó của request trước khi đã trả lời xong. Độ dài request là chỉ báo tệ: "Hợp đồng này có hiệu lực pháp lý không?" chỉ vài từ nhưng cần suy luận nghiêm túc; một tài liệu 2.000 từ kèm yêu cầu "liệt kê mọi địa chỉ email trong văn bản này" thì dài nhưng lại đơn giản về mặt xử lý.

Một router đáng tin cậy cân nhắc nhiều tín hiệu cùng lúc, thay vì tin vào một tín hiệu duy nhất.

Không tín hiệu nào một mình cho biết request khó tới đâu

Request ngắn vẫn có thể cần model mạnh - router tốt cân nhắc nhiều tín hiệu cùng lúc.

Loại tác vụRủi roKích thước contextRàng buộc outputNăng lực cần có

Trích xuất, phân loại, viết lại thường cần ít suy luận hơn lập kế hoạch hay debug.

Cân nhắc cùng lúc

Loại tác vụ, kích thước context, ràng buộc output, năng lực cần có - gộp lại chỉ ra tier rẻ nhất thoả hết.

Hard override: rủi ro

Y tế, pháp lý, tài chính, bảo mật - bỏ qua bước cân nhắc, escalate thẳng lên tier mạnh hơn.

Quyết định routing

Chọn tier rẻ nhất thoả mọi tín hiệu trên, hoặc escalate khi có hard override.

Hai tín hiệu đáng chú ý riêng. Rủi ro không bao giờ nên bị ghi đè bởi phán đoán riêng của router - request chạm tới y tế, pháp lý, tài chính, hay bảo mật nên được route lên model mạnh hơn dù mọi tín hiệu khác đều nói nó đơn giản, vì cái giá của một câu trả lời sai ở đó là bất đối xứng. Và năng lực cần có - vision, dùng tool, context window dài - có thể loại bỏ ngay tier rẻ nhất, bất kể phần suy luận "khó" tới đâu.

Ba cách xây router

Dùng model nhỏ làm bộ phân loại. Cách linh hoạt nhất: một model rẻ, nhanh đọc request rồi trả về một phán quyết có cấu trúc - tier độ khó, cờ rủi ro, và một dòng lý do - trước khi request thật đi đâu cả. Cách này thường đi kèm luật ghi đè cứng cho mọi thứ nhạy cảm về rủi ro, vì bộ phân loại có thể đoán sai, và bản thân model ngôn ngữ có thể bị dẫn dắt bởi câu chữ mang tính thao túng trong chính request.

Cascading. Thay vì đoán độ khó trước, cứ thử model rẻ trước rồi kiểm tra kết quả. Nếu output qua được một kiểm tra tự động - JSON hợp lệ, đủ field bắt buộc, code sinh ra pass test - bạn giữ kết quả đó. Nếu không qua, escalate lên model mạnh hơn. Cách này hiệu quả khi "đủ tốt" có thể kiểm tra được bằng máy móc; kém hiệu quả khi chất lượng mang tính chủ quan, vì lúc đó việc kiểm tra chất lượng lại cần một lệnh gọi model riêng, ăn vào phần tiết kiệm.

Semantic routing. Chuyển request thành embedding rồi so sánh với các nhóm đã biết theo ý nghĩa thay vì từ khoá, để "sao tôi bị tính tiền hai lần" và "thẻ tôi có một giao dịch trùng" cùng rơi vào route billing dù không chung một từ nào. Cách này mạnh ở việc nhận diện loại request, nhưng yếu ở việc ước lượng độ khó - một request billing vẫn có thể là tra cứu một dòng hoặc một tranh chấp nhiều tài liệu - nên các team thường kết hợp semantic routing với một tín hiệu độ khó riêng.

Một số team sau này huấn luyện hẳn một router riêng dựa trên dữ liệu thực tế đã ghi log - tier nào thật sự thành công với request nào trong quá khứ - khi đã có đủ traffic production để dữ liệu đó đáng tin. Đây là bước tiếp theo tự nhiên sau ba cách trên, không phải thứ thay thế việc hiểu ba cách đó trước.

Routing sai ở đâu

Under-routing đẩy một request thật sự khó tới model không đủ sức xử lý, tạo ra một câu trả lời sai nhưng đầy tự tin thay vì câu trả lời đúng. Over-routing thì ngược lại - đẩy việc dễ tới model đắt "cho chắc" - và âm thầm xoá sạch phần tiết kiệm mà cả hệ thống routing được dựng lên để đạt được.

Router cũng là một bề mặt tấn công: nếu logic routing đọc chỉ dẫn được nhúng ngay trong tin nhắn của người dùng, một request có thể "nói khéo" để lọt vào route rẻ hơn, ít bị soi hơn. Quyết định routing nên dựa vào context ứng dụng đáng tin và metadata đã được xác thực, không bao giờ dựa vào chính đoạn văn bản mà router đang cố phân loại.

Cuối cùng, logic routing sẽ cũ đi theo thời gian. Giá model thay đổi, chất lượng model tăng hoặc giảm, traffic dịch chuyển - một chính sách routing được tinh chỉnh theo model và traffic của quý trước có thể âm thầm trở nên sai. Nên xem đây là thứ cần rà soát lại định kỳ, không phải thứ chỉnh một lần rồi để yên.

Hình dạng của một router hoạt động tốt

Bỏ qua từng kỹ thuật cụ thể, một model router chỉ có đúng ba việc: ước lượng request cần gì, chọn model rẻ nhất nhiều khả năng đáp ứng được nhu cầu đó, và kiểm tra kết quả đủ kỹ để bắt được - và escalate - những trường hợp đoán rẻ bị sai. Làm đúng ba việc này, routing trở thành một trong những đòn bẩy chi phí hiệu quả nhất cho một sản phẩm dựa trên LLM, mà không bắt người dùng chấp nhận câu trả lời tệ hơn.