SLA của AI gateway có thể trông đơn giản cho đến khi xảy ra sự cố mô hình đầu tiên. Người mua thấy một tỷ lệ phần trăm khả dụng, một địa chỉ hỗ trợ và lời hứa rằng gateway sẽ định tuyến các yêu cầu. Đội ngũ sản xuất vẫn phải trả lời những câu hỏi khó hơn: điểm cuối nào được bao gồm, nhà cung cấp thượng nguồn nào đã thất bại, liệu phương án dự phòng có thay đổi hợp đồng mô hình không, bộ phận hỗ trợ cần bằng chứng gì và liệu có biện pháp khắc phục nào tự động không.
Sử dụng danh sách kiểm tra SLA của AI gateway này để biến ngôn ngữ của nhà cung cấp thành một tệp bằng chứng. Mục tiêu không phải là đàm phán bằng khẩu hiệu. Mục tiêu là biết SLA bao gồm những gì, loại trừ những gì, cách chứng minh việc định tuyến và dự phòng, và đội ngũ của bạn nên xem xét những gì trước khi gia hạn.
Cụ thể đối với Flatkey, Thỏa thuận mức độ dịch vụ công khai được kiểm tra vào ngày 6 tháng 7 năm 2026 cho biết phạm vi bao gồm là bảng điều khiển được lưu trữ, cổng API, định tuyến, đo lường và các dịch vụ tài khoản mà Flatkey trực tiếp vận hành. Nó nhắm đến 99,5% khả dụng hàng tháng cho các điểm cuối được bao gồm, loại trừ các sự cố ngừng hoạt động của nhà cung cấp mô hình AI bên thứ ba và các lỗi phía nhà cung cấp, yêu cầu khách hàng gửi ID yêu cầu, dấu thời gian, lỗi, điểm cuối, email tài khoản và tóm tắt tác động để được hỗ trợ, và không tự động tạo tín dụng trừ khi có một thỏa thuận bằng văn bản riêng quy định khác. Hãy coi đó là bằng chứng ban đầu, sau đó xác minh tài khoản, loại lưu lượng, chính sách dự phòng và quy trình hỗ trợ của bạn trước khi lưu lượng sản xuất phụ thuộc vào nó.
Trả lời nhanh: Các câu hỏi về SLA của AI Gateway
| Lĩnh vực SLA | Hỏi điều này trước khi ký hoặc gia hạn | Bằng chứng cần lưu giữ | |---|---|---| | Dịch vụ được bao gồm | Những chức năng nào của bảng điều khiển, cổng API, định tuyến, đo lường, tài khoản và hỗ trợ được bao gồm? | URL SLA hiện tại, lịch trình hợp đồng, danh sách điểm cuối và ảnh chụp màn hình có ghi ngày. | | Cách tính độ khả dụng | Độ khả dụng được đo bằng giám sát của nhà cung cấp, thăm dò của khách hàng, trạng thái công khai hay báo cáo hợp đồng? | Báo cáo độ khả dụng hàng tháng, nhật ký thăm dò, xuất sự cố và phương pháp tính toán. | | Các nhà cung cấp bên thứ ba | Các sự cố ngừng hoạt động của mô hình thượng nguồn, giới hạn tốc độ, hạn chế khu vực, thay đổi mô hình và lỗi phía nhà cung cấp có bị loại trừ không? | Liên kết trạng thái nhà cung cấp, nội dung lỗi mô hình, nhật ký định tuyến và văn bản loại trừ của nhà cung cấp. | | Định tuyến | Mô hình, nhà cung cấp, tài khoản, khu vực hoặc nhóm nào đã được thử đầu tiên? | ID yêu cầu, tuyến đường đã chọn, ID mô hình, họ điểm cuối, chủ sở hữu khóa và dấu thời gian. | | Phương án dự phòng | Lỗi nào kích hoạt hành vi thử lại, dự phòng, xếp hàng hoặc đóng khi lỗi? | Chính sách dự phòng, dấu vết định tuyến, số lần thử lại, mô hình cuối cùng và bằng chứng đầu ra được chấp nhận. | | Hỗ trợ | Cần gửi bằng chứng gì và áp dụng lộ trình mức độ nghiêm trọng nào? | Mẫu phiếu yêu cầu, ID yêu cầu, điểm cuối, dấu thời gian, lỗi, tóm tắt tác động và dòng thời gian phản hồi. | | Biện pháp khắc phục | Tín dụng dịch vụ là tự động, theo từng trường hợp hay chỉ có trong một thỏa thuận bằng văn bản riêng? | Điều khoản khắc phục của SLA, sửa đổi hợp đồng, yêu cầu tín dụng và phê duyệt tài chính. | | Gia hạn | Cần xem xét những gì trước kỳ hạn tiếp theo? | Sổ ghi chép sự cố, các trường hợp ngoại lệ dự phòng, kết quả hỗ trợ, sự kiện hạn ngạch, thay đổi giá cả và phê duyệt định tuyến. |
Câu trả lời thực tế về SLA của AI gateway là: tách biệt trách nhiệm của gateway khỏi trách nhiệm của nhà cung cấp thượng nguồn, sau đó kiểm tra tuyến đường. Nếu người mua không thể kiểm tra tuyến đường, phương án dự phòng, phiếu yêu cầu hỗ trợ và bằng chứng về độ khả dụng hàng tháng, thì SLA đó chưa sẵn sàng để quản trị sản xuất.
Tách biệt thời gian hoạt động của Gateway khỏi độ khả dụng của mô hình thượng nguồn
Câu hỏi đầu tiên về SLA của AI gateway là liệu nhà cung cấp đang cam kết về gateway, mô hình thượng nguồn hay kết quả cuối cùng cho người dùng cuối. Đó là những lớp khác nhau.
SLA công khai hiện tại của Flatkey làm rõ sự tách biệt này: các dịch vụ do Flatkey vận hành được bao gồm nằm trong phạm vi, trong khi các nhà cung cấp mô hình bên thứ ba, sự cố ngừng hoạt động của nhà cung cấp, giới hạn tốc độ của nhà cung cấp, thay đổi chính sách, hạn chế khu vực, hành vi của mô hình và các lỗi phía nhà cung cấp nằm ngoài SLA. Điều này đủ phổ biến trong việc mua gateway đến mức bộ phận mua sắm không bao giờ nên coi một tỷ lệ phần trăm thời gian hoạt động duy nhất là "tất cả các yêu cầu mô hình sẽ thành công".
Sử dụng sự phân chia này trong tệp bằng chứng:
| Lớp | Những gì có thể thất bại | Bằng chứng của người mua | |---|---|---| | Client và SDK | URL cơ sở sai, khóa sai, điểm cuối không được hỗ trợ, thời gian chờ quá thấp, lỗi phân tích cú pháp. | Cấu hình client, phiên bản SDK, nội dung yêu cầu, thời gian chờ và nhật ký cục bộ. | | Gateway | Xác thực, định tuyến, đo lường, điểm cuối gateway, bảng điều khiển, nhật ký sử dụng, dịch vụ tài khoản. | SLA của Gateway, ID yêu cầu, dấu vết định tuyến, trạng thái, bản ghi sử dụng và phiếu yêu cầu hỗ trợ. | | Nhà cung cấp thượng nguồn | Sự cố ngừng hoạt động của nhà cung cấp, hạn ngạch của nhà cung cấp, mô hình bị loại bỏ, chặn theo khu vực, từ chối chính sách, hành vi cụ thể của mô hình. | Trạng thái nhà cung cấp, trang hạn ngạch của nhà cung cấp, nội dung lỗi thượng nguồn, ID mô hình và quyết định dự phòng. | | Quy trình kinh doanh | Tác động đến người dùng, độ sâu hàng đợi, đầu ra bị suy giảm, bỏ lỡ mục tiêu nội bộ. | Dòng thời gian sự cố, loại lưu lượng bị ảnh hưởng, tóm tắt tác động đến khách hàng, quyết định khôi phục. |
Đây là lúc SLA của AI gateway trở nên có tính hoạt động. Người mua nên yêu cầu một dấu vết ở cấp độ định tuyến, không chỉ là một con số thời gian hoạt động hàng tháng.
Các câu hỏi về định tuyến và phương án dự phòng
Định tuyến là phần của SLA của AI gateway thường bị chỉ định thiếu chi tiết nhất. Một gateway có thể hỗ trợ nhiều mô hình và nhà cung cấp, nhưng độ tin cậy trong sản xuất phụ thuộc vào tuyến đường nào được phép cho mỗi loại lưu lượng.
Tài liệu chính thức về gateway từ các nhà cung cấp khác cho thấy tại sao các chi tiết lại quan trọng. Tài liệu về AI Gateway của Vercel mô tả việc định tuyến nhà cung cấp và các phương án dự phòng mô hình, bao gồm cả việc kiểm soát thứ tự định tuyến và hành vi dự phòng. Tài liệu về phương án dự phòng mô hình của họ nói rằng các bản sao lưu có thể được thử theo thứ tự khi một mô hình chính thất bại hoặc không khả dụng. Tài liệu về Pydantic AI Gateway mô tả các nhóm định tuyến nơi mức độ ưu tiên và trọng số quyết định việc chuyển đổi dự phòng hoặc cân bằng tải, với việc chuyển tiếp khi một thành viên có mức độ ưu tiên cao hơn không khả dụng, bị giới hạn tốc độ hoặc gặp lỗi. Đây là những ví dụ phân loại hữu ích, không phải là sự đảm bảo của Flatkey. Chúng cho thấy những câu hỏi mà người mua nên hỏi bất kỳ gateway nào, bao gồm cả Flatkey.
Sử dụng bảng định tuyến này trước khi phê duyệt phương án dự phòng tự động:
| Tín hiệu lỗi | Câu hỏi mặc định của người mua | Bằng chứng an toàn | |---|---|---| | Gateway 401 hoặc 403 | Khóa, tài khoản, môi trường hoặc phạm vi chính sách có bị sai không? | Chủ sở hữu khóa, môi trường, lỗi xác thực và bản ghi từ chối chính sách. | | Không tìm thấy mô hình | Mô hình được yêu cầu có tồn tại trong danh mục hiện tại cho tài khoản này không? | Hàng trong danh mục, ID mô hình, họ điểm cuối và bằng chứng ngày xuất bản hoặc ngày kiểm thử. | | Nhà cung cấp 429 | Hạn ngạch của tài khoản, khu vực, mô hình hoặc triển khai này đã hết chưa? | Trang hạn ngạch, nội dung lỗi từ phía upstream, dữ liệu retry-after và chính sách dự phòng. | | Nhà cung cấp 5xx hoặc hết thời gian chờ | Gateway có nên thử lại, chuyển sang tuyến đường cùng mô hình, xếp hàng đợi hay đóng kết nối khi lỗi? | Dấu vết định tuyến, số lần thử lại, ngưỡng hết thời gian chờ, kết quả cuối cùng và bản ghi chi phí. | | Giới hạn ngữ cảnh hoặc đầu vào không được hỗ trợ | Có cho phép dự phòng nếu mô hình dự phòng thay đổi ngữ cảnh, công cụ, thị giác hoặc hành vi phương tiện không? | Hợp đồng mô hình, kiểm thử tính năng, kiểm tra đầu ra được chấp nhận và sự chấp thuận của chủ sở hữu sản phẩm. | | Từ chối do chính sách hoặc an toàn | Một nhà cung cấp khác có được phép nhận cùng một yêu cầu không? | Ranh giới dữ liệu, sự chấp thuận của nhà cung cấp, phân loại prompt và xác nhận tuân thủ. | | Lỗi không xác định | Điều kiện dừng là gì? | Sổ tay xử lý sự cố, số lần thử tối đa, quy tắc đóng kết nối khi lỗi và chuyển cấp hỗ trợ. |
Bằng chứng mạnh mẽ nhất cho SLA của AI gateway là một dấu vết định tuyến nêu rõ tuyến đường bắt đầu, quy tắc dự phòng, tuyến đường cuối cùng và lý do mỗi lần chuyển đổi xảy ra.
Phương án dự phòng không phải lúc nào cũng giúp tăng độ tin cậy
Bộ phận mua sắm thường hỏi liệu gateway có phương án dự phòng tự động hay không. Các đội ngũ nền tảng nên trả lời bằng một câu hỏi thứ hai: dự phòng sang cái gì?
Việc tự động chuyển từ một tài khoản này sang một tài khoản khác cho cùng một mô hình đã được phê duyệt có thể hợp lý. Việc chuyển từ một họ mô hình này sang một họ mô hình khác có thể thay đổi chất lượng, cách xử lý dữ liệu, độ trễ, định dạng đầu ra, hành vi công cụ, chính sách hình ảnh hoặc video và chi phí. Một số lưu lượng truy cập nên được đóng kết nối khi lỗi vì phương án dự phòng ẩn có thể làm cho sự cố trở nên tồi tệ hơn.
Xác định phương án dự phòng theo loại lưu lượng truy cập:
| Loại lưu lượng truy cập | Trạng thái dự phòng | Tại sao | |---|---|---| | Trò chuyện với khách hàng | Chỉ sử dụng các tuyến đường tương đương đã được phê duyệt, hoặc trả về một lỗi có kiểm soát. | Chất lượng và an toàn đối với người dùng phải luôn có thể dự đoán được. | | Tóm tắt nội bộ | Thử lại, xếp hàng đợi, hoặc sử dụng một tuyến đường đã được phê duyệt có chi phí thấp hơn. | Có thể đánh đổi độ trễ để lấy chi phí và khả năng hoàn thành. | | Đánh giá và đo điểm chuẩn | Đóng kết nối khi lỗi. | Những thay đổi mô hình ẩn làm hỏng dữ liệu so sánh. | | Các công việc hàng loạt nhạy cảm về tài chính | Xếp hàng đợi hoặc yêu cầu phê duyệt trước khi dự phòng. | Việc thử lại và các mô hình dự phòng có thể làm tăng chi phí lên nhiều lần. | | Luồng công việc của agent với các công cụ | Chỉ dự phòng sau khi hành vi gọi công cụ đã được kiểm thử. | Lược đồ công cụ và hành vi streaming có thể khác nhau tùy theo nhà cung cấp. | | Lưu lượng truy cập được quản lý hoặc cô lập của khách hàng | Đóng kết nối khi lỗi trừ khi nhà cung cấp và khu vực dự phòng đã được phê duyệt trước. | Ranh giới dữ liệu và bằng chứng mua sắm quan trọng hơn việc hoàn thành tự động. |
Đây là bài kiểm thử do người mua sở hữu: chạy cùng một prompt qua tuyến đường chính và tuyến đường dự phòng được đề xuất, sau đó so sánh hình dạng phản hồi, nhật ký, chi phí, độ trễ, đầu ra được chấp nhận và bằng chứng hỗ trợ. Đừng coi SLA của AI gateway là hoàn chỉnh cho đến khi có bằng chứng về phương án dự phòng.
Các câu hỏi hỗ trợ cho gói bằng chứng
SLA hiện tại của Flatkey yêu cầu khách hàng liên hệ bộ phận hỗ trợ với email tài khoản, điểm cuối bị ảnh hưởng, ID yêu cầu nếu có, dấu thời gian, thông báo lỗi và tóm tắt tác động. Đó là một mẫu hữu ích cho bất kỳ quy trình hỗ trợ SLA nào của AI gateway.
Trước khi ra mắt, hãy tạo một gói hỗ trợ với các trường sau:
| Trường | Tại sao nó quan trọng | |---|---| | Email tài khoản và không gian làm việc | Giúp bộ phận hỗ trợ tìm đúng tenant, khóa và quyền lợi. | | Điểm cuối bị ảnh hưởng | Phân tách các sự cố về trò chuyện, phản hồi, tin nhắn, hình ảnh, video và bảng điều khiển. | | ID yêu cầu | Kết nối nhật ký ứng dụng với gateway và các dấu vết upstream. | | Dấu thời gian kèm múi giờ | Ngăn chặn độ khả dụng hàng tháng và cửa sổ sự cố bị trôi. | | ID mô hình và loại tuyến đường | Cho biết chính sách định tuyến và họ nhà cung cấp nào đã tham gia. | | Thông báo lỗi và mã trạng thái | Phân tách các lỗi xác thực, hạn ngạch, hết thời gian chờ, nhà cung cấp và trình phân tích cú pháp. | | Tóm tắt tác động | Giải thích người dùng bị ảnh hưởng, doanh thu, công việc, độ sâu hàng đợi hoặc luồng công việc nội bộ. | | Số lần thử lại từ phía khách hàng | Cho biết liệu các lần thử trùng lặp có làm tăng chi phí hoặc tải không. | | Hành động bắt buộc | Làm rõ liệu bạn cần chẩn đoán, vô hiệu hóa tuyến đường, xem xét tín dụng hay theo dõi hợp đồng. |
Liên kết gói hỗ trợ này với quy trình nhật ký kiểm toán việc sử dụng AI API của bạn. Nếu ID yêu cầu và bằng chứng định tuyến không có sẵn sau một sự cố, quy trình hỗ trợ sẽ trở thành một bài tập trí nhớ.
Các câu hỏi về biện pháp khắc phục và tín dụng
Phần biện pháp khắc phục của SLA của AI gateway rất quan trọng vì nó thường xác định những gì người mua thực sự có thể nhận lại. Mục tiêu 99,5% không có điều khoản tín dụng khác với một SLA cam kết có tín dụng dịch vụ tự động, yêu cầu thông báo bằng văn bản, các loại trừ và thời hạn yêu cầu bồi thường.
SLA công khai của Flatkey nói rằng không có tín dụng dịch vụ tự động, hoàn tiền, hình phạt hoặc bồi thường thiệt hại định trước trừ khi một thỏa thuận bằng văn bản riêng biệt cung cấp một biện pháp khắc phục khác. Bất kỳ điều chỉnh thiện chí, sửa đổi số dư hoặc khắc phục hỗ trợ nào đều được xử lý theo từng trường hợp cụ thể theo thỏa thuận người dùng và các chính sách hiện hành.
Điều đó không làm cho SLA trở nên vô dụng. Nó có nghĩa là bộ phận mua sắm nên đặt những câu hỏi đúng:
- SLA công khai có phải là toàn bộ thỏa thuận không, hay có một lịch trình riêng cho doanh nghiệp?
- Nếu có tín dụng, thời hạn yêu cầu bồi thường là bao lâu?
- Khách hàng phải cung cấp bằng chứng gì?
- Sự cố ngừng hoạt động của nhà cung cấp ngược dòng có bị loại trừ ngay cả khi cổng đã chọn nhà cung cấp đó không?
- Bảo trì theo lịch trình và các hành động bảo mật khẩn cấp có bị loại trừ không?
- Độ trễ, chất lượng mô hình, điều tiết và hành vi dự phòng có được bao gồm hay chỉ có tính khả dụng?
- Biện pháp khắc phục có áp dụng cho số dư trả trước, tín dụng hóa đơn, hoàn tiền, khắc phục hỗ trợ hoặc quyền chấm dứt hợp đồng không?
- Ai trong bộ phận tài chính phê duyệt yêu cầu bồi thường cuối cùng?
Câu trả lời nên nằm trong cùng một tệp nhà cung cấp với bản đánh giá rủi ro nhà cung cấp AI API. Bộ phận pháp lý và tài chính cần cùng một bằng chứng mà các kỹ sư nền tảng sử dụng trong quá trình xem xét sự cố.
Hạn ngạch, Giới hạn tốc độ và Các phụ thuộc của nhà cung cấp
SLA của cổng AI có thể hợp lệ trong khi một yêu cầu vẫn thất bại vì hạn ngạch của nhà cung cấp ngược dòng đã cạn kiệt. Đây là lý do tại sao bằng chứng về hạn ngạch cần có trong quá trình xem xét SLA.
Tài liệu về hạn ngạch Azure OpenAI của Microsoft cho biết các giới hạn token mỗi phút và yêu cầu mỗi phút được xác định theo khu vực, đăng ký và loại mô hình hoặc loại triển khai. Tài liệu AWS Bedrock cũng hướng các nhóm đến hạn ngạch dịch vụ cho tài nguyên Bedrock và lưu ý rằng suy luận mô hình được kiểm soát bởi hạn ngạch sử dụng token. Những thông tin thực tế này từ nhà cung cấp không phải là lời hứa của Flatkey. Chúng là lời nhắc nhở rằng cấu hình tài khoản ngược dòng có thể quyết định liệu phương án dự phòng có khả dụng trong một sự cố thực tế hay không.
Thêm các kiểm tra này vào tệp khởi chạy:
| Kiểm tra phụ thuộc | Bằng chứng | |---|---| | Phạm vi hạn ngạch ngược dòng | Khu vực, tài khoản hoặc đăng ký, mô hình, loại triển khai, TPM/RPM hoặc tương đương của nhà cung cấp. | | Phạm vi hạn ngạch cổng | Khóa, nhóm, môi trường, nhóm mô hình, giới hạn ngân sách và cửa sổ đặt lại. | | Ngân sách thử lại | Số lần thử lại tối đa, chính sách jitter/backoff và lan can chi phí. | | Dung lượng dự phòng | Hạn ngạch tuyến dự phòng, tính khả dụng của mô hình và sự chấp thuận của nhà cung cấp. | | Hành vi điều tiết | Mã lỗi, tín hiệu thử lại sau, leo thang hỗ trợ và xử lý phía người dùng. |
Nếu hạn ngạch không được đo lường bởi cùng một chủ sở hữu với định tuyến, việc xem xét SLA của cổng AI sẽ bỏ lỡ chế độ lỗi phổ biến nhất: tuyến tồn tại, nhưng tài khoản không thể hấp thụ lưu lượng sản xuất.
Đánh giá Staging của Flatkey
Đối với Flatkey, bằng chứng sản phẩm công khai được kiểm tra vào ngày 6 tháng 7 năm 2026 hỗ trợ một cổng AI API, một khóa API, URL cơ sở của bộ định tuyến tương thích OpenAI https://router.flatkey.ai/v1, khả năng hiển thị việc sử dụng và thanh toán theo định hướng bảng điều khiển, xem xét giá cả và định vị liên quan đến định tuyến. Ảnh chụp nhanh API giá trực tiếp trả về success: true, phiên bản giá a42d372ccf0b5dd13ecf71203521f9d2, 45 hàng mô hình, 48 nhà cung cấp, siêu dữ liệu điểm cuối được hỗ trợ cho tin nhắn Anthropic, Gemini generateContent, tạo hình ảnh, hoàn thành trò chuyện OpenAI và yêu cầu video, cộng với các trạng thái khả dụng là available và unknown_failure trên các hàng.
Chỉ sử dụng đó làm bằng chứng công khai đã ghi ngày. Nó không chứng minh biện pháp khắc phục SLA, cấp hỗ trợ, thành công của tuyến, đủ điều kiện dự phòng, tính khả dụng vĩnh viễn của mô hình, độ trễ, phạm vi tuân thủ hoặc giá cả cụ thể cho tài khoản của bạn.
Một đánh giá staging SLA của cổng AI Flatkey nên bao gồm:
- Mở trang giá hiện tại và chọn chính xác mô hình hoặc họ tuyến.
- Xác nhận hàng mô hình và họ điểm cuối trong tài khoản hoặc bảng điều khiển của bạn.
- Chạy một yêu cầu rủi ro thấp thông qua
https://router.flatkey.ai/v1. - Ghi lại ID yêu cầu, ID mô hình, điểm cuối, dấu thời gian, trạng thái, đơn vị sử dụng, bằng chứng chi phí và chủ sở hữu khóa.
- Chạy một thử nghiệm lỗi đã được phê duyệt: mô hình xấu, giới hạn hạn ngạch, hết thời gian chờ hoặc dự phòng bị vô hiệu hóa.
- Xác nhận nơi bằng chứng hỗ trợ xuất hiện trong nhật ký.
- Quyết định loại lưu lượng nào có thể dự phòng và loại nào phải thất bại đóng.
- Thêm các trường gói hỗ trợ vào sổ tay sự cố.
- Lưu SLA hiện tại, giá cả, bằng chứng tuyến và đường dẫn hỗ trợ trong thư mục bằng chứng nhà cung cấp.
Khi bằng chứng đó tồn tại, bộ phận nền tảng, mua sắm và tài chính có thể đánh giá cùng một tệp thay vì tranh cãi từ ảnh chụp màn hình.
Danh sách kiểm tra Kích hoạt Gia hạn
Đừng chỉ xem xét SLA của cổng AI một lần. Thêm các yếu tố kích hoạt gia hạn để tệp của người mua luôn được cập nhật.
| Kích hoạt | Cần kiểm tra lại những gì | |---|---| | Cập nhật trang SLA hoặc hợp đồng | Phạm vi, loại trừ, biện pháp khắc phục, quy trình hỗ trợ và chi tiết liên hệ. | | Họ mô hình mới | Điểm cuối, nhà cung cấp, hạn ngạch, ranh giới dữ liệu, đơn vị giá và chính sách dự phòng. | | Loại lưu lượng sản xuất mới | Tư thế chuyển đổi dự phòng, mức độ nghiêm trọng của hỗ trợ và sự chấp thuận của chủ sở hữu. | | Sự cố hoặc suýt xảy ra sự cố | Truy vết tuyến, dòng thời gian hỗ trợ, tác động đến người dùng, tác động chi phí và hành động phòng ngừa. | | Thay đổi hạn ngạch nhà cung cấp | Dung lượng dự phòng, hành vi điều tiết và phân bổ lưu lượng. | | Thay đổi giá | Chi phí cấp yêu cầu, ngân sách thử lại, chi phí mô hình dự phòng và ngưỡng tài chính. | | Đánh giá bảo mật hoặc tuân thủ | Phạm vi ghi nhật ký, lưu giữ, sự chấp thuận của nhà cung cấp và xem xét quyền truy cập. |
Liên kết danh sách kiểm tra này trở lại danh sách kiểm tra cổng AI API doanh nghiệp. SLA là một phần của gói bằng chứng doanh nghiệp, không phải là một huy hiệu tin cậy độc lập.
Những sai lầm phổ biến
| Lỗi | Tại sao lại gây hại | Cách kiểm tra tốt hơn |
|---|---|---|
| Coi mục tiêu thời gian hoạt động của gateway là đảm bảo thành công của mô hình | Các nhà cung cấp thượng nguồn, hạn ngạch, chính sách và hành vi của mô hình có thể bị loại trừ. | Tách biệt bằng chứng của gateway, nhà cung cấp, máy khách và quy trình nghiệp vụ. |
| Hỏi liệu có phương án dự phòng hay không, nhưng không hỏi nó chuyển sang cái gì | Các mô hình dự phòng có thể thay đổi đầu ra, ranh giới dữ liệu, tính năng và chi phí. | Phê duyệt phương án dự phòng theo loại lưu lượng và hợp đồng mô hình. |
| Không lưu giữ ID yêu cầu | Bộ phận hỗ trợ không thể kết nối nhật ký của khách hàng với nhật ký định tuyến một cách đáng tin cậy. | Thêm việc ghi lại ID yêu cầu vào mọi tuyến sản xuất. |
| Bỏ qua phạm vi hạn ngạch | Một tuyến dự phòng có thể tồn tại nhưng vẫn bị điều tiết trong thời gian lưu lượng cao điểm. | Lưu trữ bằng chứng về hạn ngạch của nhà cung cấp thượng nguồn và gateway cùng nhau. |
| Cho rằng tín dụng là tự động | Nhiều SLA yêu cầu một thỏa thuận riêng, quy trình yêu cầu bồi thường hoặc xem xét từng trường hợp cụ thể. | Lưu các điều khoản khắc phục và người sở hữu yêu cầu bồi thường trước khi ra mắt. |
| Chỉ xem xét tại thời điểm mua | Danh mục mô hình, hạn ngạch và các kênh hỗ trợ thay đổi. | Thêm các trình kích hoạt gia hạn và kiểm tra lại dựa trên sự cố. |
Câu hỏi thường gặp
SLA của AI gateway là gì?
SLA của AI gateway xác định mục tiêu về tính sẵn sàng, phạm vi, các trường hợp loại trừ, quy trình hỗ trợ và các biện pháp khắc phục cho các dịch vụ gateway mà nhà cung cấp vận hành. Nó có thể không bao gồm các sự cố ngừng hoạt động của nhà cung cấp mô hình bên thứ ba, giới hạn hạn ngạch, hành vi của mô hình, cấu hình của khách hàng hoặc mọi kết quả của phương án dự phòng.
SLA của AI gateway có đảm bảo mọi yêu cầu mô hình đều thành công không?
Không. SLA của AI gateway có thể bao gồm tính sẵn sàng của gateway nhưng loại trừ các lỗi của nhà cung cấp thượng nguồn, giới hạn tốc độ của nhà cung cấp, thay đổi chính sách, hành vi của mô hình, thông tin xác thực của khách hàng, bảo trì theo lịch trình hoặc các vấn đề từ phía khách hàng. Hãy kiểm tra văn bản về các trường hợp loại trừ và bằng chứng định tuyến.
Bộ phận thu mua nên hỏi gì về phương án dự phòng của mô hình?
Bộ phận thu mua nên hỏi những lỗi nào kích hoạt phương án dự phòng, những mô hình hoặc nhà cung cấp nào được phê duyệt làm phương án dự phòng, liệu phương án dự phòng có thay đổi cách xử lý dữ liệu hoặc hành vi đầu ra hay không, cách tính phí cho các lần thử lại và nơi lưu trữ bằng chứng định tuyến sau một sự cố.
Bộ phận hỗ trợ nên nhận được bằng chứng gì trong một sự cố SLA?
Bộ phận hỗ trợ nên nhận được email tài khoản, điểm cuối bị ảnh hưởng, ID yêu cầu, dấu thời gian, thông báo lỗi, ID mô hình, loại tuyến, tóm tắt tác động và hành vi thử lại của khách hàng. SLA công khai của Flatkey hiện yêu cầu một số trường này, bao gồm điểm cuối, ID yêu cầu, dấu thời gian, lỗi và tóm tắt tác động.
Tín dụng dịch vụ có được áp dụng tự động không?
Không phải lúc nào cũng vậy. SLA công khai của Flatkey nêu rõ rằng tín dụng dịch vụ, hoàn tiền, tiền phạt hoặc các khoản bồi thường thiệt hại định trước sẽ không được tạo tự động trừ khi có một thỏa thuận bằng văn bản riêng quy định khác. Người mua nên xác nhận điều khoản khắc phục, thời hạn yêu cầu bồi thường và quy trình phê duyệt.
Các nhóm nên xem xét SLA của AI gateway bao lâu một lần?
Hãy xem xét SLA của AI gateway tại thời điểm mua, gia hạn, thay đổi tuyến chính, có họ mô hình mới, loại lưu lượng sản xuất mới, thay đổi giá, thay đổi hạn ngạch và sau mỗi sự cố nghiêm trọng hoặc suýt xảy ra sự cố.
Khuyến nghị cuối cùng
SLA của AI gateway chỉ hữu ích khi nó có thể kiểm tra được. Bắt đầu với SLA công khai hoặc theo hợp đồng, tách biệt phạm vi của gateway khỏi phạm vi của nhà cung cấp thượng nguồn, chạy các bài kiểm tra định tuyến và phương án dự phòng, lưu ID yêu cầu, xác định bằng chứng hỗ trợ và thêm các trình kích hoạt gia hạn.
Flatkey có thể giúp các nhóm tập trung hóa việc truy cập mô hình, định tuyến, xem xét giá cả và bằng chứng sử dụng đằng sau một quy trình gateway duy nhất. Trước khi triển khai sản xuất, hãy xác minh mô hình chính xác, điểm cuối, hành vi định tuyến, quy trình hỗ trợ và bằng chứng SLA cho tài khoản của bạn. Sau đó nhận một khóa khi bạn đã sẵn sàng để kiểm tra quy trình SLA của AI gateway với lưu lượng dàn dựng thực tế.
