Một circuit breaker của cổng API LLM ngăn ứng dụng liên tục gửi lưu lượng vào một tuyến đường vốn đã đang lỗi. Nếu không có lớp bảo vệ đó, một timeout có thể kích hoạt retry, retry có thể kích hoạt các lần thử fallback, các lần thử fallback có thể kích hoạt thêm lỗi từ nhà cung cấp, và ứng dụng có thể biến một sự cố upstream thành một vòng lặp lỗi của nhà cung cấp.
Mục tiêu không phải là thay thế retry hoặc fallback mô hình. Mục tiêu là quyết định khi nào một tuyến đường đã không khỏe đến mức cổng nên ngừng thử trong một khoảng thời gian ngắn, gửi một probe có kiểm soát sau đó, và chọn một kết quả an toàn hơn trong lúc breaker đang mở: fallback, đưa vào hàng đợi, giảm cấp, hoặc fail closed.
Flatkey có liên quan vì flatkey.ai công khai định vị sản phẩm xoay quanh một API key, base URL tương thích OpenAI tại https://router.flatkey.ai/v1, định tuyến, thanh toán hợp nhất, phân tích 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 quota. Đây là những điểm tập trung hữu ích cho công việc về độ tin cậy. Chúng không loại bỏ nhu cầu xác định một chính sách LLM API gateway circuit breaker rõ ràng cho các luồng ứng dụng của riêng bạn.
Câu trả lời nhanh: Bộ ngắt mạch của LLM API gateway nên làm gì
Một bộ ngắt mạch LLM API gateway thực tế có ba trạng thái tuyến và một đường đi fail-closed. Hãy giữ chính sách đủ đơn giản để các kỹ sư trực vận hành có thể giải thích trong một sự cố.
| Trạng thái | Hành vi của gateway | Điều gì làm nó chuyển trạng thái | Bằng chứng cần ghi log |
|---|---|---|---|
| Closed | Lưu lượng có thể sử dụng nhà cung cấp, mô hình, họ endpoint, tài khoản hoặc nhóm tuyến. | Tỷ lệ lỗi, tỷ lệ timeout, độ trễ, phản hồi quá tải hoặc các health probe thất bại vượt ngưỡng. | ID chính sách tuyến, mô hình đã chọn, nhà cung cấp, họ endpoint, độ trễ, mã trạng thái, số lần thử lại và chi phí. |
| Open | Gateway ngừng gửi lưu lượng bình thường đến tuyến không khỏe mạnh trong một cửa sổ cooldown. | Cooldown hết hạn, hoặc một operator cho phép thủ công một probe. | Lý do breaker, thời điểm mở, số lần thử bị chặn, tuyến fallback, quyết định hàng đợi, hoặc lý do fail-closed. |
| Half-open | Gateway cho phép một số lượng giới hạn yêu cầu probe trước khi khôi phục lưu lượng. | Probe thành công sẽ đóng breaker; probe thất bại sẽ mở lại. | Kích thước mẫu probe, quy trình probe, kết quả probe, độ trễ, mức sử dụng, và phê duyệt của chủ sở hữu tuyến. |
| Fail closed | Gateway từ chối định tuyến yêu cầu vì sự cố không phải là vấn đề về sức khỏe của nhà cung cấp. | Rủi ro về auth, policy, quota, safety, ranh giới dữ liệu, yêu cầu không hợp lệ, hoặc tác động phụ của tool. | Lý do dừng, chủ sở hữu, thông báo hiển thị cho người dùng, và lộ trình khắc phục. |
Tại sao Retry tạo ra vòng lặp lỗi nhà cung cấp
Retry hữu ích khi một request thất bại vì lý do tạm thời. Chúng trở nên nguy hiểm khi mỗi request của người dùng lại tạo ra thêm nhiều lời gọi upstream, đặc biệt trong thời gian nhà cung cấp bị gián đoạn hoặc quá tải. Một vòng lặp retry có thể tiêu tốn giới hạn rate, làm hao quota, tăng độ trễ và che giấu lỗi gốc sau một lỗi cuối cùng.
Circuit breaker thay đổi câu hỏi về retry. Thay vì hỏi, "Liệu request này có nên thử lại một lần nữa không?", gateway sẽ hỏi, "Route này có đủ khỏe để nhận thêm traffic ngay bây giờ không?" Góc nhìn ở cấp route này rất quan trọng đối với workload LLM vì mỗi request có thể tốn kém, chạy lâu, streaming, dùng tool và hiển thị trực tiếp cho khách hàng.
Mẫu thiết kế cloud của Microsoft cho circuit breaker mô tả cùng ý tưởng cốt lõi cho các dịch vụ từ xa: sau nhiều lần thất bại liên tiếp, mạch sẽ mở ra để ứng dụng không tiếp tục cố thực hiện một thao tác có khả năng thất bại cao. Với một route AI, cùng mẫu này cần các ranh giới đặc thù cho LLM: hành vi mô hình, họ endpoint, mức chi tiêu token, trạng thái streaming, tác dụng phụ của tool, phân loại dữ liệu và phê duyệt fallback.
Phân loại lỗi trước khi chúng đến bộ ngắt mạch
Cách nhanh nhất để xây dựng một bộ ngắt mạch API AI tồi là coi mọi lỗi là tình trạng sức khỏe của nhà cung cấp. Điều đó tạo ra các cảnh báo sai. Nó cũng có thể che giấu những vấn đề mà chủ sở hữu ứng dụng phải tự sửa.
| Lỗi hoặc sự kiện | Quyết định của bộ ngắt mạch | Lý do | Kết quả mặc định |
|---|---|---|---|
| Provider 500, 503, overload, unavailable, connection failure, repeated upstream timeout | Tính vào sức khỏe của tuyến. | Đây là các tín hiệu hợp lý về sức khỏe của nhà cung cấp, tuyến, năng lực, hoặc mạng. | Thử lại trong phạm vi ngân sách chặt chẽ, sau đó mở bộ ngắt mạch của tuyến nếu vượt ngưỡng. |
| 429 request-rate limit | Phân loại cẩn thận. | Tín hiệu quá tải trên toàn nhà cung cấp và đợt tăng đột biến do ứng dụng tạo ra cần được xử lý khác nhau. | Giảm tốc, lùi lại, hoặc chỉ mở tuyến được phạm vi hóa mà thực sự đang bị bão hòa. |
| 429 monthly quota, exhausted credits, or spend limit | Không tính là sức khỏe của nhà cung cấp. | Đây là điều kiện về ngân sách hoặc của chủ tài khoản. | Fail closed, cảnh báo chủ ngân sách, hoặc chỉ định tuyến nếu đã có ngân sách được phê duyệt trước. |
| 401 auth, incorrect key, organization membership, IP allowlist, unsupported region | Không tính là sức khỏe của nhà cung cấp. | Yêu cầu không được phép dùng tuyến. | Fail closed và sửa thông tin xác thực, tài khoản, IP, hoặc chính sách khu vực. |
| Invalid request, unsupported parameter, unsupported model, malformed schema | Không tính là sức khỏe của nhà cung cấp. | Ứng dụng đã gửi một dạng yêu cầu mà tuyến không thể phục vụ. | Sửa yêu cầu hoặc chọn mô hình tương thích trước khi định tuyến. |
| Safety, moderation, DLP, compliance, or unapproved data-class block | Không bao giờ bỏ qua bằng phương án dự phòng. | Định tuyến sang mô hình khác có thể vượt qua ranh giới chính sách. | Fail closed và ghi lại quyết định chính sách. |
| Tool already executed, partial stream already shown, user cancelled request | Không phát lại một cách âm thầm. | Ứng dụng có thể tạo ra tác dụng phụ trùng lặp hoặc ghép hai đầu ra mô hình lại với nhau. | Đánh dấu là chưa hoàn tất, yêu cầu người dùng thử lại rõ ràng, hoặc dùng một đường khôi phục có tính idempotent. |
Hướng dẫn mã lỗi của OpenAI là một ví dụ hữu ích cho thấy vì sao phân loại này quan trọng: nó tách riêng các vấn đề xác thực và allowlist IP, các vấn đề vùng không được hỗ trợ, giới hạn tốc độ, hết hạn ngạch, lỗi máy chủ, quá tải, và việc giảm tốc đột ngột của tốc độ yêu cầu. Tài liệu của Anthropic và Google Gemini cũng đưa ra những phân biệt tương tự giữa giới hạn tốc độ, điều kiện quá tải/không khả dụng, yêu cầu không hợp lệ, và các vấn đề về quyền hoặc hạn ngạch. bộ ngắt mạch cổng API LLM của bạn nên giữ các lớp đó tách biệt trước khi mở một tuyến.
Phạm vi: đặt breaker ở tuyến đường nhỏ nhất giải thích được lỗi
Một breaker quá rộng sẽ gây ra thời gian gián đoạn không cần thiết. Một breaker quá hẹp lại khiến vòng lặp lỗi của cùng một nhà cung cấp tiếp tục lan qua các đường dẫn lân cận. Hãy giới hạn breaker ở kích thước tuyến đường nhỏ nhất có thể giải thích sự cố.
| Phạm vi | Khi nào dùng | Rủi ro nếu phạm vi đặt sai |
|---|---|---|
| Nhà cung cấp | Nhiều model từ cùng một nhà cung cấp không khả dụng hoặc bị quá tải. | Quá rộng nếu chỉ một model, tài khoản, hoặc nhóm endpoint đang lỗi. |
| Model | Một nhóm model liên tục gặp lỗi 5xx, timeout, hoặc lỗi route không được hỗ trợ. | Quá hẹp nếu tài khoản upstream hoặc nhà cung cấp đang bị quá tải. |
| Nhóm endpoint | Chat hoạt động nhưng Responses, image, video, Anthropic Messages, hoặc các route Gemini lại có hành vi khác. | Trộn các nhóm endpoint có thể che khuất các lỗi đặc thù theo giao thức. |
| Tài khoản, nhóm, khu vực, hoặc đường dẫn nhà cung cấp | Chỉ một tài khoản upstream, nhóm định tuyến, khu vực, hoặc đường dẫn nhà cung cấp đang lỗi. | Không cô lập được lỗi có thể làm tiêu hao năng lực còn tốt ở nơi khác. |
| Workflow | Tool calls, streaming, batch jobs, hoặc chat hướng đến khách hàng có các quy tắc an toàn và replay khác nhau. | Một route an toàn cho batch enrichment có thể không an toàn cho luồng người dùng trực tiếp. |
Đối với người dùng Flatkey, điều này có nghĩa là bạn nên kiểm thử từ workflow và route mà bạn thực sự dự định sử dụng. Ảnh chụp hiện tại của Flatkey pricing API cho bài viết này trả về 638 dòng model, 23 nhà cung cấp, và các nhóm endpoint cho OpenAI chat completions, OpenAI Responses, Anthropic messages, Gemini generateContent, tạo ảnh, và OpenAI video. Hãy xem đó là bằng chứng mang tính thời điểm từ ngày 18 tháng 6 năm 2026, chứ không phải là một hợp đồng tuyến đường vĩnh viễn.
Đặt các ngưỡng phù hợp với lưu lượng LLM
Một LLM API gateway circuit breaker không nên mở chỉ vì một lỗi đơn lẻ. Nó cũng không nên chờ đến khi mọi yêu cầu của khách hàng đều thất bại. Hãy dùng các ngưỡng kết hợp giữa lưu lượng tối thiểu, tỷ lệ lỗi, độ trễ và thời gian hạ nhiệt.
| Ngưỡng | Điểm khởi đầu thực tế | Vì sao quan trọng |
|---|---|---|
| Kích thước mẫu tối thiểu | Chỉ mở sau khi đã quan sát đủ số lượng yêu cầu hoặc probe. | Ngăn một lần hoàn tất đắt tiền duy nhất làm mở một tuyến toàn cục. |
| Tỷ lệ lỗi | Theo dõi riêng các lỗi upstream có thể thử lại với các lỗi thuộc về ứng dụng. | Ngăn lỗi xác thực, hạn ngạch và yêu cầu định dạng sai làm nhiễm bẩn sức khỏe tuyến. |
| Ngưỡng độ trễ hoặc timeout | Dùng ngân sách timeout riêng cho từng endpoint cho các luồng chat, streaming, hình ảnh và video. | Một ngưỡng tốt cho chat có thể sai cho video hoặc tạo hàng loạt. |
| Cooldown khi mở | Giữ tuyến ở trạng thái mở đủ lâu để chặn các cơn bão retry, rồi mới probe. | Bảo vệ cả nhà cung cấp lẫn hàng đợi yêu cầu của chính bạn. |
| Giới hạn probe half-open | Cho phép một số ít yêu cầu kiểm thử có kiểm soát trước khi đóng lại. | Ngăn lưu lượng tăng vọt hoàn toàn khi nhà cung cấp chỉ mới phục hồi một phần. |
| Ngưỡng chi phí | Đặt mức chi tiêu ước tính tối đa cho retry, fallback và probe. | Ngăn việc khôi phục độ tin cậy trở thành một sự cố thanh toán. |
Giới hạn tốc độ là một phần của thảo luận về ngưỡng. Hướng dẫn về rate limit của OpenAI giải thích rằng rate limit bảo vệ khỏi lạm dụng, đảm bảo quyền truy cập công bằng và giúp quản lý tải tổng hợp. Nếu ứng dụng của bạn cứ tiếp tục retry vào một tuyến bị giới hạn tốc độ, chính mẫu lưu lượng của bạn có thể trở thành sự cố. LLM API gateway circuit breaker nên hoạt động cùng với việc điều tiết phía client, xếp hàng và kiểm soát hạn ngạch, chứ không phải đối đầu với chúng.
Quyết định Điều Gì Xảy Ra Khi Breaker Đang Mở
Việc mở một breaker chỉ hữu ích nếu gateway có hành động tiếp theo được xác định rõ. Đừng để mọi route mở tự động rơi về bất kỳ model nào sẵn có.
| Hành động ở trạng thái mở | Khi sử dụng | Guardrail bắt buộc |
|---|---|---|
| Route dự phòng | Model hoặc nhà cung cấp dự phòng đã được phê duyệt cho quy trình này. | Chạy cùng các kiểm tra eval, schema, tool, ranh giới dữ liệu và chi phí trước khi lên production. |
| Xếp hàng | Job là bất đồng bộ hoặc trải nghiệm người dùng có thể chấp nhận độ trễ. | Bảo toàn metadata về owner, customer, model, cost và retry. |
| Suy giảm | Một kết quả một phần ít rủi ro hơn là chấp nhận được, chẳng hạn phản hồi được lưu cache hoặc tính năng bị giảm. | Hiển thị rõ trạng thái suy giảm cho ứng dụng và log. |
| Fail closed | Yêu cầu có rủi ro về policy, ngân sách, an toàn, xác thực, khu vực hoặc tác động phụ. | Trả về lỗi rõ ràng và cảnh báo đúng owner thay vì thử một model khác. |
Tài liệu công khai Vercel AI Gateway docs mô tả model fallbacks như một pattern của gateway với các model dự phòng theo thứ tự. Hãy xem đó chỉ là bằng chứng cho phân loại. Trong stack của riêng bạn, fallback là một quyết định phê duyệt riêng. Breaker quyết định liệu một route hiện có đang khỏe hay không; fallback quyết định liệu route khác có được phép phục vụ cùng yêu cầu hay không.
Streaming Và Lệnh Gọi Tool Cần Các Điểm Dừng Bổ Sung
Streaming làm cho vòng lặp lỗi của nhà cung cấp dễ bị che giấu hơn. Nếu ứng dụng tự động khởi động lại một yêu cầu sau khi đã xuất một phần đầu ra, người dùng có thể nhìn thấy một câu trả lời ghép từ hai lần thử. Lệnh gọi tool tạo ra một vấn đề thứ hai: một lần retry hoặc fallback có thể tạo trùng một khoản hoàn tiền, cập nhật ticket, email, ghi cơ sở dữ liệu hoặc hành động bên ngoài.
Hãy sử dụng các quy tắc này trong chính sách LLM API gateway circuit breaker:
- Trước đầu ra đầu tiên: có thể cho phép retry hoặc fallback nếu tuyến được phê duyệt và breaker đang đóng hoặc half-open.
- Sau đầu ra đầu tiên: đánh dấu luồng là chưa hoàn tất và yêu cầu người dùng retry rõ ràng thay vì fallback âm thầm.
- Sau khi thực thi tool: không phát lại trừ khi tool là idempotent và thao tác có replay key.
- Sau khi bị chặn bởi chính sách: fail closed. Không định tuyến sang một mô hình khác để vượt qua chặn.
Điều này đi cùng với các hướng dẫn AI API retry strategy, model fallback checklist, và AI API load balancing and failover. Breaker nên chia sẻ cùng taxonomy lỗi như các playbook đó.
Các trường quan sát được cho việc đánh giá circuit breaker
Nếu một yêu cầu thành công chỉ vì gateway âm thầm bỏ qua một route bị lỗi, sự cố đó vẫn cần được hiển thị rõ. Tài liệu AI Gateway của Cloudflare cung cấp một ví dụ công khai về các mẫu quan sát AI gateway: request logs có thể bao gồm nhà cung cấp, trạng thái, token, chi phí và thời lượng, còn custom metadata có thể gắn thẻ các yêu cầu để lọc về sau. Nhật ký gateway của bạn nên cung cấp cùng mức độ bằng chứng về route cho các quyết định của breaker.
| Trường | Vì sao người vận hành cần trường này |
|---|---|
| Breaker policy ID and version | Cho biết quy tắc nào đã mở, đóng hoặc bỏ qua route. |
| Breaker state at decision time | Giải thích liệu route đã đóng, mở, nửa mở hay fail-closed. |
| Requested model, selected model, provider, account, group, and endpoint family | Tách ý định của người dùng khỏi quyết định route của gateway. |
| Error class per attempt | Phân biệt lỗi từ upstream với lỗi auth, quota, yêu cầu không hợp lệ, policy và tool. |
| Latency, timeout, retry count, and probe result | Cho biết route thất bại chậm, thất bại nhanh hay phục hồi trong quá trình probing nửa mở. |
| Partial-output flag and tool side-effect status | Ngăn các sự cố đầu ra trộn lẫn hoặc hành động trùng lặp bị che giấu. |
| Usage, cost, quota owner, and final disposition | Kết nối khả năng khôi phục độ tin cậy với chi tiêu, ngân sách và trách nhiệm. |
Bài viết AI API observability logs đi kèm sẽ đi sâu hơn về ghi log sự cố. Với circuit breaker, hãy ưu tiên trạng thái route và lý do chính xác khiến một yêu cầu bị chặn, được probing, được định tuyến, được xếp hàng hoặc fail closed.
Kế hoạch triển khai Flatkey cho các chính sách Circuit Breaker
Hãy sử dụng cách tiếp cận theo từng giai đoạn này trước khi dựa vào LLM API gateway circuit breaker cho lưu lượng khách hàng thông qua Flatkey hoặc bất kỳ cổng tương thích OpenAI nào.
- Tạo một khóa staging: giữ các bài kiểm tra breaker tách biệt 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à kiểm tra model, họ endpoint, hàng usage và khả năng hiển thị trên dashboard. - Lưu snapshot danh mục route: lưu trang giá của Flatkey và phản hồi API giá tại ngày triển khai để các giả định về route và giá có thể được kiểm toán.
- Xác định taxonomy lỗi: quyết định lỗi nào được tính vào sức khỏe route và lỗi nào sẽ fail closed trước khi breaker nhìn thấy chúng.
- Bắt đầu với một workflow: áp dụng breaker cho một route model, một họ endpoint và một lớp lưu lượng trước khi mở rộng.
- Buộc kiểm tra lỗi: mô phỏng provider timeout, 500, 503, request-rate 429, cạn quota, lỗi xác thực, request sai định dạng, stream một phần và tác dụng phụ của tool.
- Xác minh hành vi trạng thái open: xác nhận các hành động fallback, queue, degrade hoặc fail-closed khớp với ma trận phê duyệt.
- Rà soát log và billing: xác nhận trạng thái breaker, route đã chọn, usage, chi phí và chủ sở hữu quota đều hiển thị sau mỗi lần kiểm tra.
- Thiết lập rollback: vô hiệu hóa policy nếu nó mở quá rộng, che khuất các lỗi do ứng dụng sở hữu, hoặc làm phát sinh chi tiêu không mong đợi.
Mẫu chính sách Circuit Breaker
Mẫu này không phải là một hợp đồng API của Flatkey. Hãy coi nó như một tài liệu rà soát cho các bên phụ trách kỹ thuật, sản phẩm, tài chính và bảo mật.
{
"policy_id": "support-chat-provider-breaker-v1",
"workflow": "customer-support-chat",
"environment": "production",
"route_scope": {
"provider": "primary-provider",
"model": "primary-approved-model",
"endpoint_family": "openai-chat-completions",
"traffic_class": "customer-visible-stream"
},
"count_toward_breaker": [
"upstream_5xx",
"provider_overloaded",
"provider_unavailable",
"upstream_timeout",
"connection_reset"
],
"fail_closed_before_breaker": [
"auth_error",
"ip_allowlist_error",
"unsupported_region",
"quota_exhausted",
"invalid_request",
"schema_incompatible",
"safety_or_policy_block",
"unapproved_data_class",
"tool_side_effect_already_committed"
],
"thresholds": {
"window_seconds": 60,
"minimum_requests": 20,
"failure_ratio_to_open": 0.5,
"timeout_ratio_to_open": 0.4,
"open_cooldown_seconds": 90,
"half_open_probe_requests": 3,
"max_total_attempts_per_request": 2
},
"open_state_action": {
"default": "fail_closed",
"allowed_fallback_policy_ids": [
"support-chat-fallback-v1"
],
"allow_after_partial_output": false,
"allow_after_tool_side_effect": false
},
"logging": {
"record_breaker_state": true,
"record_route_scope": true,
"record_error_class_per_attempt": true,
"record_probe_results": true,
"record_usage_cost_and_quota_owner": true
}
}Câu hỏi thường gặp
LLM API gateway circuit breaker là gì?
LLM API gateway circuit breaker là một chính sách tình trạng tuyến đường, ngăn lưu lượng bình thường đi tới một model, nhà cung cấp, tài khoản hoặc họ endpoint không khỏe sau khi lặp lại nhiều lỗi có thể retry. Nó mở trong một khoảng thời gian làm nguội, cho phép một số probe half-open giới hạn, và chỉ đóng lại sau khi tuyến đường trông khỏe mạnh trở lại.
Những lỗi nào của LLM API nên mở circuit breaker?
Các lỗi 5xx từ phía nhà cung cấp, tình trạng quá tải, phản hồi unavailable, lỗi kết nối, và các lần upstream timeout lặp lại thường là ứng viên điển hình. Lỗi xác thực, lỗi allowlist IP, khu vực không được hỗ trợ, quota đã hết, yêu cầu định dạng sai, chặn bởi chính sách, và các tác dụng phụ của công cụ thường nên fail closed thay vì mở một breaker về tình trạng nhà cung cấp.
Circuit breaker khác retry hoặc fallback như thế nào?
Retry quyết định liệu một yêu cầu có nên được thử lại hay không. Fallback quyết định liệu một tuyến đường được phê duyệt khác có thể phục vụ yêu cầu hay không. Circuit breaker quyết định liệu một tuyến đường có nên nhận lưu lượng bình thường hay không khi nó có vẻ đang không khỏe.
Circuit breaker có nên áp dụng cho phản hồi streaming của LLM không?
Có, nhưng với ranh giới chặt chẽ hơn. Một breaker có thể bảo vệ tuyến đường trước token đầu tiên nhìn thấy được. Sau khi đã có output một phần hoặc một tác dụng phụ của công cụ, ứng dụng không nên âm thầm phát lại hoặc fallback trừ khi workflow được thiết kế rõ ràng cho khôi phục có tính idempotent.
Kiểm tra cuối cùng trước khi bạn bật circuit breaker
Trước khi bạn bật LLM API gateway circuit breaker, hãy tự hỏi một câu: nếu tuyến này mở ra trong một sự cố của nhà cung cấp, liệu đội ngũ có thể giải thích điều gì đã lỗi, vì sao lưu lượng thông thường dừng lại, lưu lượng tiếp theo đi đâu, nó tốn kém bao nhiêu, và cách đóng hoặc hoàn nguyên chính sách này không?
Nếu câu trả lời là không, hãy giữ breaker ở môi trường staging. Nếu câu trả lời là có, hãy dùng quyền truy cập mô hình tập trung, định tuyến, khả năng quan sát mức sử dụng, thanh toán và kiểm soát hạn ngạch của Flatkey như một phần của vòng lặp rà soát. Khi bạn sẵn sàng xác thực các tuyến sau một gateway tương thích OpenAI, lấy một key và bắt đầu với một workflow, một tuyến mô hình, và một chính sách breaker.
