Thực hànhTrung cấp

Đo chi phí mỗi tác vụ, đừng chỉ nhìn giá mỗi token

Gắn token, công cụ, retry và kết quả cuối vào cùng một công việc để biết chi phí thực sự của ứng dụng AI.

Trong bài viết này

Từ được đánh dấu có giải thích. Di chuột hoặc chạm để xem, hay mở từ điển AI.

Một lần gọi mô hình rẻ hơn nhưng thường cần sửa đầu ra rồi gọi lại. Một cấu hình khác tốn hơn ở lượt đầu nhưng trả kết quả dùng được ngay. So sánh giá mỗi lượt có thể khiến bạn chọn phương án đắt hơn cho cả công việc.

Đơn vị cần đo là tác vụ mà người dùng muốn hoàn thành, chẳng hạn tạo một bản tóm tắt đạt tiêu chí hoặc xử lý một hồ sơ hợp lệ.

Định nghĩa điểm bắt đầu và kết thúc

Trong ví dụ giả định, một tác vụ bắt đầu khi người dùng gửi tài liệu và kết thúc khi có bản tóm tắt đã qua kiểm tra. Các lần truy xuất, gọi mô hình, sửa định dạng và thử lại đều thuộc cùng mã tác vụ.

Nếu người dùng bấm “viết lại”, hãy quyết định đó là nhánh của tác vụ cũ hay tác vụ mới theo mục tiêu đo lường. Không có cách chia luôn đúng, nhưng phải nhất quán để so sánh giữa các cấu hình.

Tách “đã trả phản hồi” khỏi “đã hoàn thành đạt yêu cầu”. Một thông báo lỗi nhanh vẫn là phản hồi, nhưng không nên được tính vào mẫu số tác vụ thành công. Đồng thời giữ tổng số yêu cầu để không che giấu mức thất bại.

Ghi chi phí theo từng bước

Một bảng sự kiện minh họa có các trường: mã tác vụ, bước, mô hình, token đầu vào, token đầu ra, trạng thái cache, công cụ được dùng, số lần thử và trạng thái cuối.

Tài liệu token counting của Anthropic phân biệt khả năng đếm token trước yêu cầu với số liệu sử dụng trả về từ API. Ước tính trước hữu ích để đặt ngân sách; số liệu thực tế và quy tắc tính phí của dịch vụ mới là cơ sở đối soát sau khi chạy.

Công thức khái niệm:

chi phí tác vụ = tổng chi phí các lượt mô hình
              + công cụ và truy xuất
              + phần hạ tầng được phân bổ

Không cộng token cache như token thường nếu cách tính phí phân loại chúng khác nhau. Ghi ngày hiệu lực của bảng giá dùng để tính, nhưng đừng nhúng giá cố định vào logic báo cáo mà không có cách cập nhật.

Nhìn để hiểuMột câu trả lời lớn lên từng token

Mô hình tự hồi quy tính xác suất token tiếp theo từ ngữ cảnh hiện có, chọn một token rồi nối vào chuỗi. Chuỗi mới trở thành ngữ cảnh cho lượt tiếp theo.

Sinh văn bản bằng cách nối tiếp tokenSơ đồ dùng các từ Hôm, nay, trời, đẹp làm token giả định để dễ quan sát. Token thật có thể nhỏ hơn một từ. Mô hình dùng chuỗi hiện có để dự đoán token kế tiếp, chọn một token rồi lặp lại; các thanh xác suất chỉ mang tính minh họa.CHUỖI HIỆN CÓHômnayTOKEN CÓ THỂ TIẾP THEOtrờitôicótrờiChọn một tokenvà ghép vào chuỗiđẹp…Ngữ cảnh được nối dàiLặp lại cho token kế tiếpTách theo từ ở đây chỉ để minh họa.

↔ Vuốt ngang để xem toàn bộ sơ đồ.

  1. 01 / Đọc ngữ cảnh

    Mô hình xử lý các token của yêu cầu và phần trả lời đã có.

  2. 02 / Tính xác suất

    Từ ngữ cảnh đó, mô hình tính phân bố xác suất cho những token có thể xuất hiện tiếp theo.

  3. 03 / Chọn token

    Cách giải mã quyết định token được chọn; không phải lúc nào cũng lấy token có xác suất cao nhất.

  4. 04 / Nối và lặp

    Token được nối vào chuỗi để tạo ngữ cảnh mới. Quá trình lặp đến điều kiện dừng.

Các ô dùng từ nguyên vẹn để dễ quan sát; đây không phải kết quả của một tokenizer cụ thể. Token thực tế có thể chỉ là một phần của từ.

Tính trên kết quả đạt yêu cầu

Giả sử cấu hình A tốn 100 đơn vị chi phí nội bộ để xử lý một lô và có 80 tác vụ đạt; cấu hình B tốn 120 đơn vị và có 110 tác vụ đạt. Đây hoàn toàn là số giả định để minh họa phép chia, không phải giá dịch vụ hay benchmark.

A tốn 1,25 đơn vị cho mỗi tác vụ đạt; B khoảng 1,09. Nếu chỉ nhìn tổng chi, A có vẻ rẻ hơn. Tuy nhiên, phép so sánh chỉ có ý nghĩa khi đầu vào và tiêu chí đạt tương đương; hai lô có độ khó khác nhau sẽ làm kết luận sai lệch.

Ngoài trung bình, xem nhóm tác vụ tốn nhiều nhất. Tài liệu dài, công cụ lỗi hoặc vòng sửa liên tục có thể tạo phần đuôi chi phí lớn. Một ngân sách chung theo tài khoản không chỉ ra nhóm nguyên nhân này.

Cắt chi phí theo nguyên nhân

Nếu phần đầu vào lặp chiếm nhiều tài nguyên, xem lại cách dựng ngữ cảnh và cache. Nếu đầu ra quá dài, sửa yêu cầu sản phẩm và giới hạn độ dài hợp lý. Nếu retry chiếm nhiều, sửa tính ổn định trước khi chọn mô hình rẻ hơn.

Giảm số tài liệu đưa vào có thể tiết kiệm nhưng làm mất bằng chứng quan trọng. Giảm độ dài đầu ra có thể cắt mất điều kiện hoặc cảnh báo cần thiết. Mỗi thay đổi cần chạy lại bộ đánh giá liên quan, không chỉ kiểm tra hóa đơn giảm.

Lỗi thường gặp là bỏ chi phí các lần thất bại khỏi báo cáo. Người dùng không nhận được kết quả, nhưng hệ thống vẫn có thể đã tiêu thụ tài nguyên. Đối soát tổng số liệu ở cấp tác vụ với báo cáo nhà cung cấp để phát hiện bước bị ghi thiếu.

Bài tập: tìm khoản chi bị ẩn

Tạo một bảng giả định gồm tác vụ thành công ngay, tác vụ cần sửa schema và tác vụ thất bại sau retry. Gán đơn vị chi phí tự chọn cho từng lượt, ghi rõ đây là dữ liệu minh họa.

Tiêu chí đạt: tổng chi bao gồm cả thất bại, mỗi tác vụ chỉ được đếm một lần trong mẫu số phù hợp và bạn giải thích được cấu hình nào rẻ hơn trên cùng tiêu chí chất lượng. Sau đó đề xuất một tối ưu có thể đo được cùng chỉ số chất lượng cần bảo vệ.

Bạn muốn hiểu điều gì?

Khám phá tất cả bài viết esc để đóng