Vài tháng trước mình mất cả tuần săn lùng p99 latency trên pipeline agent của một client. Từng API call riêng lẻ nhìn trên graph đều ổn — 80ms, 120ms, không có gì đáng lo. Rồi mình cộng dồn cả một vòng tool-call loop: retrieve, reason, gọi một tool, reason tiếp, gọi tool khác, reason lần nữa. Sáu bước, mỗi bước một round trip riêng, tổng cộng vượt quá một giây trước cả khi model bắt đầu sinh câu trả lời cuối. Không ai tính đến điều đó cho tới khi tự đo. Đó là lăng kính mình dùng để đọc thương vụ Anthropic-Akamai vừa ký, và nó thay đổi hoàn toàn ý nghĩa thật sự của thông báo này.
Điều thực sự đã được ký
Ngày 24/9/2026, Akamai công bố hợp đồng nhiều năm trị giá 11,6 tỷ đô với Anthropic, kéo dài 7 năm, có quyền mở rộng thêm tối đa 9 tỷ đô — tức trần thực tế gần 20,6 tỷ nếu cả hai bên dùng hết quyền chọn. Phần cổ phần mới là chỗ đáng đọc kỹ hai lần: Akamai phát hành cho Anthropic warrant cho 7,7 triệu cổ phiếu, tương đương khoảng 5% cổ phần lưu hành của Akamai, giá thực hiện 111,33 đô/cổ phiếu. Khoảng 2% vest ngay khi ký; 3% còn lại vest theo từng nấc khoảng 1% cho mỗi 3 tỷ đô dịch vụ cloud mà Anthropic thực sự mua thêm, cho tới trần mở rộng 9 tỷ đó. Đây không phải giấy tờ khách hàng-nhà cung cấp thông thường — nó được thiết kế để thưởng cho việc Anthropic thực sự dùng năng lực đó, không chỉ cam kết suông trên thông cáo báo chí.
Điều thông cáo không nói là workload nào chạy ở đâu. Không có tỷ lệ inference-so-với-training, không phân tách batch-so-với-latency-sensitive. Ngôn ngữ cố tình chung chung: hỗ trợ “nhu cầu workload CPU đang tăng tốc của Anthropic” và giúp họ “xây dựng, triển khai và vận hành workload AI ở quy mô lớn.” Muốn tìm lập luận kỹ thuật vì sao thương vụ này hợp lý, phải quay lại đọc những gì chính CTO của Akamai viết từ năm tháng trước.
Lập luận về 28 mili giây
Hồi tháng 4/2026 — đúng lúc Anthropic ra mắt kiến trúc “Managed Agents,” tách lớp reasoning “bộ não” stateless khỏi lớp thực thi “bàn tay” có thể bật/tắt độc lập — CTO Akamai Robert Blumofe đăng một bài lập luận rõ ràng cho hạ tầng phân tán. Con số ông đưa ra: một người dùng ở London gọi tới endpoint inference đặt tại Virginia mất khoảng 28ms độ trễ lan truyền mỗi chiều trước khi token đầu tiên quay về. Không phải thời gian tính toán. Chỉ là vật lý của ánh sáng trong sợi quang.
28ms một chiều nghe không nhiều, cho tới khi đặt nó vào một tool-call loop giống cái mình từng debug. Nếu bước reasoning của agent nằm ở Virginia và mọi tool call nó gọi cũng phải round-trip về Virginia — vector search, tra database, gọi service khác — bạn không trả 28ms một lần, mà trả nó ở mỗi bước, cộng dồn cùng thời gian tính toán thật ở từng giai đoạn. Đưa lớp thực thi lại gần nơi tool call thực sự diễn ra sẽ cắt được khoản thuế lặp lại đó, dù phần reasoning nặng vẫn chạy trên GPU đặt tập trung ở đâu đó.
Đó là lập luận thực sự tốt cho việc phân tán thực thi ra edge. Nhưng lại là lập luận yếu hơn nhiều cho việc phân tán inference ra edge, và thông báo thương vụ cố tình làm mờ ranh giới giữa hai thứ này, vì “workload CPU” đủ mơ hồ để bao gồm request routing, embedding, điều phối tool, xử lý trước/sau — tất cả đều chạy tốt trên hạ tầng CPU edge của Akamai — mà không cần cam kết chuyển trọng số model thật tới gần node edge nào cả. Inference của model frontier vẫn phụ thuộc GPU áp đảo và vẫn tập trung ở một số ít khu vực; một thương vụ về năng lực CPU không thay đổi điều đó.
Góc nhìn thật của mình
Mình không nghĩ thương vụ này chủ yếu để sửa độ trễ, dù có mượn câu chuyện marketing từ bài của Blumofe. Mình nghĩ đây là phòng hộ năng lực (capacity hedging) kèm theo câu chuyện độ trễ cho đẹp, vì phòng hộ năng lực đơn thuần không làm nên một thông cáo báo chí hay, và “chúng tôi mua thêm CPU vì đang tăng trưởng nhanh” nghe nhẹ hơn nhiều so với con số 20 tỷ đô. Chi tiết tố cáo điều này chính là cấu trúc warrant: nó được thiết kế để thưởng cho mức sử dụng thực tế tăng dần qua nhiều năm — đúng thứ bạn sẽ thiết kế nếu mối lo thật sự là “liệu có đủ compute xếp hàng khi nhu cầu mở rộng,” chứ không phải “có vấn đề độ trễ cần giải quyết trong quý này.”
Điều đó không làm luận điểm về workload CPU trở nên vô nghĩa — ngược lại là đằng khác. Khi hệ thống agent trưởng thành hơn, phần việc phía CPU (routing, retrieval, điều phối, thực thi tool, kiểm tra guardrail) tăng nhanh hơn nhiều so với phần reasoning phía GPU mà hầu hết mọi người mặc định, và đây đúng là loại workload hưởng lợi khi đặt gần người dùng và gần các service nó gọi tới. Nếu bạn đang thiết kế một nền tảng agent lúc này, bài học hữu ích không phải là “đưa LLM call ra đa vùng” — mà là “đo xem bao nhiêu phần trong ngân sách độ trễ tổng của bạn thực sự là inference GPU, so với phần còn lại trong vòng lặp,” vì với rất nhiều hệ thống agent production, “phần còn lại” lớn hơn người ta tưởng — và đó là phần bạn thực sự có thể dịch chuyển được.
Mình quay lại đo lại pipeline sáu bước từ vài tháng trước với cách chia này trong đầu. Inference GPU chiếm 40% tổng độ trễ. 60% còn lại là retrieval, tool call, và các bước network — tất cả những thứ mà một hạ tầng CPU edge, đặt đúng chỗ, có thể thu nhỏ lại. Canh bạc của Akamai có thể tốt hơn những gì thông cáo báo chí thể hiện.