Chi phí LLM tự lưu trữ trên mỗi triệu token: Mô hình chi phí GPU có thể tái lập

Chi phí LLM tự lưu trữ trên mỗi triệu token: Mô hình chi phí GPU có thể tái lập

Cách đáng tin cậy để tính chi phí LLM tự lưu trữ trên mỗi triệu token là chia tổng chi phí phục vụ đầy đủ cho số token mà khối lượng công việc của bạn thực sự chấp nhận—không phải cho thông lượng đỉnh được quảng cáo của GPU.

Sự khác biệt này rất quan trọng. Một GPU có thể đạt kết quả benchmark tốt, nhưng vẫn tốn kém trong môi trường sản xuất khi nó dành thời gian đã trả tiền để nhàn rỗi, xử lý các prompt dài bất thường, thử lại các yêu cầu thất bại hoặc tạo đầu ra mà sản phẩm của bạn từ chối. Hướng dẫn này cung cấp một mô hình có thể lặp lại cho chi phí LLM tự lưu trữ trên mỗi triệu token, một bảng tính, một ví dụ minh họa và cách công bằng để so sánh endpoint tự quản lý với API được quản lý.

Cập nhật ngày 16 tháng 10 năm 2026. Mọi số tiền bằng đô la và thông lượng bên dưới đều là đầu vào minh họa, không phải báo giá của nhà cung cấp hoặc tuyên bố về hiệu năng.

Công thức tính chi phí LLM tự lưu trữ trên mỗi triệu token

Đối với góc nhìn theo token đầu ra, sử dụng:

chi phí trên 1 triệu token đầu ra được chấp nhận =
  tổng chi phí phục vụ đầy đủ theo giờ
  / (token đầu ra/giây trong cửa sổ hoạt động × 3.600 × mức sử dụng thời gian trả phí × tỷ lệ thành công × tỷ lệ chấp nhận)
  × 1.000.000

Trong đó:

Mẫu số là yếu tố then chốt. Chi phí LLM tự lưu trữ trên mỗi triệu token phải là chi phí trên mỗi đơn vị hữu ích, không phải chi phí trên mỗi benchmark GPU.

Quy tắc không tính hai lần

Sử dụng một trong hai cách đo sau:

1. Đo thông lượng trong cửa sổ hoạt động, sau đó nhân với mức sử dụng thời gian trả phí.
2. Đo các token được chấp nhận trên toàn bộ khoảng thời gian trả phí, sau đó đặt mức sử dụng thành 1 vì thời gian nhàn rỗi đã được bao gồm trong quan sát.

Không làm cả hai. Áp dụng hệ số sử dụng cho thông lượng theo thời gian thực đã bao gồm thời gian nhàn rỗi sẽ khiến chi phí suy luận LLM trên mỗi token trông cao hơn thực tế. Bỏ mức sử dụng khỏi benchmark trong cửa sổ hoạt động sẽ khiến chi phí trông thấp hơn thực tế.

Bảng tính chi phí GPU trên mỗi triệu token có thể sao chép

Đặt một hàng trong bảng tính của bạn cho từng mô hình, cấu trúc phần cứng, khu vực và dạng khối lượng công việc. Không trộn benchmark hội thoại ngắn với khối lượng công việc sản xuất có ngữ cảnh dài.

Bảng tính giúp phép tính chi phí LLM tự lưu trữ trên mỗi triệu token có thể kiểm toán: một nhà vận hành khác phải có thể thay thế các đầu vào, chạy lại cửa sổ đo lường và tái lập kết quả.

Đây là phép tính minh họa, không phải bảng giá cho bất kỳ GPU nào. Thay thế năm đầu vào bằng các giá trị đo được sẽ tạo ra chi phí GPU trên mỗi triệu token của riêng bạn.

Ví dụ minh họa: vì sao mức sử dụng làm thay đổi kết quả

Giữ nguyên tổng chi phí đầy đủ theo giờ là $4.07 và 900 token đầu ra/giây trong cửa sổ hoạt động của endpoint giả định. Những thay đổi nhỏ trong đầu vào sẽ làm thay đổi mạnh chi phí đơn vị.

Bài học không phải là mua một bộ tăng tốc cụ thể. Bài học là định giá LLM tự lưu trữ là một mô hình vận hành-và-thông lượng. Chi phí nút theo giờ cao hơn có thể mang lại chi phí trên mỗi đầu ra được chấp nhận thấp hơn nếu nó có đủ bộ nhớ, dư địa cho batching và nhu cầu để duy trì nhiều công việc hữu ích hơn. Mức giá theo giờ thấp hơn có thể trở nên bất lợi khi năng lực nhàn rỗi và các lần thử lại xuất hiện trong mẫu số.

