Định tuyến LLM là gì? Giải thích về quy tắc, trọng số và chính sách tối ưu chi phí
Định tuyến LLM là quá trình chọn mô hình, đường dẫn nhà cung cấp hoặc đường dẫn dự phòng để xử lý một yêu cầu AI cụ thể. Quyết định có thể được cố định trong mã ứng dụng, đưa ra bằng các quy tắc rõ ràng, tính toán từ các tiêu chí có trọng số hoặc ủy quyền cho một bộ phân loại đã học. Mục tiêu không phải là để mọi yêu cầu đi theo một đường dẫn khác nhau. Mục tiêu là khiến mỗi đường dẫn đều có chủ đích, có thể kiểm thử và an toàn.
Nếu bạn đang hỏi định tuyến LLM là gì, câu trả lời thực tế là: đó là lớp chính sách nằm giữa một yêu cầu ứng dụng và một lệnh gọi mô hình. Trước tiên, bộ định tuyến loại bỏ các lựa chọn không thể đáp ứng yêu cầu, sau đó chọn một tuyến đủ điều kiện theo các ưu tiên mà nhóm của bạn đặt ra—chẳng hạn như năng lực, chất lượng, độ trễ, chi phí, tính sẵn sàng và chính sách dữ liệu.
Sự phân biệt này rất quan trọng. Một mô hình giá rẻ không mặc nhiên là lựa chọn mặc định an toàn cho quy trình làm việc hướng đến khách hàng. Một mô hình có năng lực cao không mặc nhiên là lựa chọn phù hợp cho một tác vụ phân loại đơn giản. Và một phương án dự phòng chỉ hữu ích khi nó duy trì các hợp đồng về đầu ra, công cụ và dữ liệu mà ứng dụng của bạn mong đợi.
Tóm tắt: định tuyến LLM tốt bắt đầu bằng các ràng buộc cứng, chỉ xếp hạng các ứng viên tương thích, ghi lại lý do lựa chọn và chỉ chuyển sang dự phòng khi phương án dự phòng an toàn về mặt hợp đồng.
Đó là tiêu chuẩn mà một câu trả lời sẵn sàng cho môi trường sản xuất về định tuyến LLM là gì cần đáp ứng: một quyết định mà kỹ sư có thể kiểm tra, thử nghiệm và thay đổi mà không phải đoán quy tắc ẩn nào đã điều chuyển lưu lượng.
Chính xác thì định tuyến LLM là gì?
Định tuyến LLM là gì? Đó là một quy trình ra quyết định ánh xạ yêu cầu đến vào đường dẫn thực thi đã được phê duyệt tốt nhất cho yêu cầu đó. Đường dẫn có thể xác định một mô hình cụ thể, một nhà cung cấp, một khu vực, một nhóm mô hình hoặc một phương án dự phòng đã được kiểm thử.
Bộ định tuyến có thể nằm trong ứng dụng của bạn, một cổng API hoặc một dịch vụ định tuyến mô hình được quản lý. Ví dụ: Amazon Bedrock intelligent prompt routing chọn giữa các mô hình đủ điều kiện trong một họ mô hình dựa trên chất lượng phản hồi dự đoán và chi phí. Microsoft Foundry’s model router cung cấp các chế độ định tuyến cân bằng, ưu tiên chất lượng và ưu tiên chi phí. Đây là các cách triển khai của cùng một ý tưởng cốt lõi: lựa chọn có chủ đích thay vì coi mọi prompt là giống hệt nhau.
Định tuyến LLM không giống với:
- Bộ cân bằng tải. Bộ cân bằng tải phân phối yêu cầu giữa các máy chủ tương tự nhau. Bộ định tuyến LLM cũng xem xét năng lực của mô hình và kết quả tác vụ.
- Vòng lặp thử lại. Thử lại cùng một tuyến có thể giải quyết lỗi tạm thời; điều đó không quyết định liệu một mô hình khác có hợp lệ cho tác vụ hay không.
- Việc thay thế mô hình chưa được rà soát. Chuyển một yêu cầu sang phương án dự phòng làm thay đổi cấu trúc JSON, hành vi công cụ, ranh giới quyền riêng tư hoặc chất lượng câu trả lời có thể gây ra lỗi nghiêm trọng hơn cả lỗi được báo rõ ràng.
- Huấn luyện mô hình. Định tuyến chọn một đường dẫn phục vụ tại thời điểm yêu cầu. Nó không thay đổi trọng số mô hình.
Để xem xét rộng hơn về ranh giới lưu trữ các quyết định này, hãy xem hướng dẫn của chúng tôi về LLM gateway là gì và khi nào nó trở nên hữu ích.
Cách bộ định tuyến LLM đưa ra quyết định
Thiết kế đáng tin cậy nhất tách tính đủ điều kiện khỏi mức độ ưu tiên. Trước tiên, loại trừ các lựa chọn không thể đáp ứng yêu cầu. Sau đó, chấm điểm các tuyến còn lại theo nhóm lưu lượng hiện tại.
1. Áp dụng các ràng buộc cứng trước khi chấm điểm
Ràng buộc cứng là không thể thương lượng. Mô hình không đáp ứng một ràng buộc không nên vẫn nằm trong tập ứng viên chỉ vì nó rẻ hoặc nhanh.
Các bộ lọc điển hình bao gồm:
| Ràng buộc | Câu hỏi ví dụ | Lý do được xét trước |
|---|---|---|
| Phương thức | Tuyến có chấp nhận đầu vào văn bản, hình ảnh, âm thanh hoặc video không? | Một endpoint chỉ hỗ trợ văn bản không thể xử lý lại một yêu cầu đa phương thức. |
| Hợp đồng | Nó có hỗ trợ các lệnh gọi công cụ, định dạng truyền luồng hoặc đầu ra có cấu trúc cần thiết không? | Một phản hồi hợp lệ về cú pháp vẫn có thể làm hỏng ứng dụng. |
| Chính sách dữ liệu | Nhà cung cấp, khu vực hoặc thiết lập lưu giữ có được phê duyệt cho yêu cầu này không? | Không thể đánh đổi chính sách để lấy giá token thấp hơn. |
| Dung lượng | Tuyến có đủ ngữ cảnh, hạn ngạch hoặc dung lượng hoạt động tốt không? | Một ứng viên sẽ lập tức từ chối yêu cầu thì không đủ điều kiện. |
| Chính sách sản phẩm | Mô hình này có được phép dùng cho tenant, môi trường hoặc thử nghiệm này không? | Giúp việc quản trị có thể kiểm toán thay vì ngầm định. |
Thứ tự này ngăn chặn một lỗi định tuyến phổ biến: coi mọi mô hình là có thể thay thế lẫn nhau. Chúng không phải vậy. Cần chứng minh tính tương thích cho endpoint và nhóm lưu lượng chính xác mà bạn dự định định tuyến.
2. Chấm điểm các ứng viên đủ điều kiện
Sau khi lọc, một tuyến có thể sử dụng điểm có trọng số minh bạch. Một mẫu đơn giản là:
route score =
quality_weight × expected_quality
+ latency_weight × (1 - normalized_latency)
+ cost_weight × (1 - normalized_cost)
+ reliability_weight × recent_route_health
Công thức này là một khung ra quyết định, không phải là tiêu chuẩn so sánh phổ quát. Điều quan trọng là các thành phần được chuẩn hóa nhất quán, trọng số thuộc về một nhóm lưu lượng và chính sách có thể được giải thích sau một sự cố.
Ví dụ: một tác vụ gắn thẻ chạy nền có thể đặt trọng số cao hơn cho chi phí và thông lượng. Một tác nhân hỗ trợ khách hàng có thể đặt trọng số cao hơn cho chất lượng, khả năng tương thích với công cụ và độ trễ đuôi. Một quy trình chịu sự quản lý có thể coi yêu cầu về lưu trú dữ liệu là bộ lọc tuyệt đối thay vì một điểm số.
3. Thực thi, quan sát và sử dụng phương án dự phòng có giới hạn
Bộ định tuyến nên ghi nhật ký tuyến đã chọn, dữ liệu đầu vào của điểm số, phiên bản chính sách, ID yêu cầu, độ trễ, ước tính chi phí hoặc bản ghi sử dụng, và trạng thái kết quả. Nếu tuyến chính thất bại, quyết định dự phòng cần có các quy tắc riêng:
- Lỗi có đủ tính tạm thời để thử lại trên cùng tuyến không?
- Yêu cầu có tính lũy đẳng không, hay việc thử lại có thể lặp lại một hành động bên ngoài?
- Phương án dự phòng có duy trì hợp đồng đầu ra và công cụ không?
- Phương án dự phòng có được phép vượt quá ngân sách hoặc ranh giới dữ liệu của yêu cầu không?
- Nếu không, hệ thống nên xếp hàng, suy giảm chức năng một cách linh hoạt hay trả về lỗi được kiểm soát?
Đó là lý do phương án dự phòng là một kỹ thuật định tuyến, chứ không phải từ đồng nghĩa với định tuyến. cẩm nang chiến lược dự phòng mô hình của chúng tôi trình bày chi tiết hơn về các quyết định khôi phục.
Sáu kỹ thuật định tuyến LLM nên sử dụng có chủ đích
Không có một bộ định tuyến tốt nhất duy nhất. Hãy bắt đầu với kỹ thuật đơn giản nhất có thể đáp ứng khối lượng công việc, rồi thêm độ phức tạp khi các số đo của bạn chứng minh điều đó là hợp lý.
1. Định tuyến tĩnh
Mọi yêu cầu trong một khối lượng công việc đều đi đến một mô hình hoặc điểm cuối được chỉ định.
Sử dụng khi: bạn đang thiết lập đường cơ sở, cần một mục tiêu đánh giá ổn định, hoặc có khối lượng công việc hẹp với một mô hình đã được phê duyệt.
Cần lưu ý: một tuyến tĩnh có thể che giấu chi phí sử dụng mô hình có năng lực cao cho các tác vụ tầm thường, hoặc rủi ro về độ tin cậy khi phụ thuộc vào một đường dẫn thượng nguồn.
2. Định tuyến dựa trên quy tắc
Các điều kiện tường minh chọn một tuyến: gửi yêu cầu có hình ảnh đến đường dẫn hỗ trợ thị giác; chỉ gửi yêu cầu có lệnh gọi công cụ đến các mô hình hỗ trợ hợp đồng công cụ đã được phê duyệt; gửi các bản tóm tắt theo lô nội bộ đến một tuyến tiết kiệm.
Sử dụng khi: quyết định có thể được giải thích từ siêu dữ liệu yêu cầu và số lượng quy tắc đủ ít để có thể rà soát.
Cần lưu ý: sự lan tràn của quy tắc. Hãy đặt các quy tắc trong tệp hoặc dịch vụ chính sách được quản lý phiên bản thay vì rải rác các kiểm tra nhà cung cấp trong mã ứng dụng.
3. Định tuyến dựa trên năng lực
Bộ định tuyến bắt đầu từ sổ đăng ký năng lực của mô hình thay vì chỉ dựa vào văn bản prompt. Nó lọc theo họ điểm cuối, ngữ cảnh, các phương thức được hỗ trợ, hành vi công cụ, hỗ trợ đầu ra có cấu trúc, khu vực và hạn mức tài khoản.
Sử dụng khi: một ứng dụng có nhiều loại điểm cuối hoặc các mô hình có hợp đồng khác biệt đáng kể.
Cần lưu ý: dữ liệu danh mục lỗi thời. Hãy xem ID mô hình, năng lực và việc ngừng hỗ trợ là dữ liệu vận hành cần được xác minh thường xuyên.
4. Định tuyến có trọng số theo chi phí, chất lượng, độ trễ và độ tin cậy
Các tuyến đủ điều kiện nhận điểm dựa trên mục tiêu hiện tại. Đây là câu trả lời phổ biến cho định tuyến LLM là gì khi một nhóm muốn nhiều sắc thái hơn quy tắc cố định nhưng vẫn cần một chính sách có thể giải thích.
Sử dụng khi: bạn có thể xác định tín hiệu chấp nhận có thể đo lường và có đủ dữ liệu đo từ xa về tuyến để so sánh các ứng viên.
Cần lưu ý: độ chính xác giả tạo. Một điểm số chỉ hữu ích tương ứng với dữ liệu chất lượng, các giả định chi phí, tín hiệu tình trạng và trọng số đằng sau nó. Đừng ngụ ý rằng điểm số thập phân chứng minh một mô hình tốt hơn trên mọi phương diện.
5. Định tuyến dựa trên bộ phân loại
Một bộ phân loại nhỏ hoặc bộ phân loại dựa trên LLM gán nhãn cho yêu cầu—chẳng hạn như trích xuất đơn giản, sinh mã, suy luận phức tạp hoặc nội dung nhạy cảm về an toàn—sau đó chuyển yêu cầu đến một chính sách được xác định trước cho lớp đó.
Sử dụng khi: ý định của prompt dự báo mạnh mẽ tầng mô hình phù hợp và bạn có thể đánh giá riêng lỗi của bộ phân loại với lỗi của mô hình.
Cần lưu ý: thêm một quyết định không minh bạch trước lệnh gọi mô hình. Hãy duy trì một đường dẫn cho trường hợp độ tin cậy thấp, ghi nhật ký phân loại và đánh giá bộ phân loại dựa trên các yêu cầu đại diện.
6. Định tuyến dự phòng nhận biết tình trạng
Đường dẫn chính được chọn như bình thường, nhưng bộ định tuyến phản ứng với tình trạng hết thời gian chờ, quá tải, giới hạn tốc độ hoặc suy giảm tình trạng bằng một lần thử lại có giới hạn, một phương án dự phòng tương đương, hàng đợi hoặc lỗi được kiểm soát.
Sử dụng khi: tính sẵn sàng là quan trọng và bạn đã xác định những phương án dự phòng nào tương thích với hợp đồng.
Cần lưu ý: âm thầm vượt qua một ranh giới ngữ nghĩa. Phương án dự phòng có thể phù hợp cho một tác vụ hoàn tất văn bản có thể thử lại, nhưng không phù hợp với tác nhân sử dụng công cụ, quy trình làm thay đổi trạng thái hoặc đầu ra phải khớp một schema nghiêm ngặt. Xem hướng dẫn của chúng tôi về định tuyến tác nhân đa phương thức để biết các ví dụ mà thay đổi phương thức khiến quy tắc dự phòng trở nên nghiêm ngặt hơn.
Xây dựng chính sách nhận biết chi phí mà không trở nên mù quáng về chất lượng
Nhận biết chi phí không có nghĩa là “luôn chọn mô hình rẻ nhất”. Nó có nghĩa là trao cho chi phí một vai trò xác định sau khi các bước kiểm tra năng lực, chính sách và hợp đồng bắt buộc đã được thông qua.
Một mô hình hữu ích là tạo các lớp lưu lượng trước khi thiết lập trọng số:
| Loại lưu lượng | Ưu tiên hàng đầu | Cách tiếp cận định tuyến phổ biến | Phương án dự phòng an toàn |
|---|---|---|---|
| Trợ lý hướng đến khách hàng | Chất lượng và hợp đồng có thể dự đoán | Bộ lọc năng lực + trọng số chất lượng/độ trễ | Chỉ tuyến tương đương đã được phê duyệt |
| Trích xuất nền | Thông lượng và chi phí đơn vị | Quy tắc + trọng số chi phí/độ trễ | Thử lại, xếp hàng đợi hoặc tuyến đã được phê duyệt có chi phí thấp hơn |
| Bộ đánh giá | Khả năng tái lập | Ghim phiên bản mô hình và chính sách | Thường không có phương án dự phòng ẩn |
| Agent sử dụng công cụ | Khả năng tương thích công cụ và tính idempotent | Bộ lọc năng lực + quy tắc rủi ro | Dừng và đối soát khi có tác dụng phụ không chắc chắn |
| Tạo nội dung đa phương tiện | Yêu cầu về endpoint và đầu ra | Bộ lọc phương thức/endpoint + quy tắc ngân sách | Đóng khi xảy ra lỗi trừ khi bản sao lưu đã được kiểm thử |
Sau đó, hãy so sánh con số quan trọng: chi phí cho mỗi kết quả được chấp nhận, không chỉ chi phí cho mỗi yêu cầu. Một tuyến có giá thấp hơn nhưng gây ra thêm lần thử lại, rà soát thủ công, sửa chữa schema hoặc lệnh gọi công cụ thất bại có thể tốn nhiều hơn cho mỗi tác vụ hoàn thành.
Tài liệu về định tuyến của Amazon cũng đưa ra cùng một lưu ý thực tế trong một bối cảnh khác: định tuyến tự động có các giới hạn, bao gồm dữ liệu huấn luyện dành riêng cho từng tuyến và các ranh giới hỗ trợ. Tài liệu khuyến nghị liên tục xem xét hiệu suất và chi phí thay vì cho rằng một quyết định định tuyến sẽ luôn tối ưu. Chính sách của bạn nên được đánh giá dựa trên tổ hợp yêu cầu của riêng bạn.
Chính sách định tuyến an toàn, dưới dạng mã giả
Ví dụ đơn giản hóa này giúp quyết định có thể kiểm toán. Nó không giả định rằng mọi tuyến đều có thể xử lý mọi yêu cầu.
const candidates = catalog
.filter(route => route.isHealthy)
.filter(route => route.supports(request.modality))
.filter(route => route.supportsTools(request.requiredTools))
.filter(route => route.allows(request.dataClass))
.filter(route => route.withinBudget(request.budget));
if (candidates.length === 0) {
return failClosed("No approved route for this request");
}
const primary = candidates
.map(route => ({
route,
score: score(route, request.trafficClass),
}))
.sort((a, b) => b.score - a.score)[0];
const result = await call(primary.route, request);
if (isTransient(result.error) && request.isIdempotent) {
return retryWithinBudget(primary.route, request);
}
if (canUseEquivalentFallback(result.error, request, primary.route)) {
return call(selectApprovedFallback(candidates, primary.route), request);
}
return returnControlledError(result.error);
Chính sách nên tạo ra một lý do định tuyến như tool_contract_required, budget_preferred, primary_unhealthy hoặc no_contract_safe_fallback. Chi tiết nhỏ này giúp hệ thống dễ gỡ lỗi hơn nhiều so với thông báo chung chung “mô hình thất bại”.
Cách đo lường liệu định tuyến LLM có mang lại hiệu quả hay không
Định tuyến không thành công chỉ vì nó tạo ra một tên mô hình. Nó thành công khi cải thiện kết quả của một khối lượng công việc đã xác định mà không tạo ra rủi ro không thể chấp nhận.
Theo dõi kết quả theo loại lưu lượng, phiên bản chính sách và tuyến được chọn:
- Tỷ lệ kết quả được chấp nhận: tỷ lệ phản hồi vượt qua bài kiểm tra chấp nhận về nghiệp vụ, schema hoặc đánh giá của con người.
- Chi phí cho mỗi kết quả được chấp nhận: tổng chi phí mô hình, thử lại và khắc phục chia cho số tác vụ được chấp nhận.
- Độ trễ P50, P95 và P99: phân đoạn theo kích thước yêu cầu và tuyến; giá trị trung bình có thể che giấu độ trễ đuôi gây khó chịu.
- Tỷ lệ khôi phục bằng phương án dự phòng: tần suất một phương án dự phòng tạo ra kết quả có thể chấp nhận, chứ không chỉ là HTTP 200.
- Tỷ lệ thất bại hợp đồng: đầu ra có cấu trúc không hợp lệ, công cụ không được hỗ trợ, không tương thích với streaming hoặc thiếu các trường bắt buộc.
- Phân bổ tuyến: liệu một chính sách mới có đang bất ngờ gửi phần lớn lưu lượng đến một đường dẫn đắt đỏ hoặc suy giảm hay không.
- Tỷ lệ từ chối chính sách: tần suất không có ứng viên an toàn—thường là tín hiệu cần mở rộng các năng lực đã được phê duyệt thay vì nới lỏng một rào chắn.
Để xem bảng điểm thực tế, hãy tham khảo Các chỉ số API định tuyến AI thực sự quan trọng. Các chỉ số này đặc biệt hữu ích khi một thay đổi định tuyến có vẻ làm giảm chi phí token nhưng lại làm giảm số kết quả được chấp nhận.
Khi nào bạn cần định tuyến LLM?
Bạn có thể không cần một bộ định tuyến khi một nhà cung cấp, một endpoint và một khối lượng công việc ổn định đáp ứng các yêu cầu của bạn. Hãy ghim mô hình, đặt thời gian chờ và cơ chế thử lại rõ ràng, rồi đo lường đường cơ sở trước.
Định tuyến LLM trở nên có giá trị khi ít nhất một trong các điều sau là đúng:
- Các loại yêu cầu khác nhau cần những năng lực, khung chi phí hoặc mục tiêu độ trễ khác nhau.
- Bạn cần giữ các lựa chọn về nhà cung cấp, mô hình và khu vực phía sau một ranh giới chính sách.
- Sự cố gián đoạn, vấn đề hạn ngạch hoặc việc ngừng hỗ trợ cần một đường phản hồi an toàn.
- Bạn muốn so sánh các ứng viên mà không phải viết lại mọi bên gọi.
- Bạn cần một bản ghi về tuyến nào đã xử lý một yêu cầu và lý do.
Nếu hệ thống của bạn có cấu trúc như vậy, một gateway có thể giúp ranh giới vận hành dễ quản lý hơn. Tài liệu của Flatkey mô tả một URL cơ sở tương thích với OpenAI và một khóa API duy nhất cho các mô hình được hỗ trợ; bên gọi chọn một ID mô hình cho mỗi yêu cầu, trong khi nền tảng có tài liệu về cơ chế chuyển đổi dự phòng upstream tự động. Hãy bắt đầu bằng cách cố định một mô hình và ghi nhật ký kết quả, sau đó áp dụng một chính sách định tuyến rõ ràng cho các lớp lưu lượng thực sự cần đến nó. Để tìm hiểu bước kiến trúc tiếp theo, hãy đọc danh sách kiểm tra các yêu cầu đối với AI API gateway của chúng tôi.
Để tìm hiểu các chiến lược định tuyến, một mẫu chính sách và mã nguồn production, hãy đọc hướng dẫn định tuyến mô hình của chúng tôi.
Câu hỏi thường gặp
Định tuyến LLM khác với dự phòng mô hình như thế nào?
Định tuyến LLM là quy trình ra quyết định rộng hơn để chọn một đường thực thi. Dự phòng mô hình là một hành động khôi phục trong quy trình đó, chỉ được sử dụng khi tuyến chính thất bại và một tuyến thay thế được phê duyệt cho cùng một hợp đồng yêu cầu.
Định tuyến LLM trong một API đa nhà cung cấp là gì?
Trong một API đa nhà cung cấp, định tuyến LLM có thể chọn đường đi của nhà cung cấp cũng như mô hình. Chính sách cần xác minh khả năng tương thích của endpoint, chính sách dữ liệu, năng lực mô hình, đơn vị định giá, tình trạng hoạt động và hành vi dự phòng trước khi xem hai nhà cung cấp là tương đương.
Một nhóm mới nên bắt đầu với kỹ thuật định tuyến LLM nào?
Hãy bắt đầu với định tuyến tĩnh, kết hợp kiểm tra năng lực rõ ràng và khả năng quan sát. Thêm quy tắc cho các lớp lưu lượng khác biệt rõ rệt. Chỉ chuyển sang định tuyến dựa trên trọng số hoặc bộ phân loại sau khi bạn có các kiểm thử mang tính đại diện và cách đo lường các kết quả được chấp nhận.
Bộ định tuyến LLM có thể tự động chọn mô hình rẻ nhất không?
Có thể, nhưng chi phí không bao giờ được phép vượt qua các ràng buộc cứng. Trước tiên, hãy lọc theo năng lực đã được phê duyệt và khả năng tương thích hợp đồng, sau đó tối ưu giá trong số các tuyến đủ điều kiện. Xác thực kết quả bằng chi phí trên mỗi kết quả được chấp nhận, thay vì chỉ dựa vào giá token.
Câu trả lời thực tế cho câu hỏi “định tuyến LLM là gì?”
Câu trả lời thực tế cho định tuyến LLM là gì không phải là “chọn một mô hình thông minh”. Mà là “mã hóa những lựa chọn mà nhóm của bạn có thể bảo vệ”. Hãy bắt đầu với các năng lực được phê duyệt và ràng buộc cứng; chỉ dùng trọng số cho các đánh đổi thực tế; giữ phương án dự phòng trong giới hạn và an toàn với hợp đồng; đồng thời ghi lại đầy đủ mọi quyết định để có thể cải thiện chúng sau này.
Nếu bạn đang tập trung hóa quyền truy cập mô hình, hãy tận dụng ranh giới đó để thực hiện các thử nghiệm định tuyến có kiểm soát thay vì phân tán logic nhà cung cấp qua mọi dịch vụ. Tìm hiểu thêm trong tài liệu API Flatkey.



