Danh sách kiểm tra dự phòng mô hình bắt đầu trước khi bộ định tuyến chuyển lưu lượng. Một mô hình dự phòng có thể cứu một yêu cầu khi tuyến chính thất bại, nhưng nó cũng có thể thay đổi chất lượng câu trả lời, chi phí token, hành vi công cụ, ngữ nghĩa streaming, xử lý dữ liệu và khả năng hiển thị sự cố. Hãy coi fallback là một chính sách sản xuất đã được đánh giá, không phải một công tắc rộng kiểu "thử mô hình khác".
Hướng dẫn này cung cấp cho các đội AI sản xuất một danh sách kiểm tra dự phòng mô hình thực tế cho các cổng LLM, bộ định tuyến tương thích OpenAI và các đường dẫn API AI đa nhà cung cấp. Nó tập trung vào những câu hỏi cần được trả lời trước khi fallback chạm vào lưu lượng khách hàng: mô hình dự phòng có đủ tốt không, đủ rẻ không, có tương thích công cụ không, có đủ khả năng quan sát không, và có được phép trong cùng ranh giới dữ liệu không?
Flatkey liên quan ở chỗ nội dung sản phẩm công khai của họ định vị flatkey.ai xoay quanh một khóa API, một URL gốc tương thích OpenAI tại https://router.flatkey.ai/v1, giá cả rõ ràng, thanh toán hợp nhất, phân tích mức sử dụng, điều khiển trên dashboard, tự động chuyển đổi, cân bằng tải và giới hạn hạn mức. Những tính năng đó giúp việc định tuyến dễ tập trung hơn. Chúng không loại bỏ nhu cầu về một danh sách kiểm tra dự phòng mô hình rõ ràng mà kỹ thuật, sản phẩm, tài chính và bảo mật có thể xem xét.
Danh sách kiểm tra dự phòng mô hình: Câu trả lời nhanh
Hãy dùng danh sách kiểm tra dự phòng mô hình này như một cổng quyết định go/no-go trước khi bật dự phòng mô hình LLM trong môi trường sản xuất. Mỗi hàng nên có một người chịu trách nhiệm, một điều kiện đạt, và một điều kiện dừng.
| Cổng | Câu hỏi đạt | Điều kiện dừng | Minh chứng cần lưu giữ |
|---|---|---|---|
| Chất lượng | Dự phòng có đáp ứng các đánh giá theo tác vụ giống như tuyến chính không? | Chặn dự phòng nếu nó thay đổi các dữ kiện bắt buộc, định dạng, tư thế an toàn, hoặc giọng điệu mà khách hàng nhìn thấy vượt quá ngân sách hồi quy đã chấp nhận. | Bộ eval, tỷ lệ đạt, ví dụ lỗi, ghi chú của người đánh giá, phạm vi dự phòng đã được phê duyệt. |
| Chi phí và hạn ngạch | Dự phòng có thể chạy trong cùng ngân sách, giới hạn token, pool hạn ngạch, và các giả định đơn vị giá không? | Chặn dự phòng nếu nó tiêu dùng ngân sách của nhóm khác, tài khoản khác, phương thức khác, hoặc nhà cung cấp khác mà không có phê duyệt. | Ảnh chụp giá, ước tính mức sử dụng, người chịu chi phí, người chịu hạn ngạch, số lần thử tối đa. |
| Công cụ và schema | Dự phòng có thể xử lý cùng các lệnh gọi hàm, đầu ra có cấu trúc, tác dụng phụ của công cụ, và định dạng phản hồi không? | Chặn dự phòng nếu các lệnh gọi công cụ bắt buộc, lược đồ JSON, sự kiện streaming, hoặc các trường đầu ra không được hỗ trợ hay không nhất quán. | Kiểm thử hợp đồng công cụ, xác thực schema, kiểm tra lệnh gọi công cụ bắt buộc/song song, ghi chú an toàn khi phát lại. |
| Streaming và ranh giới retry | Chỉ cho phép dự phòng trước khi có đầu ra mà người dùng nhìn thấy, hay UI được thiết kế để khởi động lại sau khi đã có một phần đầu ra? | Chặn việc chuyển sang dự phòng âm thầm sau khi đã có đầu ra một phần, thực thi công cụ, hoặc bất kỳ tác dụng phụ không idempotent nào. | Dòng thời gian của lần thử, dấu thời gian đầu ra đầu tiên, cờ đầu ra một phần, lý do retry/dự phòng. |
| Tuân thủ và ranh giới dữ liệu | Dự phòng có được phê duyệt cho cùng lớp dữ liệu, khu vực, tài khoản nhà cung cấp, chính sách lưu giữ, và chế độ ghi log không? | Chặn dự phòng khi có vấn đề về an toàn, quyền riêng tư, DLP, xác thực, IP allowlist, khu vực không được hỗ trợ, hoặc nhà cung cấp/tài khoản chưa được phê duyệt. | Thẻ lớp dữ liệu, danh sách nhà cung cấp đã phê duyệt, chế độ ghi log, quyết định chính sách, phê duyệt của người đánh giá. |
| Khả năng quan sát | Người vận hành có thể tái dựng model được yêu cầu, model được chọn, nhà cung cấp, các lần thử, lỗi, chi phí, và kết quả cuối cùng không? | Chặn dự phòng nếu thành công cuối cùng sẽ che khuất các lần thử của tuyến thất bại hoặc tác động đến ngân sách. | ID yêu cầu, ID chính sách định tuyến, chuỗi lần thử model, lỗi nhà cung cấp, mức sử dụng, chi phí, liên kết dashboard. |
Tại sao Fallback không giống Retry
Một retry gửi cùng một yêu cầu đi qua cùng một tuyến logic sau một lỗi tạm thời. Một fallback thay đổi mô hình, nhà cung cấp, tài khoản, endpoint family hoặc surface hành vi. Đó là lý do một AI gateway fallback cần quy trình phê duyệt chặt chẽ hơn so với một network retry tiêu chuẩn.
Hướng dẫn mã lỗi hiện tại của OpenAI tách các lỗi xác thực, giới hạn tần suất, hết hạn mức quota, lỗi máy chủ, quá tải và việc làm chậm đột ngột tốc độ yêu cầu. Chỉ một số trong các nhóm đó là ứng viên cho retry hoặc fallback. Một lỗi 500 hoặc quá tải tạm thời có thể biện minh cho một retry có giới hạn. Một lỗi 401, khu vực không được hỗ trợ, chặn an toàn, yêu cầu định dạng sai hoặc ngân sách tháng đã cạn thường nên thất bại kín cho đến khi chủ sở hữu sửa vấn đề gốc.
Tài liệu công khai của Vercel AI Gateway mô tả các fallback mô hình theo thứ tự và metadata về lượt thử của provider như một mẫu gateway: gateway có thể thử các mô hình dự phòng khi mô hình chính thất bại hoặc không khả dụng, và metadata có thể cho thấy những lượt thử mô hình/provider nào đã được thực hiện. Hãy dùng điều đó làm bằng chứng về mẫu, không phải là một khẳng định về hành vi của Flatkey. Trong hệ thống của riêng bạn, model fallback checklist nên xác định những lỗi nào được phép chuyển sang tuyến tiếp theo và những lỗi nào phải dừng lại.
Định nghĩa các tầng dự phòng trước khi có lưu lượng
Không phải mọi phương án dự phòng đều có cùng mức rủi ro. Chuyển sang nhà cung cấp cùng mô hình có thể giữ hành vi tốt hơn so với dùng một họ mô hình khác, trong khi một mô hình nhỏ rẻ hơn có thể chấp nhận được cho phân loại nhưng không phù hợp cho trả lời hỗ trợ khách hàng. Hãy xếp mỗi tuyến vào một tầng trước khi bật chuyển đổi tự động.
| Tầng dự phòng | Cách sử dụng điển hình | Rủi ro chính | Quy tắc phê duyệt |
|---|---|---|---|
| Cùng mô hình, nhà cung cấp hoặc tài khoản khác | Sự cố nhà cung cấp, sự cố ở cấp tài khoản, sự cố năng lực theo khu vực. | Các tham số, giá cả, giới hạn tốc độ và ghi log đặc thù của nhà cung cấp có thể khác nhau. | Phê duyệt sau khi kiểm tra tính tương đương của endpoint, tham số, hạn ngạch, chi phí và trường log. |
| Cùng họ, mô hình nhỏ hơn hoặc nhanh hơn | Các tác vụ nhạy cảm về độ trễ, tóm tắt nhẹ, trích xuất đơn giản. | Suy giảm chất lượng và khả năng bám theo hướng dẫn. | Chỉ phê duyệt cho các quy trình vượt qua đánh giá với mô hình nhỏ hơn. |
| Khác họ mô hình | Sự cố nhà cung cấp hoặc khôi phục theo tính năng cụ thể. | Phong cách đầu ra, hành vi an toàn, gọi công cụ, độ sâu suy luận và mức sử dụng token có thể thay đổi. | Yêu cầu phê duyệt từ sản phẩm, kỹ thuật và chính sách cho từng quy trình. |
| Xếp hàng thay vì dự phòng | Các job batch, bổ sung không khẩn cấp, backfill, tạo báo cáo. | Kết quả cho người dùng bị trì hoãn, backlog ẩn, dữ liệu lỗi thời. | Phê duyệt khi trải nghiệm người dùng có thể chấp nhận độ trễ và job vẫn giữ metadata sở hữu. |
| Fail closed | Xác thực, quyền, an toàn, ranh giới dữ liệu, hết ngân sách, yêu cầu sai định dạng. | Lỗi ngắn hạn sẽ hiển thị với người dùng hoặc người vận hành. | Mặc định cho các trường hợp chính sách, bảo mật, tuân thủ và ngân sách chưa được phê duyệt. |
Cổng chất lượng: Đánh giá tác vụ, không phải tên model
Hàng chất lượng trong một checklist fallback của model nên sử dụng các bài đánh giá (eval) theo từng workflow cụ thể. Một fallback có thể phù hợp cho việc tạo tiêu đề nhưng lại sai cho rà soát hợp đồng. Nó có thể phù hợp cho một nhãn phân loại nhưng rủi ro đối với workflow hỗ trợ có dùng công cụ. Chính sách nên kiểm tra đúng dạng tác vụ sẽ thực sự chạy trong production.
Xây dựng một bộ eval fallback nhỏ nhưng đại diện:
- Ví dụ vàng: các đầu ra thành công của luồng chính cho các trường hợp bình thường, các case biên và khách hàng giá trị cao.
- Ví dụ lỗi: các prompt trước đây đã gây ra ảo giác, từ chối, trôi schema, dùng sai công cụ hoặc phản hồi quá dài.
- Kiểm tra hồi quy: thông tin bắt buộc, tuyên bố bị cấm, schema đầu ra, giọng điệu, quy tắc trích dẫn và tư thế an toàn.
- Rà soát của con người: ghi chú của người đánh giá cho những ví dụ mà các kiểm tra tự động không thể quyết định chất lượng.
- Phạm vi fallback: workflow, môi trường, tầng khách hàng, danh sách model và số lần thử tối đa chính xác mà fallback được phê duyệt.
Các ví dụ eval của OpenAI mô tả những grader có thể kiểm tra các trường hẹp, đối chiếu với ground truth, hoặc đánh giá đầu ra một cách toàn diện hơn. Hãy dùng mẫu đó cho việc phê duyệt fallback: mỗi ứng viên fallback nên có tiêu chí đạt/không đạt cụ thể, không phải một đánh giá mơ hồ kiểu “trông ổn”.
Cost Gate: Định giá đường dự phòng, không chỉ đường chính
Dự phòng có thể biến một sự cố độ tin cậy thành một sự cố chi phí nếu nó âm thầm chuyển lưu lượng sang một mô hình đắt hơn, cửa sổ ngữ cảnh lớn hơn, phương thức khác, tầng nhà cung cấp cao cấp, hoặc một nhóm hạn mức riêng. Phần chi phí của model fallback checklist này nên trả lời bốn câu hỏi trước khi triển khai:
- Đơn vị chi phí là gì? Token văn bản, input được cache, token suy luận, đầu ra hình ảnh, giây video, hoặc một đơn vị riêng của nhà cung cấp có thể làm thay đổi cấu trúc ngân sách.
- Chi phí tối đa cho mỗi yêu cầu là bao nhiêu? Đặt giới hạn cho input, output, ngữ cảnh, suy luận, và số lần thử cho đường dự phòng.
- Ngân sách của ai được sử dụng? Đừng chuyển lưu lượng production sang đội khác, khách hàng khác, tài khoản BYOK khác, hoặc số dư của nhà cung cấp khác mà chưa được phê duyệt.
- Tài chính sẽ nhìn thấy điều này như thế nào? Log nên phân biệt mô hình được yêu cầu, mô hình được chọn, nhà cung cấp, lý do định tuyến, mức sử dụng token, và chi phí.
Tài liệu AI Gateway của Cloudflare là bằng chứng mẫu hữu ích ở đây: trang logging của nó liệt kê metadata của yêu cầu như nhà cung cấp, trạng thái, mức sử dụng token, chi phí, và thời lượng; metadata tùy chỉnh có thể gắn thẻ yêu cầu bằng đội hoặc mã test; và các header chi phí tùy chỉnh có thể ghi đè giả định chi phí công khai của mô hình cho việc hạch toán ở mức yêu cầu. Người dùng Flatkey nên làm cho cùng loại bằng chứng này hiển thị thông qua dashboard Flatkey, usage logs, và rà soát billing trước khi dựa vào fallback tự động.
Cổng Công Cụ Và Schema: Chứng Minh Khả Năng Tương Thích Trước Khi Chuyển Đổi
Những quy trình làm việc nặng về công cụ cần một danh sách kiểm tra fallback của mô hình chặt chẽ hơn so với chỉ tạo văn bản thuần túy. Hướng dẫn gọi hàm của OpenAI định nghĩa các công cụ là chức năng bạn cung cấp cho mô hình, và mô tả luồng nhiều bước: gửi các công cụ khả dụng, nhận một lệnh gọi công cụ, thực thi mã ở phía ứng dụng, gửi đầu ra của công cụ trở lại, rồi nhận phản hồi cuối cùng. Điều đó có nghĩa là mô hình fallback phải được kiểm thử trên toàn bộ vòng lặp công cụ, chứ không chỉ câu trả lời đầu tiên.
Chạy kiểm thử tương thích công cụ cho:
- Lựa chọn công cụ: fallback có gọi đúng công cụ khi mô hình chính cũng làm vậy không?
- Đối số: các trường bắt buộc, enum, ID và đối tượng JSON lồng nhau có hợp lệ không?
- Tác động phụ: công cụ có tính idempotent không, hay một fallback có thể lặp lại việc hoàn tiền, gửi email, cập nhật ticket hoặc ghi vào cơ sở dữ liệu?
- Công cụ song song: nếu tuyến chính dùng các lệnh gọi công cụ song song, fallback có hỗ trợ hành vi tương tự hay cần tuần tự hóa?
- Đầu ra có cấu trúc: fallback có đáp ứng schema mà mã phía sau mong đợi không?
- Từ chối và kết quả theo chính sách: ứng dụng có thể phát hiện khi fallback từ chối hoặc chặn một yêu cầu không an toàn không?
Tài liệu về Structured Outputs của OpenAI nêu rằng Structured Outputs được thiết kế để làm cho phản hồi của mô hình tuân thủ một JSON Schema được cung cấp, và phân biệt gọi hàm với các schema của định dạng phản hồi. Tài liệu cũng lưu ý rằng structured outputs vẫn có thể chứa sai sót và nên được xử lý bằng hướng dẫn, ví dụ hoặc các tác vụ con đơn giản hơn khi cần. Với chính sách fallback, điều đó có nghĩa là xác thực schema là cần thiết nhưng chưa đủ: hãy xác thực cả nội dung lẫn tác động phụ.
Cổng phát luồng: Không ẩn đầu ra một phần
Phát luồng bổ sung một ranh giới riêng cho danh sách kiểm tra dự phòng mô hình. Trước token hiển thị đầu tiên, việc dự phòng có thể là một lựa chọn tuyến đường sạch sẽ. Sau khi người dùng đã thấy đầu ra một phần, việc chuyển tuyến âm thầm có thể ghép hai câu trả lời từ các mô hình khác nhau và che giấu sự cố.
Sử dụng quy tắc mặc định này:
- Trước đầu ra đầu tiên: có thể cho phép dự phòng nếu lỗi chỉ là tạm thời và tuyến dự phòng đã được phê duyệt trước.
- Sau đầu ra đầu tiên: đánh dấu câu trả lời là chưa hoàn chỉnh và yêu cầu người dùng khởi động lại hoặc thử lại một cách rõ ràng.
- Sau một tác động phụ từ công cụ: thất bại đóng hoặc sử dụng một đường phục hồi có tính idempotent. Không phát lại một cách mù quáng.
- Sau khi bị chặn vì an toàn hoặc tuân thủ: thất bại đóng. Không chuyển sang một mô hình ít bị ràng buộc hơn để lấy câu trả lời.
Điều này đi cùng với các playbook chiến lược thử lại AI API và cân bằng tải và chuyển đổi dự phòng AI API. Quyết định thử lại, dự phòng, xếp hàng và thất bại đóng nên dùng chung một phân loại lỗi để thành công cuối cùng không xóa đi đường đi của tuyến.
Cổng tuân thủ: Giữ nguyên cùng một ranh giới dữ liệu
Một tuyến dự phòng có thể vượt qua các ranh giới mà trong một đường đi mã nguồn đơn giản là không nhìn thấy được. Nó có thể sử dụng một nhà cung cấp, tài khoản, khu vực, chế độ ghi log, chủ sở hữu thông tin xác thực, thiết lập lưu giữ hoặc chính sách kiểm duyệt khác. Hàng tuân thủ trong danh sách kiểm tra dự phòng mô hình nên đủ rõ ràng để người đánh giá có thể nói có hoặc không trước khi lưu lượng di chuyển.
| Ranh giới | Câu hỏi cần hỏi | Quan điểm mặc định |
|---|---|---|
| Loại dữ liệu | Tuyến dự phòng này có được phép cho nội dung khách hàng, tài liệu nội bộ, dữ liệu được quản lý, bí mật hoặc tải trọng giống PII không? | Chặn mặc định trừ khi loại dữ liệu được phê duyệt cho tuyến dự phòng. |
| Nhà cung cấp và tài khoản | Tuyến này có sử dụng cùng tài khoản nhà cung cấp, tài khoản BYOK hay danh sách nhà cung cấp được phê duyệt không? | Yêu cầu phê duyệt của chủ sở hữu tài khoản trước khi tràn sang tài khoản khác. |
| Chế độ ghi log | Prompt và đầu ra có được lưu trữ hay tuyến chỉ lưu siêu dữ liệu? | Sử dụng chỉ siêu dữ liệu khi việc lưu giữ tải trọng nhạy cảm chưa được phê duyệt. |
| Khu vực hoặc chính sách truy cập | Fallback có thể vi phạm danh sách cho phép IP, quy tắc khu vực không được hỗ trợ hoặc quy tắc vị trí dữ liệu của khách hàng không? | Chặn mặc định và cảnh báo chủ sở hữu. |
| An toàn và chính sách | Tuyến chính bị chặn bởi an toàn, kiểm duyệt, DLP hoặc ủy quyền công cụ hay không? | Không bỏ qua chặn chính sách bằng fallback. |
Tài liệu ghi log của Cloudflare cung cấp một ví dụ công khai cụ thể về lý do điều này quan trọng: log yêu cầu có thể bao gồm prompt và phản hồi, trong khi một header theo từng yêu cầu có thể bỏ lưu trữ tải trọng và chỉ giữ siêu dữ liệu. Chính sách fallback của Flatkey của bạn cũng nên quyết định tương tự khi nào nội dung thô có thể được lưu và khi nào bằng chứng tuyến đường chỉ nên là siêu dữ liệu.
Các trường quan sát cho việc xem xét fallback
Nếu log chỉ nói “request succeeded,” thì model fallback checklist đã thất bại. Người vận hành cần thấy chuỗi các lần thử dẫn đến thành công hoặc thất bại.
| Field | Why It Matters |
|---|---|
| Route policy ID and version | Hiển thị chính sách đã được phê duyệt nào cho phép hoặc chặn fallback. |
| Requested model and selected model | Tách biệt ý định của người dùng với quyết định của router. |
| Provider, account, endpoint family, and region if applicable | Hiển thị liệu yêu cầu có vượt qua ranh giới vận hành hay tuân thủ hay không. |
| Error class and status code per attempt | Phân biệt lỗi tạm thời của nhà cung cấp với các vấn đề về xác thực, hạn ngạch, hình dạng request hoặc chính sách. |
| Tool-call IDs, schema validation result, and side-effect status | Ngăn việc thực thi công cụ trùng lặp và trôi lệch schema ẩn. |
| Usage, cost, cache, and quota owner | Kết nối khả năng khôi phục độ tin cậy với chi tiêu và xem xét ngân sách. |
| Partial-output flag and first-output timestamp | Chứng minh fallback xảy ra trước hay sau đầu ra mà người dùng nhìn thấy. |
| Final disposition | Một trong các trạng thái: primary success, fallback success, queued, user retry required, fail closed. |
Bài viết AI API observability logs đi sâu hơn về các trường sự cố. Với fallback, hãy ưu tiên chuỗi lần thử route và nguyên nhân dừng.
Kế hoạch triển khai Staging cho Flatkey
Sử dụng kế hoạch triển khai này khi kiểm thử AI gateway fallback thông qua Flatkey hoặc bất kỳ router tương thích OpenAI nào. Nó giữ model fallback checklist gắn với bằng chứng thay vì giả định.
- Tạo một staging key: giữ các bài kiểm thử fallback tách khỏi lưu lượng khách hàng production.
- Xác nhận route cơ sở: trỏ một client tương thích OpenAI tới
https://router.flatkey.ai/v1và xác minh model chính, họ endpoint, hàng usage và khả năng hiển thị trên dashboard. - Ghi lại các thông tin catalog hiện tại: vào ngày 18 tháng 6 năm 2026, Flatkey pricing API trả về 638 dòng model, 23 nhà cung cấp, và các họ endpoint bao gồm OpenAI chat completions, OpenAI Responses, Anthropic messages, Gemini generateContent, image generation, và video generation. Hãy xem đó là bằng chứng theo thời điểm, không phải một cam kết vĩnh viễn.
- Chọn một tier fallback: bắt đầu với fallback rủi ro thấp nhất phù hợp với workflow, chẳng hạn như route cùng model hoặc một model chi phí thấp hơn được xác định rõ phạm vi cho một tác vụ hẹp.
- Chạy eval trước khi có traffic: kiểm thử các ví dụ chuẩn, các trường hợp biên, xác thực schema, lời gọi tool, ranh giới streaming, và các chặn theo policy.
- Chạy kiểm thử lỗi cưỡng bức: mô phỏng timeout của primary, rate limit, lỗi provider, request sai định dạng, lỗi auth, cạn quota, chặn policy, và lỗi stream sau khi xuất output.
- Rà soát logs và billing: xác nhận model được yêu cầu, model được chọn, lý do fallback, lượt thử provider, usage, cost, key, team, và environment đều hiển thị.
- Đặt quy tắc rollback: vô hiệu hóa fallback tự động hoặc thủ công nếu chất lượng, chi phí, policy, hoặc các cổng quan sát thất bại.
Kết hợp điều này với kiến trúc LLM API gateway, checklist cổng API AI doanh nghiệp, và giá Flatkey khi bạn chuyển từ staging sang production.
Mẫu Chính sách Fallback
Mẫu này không phải là một hợp đồng API của Flatkey. Đây là một tài liệu xem xét mà nhóm của bạn có thể điều chỉnh trước khi bật fallback.
{
"policy_id": "support-chat-fallback-v1",
"workflow": "customer-support-chat",
"environment": "production",
"primary_route": {
"model": "primary-approved-model",
"endpoint_family": "openai-chat-completions"
},
"fallback_routes": [
{
"model": "approved-backup-model",
"allowed_reasons": ["primary_timeout", "temporary_5xx", "provider_unavailable"],
"blocked_reasons": ["auth_error", "invalid_request", "quota_exhausted", "safety_block", "unapproved_data_class"],
"requires_eval_pass": true,
"requires_cost_owner": true,
"requires_tool_contract_pass": true,
"allow_after_partial_output": false
}
],
"limits": {
"max_total_attempts": 2,
"max_elapsed_ms": 12000,
"max_input_tokens": 8000,
"max_output_tokens": 1200,
"max_estimated_cost_usd": 0.05
},
"logging": {
"record_attempt_chain": true,
"record_requested_and_selected_model": true,
"record_error_class_per_attempt": true,
"record_usage_and_cost": true,
"payload_logging_mode": "metadata_only"
},
"rollback": {
"disable_on_schema_failures": true,
"disable_on_unapproved_cost_spike": true,
"disable_on_policy_boundary_error": true
}
}Câu hỏi thường gặp
Checklist dự phòng mô hình là gì?
Checklist dự phòng mô hình là danh sách rà soát trước khi triển khai để quyết định liệu một mô hình hoặc nhà cung cấp dự phòng có thể xử lý lưu lượng một cách an toàn khi tuyến chính gặp sự cố hay không. Nó nên bao gồm chất lượng, chi phí, hạn mức, công cụ, hành vi streaming, ranh giới tuân thủ, khả năng quan sát và các quy tắc khôi phục.
Khi nào tôi nên dùng dự phòng mô hình LLM thay vì thử lại?
Hãy dùng dự phòng mô hình LLM khi tuyến chính gặp lỗi tạm thời từ phía nhà cung cấp hoặc không khả dụng, và tuyến dự phòng đã được phê duyệt cho cùng một luồng công việc. Không dùng cơ chế dự phòng cho các yêu cầu sai định dạng, lỗi xác thực, chặn an toàn, hết ngân sách hoặc các lớp dữ liệu chưa được phê duyệt.
Cổng AI dự phòng nên xử lý các lệnh gọi công cụ như thế nào?
Một cổng AI dự phòng nên chứng minh khả năng tương thích với công cụ trước khi đưa vào sản xuất. Hãy kiểm tra việc chọn công cụ, đối số JSON, các trường bắt buộc, xác thực lược đồ, tác động phụ, tính idempotent, các lệnh gọi song song và định dạng phản hồi cuối cùng. Nếu một công cụ đã gây ra tác động phụ, đừng phát lại yêu cầu qua một mô hình khác trừ khi thao tác đó được xác định rõ là an toàn để lặp lại.
Bước đánh giá cuối cùng
Trước khi bật fallback, hãy tự hỏi một câu trực tiếp: chúng ta có thể giải thích vì sao tuyến này đã chuyển, điều gì đã thay đổi, nó tốn bao nhiêu, liệu nó có vượt qua ranh giới chính sách nào không, và cách để khôi phục nó là gì không? Nếu câu trả lời là không, thì model fallback checklist chưa hoàn chỉnh.
Flatkey có thể tập trung hóa việc truy cập mô hình, định tuyến, tính phí, khả năng hiển thị mức sử dụng và quản lý khóa sau một đường dẫn tương thích với OpenAI duy nhất. Hãy dùng điểm tập trung đó để làm cho các quyết định fallback có thể kiểm thử trước khi việc chuyển đổi tự động chạm tới lưu lượng sản xuất. Khi bạn sẵn sàng xác thực các tuyến trong môi trường staging, hãy lấy một khóa và bắt đầu với một chính sách fallback đã được phê duyệt.
