Khả năng quan sát API LLM: Metrics, Traces, Logs và Chi phí

Khả năng quan sát API LLM là thực hành biến mọi lần gọi mô hình thành đủ bằng chứng có cấu trúc để trả lời bốn câu hỏi trong môi trường production:

1. Yêu cầu có thành công không?
2. Người dùng đã phải chờ bao lâu?
3. Yêu cầu đã tiêu thụ gì và tốn bao nhiêu?
4. Tại sao hệ thống chọn mô hình đó, thử lại, hoặc chuyển sang phương án dự phòng?

Giám sát HTTP thông thường là cần thiết, nhưng không đủ. Một 200 OK vẫn có thể chứa JSON không hợp lệ, câu trả lời trống, phản hồi bị từ chối, một lời gọi công cụ bị lỗi, hoặc đầu ra vi phạm hợp đồng của ứng dụng. Một yêu cầu cũng có thể thành công sau ba lần thử và âm thầm tốn kém gấp bốn lần so với dự kiến.

Mục tiêu thực tế không phải là ghi lại mọi prompt. Mà là tạo ra một hợp đồng telemetry nhỏ, nhất quán, kết nối kết quả ứng dụng với model, nhà cung cấp, route, độ trễ, mức sử dụng token, số lần thử lại, và chi phí—mà không làm lộ dữ liệu người dùng.

Hướng dẫn này cho thấy cách xây dựng hợp đồng đó bằng metrics, traces, structured logs, mục tiêu cấp dịch vụ, dashboard, và cảnh báo.

Khả năng quan sát API LLM phải giải thích điều gì

Một hệ thống quan sát hữu ích cho phép kỹ sư trực ca nhanh chóng đi từ triệu chứng đến nguyên nhân.

Quy tắc thiết kế đầu tiên rất đơn giản: đo hợp đồng ứng dụng, không chỉ hợp đồng truyền tải.

Năm lớp telemetry

Việc giám sát API LLM trở nên dễ hơn khi bạn tách thành năm lớp thay vì ép mọi tín hiệu vào một dashboard duy nhất.

1. Metrics của yêu cầu

Metrics cho thấy xu hướng và cung cấp sức mạnh cho cảnh báo. Ghi lại counters và histograms cho:

• Số lượng yêu cầu
• Độ trễ end-to-end
• Thời gian đến token đầu tiên cho phản hồi streaming
• Độ trễ của nhà cung cấp hoặc của lần gọi model
• Các yêu cầu thành công, thất bại, bị hủy và hết thời gian chờ
• Phản hồi HTTP 429 và 5xx
• Các lần thử lại và chuyển sang fallback
• Input, output, và cached tokens
• Chi phí ước tính và đã đối soát

Metrics nên có các nhãn giới hạn. Các nhãn tốt bao gồm provider, model, route, environment, status, và error_type. Tránh các nhãn có độ phân mảnh cao như user IDs, request IDs, prompt text, hoặc full URLs.

2. Distributed traces

Trace giải thích lộ trình của một yêu cầu duy nhất xuyên qua API, hàng đợi, lớp truy xuất, các lần gọi công cụ, gateway và nhà cung cấp mô hình của bạn.

Một cấu trúc phân cấp trace thực tế trông như sau:

POST /support/reply
├── retrieve_customer_context
├── llm.route
│   ├── llm.attempt provider_a/model_primary
│   └── llm.attempt provider_b/model_fallback
├── validate_structured_output
└── persist_draft

Mỗi lần thử mô hình nên là một span riêng. Nếu thử hai nhà cung cấp, trace phải hiển thị hai lần thử thay vì che giấu cả hai bên trong một span llm.call mờ đục duy nhất.

Các quy ước ngữ nghĩa Generative AI của OpenTelemetry cung cấp một từ vựng chung hữu ích cho các span, metric và event của generative AI. Hãy coi phiên bản quy ước là một phần của lược đồ telemetry của bạn để bạn có thể di chuyển có chủ đích khi các thuộc tính thay đổi.

