Khi giá cloud thôi đi xuống: 'chạy trước, tối ưu sau' vừa hết hạn

Thứ Bảy ngày 4/1/2026, AWS tăng khoảng 15% giá EC2 Capacity Blocks cho GPU NVIDIA H200 mà không có thông báo chính thức nào. Ở US West (N. California), mức p5e đi từ 43,26 lên 49,75 USD mỗi giờ. The Register phát hiện thay đổi này vào ngày hôm sau, và điều đáng chú ý không phải là 15%.

Điều đáng chú ý là chiều của mũi tên. Trong khoảng hai mươi năm, giá điện toán trên cloud gần như chỉ đi một hướng: xuống. AWS công bố hàng trăm lần giảm giá; mỗi thế hệ máy mới rẻ hơn thế hệ cũ trên cùng đơn vị hiệu năng. Đây là lần đầu tiên một dịch vụ chủ lực đi ngược lại một cách công khai.

Và nó không đơn độc. CEO của OVHcloud, Octave Klaba, dự báo công khai mức tăng 5–10% ở tất cả nhà cung cấp trong khoảng tháng 4 đến tháng 9/2026, do chi phí phần cứng máy chủ tăng 15–25% — RAM và ổ NVMe bị kéo giá bởi nhu cầu hạ tầng AI.

Giả định vừa gãy, và vì sao nó quan trọng hơn 15%

Suốt mười lăm năm, mọi kế hoạch hạ tầng đều dựa trên một giả định ngầm mà hiếm ai viết ra: giá sẽ rẻ dần. Giả định đó biện minh cho một cách làm rất hợp lý về mặt kinh doanh — cứ đưa sản phẩm ra thị trường trước, tối ưu chi phí sau. Nếu một kiến trúc hôm nay tốn 10.000 USD mỗi tháng, thì cùng kiến trúc đó sau hai năm sẽ tốn ít hơn, kể cả khi bạn không làm gì cả. Đường giá đi xuống là một khoản trợ cấp âm thầm cho mọi quyết định vội vàng.

Khi đường giá đổi chiều, khoản trợ cấp đó biến mất — và đảo dấu. Lãng phí không còn tự nhỏ đi theo thời gian nữa. Nó lớn lên. Một kiến trúc dư thừa 30% ở mức giá 2025 sẽ dư thừa nhiều hơn 30% tính bằng tiền ở mức giá 2027, dù không có gì thay đổi trong hệ thống.

Đây là lý do bài này không phải một bài về mẹo tiết kiệm. Con số 15% tự nó không lớn. Việc mất đi một cơ chế tự sửa sai đã hoạt động âm thầm suốt hai thập kỷ mới là thay đổi thật.

Hoá đơn không nói cho bạn biết tiền chảy đi đâu

Các khảo sát ngành đặt mức lãng phí trung bình trong hoá đơn cloud ở khoảng 28–34% — tài nguyên nhàn rỗi, tài nguyên cấp thừa, và tài nguyên mồ côi không còn ai dùng. Mức vượt ngân sách trung bình khoảng 17%. Chia nhỏ hơn, ba nguồn thường được ghi nhận là:

• Tài nguyên nhàn rỗi hoặc đã dừng — khoảng 10–15% hoá đơn tháng. Máy vẫn tồn tại và vẫn tính tiền dù không phục vụ gì.
• Compute cấp thừa — thêm khoảng 10–12%. Máy chạy thật nhưng lớn hơn nhu cầu, thường vì kích thước được chọn một lần lúc mới dựng rồi không ai xem lại.
• Truyền dữ liệu ra ngoài và giữa các region — khoảng 3–6%. Nhỏ hơn hai khoản trên, nhưng là khoản khó nhất trong ba.

Khoản thứ ba đáng được nói riêng, vì nó khác bản chất. Hai khoản đầu là *tài nguyên* — có thể nhìn thấy trên dashboard, có thể tắt, có thể chỉnh kích thước. Chi phí truyền dữ liệu không phải tài nguyên. Nó là hệ quả trực tiếp của việc bạn đặt dịch vụ ở đâu, và nó không xuất hiện trong bất kỳ màn hình theo dõi mức sử dụng nào. Bạn không tắt được nó. Bạn chỉ đổi được thiết kế đã sinh ra nó.

