Việc lựa chọn giữa dung lượng GPU theo on-demand và spot không chỉ là bài toán bảng giá. Mức giá theo giờ rẻ hơn có thể trở nên bất lợi nếu job phải khởi động lại, checkpoint yếu, dữ liệu phải tải lại, hoặc kỹ sư mất nhiều ngày để giữ cho các máy có thể bị ngắt quãng luôn hoạt động. Dung lượng GPU reserved cũng có thể trông rẻ hơn cho đến khi nhu cầu mô hình thay đổi và đội ngũ bị “khóa” vào phần cứng không được sử dụng hết.
Hướng dẫn này so sánh giá GPU on-demand, spot và reserved dành cho người mua hạ tầng AI, các nhóm FinOps và kỹ sư nền tảng cần một mô hình ra quyết định thực tế theo khối lượng công việc. Câu trả lời ngắn gọn: dùng GPU on-demand cho các phép đo ban đầu và công việc khẩn cấp, GPU spot cho khối lượng công việc batch có khả năng chịu lỗi, và dung lượng GPU reserved chỉ sau khi bạn chứng minh được mức sử dụng nền tảng.
Nếu bạn vẫn đang cân nhắc liệu có nên thuê GPU hay không, hãy bắt đầu với các hướng dẫn rộng hơn về giá thuê GPU và GPU cloud so với model API. Bài viết này tập trung vào lựa chọn mô hình giá sau khi bạn đã xác định rằng dung lượng GPU là một phần của kế hoạch.
Câu trả lời nhanh: on-demand vs spot GPU vs reserved
Với hầu hết các đội, cách tiếp cận ban đầu nên như sau:
| Mô hình giá | Phù hợp nhất với | Rủi ro chính | Chỉ số cần theo dõi |
|---|---|---|---|
| GPU on-demand | Benchmark, thử nghiệm khẩn cấp, demo, production giai đoạn đầu, mức sử dụng chưa rõ | Thời gian nhàn rỗi và mức giá giờ niêm yết cao hơn | Số phút GPU hoạt động hữu ích / số phút có tính phí |
| GPU spot | Batch inference, đánh giá offline, training có checkpoint, hàng đợi media, worker có thể thử lại | Bị thu hồi, trễ hàng đợi, lãng phí khi khởi động lại, công việc trùng lặp | Job hoàn thành sau khi tính cả chi phí gián đoạn |
| GPU reserved | Inference production ổn định, training theo lịch, cửa sổ ra mắt, cụm chuyên dụng | Không sử dụng hết, bị khóa vào phần cứng, lệch với hợp đồng | Utilization nền so với điểm hòa vốn của cam kết |
Nguyên tắc bền vững cho các quyết định on-demand vs spot GPU rất đơn giản: hãy so sánh chi phí hiệu dụng trên mỗi khối lượng công việc hoàn thành, chứ không phải giá GPU theo giờ được quảng cáo.
chi phí hiệu dụng trên mỗi khối lượng công việc hoàn thành =
(compute + lưu trữ + băng thông + thời gian nhàn rỗi + lãng phí khi khởi động lại + hỗ trợ + chi phí vận hành kỹ thuật)
/ số job được chấp nhận, token đã huấn luyện, token suy luận, ảnh, clip hoặc lượt benchmark
Công thức đó quan trọng vì mỗi mô hình chuyển rủi ro sang một nơi khác. On-demand đặt rủi ro vào thời gian nhàn rỗi. Spot đặt rủi ro vào gián đoạn và điều phối. Dung lượng reserved đặt rủi ro vào độ chính xác của dự báo.
Giá GPU on-demand nghĩa là gì
Giá GPU on-demand là mức nền tảng rõ ràng nhất. Bạn trả tiền trong thời gian instance, pod hoặc server đang chạy, mà không có cam kết dài hạn. AWS mô tả On-Demand Instances là dung lượng trả theo mức sử dụng, không có cam kết dài hạn. Các dịch vụ GPU chuyên biệt cũng dùng ngôn ngữ tương tự cho pod, instance hoặc máy chủ GPU tính theo giờ, dù đơn vị tính phí và dung lượng lưu trữ đi kèm có thể khác nhau.
Hãy dùng on-demand trước khi khối lượng công việc هنوز chưa rõ:
| Trường hợp sử dụng | Vì sao on-demand phù hợp |
|---|---|
| Benchmark đầu tiên của một mô hình hoặc stack phục vụ | Bạn cần đo thời gian sạch, không có biến số gián đoạn. |
| Xác thực driver, CUDA, container hoặc framework | Việc debug không nên bị trộn với rủi ro bị spot thu hồi. |
| Môi trường demo khách hàng hoặc QA | Tính dự đoán quan trọng hơn mức giá thấp nhất. |
| Endpoint production giai đoạn đầu | Bạn cần tính sẵn sàng trước khi có dữ liệu sử dụng ổn định. |
| Chạy training hoặc fine-tuning ngắn, khẩn cấp | Độ trễ hàng đợi có thể tốn kém hơn mức tiết kiệm theo giờ. |
Cái bẫy là thời gian nhàn rỗi. Nếu một notebook, pod hoặc inference server chạy 100 giờ có tính phí nhưng GPU chỉ hoạt động 28 giờ hữu ích, thì chi phí thực không phải là giá theo giờ mà nhà cung cấp niêm yết. Tỷ lệ thực bị đội lên bởi phần lãng phí do nhàn rỗi.
tỷ lệ theo giờ hiệu dụng của on-demand =
giá theo giờ on-demand niêm yết / tỷ lệ sử dụng hữu ích
Nếu mức sử dụng là 35%, một GPU $4/hour sẽ vận hành như một tài nguyên $11.43/useful-hour trước khi tính lưu trữ, băng thông hoặc chi phí vận hành kỹ thuật. Với các quyết định on-demand vs spot GPU, hãy xử lý việc tắt máy nhàn rỗi và ghép hàng đợi trước khi thương lượng mức giá theo giờ tốt hơn.
Giá GPU spot nghĩa là gì
Giá GPU spot sử dụng dung lượng dư thừa hoặc có thể bị ngắt quãng. AWS nói EC2 Spot Instances dùng dung lượng EC2 dư thừa và có thể giảm giá tới 90% so với giá On-Demand. Google Cloud Spot VMs và Azure Spot Virtual Machines cũng theo cùng một mô hình chung: dung lượng giá thấp hơn nhưng có thể bị ưu tiên thu hồi hoặc đẩy ra khi cloud cần lấy lại.
GPU spot hấp dẫn đối với các khối lượng công việc AI vì training, đánh giá, tạo ảnh và batch inference thường có các phần lớn có thể thử lại. Nhưng “có thể thử lại” không tự động xảy ra. Bạn cần checkpointing, job idempotent, data locality, giám sát và một scheduler có thể khởi động lại mà không làm hỏng kết quả.
Spot thường là ứng viên mạnh khi:
- Các job training checkpoint thường xuyên và tiếp tục lại một cách trơn tru.
- Batch inference có thể thử lại mà không gây lỗi thấy được đối với người dùng.
- Các đánh giá offline có thể chạy trên nhiều worker.
- Các job tạo nội dung media nằm phía sau một hàng đợi.
- Một worker lỗi không làm mất hiệu lực toàn bộ job nhiều node.
- Đội ngũ đã có orchestration cho việc bị thu hồi và ngăn trùng lặp.
Spot thường là lựa chọn yếu khi:
- Một lần huấn luyện kéo dài nhiều ngày khởi động lại từ một checkpoint cũ.
- Thời gian khởi động chủ yếu bị chi phối bởi việc tải model, image hoặc dataset.
- Độ trễ hướng tới khách hàng phụ thuộc vào việc máy còn hoạt động.
- Huấn luyện nhiều node thất bại khi một worker biến mất.
- Kỹ sư phải tự tay theo dõi và xử lý các lần khởi động lại.
Đối với ưu và nhược điểm của GPU instance spot so với on-demand, phép tính nên bao gồm hao hụt do gián đoạn:
chi phí theo giờ hiệu dụng của spot =
giá theo giờ của spot / (1 - tỷ lệ hao hụt do gián đoạn)
Nếu spot rẻ hơn 60% nhưng các lần gián đoạn, tải lại dữ liệu, bước thất bại và độ trễ hàng đợi làm lãng phí 35% thời gian công việc đã trôi qua, thì mức giảm giá thực sự nhỏ hơn nhiều so với giá niêm yết. Nếu hao hụt do khởi động lại tăng lên cùng bậc với mức giảm giá, thì dung lượng on-demand thường gọn gàng hơn.
Ý nghĩa của giá GPU reserved
Giá GPU reserved là một mô hình cam kết. Nó có thể xuất hiện dưới dạng reserved instance, Savings Plan, chiết khấu committed use, reserved cluster, private capacity, capacity block hoặc hợp đồng GPU chuyên dụng. Tên gọi khác nhau tùy nhà cung cấp, nhưng đánh đổi thì giống nhau: bạn đổi sự linh hoạt lấy dung lượng có thể dự đoán hoặc một mức chi phí hiệu dụng thấp hơn.
Dung lượng GPU reserved phù hợp khi:
| Tín hiệu | Ý nghĩa |
|---|---|
| Lưu lượng suy luận nền ổn định | Bạn có thể giữ GPU bận trong phần lớn các giờ của tháng. |
| Lịch huấn luyện lặp lại | Bạn biết khi nào cần dung lượng và cần trong bao lâu. |
| Nhu cầu dung lượng khi ra mắt | Bạn không thể dựa vào tính sẵn có theo kiểu best-effort của spot. |
| Yêu cầu topology nhiều node | Vị trí mạng, fabric và tính cục bộ của lưu trữ đều quan trọng. |
| Mua sắm cần chi tiêu cố định | Một cam kết hàng tháng đã biết trước dễ được phê duyệt hơn mức sử dụng biến động. |
Câu hỏi cốt lõi của dung lượng reserved là điểm hòa vốn theo mức sử dụng:
mức sử dụng hòa vốn của reserved =
cam kết hàng tháng của reserved
/ (giá theo giờ on-demand * số giờ trong tháng)
Nếu cam kết reserved hòa vốn ở mức sử dụng 62% và mức nền thực tế của bạn chỉ là 25%, thì reserved không phải là một khoản giảm giá. Nó là một gói đăng ký dung lượng nhàn rỗi. Với các cụm GPU, hãy kết hợp điều này với mô hình TCO của cụm GPU để bao gồm mạng, lưu trữ, hỗ trợ, remote hands và vận hành.
Ma trận quyết định theo khối lượng công việc
Mô hình giá tốt nhất phụ thuộc nhiều hơn vào khả năng chịu lỗi và mức sử dụng so với kích thước model đơn thuần.
| Khối lượng công việc | Điểm khởi đầu tốt hơn | Lý do |
|---|---|---|
| Benchmark model đầu tiên | GPU on-demand | Bạn cần một baseline sạch cho throughput, độ trễ, bộ nhớ và các chế độ lỗi. |
| Đánh giá stack serving mới | GPU on-demand | Xác thực vLLM, SGLang, TensorRT-LLM, driver, image và việc tải model trước khi tối ưu giá. |
| Bộ kiểm thử offline | GPU spot | Kết quả có thể thử lại, chia nhỏ và kiểm tra công việc trùng lặp. |
| Batch embedding hoặc batch inference | GPU spot, với phương án dự phòng on-demand | Công việc có thể xếp hàng nếu có idempotency và các kiểm soát retry. |
| Baseline suy luận hướng tới khách hàng | Reserved cộng với burst on-demand | Nhu cầu ổn định có thể biện minh cho cam kết; phần burst vẫn linh hoạt. |
| Ra mắt một lần hoặc chiến dịch ngắn hạn | On-demand hoặc capacity block | Đảm bảo dung lượng có thể quan trọng hơn giảm giá dài hạn. |
| Huấn luyện phân tán nhiều node | Reserved hoặc cụm chuyên dụng | Vị trí đặt, network fabric và miền lỗi chi phối giá theo giờ. |
| Tính năng AI khối lượng thấp | Model API hoặc gateway | Dung lượng GPU nhàn rỗi có thể tốn hơn suy luận theo mức dùng được quản lý. |
Đối với việc chọn model GPU trong bất kỳ hàng nào, hãy kết hợp bài viết này với hướng dẫn chọn GPU cho AI, GPU tốt nhất cho suy luận LLM, và hướng dẫn triển khai vLLM.
Kinh tế on-demand so với spot GPU: một ví dụ đơn giản
Giả sử một batch suy luận có thể chạy trên cùng một dòng GPU ở chế độ on-demand hoặc spot.
| Trường | On-demand | Spot |
|---|---|---|
| Giá niêm yết theo giờ | $4.00 |
$1.80 |
| Mức sử dụng hữu ích | 70% |
70% |
| Hao hụt do khởi động lại và bị thu hồi | 0% |
22% |
| Chi phí hiệu dụng cho mỗi giờ hữu ích | $5.71 |
$3.30 |
Spot vẫn thắng trong ví dụ này vì mức giảm giá lớn hơn hao hụt. Bây giờ hãy tăng hao hụt do khởi động lại lên 55% vì công việc liên tục tải lại trọng số và mất các batch dở dang.
| Trường | On-demand | Spot |
|---|---|---|
| Giá niêm yết theo giờ | $4.00 |
$1.80 |
| Mức sử dụng hữu ích | 70% |
70% |
| Hao hụt do khởi động lại và bị thu hồi | 0% |
55% |
| Chi phí hiệu dụng cho mỗi giờ hữu ích | $5.71 |
$5.71 |
Vào thời điểm đó, mức chiết khấu spot nhìn có vẻ hấp dẫn sẽ biến mất. Đây là lý do vì sao việc so sánh GPU on-demand và spot nên bao gồm cả phần lãng phí vận hành, chứ không chỉ tỷ lệ spot do nhà cung cấp công bố.
Kinh tế GPU reserved: bài kiểm tra mức sử dụng
Dung lượng reserved cần một bài kiểm tra khác. Giả sử một GPU on-demand có giá $4/hour, và cam kết reserved theo tháng cho dung lượng tương đương là $1,900/month.
chi phí on-demand hàng tháng ở mức sử dụng 100% =
$4 * 730 giờ = $2,920
mức sử dụng hòa vốn của reserved =
$1,900 / $2,920 = 65%
Gói reserved đó chỉ hấp dẫn nếu khối lượng công việc có thể giữ GPU bận hơn khoảng hai phần ba thời gian trong tháng. Nếu endpoint production của bạn dùng GPU rất nhiều trong giờ làm việc nhưng để lạnh vào ban đêm và cuối tuần, mức cơ sở thực tế có thể thấp hơn điểm hòa vốn.
Câu hỏi dưới góc độ mua sắm là:
- Mức cơ sở được đo thực tế là gì, không phải đỉnh dự báo?
- Những khối lượng công việc nào được phép tận dụng dung lượng reserved đang nhàn rỗi?
- Điều gì xảy ra nếu mô hình chuyển từ H100 sang H200, B200, L40S, hoặc một API được quản lý?
- Lưu trữ, hỗ trợ, mạng và egress nằm trong hay ngoài cam kết?
- Hợp đồng có thể giảm quy mô, chuyển loại GPU, hoặc đổi khu vực không?
Đừng đặt chỗ dựa trên hy vọng. Hãy đặt chỗ dựa trên mức sử dụng đã đo được.
Danh sách kiểm tra nguồn của nhà cung cấp
Trang giá GPU thay đổi thường xuyên, và giá trên marketplace có thể thay đổi nhanh hơn một chu kỳ mua sắm. Hãy dùng phần này như một danh sách kiểm tra nguồn, không phải một bảng giá cố định. Kiểm tra lại vào ngày bạn phê duyệt chi tiêu.
| Danh mục nhà cung cấp | Nguồn chính thức cần kiểm tra | Thông tin cần ghi nhận |
|---|---|---|
| AWS | Amazon EC2 pricing, EC2 Spot Instances, EC2 Capacity Blocks for ML | Khu vực, dòng instance GPU, On-Demand, Spot, Savings Plans hoặc Reserved Instances, thời gian capacity block, EBS, truyền dữ liệu, hỗ trợ. |
| Google Cloud | Compute Engine GPU pricing, Spot VMs, Committed use discounts | Loại GPU, dòng máy, khu vực, trạng thái Spot VM, thời hạn cam kết, nhu cầu reservation, persistent disk, network egress. |
| Microsoft Azure | Azure Spot Virtual Machines, Reserved VM Instances | SKU của GPU VM, khu vực, chính sách thu hồi, cài đặt giá tối đa, thời hạn reservation, managed disk, băng thông, hỗ trợ. |
| RunPod | RunPod pricing và tài liệu sản phẩm | Secure Cloud so với Community Cloud, giá pod, giá serverless, lưu trữ bền vững, network volume, hành vi cold start. |
| Vast.ai | Vast.ai pricing và Vast.ai docs | Độ tin cậy của host, trạng thái datacenter/community, cờ interruptible, disk, băng thông, host đã xác minh, nhu cầu public IP. |
| Lambda | Lambda Cloud GPU pricing | Loại instance, số lượng GPU, khu vực, khả năng sẵn có on-demand, điều khoản báo giá cluster reserved, giả định về lưu trữ và mạng. |
Thêm một dòng ngày kiểm tra vào bảng tính của bạn. Trong bài viết này, danh sách kiểm tra nguồn đã được rà soát vào October 13, 2026.
Những câu hỏi mua sắm trước khi bạn lựa chọn
Trước khi bạn chọn dung lượng GPU on-demand so với spot hoặc ký hợp đồng GPU reserved, hãy hỏi những câu sau:
| Câu hỏi | Vì sao điều này quan trọng |
|---|---|
| Công việc có thể checkpoint và tiếp tục mà không cần sửa thủ công không? | Xác định liệu rủi ro gián đoạn của spot có chấp nhận được hay không. |
| Thời gian khởi động trước khi bắt đầu xử lý GPU hữu ích là bao lâu? | Việc nạp model và dữ liệu lâu sẽ làm giảm lợi ích tiết kiệm của spot và làm giảm hiệu quả của on-demand. |
| Tỷ lệ nhàn rỗi được đo là bao nhiêu? | Thời gian nhàn rỗi là rò rỉ chi phí chính của on-demand. |
| Mức cơ sở là gì, không phải mức đỉnh? | Giá reserved chỉ hiệu quả khi nhu cầu cơ sở là có thật. |
| Khối lượng công việc có cần một khu vực hoặc fabric mạng cụ thể không? | Cấu trúc topo khan hiếm có thể khiến mức giá spot/on-demand chung chung trở nên không còn liên quan. |
| Lưu trữ, snapshots, băng thông và hỗ trợ có được bao gồm không? | Số giờ GPU chỉ là một dòng trong hóa đơn thực tế. |
| Lộ trình thoát ra là gì nếu lựa chọn model thay đổi? | Khóa chặt phần cứng rất tốn kém khi kiến trúc model thay đổi. |
| Thay vào đó, một API model được quản lý có đáp ứng yêu cầu không? | Khối lượng công việc có mức sử dụng thấp hoặc nhiều model có thể không đủ lý do để vận hành GPU. |
Đối với các quyết định về multi-node và dung lượng riêng, hãy so sánh điều này với thuê cụm GPU và private GPU cloud.
Khi một API model vượt trội hơn cả ba mô hình giá GPU
GPU on-demand, spot và reserved đều giả định rằng việc thuê và vận hành phần cứng là lớp trừu tượng phù hợp. Điều đó không phải lúc nào cũng đúng.
Một API mô hình được quản lý có thể là điểm khởi đầu kinh tế tốt hơn khi:
- Mức sử dụng thấp, không đều hoặc chưa rõ.
- Sản phẩm cần nhiều mô hình thay vì một mô hình tự lưu trữ.
- Độ tin cậy, nâng cấp và mở rộng sẽ làm phân tán sự chú ý khỏi lộ trình sản phẩm.
- Nhóm cần sổ ghi nhận sử dụng, ngân sách và hóa đơn hơn là khả năng kiểm soát phần cứng.
- Khối lượng công việc là suy luận trong môi trường production hơn là huấn luyện mô hình hoặc nghiên cứu phục vụ tùy chỉnh.
Flatkey nằm ở phía API của quyết định đó. Nó cung cấp cho các nhóm AI một khóa API, một số dư, một hóa đơn, khả năng hiển thị mức sử dụng và quyền truy cập vào các tuyến mô hình chính thức trên nhiều nhà cung cấp. Nếu bảng tính GPU on-demand so với spot cho thấy mức sử dụng phần cứng vẫn chưa đủ cao, hãy so sánh chi phí API được quản lý trên mỗi kết quả được chấp nhận trước khi mua hoặc đặt trước dung lượng GPU. Bước tiếp theo là các hướng dẫn về so sánh giá mô hình AI và giá AI gateway.
Khuyến nghị cuối cùng
Hãy sử dụng trình tự này:
- Bắt đầu với dung lượng GPU on-demand cho đến khi các số liệu benchmark và mức sử dụng đủ đáng tin cậy.
- Chỉ chuyển các tác vụ có thể thử lại sang GPU spot sau khi cơ chế checkpointing, idempotency và tự động khởi động lại đã được chứng minh.
- Chỉ đặt trước dung lượng GPU cho nhu cầu nền đã đo lường, các khung thời gian ra mắt đã cam kết hoặc các cụm nhạy cảm với topology.
- Giữ một đường dẫn API mô hình mở khi mức sử dụng thấp, lựa chọn mô hình thay đổi thường xuyên hoặc bộ phận tài chính cần phân bổ mức sử dụng rõ ràng hơn.
Quyết định tốt nhất giữa GPU on-demand và spot không phải là quyết định có mức giá theo giờ niêm yết thấp nhất. Đó là quyết định giữa on-demand và spot giúp tối thiểu hóa chi phí trên mỗi khối lượng công việc hoàn thành trong khi vẫn giữ rủi ro về độ tin cậy ở mức mà nhóm của bạn thực sự có thể quản lý.
