Giải thích API Gateway OpenAI bằng ngôn ngữ đơn giản

Ý nghĩa thường gặp của cụm từ

Khi ai đó tìm kiếm openai gateway api, họ thường muốn một trong ba thứ, và họ hiếm khi nói rõ điều đó. Phân loại chúng trước tiên giúp tránh nhiều nhầm lẫn, vì ba thứ này có nhiệm vụ và chi phí khác nhau.

Ý nghĩa	Nó làm gì	Lý do điển hình để muốn nó
Một proxy hoặc router do bạn vận hành	Nằm trong cơ sở hạ tầng của bạn, nhận yêu cầu theo định dạng OpenAI và chuyển tiếp chúng đến một hoặc nhiều nhà cung cấp upstream	Quản lý khóa chính, ghi log, dự phòng, theo dõi chi tiêu theo nhóm
Một dịch vụ lưu trữ đa nhà cung cấp	Bên thứ ba vận hành lớp chuyển hướng đó cho bạn và tính phí bạn cho dịch vụ đó	Một tài khoản cho nhiều mô hình, không cần duy trì máy chủ
Một endpoint tương thích	Nhà cung cấp phục vụ mô hình của riêng mình thông qua cùng định dạng yêu cầu và phản hồi	Tái sử dụng mã SDK hiện có với mô hình khác hoặc quy tắc nội dung khác

Từ gateway bắt nguồn từ mạng và quản lý API, nơi nó có nghĩa là cửa trước kiểm tra thông tin xác thực, áp dụng giới hạn và chuyển lưu lượng truy cập. Áp dụng cho mô hình ngôn ngữ, cửa trước nói ngôn ngữ định dạng được phổ biến bởi endpoint chat completions của OpenAI: một body JSON với tên mô hình và danh sách các thông điệp, một bearer token trong header, và một câu trả lời JSON với các lựa chọn và sử dụng token. Vì quá nhiều công cụ được viết cho định dạng đó, nhiều máy chủ hiện nay mô phỏng nó.

Vị trí phù hợp của trang web này

Trang web này thuộc hàng thứ ba, không phải hai hàng đầu. Đây là một API lưu trữ expose một mô hình trọng số mở thông qua định dạng yêu cầu OpenAI. Mô hình được vận hành bởi một nhà cung cấp độc lập và được tinh chỉnh để trả lời mà không từ chối nội dung cho người dùng trưởng thành hợp pháp. Bạn chọn nó bằng model ID uncensored.

Điều đó cần được giải thích rõ ràng, vì tên miền có thể gợi ý nhiều hơn những gì nó cung cấp:

• Đây không phải là API chính thức của OpenAI, Meta, Mistral, Qwen, DeepSeek, xAI, Google, Anthropic hoặc bất kỳ nhà cung cấp nào khác.
• Đây không phải là bộ định tuyến giữa các nhà cung cấp. Không có yêu cầu nào được chuyển tiếp đến mô hình của công ty khác. Mọi lệnh gọi đều đến cùng một mô hình.
• API này chỉ xử lý văn bản. Không có tạo ảnh, âm thanh hay video, không có embedding và không có fine-tuning.
• Nó hỗ trợ POST /v1/chat/completions và GET /v1/models, và không có gì hơn hai endpoint đó.

Những gì bạn nhận được là giao diện quen thuộc: streaming qua SSE, gọi hàm, chế độ JSON và các tham số sampling thông thường. Cửa sổ ngữ cảnh là 100.000 token, tính cả prompt và completion. Chi tiết có trong tài liệu API.

Tại sao sự tương thích giao diện là phần hữu ích

Phần lớn giá trị của ý tưởng endpoint tương thích là chi phí chuyển đổi của bạn giảm xuống gần như bằng không. Nếu mã của bạn hoạt động với một máy chủ theo kiểu OpenAI, việc trỏ nó sang máy chủ khác chỉ là thay đổi cấu hình thay vì viết lại. Bạn thay đổi URL và khóa, và bạn thay đổi tên mô hình.

Dưới đây là cách nó trông với curl, giúp dễ dàng thấy các thành phần di chuyển:

