同時運行1500個AI智能體得到的六個數字

本文是系列文章的第四篇。前三篇奠定基礎：第一篇展示瞭如何在加載時重寫二進制文件的每個系統調用，使客户程序無法繞過運行時；第二篇解釋了為何不運行客户內核，僅用一個36KB的墊片處理智能體實際需要的約30個系統調用；第三篇介紹了池守護進程：虛擬機如何預熱、連接如何預先建立、運行時如何位於每個智能體的路徑上。

第四篇來得比預期晚。不是寫作障礙，而是工作本身——讓1500個虛擬機真正穩定運行，讓池守護進程在真實負載下保持TLS會話，追蹤那些直到從開發機遷移到AWS不同CPU系列才出現的快照可移植性缺陷。這篇博客的存在是因為系統現在足夠穩定，可以可靠地測量。

本文介紹的是利用所有這些技術能實現什麼——大規模運行的實際面貌。

每個數字均來自在單個AWS c6i.metal實例上同時運行1500個完全KVM隔離的虛擬機。不是容器，不是共享內核的進程。每個智能體擁有自己的虛擬機，自己的硬件隔離邊界。

我試圖回答的問題是：這實際上要付出什麼代價？內存、延遲、吞吐量——隔離模型是否讓其中一些變得不可測量，還是你處處都要為此付出代價？

以下是運營儀表板顯示的數據。

1. 暖啓動虛擬機時間——0.42秒

在任何事情之前，池必須就緒。

以樸素方式預熱1500個KVM虛擬機——fork、exec、boot、import——每個智能體運行依次耗時約200毫秒。第一個作業運行前就要五分鐘。

我們的做法是：將Python通過完整導入序列運行一次，在那一刻凍結虛擬機，並將結果保存為快照。99MB的非零頁面——解釋器狀態、加載的模塊、預解析的導入。在池啓動時，所有1500個虛擬機並行從該快照恢復。物理頁面在虛擬機之間共享，直到某個智能體寫入。每個智能體無需支付導入成本。

需要澄清一點：該快照僅包含Python標準庫。用户級導入——anthropic、openai、requests，無論智能體使用什麼——仍在智能體啓動時發生。我們可以在啓動序列後期（這些導入之後）拍攝快照，進一步縮短調度時間。但代價是，你會得到按智能體類型不同的快照，而不是整個集羣共享的通用Python鏡像。我們選擇了通用鏡像——0.42秒已經夠快，而且一個鏡像操作更簡單。

條形圖顯示了1500個虛擬機在100毫秒時間桶中的分佈。大多數落在前兩個桶中。總牆鍾時間：0.42秒。

我們沒有客户內核。墊片只有約36KB。沒有其他東西。

1. 運行密度——10.8個智能體/GB

這是我最常被問到的數字。

1500個KVM隔離的虛擬機——每個都在向LLM API發起活躍TLS調用——適配在139GB物理內存中。即每GB 10.8個智能體，不是空閒，不是靜態，而是在真實負載下。該數字包括智能體運行時累積的一切：Python堆、打開的TLS會話、傳輸中的請求緩衝區、棧幀、系統調用狀態。

ps RSS顯示更高——所有VMM進程總和約290GB。這個數字具有誤導性：99MB的Python快照在所有1500個工作者之間共享，RSS會計將其計入每個進程一次，而非每個物理頁面一次。儀表板上的139GB是物理內存，直接從宿主機測量。

10.8個智能體/GB是在真實負載下測量的。一個空閒虛擬機成本為3MB（上文）。你的數字將介於兩者之間，取決於你的智能體做什麼以及運行時累積多少堆。

1. DNS緩存——100%命中率，260,700次命中

原生Linux進程獲得操作系統級DNS緩存。將該進程移入擁有自己內核的虛擬機，你通常會失去它——客户機運行自己的解析器，發出自己的上游查詢，支付自己的延遲。

我們的客户機沒有內核。DNS查詢通過池守護進程退出，它位於UDP數據包離開宿主機之前的路徑上。池在所有1500個智能體之間維護一個共享緩存——因此每個客户機獲得與原生進程完全相同的效果，甚至更強：一次上游查詢服務整個集羣。

