同時執行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上聯絡我。