AWS kêu gọi kỹ sư giảm lãng phí CPU: Tín hiệu cảnh báo cho hạ tầng blockchain

Cuối tuần qua, Crypto Briefing đưa tin AWS đã chỉ đạo các kỹ sư tập trung giảm lãng phí CPU khi EC2 đang chịu áp lực dung lượng. Thông tin không kèm con số, không kèm ngày công bố chính thức, nhưng đủ để khiến những ai đang vận hành node, RPC hoặc indexer phải chú ý. Tôi không ngạc nhiên. Khi bạn chạy một hệ thống dữ liệu thời gian thực cho hàng nghìn validator, bạn biết rằng điều đầu tiên chết không phải là token, mà là khả năng kiếm được một chiếc máy chủ đủ tốt. Tôi đã bắt đầu theo dõi chủ đề này từ lâu, bởi hạ tầng Web3 không nằm trên blockchain, mà nằm trên các trung tâm dữ liệu của Amazon, Microsoft và Google. Khi một trong ba trụ cột này bắt đầu kẹt tài nguyên, toàn bộ lớp ứng dụng phi tập trung sẽ rung chuyển theo cách mà dữ liệu on-chain không thể hiện ngay lập tức. EC2 là dịch vụ điện toán đám mây cốt lõi nhất của AWS. Nó cho phép khách hàng thuê các máy chủ ảo với cấu hình linh hoạt từ vài CPU cho tới hàng trăm CPU, chạy trong vài phút. Trong nhiều năm, AWS vận hành theo hướng “thừa cung”, luôn duy trì một lượng công suất dư để đáp ứng mọi nhu cầu đột biến. Nhưng câu chuyện đang thay đổi. Cụm từ “capacity strain” trong thông tin rò rỉ nói lên rằng AWS không còn có thể cấp phát tài nguyên một cách vô tư như trước. Giới hạn không nằm ở phần mềm hay API, mà nằm ở phần cứng, nguồn điện và chuỗi cung ứng chip. Trong bối cảnh AI tạo sinh bùng nổ, nhu cầu GPU tăng vọt, nhưng điều ít ai để ý là CPU cũng bị cuốn vào vòng xoáy. Mỗi tác vụ AI đều cần CPU để xử lý dữ liệu đầu vào, điều phối luồng, nén dữ liệu, chạy inference phụ trợ. Nếu GPU là cỗ máy, thì CPU là hệ thống van và đường ống. Khi đường ống tắc, cả cỗ máy phải dừng. Điều đó giải thích tại sao một tuyên bố về việc giảm lãng phí CPU lại có sức nặng hơn nhiều so với vẻ ngoài của nó. Đối với cộng đồng blockchain, câu chuyện AWS nghe có vẻ xa vời nhưng thực ra rất gần. Phần lớn các dự án DeFi, NFT hay oracle đều chọn EC2 để chạy backend, indexer và một phần node. Các nhà cung cấp RPC như Infura, Alchemy hay QuickNode cũng xây dựng hạ tầng trên đám mây công cộng. Ngay cả những dự án “phi tập trung” nhất cũng cần một lớp ngoài chuỗi để đọc dữ liệu, phục vụ API và lưu trữ lịch sử. Khi AWS bắt đầu siết chặt CPU, mọi thứ từ chi phí vận hành đến độ trễ của giao dịch đều có thể bị ảnh hưởng. Nhưng điều thú vị không nằm ở việc hạ tầng khan hiếm. Điều thú vị nằm ở phản ứng của AWS: thay vì tăng giá, họ lại yêu cầu kỹ sư tối ưu mã, giảm lãng phí. Quyết định này phản ánh ba thực tế lớn đang chồng lên nhau. Trước hết, AWS tin rằng có một lượng lớn tài nguyên đang bị dùng sai hoặc phân bổ kém. Trong các hệ thống lớn, hiện tượng over-provisioning rất phổ biến: khách hàng đặt máy lớn hơn nhu cầu vì sợ quá tải; kỹ sư mở nhiều instance để test rồi quên tắt; hoặc thuật toán chọn vị trí đặt máy chưa tối ưu, tạo ra các khoảng trống rời rạc không thể dùng cho workload khác. Việc yêu cầu giảm CPU waste có nghĩa là AWS muốn dọn dẹp chính hệ thống phân bổ tài nguyên của mình trước khi tính chuyện đầu tư thêm phần cứng. Đây là chiến lược phòng thủ thông minh, bởi phần mềm có thể tạo ra nhiều “sức chứa ảo” hơn mà không cần đợi chip hay điện. Ngoài ra, AWS đang đối mặt với bài toán không thể giải bằng cách tăng vốn đầu tư. Thời gian giao hàng của CPU và GPU đang dài ra do chuỗi cung ứng toàn cầu, đặc biệt khi các hãng chip ưu tiên phân bổ wafer cho AI accelerator. Nếu AWS tăng đơn hàng hôm nay, phải nhiều quý nữa máy mới tới. Trong khi đó, nhu cầu từ các công ty AI và cả một phần từ Web3 lại tăng theo cấp số nhân. Nút thắt nằm ở phần cứng, không phải ở cầu. Vì vậy, cách nhanh nhất để có thêm công suất là tối ưu tài nguyên hiện có. Điều này giải thích vì sao một gã khổng lồ như AWS lại phải ra chỉ thị nội bộ về hiệu quả CPU, thay vì đơn giản bấm nút mở thêm máy chủ. Bức tranh còn có một lớp nữa: AWS muốn duy trì câu chuyện tăng trưởng mà không phá vỡ mối quan hệ khách hàng. Nếu họ tăng giá EC2 ngay lúc khách hàng AI đang đổ tiền vào mô hình, tâm lý thị trường sẽ xấu đi và đối thủ sẽ chớp cơ hội. Ngược lại, nếu họ âm thầm ép mọi thứ hiệu quả hơn, họ có thể giải phóng 5-10% dung lượng mà không một khách hàng nào nhận ra sự thay đổi. Với quy mô hàng triệu instance, con số đó tương đương hàng nghìn máy chủ mới. Đó là lý do vì sao thông tin này không được công bố rầm rộ, mà rò rỉ ra ngoài như một mảnh ghép trong một bài phân tích. Nhìn sâu vào kỹ thuật, bài toán giảm lãng phí CPU kéo theo nhiều tầng phức tạp. Một trong những kỹ thuật phổ biến là bin-packing: đặt các instance ảo lên máy vật lý sao cho ít khoảng trống nhất. Nhưng việc nhồi nhét quá nhiều instance vào một máy có thể dẫn đến tình trạng Noisy Neighbor, khi một khách hàng dùng hết CPU chung làm những khách hàng khác chậm lại. AWS phải cân bằng giữa mật độ cao và sự ổn định. Họ có thể dùng các kỹ thuật như thu thập metrics sử dụng CPU mịn, dùng machine learning để dự đoán workload theo giờ, di chuyển instance giữa các máy vật lý khi phát hiện xung đột, hoặc điều chỉnh bộ lập lịch để ưu tiên workload có độ nhạy cảm độ trễ thấp. Tất cả đều là những thao tác phức tạp và tiềm ẩn rủi ro. Nếu tối ưu quá tay, AWS có thể đánh đổi chất lượng dịch vụ, gây ra hiện tượng performance degradation lan rộng. Tôi từng tham gia một đợt audit hạ tầng cho một giao thức oracle và phát hiện ra một điều khiến tôi khá bất ngờ: nhóm phát triển chạy ba môi trường staging, production và test trên những instance có cấu hình giống hệt nhau, nhưng chỉ có môi trường production chịu tải thật. Hai môi trường còn lại vẫn chiếm CPU, vẫn ghi log, vẫn tốn tiền mỗi tháng. Đó là một dạng lãng phí mà AWS đang muốn diệt trừ. Và tôi tin rằng trong nội bộ AWS, họ nhìn thấy hàng trăm nghìn instance kiểu như vậy mỗi ngày. Khi tôi thấy thông tin Crypto Briefing, tôi chợt nhớ tới câu nói quen thuộc trong nghề: “Dữ liệu on-chain không nói dối, nhưng hạ tầng ngoài chuỗi thì nói dối rất nhiều.” Các chuỗi khối có thể chứng minh số dư, nhưng không thể chứng minh rằng AWS đang dùng CPU của bạn cho một workload khác khi bạn không để ý. Tôi cũng từng fork repo của một dự án DePIN và phát hiện họ đặt toàn bộ thành phần “phi tập trung” lên EC2, thậm chí không dùng tới spot instance để giảm chi phí. Lúc đó tôi tự hỏi: nếu một dự án tuyên bố tạo ra hạ tầng compute phi tập trung mà không tối ưu nổi một file Terraform, thì làm sao họ có thể đối phó với việc AWS tăng giá hoặc siết capacity? Câu trả lời là họ không thể. Bài toán CPU waste không chỉ là vấn đề của Amazon. Nó là vấn đề của toàn bộ hệ sinh thái sử dụng đám mây, bao gồm cả Web3. Ở khía cạnh tài chính, cú ép CPU này tạo ra một ảnh hưởng dây chuyền lên đơn vị kinh tế của cloud. Khi AWS giảm lãng phí, số vCPU có thể bán trên mỗi máy chủ vật lý tăng lên, nhờ đó giảm chi phí đơn vị và cải thiện biên lợi nhuận. Đây là động cơ chính đáng cho bất kỳ công ty nào. Nhưng với khách hàng sử dụng nhiều instance, nó cũng có nghĩa là AWS sẽ có ít động lực giảm giá hơn. Các dự án crypto vốn quen với việc tận dụng một lượng lớn tài nguyên đám mây giá rẻ để chạy node thử nghiệm, snapshot, indexer sẽ phải bắt đầu tối ưu. Technical debt ở đây là thói quen thiết kế hệ thống dựa trên giả định cloud rẻ và vô hạn. Khi giả định đó đổ vỡ, toàn bộ thiết kế cũng sụp đổ theo. Không chỉ vậy, căng thẳng dung lượng ở AWS còn tạo ra sự phân tầng trong khả năng tiếp cận tài nguyên. Những khách hàng lớn, đặc biệt là các công ty AI có hợp đồng cam kết chi tiêu khổng lồ, sẽ được ưu tiên khi khởi tạo instance. Các dự án blockchain nhỏ, không có enterprise agreement, sẽ rơi vào nhóm first come, first served và dễ dàng bị từ chối capacity hơn. Điều này không được ghi trong bất kỳ bảng giá nào, nhưng lại diễn ra mỗi ngày. Nếu bạn đang chạy một validator nhỏ và không thể mở thêm instance ở region us-east-1 trong một ngày nóng, bạn sẽ hiểu tôi nói gì. Sự thiếu minh bạch trong việc phân bổ dung lượng là một rủi ro mà thị trường chưa định giá. Câu chuyện bắt đầu có tầng lớp contrarian khi nhìn vào phản ứng của thị trường. Trong khi phần lớn nhà đầu tư đang chạy theo cổ phiếu AI và bán những dự án hạ tầng vật lý, tôi thấy một điểm mù: nếu AWS phải tối ưu CPU vì giới hạn phần cứng, điều đó nghĩa là mô hình thuê tài nguyên từ một công ty lớn đang chạm trần. Các dự án DePIN có thể hưởng lợi gián tiếp, không phải vì họ tốt hơn, mà vì thị trường bắt đầu nhìn nhận giá trị của việc phân tán tài nguyên tính toán. Tất nhiên, đây là những gì funding rates ám chỉ trong mấy tuần gần đây: thị trường sideway, không ai dám khẳng định xu hướng, nhưng chi phí thuê sức mạnh tính toán lại tăng đều đặn. Khi chi phí đầu vào tăng, những dự án sử dụng nhiều tài nguyên sẽ bị ép biên lợi nhuận, trong khi những dự án biết tối ưu hoặc tự chủ hạ tầng sẽ trụ lại. Một góc nhìn phản trực giác khác: việc AWS giảm CPU waste không nhất thiết là tin xấu. Nếu họ làm đúng, khách hàng có thể không nhận thấy gì, nhưng AWS sẽ có thêm dư địa để cấp phát instance, giữ giá ổn định và giảm tình trạng insufficient capacity khi khởi tạo máy. Lợi ích thiết thực nhất với Web3 nằm ở dạng này: nhiều validator nhỏ tạm thời không thể mở thêm instance do thiếu dung lượng ở một số region. Nếu AWS tối ưu tốt, số region có thể sử dụng sẽ tăng lên, giúp các node phân bố đều hơn. Ngược lại, nếu tối ưu kém, họ có thể đẩy workload vào vùng tài nguyên tập trung, tạo ra điểm nghẽn mới, thậm chí gây mất ổn định cho các chuỗi có node chạy trên EC2. Tôi không lạc quan quá mức. Lịch sử cho thấy các chương trình tối ưu hiệu suất trong các tập đoàn lớn thường đạt 70% mục tiêu rồi chững lại, vì xung đột giữa các đội kỹ thuật và áp lực phải giao tính năng mới. Nếu AWS không có cơ chế khuyến khích đủ mạnh, kỹ sư sẽ tối ưu phần dễ, bỏ qua phần khó. Phần khó là hệ thống scheduler phân tán, nơi quyết định workload chạy trên máy nào. Việc tối ưu một scheduler đòi hỏi thay đổi lớn và có thể làm gián đoạn hàng triệu instance nếu xảy ra lỗi. AWS sẽ phải chấp nhận rủi ro. Và trong thị trường đi ngang hiện tại, mọi rủi ro hạ tầng đều có thể phản ánh vào giá token của những dự án phụ thuộc nhiều vào cloud. Một hướng đi khác nằm ở sự dịch chuyển sang self-hosted. Các nhà vận hành node độc lập, các tổ chức validator, các nhóm phát triển giao thức có thể bắt đầu đầu tư vào hạ tầng riêng tại nhiều trung tâm dữ liệu nhỏ thay vì đặt hết lên AWS. Xu hướng này đã âm ỉ từ khi FTX sụp đổ, vì các quỹ bắt đầu lo ngại rủi ro đối tác. Giờ đây, nó có thêm một lý do kinh tế kỹ thuật. Nếu AWS không thể đảm bảo capacity, thì việc chạy trên bare-metal tại một colocation ở châu Âu hoặc châu Á trở nên hấp dẫn hơn, dù chi phí vận hành có thể cao hơn một chút. Đây là nơi các dự án DePIN có thể tạo ra giá trị thực tế: bằng cách xây dựng một thị trường mở cho compute, họ giúp các dự án khác chuyển dịch khỏi cloud tập trung mà không cần lo lắng về việc tìm kiếm nhà cung cấp. Tôi từng nói với một người sáng lập DeFi rằng: “Nếu chúng ta nhìn vào merkle tree, mọi thứ có vẻ hoàn hảo, nhưng nếu nhìn vào nơi lưu trữ cây merkle đó, bạn sẽ thấy trung tâm dữ liệu của AWS.” Anh ấy cười, nhưng không phủ nhận. Đó là vấn đề của cả ngành. Chúng ta chăm chút tính phi tập trung trên lớp đồng thuận, nhưng bỏ quên tính phi tập trung của hạ tầng. Khi AWS siết lại, giá trị của những nguồn lực thay thế sẽ tăng. Đó là lý do tôi vẫn quan sát mảng DePIN, không phải vì token của họ tăng giá, mà vì áp lực thật từ phía cung đang tạo ra một thị trường cho họ. Cuối cùng, câu chuyện AWS giảm lãng phí CPU không chỉ là một tin nội bộ về hiệu quả, mà là một tín hiệu cho thấy kỷ nguyên tài nguyên không giới hạn đã kết thúc. Và trong một kỷ nguyên khan hiếm, những ai kiểm soát được hạ tầng của chính mình sẽ nắm lợi thế lớn nhất. Blockchain có thể không cần AWS, nhưng Web3 lại đang rất cần một câu trả lời cho bài toán này.