3. Logs có cấu trúc

Logs ghi lại các quyết định rời rạc và ngữ cảnh chẩn đoán mà sẽ quá tốn kém hoặc quá chi tiết nếu dùng làm nhãn metric.

Các event hữu ích bao gồm:

• llm.request.started
• llm.route.selected
• llm.retry.scheduled
• llm.fallback.selected
• llm.response.validated
• llm.request.completed
• llm.request.failed

Mỗi event nên bao gồm cùng các trường tương quan: request_id, trace_id, route, model, provider, prompt_version, và attempt.

4. Tín hiệu chất lượng và hợp đồng

Không thể suy ra chất lượng chỉ từ mã trạng thái. Hãy thêm các bộ kiểm tra xác định ở mọi nơi có thể:

• JSON được phân tích thành công
• Các trường schema bắt buộc tồn tại
• Tên công cụ và đối số được phép
• Danh sách trích dẫn có mặt khi được yêu cầu
• Độ dài đầu ra nằm trong giới hạn sản phẩm
• Trạng thái từ chối hoặc an toàn được nhận diện
• Các kiểm tra quy tắc kinh doanh đều đạt

Với các tác vụ mang tính chủ quan, hãy đính kèm kết quả đánh giá được lấy mẫu sau đó. Giữ telemetry yêu cầu trực tuyến và đánh giá ngoại tuyến được nối với nhau thông qua một request hoặc sample ID ổn định.

Trước khi thay thế một mô hình production, hãy dùng một quy trình đánh giá mô hình AI có thể lặp lại thay vì chỉ dựa vào độ trễ tổng hợp và giá token.

5. Chi phí và kết quả kinh doanh

Số lượng token là tín hiệu sử dụng, không phải kết quả kinh doanh. Hãy kết nối việc sử dụng mô hình với đơn vị mà sản phẩm của bạn quan tâm:

• Chi phí trên mỗi phản hồi hỗ trợ được chấp nhận
• Chi phí trên mỗi tác vụ lập trình hoàn thành
• Chi phí trên mỗi hình ảnh sản phẩm được tạo ra và được người duyệt chấp thuận
• Chi phí trên mỗi khách hàng tiềm năng đủ điều kiện được làm giàu dữ liệu
• Chi phí trên mỗi lần trích xuất có cấu trúc thành công

Công thức hữu ích nhất là:

chi phí hiệu dụng trên mỗi tác vụ được chấp nhận = tổng chi phí mô hình / số tác vụ được chấp nhận

Điều này phơi bày các khoản tiết kiệm giả. Một mô hình rẻ hơn nhưng gây ra nhiều lần thử lại, lỗi xác thực hơn hoặc công việc làm lại của con người có thể làm tăng chi phí hiệu dụng.

Hợp đồng telemetry tối thiểu cho mọi lần gọi mô hình

Hãy bắt đầu với một lược đồ event có phiên bản. Tên trường chính xác có thể theo stack observability của bạn, nhưng các khái niệm nên giữ ổn định.

{
  "schema_version": "llm-observability.v1",
  "timestamp": "2026-07-30T09:00:00Z",
  "request_id": "req_internal_01",
  "trace_id": "7c4b...",
  "environment": "production",
  "feature": "support_reply",
  "route": "support-default",
  "provider": "provider-a",
  "model": "model-primary",
  "prompt_version": "support-reply-v12",
  "attempt": 1,
  "stream": true,
  "status": "success",
  "http_status": 200,
  "latency_ms": 1840,
  "time_to_first_token_ms": 410,
  "input_tokens": 1640,
  "output_tokens": 284,
  "cached_input_tokens": 900,
  "estimated_cost_usd": 0.0068,
  "validator": "passed",
  "fallback_reason": null,
  "provider_request_id": "redacted-or-scoped-value"
}