Copycurl https://api.openaigatewayapi.com/v1/chat/completions \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "uncensored",
    "messages": [{"role": "user", "content": "Say hello in three languages."}]
  }'

Và cùng một thứ thông qua Python SDK, nơi chỉ constructor biết về máy chủ:

Copyfrom openai import OpenAI

client = OpenAI(base_url="https://api.openaigatewayapi.com/v1", api_key="paste-your-key-here")

reply = client.chat.completions.create(
    model="uncensored",
    messages=[{"role": "user", "content": "Say hello in three languages."}],
)
print(reply.choices[0].message.content)

Đây cũng là lý do tại sao lớp gateway và endpoint tương thích bị nhầm lẫn. Từ phía client, chúng trông giống hệt nhau: cùng đường dẫn, cùng header, cùng JSON. Sự khác biệt nằm sau cánh cửa. Router quyết định mô hình nào trả lời mỗi yêu cầu. Endpoint tương thích luôn sử dụng mô hình mà nó lưu trữ.

Khi nào bạn cần một lớp gateway thực sự

Sự tương thích đơn thuần không mang lại cho bạn các tính năng mà mọi người đề cập khi nói về việc vận hành gateway. Nếu bất kỳ điều nào trong số này áp dụng cho bạn, hãy lên kế hoạch cho một lớp riêng biệt thay vì mong đợi nó từ một endpoint đơn lẻ:

• Fallback tự động. Thử lại với nhà cung cấp khác khi nhà cung cấp đầu tiên gặp lỗi.
• Ngân sách và khóa theo nhóm. Cấp nhiều khóa nội bộ, mỗi khóa có giới hạn riêng, từ một tài khoản upstream.
• Ghi log và ẩn dữ liệu yêu cầu. Ghi lại prompt và phản hồi tập trung, với các trường nhạy cảm bị loại bỏ.
• Routing theo nhiệm vụ. Mô hình rẻ cho phân loại, mô hình lớn hơn cho suy luận, được chọn bởi quy tắc của riêng bạn.
• Lưu trữ. Trả lại câu trả lời đã lưu trữ cho các prompt lặp lại.

Đó là những lý do tốt, và proxy tự lưu trữ thường là câu trả lời đúng cho một nhóm có nhiều nhà cung cấp. Nó cũng thêm một dịch vụ để triển khai, giám sát và bảo mật, đây là chi phí dễ bị đánh giá thấp cho một dự án nhỏ. Trang về các sự đánh đổi khi vận hành gateway LLM đi qua quyết định đó chi tiết hơn.

Hai ý tưởng kết hợp mà không gặp rắc rối. Proxy do bạn vận hành có thể liệt kê endpoint này làm một upstream, với uncensored làm mô hình nó chuyển tiếp đến. Trong thiết lập đó, hãy ghi log header phản hồi X-Request-Id ở phía bạn. Đó là giá trị để trích dẫn nếu bạn cần trợ giúp theo dõi một cuộc gọi cụ thể.

Các giới hạn và hành vi bạn nên lên kế hoạch

Một endpoint được lưu trữ đơn giản là đơn giản, nhưng nó có các cạnh bạn nên biết trước khi xây dựng dựa trên nó.

Các giới hạn về tốc độ và độ đồng thời

Khóa đầy đủ cho phép 8 yêu cầu đồng thời và 300 yêu cầu mỗi phút. Khóa dùng thử cho phép 2 yêu cầu đồng thời và 60 mỗi phút. Khi vượt quá giới hạn, API trả về HTTP 429 với mã lỗi rate_limited hoặc concurrency. Trong thời gian quá tải tạm thời, nó cũng trả về 429, với header Retry-After: 5. Một yêu cầu streaming giữ slot của nó cho đến khi stream kết thúc, vì vậy các thế hệ dài tính vào độ đồng thời trong toàn bộ thời gian của chúng.

Kích thước yêu cầu

