Sáng thứ Ba, dashboard chi phí LLM của team mình hiện đúng con số của tuần trước. $2 mỗi triệu input token, $10 mỗi triệu output, $0.20 mỗi triệu cache read. Không đổi một ly. Nếu chỉ nhìn tới đó thôi, chắc mình đã xếp Sonnet 5.5 vào mục “chẳng có gì mới, bỏ qua”.

Mà vậy là sai. Anthropic ra Sonnet 5.5 ngày 28/9, model thứ hai trong họ 5.5 sau khi Opus 5.5 ra mắt một tuần trước đó. Giá không nhích một xu. Nhưng Anthropic lại nói rẻ hơn tới 30% mỗi task, chạy nhanh hơn 30%+ so với Sonnet 5. Hai điều này chỉ hợp lý khi ghép lại với nhau nếu model làm cùng một việc bằng ít token và ít tool call hơn. Và đúng là vậy thật. Điểm Terminal-Bench 4.0 nhảy từ 10.3% lên 70.6%. Đây không phải một cú tinh chỉnh nhỏ — đây là một mức độ khác hẳn về độ tin cậy agentic.

Đây mới là phần đáng để bất kỳ ai đang vận hành mô hình chi phí AI ở công ty phải suy nghĩ lại: dashboard của bạn không nhìn thấy chuyện này. Không phải vì dữ liệu không tồn tại — mà vì bạn chưa hề thu thập nó.

Điểm mù của chỉ số

Đa số hệ thống FinOps cho workload LLM chỉ đo tốt đúng một thứ: đô-la trên mỗi token, thường được gộp theo model và theo ngày. Con số này dễ lấy, vì hóa đơn API tự đưa sẵn. Thế là team xây cả câu chuyện chi phí xoay quanh nó.

Vấn đề là workload agentic không tiêu tiền theo token. Nó tiêu tiền theo task — và chi phí của một task là hàm số của việc cần bao nhiêu token để hoàn thành, mà bản thân số token đó lại phụ thuộc vào số bước, số lần retry, số tool call model cần. Một model đắt hơn 20% mỗi token nhưng xong task chỉ bằng nửa số tool call thì rẻ hơn theo mọi nghĩa quan trọng. Ngược lại, một model giữ nguyên giá mỗi token nhưng bỗng dưng cần gấp 3 lần số bước để xong việc — đó là một regression âm thầm mà dashboard của bạn sẽ báo cáo là “không đổi” suốt nhiều tuần liền.

Sonnet 5.5 là lần đầu tiên mình thấy khoảng trống này được chính một vendor ghi lại rõ ràng, chứ không chỉ là kỹ sư ngồi than vãn trước hóa đơn AWS. GitHub chạy test sớm khi đưa model này vào GitHub Copilot (GA cùng ngày, 28/9) và báo là nó “ngang bằng Claude Sonnet 5 trên các tác vụ coding, nhưng dùng ít bước, ít token, ít tool call hơn hẳn.” Abhinay Kathuria của Zendesk nói ticket được xử lý nhanh hơn 20% trong lúc test. Cả hai đều không phải câu chuyện về giá token. Cả hai đều là câu chuyện về token-trên-mỗi-task và bước-trên-mỗi-task — mà nếu đó không phải một dòng trên dashboard của bạn, bạn sẽ đọc bản ra mắt này như một sai số làm tròn.

Một ví dụ tính cụ thể

Giả sử team bạn có một agent CI chuyên đi soi các test chạy fail — đọc lỗi, grep codebase, kiểm tra commit gần đây, quyết định đây là flaky test hay regression thật, rồi tạo hoặc cập nhật ticket. Trên Sonnet 5, task này thường chạy:

  • 14 tool call (đọc file, grep, git log, gọi API ticket)
  • 38,000 token tổng cộng (input + output, tính cả retry)
  • Chi phí ở mức $2/$10 mỗi triệu: khoảng $0.29 cho mỗi lần triage

Chạy đúng task đó trên Sonnet 5.5 với mức cải thiện hiệu suất mà Anthropic và GitHub mô tả — cứ tạm tính giảm 25% tool call và token, nằm trong khoảng 30% họ công bố:

  • 10-11 tool call
  • ~28,500 token
  • Chi phí: khoảng $0.22 cho mỗi lần triage