Không đặt prompt và phản hồi thô làm các trường bắt buộc. Chỉ lưu chúng khi có nhu cầu xác định, chính sách lưu giữ đã được phê duyệt, kiểm soát truy cập phù hợp và một đường dẫn che giấu an toàn.

Các metrics nên có trên dashboard đầu tiên

Đừng bắt đầu với 40 panel. Hãy xây dựng một dashboard vận hành duy nhất trả lời câu hỏi liệu người dùng có nhận được kết quả hợp lệ trong ngân sách độ trễ và chi phí hay không.

Lưu lượng và thành công

• Số request mỗi phút
• Tỷ lệ thành công của lớp vận chuyển
• Tỷ lệ thành công đã được xác thực
• Tỷ lệ hủy
• Tỷ lệ timeout
• Tỷ lệ khuếch đại retry
• Tỷ lệ fallback

Tỷ lệ thành công đã được xác thực nên là tín hiệu khả dụng chính:

validated success rate = requests that pass the application contract / eligible requests

Điều này chặt chẽ hơn và hữu ích hơn so với phản hồi 2xx / requests.

Độ trễ

Theo dõi phân phối thay vì giá trị trung bình:

• Độ trễ end-to-end p50, p95 và p99
• Độ trễ gọi provider p50, p95 và p99
• Thời gian đến token đầu tiên p50 và p95
• Thời gian chờ trong hàng đợi p95
• Thời gian thực thi tool p95
• Thời lượng xác thực p95

Tách riêng các route streaming và non-streaming. Một request streaming có thể mang lại cảm giác phản hồi tốt với thời gian đến token đầu tiên tốt, ngay cả khi tổng thời gian hoàn tất dài.

Độ tin cậy

• Tỷ lệ 429 theo provider và model
• Tỷ lệ 5xx theo provider và model
• Tỷ lệ lỗi mạng
• Tỷ lệ phản hồi sai định dạng hoặc không hợp lệ theo schema
• Tỷ lệ lỗi gọi tool
• Trạng thái mở của circuit breaker
• Tỷ lệ cạn kiệt ngân sách retry

Nếu giới hạn tốc độ là nguyên nhân thường xuyên, hãy dùng chiến lược retry LLM cho giới hạn RPM và TPM có giới hạn thay vì retry không phối hợp trong mỗi worker của ứng dụng.

Sử dụng và chi phí

• Token đầu vào và đầu ra theo feature
• Số token trên mỗi tác vụ được chấp nhận
• Chi phí ước tính trên mỗi request
• Chi phí trên mỗi tác vụ được chấp nhận
• Chi phí do retry
• Chênh lệch chi phí do fallback
• Chi tiêu hằng ngày so với ngân sách
• Ước tính chi phí so với hóa đơn của provider hoặc xuất dữ liệu sử dụng

Giữ cả estimated_cost và reconciled_cost. Giá trị đầu tiên cho phép giám sát gần như theo thời gian thực; giá trị thứ hai hiệu chỉnh các ước tính sau khi dữ liệu thanh toán chính thức được cung cấp.

Cách theo dõi các lần thử lại và định tuyến dự phòng

Các lần thử lại và phương án dự phòng là nơi giám sát cơ bản thường thất bại. Nếu mọi lần thử đều dùng chung một trường trạng thái, một yêu cầu tốn kém và bị suy giảm hiệu năng có thể trông vẫn bình thường.

Ghi lại các trường sau cho mỗi lần thử:

Một playbook định tuyến dự phòng API LLM trong môi trường production nên xác định chính sách quyết định. Sau đó, khả năng quan sát nên chứng minh rằng bộ định tuyến đã tuân theo chính sách đó.

Mẫu instrumentation TypeScript

Ví dụ sau giữ telemetry độc lập với một SDK mô hình cụ thể. Nó ghi lại một span route cha và một span con cho mỗi lần thử.

import { context, SpanStatusCode, trace } from "@opentelemetry/api";

const tracer = trace.getTracer("ai-gateway");

