API trung gian là gì: nguyên lý hoạt động, rủi ro thường gặp và danh sách chọn lựa
Nhiều nhà phát triển lần đầu tiếp xúc với "API relay" chỉ biết đổi địa chỉ và khóa để gọi LLM, nhưng không rõ những gì xảy ra ở giữa. Bài viết này sẽ phân tích một yêu cầu từ góc độ vận hành, làm rõ ba việc: chuyển tiếp, ánh xạ khóa và tính phí, liệt kê ba lỗi phổ biến nhất cùng danh sách kiểm tra, và đưa ra hai lệnh để bạn tự kiểm chứng.
Tóm tắt
- Bản chất của relay là "chuyển tiếp proxy + ánh xạ khóa + ghi công suất sử dụng". Yêu cầu của bạn sẽ đi qua thêm một bước, và độ ổn định cũng như bảo mật phụ thuộc vào bước này.
- Ba loại lỗi thường gặp: lưu khóa không đúng, đầu ra không phải mô hình bạn nghĩ, quy tắc giới hạn tốc độ nằm ngoài tài liệu.
- Khi chọn dịch vụ, bạn đừng chỉ nhìn giá đơn, mà hãy xem trước danh sách mô hình có thể truy vấn, mã lỗi có chuẩn không, hạn mức và giới hạn tốc độ có được ghi rõ không.
- Sau khi có khóa, hãy chạy thử /v1/models và một yêu cầu nhỏ, trong mười phút bạn có thể loại bỏ phần lớn vấn đề.
Đường đi của một yêu cầu qua trung gian
Trước hết làm rõ thuật ngữ. “API trung gian” là một gateway công khai định dạng chuẩn, nằm giữa chương trình của bạn và backend chạy mô hình thực sự. Mã của bạn vẫn gửi yêu cầu theo định dạng OpenAI, chỉ cần trỏ base_url đến địa chỉ gateway và dùng khóa do gateway cấp.
Gateway thường làm ba việc trong bước này.
- Chuyển tiếp yêu cầu: xác thực định dạng thân yêu cầu, bổ sung tham số mặc định nếu cần, rồi chuyển yêu cầu cho backend; nội dung backend trả về (bao gồm các phân đoạn SSE truyền phát) được trả lại cho bạn nguyên vẹn hoặc xử lý nhẹ.
- Ánh xạ khóa: Bạn nắm giữ khóa do gateway phát hành, nó chỉ có ý nghĩa trong gateway. Gateway dựa vào đó để nhận diện bạn, số dư và các mô hình bạn có thể gọi; thông tin xác thực thực sự giao tiếp với backend luôn nằm trong gateway, không xuất hiện trong mã của bạn.
- Tính phí và giới hạn tốc độ: sau mỗi yêu cầu, gateway trừ số dư dựa trên số token đầu vào/đầu ra trong usage nhân với đơn giá, đồng thời đếm số yêu cầu mỗi phút theo khóa và trả về 429 nếu vượt quá.
Ghép ba việc này lại, bạn sẽ hiểu vì sao trải nghiệm trung gian khác nhau rất nhiều: cách triển khai lớp chuyển tiếp quyết định độ trễ và tính ổn định của truyền phát, lớp khóa quyết định phạm vi thiệt hại khi bị lộ, lớp tính phí quyết định hóa đơn có minh bạch và đối chiếu được không.
Khác biệt với dịch vụ kết nối trực tiếp một mô hình
Dịch vụ kết nối trực tiếp là khi bạn gửi yêu cầu trực tiếp đến tên miền chính thức của nhà cung cấp mô hình, thường một tài khoản tương ứng với một bộ mô hình, một quy tắc tính phí và một tài liệu. Dịch vụ trung gian có hai dạng phổ biến, khác nhau ở “phía sau kết nối những gì”.
| Kích thước | Kết nối trực tiếp dịch vụ đơn | Trung gian tổng hợp | Trung gian đơn mô hình |
|---|---|---|---|
| Số lượng mô hình | Vài mô hình của nhà cung cấp | Cả chục đến hàng trăm | Một |
| Định dạng endpoint | Mỗi nhà cung cấp một định dạng | Thống nhất tương thích OpenAI | Tương thích OpenAI |
| Độ khó gỡ lỗi | Thấp nhất, chuỗi ngắn nhất | Cao nhất, ánh xạ tên mô hình phức tạp | Thấp, chỉ một mô hình |
| Kịch bản phù hợp | Dùng ổn định một nhà cung cấp | Cần đổi mô hình liên tục để so sánh | Mô hình cố định, hướng đến khả năng dự đoán |
Nếu công việc của bạn chỉ dựa vào một mô hình, lợi ích của tổng hợp sẽ không phát huy, mà còn phải chịu rủi ro “mô hình này thực chất là ai”. Ngược lại, nếu bạn đổi mô hình mỗi tuần để so sánh, dạng tổng hợp sẽ tiết kiệm nhiều công sức tích hợp. Không có优劣 tuyệt đối, quan trọng là bạn thuộc nhóm nào.
Trang này thuộc dạng cuối cùng: chỉ cung cấp một mô hình, id mô hình là uncensored, endpoint là hoàn thành hội thoại tương thích OpenAI. Bạn có thể đọc tiếp Chi phí và sự đánh đổi của API AI không giới hạn để thảo luận về sự đánh đổi và chi phí này.
Ba loại rủi ro thường gặp nhất
Bảo mật khóa
Khóa trung gian giống như một thẻ nạp tiền, ai có đều chi được số dư của bạn. Các đường rò rỉ thường gặp: viết khóa vào mã giao diện người dùng, commit vào kho công khai, dán vào ticket hoặc ảnh chụp nhóm. Nên chỉ đặt khóa trong biến môi trường máy chủ, giao diện người dùng luôn gọi qua backend của bạn; khi nghi ngờ bị lộ hãy đặt lại ngay, khóa cũ phải mất hiệu lực ngay lập tức. Đồng thời xem dịch vụ có cho phép bạn tự đặt lại không, và sau khi đặt lại khóa cũ có mất hiệu lực ngay hay “chỉ hết hạn sau vài giờ”.
Mô hình bị thay thế
Đây là vấn đề được thảo luận nhiều nhất trong các dịch vụ tổng hợp: bạn yêu cầu A nhưng nhận lại B rẻ hơn. Khó có thể phán đoán qua tài liệu, bạn chỉ có thể xác minh qua hành vi. Bạn có thể cố định một bộ câu hỏi nhỏ có đáp án chuẩn, cố định temperature để kiểm tra lặp lại, quan sát xem phong cách đầu ra có ổn định không; hoặc yêu cầu /v1/models để xem danh sách có khớp với trang tính phí không. Tên mô hình mơ hồ, cùng một tên nhưng biểu hiện khác nhau ở các thời điểm khác nhau đều đáng bị nghi ngờ.
Giới hạn tốc độ không minh bạch
Một số dịch vụ chỉ ghi "sử dụng hợp lý" trong tài liệu, nhưng thực tế giảm tốc độ hoặc cắt yêu cầu khi cao điểm, khiến chương trình của bạn thỉnh thoảng bị quá thời gian chờ. Cách làm chuyên nghiệp là ghi rõ số lượng yêu cầu mỗi phút cho mỗi khóa, trả về mã 429 chuẩn khi vượt quá giới hạn thay vì để kết nối treo. Khi chọn dịch vụ, bạn nhất định phải hỏi rõ: giới hạn tốc độ tính theo khóa hay theo tài khoản, khi vượt quá sẽ trả về mã gì, khi hết tín dụng sẽ trả về mã lỗi độc lập nào.
Danh sách kiểm tra khi chọn dịch vụ trung chuyển
Bạn có thể sao chép danh sách này vào tài liệu đánh giá của mình và tích chọn từng mục.
- Dịch vụ có cung cấp
GET /v1/modelscông khai để trả về danh sách mô hình và giá cả khớp với trang định giá không? - Phản hồi lỗi có phải là JSON có cấu trúc, bao gồm code và message, và có phân biệt rõ 401, 402, 429, 503 không?
- Giới hạn số lượng yêu cầu mỗi phút cho mỗi khóa API có được ghi rõ trong tài liệu hay chỉ được thông báo qua bộ phận chăm sóc khách hàng?
- Độ dài cửa sổ ngữ cảnh, số token tối đa cho một lần xuất và kích thước yêu cầu có được quy định bằng các con số cụ thể không?
- Chi phí có được trừ chính xác theo số token trong usage không và bạn có thể kiểm tra số dư bất cứ lúc nào không?
- Số dư trả trước có hết hạn không? Thời hạn sử dụng của tín dụng dùng thử có được ghi rõ không?
- Bạn có thể tự đặt lại khóa API không và khóa cũ có ngừng hoạt động ngay lập tức không?
- Dịch vụ có hỗ trợ truyền phát (streaming) không và phản hồi cuối cùng có bao gồm thống kê usage để bạn dễ dàng đối chiếu số liệu không?
- Có tuyên bố rõ ràng bằng một câu về việc prompt có được sử dụng để huấn luyện mô hình không?
- Các khả năng không được hỗ trợ (ví dụ: vector, hình ảnh, giọng nói) có được ghi rõ ràng hay được mô tả mập mờ?
Mục tiêu 10 điểm là không thực tế, nhưng nếu bạn không thể trả lời được hai trong năm mục đầu tiên, bạn nên dùng thử với số tiền nhỏ trước khi nạp một khoản lớn.
Xác minh cơ bản trong 10 phút sau khi nhận khóa API
Bất kể bạn chọn dịch vụ nào, bạn nên dành 10 phút để thực hiện xác minh cơ bản trước khi đưa vào sử dụng. Bước đầu tiên là liệt kê danh sách mô hình và xác nhận id trả về khớp với kỳ vọng của bạn:
curl -s https://api.llmzhongzhuan.com/v1/models \
-H "Authorization: Bearer $API_KEY"
Bước thứ hai là gửi một yêu cầu nhỏ và quan sát xem trường usage trong phản hồi có tồn tại và số lượng có hợp lý không. Ví dụ dưới đây cố tình yêu cầu mô hình nhắc lại ngày tháng để quan sát xem nó có bịa ra thông tin mà nó không thể biết được hay không. Đây là một bài kiểm tra hành vi sơ bộ, không phải là đánh giá nghiêm ngặt:
curl -s https://api.llmzhongzhuan.com/v1/chat/completions \
-H "Authorization: Bearer $API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "uncensored",
"messages": [{"role": "user", "content": "用一句话介绍你自己,然后复述今天的日期是几号。"}],
"max_tokens": 200
}'
Bạn nên đưa hai bước này vào kịch bản triển khai của mình và chạy lại mỗi khi thay đổi khóa API hoặc dịch vụ. Nếu phản hồi không có usage hoặc số lượng usage không khớp rõ ràng với độ dài đầu vào, điều đó cho thấy tính minh bạch về chi phí có vấn đề và bạn cần làm rõ trước khi nạp số tiền lớn. Để tìm hiểu cách tích hợp vào các khung công cụ khác nhau, bạn có thể xem hướng dẫn cấu hình khung công cụ.
Các tham số của trang web này để bạn đối chiếu với danh sách kiểm tra
Dưới đây là các tham số thực tế của trang web này để bạn dễ dàng đối chiếu với danh sách kiểm tra ở trên mà không cần phải lật qua lật lại tài liệu.
- Địa chỉ endpoint:
https://api.llmzhongzhuan.com/v1, hỗ trợPOST /v1/chat/completionsvàGET /v1/models, xác thực sử dụng khóa Bearer. - Chỉ có một mô hình với id
uncensored; chỉ hỗ trợ văn bản, không có vector, hình ảnh, giọng nói, video và fine-tuning. - Cửa sổ ngữ cảnh tổng cộng 100,000 token (bao gồm đầu vào và đầu ra),
max_tokensmặc định là 2048, tối đa mỗi lần là 32,000; kích thước yêu cầu không vượt quá 8 MB. - Mỗi khóa được giới hạn 300 yêu cầu mỗi phút, vượt quá sẽ trả về 429; mã 503 với upstream_busy nghĩa là bạn chỉ cần thử lại sau; khi hết tín dụng hoặc hết thời gian dùng thử sẽ trả về 402 với no_credit.
- Giá là 0,25 USD cho mỗi triệu token đầu vào và 1,00 USD cho mỗi triệu token đầu ra, nạp tiền trả trước, không có gói đăng ký, số dư không bao giờ hết hạn.
- Prompt của bạn sẽ không được sử dụng để huấn luyện mô hình.
Các con số cụ thể vui lòng tham khảo trang định giá và tài liệu. Tài khoản mới có tín dụng dùng thử 0,50 USD, có hiệu lực trong 7 ngày, khi đăng ký không cần cung cấp thông tin thanh toán, bạn có thể sử dụng ngay để hoàn tất quy trình xác minh ở trên.
Câu hỏi thường gặp
API trung gian và gọi trực tiếp endpoint chính thức, điểm khác biệt lớn nhất là gì?
Relay thêm một lớp gateway giữa bạn và mô hình, chịu trách nhiệm chuyển tiếp, phát lại khóa và tính phí. Chuỗi liên kết dài hơn mang lại định dạng giao diện thống nhất và cách tính phí linh hoạt hơn, nhưng cái giá bạn phải trả là phải tin tưởng nhiều hơn vào độ ổn định và sự trung thực của lớp này.
Làm thế nào để biết dịch vụ trung gian có đổi mô hình ngầm không?
Sử dụng cùng một câu hỏi và temperature cố định để kiểm tra xem đầu ra có ổn định không, đồng thời đối chiếu danh sách /v1/models với trang định giá. Với dịch vụ chỉ có một mô hình, loại rủi ro này tương đối nhỏ hơn vì chỉ có một id duy nhất.
Làm gì khi khóa API trung gian bị lộ?
Bạn hãy ngay lập tức đặt lại khóa trong bảng điều khiển và xác nhận khóa cũ có mất hiệu lực ngay lập tức hay không. Sau này, bạn chỉ nên đặt khóa trong biến môi trường của máy chủ, còn phía client sẽ chuyển tiếp qua backend của chính bạn.
Khi chọn dịch vụ trung gian, bạn nên xem xét những mục nào trước tiên?
Trước tiên hãy xem liệu danh sách mô hình có thể truy vấn công khai không, mã lỗi có chuẩn không và giới hạn tốc độ mỗi phút có được ghi rõ không, sau đó mới xem độ dài ngữ cảnh và thời hạn hết hạn của số dư. Đơn giá nên được so sánh sau các yếu tố đó.
Nên dùng bao nhiêu tín dụng để kiểm tra là an toàn?
Hãy sử dụng tín dụng dùng thử hoặc số dư nhỏ để chạy thử qua /v1/models và một vài yêu cầu điển hình, sau đó mới tăng dần mức sử dụng. Không nên nạp một khoản lớn ngay từ đầu.
Chỉ cần điền biểu mẫu để lấy khóa API
Tạo tài khoản, sao chép khóa API và sửa đổi Base URL. Cấu hình rất đơn giản.