Cùng loại với nó là lưu trữ tích tụ: snapshot của những máy đã xoá, log giữ mãi vì không ai đặt thời hạn, và bản sao dữ liệu thật trong môi trường thử nghiệm. Khoản cuối này chúng tôi đã nhắc trong bài về luật bảo vệ dữ liệu cá nhân ở một góc khác — nó là rủi ro tuân thủ. Hoá ra nó còn là một dòng trên hoá đơn, và cùng một hành động dọn được cả hai.

Phản xạ đầu tiên khi giá tăng là phản xạ sai

Khi thấy giá tăng, phản xạ tự nhiên của phần lớn tổ chức là chốt giá: mua reserved instance, ký savings plan, cam kết một đến ba năm để đổi lấy chiết khấu. Về mặt tài chính thuần tuý, đó là một giao dịch hợp lý.

Vấn đề là nó tối ưu nhầm chiều. Cam kết dài hạn giảm đơn giá của tài nguyên bạn đang dùng. Nó không hỏi câu quan trọng hơn: *có nên dùng chỗ đó không*. Giảm 30% giá của một cụm máy lẽ ra không nên chạy thì vẫn là tiêu tiền — chỉ là tiêu rẻ hơn, và giờ tiêu trong ba năm.

Tệ hơn, nó đóng băng đúng thứ bạn đang muốn thay đổi. Sau khi ký cam kết cho một hình dạng hạ tầng cụ thể, mọi đề xuất tái kiến trúc đều phải trả lời câu hỏi "thế còn phần cam kết đã trả?" — và câu hỏi đó thường thắng, kể cả khi nó không nên thắng. Một chi phí biến đổi vừa được chuyển thành chi phí cố định, đúng vào lúc bạn cần sự linh hoạt nhất.

Có một trường hợp ngoại lệ rõ ràng: phần tải đã chạy ổn định nhiều tháng, đã được đo, và không nằm trong bất kỳ kế hoạch thay đổi nào. Với phần đó, cam kết là quyết định đúng. Sai lầm phổ biến là cam kết cho *toàn bộ* hoá đơn vì mức chiết khấu trên toàn bộ trông hấp dẫn hơn.

Lãng phí bằng 0 không phải mục tiêu

Một điểm ít được nói trong các bài về tối ưu chi phí: các tổ chức đã đạt mức trưởng thành cao nhất về quản trị chi phí cloud vẫn lãng phí 14–18%, so với mức trung bình khoảng 27%. Họ không tiến về 0, và họ không cố.

Lý do là một phần lãng phí thực ra đang mua thứ gì đó. Công suất dự phòng mua khả năng chịu tải đột biến. Một môi trường staging luôn sẵn sàng mua tốc độ phát hành. Một replica không bao giờ được đọc mua thời gian ngủ yên của đội trực. Nếu bạn cấp đúng bằng nhu cầu trung bình, bạn không có đệm — và bạn sẽ phát hiện điều đó vào đúng ngày tệ nhất.

Vì vậy câu hỏi đúng không phải "làm sao giảm lãng phí xuống 0" mà "khoản này đang mua gì cho tôi, và chuyện gì xảy ra nếu bỏ nó". Khoản trả lời được câu đó là bảo hiểm. Khoản không trả lời được là mất trắng — và trong thực tế, phần lớn nó là môi trường thử nghiệm chạy 24/7 để phục vụ tám giờ làm việc, snapshot của những máy đã không còn, và dịch vụ thuộc một dự án đã kết thúc từ quý trước.

Cách phân biệt này quan trọng vì nó quyết định thứ tự làm. Một chiến dịch cắt giảm không phân biệt hai loại sẽ cắt cả phần đệm — và sự cố kế tiếp sẽ tiêu tốn nhiều hơn toàn bộ số tiền vừa tiết kiệm được.

Chi phí không phân bổ được là chi phí không giảm được

Báo cáo State of FinOps 2026 của FinOps Foundation ghi nhận 50% người làm nghề xếp "tối ưu tải và giảm lãng phí" là ưu tiên số một hiện tại. Nhưng chi tiết đáng chú ý hơn nằm ở phần nhận xét: họ nói phần lãng phí lớn và dễ thấy đã bị dọn xong rồi; thứ còn lại là nhiều khoản nhỏ và khó bắt hơn nhiều.