Tách prefill khỏi decode trước khi benchmark

Phục vụ LLM không phải là một khối lượng công việc đồng nhất. Suy luận có giai đoạn xử lý ngữ cảnh (prefill) và giai đoạn sinh (decode); hướng dẫn TensorRT-LLM của NVIDIA nêu rõ đây là các giai đoạn riêng biệt và nhấn mạnh việc tinh chỉnh theo từng loại khối lượng công việc. Xem hướng dẫn tinh chỉnh hiệu năng TensorRT-LLM trước khi coi bất kỳ con số token mỗi giây nổi bật nào là có tính đại diện.

• Prompt dài, ngữ cảnh truy xuất và tệp đính kèm lớn gây áp lực lên prefill và KV cache.
• Câu trả lời dài, sinh mã và suy luận tác tử gây áp lực lên năng lực decode và thời gian trên mỗi token đầu ra.
• Đồng thời cao khiến hành vi của scheduler, batching, độ lưu trú của cache và dư địa bộ nhớ trở thành một phần của mô hình giá.

Ghi nhận riêng các phân phối prompt và đầu ra. Đối với một trợ lý thiên về truy xuất với 20.000 token đầu vào và 300 token đầu ra, kinh tế học chỉ tính đầu ra có thể bỏ sót nút thắt thực sự. Đối với quy trình lập trình với 2.000 token đầu vào và 4.000 token đầu ra, decode có thể chiếm ưu thế.

Để so sánh chặt chẽ chi phí LLM tự lưu trữ trên mỗi triệu token, hãy duy trì ít nhất ba góc nhìn sau:

Đo mẫu số từ telemetry sản xuất

Đừng suy ra thông lượng được chấp nhận từ thông số kỹ thuật phần cứng. Stack phục vụ phải xuất các đầu vào giúp phép tính có thể tái lập.

Ví dụ, vLLM ghi nhận các metric Prometheus cho token prompt, token được sinh, yêu cầu hoàn tất, từ chối tiếp nhận, thời gian xếp hàng, thời gian prefill, thời gian decode, mức sử dụng KV-cache, thời gian đến token đầu tiên và độ trễ trên mỗi token đầu ra. Những metric này đủ để xây dựng bản ghi đo lường thay vì phỏng đoán từ một benchmark. Tài liệu tham chiếu metric của vLLM liệt kê tên và ý nghĩa metric hiện tại.

Ghi nhận bản ghi này cho mỗi lần chạy:

measurement_window_start/end
model_id and weights_precision
serving_engine and version
gpu_sku, gpu_count, interconnect, region
input_tokens_p50/p95 and output_tokens_p50/p95
concurrency and request-rate distribution
prompt_tokens_total and generation_tokens_total
request_success_total and admission_rejections_total
time_to_first_token_p50/p95 and time_per_output_token_p50/p95
KV-cache usage and OOM/timeout counts
paid capacity hours and fully loaded hourly cost
acceptance-rule version and accepted-output count

Telemetry phần cứng hữu ích, nhưng đó là công cụ chẩn đoán—không phải mẫu số chi phí đơn vị. Tài liệu profiling DCGM của NVIDIA lưu ý rằng activity là giá trị trung bình theo khoảng thời gian và cần được tương quan với thông lượng của khối lượng công việc đại diện. Sử dụng các metric profiling DCGM để điều tra xem năng lực tính toán, băng thông bộ nhớ hay hành vi interconnect có đang giới hạn lần chạy hay không; đừng thay thế mức sử dụng trong thời gian trả phí bằng một tỷ lệ phần trăm sử dụng GPU duy nhất.

Xây dựng tử số tính đủ chi phí

Giá thuê GPU là một đầu vào, không phải câu trả lời. Để tính chi phí phục vụ LLM một cách công bằng, hãy bao gồm chi phí năng lực và vận hành cần thiết cho cùng cửa sổ đo lường.

Đối với một dự án thí điểm, hãy báo cáo hai chỉ số:

Chi phí chỉ riêng GPU trên 1 triệu token
Chi phí đầy đủ trên 1 triệu token được chấp nhận

Khoảng chênh lệch không phải là sai sót; đó là chi phí vận hành của dịch vụ tự lưu trữ. Nó giúp quyết định định giá LLM tự lưu trữ có thể kiểm toán được.

Tính cả các lần thử lại và đầu ra bị từ chối

Token được tạo ra không tự động là token hữu ích. Một yêu cầu có thể tiêu tốn năng lực prefill và giải mã một phần trước khi hết thời gian chờ, tạo JSON không hợp lệ, thất bại khi gọi công cụ, vi phạm quy tắc chính sách hoặc không đạt ngưỡng chất lượng.

