Chi phí GPU của bạn không phải là vấn đề của mô hình.

Chi phí điện toán đám mây có một thói quen rất khó chịu. Nó chờ đợi cho đến khi mọi người đang nói về những trừu tượng thú vị, sau đó nó xuất hiện với hóa đơn nhàm chán. Đối với hạ tầng AI, trừu tượng thú vị là mô hình. Mô hình nào thông minh hơn? Mô hình nào có khả năng suy luận tốt hơn? Mô hình nào rẻ hơn trên mỗi triệu token? Mô hình nào có thể giải thích một lỗi kiểm thử với sự tự tin của một người hoàn toàn không chạy nó? Những câu hỏi hữu ích. Những câu hỏi chưa đầy đủ. OpenCost 1.121.0 đã bổ sung tính năng theo dõi chi phí suy luận Kubernetes với các số liệu llm-d và vLLM. Phần thú vị không chỉ là nó có thể tính toán chi phí mô hình và token. Phần thú vị là sự phân biệt mà nó buộc các nhóm nền tảng phải thực hiện. Chi phí công việc của mô hình là bao nhiêu? Và chi phí để giữ cho mô hình sẵn sàng là bao nhiêu? Đó không phải là cùng một câu hỏi. Sự khác biệt đó là nơi nhiều bảng tính AI tự lưu trữ bị loại bỏ. mô hình không phải là khối lượng công việc Khi các nhóm nói về chi phí AI, họ thường chuyển thẳng đến giá mỗi token. Điều đó có ý nghĩa đối với các API SaaS. Bạn gửi token. Bạn nhận token. Ở đâu đó giữa chừng, một hệ thống thanh toán thực hiện các công việc của hệ thống thanh toán và bảng điều khiển của bạn nhận thêm một con số nhỏ để khiến bạn buồn. Tự lưu trữ thay đổi hình dạng. Bây giờ bạn không chỉ mua suy luận. Bạn đang vận hành hạ tầng. Có GPU. Có bộ nhớ. Có một cổng. Có các pod. Có các trọng số mô hình nằm trong VRAM. Có định tuyến. Có hành vi bộ nhớ đệm. Có các không gian tên, nhóm, người thuê và có lẽ một triển khai mà không ai muốn chạm vào vì nó "tạm thời" vào tháng 3. Đây là lý do tại sao góc nhìn của OpenCost quan trọng. Nó kết nối phân bổ chi phí Kubernetes với các số liệu suy luận từ vLLM và llm-d. Nó đang cố gắng trả lời các câu hỏi về chi phí tại nơi khối lượng công việc thực sự chạy, không phải trong một slide nơi tất cả các GPU được sử dụng 100% một cách kỳ diệu và không ai phải trả tiền cho dung lượng nhàn rỗi. Slide đó rất đẹp. Nó cũng là hư cấu. chi phí sử dụng có thể nói dối bạn một cách lịch sự Sự phân biệt hữu ích là chi phí dựa trên sử dụng so với chi phí dựa trên phân bổ. Chi phí dựa trên sử dụng là về công việc đang hoạt động. Mô hình đã xử lý token. Tính toán GPU đã được tiêu thụ. Token đầu vào và đầu ra có chi phí xử lý thực tế. Lượt truy cập bộ nhớ đệm KV đã thay đổi chi phí đó. Tuyệt vời. Chi phí dựa trên phân bổ là về tính khả dụng. Mô hình được tải. Bộ nhớ GPU được dành riêng. Ngăn xếp phục vụ đang hoạt động. Hạ tầng chung đang chạy. Hệ thống sẵn sàng phản hồi ngay cả khi lưu lượng yêu cầu đang tạm dừng. Cả hai con số đều đúng. Chỉ một trong số đó trả lời câu hỏi xây dựng hay mua. Nếu một mô hình tự lưu trữ có giá một đô la cho mỗi triệu token khi nó đang hoạt động, và một API được lưu trữ có giá hai đô la cho mỗi triệu token, bảng tính bắt đầu mỉm cười. "Nhìn kìa, chúng ta rẻ hơn." Có thể. Nếu GPU đủ bận rộn. Nếu mô hình chủ yếu nhàn rỗi, chi phí thực tế trên mỗi token cũng bao gồm cả những giờ yên tĩnh. Một GPU với một mô hình được tải không phải là miễn phí vì hàng đợi yêu cầu trống. Nó chỉ đắt hơn theo một cách ít đẹp mắt hơn. Đây là cái bẫy. Chi phí dựa trên sử dụng có thể làm cho việc tự lưu trữ trông rẻ vì nó bỏ qua chi phí duy trì sự sẵn sàng. Chi phí dựa trên phân bổ bao gồm phần mà các nhóm sản xuất thực sự phải trả vào cuối tháng. Hóa đơn không quan tâm rằng điểm chuẩn của bạn hiệu quả trong bảy phút. dung lượng dự phòng là một quyết định sản phẩm Có một lý do khiến các nhóm giữ các mô hình ở trạng thái sẵn sàng. Độ trễ là yếu tố quan trọng. Khởi động nguội là điều không mong muốn. Người dùng không thích chờ đợi trong khi nền tảng của bạn từ từ khôi phục hoạt động. Một số tác vụ yêu cầu mô hình phải sẵn sàng ngay lập tức, không phải sau một quá trình lập lịch và tải dữ liệu phức tạp. Do đó, duy trì dung lượng "nóng" (warm capacity) có thể là lựa chọn đúng đắn. Tuy nhiên, đây phải là một lựa chọn có chủ đích. Không phải là một sự cố ngoài ý muốn. Đây là lúc AI FinOps trở thành kỹ thuật nền tảng. Câu hỏi hữu ích không phải là "mô hình này có đắt không?". Câu hỏi đó quá mơ hồ. Mọi thứ đều đắt đỏ nếu bạn nhìn kỹ khi có bộ phận mua sắm ở gần. Những câu hỏi tốt hơn mang tính thực tế hơn. Đội ngũ nào cần mô hình này hoạt động liên tục (warm)? Lưu lượng truy cập nào có thể chấp nhận xếp hàng hoặc mở rộng quy mô (scale-up)? Những tác vụ khối lượng thấp nào nên sử dụng API bên ngoài thay vì tự triển khai? Những mô hình nào có thể chia sẻ dung lượng? Những tuyến đường nào nên hợp nhất lưu lượng truy cập để cải thiện hiệu suất sử dụng? Những thử nghiệm nào đang âm thầm dự trữ phần cứng cấp độ sản xuất cho mục đích trình diễn? Điều này ít hào nhoáng hơn so với việc lựa chọn mô hình. Nhưng đây cũng là nơi tạo ra tiền. nhãn chi phí trở thành kiến trúc Một chi tiết tôi thích trong công việc của OpenCost là hình dạng nhãn. Các chỉ số mới bao gồm những thứ như tên mô hình, phiên bản mô hình, không gian tên (namespace), loại tác vụ và liệu cơ sở chi phí là sử dụng hay phân bổ. Nghe có vẻ nhàm chán. Tốt. Các nhãn nhàm chán là cách để hóa đơn trở nên dễ gỡ lỗi. Nếu không có chúng, chi phí AI sẽ trở thành một màn sương mù. Mọi người đều biết nền tảng đắt đỏ. Không ai biết liệu phần đắt đỏ là chatbot của một đội, công cụ tóm tắt hàng loạt của đội khác, một triển khai thử nghiệm (staging deployment) bị lãng quên, hay một mô hình không ai ngừng hoạt động vì phiếu di chuyển đã được đổi tên thành một sáng kiến lộ trình và sau đó biến mất. Phân bổ chi phí không chỉ là vệ sinh tài chính. Nó thay đổi hành vi kỹ thuật. Khi các đội có thể thấy chi phí duy trì một mô hình hoạt động liên tục (warm) cho không gian tên của họ, họ có thể có một cuộc trò chuyện thực tế về độ trễ, khối lượng và sự đánh đổi. Khi họ chỉ thấy một hóa đơn GPU tổng hợp, cuộc trò chuyện trở thành những cảm nhận chung chung với một tệp bảng tính đính kèm. Chúng ta đã từng chứng kiến điều này với Kubernetes trước đây. Các yêu cầu CPU (CPU requests) trông giống như các chi tiết YAML nhỏ cho đến khi các tác vụ yêu cầu quá mức trở thành tiền thật. Các lớp lưu trữ (storage classes) trông giống như hệ thống ống nước cho đến khi các ổ đĩa được giữ lại (retained volumes) trở thành hóa đơn. Nhật ký (logs) trông vô hại cho đến khi mọi người phát hiện ra rằng đầu ra gỡ lỗi cũng có một bộ phận thanh toán. Suy luận (Inference) đang nhận được sự đối xử tương tự. YAML giờ đây được kết nối với token. Tuyệt vời và khủng khiếp, như thường lệ. nền tảng sở hữu khoảng cách Khoảng cách giữa chi phí dựa trên sử dụng và chi phí dựa trên phân bổ là phần tôi sẽ theo dõi. Đó là chi phí của sự sẵn sàng. Đôi khi khoảng cách đó là lành mạnh. Một hệ thống chống gian lận, trợ lý sự cố hoặc quy trình làm việc hướng tới khách hàng có thể biện minh cho dung lượng hoạt động liên tục (warm capacity) vì...