Điều đó đúng với các tổ chức đã đi qua một vòng tối ưu. Với phần lớn doanh nghiệp chưa từng làm, phần dễ vẫn còn nguyên — và lý do nó còn nguyên hiếm khi là thiếu hiểu biết kỹ thuật. Nó còn nguyên vì không ai sở hữu con số. Hoá đơn về phòng tài chính, nơi không biết dòng nào tương ứng với dịch vụ nào. Đội kỹ thuật biết dịch vụ nào là của mình nhưng không nhìn thấy hoá đơn.

Bước đầu tiên vì thế không phải cắt giảm mà là quy trách nhiệm: mỗi dòng chi phí về một chủ sở hữu nghiệp vụ cụ thể. Phần khó nhất — và cũng là phần định nghĩa mức trưởng thành thật — là tài nguyên dùng chung: một cluster Kubernetes phục vụ năm đội, một database phục vụ mười hai dịch vụ, một hàng đợi tin nhắn dùng chung toàn hệ thống. Gắn nhãn không giải quyết được những thứ này; phải có một quy tắc phân bổ mà các bên chấp nhận được, kể cả khi nó không hoàn hảo. Với cluster dùng chung, thiết kế node pool và quota theo đội là chỗ việc phân bổ trở nên khả thi thay vì chỉ là một bảng tính ước lượng.

Một quy tắc phân bổ gần đúng nhưng được các bên đồng ý còn hữu ích hơn một con số chính xác mà không ai dùng để ra quyết định.

Mặt trận đang lớn nhanh nhất: GPU

Trong khi phần lớn công cụ và quy trình tối ưu chi phí được xây cho máy ảo thông thường, khoản chi tăng nhanh nhất lại nằm ở chỗ khác. Mức sử dụng GPU trung bình được ghi nhận vào khoảng 23% — nghĩa là khoảng 77% công suất đã trả tiền không chạy gì.

Con số đó không hoàn toàn là lỗi vận hành. GPU khó chia sẻ hơn CPU rất nhiều: bộ nhớ không co giãn được như RAM thường, và một tác vụ huấn luyện chiếm trọn thiết bị trong nhiều giờ. Nhưng khoảng cách giữa 23% và một mức hợp lý là rất rộng, và phần lớn nó đến từ ba thói quen: cấp GPU theo đỉnh của tác vụ huấn luyện rồi để nguyên khi chuyển sang phục vụ inference, không tách hàng đợi huấn luyện khỏi hàng đợi phục vụ, và chọn thiết bị theo dung lượng bộ nhớ tối đa từng cần thay vì theo phân phối thực tế của tải. Chúng tôi đã viết riêng về cách VRAM và HBM quyết định chi phí vận hành AI — phần lớn quyết định tốn kém nhất được ra ở bước chọn thiết bị, trước khi có dòng chi phí nào xuất hiện.

Vẫn theo State of FinOps 2026, 98% tổ chức nói họ đang chủ động quản lý chi phí AI, tăng từ 63% năm 2025 và 31% năm 2024. Nhưng ba khó khăn hàng đầu họ nêu ra là: nhìn thấy được chi phí, phân bổ được nó, và đo được giá trị nó tạo ra.

Đọc hai câu đó cạnh nhau thì thấy rõ tình trạng thật: gần như tất cả nói đang quản lý một thứ mà đa số chưa nhìn rõ. Đó không phải nói dối — đó là mô tả khá chính xác một lĩnh vực mà mô hình giá vẫn đang được phát minh dở dang, nơi token, giờ-GPU, huấn luyện và suy luận được tính theo những cách khác nhau ở mỗi nhà cung cấp.

Bối cảnh Việt Nam: áp lực đến từ hai phía

Thị trường cloud Việt Nam được ước tính đạt khoảng 1,5 tỷ USD trong năm 2026, với tốc độ tăng trưởng kép khoảng 20–25% mỗi năm cho giai đoạn 2023–2028. Đây là một thị trường đang mở rộng nhanh, và phần lớn doanh nghiệp trong đó chưa từng đi qua một vòng tối ưu chi phí nào.