type ModelAttempt = {
  provider: string;
  model: string;
  reason: "primary" | "retry" | "fallback";
};

export async function runModelRoute(
  attempts: ModelAttempt[],
  callModel: (attempt: ModelAttempt) => Promise<{
    text: string;
    usage?: { inputTokens?: number; outputTokens?: number };
    providerRequestId?: string;
  }>,
) {
  return tracer.startActiveSpan("llm.route", async (routeSpan) => {
    routeSpan.setAttribute("app.llm.route", "support-default");
    routeSpan.setAttribute("app.llm.attempt_limit", attempts.length);

    try {
      for (const [index, attempt] of attempts.entries()) {
        const result = await tracer.startActiveSpan(
          "llm.attempt",
          { attributes: {
            "gen_ai.system": attempt.provider,
            "gen_ai.request.model": attempt.model,
            "app.llm.attempt": index + 1,
            "app.llm.reason": attempt.reason,
          } },
          context.active(),
          async (attemptSpan) => {
            const startedAt = performance.now();

            try {
              const response = await callModel(attempt);
              const valid = response.text.trim().length > 0;

              attemptSpan.setAttribute("app.llm.validated", valid);
              attemptSpan.setAttribute(
                "gen_ai.usage.input_tokens",
                response.usage?.inputTokens ?? 0,
              );
              attemptSpan.setAttribute(
                "gen_ai.usage.output_tokens",
                response.usage?.outputTokens ?? 0,
              );
              attemptSpan.setAttribute(
                "app.llm.latency_ms",
                performance.now() - startedAt,
              );

              if (!valid) {
                throw new Error("response_validation_failed");
              }

              attemptSpan.setStatus({ code: SpanStatusCode.OK });
              return response;
            } catch (error) {
              attemptSpan.recordException(error as Error);
              attemptSpan.setStatus({
                code: SpanStatusCode.ERROR,
                message: (error as Error).message,
              });
              return null;
            } finally {
              attemptSpan.end();
            }
          },
        );

        if (result) {
          routeSpan.setAttribute("app.llm.selected_attempt", index + 1);
          routeSpan.setStatus({ code: SpanStatusCode.OK });
          return result;
        }
      }

      throw new Error("llm_route_exhausted");
    } catch (error) {
      routeSpan.recordException(error as Error);
      routeSpan.setStatus({
        code: SpanStatusCode.ERROR,
        message: (error as Error).message,
      });
      throw error;
    } finally {
      routeSpan.end();
    }
  });
}

Trong môi trường production, hãy thêm các bộ đếm metric và sự kiện log có cấu trúc cùng với các span. Đồng thời, hãy thu thập các mã định danh request của nhà cung cấp khi có sẵn; chúng thường rất cần thiết khi leo thang một sự cố lên nhà cung cấp mô hình. Hãy giữ những mã định danh đó khỏi các thông báo lỗi công khai.

Logs không làm rò rỉ prompt

Giá trị mặc định an toàn nhất là ghi log theo hướng ưu tiên metadata trước.

Ghi log theo mặc định

• ID yêu cầu nội bộ và ID trace
• ID yêu cầu của nhà cung cấp
• Tên tính năng và route
• Nhà cung cấp, model và bí danh triển khai
• Phiên bản template prompt
• Các tham số như temperature và số token đầu ra tối đa
• Mức sử dụng token
• Độ trễ và thời gian đến token đầu tiên
• Loại lỗi và quyết định thử lại
• Kết quả validator
• Tên công cụ đã được làm sạch

Không ghi log theo mặc định

• Prompt hoặc phản hồi thô
• API key hoặc header xác thực
• Secret của khách hàng
• Tài liệu được truy xuất
• Đối số công cụ chứa dữ liệu cá nhân hoặc dữ liệu thuộc diện quản lý
• Đường dẫn tệp đầy đủ hoặc bản ghi cơ sở dữ liệu
• URL đã ký

