Nếu bạn đang vận hành các khối lượng công việc thực tế (production workloads) trên các mô hình ngôn ngữ lớn, bạn đã biết rằng hiệu suất mô hình chỉ là một nửa cuộc chiến. Nửa còn lại chính là hóa đơn vào cuối tháng. Ba nhà cung cấp—Mancer 2, Novita và StreamLake—gần đây đã điều chỉnh giá mô hình của họ. Nếu bạn đang phụ thuộc vào bất kỳ API nào trong số này, hóa đơn tiếp theo của bạn có thể sẽ khác so với hóa đơn trước đó.
Điều này không còn là chuyện lạ nữa. Thị trường LLM vẫn đang thử nghiệm các cách tính phí cho quá trình suy luận (inference). Một số nhà cung cấp tính phí trên mỗi nghìn token. Những nhà cung cấp khác lại gom các yêu cầu thành các gói (tiers) hoặc cung cấp các mức chiết khấu cho việc sử dụng liên tục. Khi một nền tảng thay đổi đơn giá hoặc cấu trúc lại các gói dịch vụ, tác động lên ngân sách của bạn có thể dao động từ một sự phiền toái nhỏ đến việc vượt quá chi phí nghiêm trọng. Việc theo dõi các cập nhật này không phải là một lựa chọn, mà là một phần của công việc.
Tại sao việc định giá API xứng đáng để bạn dành sự chú ý
Các nhà phát triển thường coi việc định giá API là một hạng mục "thiết lập xong rồi quên luôn". Bạn đánh giá hiệu năng (benchmark) một mô hình, chọn một nhà cung cấp và tiếp tục xây dựng các tính năng. Điều đó sẽ ổn cho đến khi nó không còn ổn nữa. Trong bối cảnh hiện tại, các thay đổi về giá có thể xảy ra mà không có bất kỳ thông báo rầm rộ nào. Một nhà cung cấp có thể giảm chi phí cho một mô hình cũ trong khi tăng giá cho endpoint mới hơn của họ. Một nhà cung cấp khác có thể áp dụng thêm phụ phí cho token đầu ra (output token) mà quý trước chưa hề có. Nếu bạn không theo dõi, bạn sẽ chỉ nhận ra khi hóa đơn đám mây gửi đến.
Sự chi tiết trong cách tính phí LLM khiến việc này trở nên đặc biệt phức tạp. Bạn hiếm khi trả một mức phí cố định hàng tháng. Thay vào đó, bạn đang trả tiền cho từng token đầu vào (prompt token) và từng token đầu ra (completion token). Việc tăng giá ở phía đầu ra có thể gây đau đớn hơn so với phía đầu vào, vì các phản hồi (completions) thường dài hơn các câu lệnh (prompts). Nếu ứng dụng của bạn tạo ra văn bản dài, mã nguồn hoặc các chuỗi suy luận nhiều bước, một sự gia tăng nhỏ trên mỗi token sẽ nhanh chóng nhân lên theo quy mô.
Ngoài ra còn có vấn đề về sự trôi dạt (drift). Hồ sơ token của ứng dụng của bạn thay đổi theo thời gian. Bạn có thể thêm một system prompt mới tiêu tốn nhiều token đầu vào hơn. Bạn có thể chuyển sang kỹ thuật chain-of-thought prompting tạo ra các đầu ra dài hơn. Ngay cả khi giá của nhà cung cấp giữ nguyên, chi phí của bạn vẫn sẽ thay đổi. Khi giá của nhà cung cấp cũng biến động cùng lúc, tác động cộng hưởng có thể khiến một đội ngũ thiếu sự giám sát bị bất ngờ.
Những gì đã thay đổi
Mancer 2, Novita và StreamLake đều đã triển khai các điều chỉnh về giá. Các chi tiết cụ thể khác nhau tùy theo nền tảng, nhưng xu hướng chung là giống nhau: cấu trúc chi phí bạn đã sử dụng tháng trước có thể không còn áp dụng ở hiện tại.
Mancer 2 đã cập nhật giá mô hình, điều này có nghĩa là các nhà phát triển đang sử dụng các endpoint của họ cần đánh giá lại chi phí trên mỗi yêu cầu. Nếu bạn đã lưu trữ các bảng giá cũ trong tài liệu nội bộ, những con số đó đã lỗi thời.
Novita cũng đã thực hiện các điều chỉnh giá trên toàn bộ các dịch vụ của mình. Đối với các đội ngũ chọn Novita vì nó phù hợp với một mức ngân sách cụ thể, các mức giá mới có thể làm thay đổi tổng chi phí sở hữu (total cost of ownership) cho các dự án đang triển khai.
StreamLake cũng đã thay đổi cách định giá. Bất kỳ tích hợp nào được xây dựng dựa trên bảng giá trước đây của StreamLake nên được xem xét lại trước khi chu kỳ thanh toán tiếp theo bắt đầu.
Vì đây là ba nền tảng riêng biệt với ba mô hình định giá khác nhau, nên không có quy tắc chung nào về việc bạn sẽ phải trả nhiều hơn hay ít hơn. Một nhà cung cấp có thể đã giảm giá cho các gói khởi đầu (starter-tier) trong khi tăng giá cho các gói thông lượng cao cấp (premium throughput). Một nhà cung cấp khác có thể đã điều chỉnh phí phụ thu cho cửa sổ ngữ cảnh (context-window premiums). Giả định an toàn duy nhất là bảng tính cũ của bạn đã không còn chính xác.
Những chi phí ẩn khi phớt lờ các thay đổi về giá
Hãy xem xét điều này thực sự có ý nghĩa gì trong thực tế. Giả sử bạn vận hành một trợ lý hỗ trợ khách hàng xử lý mười nghìn cuộc hội thoại mỗi ngày. Mỗi lượt trao đổi trung bình tiêu tốn hai nghìn token đầu vào và bốn trăm token đầu ra. Một thay đổi dù chỉ vài cent trên mỗi triệu token cũng có thể cộng dồn thành hàng trăm đô la mỗi tháng. Nếu thay đổi giá ảnh hưởng đến token đầu ra và trợ lý của bạn bắt đầu tạo ra các phản hồi dài hơn do bạn đã nâng cấp mô hình, bạn sẽ bị ảnh hưởng gấp đôi.
Tiếp theo là hiệu ứng nhân bản (multiplier effect). Nhiều ứng dụng không gọi LLM chỉ một lần cho mỗi yêu cầu của người dùng. Họ gọi nó trong một vòng lặp, hoặc trong một quy trình (pipeline) với các bước truy xuất (retrieval), hoặc có các phương án dự phòng (fallbacks) sang các mô hình phụ. Một thay đổi giá ở mô hình dự phòng có vẻ không khẩn cấp, cho đến khi mô hình chính của bạn chạm giới hạn tốc độ (rate limit) và bạn phải tiêu tốn một ngày thứ Tư mưa gió với mô hình dự phòng đắt đỏ hơn.
Vượt ngân sách không phải là rủi ro duy nhất. Nếu giá giảm mà bạn không nhận ra, bạn có thể đang hạn chế (throttling) mức độ sử dụng một cách không cần thiết. Lẽ ra bạn có thể phục vụ nhiều người dùng hơn, xử lý các tài liệu lớn hơn hoặc giảm giá bán cho khách hàng của chính mình. Sự thiếu hiểu biết luôn mang lại tác động theo cả hai hướng.
Cách xây dựng thói quen theo dõi chi phí
Bạn không cần một đội ngũ tài chính doanh nghiệp để kiểm soát việc này. Bạn chỉ cần một quy trình và một nơi để ghi lại các thay đổi.
Hãy bắt đầu bằng việc tập trung hóa các bảng giá của bạn. Hãy duy trì một tài liệu đơn giản—cho dù đó là một trang wiki dùng chung, một bảng Notion, hay một tin nhắn được ghim trong kênh dev của bạn—liệt kê giá hiện tại trên mỗi token hoặc mỗi yêu cầu cho mọi mô hình bạn đang sử dụng. Khi một nhà cung cấp thông báo thay đổi, hãy cập nhật tài liệu ngay lập tức. Đừng đợi đến buổi sprint review.
Tiếp theo, hãy gắn thẻ (tag) mức độ sử dụng theo nhà cung cấp và theo mô hình. Hầu hết các công cụ quan sát (observability tools) đều cho phép bạn đính kèm siêu dữ liệu tùy chỉnh (custom metadata) vào các lệnh gọi API. Hãy sử dụng các thẻ đó để tạo báo cáo tóm tắt chi phí hàng tuần. Nếu bạn thấy một sự gia tăng đột biến, bạn có thể truy vết nguyên nhân là do mức độ sử dụng tăng hay do thay đổi về giá chỉ trong vài giây thay vì vài ngày.
Xây dựng một cảnh báo tốc độ tiêu thụ (burn-rate alert). Việc này không cần phải quá cầu kỳ. Một đoạn mã (script) được lập lịch để truy vấn bảng điều khiển sử dụng và gửi một con số lên Slack mỗi sáng là đủ. Khi con số đó nhảy vọt, bạn sẽ biết ngay trong ngày, chứ không phải ba mươi ngày sau khi bộ phận tài chính gửi một email giận dữ.
Xem xét lại các lựa chọn mô hình của bạn hàng quý. Mô hình tốt nhất cho trường hợp sử dụng của bạn vào tháng Một có thể không còn là tốt nhất vào tháng Sáu, không phải vì mô hình đó kém đi, mà vì bối cảnh giá cả đã thay đổi. Một nhà cung cấp từng quá đắt đỏ có thể đã giảm giá. Một lựa chọn giá rẻ yêu thích có thể đã tăng giá. Hãy chạy lại các bài kiểm tra hiệu năng (benchmarks) của bạn dựa trên giá thực tế, không phải giá trong quá khứ.
Cuối cùng, hãy tính đến yếu tố giá cả trong các quyết định kiến trúc của bạn. Nếu bạn biết một nhà cung cấp thường xuyên thay đổi giá, hãy thiết kế hệ thống sao cho bạn có thể hoán đổi các điểm cuối (endpoints) mà không cần phải viết lại một nửa mã nguồn (codebase). Hãy trừu tượng hóa client đằng sau một giao diện nội bộ. Hãy giữ tên mô hình trong một tệp cấu hình, thay vì viết cứng (hard-coded) trong lớp prompt (prompt layer) của bạn.
Nơi để nhận các cập nhật đáng tin cậy
Blog và tài liệu của nhà cung cấp là những nguồn chính thức, nhưng chúng rất dễ bị bỏ lỡ trong một tuần làm việc bận rộn. Một lựa chọn là theo dõi các bản tổng hợp được chọn lọc chuyên theo dõi chính xác những loại thay đổi này trong toàn bộ hệ sinh thái. Để xem phân tích đầy đủ về các điều chỉnh gần đây của Mancer 2, Novita và StreamLake, hãy kiểm tra bản tóm tắt chi tiết tại đây:
Changes to LLM Pricing: Mancer 2, Novita, and StreamLake
Nếu bạn muốn luôn nắm bắt thông tin và so sánh ghi chú với những nhà phát triển khác đang cố gắng giữ cho hóa đơn hạ tầng AI ở mức hợp lý, cũng có một cộng đồng đáng để tham gia:
Cách phòng thủ tốt nhất trước các hóa đơn bất ngờ là một mạng lưới những người sẽ cảnh báo các thay đổi ngay khi chúng xảy ra.
Bài học thực tế quan trọng nhất
Sự biến động về giá là một đặc tính của thị trường LLM hiện tại, chứ không phải là một lỗi. Các mô hình trở nên rẻ hơn để vận hành, các nhà cung cấp thử nghiệm các cấu trúc giá, và sự cạnh tranh đẩy các con số thay đổi. Đó là tin tốt về lâu dài, nhưng chỉ khi bạn chú ý. Hãy đối xử với chi phí API giống như cách bạn đối xử với các chỉ số thời gian hoạt động (uptime metrics): đo lường chúng, thiết lập cảnh báo và kiểm tra chúng thường xuyên. Những thay đổi gần đây từ Mancer 2, Novita và StreamLake chỉ là lời nhắc nhở mới nhất rằng mức giá cho hệ thống AI (AI stack) của bạn không bao giờ thực sự cố định.