Điều làm bối cảnh Việt Nam khác biệt là áp lực đến từ hai hướng cùng lúc. Một mặt là giá dịch vụ từ nhà cung cấp nước ngoài tăng — đúng xu hướng toàn cầu ở trên. Mặt khác là yêu cầu về nội địa hoá dữ liệu, thứ có thể buộc một phần hệ thống phải chuyển vị trí bất kể chi phí. Tổng hợp trên báo trong nước gọi đây là áp lực kép, và dẫn thêm dự báo của Gartner về mức tăng rất mạnh của giá DRAM và bộ nhớ flash trong năm 2026 — con số này chúng tôi dẫn lại qua nguồn thứ cấp, chưa kiểm chứng từ báo cáo gốc.

Hệ quả thực tế: đây là thời điểm tệ nhất để ký cam kết ba năm cho một vị trí địa lý cụ thể. Nếu quy định buộc dữ liệu cá nhân của người dùng Việt Nam phải nằm trong nước, khoản cam kết ở một region nước ngoài không chuyển đi được — nó chỉ trở thành chi phí chìm bên cạnh chi phí mới.

Xu hướng dịch chuyển sang nhà cung cấp trong nước — VNPT, Viettel, FPT — đang diễn ra vì lý do này nhiều hơn là vì giá. Cách bố trí phổ biến hiện nay là giữ dịch vụ nước ngoài cho những thứ chỉ họ có (API mô hình AI, SaaS quốc tế) và chuyển dữ liệu nhạy cảm cùng phần lõi về hạ tầng trong nước. Nếu bạn đang cân nhắc bước này, phần khó không nằm ở chi phí mà ở việc chuyển mà không dừng hệ thống — đó là bài toán dual-write, backfill và cutover chứ không phải bài toán so sánh bảng giá.

Bốn phép đo cho một buổi chiều

• Quy từng dòng hoá đơn về một chủ sở hữu nghiệp vụ. Sản phẩm nào, đội nào, khách hàng nào. Ghi lại phần không quy được — đó là phần quan trọng nhất, vì chi phí không phân bổ được là chi phí không ai chịu trách nhiệm giảm.
• Với mỗi khoản nhàn rỗi, hỏi nó đang mua gì. Khả năng chịu tải đột biến? Tốc độ phát hành? Giấc ngủ của đội trực? Thứ trả lời được là bảo hiểm và nên giữ. Thứ không trả lời được là mất trắng và nên cắt trước tiên.
• Tách riêng chi phí truyền dữ liệu và lưu trữ tích tụ. Hai khoản này không nằm trên dashboard sử dụng vì chúng không phải tài nguyên tắt được. Chúng chỉ giảm khi thiết kế đổi — và chúng là nơi chi phí âm thầm lớn lên nhất theo thời gian.
• Kiểm lại mọi cam kết dài hạn theo hai câu hỏi. Phần tải này đã ổn định bao lâu? Và nếu quy định buộc chuyển vị trí trong mười tám tháng tới, khoản cam kết này còn dùng được không? Cam kết cho phần trả lời tốt cả hai; phần còn lại giữ ở giá theo nhu cầu.

Kết luận

Việc AWS tăng 15% giá một dòng GPU vào một ngày thứ Bảy không phải sự kiện lớn. Cái lớn là thứ nó báo hiệu: một cơ chế tự sửa sai đã âm thầm hoạt động suốt hai mươi năm vừa ngừng lại.

Trong hai mươi năm đó, "chạy trước, tối ưu sau" là một chiến lược hợp lý — không phải vì các đội kỹ thuật cẩu thả, mà vì đường giá đi xuống thực sự có trả một phần hoá đơn cho sự vội vàng. Đó là một khoản trợ cấp đi mượn, và nó đang hết.

Danh sách việc cần làm không có gì mới và cũng chẳng cần công cụ đắt tiền: biết mỗi đồng đang thuộc về ai, phân biệt phần đệm với phần mất trắng, đo hai khoản chi không nằm trên dashboard, và đừng khoá mình vào một hình dạng hạ tầng chưa được kiểm chứng. Không việc nào trong đó là mới. Chỉ là từ giờ, việc hoãn chúng lại không còn miễn phí nữa.

Nếu bạn muốn biết hoá đơn hạ tầng của mình đang phân bổ được bao nhiêu phần trăm — con số thường gây bất ngờ nhiều hơn tổng số tiền — liên hệ với chúng tôi để rà soát một hệ thống cụ thể, hoặc xem năng lực Server & Database và Optimization Loop của KonexForge.