Sử dụng điều chỉnh mức độ chấp nhận mà đội ngũ sản phẩm của bạn có thể tái lập:

token đầu ra được chấp nhận =
  token đầu ra được tạo
  × tỷ lệ thực thi thành công
  × tỷ lệ chấp nhận của sản phẩm

Nếu mức độ chấp nhận được đo ở cấp yêu cầu, hãy ghi lại quy tắc chính xác: phiên bản bộ đánh giá, tập mẫu, trình xác thực schema, quy trình đánh giá của con người hoặc sự kiện thành công của tác vụ. Thay đổi quy tắc mà không lập phiên bản khiến xu hướng chi phí trở nên vô nghĩa.

Đây cũng là lý do chi phí suy luận LLM trên mỗi token thô có thể gây hiểu lầm. Một cấu hình tăng thông lượng 30% nhưng làm giảm tỷ lệ thành công của tác vụ được chấp nhận có thể tốn kém hơn ở lớp sản phẩm.

So sánh tự lưu trữ với API được quản lý trên cùng một đơn vị

Tự lưu trữ mua năng lực. API được quản lý mua mức sử dụng. Chúng chỉ trở nên có thể so sánh khi tử số và mẫu số tương ứng.

Sử dụng kiểm tra thông lượng hòa vốn này khi điểm chuẩn API được biểu thị bằng cùng một đơn vị:

token đầu ra/giây cần thiết trong khoảng thời gian hoạt động =
  chi phí phục vụ đầy đủ theo giờ × 1,000,000
  / (chi phí API được quản lý trên 1 triệu token đầu ra được chấp nhận × 3,600 × mức sử dụng × tỷ lệ thành công × tỷ lệ chấp nhận)

Trước khi quyết định, hãy đồng bộ các kiểm soát này trên cả hai phương án:

• Cùng một mô hình hoặc một mô hình tương đương về chất lượng đã được đánh giá rõ ràng.
• Cùng phân phối độ dài prompt và đầu ra.
• Cùng SLO độ trễ và đặc điểm mức độ đồng thời.
• Cùng các quy tắc thử lại, dự phòng và chấp nhận.
• Cùng cách xử lý lượt truy cập cache, lỗi công cụ và công việc bị hủy.

Nếu quyền kiểm soát GPU trực tiếp, trọng số tùy chỉnh, yêu cầu bố trí cứng hoặc một ngăn xếp kernel chuyên biệt là yêu cầu bắt buộc, tự lưu trữ vẫn có thể là lựa chọn đúng ngay cả khi chi phí cao hơn mức cơ sở được quản lý. Nếu lưu lượng thấp hoặc biến động, mô hình thay đổi thường xuyên hoặc đội ngũ không muốn vận hành hạ tầng suy luận, API tính phí theo mức sử dụng có thể hấp thụ rủi ro sử dụng.

Để so sánh mua sắm rộng hơn, xem hướng dẫn GPU cloud so với model API và hướng dẫn giá thuê GPU của Flatkey. Khi không cần quyền kiểm soát GPU trực tiếp, phương án được quản lý là một điểm chuẩn hữu ích: Flatkey cung cấp API mô hình và công cụ hợp nhất với một số dư duy nhất, nhờ đó các đội ngũ có thể so sánh phương án được quản lý với phép tính tự lưu trữ mà không phải duy trì các khóa nhà cung cấp riêng biệt. Bắt đầu thiết lập mức cơ sở API Flatkey với cùng tập kiểm thử và quy tắc chấp nhận.

Bài kiểm tra mua sắm gồm bảy bước

Hãy sử dụng khuôn khổ chi phí LLM tự lưu trữ trên mỗi triệu token này như một tài liệu mua sắm, không chỉ là một điểm chuẩn kỹ thuật. Nó phải cho thấy chính xác giả định nào về khối lượng công việc, năng lực và chất lượng đã làm thay đổi kết quả.

1. Xác định đơn vị: token đầu vào, token đầu ra, token kết hợp, phản hồi được chấp nhận hoặc tác vụ được chấp nhận.
2. Đo thông lượng trong khoảng thời gian hoạt động dưới lưu lượng có đặc điểm giống môi trường sản xuất, thay vì chỉ một prompt tổng hợp.
3. Đo mức sử dụng trong thời gian trả phí trên mọi bản sao trả phí và nút dự phòng luôn sẵn sàng.
4. Thêm toàn bộ chi phí vận hành vào tử số theo giờ.
5. Lập phiên bản cho các quy tắc thành công và chấp nhận, rồi tính đầu ra được chấp nhận.
6. Chạy cùng khối lượng công việc qua mức cơ sở API được quản lý.
7. Xem xét đồng thời chi phí, độ trễ p95, độ tin cậy, chất lượng và nỗ lực kỹ thuật trước khi đặt trước năng lực.