Giá mỗi token không đổi. Gói giá của bạn không thay đổi gì cả. Nhưng nếu agent này chạy 2,000 lần một tháng trên toàn bộ test suite, chênh lệch là $580 so với $440 — tiết kiệm thật $140/tháng, vô hình với một dashboard chỉ theo dõi dòng giá-token, vì giá token đúng nghĩa đen là không nhúc nhích. Nhân con số này lên mọi workflow agentic mà tổ chức bạn đang chạy, cái số vô hình đó không còn nhỏ nữa.

Cái cần đo thật sự

Bạn cần hai con số nằm cạnh chi phí token, chứ không phải thay thế nó: số bước trên mỗi task và số token trên mỗi task, chia theo loại task và theo phiên bản model. Dưới đây là hình dung khá sát về một wrapper quanh vòng lặp agent của bạn — kiểu code bạn thật sự sẽ dán vào một PR, không phải cả một nền tảng observability hoàn chỉnh:

type AgentRunMetrics = {
  taskType: string;
  model: string;
  stepsPerTask: number;
  tokensPerTask: number;
  toolCallsPerTask: number;
  wallClockMs: number;
  succeeded: boolean;
};

async function runInstrumentedAgent(
  taskType: string,
  model: string,
  agentLoop: () => AsyncGenerator<AgentStep>
): Promise<AgentRunMetrics> {
  const start = Date.now();
  let steps = 0;
  let tokens = 0;
  let toolCalls = 0;
  let succeeded = false;

  for await (const step of agentLoop()) {
    steps += 1;
    tokens += step.inputTokens + step.outputTokens;
    if (step.isToolCall) toolCalls += 1;
    if (step.isFinalAnswer) succeeded = true;
  }

  const metrics: AgentRunMetrics = {
    taskType,
    model,
    stepsPerTask: steps,
    tokensPerTask: tokens,
    toolCallsPerTask: toolCalls,
    wallClockMs: Date.now() - start,
    succeeded,
  };

  // Đẩy về bất kỳ hệ thống nào bạn đang dùng sẵn — Datadog, một bảng
  // Postgres, hay chỉ một dòng log để pipeline parse. Vấn đề mấu chốt
  // là các trường này tồn tại và query được theo từng phiên bản model,
  // chứ không chỉ mỗi $/token.
  emitMetric("agent.run", metrics);

  return metrics;
}

Câu query bạn thật sự cần chạy mỗi tháng một lần là: với mỗi taskType, vẽ tokensPerTask và stepsPerTask theo model qua thời gian. Khi bạn đổi từ Sonnet 5 sang Sonnet 5.5, hoặc khi model kế tiếp ra mắt, biểu đồ đó sẽ nhúc nhích dù biểu đồ giá-mỗi-token không hề đổi. Đó mới là tín hiệu thật. Biểu đồ giá token chỉ là một input để tính hóa đơn, không phải thước đo cho việc model thực sự tốn bao nhiêu để hoàn thành công việc.

Chi phí trên mỗi token giờ là chỉ số sai để làm trọng tâm

Nói thẳng luôn: những team vẫn đang xây toàn bộ câu chuyện FinOps AI dựa trên $/token là đang đo cái dễ đo, không phải cái đúng cần đo. Cách này hợp lý khi model chủ yếu chỉ là completion một lượt — một prompt, một response, chi phí chỉ đơn giản là token nhân giá. Workload agentic đã phá vỡ giả định đó từ lâu rồi, mà đa số dashboard chi phí thì chưa theo kịp.

Cái nên thay thế là chi phí trên mỗi task hoàn thành, với số bước và số token trên mỗi task làm lớp chẩn đoán bên dưới — những con số cho bạn biết tại sao chi phí-mỗi-task lại thay đổi. Rõ ràng Anthropic xây Sonnet 5.5 với tư duy này; điểm GDPval-AA v2.1 (1844 Elo, gần bằng 1846 của Opus 5.5) cho thấy họ đang tối ưu cho chất lượng hoàn thành task ở chi phí vận hành thấp hơn, chứ không hề đụng vào đòn bẩy giá-mỗi-token.

Nếu team bạn đưa một agent lên production mà không có biểu đồ bước-trên-task và token-trên-task nằm cạnh biểu đồ giá token, bạn đang bay mù trên đúng cái trục mà các model bây giờ đang cạnh tranh với nhau. Sonnet 5.5 là cái cớ tốt để đi thêm nó vào trước khi bản ra mắt kế tiếp khiến khoảng trống này càng khó giải thích hơn với người đang giữ ngân sách.

Xuất nội dung

Bình luận