Khi cần thu thập nội dung để gỡ lỗi hoặc đánh giá, hãy lấy mẫu riêng, che mờ trước khi lưu trữ, hạn chế quyền truy cập, mã hóa và đặt thời gian lưu giữ ngắn. Hướng dẫn quản lý API key an toàn bao quát các biện pháp kiểm soát liên quan cho secret, ghi log, xoay vòng và ứng phó sự cố.

SLO cho các tính năng dựa trên LLM

Một mục tiêu mức dịch vụ (SLO) cho LLM nên mô tả tính năng mà người dùng nhìn thấy, không phải tài khoản của nhà cung cấp.

Ví dụ SLO cho một tính năng trả lời hỗ trợ có cấu trúc:

Những con số này chỉ là ví dụ, không phải mục tiêu सार्व quát. Hãy thiết lập chúng dựa trên kỳ vọng của người dùng, độ phức tạp của tác vụ, hành vi của nhà cung cấp và kinh tế đơn vị.

Sử dụng error budget để quyết định khi nào nên làm chậm phát hành tính năng, siết chặt chính sách route hoặc chuyển lưu lượng. Một nhà cung cấp có thể đạt mục tiêu khả dụng của riêng họ nhưng sản phẩm của bạn vẫn không đạt SLO vì hàng đợi, công cụ, xác thực hoặc hành vi fallback làm phát sinh lỗi.

Cảnh báo theo triệu chứng, chẩn đoán theo nguyên nhân

Gửi cảnh báo khẩn cho người vận hành khi có tác động đến người dùng. Dùng cảnh báo mức độ thấp hơn hoặc chú thích trên dashboard cho các nguyên nhân có khả năng xảy ra.

Triệu chứng cần pager

• Tỷ lệ thành công đã xác thực vi phạm SLO
• p95 thời gian đến token đầu tiên vượt ngưỡng hướng tới người dùng
• Tỷ lệ route cạn kiệt tăng vọt
• Chi phí trên mỗi tác vụ được chấp nhận vượt ngưỡng kiểm soát
• Một tính năng quan trọng không có target nào khỏe mạnh tương thích với hợp đồng

Tín hiệu chẩn đoán

• Tỷ lệ 429 của một nhà cung cấp tăng lên
• Tỷ lệ lỗi schema của một model thay đổi
• Khuếch đại retry tăng
• Thời gian chờ hàng đợi tăng
• Circuit breaker mở
• Mức sử dụng token thay đổi sau một lần phát hành prompt

Tránh gửi pager cho mọi lỗi 5xx từ nhà cung cấp. Nếu fallback đang hoạt động và người dùng vẫn nhận được phản hồi hợp lệ trong ngân sách độ trễ, sự kiện đó có thể chỉ cần điều tra mà không cần đánh thức kỹ sư trực ca.

Mô hình vận hành với ba dashboard

Dashboard 1: Trải nghiệm người dùng

Hiển thị khả dụng đã xác thực, độ trễ, thời gian đến token đầu tiên, hoàn thành tác vụ và lỗi mà người dùng nhìn thấy theo từng tính năng.

Dashboard 2: Điều phối và nhà cung cấp

Hiển thị tỷ lệ lưu lượng, lỗi của nhà cung cấp, các lần thử lại, phương án dự phòng, circuit breaker, mức bão hòa tuyến và độ trễ theo mô hình và đích.

Dashboard 3: Mức sử dụng và kinh tế

Hiển thị số token, chi tiêu ước tính, chi tiêu đối soát, chi phí trên mỗi tác vụ được chấp nhận, chênh lệch ngân sách và các tính năng hàng đầu theo chi phí.

Giữ nguyên các chú thích về triển khai và phiên bản prompt trên cả ba dashboard. Nếu không, một hồi quy bắt đầu ngay sau khi phát hành có thể trông giống như biến thiên ngẫu nhiên của nhà cung cấp.

Danh sách kiểm tra triển khai

