Định tuyến dự phòng cho API LLM rất đơn giản khi mọi yêu cầu đều trả về văn bản. Nếu tuyến chính bị quá thời gian chờ, bạn thử lại một lần, chuyển sang mô hình dự phòng, xác thực schema và ghi lại lý do.
Logic đó sẽ đổ vỡ khi cùng một sản phẩm cũng định tuyến việc tạo hình ảnh, chuyển lời nói thành văn bản, tạo giọng nói và tạo video. Một phương án dự phòng an toàn cho việc trích xuất JSON không tự động an toàn cho hình ảnh thương hiệu. Một phương án dự phòng speech-to-text không giống với phương án dự phòng text-to-speech. Một phương án dự phòng video có thể tạo ra chi phí trùng lặp, gây nhầm lẫn hàng đợi hoặc tạo ra đầu ra vẫn cần con người phê duyệt.
Hướng dẫn này biến Fallback Routing for LLM APIs: Multimodal Agent Routing for Text, Image, Audio, and Video thành một playbook triển khai cho các nhóm sản phẩm AI. Mục tiêu không phải là chọn một mô hình duy nhất cho mọi trường hợp. Mục tiêu là làm cho việc chọn tuyến, xác minh, dự phòng và xem xét chi phí trở nên rõ ràng cho từng phương thức mà tác tử của bạn chạm tới.
Tính đến ngày 12 tháng 9 năm 2026, các trang công khai trực tiếp của Flatkey định vị sản phẩm xoay quanh một key, một số dư, một hóa đơn, hơn 100 mô hình AI chính thức, hơn 1.000 công cụ, thiết lập tương thích OpenAI, nhật ký sử dụng và cơ chế failover tự động. Các trang công khai về mô hình và giá của Flatkey cũng hiển thị các tuyến mô hình định hướng cho văn bản, hình ảnh, âm thanh và video. Hãy coi các trang trực tiếp đó là điểm kiểm tra thương mại hiện tại trước khi triển khai vì tính sẵn có của mô hình, giá cả và tình trạng tuyến có thể thay đổi.
Câu trả lời nhanh: điều gì thay đổi trong định tuyến dự phòng đa phương thức?
Trong các hệ thống chỉ có văn bản, dự phòng thường chỉ hỏi một câu: "Một tuyến khác có thể tạo ra câu trả lời tương đương không?"
Trong các hệ thống đa phương thức, định tuyến dự phòng cho API LLM phải hỏi bốn câu:
- Đang tạo ra hiện vật nào? Văn bản, hình ảnh, âm thanh và video không dùng chung một tiêu chuẩn chất lượng.
- Hiện vật được xác minh như thế nào? Bộ phân tích JSON, người duyệt hình ảnh, bộ kiểm tra bản ghi chép và hàng đợi phê duyệt video là các hệ thống xác minh khác nhau.
- Thất bại nào thực sự có thể khắc phục? Giới hạn tốc độ, quá thời gian chờ, đầu vào không hợp lệ, từ chối vì an toàn và đầu ra kém chất lượng cần những hành động khác nhau.
- Phương án dự phòng có thể giữ nguyên hợp đồng không? Một tuyến dự phòng chỉ an toàn khi nó giữ nguyên phương thức, hình dạng đầu ra, ngân sách độ trễ, trần chi phí và đường dẫn xem xét.
Quy tắc thực tiễn rất đơn giản: phương án dự phòng chỉ ở trong lớp quy trình làm việc, trừ khi một lớp con người hoặc chính sách phê duyệt rõ ràng việc chuyển sang.
Vì sao các lần thử lại chung chung thất bại đối với văn bản, hình ảnh, âm thanh và video
Các lần thử lại chung chung coi mọi yêu cầu thất bại như một vấn đề truyền tải. Cách nhìn đó quá nông đối với định tuyến tác tử đa phương thức.
| Phương thức | Dạng lỗi thường gặp | Tại sao thử lại chung chung là rủi ro |
|---|---|---|
| Văn bản | Quá thời gian, giới hạn tốc độ, lỗi bộ phân tích, không khớp lời gọi công cụ, câu trả lời yếu | Thử lại có thể an toàn, nhưng chuyển mô hình có thể làm hỏng lược đồ, trích dẫn, công cụ hoặc giọng điệu. |
| Hình ảnh | Chặn an toàn, sai tỷ lệ khung hình, không khớp thương hiệu, độ trung thực thấp, bám chỉnh sửa kém | Một mô hình hình ảnh khác có thể trả về tệp hợp lệ nhưng vẫn không đạt bài đánh giá sáng tạo. |
| Âm thanh | Định dạng không được hỗ trợ, bản ghi kém, sai ngôn ngữ, không khớp giọng nói, độ trễ tăng đột biến | Phiên âm, dịch thuật và đầu ra giọng nói là các tác vụ riêng biệt với các quy tắc dự phòng riêng. |
| Video | Hàng đợi dài, tác vụ thất bại, tài sản hết hạn, chuyển động không nhất quán, đầu ra bị từ chối tốn kém | Gửi lại một cách mù quáng có thể tạo ra tác vụ trùng lặp, chi phí trùng lặp và nhiều tài sản hơn để xem xét. |
Bộ định tuyến cần biết liệu một lỗi là sự kiện dịch vụ có thể thử lại, một yêu cầu không hợp lệ, một kết quả về an toàn hay chính sách, hay một thiếu hụt về chất lượng. Những nhóm đó dẫn đến các hành động khác nhau.
Bắt đầu với các lớp tuyến, không phải tên mô hình
Định tuyến dự phòng an toàn nhất cho API LLM bắt đầu với các lớp tuyến. Mô hình có thể đi vào và ra khỏi một lớp khi mức độ sẵn có và chất lượng thay đổi; chính sách quy trình làm việc nên ổn định.
| Lớp tuyến | Các tác vụ chính | Lớp xác minh | Hành vi dự phòng mặc định |
|---|---|---|---|
| Suy luận văn bản | Trích xuất, phân loại, tóm tắt, lập trình, đầu ra có cấu trúc, lời gọi công cụ | Kiểm tra lược đồ, kiểm thử bộ phân tích, lấy mẫu theo rubric, thành công của công cụ | Có thể cho phép tự động dự phòng khi bản sao lưu bảo toàn dạng phản hồi và hành vi công cụ. |
| Hiểu thị giác | Phân tích hình ảnh, xem xét tài liệu, diễn giải ảnh chụp màn hình | Kiểm tra đầu ra văn bản cùng với độ phủ đầu vào trực quan | Dự phòng sang một tuyến suy luận có khả năng thị giác khác, không phải sang tuyến tạo ảnh. |
| Tạo hoặc chỉnh sửa hình ảnh | Ảnh mới, chỉnh sửa, biến thể sản phẩm, bản nháp sáng tạo | QA trực quan, kiểm tra thương hiệu, rà soát mẫu prompt | Chỉ dự phòng sang một tuyến hình ảnh đã được phê duyệt với tỷ lệ khung hình, phong cách và quy tắc rà soát khớp nhau. |
| Đầu vào âm thanh | Phiên âm, dịch thuật, tóm tắt cuộc họp, QA cuộc gọi | Kiểm tra độ chính xác bản ghi, kiểm tra ngôn ngữ, rà soát dấu thời gian | Dự phòng sang một tuyến phiên âm hoặc hiểu âm thanh khác với cùng giới hạn đầu vào. |
| Đầu ra âm thanh | Tổng hợp giọng nói, phản hồi tác tử giọng nói, thuyết minh | QA phát lại, chính sách giọng nói, ngân sách độ trễ | Dự phòng sang một tuyến giọng nói đã được phê duyệt; giữ tách biệt với dự phòng phiên âm. |
| Tạo video | Text-to-video, image-to-video, clip xem trước, tài sản sáng tạo | Phê duyệt của con người, kiểm tra thời lượng/độ trung thực, giám sát hàng đợi | Giữ phạm vi dự phòng hẹp; thường chuyển sang xem xét thủ công thay vì tự động tạo một tác vụ khác. |
Ma trận phân loại tuyến này ngăn một sai lầm phổ biến: coi "mô hình đa phương thức" như một nhóm năng lực duy nhất. Một mô hình chấp nhận hình ảnh để phân tích không nhất thiết có thể tạo ra hình ảnh. Một mô hình hiểu âm thanh không tự động là mô hình giọng nói sẵn sàng cho môi trường sản xuất. Một mô hình có thể tạo video trong bản demo không tự động an toàn cho tự động hóa hướng tới khách hàng.
Sử dụng ma trận quyết định dự phòng trước khi bạn viết mã
Một ma trận quyết định cung cấp cho sản phẩm, kỹ thuật và vận hành một chính sách chung. Hãy bắt đầu với ma trận bên dưới và thay các ví dụ bằng mô hình, nhà cung cấp và quy tắc phê duyệt của riêng bạn.
| Điều kiện | Hành động cho văn bản | Hành động cho hình ảnh | Hành động cho âm thanh | Hành động cho video |
|---|---|---|---|---|
| Route chính hết thời gian chờ trước khi bắt đầu xuất ra | Thử lại trong giới hạn ngân sách, rồi chuyển sang route văn bản đã được phê duyệt | Thử lại một lần nếu chưa có tài sản nào được tạo, rồi chuyển sang route hình ảnh đã được phê duyệt | Thử lại hoặc chuyển dự phòng trong cùng loại tác vụ âm thanh | Kiểm tra trạng thái tác vụ trước; không tạo tác vụ trùng lặp cho đến khi biết trạng thái ban đầu. |
| Lỗi giới hạn tốc độ hoặc giới hạn năng lực | Chuyển dự phòng khi bản sao lưu đáp ứng giới hạn lược đồ và chi phí | Chuyển dự phòng khi bản sao lưu đáp ứng giới hạn prompt, kích thước và rà soát | Chuyển dự phòng khi bản sao lưu hỗ trợ cùng định dạng tệp và ngôn ngữ | Chỉ chuyển dự phòng nếu chi phí trùng lặp và hành vi hàng đợi là chấp nhận được. |
| Yêu cầu không hợp lệ hoặc đầu vào không được hỗ trợ | Dừng và sửa yêu cầu | Dừng và sửa prompt, loại đầu vào, kích thước hoặc tỉ lệ khung hình | Dừng và sửa định dạng phương tiện, thời lượng, ngôn ngữ hoặc tốc độ lấy mẫu | Dừng và sửa thời lượng, phương tiện tham chiếu, prompt hoặc các trường endpoint. |
| Từ chối vì an toàn hoặc chính sách | Không che giấu việc từ chối bằng dự phòng | Không vượt qua chính sách bằng mô hình khác | Không vượt qua chính sách bằng nhà cung cấp âm thanh khác | Không vượt qua chính sách bằng nhà cung cấp video khác. |
| Đầu ra không vượt qua xác minh tự động | Chuyển dự phòng nếu hợp đồng có thể kiểm tra bằng máy | Gửi tới rà soát trực quan hoặc tạo lại theo chính sách route đã được phê duyệt | Gửi tới rà soát bản ghi/phát lại hoặc chuyển dự phòng trong cùng loại tác vụ | Gửi tới rà soát thủ công; dùng các quy tắc tạo lại, không phải chuyển tiếp mù quáng. |
| Đầu ra streaming một phần đã đến tay người dùng | Thường dừng và đối chiếu; tránh chuyển đổi mô hình một cách minh bạch | Không áp dụng cho hầu hết route hình ảnh | Dừng và đối chiếu trạng thái mà người dùng nhìn thấy | Không chuyển đổi âm thầm sau khi đã có trạng thái tác vụ hiển thị. |
| Lời gọi công cụ có thể đã tạo ra tác động phụ | Đối chiếu tính idempotent trước khi thử lại hoặc chuyển dự phòng | Đối chiếu mọi ghi chép tài sản/lưu trữ | Đối chiếu trạng thái bản ghi, cuộc gọi hoặc phiên giọng nói | Đối chiếu trước trạng thái ID tác vụ, lưu trữ, thanh toán và phê duyệt. |
Ma trận này là tài sản giá trị chính của bài viết. Nó biến định tuyến dự phòng cho API LLM từ một suy nghĩ muộn về mặt kỹ thuật thành một chính sách có thể được rà soát trước khi lưu lượng sản xuất được chuyển đi.
Kiến trúc tham chiếu cho định tuyến tác tử đa phương thức
Một bộ định tuyến trong môi trường sản xuất không cần phải phức tạp, nhưng nó cần các ranh giới rõ ràng.
flowchart LR
A[Yêu cầu của tác tử] --> B[Phân loại quy trình làm việc]
B --> C[Chọn tuyến chính]
C --> D[Gọi nhà cung cấp hoặc cổng]
D --> E[Xác minh artifact]
E -->|pass| F[Trả về và ghi log]
E -->|retryable failure| G[Chính sách dự phòng]
E -->|policy or invalid input| H[Dừng với lỗi có thể hành động]
G --> I[Tuyến dự phòng đã được phê duyệt]
I --> D
G --> J[Đánh giá của con người hoặc hàng đợi thủ công]
Các thành phần chính là:
- Bộ phân loại quy trình làm việc: gán nhãn tác vụ là văn bản, thị giác, tạo ảnh, đầu vào âm thanh, đầu ra âm thanh hoặc tạo video trước khi chọn tuyến.
- Sổ đăng ký năng lực: ghi lại tuyến nào hỗ trợ từng phương thức, điểm cuối, định dạng đầu vào, dạng đầu ra, ngữ cảnh tối đa, hành vi streaming và lớp chi phí.
- Chính sách dự phòng: xác định các lỗi có thể thử lại, các tuyến dự phòng được phép, quy tắc chống bỏ qua và số lần thử tối đa.
- Lớp xác minh: kiểm tra artifact trước khi trả về cho người dùng hoặc chuyển tiếp xuống phía sau.
- Sổ cái và khả năng quan sát: ghi model, tuyến, chủ sở hữu, trạng thái, lý do dự phòng, độ trễ, mức sử dụng, chi phí và kết quả của người duyệt.
Flatkey có thể nằm ở lớp nhà cung cấp-hoặc-cổng khi một nhóm muốn có một bộ định tuyến tương thích OpenAI, một số dư dùng chung và một nơi duy nhất để xem xét các tuyến model được hỗ trợ. Ứng dụng của bạn vẫn sở hữu chính sách: lớp phương thức nào được phép dự phòng, khi nào dừng và khi nào cần con người quyết định.
Định nghĩa chính sách dưới dạng dữ liệu
Giữ chính sách định tuyến ngoài các câu lệnh if rải rác. Một đối tượng dữ liệu nhỏ dễ rà soát hơn và an toàn hơn khi thay đổi.
{
"workflow": "support_ticket_with_screenshot",
"route_class": "vision_understanding",
"primary_model": "primary-vision-reasoning-route",
"fallback_models": ["backup-vision-reasoning-route"],
"fallback_on": ["timeout_before_output", "rate_limit", "upstream_5xx"],
"do_not_fallback_on": ["safety_rejection", "invalid_input", "partial_stream_sent"],
"verification": {
"type": "structured_text",
"required_fields": ["summary", "severity", "evidence"]
},
"max_attempts": 2,
"max_incremental_cost_usd": 0.05,
"log_fields": [
"request_id",
"workspace_id",
"route_class",
"model",
"fallback_reason",
"latency_ms",
"cost_usd",
"verification_status"
]
}
Cùng cấu trúc này có thể biểu diễn các quy trình làm việc với media:
{
"workflow": "product_video_preview",
"route_class": "video_generation",
"primary_model": "primary-video-route",
"fallback_models": ["approved-video-preview-route"],
"fallback_on": ["provider_5xx", "capacity_unavailable"],
"do_not_fallback_on": ["client_timeout_without_task_state", "safety_rejection", "asset_created"],
"verification": {
"type": "human_review",
"checks": ["duration", "motion", "brand_safety", "reference_consistency"]
},
"max_attempts": 1,
"manual_queue_after_failure": true
}
Lưu ý sự khác biệt: chính sách cho văn bản thường có thể tự động dự phòng vì kết quả có thể được kiểm tra bằng máy. Chính sách cho video hẹp hơn vì một lần tạo thứ hai không chỉ là thử lại; nó là một tài sản khác và một sự kiện chi phí khác.
Các quy tắc dự phòng theo từng phương thức
Văn bản: giữ nguyên hợp đồng phản hồi
Văn bản là nơi dễ bắt đầu nhất vì việc xác minh có thể được tự động hóa. Đối với định tuyến dự phòng cho API LLM, một bản sao lưu cho văn bản nên giữ nguyên:
- hình dạng của endpoint;
- hình dạng của sự kiện streaming nếu có dùng;
- hành vi JSON hoặc đầu ra có cấu trúc;
- hành vi gọi công cụ;
- yêu cầu trích dẫn hoặc truy xuất;
- trần độ trễ;
- trần chi phí.
Sai lầm là chuyển dự phòng từ một route đầu ra có cấu trúc dự đoán được sang một mô hình sáng tạo hơn nghe hay hơn nhưng làm hỏng việc phân tích phía sau. Nếu route phục vụ tự động hóa sản phẩm, độ ổn định của bộ phân tích quan trọng hơn văn phong.
Thị giác: tách hiểu hình ảnh khỏi tạo ảnh
Các tác vụ thị giác thường tạo ra văn bản về một hình ảnh. Các tác vụ tạo ảnh tạo ra một hiện vật trực quan mới. Chúng không nên dùng chung một nhóm dự phòng.
OpenAI, Google Gemini và Anthropic đều tài liệu hóa các khả năng API liên quan đến hiểu hình ảnh hoặc hình ảnh, nhưng các tài liệu đó mô tả những bề mặt yêu cầu và hành vi mô hình khác nhau. Với định tuyến tác tử đa phương thức, câu hỏi chính sách không đơn giản là "route này có thể xử lý ảnh không?" Mà là "route này có xử lý tác vụ ảnh này với cùng ràng buộc đầu vào và hợp đồng đầu ra không?"
Ví dụ, một quy trình triage ảnh chụp màn hình có thể cần một route suy luận có khả năng thị giác và trả về văn bản có cấu trúc. Một quy trình sáng tạo thương hiệu cần một route tạo ảnh trả về tệp và vượt qua đánh giá trực quan. Đó là các lớp route riêng biệt.
Tạo ảnh: không vượt qua khâu duyệt sáng tạo
Định tuyến dự phòng cho ảnh nên bảo vệ hợp đồng sáng tạo:
- tỷ lệ khung hình;
- độ phân giải hoặc hạng kích thước;
- chỉnh sửa so với tạo mới hoàn toàn;
- khả năng tương thích với mẫu prompt;
- xem xét thương hiệu và tuân thủ;
- vòng đời lưu trữ và tài sản;
- chi phí trên mỗi tài sản được chấp nhận.
Nếu route ảnh chính thất bại vì đầu vào không hợp lệ, dự phòng là lựa chọn sai. Hãy sửa yêu cầu. Nếu nó thất bại vì nhà cung cấp tạm thời không khả dụng trước khi bất kỳ tài sản nào được tạo ra, dự phòng có thể hợp lý khi route sao lưu đã vượt qua QA trực quan.
Âm thanh: tách phiên âm, hiểu và giọng nói
Định tuyến âm thanh thường che giấu ba công việc khác nhau:
- Chuyển giọng nói thành văn bản: chuyển âm thanh thành bản ghi.
- Hiểu âm thanh: suy luận về nội dung âm thanh, ý định của người nói, hoặc ngữ cảnh cuộc họp.
- Chuyển văn bản thành giọng nói: tạo đầu ra được nói ra.
Các công việc đó có các chế độ lỗi khác nhau. Một luồng phiên âm có thể được đánh giá bằng tỷ lệ lỗi từ, từ vựng theo miền, nhãn người nói, dấu thời gian và độ trễ. Một luồng giọng nói được đánh giá bằng chất lượng giọng, phát âm, độ trễ, chính sách giọng nói được phép và trải nghiệm phát lại.
Cơ chế dự phòng nên nằm trong đúng loại công việc âm thanh cụ thể. Đừng dùng "có khả năng xử lý âm thanh" như một nhãn chính sách duy nhất.
Video: coi dự phòng như một sự kiện sản xuất khác
Video thường là phương thức có rủi ro cao nhất cho cơ chế dự phòng tự động vì một yêu cầu thất bại hoặc chậm có thể đã tạo ra một tác vụ ở phía nhà cung cấp. Trước khi tạo tác vụ khác, hệ thống của bạn nên biết:
- liệu tác vụ gốc có tồn tại hay không;
- liệu nó đang ở trạng thái chờ, đang xử lý, thành công, thất bại hay đã hết hạn;
- liệu một URL đầu ra đã được tạo hay chưa;
- liệu bất kỳ mức sử dụng hoặc chi phí nào đã được ghi nhận hay chưa;
- liệu một người duyệt đã xem tài sản hay chưa;
- liệu việc tạo lại lần thứ hai có vi phạm ngân sách hoặc luồng phê duyệt hay không.
Với việc tạo video, mặc định an toàn là: chỉ thử lại phần vận chuyển trước khi tồn tại tác vụ, thăm dò tác vụ hiện có cho đến trạng thái cuối, rồi dùng một luồng tạo lại thủ công hoặc được phê duyệt một cách chặt chẽ.
Ghi gì khi cơ chế dự phòng xảy ra
Cơ chế dự phòng không hiển thị trong nhật ký sẽ trở nên không thể cải thiện. Tối thiểu, mọi yêu cầu nên ghi lại:
| Trường | Vì sao nó quan trọng |
|---|---|
request_id |
Gắn hành vi mà người dùng thấy với bằng chứng từ nhà cung cấp và cổng trung gian. |
route_class |
Cho biết công việc là văn bản, thị giác, hình ảnh, âm thanh hay video. |
primary_model và final_model |
Cho biết luồng nào đã trả lời hoặc tạo ra hiện vật. |
fallback_reason |
Phân biệt hết thời gian chờ, giới hạn tốc độ, lỗi upstream, lỗi xác minh hoặc ghi đè thủ công. |
attempt_count |
Ngăn các vòng lặp thử lại không có giới hạn. |
latency_ms |
Cho biết cơ chế dự phòng có giúp hay làm hại trải nghiệm người dùng. |
usage và cost |
Làm rõ kinh tế của tuyến dự phòng. |
verification_status |
Kết nối dự phòng với chất lượng đầu ra, không chỉ là thành công của API. |
reviewer_outcome |
Cần cho việc theo dõi chấp nhận đối với hình ảnh, âm thanh và video. |
Đối với các nhóm sản phẩm AI, chỉ số hữu ích nhất thường không phải là thời gian hoạt động thô. Đó là tỷ lệ đầu ra được chấp nhận sau dự phòng. Một tuyến dự phòng trả về nhanh nhưng tạo ra các tài sản bị từ chối thì không đáng tin cậy theo nghĩa sản phẩm.
Flatkey phù hợp ở đâu
Flatkey có liên quan đến định tuyến dự phòng cho API LLM vì vấn đề vận hành lớn hơn một lần gọi API. Các sản phẩm đa phương thức thường tích lũy các khóa riêng theo nhà cung cấp, tài khoản thanh toán trực tiếp, ID mô hình rời rạc, xử lý lỗi không nhất quán, và các bảng điều khiển riêng cho thử nghiệm văn bản, hình ảnh, âm thanh và video.
Các tài liệu công khai và website của Flatkey cung cấp cho các đội ngũ một URL bộ định tuyến tương thích OpenAI duy nhất cho các lệnh gọi mô hình được hỗ trợ, một danh mục mô hình, nhật ký sử dụng, một số dư và một giao diện hóa đơn duy nhất. Website trực tiếp cũng định khung độ tin cậy xung quanh cơ chế tự động chuyển đổi dự phòng và các giao diện trạng thái/SLA công khai. Điều đó không loại bỏ nhu cầu về chính sách đa phương thức của riêng bạn. Nó chỉ cho chính sách đó một nơi để hoạt động thay vì phân tán việc lựa chọn tuyến trên khắp mã tính năng.
Hãy dùng Flatkey khi bạn muốn:
- một điểm cuối bộ định tuyến duy nhất trong khi so sánh các tuyến mô hình được hỗ trợ;
- một nơi để kiểm tra khả năng sẵn sàng của mô hình và bối cảnh thương mại;
- một số dư và một hóa đơn thay vì các tài khoản nhà cung cấp rời rạc;
- nhật ký sử dụng cho mô hình, token, chi phí, độ trễ và xem xét của chủ sở hữu;
- quản trị tuyến khi nhiều tác tử và quy trình làm việc hơn áp dụng API AI.
Hãy dùng tài khoản nhà cung cấp trực tiếp khi chỉ một nhà cung cấp là yêu cầu duy nhất, khối lượng công việc không cần chuyển đổi dự phòng, và con đường nhà cung cấp đơn giản nhất quan trọng hơn kiểm soát xuyên mô hình.
Danh sách kiểm tra triển khai cho định tuyến dự phòng cho API LLM
Trước khi bạn bật chuyển đổi dự phòng tự động trong một sản phẩm đa phương thức, hãy hoàn thành danh sách kiểm tra này:
- Kiểm kê các phương thức. Liệt kê mọi quy trình làm việc tạo văn bản, phân tích hình ảnh, tạo hình ảnh, chấp nhận âm thanh, nói, hoặc tạo video.
- Gán các lớp tuyến. Đừng để một nhãn "đa phương thức" che phủ các loại hiện vật khác nhau.
- Xác định việc xác minh. Mỗi lớp tuyến cần một phương pháp đạt/không đạt trước khi có thể tin cậy vào cơ chế chuyển đổi dự phòng.
- Tách thử lại khỏi chuyển đổi dự phòng. Thử lại lặp lại cùng một tuyến. Chuyển đổi dự phòng thay đổi tuyến. Tạo lại tạo ra một hiện vật mới.
- Viết các quy tắc chống lách. Từ chối vì an toàn, đầu vào không hợp lệ, tác động phụ, và đầu ra một phần hiển thị được không nên âm thầm chuyển sang dự phòng.
- Đặt trần chi phí. Một cơ chế dự phòng cứu được yêu cầu nhưng làm vỡ ngân sách thì vẫn là thất bại của sản phẩm.
- Ghi lại quyết định tuyến. Lưu tuyến chính, tuyến cuối cùng, lý do lỗi, chi phí, độ trễ, và kết quả xác minh.
- Kiểm thử chèn lỗi. Mô phỏng hết thời gian chờ, giới hạn tốc độ, lỗi 5xx, đầu vào không hợp lệ, lỗi bộ phân tích, hình ảnh bị từ chối, bản ghi chép sai, và các tác vụ video chậm.
- Bắt đầu với một quy trình làm việc ít rủi ro. Đừng bật chuyển đổi dự phòng xuyên phương thức trên toàn bộ sản phẩm cùng một lúc.
- Rà soát tỷ lệ đầu ra được chấp nhận hàng tuần. Tối ưu cho kết quả có thể sử dụng, không chỉ cho các phản hồi HTTP thành công.
Đó là sự khác biệt giữa định tuyến dự phòng đáng tin cậy cho API LLM và việc thử lại mù quáng trên các tuyến không tương thích.
Câu hỏi thường gặp
Định tuyến dự phòng cho API LLM là gì?
Định tuyến dự phòng cho API LLM là chính sách quyết định khi nào một tuyến mô hình bị lỗi, suy giảm hoặc không khả dụng nên thử lại, chuyển sang một bản sao lưu đã được phê duyệt, dừng lại với một lỗi có thể hành động, hoặc chuyển sang xem xét của con người.
Tại sao định tuyến tác tử đa phương thức lại khó hơn định tuyến chỉ văn bản?
Định tuyến tác tử đa phương thức khó hơn vì đầu ra văn bản, hình ảnh, âm thanh và video có các phương pháp xác minh, đường cong chi phí, kỳ vọng độ trễ và rủi ro xem xét khác nhau. Một quy tắc dự phòng chung không thể an toàn bao trùm cả bốn.
Một cổng API có thể xử lý văn bản, hình ảnh, âm thanh và video không?
Có, một gateway có thể tập trung hóa việc truy cập và rà soát mức sử dụng trên các tuyến được hỗ trợ. Ứng dụng vẫn cần các lớp tuyến và chính sách dự phòng riêng cho từng phương thức và quy trình làm việc.
Khi nào nên tự động dự phòng?
Dự phòng tự động là an toàn nhất khi hợp đồng đầu ra có thể kiểm tra bằng máy, tuyến dự phòng đã được kiểm thử trước đó, chưa có đầu ra một phần nào đến tay người dùng, không có tác dụng phụ nào chưa chắc chắn, và tuyến dự phòng vẫn nằm trong giới hạn độ trễ và chi phí.
Khi nào nên giữ dự phòng ở chế độ thủ công?
Nên giữ dự phòng ở chế độ thủ công khi tạo phẩm cần được đánh giá chủ quan, yêu cầu có thể đã tạo ra tác dụng phụ, chi phí làm lại trùng lặp cao, hoặc đã xảy ra từ chối vì chính sách/an toàn. Tạo video và tạo hình ảnh nhạy cảm với thương hiệu thường thuộc nhóm này.
Thử lại có giống dự phòng không?
Không. Thử lại gửi cùng một yêu cầu đến cùng một tuyến thêm một lần nữa. Dự phòng thì thay đổi tuyến. Tạo lại sinh ra một tạo phẩm mới. Hãy xem đó là các hành động chính sách riêng biệt vì chúng có hàm ý khác nhau về chi phí và chất lượng.
Các nhóm nên đo lường chất lượng dự phòng như thế nào?
Đo tỷ lệ thành công, tỷ lệ dự phòng, độ trễ, chi phí gia tăng, lỗi bộ phân tích, mức chấp nhận của người đánh giá, tỷ lệ đầu ra bị từ chối, và tỷ lệ đầu ra được chấp nhận sau khi dự phòng. HTTP 200 chỉ là điểm bắt đầu của việc đo lường.
Xây dựng chính sách định tuyến trước lần thay đổi mô hình tiếp theo
Lý do mạnh mẽ nhất để chuẩn hóa định tuyến dự phòng cho API LLM là việc truy cập mô hình thay đổi nhanh hơn kiến trúc ứng dụng. Các tuyến mới cho văn bản, hình ảnh, âm thanh và video sẽ tiếp tục ra mắt. Một số sẽ biến mất, chậm đi, đổi giá, hoặc hoạt động khác đi dưới tải.
Nếu sản phẩm của bạn có các lớp tuyến, quy tắc xác minh, trần chi phí, và các quyết định dự phòng có thể quan sát được, thì việc thêm hoặc bớt một mô hình chỉ là một cập nhật chính sách có kiểm soát. Nếu logic định tuyến của bạn bị ẩn trong mã tính năng, mọi thay đổi mô hình đều trở thành rủi ro di chuyển.
Bắt đầu với một quy trình làm việc được khoanh vùng, xác định phương thức và lớp xác minh của nó, kiểm thử các tuyến dự phòng đã được phê duyệt, rồi mở rộng tiếp. Khi bạn sẵn sàng tập trung hóa truy cập và thanh toán trên các tuyến được hỗ trợ, hãy dùng Flatkey API quickstart, xem quy trình làm việc API AI hợp nhất, và so sánh tình trạng sẵn có hiện tại của mô hình trên Flatkey model directory.