如果50個智能體同時冷缺失同一個名稱，只發出一個查詢，所有50個都得到答案。上游解析器在TTL窗口內每個名稱每窗口只看到一個查詢，無論集羣大小。

如果你一直關注本系列，這聽起來會熟悉：對於池無法解析或處理的任何內容——奇異記錄類型、DNSSEC、任何非標準的東西——查詢會降級到原生Linux棧。與系統調用設計相同的原則。常見情況走快速路徑，真正的東西作為後備。

100%命中率，260,700次緩存命中。在這次運行中，所有1500個智能體都命中相同的兩個端點——api.anthropic.com和本地Postman mock——因此緩存迅速飽和。在更多樣化的集羣中，命中率會降低，但合併效益無論如何隨智能體數量擴展。隔離沒有讓智能體失去DNS緩存——他們得到了更好的。

1. 首次網絡調用時間——p50 44ms，p99 105ms

智能體代碼是確定性的。同一任務每次都在相同點觸及網絡。因此從調度到首次網絡調用的時間幾乎完全是基礎設施開銷——智能體等待就緒的時間，而非工作時間。

調度到首次系統調用： p50: 44ms p95: 86ms p99: 105ms n: 1500

連接到首次發送（預建立TLS）： p50: 70ms p99: 1.6s n: 1500

調度數字是純基礎設施開銷——虛擬機恢復到首次系統調用。連接數字是直到第一個字節通過預建立TLS會話到達線路的時間。連接上的p99尾延遲反映了在首次發送前遭遇Anthropic速率限制的智能體。

對於一項工作而言，44ms微不足道。但對於連續運行的1500個智能體，這決定了基礎設施是否可測量。

1. TLS緩存——持有338個會話

每次HTTPS調用通常以TCP握手（10-50ms）和TLS握手（50-150ms）開始。在1500個智能體都訪問同一端點的情況下，每次冷連接都會支付大量延遲。

池守護進程位於每個智能體與每個上游目的地之間的網絡路徑中——這意味着它也可以擁有TLS層。

在池啓動時，守護進程建立到配置的上游端點的持久TLS會話。當智能體發起HTTPS請求時，它向環形緩衝區寫入明文。守護進程代表它處理TLS，進入已建立的會話。無需握手，無需往返。

整個集羣持有338個會話。1500個智能體共享338個上游連接。API看到338個連接。智能體看到零握手延遲。

需要直説一點：池守護進程讀取每個智能體請求的明文。這是有意的——同一接縫使得策略執行、憑證注入和響應檢查成為可能。這是否是你想要的取決於你的威脅模型。這是一個設計選擇，而非副作用。

1. 網絡吞吐量——入站33.2 MB/s，出站37.0 MB/s

截至此快照時刻，已完成138,972次LLM調用——自池啓動以來累積，1500個智能體每個大約每秒發起一次調用。

入站33.2 MB/s，出站37.0 MB/s。這些數字隨集羣動態變化——這是實時運行的快照，不是上限。在1500個智能體時，運行時遠未達到c6i.metal的網絡限制。此處約束是LLM API——在我們的案例中是Anthropic速率限制。智能體大部分時間在等待，而非移動字節。

這些數字加起來意味着什麼

將它們放在一起，你得到在運行中的KVM集羣上一個作業的生命週期：

池預熱：1500個虛擬機在0.42秒內完成，密度每GB 10.8個智能體

作業到達：首次網絡調用44ms

智能體解析端點：<1µs DNS緩存命中，0ms TCP（預建立）

智能體發起HTTPS調用：0ms TLS——持有338個會話，智能體寫入明文

響應流回：集羣持續吞吐量33.2 MB/s

每一層的工作原理相同：運行時已經位於路徑中，因此它緩存DNS響應、保持TLS會話、共享快照頁面。無需單獨系統。實施隔離的同一機制也在進行優化。

KVM隔離不一定意味着沉重。這些數字是證據。

在1500個智能體時，節省是可測量的。在10000個時，它們變得結構性——區別在於是否需要更多機器。

下一篇內容將探討，當運行時同時看到主機上每個智能體的每個系統調用、每個DNS查詢、每個TLS會話、每個模型調用時，什麼變得可能。

如果你在生產中運行智能體，且其中任何一點是實際問題——請在LinkedIn上聯繫我。