1. Định nghĩa một lược đồ sự kiện có phiên bản.
2. Tạo một ID yêu cầu nội bộ tại ranh giới sản phẩm.
3. Truyền ngữ cảnh trace qua hàng đợi, công cụ và các lệnh gọi mô hình.
4. Tạo một span con cho mỗi lần thử mô hình.
5. Ghi lại ID yêu cầu của nhà cung cấp khi được trả về.
6. Thêm xác thực đầu ra mang tính quyết định.
7. Theo dõi rõ ràng lý do thử lại và phương án dự phòng.
8. Tính chi phí ước tính từ một bảng giá có phiên bản.
9. Đối soát các ước tính với dữ liệu sử dụng hoặc xuất hóa đơn có thẩm quyền.
10. Xây dựng một dashboard kết quả của người dùng trước các dashboard của nhà cung cấp.
11. Đặt SLO cho thành công đã được xác thực và độ trễ.
12. Ẩn hoặc loại trừ prompt, phản hồi, bí mật và dữ liệu công cụ nhạy cảm.
13. Chạy các bài kiểm thử lỗi cho timeout, 429, 5xx, đầu ra sai định dạng và mức bão hòa tuyến.
14. Rà soát độ bùng nổ cardinality của nhãn trước khi bật metrics trong production.
15. Lấy mẫu trace theo rủi ro: giữ lại lỗi và các yêu cầu chậm nhiều hơn so với các thành công thông thường.

Các sai lầm phổ biến về observability

Xem mọi 200 là thành công

Thêm trình kiểm tra hợp đồng và báo cáo riêng phần thành công đã được xác thực.

Ghi log prompt thô cho mọi yêu cầu

Điều này tạo ra các vấn đề về quyền riêng tư, bảo mật, lưu giữ và chi phí. Hãy ưu tiên metadata và lấy mẫu có kiểm soát.

Che giấu các lần thử lại bên trong một khoảng thời gian duy nhất

Tạo một span và một sự kiện cho mỗi lần thử để người vận hành có thể thấy sự khuếch đại.

Dùng tên mô hình như danh tính tuyến duy nhất

Theo dõi nhà cung cấp, bí danh triển khai hoặc tài khoản, khu vực và chính sách tuyến. Cùng một mô hình có thể hoạt động khác nhau giữa các đích.

Cảnh báo dựa trên độ trễ trung bình

Số trung bình che khuất nỗi đau ở phần đuôi phân phối. Hãy dùng p95 và p99, đồng thời tách thời gian đến token đầu tiên khỏi tổng thời gian hoàn tất.

Luôn tin vào chi phí ước tính

Bảng giá, cách xử lý cache và hạch toán của nhà cung cấp có thể thay đổi. Hãy đối soát ước tính với dữ liệu billing và ghi lại phiên bản bảng giá.

Để telemetry labels tăng không giới hạn

ID yêu cầu và mã định danh khách hàng thuộc về trace hoặc log, không phải label của metrics.

API gateway AI giúp gì

Các ứng dụng đa nhà cung cấp nếu không có gateway sẽ cần các adapter riêng cho xác thực, đặt tên mô hình, retry, trường sử dụng, lỗi và xuất hóa đơn. Một gateway có thể giảm bề mặt tích hợp đó bằng cách cung cấp cho ứng dụng một ranh giới API ổn định, trong khi vẫn bảo toàn thông tin nhà cung cấp và mô hình trong telemetry nội bộ.

Flatkey cung cấp một API key, một endpoint tương thích OpenAI và quyền truy cập vào các mô hình từ các nhà cung cấp lớn. Điều đó giúp có thể tập trung hóa hợp đồng telemetry phía ứng dụng ngay cả khi khối lượng công việc sử dụng các mô hình văn bản, hình ảnh hoặc video khác nhau. Gateway không thay thế observability ở cấp sản phẩm: ứng dụng của bạn vẫn phải ghi lại tính năng, phiên bản prompt, kết quả xác thực, độ trễ mà người dùng nhìn thấy và kết quả tác vụ được chấp nhận.