Các lỗi phổ biến trong mô hình chi phí LLM tự lưu trữ

Sử dụng thông lượng điểm chuẩn đỉnh. Mức đỉnh hữu ích để so sánh một thiết lập được kiểm soát. Đây không phải là thông lượng kỳ vọng của tổ hợp sản xuất của bạn.

Gọi mức sử dụng GPU là mức sử dụng năng lực. Một GPU bận vẫn có thể được gắn với một endpoint có quy mô quá lớn so với nhu cầu trả phí. Hãy sử dụng mức sử dụng trong thời gian trả phí cho kinh tế đơn vị và dùng đo từ xa phần cứng để chẩn đoán nguyên nhân.

Áp dụng mức sử dụng hai lần. Hãy chọn thông lượng trong khoảng thời gian hoạt động cộng với mức sử dụng, hoặc thông lượng theo thời gian thực đã bao gồm thời gian nhàn rỗi.

Bỏ qua token đầu vào. Ngữ cảnh dài làm tăng áp lực prefill và bộ nhớ đệm KV ngay cả khi sản phẩm chủ yếu tính phí theo đầu ra.

Coi mọi token được tạo ra đều được chấp nhận. Thử lại, đối số công cụ không hợp lệ, lỗi schema và các trường hợp bị loại vì chất lượng đều là công việc phải trả phí.

Chỉ so sánh hóa đơn GPU với giá niêm yết API. Kỹ thuật, hỗ trợ, lưu trữ, mạng, khả năng quan sát và năng lực dự phòng đều phải được đưa vào cùng một phép tính.

Để có quyết định đầy đủ (khi nào tự lưu trữ có lợi, định cỡ bộ nhớ GPU, công cụ và thiết lập máy chủ từng bước), hãy xem hướng dẫn LLM tự lưu trữ của chúng tôi.

Câu hỏi thường gặp

Làm thế nào để tính chi phí LLM tự lưu trữ trên mỗi triệu token?

Chia chi phí phục vụ theo giờ đã bao gồm toàn bộ chi phí cho số token được chấp nhận mỗi giờ tính phí, sau đó nhân với 1.000.000. Hãy sử dụng thông lượng đo được giống môi trường sản xuất, mức sử dụng trong thời gian tính phí, tỷ lệ thành công và tỷ lệ chấp nhận — không phải mức đỉnh GPU trên lý thuyết.

Chi phí GPU trên mỗi triệu token có giống chi phí suy luận LLM trên mỗi token không?

Chi phí GPU trên mỗi triệu token có thể là một chỉ số hạ tầng chỉ bao gồm GPU. Chi phí suy luận LLM trên mỗi token nên bao gồm tử số vận hành liên quan và mẫu số được xác định rõ ràng. Đối với quyết định sản phẩm, chi phí trên mỗi phản hồi hoặc tác vụ được chấp nhận thường là chỉ số bổ trợ an toàn hơn.

Tôi nên dùng token đầu ra hay tổng số token?

Hãy dùng cả hai khi chi phí đầu vào và đầu ra có các nút thắt khác nhau. Token đầu ra dễ so sánh cho khối lượng công việc sinh nội dung; tổng token hoặc token có trọng số thể hiện tốt hơn khối lượng công việc truy xuất ngữ cảnh dài. Giữ đơn vị giống hệt nhau khi so sánh tự lưu trữ với API.

Khi nào tự lưu trữ giúp tiết kiệm chi phí?

Khả năng tiết kiệm chi phí cao hơn khi nhu cầu ổn định, năng lực được sử dụng tốt, mô hình và việc triển khai ổn định, đồng thời quyền kiểm soát trực tiếp mang lại giá trị. Khả năng này thấp hơn khi lưu lượng biến động đột ngột, lựa chọn mô hình thay đổi thường xuyên hoặc chi phí vận hành vượt quá khoản tiết kiệm từ năng lực.

Kết luận

Con số chi phí LLM tự lưu trữ trên mỗi triệu token có cơ sở là năng lực tính phí đã bao gồm toàn bộ chi phí chia cho thông lượng được chấp nhận. Hãy đo prefill và decode riêng biệt, tính thời gian nhàn rỗi một lần, quản lý phiên bản quy tắc chấp nhận và so sánh đường cơ sở được quản lý theo cùng một đơn vị. Điều đó biến báo giá GPU thành một mô hình chi phí sẵn sàng cho việc ra quyết định.

Tài liệu tham khảo kỹ thuật

• Tài liệu tham khảo về chỉ số vLLM
• Hướng dẫn tinh chỉnh hiệu năng NVIDIA TensorRT-LLM
• Tài liệu về profiling NVIDIA DCGM