Body tối đa là 8 MB. Trên thực tế, cửa sổ 100.000 token là giới hạn chặt chẽ hơn cho hầu hết các prompt. Nếu bạn nhồi lịch sử trò chuyện dài vào mọi cuộc gọi, hãy cắt giảm nó trước khi đạt đến bất kỳ giới hạn nào.

Khả năng quan sát

Mọi phản hồi đều bao gồm X-Request-Id và X-Balance-USD, cùng các header phản ánh yêu cầu và giới hạn độ đồng thời của bạn. Hãy ghi log chúng. Một gateway bạn xây dựng sau này có thể đọc cùng header đó, vì vậy bạn không mất gì khi bắt đầu với chúng.

Các câu hỏi cần hỏi về bất kỳ gateway hoặc API tương thích nào

Danh sách kiểm tra này áp dụng cho bạn dù bạn đang đánh giá dịch vụ này, một bộ định tuyến được lưu trữ hay một proxy tự lưu trữ. Hãy ghi lại các câu trả lời trước khi bạn cam kết viết mã cho bất kỳ cái nào trong số đó.

1. Mô hình nào trả lời? Một nhà cung cấp có tên, một mô hình trọng số mở trên máy chủ độc lập, hoặc bất kỳ mô hình nào mà bộ định tuyến chọn tại thời điểm đó.
2. Đơn vị giá là gì? Theo token, theo yêu cầu hoặc theo tháng. Ở đây là theo token, tín dụng trả trước.
3. Điều gì xảy ra khi có lỗi? Ở đây, các yêu cầu bị lỗi hoặc bị từ chối sẽ không bị tính phí.
4. Tính năng nào là thực? Hãy kiểm tra truyền phát (streaming), gọi hàm và chế độ JSON với các payload của chính bạn, không phải một prompt mẫu.
5. Prompt của bạn đi đâu? Ở đây chúng không được sử dụng để huấn luyện. Hãy đọc trang quyền riêng tư để biết chi tiết và so sánh nó với bất kỳ giải pháp thay thế nào.
6. Giới hạn cứng là gì? Độ đồng thời, số yêu cầu mỗi phút, kích thước body và cửa sổ ngữ cảnh.

Giá cả đủ đơn giản để bạn kiểm tra trong một phút: $0.15 cho 1M token đầu vào và $0.50 cho 1M token đầu ra, được trừ từ tín dụng trả trước không bao giờ hết hạn. trang giá có các mức nạp tiền. Nếu bạn muốn xem endpoint hoạt động như thế nào trước khi trả bất kỳ khoản phí nào, trang khóa API cho phép người dùng mới nhận tín dụng dùng thử $0.50 chỉ với một cú nhấp chuột, không cần thẻ.

Một cách khởi đầu hợp lý

Hãy giữ thử nghiệm ban đầu nhỏ. Nhận tín dụng dùng thử, gọi GET /v1/models để xác nhận khóa, sau đó gửi ba prompt thực từ ứng dụng của bạn với URL gốc đã được thay đổi. So sánh câu trả lời với những gì bạn nhận được hiện tại, kiểm tra các tiêu đề phản hồi và xem xét số lượng token trong usage. Nếu đầu ra phù hợp và các giới hạn phù hợp với lưu lượng truy cập của bạn, hãy di chuyển một tính năng ít rủi ro sang môi trường production trước khi làm phần còn lại. Các công cụ nội bộ, trợ lý soạn thảo và công việc nền là những ứng viên đầu tiên tốt, vì một điểm chưa hoàn thiện ở đó sẽ khiến bạn tốn kém ít hơn nhiều so với một điểm trong luồng tương tác với khách hàng.

Nếu sau này bạn quyết định cần định tuyến hoặc dự phòng, những gì bạn đã xây dựng sẽ không bị lãng phí. Định dạng yêu cầu vẫn giữ nguyên và một lớp proxy có thể được thêm vào phía trước mà không cần thay đổi mã ứng dụng.

Hướng dẫn khác

• API OpenAI cho Nhà phát triển: Sử dụng một endpoint tương thích
• Giá API Gateway OpenAI: Ví dụ chi phí thực tế
• Gateway LLM: Phân tích chi phí so với độ phức tạp