Chiến lược retry API AI là chính sách quyết định ứng dụng của bạn nên làm gì sau khi một yêu cầu tới mô hình bị lỗi, chậm lại, hoặc trả về kết quả một phần. Chính sách sai rất tốn kém: thử lại mọi lỗi thì bạn sẽ làm tăng áp lực hạn mức; chuyển mô hình quá sớm thì bạn sẽ thay đổi chất lượng câu trả lời; xếp hàng công việc tương tác thì người dùng phải chờ; mở lỗi đối với các thất bại về an toàn hoặc xác thực thì bạn sẽ che giấu một sự cố thực sự.
Hướng dẫn này là một thang quyết định thực tiễn dành cho các nhóm sản xuất sử dụng AI gateway, bộ định tuyến đa nhà cung cấp, hoặc base URL tương thích OpenAI. Nó bao gồm khi nào nên thử lại với cùng nhà cung cấp, khi nào nên chuyển mô hình, khi nào nên xếp hàng công việc, và khi nào nên fail closed. Mục tiêu của chiến lược retry API AI không phải là làm cho mọi yêu cầu thành công bằng mọi giá. Mục tiêu là khôi phục từ các lỗi tạm thời mà không che lấp các yêu cầu sai, vấn đề xác thực, cạn hạn mức, các phương án dự phòng không an toàn, hoặc sự cố định tuyến.
Flatkey phù hợp với vấn đề này vì nội dung sản phẩm công khai của họ tập trung vào một API key, một base URL tương thích OpenAI tại https://router.flatkey.ai/v1, giá cả rõ ràng, thanh toán hợp nhất, và một bảng điều khiển duy nhất cho khóa, mức sử dụng, và định tuyến. Flatkey cũng mô tả việc tự động chuyển đổi và cân bằng tải. Những tính năng đó vẫn cần một chính sách retry rõ ràng để các nhóm có thể giải thích vì sao một yêu cầu được thử lại, đổi mô hình, xếp hàng, hoặc fail closed.
Câu trả lời nhanh: Thang chiến lược retry AI API
Hãy dùng thang quyết định này như một tài sản giá trị cho chiến lược retry AI API của bạn. Nó giữ cho hành vi retry gắn với chủ sở hữu lỗi, luồng công việc của người dùng và bán kính tác động thay vì một quy tắc chung \"thử lại\".
| Tín hiệu lỗi | Hành động mặc định | Khi nào cần leo thang | Điều kiện dừng |
|---|---|---|---|
| Timeout mạng trước khi nhà cung cấp chấp nhận yêu cầu | Retry một lần với backoff có jitter nếu thao tác là idempotent hoặc dùng client request ID. | Chuyển tuyến sau khi hết ngân sách retry và đích dự phòng đã được phê duyệt cho cùng workflow. | Dừng sau khi hết ngân sách tuyến; trả về phản hồi retry-later có kiểm soát. |
| HTTP 429 giới hạn tần suất với hướng dẫn retry | Tôn trọng tín hiệu chờ trả về, làm chậm bên gọi và giảm độ đồng thời. | Xếp hàng tác vụ nền hoặc chuyển sang tuyến đã được phê duyệt với quota riêng. | Fail closed nếu quota đã cạn, ngân sách bị giới hạn hoặc không còn tuyến được phép. |
| HTTP 500, 502, 503, 504, hoặc nhà cung cấp quá tải | Retry một số lần nhỏ với exponential backoff và jitter. | Chỉ chuyển model hoặc nhà cung cấp sau khi xác nhận phương án dự phòng đáp ứng các quy tắc chất lượng và chính sách. | Dừng khi yêu cầu sẽ vượt quá giới hạn độ trễ, token, chi phí hoặc số lần thử. |
| Yêu cầu không hợp lệ 400, lỗi schema, tham số không được hỗ trợ, hoặc tràn ngữ cảnh | Không retry nếu không thay đổi. Sửa yêu cầu, thu gọn ngữ cảnh, hoặc trả về lỗi có thể do người dùng khắc phục. | Chuyển sang model có ngữ cảnh lớn hơn chỉ khi sản phẩm chấp nhận thay đổi về hành vi và chi phí. | Fail closed khi lỗi dạng yêu cầu lặp lại. |
| 401, 403, key bị vô hiệu hóa, IP không được ủy quyền, hoặc lỗi quyền truy cập | Fail closed và cảnh báo cho chủ sở hữu key. | Luân chuyển key hoặc sửa quyền truy cập tài khoản thông qua workflow của operator. | Không bao giờ âm thầm fallback sang tài khoản khác trừ khi chính sách bảo mật của bạn cho phép rõ ràng. |
| Chặn an toàn, chặn theo chính sách, lỗi ủy quyền công cụ, hoặc vấn đề ranh giới dữ liệu | Fail closed với thông báo an toàn và ghi log lý do chính sách. | Leo thang để xem xét nếu khối chặn có vẻ không chính xác hoặc ảnh hưởng khách hàng. | Không retry trên model ít bị hạn chế hơn chỉ để lấy một câu trả lời. |
| Streaming bắt đầu, rồi bị treo hoặc ngắt kết nối | Chỉ retry nếu thao tác có thể phát lại an toàn và trải nghiệm người dùng hỗ trợ một phản hồi mới. | Chuyển tuyến cho các yêu cầu tương lai sau khi log cho thấy lỗi ở mức stream lặp lại. | Không nối một câu trả lời model thứ hai vào một câu trả lời đã được gửi một phần, trừ khi UI được thiết kế cho điều đó. |
Tại sao một vòng lặp thử lại mù quáng làm hỏng sản phẩm AI
Hầu hết các dịch vụ web có thể dùng một mẫu thử lại tiêu chuẩn cho các lỗi tạm thời. Các API AI cần cẩn trọng hơn vì yêu cầu có thể tốn kém, có trạng thái, được truyền luồng, sử dụng công cụ và nhạy cảm với mô hình. Một vòng lặp LLM API retries mù quáng có thể tự tạo ra bốn lỗi của riêng nó:
- Khuếch đại hạn mức: thử lại các lỗi 429 quá mạnh tay có thể tiêu tốn chính chính dung lượng yêu cầu hoặc token vốn đã bị giới hạn.
- Trôi dạt chất lượng: một mô hình dự phòng có thể trả lời khác đi, bỏ qua một mẫu công cụ, hoặc thay đổi định dạng đầu ra.
- Bất ngờ về chi phí: một lần dự phòng thành công có thể đắt hơn tuyến chính, đặc biệt với ngữ cảnh dài, suy luận, hình ảnh hoặc video.
- Che giấu sự cố: lần thành công cuối cùng có thể che đi năm lần thất bại trừ khi nhật ký lưu giữ chuỗi thử lại.
Vì vậy, một AI API retry strategy tốt là một chính sách định tuyến, một chính sách quan sát, và một chính sách sản phẩm. Nó phải quy định cơ chế phục hồi nào được phép, bằng chứng nào phải được ghi lại, và trải nghiệm người dùng nào là chấp nhận được khi phục hồi thất bại.
Phân loại lỗi trước khi bạn thử lại
Bắt đầu mọi chiến lược thử lại API AI với một hệ thống phân loại lỗi đã chuẩn hóa. Tài liệu của các nhà cung cấp khác nhau, nhưng các nhóm vận hành đủ ổn định để chuyển thành chính sách:
| Nhóm | Ví dụ | Chủ sở hữu | Cách xử lý khi thử lại |
|---|---|---|---|
| Lỗi của bên gọi | JSON sai định dạng, tham số không hợp lệ, schema công cụ không được hỗ trợ, ngữ cảnh quá dài. | Ứng dụng hoặc pipeline prompt. | Không thử lại nếu không thay đổi. |
| Xác thực hoặc quyền truy cập | Key không hợp lệ, key bị vô hiệu hóa, tư cách thành viên dự án, danh sách cho phép IP, quyền tài khoản. | Chủ sở hữu thông tin xác thực hoặc chủ sở hữu bảo mật. | Thất bại an toàn và cảnh báo. |
| Giới hạn tốc độ | Số yêu cầu mỗi phút, số token mỗi phút, giới hạn tăng tốc, giới hạn đồng thời. | Chủ sở hữu lưu lượng và chủ sở hữu hạn ngạch. | Lùi lại, xếp hàng, giảm đồng thời, hoặc chuyển sang nhóm hạn ngạch đã được phê duyệt. |
| Hạn ngạch hoặc ngân sách đã cạn | Tín dụng đã dùng hết, trần chi tiêu hằng tháng, hạn ngạch nhóm, hạn ngạch khách hàng, giới hạn số dư trả trước. | Tài chính, chủ sở hữu gói, hoặc chủ sở hữu khách hàng. | Thất bại an toàn hoặc xếp hàng chờ phê duyệt; không tự động tiêu qua ngân sách khác một cách âm thầm. |
| Lỗi tạm thời từ nhà cung cấp | Lỗi máy chủ nội bộ, dịch vụ quá tải, lỗi cổng tạm thời, hết thời gian chờ. | Nhà cung cấp hoặc đường truyền mạng. | Thử lại với ngân sách nhỏ, sau đó chuyển sang phương án dự phòng nếu được phê duyệt. |
| Chặn do chính sách hoặc an toàn | Chặn do kiểm duyệt, đầu ra bị hạn chế, ranh giới dữ liệu, lỗi ủy quyền công cụ. | An toàn, bảo mật, hoặc chính sách sản phẩm. | Thất bại an toàn trừ khi có lộ trình khắc phục đã được con người phê duyệt. |
Hướng dẫn mã lỗi của OpenAI tách riêng lỗi giới hạn tốc độ 429 khỏi tình trạng cạn hạn ngạch, mô tả các trường hợp 500 và 503 là những tình huống cần chờ rồi thử lại, và coi các vấn đề xác thực là lỗi cần sửa key hoặc tổ chức thay vì là ứng viên để thử lại. Tài liệu lỗi của Anthropic cũng tách riêng các nhóm yêu cầu không hợp lệ, xác thực, quyền, giới hạn tốc độ, lỗi API và quá tải. Những khác biệt đó là lý do vì sao mã trạng thái thôi là chưa đủ; cổng tích hợp của bạn nên lưu loại lỗi từ nhà cung cấp và mã lỗi an toàn trong nhật ký.
Khi Nào Nên Thử Lại Cùng Một Mô Hình
Hãy thử lại cùng một mô hình khi lỗi có vẻ là tạm thời, yêu cầu có thể được phát lại một cách an toàn, và việc thử lại sẽ không làm sự cố tệ hơn. Đây là phần hẹp nhất nhưng hữu ích của một chiến lược thử lại API AI.
Các trường hợp phù hợp để thử lại trên cùng tuyến bao gồm:
- Timeout kết nối xảy ra trước khi nhà cung cấp chấp nhận yêu cầu.
- Phản hồi 500, 502, 503 hoặc 504 tạm thời.
- Phản hồi giới hạn tần suất với khoảng chờ ngắn và đủ ngân sách độ trễ còn lại của người dùng.
- Lỗi thiết lập streaming trước khi bất kỳ token nào hiển thị cho người dùng được gửi đi.
Hãy dùng exponential backoff có jitter thay vì ngủ đồng bộ. Hướng dẫn retry của Google Cloud mô tả truncated exponential backoff với jitter là dạng retry tiêu chuẩn vì nó tránh các đợt retry thundering herd. Với API AI, cũng nên thêm một ngân sách retry nhỏ theo từng workflow. Một yêu cầu chat tương tác có thể chỉ nên có một hoặc hai lần thử. Một batch tóm tắt chạy ban đêm có thể chờ lâu hơn và retry thận trọng hơn. Một workflow thanh toán, an toàn hoặc hành động của khách hàng nên chặt chẽ hơn.
Mỗi lần retry trên cùng tuyến nên ghi log chỉ số lần thử, tuyến, ID yêu cầu của nhà cung cấp khi có, mã trạng thái, loại lỗi, thời gian chờ và kết quả cuối cùng. Kết hợp điều này với checklist log khả năng quan sát API AI để thành công cuối cùng không làm mất dấu các lần thử thất bại.
Khi Nào Nên Chuyển Đổi Mô Hình Hoặc Nhà Cung Cấp
Một lần thử lại với mô hình dự phòng không chỉ là một lần thử lại khác. Nó thay đổi mô hình, nhà cung cấp, tài khoản, chi phí, hành vi, và đôi khi là ranh giới tuân thủ. Chỉ chuyển đổi khi phương án dự phòng đã được phê duyệt trước cho đúng quy trình làm việc đó.
Chỉ chuyển đổi mô hình hoặc nhà cung cấp khi tất cả các điều sau đều đúng:
- Tuyến chính đã dùng hết ngân sách thử lại ngắn của nó hoặc đã trả về lỗi từ phía nhà cung cấp.
- Mô hình dự phòng được phê duyệt cho cùng loại dữ liệu, cấp khách hàng, họ endpoint, hành vi công cụ, và định dạng đầu ra.
- Chủ sở hữu sản phẩm chấp nhận sự khác biệt về chất lượng và trải nghiệm người dùng.
- Chủ sở hữu tài chính chấp nhận sự khác biệt về chi phí và hạn ngạch.
- Nhật ký ghi nhận cả tuyến được yêu cầu và tuyến được chọn.
Không chuyển đổi khi yêu cầu bị lỗi định dạng, không được phép, bị chặn bởi chính sách an toàn, hoặc gắn với một tính năng đặc thù của nhà cung cấp mà phương án dự phòng không hỗ trợ. Tài liệu fallback mô hình của Vercel's AI Gateway mô tả các mô hình dự phòng theo thứ tự như một cách để phục hồi từ lỗi hoặc tình trạng không khả dụng. Hãy xem đó là một mẫu định tuyến công khai hữu ích, nhưng vẫn tự định nghĩa các bài kiểm thử chấp nhận của riêng bạn trước khi dùng fallback trong môi trường sản xuất.
Đối với người mua Flatkey, câu hỏi vận hành rất cụ thể: nếu một tuyến upstream gặp lỗi, những tuyến dự phòng nào được phép, có bao nhiêu lần thử được cho phép, và kỹ thuật có thể xem chuỗi tuyến ở đâu sau đó? Sách lược cân bằng tải và chuyển đổi dự phòng cho AI API là phần đi kèm để thiết kế thang tuyến đó.
Khi nào nên xếp hàng thay vì thử lại đồng bộ
Xếp hàng công việc khi người dùng không cần phản hồi ngay lập tức, khi năng lực của nhà cung cấp bị hạn chế tạm thời, hoặc khi khối lượng yêu cầu phù hợp với quy trình làm việc theo lô. Hàng đợi không phải là lỗi; đó là một cách để giữ cho AI API retry strategy không xung đột với các giới hạn đồng bộ.
Hướng dẫn về giới hạn tốc độ của OpenAI phân biệt các giới hạn yêu cầu đồng bộ với công việc theo lô và lưu ý rằng các trường hợp sử dụng không cần phản hồi ngay có thể dùng thực thi kiểu batch mà không ảnh hưởng đến giới hạn tốc độ yêu cầu đồng bộ. Nguyên tắc sản phẩm này cũng áp dụng ngoài một nhà cung cấp duy nhất: chuyển công việc không khẩn cấp ra khỏi lưu lượng tương tác.
Các ứng viên phù hợp để đưa vào hàng đợi bao gồm:
- Làm giàu dữ liệu hàng loạt, tóm tắt, tạo embedding, duyệt kiểm duyệt, hoặc tạo báo cáo.
- Các tác vụ mà khách hàng có thể nhìn thấy và vốn đã có trang trạng thái async hoặc webhook.
- Các tác vụ backfill và di chuyển, nơi độ mới được đo bằng phút hoặc giờ.
- Các cửa sổ retry-after vượt quá ngân sách độ trễ tương tác của người dùng nhưng vẫn phù hợp với hàng đợi công việc.
Bản ghi hàng đợi nên lưu giữ chủ sở hữu yêu cầu gốc, API key, chính sách tuyến, số lần thử lại, model được yêu cầu, thời điểm đưa vào hàng đợi, thời điểm thử tiếp theo và chủ sở hữu ngân sách. Nếu không, các lần thử lại trong hàng đợi sẽ trở thành chi phí vô hình.
Khi Nào Nên Fail Closed
Nên fail closed khi việc tiếp tục sẽ tạo ra sự mơ hồ về bảo mật, tuân thủ, dữ liệu, ngân sách hoặc rủi ro sản phẩm. Đây là phần của AI API retry strategy giúp ngăn kỹ thuật độ tin cậy trở thành hành vi bỏ qua chính sách một cách âm thầm.
Hãy fail closed đối với:
- API key không hợp lệ hoặc đã bị vô hiệu hóa, lỗi quyền dự án, lỗi allowlist IP và quyền sở hữu tài khoản không mong đợi.
- Chặn an toàn, chặn kiểm duyệt, lỗi quyền công cụ và lỗi ranh giới dữ liệu.
- Cạn hạn mức hoặc ngân sách khi chưa có chủ ngân sách nào phê duyệt phần vượt.
- Các yêu cầu bị lỗi định dạng sẽ lặp lại nguyên trạng.
- Các đường dự phòng chưa vượt qua kiểm tra chất lượng, chi phí, quyền riêng tư và tuân thủ.
- Các phản hồi streaming đã trả về một phần nội dung và không thể phát lại một cách sạch sẽ.
Fail closed không có nghĩa là trả về một lỗi thù địch. Nó có nghĩa là hệ thống trả về một thông điệp được kiểm soát, ghi lại lý do dừng, cảnh báo cho chủ sở hữu khi cần, và tránh một thay đổi tuyến đường bị ẩn. Điều này đặc biệt quan trọng đối với các tính năng AI hướng tới khách hàng, nơi một fallback âm thầm có thể tạo ra một câu trả lời khác biệt đáng kể.
Mẫu Chính Sách Retry Cho Các Đội Sản Xuất
Hãy dùng mẫu này để chuyển thang thành một bản ghi chính sách. Nó được cố ý thiết kế tổng quát và nên được điều chỉnh cho phù hợp với gateway, ứng dụng, và các quy tắc tuân thủ của bạn.
{
"policy_id": "chat-prod-retry-v3",
"workflow": "customer-chat",
"environment": "production",
"idempotency": {
"requires_client_request_id": true,
"allow_replay_after_stream_started": false
},
"same_route_retry": {
"retryable_status_codes": [408, 429, 500, 502, 503, 504],
"max_attempts": 2,
"backoff": "exponential_with_jitter",
"max_elapsed_ms": 9000
},
"fallback": {
"enabled": true,
"allowed_reasons": ["primary_timeout", "provider_overload", "temporary_5xx"],
"blocked_reasons": ["auth_error", "invalid_request", "safety_block", "budget_exhausted"],
"allowed_models": ["approved-backup-chat-model"],
"requires_quality_eval": true,
"requires_cost_owner": true
},
"queue": {
"enabled_for": ["bulk_summary", "nightly_enrichment"],
"not_enabled_for": ["live_customer_chat"]
},
"fail_closed": {
"auth_errors": true,
"policy_errors": true,
"unapproved_fallback": true,
"quota_without_budget_owner": true
},
"logging": {
"record_attempt_chain": true,
"record_retry_after": true,
"record_requested_and_selected_route": true,
"content_logging_mode": "metadata_only"
}
}Đây không phải là một hợp đồng API của Flatkey. Nó là một mẫu rà soát dành cho các đội kỹ thuật, sản phẩm, tài chính và an ninh. Trường quan trọng nhất không phải là tên JSON chính xác; mà là điều kiện dừng rõ ràng cho từng đường phục hồi.
Danh sách kiểm tra triển khai Flatkey
Sử dụng danh sách kiểm tra này khi thử nghiệm chiến lược thử lại API AI thông qua Flatkey hoặc bất kỳ cổng AI nào:
- Bắt đầu ở môi trường staging: trỏ một client tương thích với OpenAI tới
https://router.flatkey.ai/v1bằng khóa không phải sản xuất. - Chọn một luồng công việc: chọn một tuyến chat, tóm tắt, embedding, hình ảnh hoặc video thay vì thử tất cả mô hình cùng lúc.
- Đặt ngân sách thử lại: xác định số lần thử tối đa, thời gian tối đa đã trôi qua, và những lớp trạng thái hoặc lỗi nào có thể được thử lại.
- Xác định điều kiện đủ để chuyển sang phương án dự phòng: yêu cầu phê duyệt của sản phẩm cho chất lượng đầu ra, phê duyệt của tài chính cho chi phí, và phê duyệt của bảo mật cho loại dữ liệu.
- Tách lưu lượng hàng đợi: chuyển các công việc theo lô ra khỏi các yêu cầu tương tác của người dùng khi có thể.
- Thất bại kín với các vấn đề chính sách: không để các lỗi xác thực, an toàn, ngân sách hoặc hình dạng yêu cầu tự động chuyển sang tuyến khác một cách âm thầm.
- Xác minh nhật ký: xác nhận bảng điều khiển hoặc nhật ký đã xuất hiển thị tuyến được yêu cầu, tuyến được chọn, chuỗi lần thử, trạng thái, mức sử dụng, chi phí và chủ sở hữu.
- Rà soát chi tiêu: sử dụng các thực hành quản lý hạn mức API AI và phân bổ chi phí API AI theo nhóm để việc khôi phục sau thử lại không trở thành một bất ngờ về ngân sách.
Trang giá Flatkey trực tiếp đã công bố giá mô hình được render phía máy chủ cho 638 mô hình AI trên 23 nhà cung cấp khi được kiểm tra vào ngày 18 tháng 6 năm 2026. Hãy xem đó chỉ là bằng chứng danh mục có thời điểm. Trước khi có lưu lượng sản xuất, hãy xác minh chính xác các dòng mô hình, loại endpoint, đơn vị định giá, trạng thái khả dụng và các trường bảng điều khiển cho luồng công việc của bạn.
Các Sai Lầm Thường Gặp Cần Tránh
- Xử lý mọi lỗi 429 theo cùng một cách: áp lực lưu lượng, giới hạn tăng tốc và cạn kiệt ngân sách cần những hành động khác nhau.
- Thử lại các yêu cầu không hợp lệ: lỗi về schema, ngữ cảnh và tham số không được hỗ trợ cần thay đổi yêu cầu, không phải thêm lần thử.
- Dùng phương án dự phòng mà không đánh giá: một mô hình rẻ hơn hoặc sẵn có không tự động phù hợp cho cùng một quy trình làm việc của khách hàng.
- Bỏ qua trạng thái streaming: thử lại sau khi đã có đầu ra một phần có thể tạo ra các câu trả lời trùng lặp hoặc mâu thuẫn.
- Bỏ qua nhật ký các lần thử: việc xem xét sự cố cần toàn bộ chuỗi tuyến đường, không chỉ lần thành công cuối cùng.
- Để việc thử lại vượt qua ngân sách: mỗi lần thử lại là một yêu cầu khác, một số lượng token khác, và thường là một dòng chi phí khác.
Câu hỏi thường gặp
Chiến lược thử lại của API AI nên thử lại một yêu cầu thất bại bao nhiêu lần?
Đối với lưu lượng tương tác, hãy bắt đầu với một hoặc hai lần thử và một ngân sách thời gian trôi qua nghiêm ngặt. Các tác vụ nền có thể dùng thời gian chờ tăng dần dài hơn và nhiều lần thử hơn. Con số phù hợp phụ thuộc vào tính idempotent, độ trễ đối với người dùng, hướng dẫn của nhà cung cấp, hạn mức, chi phí và việc phương án dự phòng có được chấp thuận hay không.
Các lần thử lại của API LLM nên dùng cùng mô hình hay mô hình dự phòng?
Hãy thử lại cùng mô hình đối với các lỗi có khả năng chỉ là tạm thời. Chỉ dùng mô hình dự phòng sau khi đã hết ngân sách thử lại theo cùng tuyến và mô hình dự phòng đã vượt qua các kiểm tra về chất lượng, chi phí, công cụ, quyền riêng tư và tuân thủ.
Khi nào việc thử lại bằng mô hình dự phòng nên bị chặn?
Hãy chặn phương án dự phòng đối với lỗi xác thực, lỗi quyền, yêu cầu không hợp lệ, các chặn về an toàn hoặc chính sách, cạn ngân sách mà chưa được phê duyệt, và bất kỳ quy trình nào mà một mô hình khác có thể làm thay đổi hành vi hiển thị cho người dùng vượt quá mức chấp nhận của sản phẩm.
Cần ghi log những gì cho các sự cố thử lại và dự phòng?
Ghi log ID yêu cầu gốc, chỉ số lần thử, tuyến được yêu cầu, tuyến đã chọn, ID yêu cầu của nhà cung cấp khi có, mã trạng thái, loại lỗi, dữ liệu retry-after, độ trễ, mức sử dụng token, chi phí, lý do quyết định dự phòng và kết quả cuối cùng. Ghi log ưu tiên metadata thường là mặc định phù hợp nhất.
Kết luận: Làm rõ cơ chế khôi phục
Chiến lược thử lại API AI là một cơ chế kiểm soát trong môi trường sản xuất, không phải là một hàm hỗ trợ. Hãy thử lại các lỗi tạm thời với một ngân sách nhỏ. Chỉ chuyển đổi mô hình khi phương án dự phòng đã được phê duyệt. Đưa vào hàng đợi những công việc không cần câu trả lời đồng bộ. Đóng kín khi vấn đề thực sự là bảo mật, an toàn, ngân sách hoặc định dạng yêu cầu.
Nếu nhóm của bạn muốn một khóa, một URL cơ sở tương thích, và một nơi rõ ràng hơn để xem xét định tuyến mô hình, giá cả, mức sử dụng và hành vi khôi phục, hãy lấy một khóa Flatkey và kiểm tra thang bậc thử lại của bạn trong môi trường staging trước khi có lưu lượng sản xuất.