Nếu nhóm của bạn đang hợp nhất các nhà cung cấp, hãy bắt đầu với hướng dẫn kiến trúc AI API gateway, sau đó thêm hợp đồng telemetry trong bài viết này trước khi đưa lưu lượng sản xuất vào hoạt động.

Câu hỏi thường gặp

Khả năng quan sát API LLM là gì?

Khả năng quan sát API LLM là việc thu thập và đối chiếu metrics, traces, logs, kiểm tra chất lượng, dữ liệu sử dụng và chi phí cho các tính năng được hỗ trợ bởi mô hình. Nó giải thích cả hành vi của nhà cung cấp lẫn việc ứng dụng có trả về một kết quả hợp lệ cho người dùng hay không.

Tôi nên giám sát điều gì cho một API LLM?

Hãy giám sát tỷ lệ thành công đã được xác thực, độ trễ end-to-end, thời gian đến token đầu tiên, độ trễ của nhà cung cấp, tỷ lệ 429 và 5xx, số lần thử lại, phương án dự phòng, mức sử dụng token, chi phí ước tính, chi phí trên mỗi tác vụ được chấp nhận và các lỗi về hợp đồng đầu ra.

Có nên lưu prompt và phản hồi trong traces không?

Không theo mặc định. Hãy lưu metadata trước. Chỉ ghi lại nội dung cho một mục đích gỡ lỗi hoặc đánh giá đã xác định, kèm theo che giấu dữ liệu, kiểm soát truy cập, mã hóa, lấy mẫu và chính sách lưu giữ.

Sự khác nhau giữa giám sát LLM và khả năng quan sát LLM là gì?

Giám sát cho bạn biết rằng một metric đã biết nào đó vượt ngưỡng. Khả năng quan sát cung cấp đủ bằng chứng được tương quan để điều tra các chế độ lỗi mới trên toàn bộ ứng dụng, tuyến, nhà cung cấp, mô hình, công cụ và hợp đồng đầu ra.

Làm thế nào để tính chi phí LLM trên mỗi request?

Nhân các đơn vị sử dụng đầu vào, đầu ra, đầu vào được lưu cache, media hoặc các đơn vị sử dụng khác có tính phí với một bảng giá được phiên bản hóa, rồi cộng thêm chi phí của các lần thử lại và các lần dự phòng. Đối soát ước tính này với dữ liệu billing của nhà cung cấp hoặc gateway.

Tôi nên lưu request ID nào?

Hãy tạo request ID nội bộ và trace ID của riêng bạn, sau đó cũng lưu request ID của nhà cung cấp khi API trả về một ID. Các ID nội bộ kết nối các hệ thống của bạn; ID của nhà cung cấp giúp hỗ trợ bên ngoài và leo thang xử lý sự cố.

Xây dựng hợp đồng telemetry trước khi sự cố xảy ra

Thời điểm tốt nhất để quyết định một lần gọi mô hình nên ghi lại những gì là trước khi lưu lượng sản xuất xuất hiện. Hãy bắt đầu với thành công đã được xác thực, phân phối độ trễ, một span cho mỗi lần thử, các nhãn metric có giới hạn, log ưu tiên metadata, và chi phí trên mỗi tác vụ được chấp nhận. Sau đó kiểm tra hệ thống bằng cách buộc những lỗi mà bạn kỳ vọng bộ định tuyến sẽ xử lý.

Nền tảng đó biến một báo cáo mơ hồ—“tính năng AI chậm và tốn kém”—thành một quyết định có thể truy vết: tính năng nào, tuyến nào, mô hình nào, lần thử nào, lỗi nào, độ trễ bao nhiêu và chi phí bao nhiêu.

Khám phá giá Flatkey khi bạn sẵn sàng so sánh các tuyến đa mô hình phía sau một API tương thích OpenAI duy nhất.