Một AI API gateway cung cấp cho ứng dụng một điểm cuối ổn định duy nhất, trong khi hạ tầng phía sau điểm cuối đó có thể sử dụng nhiều mô hình, nhà cung cấp, tài khoản hoặc khu vực. Phần hữu ích không chỉ là che giấu nhiều API key phía sau một key. Phần hữu ích là tạo ra một điểm quyết định có kiểm soát cho mọi yêu cầu.
Điểm quyết định đó có thể trả lời các câu hỏi vận hành trước khi lưu lượng đi tới nhà cung cấp mô hình:
- Khách hàng này có được phép gọi mô hình được yêu cầu không?
- Upstream nào hiện tại đáp ứng được yêu cầu về khả năng, độ trễ và chi phí?
- Upstream đó có đủ khỏe để nhận thêm lưu lượng không?
- Yêu cầu này có thể được thử lại một cách an toàn không?
- Cơ chế fallback nào sẽ bảo toàn hợp đồng phản hồi?
- Sau đó đội ngũ sẽ giải thích tuyến, chi phí và lỗi như thế nào?
Hướng dẫn này ánh xạ những trách nhiệm đó vào một kiến trúc production. Nó cũng cho thấy một API key duy nhất hữu ích ở đâu, không hữu ích ở đâu, và cách chuyển một client tương thích OpenAI mà không biến gateway thành nguồn ẩn của các bất ngờ về định tuyến.
The reference architecture in one request path
Một yêu cầu qua AI gateway thực tế đi qua năm lớp:
- Hợp đồng phía client: ứng dụng gửi một yêu cầu đã xác thực tới một base URL ổn định duy nhất.
- Kiểm soát tiếp nhận: gateway xác thực danh tính, hạn mức, quyền mô hình, giới hạn payload và metadata của yêu cầu.
- Chính sách định tuyến: một bộ máy chính sách chuyển đổi mô hình hoặc khả năng được yêu cầu thành các đích upstream đủ điều kiện.
- Kiểm soát thực thi: các quy tắc về trạng thái khỏe, đồng thời, timeout, retry, fallback và streaming quyết định cách gọi đích đã chọn.
- Telemetry và hạch toán: gateway ghi lại tuyến đã chọn, trạng thái phản hồi, độ trễ, mức sử dụng token hoặc media, và phân bổ chi phí.
Ứng dụng / agent
|
| một API key + lược đồ yêu cầu ổn định
v
AI API gateway
├─ xác thực và chính sách tenant
├─ sổ đăng ký alias mô hình và năng lực
├─ chính sách định tuyến và quy tắc ngân sách
├─ kiểm soát trạng thái khỏe, timeout, retry và fallback
└─ logs, traces, usage, và phân bổ chi phí
|
├────────> Nhà cung cấp hoặc triển khai A
├────────> Nhà cung cấp hoặc triển khai B
└────────> Nhà cung cấp hoặc triển khai C
Do đó, gateway vừa là một control plane vừa là một data plane. Control plane lưu trữ chính sách, thông tin xác thực, alias, hạn mức và cấu hình định tuyến. Data plane xử lý các yêu cầu trực tiếp, phản hồi streaming, retry và telemetry. Giữ các trách nhiệm này tách biệt về mặt khái niệm sẽ giúp thay đổi an toàn hơn: người vận hành có thể cập nhật chính sách định tuyến mà không cần yêu cầu mọi đội ứng dụng phát hành mã client mới.
“Một khóa” nên có nghĩa là gì
“Một khóa” nên có nghĩa là một hợp đồng thông tin xác thực hướng tới ứng dụng duy nhất, chứ không phải một thông tin xác thực được dùng chung cho mọi người, dịch vụ và môi trường.
Một thiết kế đúng đắn sẽ cấp các thông tin xác thực gateway riêng biệt cho production, staging, phát triển cục bộ, CI và các workload độc lập. Mỗi key nên có phạm vi hẹp, một chủ sở hữu, một hạn mức và một đường thu hồi. Sau đó gateway giữ các thông tin xác thực của nhà cung cấp ở phía server và ánh xạ danh tính đầu vào tới các thông tin xác thực upstream mà nó được phép dùng.
Điều này tạo ra một ranh giới bảo mật hữu ích:
| Ranh giới | Khách hàng có thể thấy | Gateway có thể thấy | Nhà cung cấp có thể thấy |
|---|---|---|---|
| Thông tin xác thực ứng dụng | Khóa gateway của chính nó | Danh tính khách hàng và chính sách | Không bắt buộc |
| Thông tin xác thực nhà cung cấp | Không gì cả | Secret upstream được mã hóa hoặc danh tính được quản lý | Danh tính tài khoản nhà cung cấp |
| Chính sách định tuyến | Mô hình công khai hoặc bí danh được yêu cầu | Các đích đủ điều kiện và lý do lựa chọn | Chỉ yêu cầu đã được chọn |
| Bối cảnh tính phí | Mức sử dụng cấp ứng dụng nếu được hiển thị | Tenant, dự án, tuyến, mức sử dụng và ánh xạ giá | Mức sử dụng phía nhà cung cấp |
Khóa gateway không bao giờ nên được xem là lý do để nới lỏng vệ sinh khóa. Hãy đặt nó trong trình quản lý bí mật, không bao giờ trong mã trình duyệt hoặc kho lưu trữ công khai, xoay vòng nó, và tách riêng theo môi trường. Để xem danh sách kiểm tra vận hành chi tiết hơn, hãy xem quản lý khóa API an toàn cho các sản phẩm AI.
Bí danh mô hình tách hợp đồng của khách hàng khỏi nhà cung cấp
Trừu tượng định tuyến đầu tiên là một bí danh mô hình. Thay vì mã hóa cứng một mã định danh mô hình riêng của nhà cung cấp trong toàn bộ ứng dụng, khách hàng yêu cầu một tên ổn định như:
support-fast
reasoning-high
code-review-default
image-generation-standard
Sổ đăng ký đứng sau mỗi bí danh xác định một hợp đồng năng lực. Một bí danh văn bản có thể chỉ định gọi công cụ, đầu ra có cấu trúc, kích thước ngữ cảnh tối thiểu, hỗ trợ streaming, và một họ fallback được phê duyệt. Một bí danh hình ảnh hoặc video cần các trường khác, chẳng hạn như loại đầu vào được chấp nhận, kích thước đầu ra, hành vi tác vụ bất đồng bộ, và các ràng buộc an toàn.
Một bí danh không nên hứa rằng mọi mô hình ứng viên đều hoạt động giống hệt nhau. Nó nên xác định hành vi tối thiểu mà ứng dụng có thể dựa vào.
alias: support-fast
contract:
modality: text
streaming: true
tools: optional
structured_output: required
maximum_latency_ms: 3500
routes:
- target: provider-a/model-fast
priority: 1
- target: provider-b/model-balanced
priority: 2
Sự gián tiếp này chính là điều làm cho một URL cơ sở ổn định trở nên có giá trị. Các ứng dụng tích hợp với hợp đồng bí danh; chủ sở hữu nền tảng có thể thay đổi tập đích sau khi đánh giá, một sự cố ở nhà cung cấp, thay đổi về giá, hoặc yêu cầu khu vực.
Quyết định định tuyến nên được làm rõ ràng
Định tuyến trong môi trường production thường kết hợp các bộ lọc cứng và xếp hạng mềm.
1. Áp dụng các bộ lọc đủ điều kiện cứng
Loại bỏ bất kỳ đích nào không thể đáp ứng yêu cầu. Các bộ lọc phổ biến bao gồm:
- Chế độ và loại đầu vào bắt buộc
- Yêu cầu về cửa sổ ngữ cảnh hoặc kích thước đầu ra
- Hỗ trợ gọi công cụ hoặc đầu ra có cấu trúc
- Cư trú dữ liệu hoặc khả dụng theo khu vực
- Danh sách cho phép của tenant hoặc dự án
- Chính sách an toàn hoặc tuân thủ
- Quota hiện tại, giới hạn tốc độ, hoặc trạng thái đồng thời
- Tương thích streaming
Một đích không đạt yêu cầu cứng không bao giờ nên được chọn chỉ vì nó rẻ hơn.
2. Xếp hạng các đích đủ điều kiện
Sau khi lọc, chấm điểm các tuyến còn lại. Một chính sách đơn giản có thể dễ vận hành hơn một bộ tối ưu hóa khó hiểu:
route score =
quality_weight × evaluation_score
- latency_weight × predicted_latency
- cost_weight × estimated_cost
- risk_weight × recent_error_rate
Các trọng số nên khác nhau tùy theo khối lượng công việc. Chat tương tác có thể ưu tiên thời gian đến token đầu tiên. Một tác vụ trích xuất chạy ban đêm có thể ưu tiên chi phí trên mỗi bản ghi có cấu trúc thành công. Một tác tử lập trình có thể coi độ tin cậy của công cụ và hành vi ngữ cảnh dài quan trọng hơn một chênh lệch giá nhỏ.
3. Ghi lại lý do
Mỗi quyết định định tuyến nên tạo ra siêu dữ liệu có thể đọc bằng máy, chẳng hạn như:
{
"requested_alias": "support-fast",
"selected_target": "provider-a/model-fast",
"policy_version": "support-fast-2026-07-29.3",
"selection_reason": "healthy_primary_within_latency_budget",
"fallback_count": 0
}
Nếu một nhóm không thể tái tạo lý do vì sao một tuyến được chọn, họ không thể gỡ lỗi sự trôi lệch chi phí, suy giảm chất lượng, hoặc sự cố của nhà cung cấp.
Kiểm tra sức khỏe cần nhiều hơn một HTTP 200
Một upstream có thể trả về các kiểm tra sức khỏe thành công trong khi vẫn thất bại với lưu lượng mô hình thực tế. Vì vậy, sức khỏe của AI gateway cần nhiều tín hiệu:
- Sức khỏe truyền tải: lỗi kết nối, lỗi TLS, lỗi DNS và timeout từ upstream
- Sức khỏe API: phản hồi giới hạn tốc độ, lỗi xác thực, lỗi từ nhà cung cấp và phản hồi bị định dạng sai
- Sức khỏe mô hình: đầu ra rỗng, đầu ra có cấu trúc không hợp lệ, lời gọi công cụ bị lỗi, hoặc các mảnh streaming không tương thích
- Sức khỏe hiệu năng: thời gian đến token đầu tiên, độ trễ tổng thể, thời gian chờ hàng đợi và thông lượng
- Sức khỏe năng lực: số yêu cầu đồng thời, áp lực token mỗi phút, số dư tài khoản, hoặc hạn mức triển khai
Hãy dùng một cửa sổ trượt thay vì chỉ một lần thất bại. Một circuit breaker có thể tạm thời loại bỏ một đích sau khi vượt ngưỡng thất bại hoặc độ trễ, sau đó cho phép các probe giới hạn trước khi khôi phục toàn bộ lưu lượng. Phát hiện outlier cũng có thể loại bỏ một triển khai không khỏe mạnh trong khi vẫn giữ các triển khai khỏe mạnh từ cùng nhà cung cấp khả dụng.
Nguyên tắc này đã được thiết lập rõ trong hạ tầng gateway và service mesh: retry, circuit breaking, và phát hiện outlier là các cơ chế riêng biệt, và mỗi cơ chế cần một chính sách có giới hạn. Envoy mô tả riêng từng cơ chế này trong hướng dẫn về HTTP retry, circuit breaking, và phát hiện outlier.
Chỉ retry khi yêu cầu an toàn
Retry chỉ cải thiện độ tin cậy khi chúng không nhân đôi công việc hoặc tạo ra side effect trùng lặp.
Với một lần hoàn tất văn bản không streaming bị lỗi trước khi bất kỳ byte phản hồi nào đến, một lần retry đối với cùng đích có thể là hợp lý. Với một yêu cầu kích hoạt công cụ, khởi chạy một công việc tạo ảnh hoặc video, tính phí vào tài khoản bên ngoài, hoặc đã stream một phần đầu ra, một lần retry mù quáng có thể tạo ra bản sao hoặc làm hỏng trải nghiệm người dùng.
Hãy xác định điều kiện đủ để retry bằng ba câu hỏi:
- Yêu cầu đã được chấp nhận ở upstream chưa? Lỗi kết nối trước khi được chấp nhận khác với timeout sau khi nhà cung cấp bắt đầu xử lý.
- Đã có đầu ra nào đến được client chưa? Khi streaming bắt đầu, việc chuyển sang nhà cung cấp khác có thể tạo ra một câu trả lời bị gián đoạn.
- Có khóa idempotency hoặc bản ghi khử trùng lặp không? Các quy trình media và agent chạy dài cần một định danh thao tác ổn định.
Một ma trận retry thận trọng trông như sau:
| Lỗi | Retry cùng đích | Fallback sang đích khác | Ghi chú |
|---|---|---|---|
| Lỗi kết nối trước khi có phản hồi | Thường an toàn, có giới hạn | Thường an toàn | Áp dụng jitter và ngân sách deadline |
| Giới hạn tốc độ của nhà cung cấp | Đôi khi | Thường xuyên | Tôn trọng gợi ý retry và trạng thái năng lực |
| Lỗi 5xx của nhà cung cấp trước khi có đầu ra | Có giới hạn | Thường xuyên | Tạm thời loại trừ đích không khỏe mạnh |
| Đầu ra có cấu trúc không hợp lệ | Chỉ khi có chính sách sửa lỗi | Chỉ tới đích tương thích hợp đồng | Tính vào SLO chất lượng |
| Phản hồi streaming một phần | Thường là không | Thường là không | Trả về lỗi stream rõ ràng hoặc chỉ tiếp tục với một giao thức rõ ràng |
| Job media async đã được chấp nhận | Không retry mù quáng | Không fallback mù quáng | Polling theo operation ID; khử trùng lặp các submission |
Giữ một deadline end-to-end duy nhất. Nếu client cho phép tám giây, gateway không thể dùng bảy giây cho primary rồi lại cho fallback thêm tám giây nữa. Mỗi lần thử đều tiêu tốn cùng một ngân sách request.
Fallback phải bảo toàn hợp đồng
Fallback không đơn giản là “thử một model khác.” Đó là một thỏa thuận về những gì có thể thay đổi khi tuyến primary gặp lỗi.
Định nghĩa fallback ở ba cấp độ:
- Cùng model, khác deployment hoặc account: rủi ro hành vi thấp nhất; hữu ích cho lỗi quota hoặc vùng.
- Họ model tương đương: rủi ro trung bình; cần regression test cho schema, tools, safety và phong cách đầu ra.
- Khả năng bị suy giảm: rủi ro cao nhất; có thể vô hiệu hóa tools, giảm context hoặc trả về phản hồi hàng đợi thay vì phản hồi trực tiếp.
Với mỗi alias, hãy ghi rõ:
- Những lớp lỗi nào kích hoạt fallback
- Những đích nào tương thích hợp đồng
- Client có được thông báo rằng fallback đã xảy ra hay không
- Số lần thử tối đa và deadline tổng
- Cách đo lường thay đổi về chất lượng và chi phí
- Phản hồi có thể được cache hoặc phát lại hay không
Quyền truy cập nhà cung cấp theo khu vực bổ sung thêm một chiều nữa. Một nhà cung cấp hoặc model có thể khả dụng ở một địa lý, loại tài khoản hoặc thỏa thuận thương mại và không khả dụng ở nơi khác. Định tuyến nhà cung cấp LLM theo khu vực giải thích các kiểm tra riêng biệt về truy cập, chính sách và failover cần thiết cho những tuyến đó.
Streaming là một phần của hợp đồng gateway
Các dạng request tương thích với OpenAI có thể đơn giản hóa việc di chuyển client, nhưng khả năng tương thích streaming đòi hỏi chuyển đổi có chủ đích. Gateway phải bảo toàn thứ tự sự kiện, finish reason, metadata sử dụng, các fragment của tool-call, tín hiệu lỗi và hủy kết nối.
Trước khi định tuyến hai model phía sau một alias streaming duy nhất, hãy kiểm tra:
- Thời gian đến sự kiện đầu tiên và hành vi heartbeat
- Định dạng delta văn bản gia tăng
- Lắp ráp đối số tool-call
- Báo cáo usage trong sự kiện cuối cùng
- Truyền tiếp hủy bỏ từ client
- Hành vi timeout trước và sau sự kiện đầu tiên
- Định dạng lỗi sau khi headers đã được gửi
Đừng giấu việc khởi động lại luồng trong một phản hồi trừ khi giao thức hỗ trợ rõ ràng khả năng tiếp tục. Trong hầu hết client, việc trộn một câu trả lời dang dở từ một model với câu trả lời thứ hai từ một model khác tệ hơn việc trả về một lỗi rõ ràng.
Khả năng quan sát kết nối routing với kết quả
Dashboard của gateway hữu ích, nhưng việc chẩn đoán trong production cần telemetry có cấu trúc, có thể liên kết một yêu cầu model với trace của ứng dụng xung quanh.
Tối thiểu, hãy ghi nhận:
| Dimension | Trường ví dụ |
|---|---|
| Danh tính | tenant, project, environment, key ID, workload |
| Yêu cầu | request ID, operation ID, alias, modality, kích thước đầu vào |
| Routing | phiên bản policy, các đích đủ điều kiện, đích được chọn, số lần fallback |
| Độ tin cậy | nhóm trạng thái, mã lỗi nhà cung cấp, số lần thử lại, giai đoạn timeout |
| Hiệu năng | thời gian chờ hàng đợi, thời gian đến token đầu tiên, độ trễ tổng, thông lượng đầu ra |
| Sử dụng | đơn vị input, output, cache, hình ảnh, âm thanh hoặc video |
| Kinh tế | chi phí ước tính, chi phí được tính hóa đơn, quy tắc ngân sách, phiên bản giá |
| Chất lượng | nhãn đánh giá, tính hợp lệ của schema, thành công của tool, kết quả người dùng |
Tránh ghi log prompt và đầu ra thô theo mặc định. Chỉ ghi lại nội dung khi trường hợp sử dụng, chính sách lưu giữ và kỳ vọng của người dùng cho phép. Dự án OpenTelemetry duy trì các quy ước ngữ nghĩa cho hệ thống AI sinh sinh đang phát triển, có thể giúp các nhóm sử dụng tên span và metric nhất quán thay vì tự tạo một schema riêng cho từng nhà cung cấp.
Kiểm soát chi phí phải đặt trước lời gọi tới upstream
Báo cáo chi tiêu hậu kiểm không thể ngăn một sự cố. Policy chấp nhận và routing nên đánh giá chi phí trước khi gửi lưu lượng.
Các kiểm soát hữu ích bao gồm:
- Hạn mức cứng theo từng key và từng project
- Cảnh báo ngân sách mềm
- Số đơn vị đầu vào hoặc đầu ra tối đa
- Allowlist model theo môi trường
- Routing nhận biết chi phí cho workload linh hoạt
- Policy cache cho các yêu cầu lặp lại
- Giới hạn đồng thời cho các tác vụ media tốn kém
- Công tắc tắt khẩn cấp cho một model, nhà cung cấp, tenant hoặc route
Engine routing cần một bảng giá được phiên bản hóa và một lớp chuẩn hóa usage nhất quán. Nếu không, policy “model rẻ nhất” có thể so sánh các đơn vị không tương thích hoặc giá cũ. Để xem một framework tách biệt mức giá của nhà cung cấp, phí nền tảng và các kiểm soát vận hành, hãy xem AI gateway pricing.
Di chuyển tối thiểu tương thích OpenAI
Thay đổi nhỏ nhất ở client thường chỉ là một API key mới, base URL mới và tên model mới. Với một gateway tương thích OpenAI, code ứng dụng có thể giữ nguyên cùng thư viện client:
import os
from openai import OpenAI
client = OpenAI(
api_key=os.environ["FLATKEY_API_KEY"],
base_url="https://router.flatkey.ai/v1",
)
response = client.chat.completions.create(
model="your-model-or-alias",
messages=[
{"role": "user", "content": "Tóm tắt báo cáo sự cố này."}
],
)
Thay đổi mã đó là phần dễ nhất. Một quá trình di chuyển an toàn có bốn giai đoạn:
- Kiểm kê hợp đồng hiện tại. Ghi lại các model, tham số, hành vi streaming, công cụ, lược đồ, timeout và xử lý lỗi.
- Chạy đánh giá shadow hoặc ngoại tuyến. So sánh chất lượng đầu ra, tính hợp lệ của lược đồ, độ trễ và chi phí trên các yêu cầu đại diện.
- Canary một workload. Bắt đầu với một tỷ lệ lưu lượng có giới hạn và một đường quay lui ngay lập tức.
- Bật riêng từng tính năng định tuyến. Trước tiên đổi endpoint, sau đó thêm alias, rồi chuyển đổi dự phòng dựa trên sức khỏe, sau đó tối ưu chi phí hoặc chất lượng.
Tách biệt những thay đổi đó giúp việc chẩn đoán sự cố dễ dàng hơn. Nếu việc di chuyển endpoint, thay thế model, chính sách thử lại và bộ tối ưu chi phí cùng khởi chạy một lúc, đội ngũ sẽ không biết biến nào gây ra suy giảm. Flatkey integration starter trình bày chi tiết hơn về mẫu di chuyển base URL.
Danh sách kiểm tra sẵn sàng cho sản xuất
Hãy dùng danh sách kiểm tra này trước khi coi gateway là hạ tầng dùng chung.
Hợp đồng client
- Base URL ổn định và lược đồ request được phiên bản hóa
- Alias có tên với các khả năng tối thiểu được tài liệu hóa
- Bao lỗi nhất quán và request ID
- Đã kiểm thử streaming, gọi tool và đầu ra có cấu trúc
Danh tính và bảo mật
- Tách riêng key theo dịch vụ và môi trường
- Thông tin xác thực nhà cung cấp ở phía server
- Phạm vi key, hạn mức, xoay vòng và thu hồi
- Tắt ghi log prompt và response, hoặc được quản lý một cách rõ ràng
Định tuyến và độ tin cậy
- Bộ lọc đủ điều kiện cứng trước khi xếp hạng theo chi phí
- Chính sách định tuyến và dữ liệu giá được phiên bản hóa
- Trạng thái sức khỏe dựa trên hành vi request thực tế
- Số lần thử lại có giới hạn với một deadline end-to-end
- Mục tiêu dự phòng tương thích về hợp đồng
- Circuit breaker và các probe phục hồi
Vận hành
- Telemetry về lý do tuyến, lỗi nhà cung cấp, độ trễ và mức sử dụng
- Cảnh báo cho tỷ lệ fallback, tỷ lệ lỗi, độ lệch chi phí và áp lực hạn mức
- Công tắc ngắt cho từng model và từng tuyến
- Runbook cho sự cố nhà cung cấp và sự cố gateway
- Đường đi khẩn cấp trực tiếp hoặc thay thế cho các workload quan trọng
Flatkey phù hợp với kiến trúc này như thế nào
Flatkey cung cấp một API key, một base URL tương thích với OpenAI và một bảng điều khiển cho quyền truy cập model được hỗ trợ, mức sử dụng và thanh toán. Bộ định tuyến của nó được thiết kế để giảm số lượng tài khoản nhà cung cấp riêng lẻ và các đường tích hợp phân mảnh, đồng thời hỗ trợ chuyển đổi upstream và cân bằng tải.
Đối với một nhóm ứng dụng, lợi ích về kiến trúc là một ranh giới client ổn định: trỏ một client tương thích OpenAI tới https://router.flatkey.ai/v1, chọn một mô hình được hỗ trợ, và giữ quyền truy cập mô hình phía sau cùng một endpoint gateway. Các nhóm vẫn nên tự định nghĩa các hợp đồng ở cấp ứng dụng, ngưỡng đánh giá, phạm vi khóa, ngân sách lỗi và kỳ vọng dự phòng của riêng mình.
Kiến trúc gateway tốt nhất không làm cho việc định tuyến trở nên vô hình. Nó làm cho việc định tuyến trở nên có thể thay đổi, có giới hạn và dễ giải thích.
FAQ
AI API gateway là gì?
AI API gateway là lớp trung gian giữa các ứng dụng và nhà cung cấp mô hình. Nó tập trung hóa xác thực, quyền truy cập mô hình, định tuyến, các kiểm soát độ tin cậy, theo dõi mức sử dụng và chính sách, đồng thời cung cấp một API ổn định cho phía client.
Một API key có nghĩa là mọi dịch vụ đều dùng chung cùng một khóa không?
Không. Điều đó có nghĩa là các ứng dụng sử dụng thông tin xác thực do gateway cấp thay vì xử lý trực tiếp từng thông tin xác thực của nhà cung cấp. Các dịch vụ production, môi trường và nhóm vẫn nên nhận các khóa riêng biệt có phạm vi cụ thể.
Định tuyến mô hình là gì?
Định tuyến mô hình là quá trình lọc các mô hình hoặc triển khai đủ điều kiện và chọn một đích đến dựa trên năng lực, chính sách, tình trạng, độ trễ, chất lượng, chi phí, khu vực hoặc năng lực.
Chiến lược dự phòng an toàn nhất là gì?
Bắt đầu với cùng một mô hình trên một triển khai hoặc tài khoản khỏe mạnh khác. Dự phòng sang mô hình khác chỉ nên xảy ra sau khi các bài kiểm thử cho thấy đích đến thay thế vẫn giữ nguyên lược đồ, công cụ, streaming, an toàn và hợp đồng chất lượng của ứng dụng.
Gateway có thể thử lại một phản hồi streaming trên mô hình khác không?
Thường là không sau khi đầu ra đã đến được client. Việc chuyển đổi giữa chừng có thể kết hợp các phản hồi từng phần không tương thích. Hãy dùng một lỗi stream rõ ràng trừ khi client và gateway triển khai một giao thức resume rõ ràng.
API tương thích OpenAI có đủ để di chuyển mà không cần thay đổi gì không?
Nó giảm thay đổi đối với SDK và hình dạng request, nhưng các nhóm vẫn cần xác minh các tham số được hỗ trợ, lỗi, sự kiện streaming, lời gọi công cụ, đầu ra có cấu trúc, tính toán token và hành vi mô hình.
