Khả năng quan sát AI API là thứ giúp một đội ngũ kỹ thuật tái dựng lại sự cố định tuyến mô hình mà không cần đoán mò. Một người dùng báo cáo timeout, một mô hình dự phòng trả lời khác đi, một nhà cung cấp trả về 429, hoặc chi phí tăng vọt sau khi chuyển upstream. Việc đánh giá sự cố cần nhiều hơn một prompt thô và một mã trạng thái. Nó cần một bản ghi log hiển thị request, route, chuỗi retry, mô hình được chọn, hồ sơ độ trễ, mức sử dụng, chi phí và các kiểm soát quyền riêng tư đối với những gì đã được lưu.
Hướng dẫn này là một danh sách kiểm tra ở mức trường dữ liệu cho các log khả năng quan sát AI API trong các sự cố định tuyến. Nó được viết cho các đội sử dụng AI gateway, bộ định tuyến đa nhà cung cấp, hoặc lớp tương thích, nơi một request ứng dụng có thể đi qua nhiều đường upstream khả dĩ. Mục tiêu không phải là lưu mọi prompt mãi mãi. Mục tiêu là giữ đủ siêu dữ liệu để chứng minh điều gì đã xảy ra trong khi vẫn kiểm soát được đầu vào nhạy cảm, đầu ra, tham số công cụ, và mã định danh khách hàng.
Flatkey phù hợp với vấn đề này vì nội dung sản phẩm công khai của họ tập trung vào một API key duy nhất, một base URL tương thích OpenAI tại https://router.flatkey.ai/v1, hóa đơn hợp nhất, và một dashboard cho key, mức sử dụng, và định tuyến. Flatkey cũng đề cập đến việc tự động chuyển đổi và cân bằng tải giữa các tài khoản upstream. Những tính năng độ tin cậy đó chỉ thực sự hữu ích khi các log có thể trả lời một câu hỏi định tuyến sau sự việc.
Khả năng quan sát AI API bắt đầu từ các câu hỏi về sự cố
Trước khi chọn các trường dữ liệu, hãy xác định những câu hỏi mà người chỉ huy sự cố phải trả lời. Với định tuyến mô hình, khả năng quan sát AI API nên giúp trả lời các câu hỏi này từ một bản ghi yêu cầu hoặc một trace được liên kết:
- Ứng dụng, môi trường, nhóm, khóa, quy trình làm việc và chủ sở hữu an toàn cho khách hàng nào đã gửi yêu cầu?
- Nhóm endpoint nào, mô hình được yêu cầu nào, chính sách định tuyến nào và quy tắc dự phòng nào đã được áp dụng tại thời điểm yêu cầu?
- Nhà cung cấp, mô hình, tài khoản upstream nào hoặc tuyến nào thực sự đã phục vụ phản hồi?
- Yêu cầu có được thử lại, chuyển sang tuyến khác, giới hạn tốc độ, xếp hàng, chặn hay hủy bỏ không?
- Mã trạng thái nào, lớp lỗi của nhà cung cấp, header giới hạn tốc độ, timeout hoặc sự kiện luồng nào đã làm thay đổi kết quả?
- Có bao nhiêu token đầu vào, đầu ra, được lưu trong cache và token suy luận đã được tính, và tuyến đó có chi phí bao nhiêu?
- Các kiểm soát quyền riêng tư đã lưu payload thô, payload đã che giấu, chỉ metadata, hay không có mục log nào?
Nếu một log không thể trả lời những câu hỏi đó, nhóm sẽ lấp khoảng trống bằng trí nhớ từ Slack, ảnh chụp màn hình và ticket hỗ trợ từ nhà cung cấp. Điều đó làm chậm việc khắc phục và khiến các thay đổi tuyến trong tương lai khó được tin cậy hơn.
Danh sách kiểm tra nhật ký sự cố định tuyến mô hình
Bảng dưới đây là tài sản cốt lõi về khả năng quan sát API AI cho bài viết này. Hãy dùng nó như một danh sách kiểm tra triển khai cho nhật ký LLM API, nhật ký gateway hoặc sự kiện kho dữ liệu.
| Nhóm trường | Các trường cần ghi nhận | Vì sao quan trọng trong một sự cố định tuyến | Ghi chú về quyền riêng tư |
|---|---|---|---|
| Correlation IDs | Mã yêu cầu ứng dụng, X-Client-Request-Id, x-request-id của nhà cung cấp, W3C traceparent, ID nhật ký gateway, ID sự kiện. |
Kết nối lỗi mà người dùng nhìn thấy, quyết định của gateway, yêu cầu tới nhà cung cấp, trace span và ticket hỗ trợ. | Dùng ID không có ngữ nghĩa. Không mã hóa email, IP, tên tenant hoặc văn bản prompt vào các trường trace. |
| Tenant và chủ sở hữu | Dự án, môi trường, ID hoặc hash của API key, nhóm, quy trình, ID tài khoản an toàn cho khách hàng, trung tâm chi phí. | Cho thấy ai bị ảnh hưởng và ai sở hữu hạn ngạch, chi phí và việc khắc phục. | Ưu tiên ID nội bộ ổn định thay vì tên khách hàng thô hoặc email người dùng. |
| Route được yêu cầu | Họ endpoint, model được yêu cầu, ưu tiên nhà cung cấp, chính sách định tuyến, chính sách fallback, phiên bản bí danh model, phiên bản danh mục/giá. | Tái tạo lại điều client đã yêu cầu và những gì router được phép làm tại thời điểm đó. | Không đưa prompt vào đối tượng route trừ khi chế độ debug đã được phê duyệt riêng đang hoạt động. |
| Route được chọn | Nhà cung cấp cuối cùng, model cuối cùng, tài khoản hoặc kênh upstream, khu vực nếu liên quan, lý do quyết định route, ID quy tắc chính sách. | Chứng minh liệu model chính có phục vụ phản hồi hay một đường dự phòng đã thay đổi hành vi hoặc chi phí. | ID tài khoản nên là tham chiếu nội bộ, không phải bí mật của nhà cung cấp hay thông tin xác thực đầy đủ. |
| Chuỗi retry và fallback | Chỉ số lần thử, số lần retry, nhà cung cấp/model trước đó, lớp lỗi, mã trạng thái, đích fallback, kết quả cuối cùng. | Ngăn retry mù quáng và cho thấy thang failover có hoạt động như thiết kế hay không. | Lưu lớp lỗi và các trích đoạn an toàn. Tránh lưu toàn bộ thân lỗi từ nhà cung cấp nếu chúng có thể lặp lại nội dung prompt. |
| Độ trễ và streaming | Thời điểm bắt đầu yêu cầu, thời lượng gateway, thời lượng nhà cung cấp, thời gian đến token/chunk đầu tiên, stream đã bắt đầu, stream đã hoàn tất, lý do hủy, client ngắt kết nối. | Tách riêng độ trễ của nhà cung cấp, thời gian định tuyến của gateway, tình trạng nghẽn streaming và hủy bỏ từ phía client. | Các chunk streaming là nội dung. Theo mặc định chỉ ghi log metadata thời gian và chỉ ghi nội dung trong chế độ debug được quản lý. |
| Sử dụng và chi phí | Số token đầu vào, token đầu ra, token được cache, token suy luận, đơn vị ảnh/video nếu liên quan, số lượng yêu cầu, hạng mục, chi phí ước tính hoặc cuối cùng. | Giải thích tác động ngân sách khi fallback chuyển lưu lượng sang nhà cung cấp, model hoặc tầng dịch vụ khác. | Tổng hợp theo key, quy trình và nhóm cho dashboard thông thường; hạn chế chế độ xem theo từng người dùng. |
| Dạng phản hồi | Lý do kết thúc, ID/tên lời gọi tool, loại đầu ra, trạng thái phản hồi, chi tiết bị cắt ngắn hoặc chưa hoàn chỉnh, tầng dịch vụ. | Cho thấy model dừng bình thường, gọi tool, chạm giới hạn hay trả về phản hồi chưa hoàn chỉnh. | Tham số tool và kết quả tool có thể chứa dữ liệu nhạy cảm. Theo mặc định chỉ lưu ID và tên. |
| Lỗi và giới hạn tốc độ | Mã trạng thái HTTP, mã lỗi của nhà cung cấp, lớp timeout, retry-after, các header yêu cầu remaining/limit/reset, các header token remaining/limit/reset. | Phân biệt yêu cầu sai, xác thực thất bại, sự cố nhà cung cấp, cạn quota và bão giới hạn tốc độ. | Chuẩn hóa lỗi của nhà cung cấp thành các lớp an toàn trước khi đưa chúng vào công cụ phân tích rộng. |
| Quản trị và lưu giữ | Hành động DLP, ID chính sách, chế độ ghi log nội dung, cờ redaction, hash payload, lớp lưu giữ, đủ điều kiện xóa. | Giúp bảo mật và tuân thủ xác minh vì sao nội dung được lưu, bị redaction, bị chặn hoặc bị loại trừ. | Mặc định chỉ ghi log metadata khi nội dung thô không cần thiết cho một quy trình hỗ trợ hoặc kiểm toán đã xác định. |
Thu thập ID trước khi bạn gỡ lỗi nhà cung cấp
Công việc đầu tiên của quan sát API AI là liên kết tương quan. Tài liệu tham khảo API của OpenAI khuyến nghị ghi log các request ID trong môi trường production và ghi nhận cả các giá trị x-request-id do nhà cung cấp tạo ra lẫn các giá trị X-Client-Request-Id do bên gọi cung cấp. Vế sau đặc biệt quan trọng khi timeout hoặc lỗi mạng khiến client của bạn không nhận được các header phản hồi của nhà cung cấp.
Đối với một gateway, hãy thêm một lớp nữa: một gateway request ID tồn tại xuyên suốt các lần thử lại và cơ chế dự phòng nội bộ. Nếu một yêu cầu từ người dùng thử provider A, rồi provider B, và cuối cùng là một mô hình dự phòng, thì gateway ID nên liên kết tất cả các lần thử đó lại với nhau. Provider request ID nên vẫn chỉ gắn với từng lần thử cụ thể. Trace ID nên liên kết cuộc gọi AI này với phần còn lại của yêu cầu ứng dụng.
W3C Trace Context xác định traceparent và tracestate để truyền ngữ cảnh trace phân tán giữa các dịch vụ. Hãy dùng các header đó cho việc liên kết trace, không phải để định danh khách hàng. Phần quyền riêng tư của W3C nói rất rõ: các trường tracing không được chứa thông tin nhận dạng cá nhân hoặc thông tin nhạy cảm khác.
Ghi nhật ký Tuyến Yêu cầu Và Tuyến Được chọn Riêng biệt
Một sai lầm phổ biến trong giám sát cổng AI là chỉ ghi lại nhà cung cấp và mô hình cuối cùng. Điều đó làm mất dấu vết định tuyến quan trọng nhất: khách hàng đã yêu cầu gì và chính sách đã cho phép gì trước khi cổng đưa ra quyết định.
Hãy giữ hai đối tượng này tách biệt:
- Tuyến yêu cầu: họ endpoint, mô hình hoặc bí danh được yêu cầu, chính sách tuyến, ưu tiên nhà cung cấp, chính sách dự phòng, phiên bản danh mục, phiên bản giá, và chế độ yêu cầu như streaming hoặc batch.
- Tuyến được chọn: nhà cung cấp cuối cùng, mô hình cuối cùng, tài khoản hoặc kênh upstream, khu vực khi phù hợp, lý do quyết định tuyến, và ID quy tắc chính sách.
Sự tách biệt này đặc biệt quan trọng khi phản hồi dự phòng là hợp lệ nhưng gây bất ngờ. Nếu tuyến được yêu cầu là chat/completions với streaming được bật, và tuyến được chọn chuyển sang một mô hình khác sau khi timeout, quá trình xem xét sự cố có thể thấy cả đường đi dự kiến lẫn đường đi thực tế. Nó cũng giúp bộ phận tài chính hiểu vì sao mức sử dụng xuất hiện dưới một mô hình hoặc khoản mục khác.
Người mua Flatkey nên áp dụng cùng một mẫu đánh giá. Bắt đầu với danh sách kiểm tra yêu cầu cổng AI API, sau đó dùng sổ tay cân bằng tải và dự phòng để xác định những thay đổi tuyến nào được phép trước khi bạn xem nhật ký.
Ghi Lại Chuỗi Thử Lại Và Dự Phòng
Các lần thử lại là nơi những log không đầy đủ trở nên tốn kém. Nếu các trường được lưu duy nhất chỉ là trạng thái cuối cùng và mô hình cuối cùng, đội ngũ sẽ không thể biết một yêu cầu đã thành công ngay ở lần thử đầu tiên, sau một lần thử lại, hay sau năm lần thử qua nhiều nhà cung cấp. Khả năng quan sát API AI ở cấp độ sự cố coi retry và fallback như một chuỗi.
Mỗi lần thử nên bao gồm:
- Chỉ số lần thử và ID yêu cầu cổng trung gian gốc.
- Nhà cung cấp, mô hình, tài khoản upstream và nhóm endpoint cho lần thử đó.
- Thời gian bắt đầu, thời lượng, lớp timeout và trạng thái streaming.
- Mã trạng thái, lớp lỗi của nhà cung cấp, ID yêu cầu của nhà cung cấp và siêu dữ liệu giới hạn tốc độ.
- Đích fallback và lý do quyết định khi lần thử không kết thúc chuỗi.
Chuỗi này ngăn cổng trung gian che giấu các chế độ lỗi thực sự. Một yêu cầu định dạng sai nên thất bại đóng, chứ không vòng qua các nhà cung cấp. Lỗi 500 từ nhà cung cấp có thể biện minh cho một lần thử lại. Giới hạn hạn mức có thể chuyển sang một tài khoản upstream đã được phê duyệt. Một sự không khớp mô hình đối diện khách hàng có thể cần một lỗi được kiểm soát thay vì fallback âm thầm.
Đo độ trễ cho luồng, không chỉ cho các cuộc gọi đã hoàn tất
Các phản hồi dạng streaming cần nhiều hơn tổng thời lượng. Tài liệu quan sát của Vercel AI Gateway nêu rõ thời gian đến token đầu tiên, thời lượng yêu cầu, số lượng token và chi tiêu là các chỉ số của gateway. Các quy ước ngữ nghĩa GenAI của OpenTelemetry bao gồm gen_ai.response.time_to_first_chunk và gen_ai.request.stream. Những trường này hữu ích vì nhiều sự cố định tuyến thực chất là sự cố streaming: nhà cung cấp đã chấp nhận yêu cầu, chunk đầu tiên đến muộn, luồng bị treo, hoặc phía client ngắt kết nối.
Ít nhất, hãy ghi lại thời điểm bắt đầu yêu cầu, thời lượng gateway, thời lượng nhà cung cấp, thời gian đến token hoặc chunk đầu tiên, cờ luồng đã bắt đầu, cờ luồng đã hoàn tất, lý do hủy, và trạng thái ngắt kết nối của client. Với các phản hồi không streaming, các trường này có thể vẫn là null hoặc false. Điều này giúp duy trì một schema duy nhất trên Chat Completions, Responses và các họ endpoint đặc thù của từng nhà cung cấp.
Không lưu các chunk của luồng theo mặc định. Các chunk của luồng là nội dung phản hồi, và nội dung phản hồi có thể bao gồm dữ liệu người dùng, ngữ cảnh được truy xuất, kết quả công cụ, hoặc thông tin được quản lý. Đối với khả năng quan sát API AI thông thường, siêu dữ liệu về thời gian thường là đủ để chẩn đoán tình trạng treo.
Kết nối mức sử dụng và chi phí với quyết định định tuyến
Mức sử dụng và chi phí là các trường sự cố, không chỉ là trường tài chính. Các ví dụ của OpenAI Responses API bao gồm mức sử dụng token đầu vào, đầu ra, được lưu vào bộ nhớ đệm, suy luận và tổng cộng. Endpoint usage của tổ chức OpenAI hỗ trợ nhóm theo dự án, người dùng, API key, mô hình, batch và service tier; endpoint chi phí hỗ trợ nhóm theo dự án, line item và API key. Tài liệu AI Gateway của Vercel cũng mô tả các bản tóm tắt yêu cầu theo dự án và API key, số lượng token, P75 duration, P75 TTFT và chi phí.
Đối với khả năng quan sát AI API, hãy ghi nhận mức sử dụng và chi phí ở cấp độ lần thử khi có thể, và luôn ở cấp độ yêu cầu cuối cùng. Một phương án dự phòng có thể đúng về mặt vận hành nhưng gây bất ngờ về tài chính. Nếu không có mô hình, tuyến, mức sử dụng và chi phí trong cùng một sự kiện, bộ phận tài chính có thể thấy chi tiêu tăng vọt trước khi kỹ thuật có thể giải thích.
Giá công khai và nội dung trang chủ của Flatkey cho thấy định giá rõ ràng, thanh toán hợp nhất, phân tích mức sử dụng, và một bảng điều khiển cho khóa, mức sử dụng và định tuyến. Một ảnh chụp định giá ngày 18 tháng 6 năm 2026 được lưu cho tác vụ này trả về 638 hàng mô hình, 23 nhà cung cấp, và các nhóm endpoint bao gồm OpenAI Chat Completions, OpenAI Responses, Anthropic Messages, Gemini generateContent, tạo ảnh, và OpenAI video. Hãy coi các con số đó là bằng chứng theo thời điểm, rồi xác minh trang định giá trực tiếp và các bản ghi bảng điều khiển cho các mô hình cụ thể trong quy trình của bạn.
Sử dụng ghi log chỉ chứa metadata làm mặc định
Prompt và phản hồi thô là các công cụ gỡ lỗi mạnh mẽ, nhưng chúng cũng là các bản ghi rủi ro. Tài liệu ghi log của Cloudflare AI Gateway là một mẫu tham chiếu hữu ích: chúng mô tả các bản ghi request với prompt, response, provider, timestamp, status, token usage, cost, duration và user agent, đồng thời cũng ghi lại một header có thể ngăn lưu trữ body request và response thô trong khi vẫn giữ lại metadata như số lượng token, model, provider, status code, cost và duration.
Đó là tư thế mặc định phù hợp cho log API LLM: thu thập metadata theo mặc định, sau đó yêu cầu chế độ debug rõ ràng hoặc quy trình hỗ trợ trước khi nội dung thô được lưu trữ. Các quy ước ngữ nghĩa GenAI của OpenTelemetry đánh dấu các tin nhắn đầu vào, tin nhắn đầu ra, chỉ dẫn hệ thống, tham số lời gọi công cụ và kết quả lời gọi công cụ là những trường có thể chứa thông tin nhạy cảm. Chính sách ghi log của bạn nên phản ánh điều đó.
Một chính sách thực tế có bốn chế độ:
- Không ghi log: dùng cho các request không được phép lưu giữ quá thời gian xử lý tạm thời.
- Chỉ metadata: route, ID, độ trễ, trạng thái, mức sử dụng, chi phí và cờ che giấu.
- Payload đã che giấu: các trường request/response được chọn sau khi loại bỏ PII và bí mật.
- Payload thô: bản ghi debug ngắn hạn, có kiểm soát truy cập, cho một sự cố cụ thể hoặc một trường hợp hỗ trợ đã được khách hàng chấp thuận.
Một sự kiện nhật ký định tuyến mẫu
Mẫu này có chủ đích ưu tiên metadata. Hãy điều chỉnh tên gọi cho phù hợp với hệ thống ghi log của bạn, nhưng giữ nguyên sự tách biệt giữa tuyến được yêu cầu, tuyến được chọn, các lần thử, mức sử dụng, chi phí và các kiểm soát quyền riêng tư.
{
"gateway_request_id": "gw_01jz_route_abc",
"app_request_id": "req_9a7c",
"traceparent": "00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01",
"client_request_id": "7c2c1b3a-4b55-4e36-bd47-8d1c2e2f2e11",
"owner": {
"project": "checkout-ai",
"environment": "production",
"api_key_id": "key_hash_6f12",
"team": "platform",
"workflow": "customer-chat"
},
"requested_route": {
"endpoint_family": "chat_completions",
"model": "primary-chat-model",
"stream": true,
"route_policy_id": "chat-prod-v8",
"fallback_policy_id": "chat-prod-safe-fallback-v3",
"catalog_version": "2026-06-18"
},
"selected_route": {
"provider": "provider_b",
"model": "backup-chat-model",
"upstream_account": "acct_pool_2",
"decision_reason": "primary_timeout",
"policy_rule_id": "fallback_on_timeout_once"
},
"attempts": [
{
"index": 1,
"provider": "provider_a",
"model": "primary-chat-model",
"provider_request_id": "req_provider_a_123",
"status_code": 504,
"error_class": "timeout",
"duration_ms": 12000,
"fallback_target": "provider_b"
},
{
"index": 2,
"provider": "provider_b",
"model": "backup-chat-model",
"provider_request_id": "req_provider_b_456",
"status_code": 200,
"duration_ms": 2400,
"time_to_first_chunk_ms": 620,
"finish_reason": "stop"
}
],
"usage": {
"input_tokens": 1284,
"output_tokens": 312,
"cached_input_tokens": 0,
"reasoning_output_tokens": 0
},
"cost": {
"currency": "usd",
"estimated_amount": 0.0048,
"line_item": "backup-chat-model"
},
"privacy": {
"content_logging_mode": "metadata_only",
"payload_redacted": true,
"retention_class": "30_day_incident_metadata"
}
}Các tên trường là ví dụ, không phải là một hợp đồng API của Flatkey. Hãy dùng chúng để kiểm tra xem cổng của bạn, kho dữ liệu và công cụ xử lý sự cố có thể trả lời các câu hỏi về định tuyến mà không cần nội dung thô hay không.
Một quy trình phân loại trong 10 phút
Khi một sự cố định tuyến mô hình bắt đầu, quy trình khả năng quan sát API AI nên đủ ngắn để kỹ sư trực ca có thể thực hiện dưới áp lực:
- Tìm yêu cầu được tương quan: tìm kiếm theo ID yêu cầu của ứng dụng, ID yêu cầu của cổng, ID lỗi hiển thị cho người dùng, ID yêu cầu của nhà cung cấp, hoặc ID trace.
- So sánh tuyến được yêu cầu và tuyến được chọn: xác nhận mô hình được yêu cầu, chính sách tuyến, quy tắc dự phòng, nhà cung cấp cuối cùng, và mô hình cuối cùng.
- Đọc chuỗi lần thử: xác định lỗi đầu tiên, số lần thử lại, mục tiêu dự phòng, và kết quả cuối cùng.
- Kiểm tra ngữ cảnh giới hạn tốc độ và hạn mức: kiểm tra các header còn lại, giới hạn, và đặt lại khi nhà cung cấp trả về 429 hoặc khi có áp lực token.
- Tách độ trễ khỏi streaming: so sánh thời lượng cổng, thời lượng nhà cung cấp, thời gian đến chunk đầu tiên, kết thúc stream, và ngắt kết nối của client.
- Đối chiếu mức sử dụng và chi phí: xem lại số lượng token, cấp dịch vụ, mục chi phí, và quyền sở hữu theo nhóm/khóa.
- Xem lại chế độ riêng tư: xác nhận log chỉ có metadata, đã che bớt, thô, hay cố ý bị lược bỏ.
- Quyết định hành động của tuyến: hoàn nguyên chính sách, vô hiệu hóa một tuyến, giảm trọng số lưu lượng, tăng hạn mức, xếp hàng công việc nền, hoặc thất bại đóng.
Sau sự cố, hãy chuyển chính các bước đó thành chế độ xem trên dashboard. Những lần rà soát nhanh nhất xảy ra khi kỹ thuật, hỗ trợ và tài chính có thể kiểm tra cùng một dạng sự kiện.
Flatkey Phù Hợp Với Khả Năng Quan Sát API AI Như Thế Nào
Flatkey được định vị dành cho các nhóm muốn có một API key, một endpoint router tương thích, giá cả rõ ràng, thanh toán hợp nhất, và một bảng điều khiển duy nhất cho khóa, mức sử dụng, và định tuyến. Trong bài viết này, lộ trình xác minh liên quan là thực tế: trỏ một client staging tới https://router.flatkey.ai/v1, gửi yêu cầu qua một khóa không phải production, kích hoạt một lỗi có kiểm soát khi có thể, và xác nhận những bản ghi sử dụng, định tuyến, lỗi, và chi phí nào xuất hiện trong dashboard.
Sử dụng theo dõi mức sử dụng AI theo từng khóa để tách biệt lưu lượng staging, production, khách hàng, và workflow. Sử dụng quản lý hạn mức API AI để tránh việc cơ chế fallback làm tiêu tốn ngân sách chung. Sử dụng phân bổ chi phí API AI theo nhóm khi thay đổi định tuyến cần một chủ sở hữu tài chính.
CTA rất đơn giản: nếu nhóm của bạn muốn kiểm thử khả năng quan sát API AI sau một key duy nhất, lấy một key, chạy một tuyến staging qua Flatkey, và xem xét liệu các log có trả lời được những câu hỏi về sự cố ở trên trước khi bạn dựa vào việc chuyển đổi tự động trong production hay không.
Câu hỏi thường gặp
Quan sát API AI là gì?
Quan sát API AI là khả năng kiểm tra lưu lượng API của mô hình trên các request ID, trace, mô hình, nhà cung cấp, quyết định định tuyến, lần thử lại, fallback, mức sử dụng, chi phí, độ trễ, lỗi và kiểm soát quyền riêng tư. Với các sự cố định tuyến, nó nên giải thích cả những gì client đã yêu cầu lẫn những gì gateway thực sự đã chọn.
Nhật ký API LLM nên ghi lại những gì?
Nhật ký API LLM nên ghi lại correlation ID, metadata chủ sở hữu, tuyến được yêu cầu, tuyến được chọn, chuỗi retry, độ trễ, trạng thái streaming, mức sử dụng token, chi phí, lý do kết thúc, loại lỗi, ngữ cảnh giới hạn tần suất và chế độ ghi log nội dung. Prompt và đầu ra thô nên là tùy chọn, có kiểm soát truy cập và được che/mask khi có thể.
Tại sao phải ghi riêng model được yêu cầu và model phản hồi?
Model được yêu cầu thể hiện ý định của client. Model phản hồi cho thấy thực tế đã phục vụ yêu cầu. Trong một sự cố fallback, hai giá trị này có thể khác nhau. Ghi cả hai là điều thiết yếu cho việc đánh giá chất lượng, đối soát chi phí và trao đổi với bộ phận hỗ trợ.
Request ID giúp hỗ trợ nhà cung cấp như thế nào?
Request ID của nhà cung cấp xác định lời gọi API ở upstream. Một request ID do bên gọi cung cấp có thể hữu ích khi timeout khiến header phản hồi không đến được client của bạn. Hãy giữ cả hai ID trong hồ sơ sự cố, cùng với gateway request ID và trace ID.
Giám sát gateway AI có nên lưu prompt thô không?
Không nên mặc định như vậy. Giám sát gateway AI thường cần metadata trước: tuyến, model, trạng thái, thời lượng, mức sử dụng, chi phí và chế độ quyền riêng tư. Chỉ lưu prompt hoặc phản hồi thô trong một quy trình gỡ lỗi, hỗ trợ hoặc kiểm toán đã được xác định, kèm chính sách lưu giữ và kiểm soát truy cập.
Các nguồn đã sử dụng
- Tổng quan OpenAI API: gỡ lỗi các yêu cầu và ID yêu cầu
- Tài liệu tham khảo OpenAI Chat Completions API và Tài liệu tham khảo Responses API
- Tài liệu tham khảo OpenAI organization usage and costs API
- Tài liệu logging của Cloudflare AI Gateway
- Tài liệu observability của Vercel AI Gateway
- Khuyến nghị W3C Trace Context
- Các thuộc tính quy ước ngữ nghĩa GenAI của OpenTelemetry
Kiểm tra cuối cùng trước khi bạn thay đổi định tuyến
Trước khi bạn tin tưởng cơ chế chuyển dự phòng tự động, hãy biến khả năng quan sát API AI thành một phần của cổng phát hành. Xác nhận chính sách định tuyến, thang retry, các trường token và chi phí, header giới hạn tần suất, dấu thời gian streaming, ID yêu cầu của nhà cung cấp, chế độ riêng tư và lớp lưu giữ. Sau đó chạy một sự cố có kiểm soát trong môi trường staging và xác minh rằng log có thể giải thích kết quả mà không cần truy cập prompt thô.
Flatkey giảm bề mặt tích hợp xuống còn một khóa và một URL gốc tương thích. Để đánh giá lớp độ tin cậy đó bằng lưu lượng của chính bạn, hãy lấy một khóa, chạy một quy trình làm việc trong staging và kiểm tra các bản ghi định tuyến, sử dụng, chi phí và lỗi mà nhóm của bạn sẽ cần trong một sự cố thực sự.
