Novita vừa mới cập nhật bảng giá LLM của mình. Đối với các đội ngũ đang chạy suy luận (inference) thực tế thông qua nền tảng này, câu nói đó nên là tín hiệu để bạn thực hiện kiểm tra ngay lập tức mức chi tiêu hiện tại của mình. Những thay đổi về giá API hiếm khi đến vào thời điểm thuận tiện, và khi chúng tác động lên nhiều cấp độ mô hình khác nhau, ảnh hưởng đến mức tiêu thụ ngân sách hàng tháng của bạn có thể lớn hơn dự kiến.

Tại sao giá suy luận xứng đáng để bạn dành sự chú ý

Hầu hết các ứng dụng AI hiện đại không được xây dựng trên các cụm GPU tự quản lý. Các nhà phát triển chuyển hướng yêu cầu đến các nhà cung cấp suy luận như Novita vì phương án thay thế đòi hỏi phải đảm bảo phần cứng, quản lý việc triển khai vLLM hoặc TGI, và xử lý tình trạng khởi động lạnh (cold starts) trong các đợt lưu lượng truy cập tăng đột biến. Sự tiện lợi đó rất có giá trị, nhưng nó cũng được tính phí theo định mức. Mỗi token được tạo ra đều cộng thêm vào hóa đơn, tích tụ qua các phiên người dùng, các tác vụ chạy ngầm và các công cụ nội bộ.

Khi một nhà cung cấp điều chỉnh giá, hiệu ứng sẽ lan tỏa qua toàn bộ hệ thống (stack) của bạn. Một chatbot xử lý mười nghìn cuộc hội thoại khách hàng mỗi ngày có thể tiêu thụ bốn mươi triệu token đầu vào và mười hai triệu token đầu ra trong một tuần. Chỉ cần thay đổi mức giá trên mỗi triệu token dù chỉ vài đô la, sự chênh lệch hàng tháng sẽ nhanh chóng trở nên đáng kể. Đối với các sản phẩm tự thân (bootstrapped) hoặc các đội ngũ hoạt động với biên lợi nhuận thấp, sự chênh lệch đó có thể xóa sạch lợi nhuận. Một trợ lý lập trình chạy dưới dạng tiện ích mở rộng trình duyệt, một quy trình tóm tắt hàng loạt xử lý qua đêm, hay một công cụ tra cứu nội bộ truy vấn mô hình sau mỗi lần tải trang đều có chung một điểm yếu. Kinh tế học đơn vị (unit economics) của chúng phụ thuộc vào chính xác giá của token tiếp theo.

Những gì đã thay đổi tại Novita

Novita đã triển khai các mức chi phí mới ảnh hưởng đến các mô hình khác nhau trong danh mục của mình. Công ty không áp dụng một mức tăng hoặc giảm phần trăm đồng nhất cho tất cả. Thay vào đó, các điều chỉnh thay đổi tùy theo từng mô hình, điều đó có nghĩa là hóa đơn của bạn sẽ thay đổi tùy thuộc vào chính xác các endpoint mà bạn đang sử dụng.

Nếu ứng dụng của bạn chuyển hướng toàn bộ lưu lượng qua một mô hình ngôn ngữ lớn duy nhất, việc tính toán sẽ rất đơn giản. Hãy so sánh mức giá cũ với mức giá mới và dự tính thiệt hại hoặc khoản tiết kiệm. Nhưng hầu hết các thiết lập thực tế đều phức tạp hơn. Các đội ngũ thường duy trì logic định tuyến để gửi các truy vấn đơn giản đến các mô hình nhẹ hơn và dành các mô hình "nặng ký" cho các tác vụ suy luận phức tạp. Những đội ngũ khác lại chạy các thử nghiệm A/B trên nhiều mô hình để so sánh độ trễ và chất lượng. Trong những kịch bản đó, sự thay đổi giá chỉ ở một hoặc hai mô hình cũng có thể làm biến dạng toàn bộ cấu trúc chi phí của bạn.

Các con số cụ thể về mỗi token và mỗi yêu cầu được trình bày chi tiết trong một bài phân tích do Narevbot đăng trên Dev.to. Bạn có thể xem bảng giá chính xác tại đây: https://dev.to/narevbot/changes-to-llm-pricing-novita-3plc

Đừng dựa vào trí nhớ hay một ảnh chụp màn hình cũ nằm đâu đó trong tài liệu của bạn. Hãy lấy các con số hiện tại trực tiếp từ nguồn đó trước khi bạn lập kế hoạch cho quý tiếp theo.

Cách kiểm tra mức độ rủi ro của bạn

Hãy bắt đầu với dữ liệu, thay vì những giả định. Đăng nhập vào bảng điều khiển (dashboard) Novita của bạn và xuất lịch sử sử dụng trong hai đến ba tháng qua. Phân loại dữ liệu đó theo mô hình và theo loại hoạt động. Bạn cần biết endpoint nào đang tiêu tốn phần lớn ngân sách và endpoint nào đang tạo ra nhiều token nhất trên mỗi yêu cầu.

Hãy tìm kiếm các mô hình sau:

  • Rủi ro tập trung. Nếu 70% chi tiêu của bạn đổ dồn vào một mô hình và mô hình đó tăng giá, mức độ cấp bách là điều hiển nhiên. Nếu chi tiêu của bạn rải rác qua tám mô hình và ba trong số đó thay đổi giá, việc tính toán sẽ mất nhiều thời gian hơn nhưng mức độ rủi ro vẫn là có thật.
  • Lạm phát token. Kiểm tra xem các prompt của bạn có đang phình to với những ngữ cảnh không cần thiết hay không. Các system prompt dài, các ví dụ few-shot lặp đi lặp lại và định dạng XML rườm rà đều làm tăng chi phí đầu vào. Một đợt cập nhật giá là cái cớ hoàn hảo để cắt giảm những phần dư thừa.
  • Hiệu suất đầu ra kém. Nếu ứng dụng của bạn yêu cầu các phản hồi dài nhưng chỉ sử dụng vài câu đầu tiên, bạn đang phải trả tiền cho những token mà bạn bỏ đi. Hãy điều chỉnh giới hạn max_token và các chuỗi dừng (stop sequences).
  • Các tác vụ chạy ngầm nhàn rỗi. Một tác vụ được lập lịch để tạo báo cáo hoặc nhúng (embed) tài liệu có thể đang chạy thường xuyên hơn mức cần thiết. Hãy kiểm tra lại lịch trình cron và kích thước lô (batch size).