【2026 最新】BitTorrent 式 LLM 怎麼跑？DRIFT-LLM 私有 Mesh 雙機教學

你有兩台各自塞不下一個大模型的電腦，能不能像 BitTorrent 一樣「大家湊 RAM」就跑起來？可以，但真正發生的事不是把模型檔案隨機切碎，而是讓每台機器接手一段 Transformer 層。這篇 DRIFT-LLM 私有 Mesh 教學會帶你從零看懂層切分、hidden state、KV cache 與網路瓶頸，再完成一套可回滾的雙機驗收。

全文專為第一次碰分散式推論的人寫。你會拿一個只有 8 層的公開小模型先驗證管線，而不是一開始就下載數十 GB 權重；也不會把任何公司資料、個資或憑證交給陌生節點。重點不是追求漂亮跑分，而是學會判斷：第二台機器究竟解決了「放不下」，還是真的解決了「跑不快」。

先說結論：它像接力賽，不像共享硬碟

• 能做：DRIFT-LLM 讓多台你能控制的機器各自載入連續模型層，合起來完成一次生成。
• 不保證更快：雙機的價值通常先是讓原本放不下的模型「能跑」；單一請求還會多出網路往返與序列化成本。
• KV cache 分散存放：每個工作節點保留自己所負責層的注意力快取；解碼每個 token 都得依序經過整條路線。
• 私網不等於零信任：Tailscale 可保護傳輸路徑，但實際執行模型層的節點仍接觸運算輸入；所有節點都應視為信任邊界的一部分。
• 公網要換一套威脅模型：CommunityAI 被選中的 text peer 能讀到完整 prompt；後續 block workers 則處理由請求衍生的 activations。alpha 階段只傳你有權公開且不含秘密或個資的內容。

DRIFT-LLM 私有 Mesh 是什麼？先記住一句公式

分散式 LLM ＝ 模型層接力 × 各層本地 KV cache；速度看整條路的瓶頸，隱私看最不可信的一棒。

把 8 層模型想成一條有 8 站的接力路線。A 電腦負責第 0～3 層，B 電腦負責第 4～7 層；文字先變成 token，client 把 A 與 B 串成路線，讓中間表示（hidden state，可理解成模型內部的數字工作稿）依序穿過兩段。這是邏輯資料流，不代表封包一定由 A 直接送到 B；固定 commit 的目前實作可能經 client 接回下一段。DRIFT-LLM 的固定版本 README把它描述為連續 Transformer blocks、自管 DHT 發現與完整層覆蓋；截至 2026 年 9 月，該專案定位是自行管理的私有 cluster，而不是官方提供的公共主網。本文的「私有」指 bootstrap、workers 與網路均由自己管理，不代表 DRIFT protocol 自帶成員授權或資料不外流保證。

先拆四個零件：模型層、hidden state、KV cache、DHT

① 模型層：「每台機器守幾站」

層切分（layer sharding）不是把同一層平均分給兩張卡，而是把連續層分段。這比較接近 pipeline parallelism：A 的輸出會成為 B 的輸入。相對地，tensor parallelism 是把一層內部的矩陣計算拆開，通常需要更頻繁同步。DRIFT-LLM 採前者；若你想先補齊本機推論引擎的全貌，可搭配LLM 推論引擎白話指南閱讀。

② Hidden state：「交給下一棒的數字工作稿」

前一段模型層完成後，會把 activation／hidden state 傳給下一段。它不是原始文字封包，但也不能因此宣稱「看不懂就等於安全」；能運算它的節點本來就是你的信任面。Petals 的分散式推論研究也把私人 prompt 的保護列為限制，並建議敏感資料只交給可信節點或隔離網路。

③ KV cache：「每一站自己的前文便條」

生成第二個 token 時，模型不想把第一個 token 的注意力全部重算，所以每層會保留 past keys 與 values。Hugging Face 的 cache 說明指出，快取會隨序列長度增長；在層切分架構裡，A 保存第 0～3 層的 cache，B 保存第 4～7 層的 cache。這也是長上下文與併發請求會快速吃掉記憶體的原因。想再深入，可接著看Agent KV Cache 擴充實戰。

④ 自管 DHT：「只有地址簿，不是中央司令台」

DHT（分散式雜湊表）可先想成節點地址簿：它讓 client 找到「誰持有哪幾層」，再選出能覆蓋全模型的路線。它不會把慢機器變快，也不會自動替缺少的層生出備援。雙機各持有唯一一半時，任一台離線，完整路線就不存在。

開工前：把這次實驗縮到真的能驗收

這份流程使用 DRIFT-LLM 倉庫在 2026 年 9 月 14 日查得的 commit dd294a15…，模型使用公開的 Maykeye/TinyLLama-v0 固定 revision。它只有 8 個 hidden layers，適合驗證「兩台是否真的串起來」，不適合評估回答品質，也不能代表大型模型速度。

1. 兩台自己管理的測試機，先以 CPU／float32 跑通；有 GPU 再調整。
2. Python 3.10 以上、Git、uv 與 Tailscale 已可用。
3. 兩台都只放合成 prompt，不掛工作目錄、不帶雲端金鑰。
4. 保留本機鍵盤或其他 recovery path；故障注入時只停 DRIFT 程序，不停遠端連線工具。
5. 先記錄 OS、CPU/GPU、RAM、Tailscale 版本、DRIFT commit、模型 revision、dtype 與層切分。

DRIFT 的官方 README 提供一行遠端安裝腳本；教學環境更適合先 clone、檢查 commit 再安裝，因為你看得見自己要執行哪一版程式。以下只涵蓋 POSIX shell；Windows 的命令語法與原生依賴不同，不屬於這條已查核路徑。

git clone https://github.com/ApexDevelopment/DRIFT-LLM.git
cd DRIFT-LLM
git checkout dd294a15da3b3b9c61c51e6bf36d58696759cec9
uv sync --frozen --extra api
git rev-parse HEAD

DRIFT-LLM 私有 Mesh：兩台電腦逐步部署

步驟 1：先證明 Tailscale 走得通

兩台機器登入同一個 tailnet 後，各自執行 tailscale ip -4 記下位址，再由 A 執行 tailscale ping <B 的名稱或 IP>，B 反向再做一次。Tailscale 官方連線文件區分 direct、DERP relay 與 peer relay；三者資料面都有端對端加密，但 relay 往往增加延遲，所以跑分時必須把實際路徑一起記錄。

別只新增一條窄規則就以為舊的 allow-all 消失了。規則是累加的，請先審核整份 tailnet policy，再依官方 Grants 指南只允許這兩台實驗機彼此連到各自的 TCP 31337；若 API client 在第三台，再單獨加入該 client 到 workers 的規則。MagicDNS 只是名稱解析，不是授權；Funnel 會把服務公開到 Internet，這個實驗不要開。

步驟 2：A 機持有 0～3 層

把 <A_TAILSCALE_IP> 換成 A 的實際 Tailscale IPv4。監聽與對外宣告都只填這個位址，再用主機防火牆與 tailnet policy 限制來源；啟動後另外確認 LAN／WAN 介面沒有 31337 listener。

uv run drift up Maykeye/TinyLLama-v0 \
  --revision 298338802ab94432b917bcce11382aa151aee50f \
  --block_indices 0:4 \
  --device cpu --torch_dtype float32 --quant_type none \
  --host_maddrs /ip4/<A_TAILSCALE_IP>/tcp/31337 \
  --announce_maddrs /ip4/<A_TAILSCALE_IP>/tcp/31337 \
  --no_auto_relay

A 機準備完成後會印出 drift://… join token。把它當成叢集入口資訊，不要貼到公開 issue 或聊天群。

步驟 3：B 機持有 4～7 層

uv run drift up Maykeye/TinyLLama-v0 \
  --join 'drift://<PEER_ID>@<A_TAILSCALE_IP>:31337' \
  --revision 298338802ab94432b917bcce11382aa151aee50f \
  --block_indices 4:8 \
  --device cpu --torch_dtype float32 --quant_type none \
  --host_maddrs /ip4/<B_TAILSCALE_IP>/tcp/31337 \
  --announce_maddrs /ip4/<B_TAILSCALE_IP>/tcp/31337 \
  --no_auto_relay

驗收訊號不是「兩個終端都沒報錯」，而是 client 能找到 0～7 層的完整覆蓋並生成 token。若顯示缺層，先核對兩台的 model、revision、DHT prefix／join token 與區段邊界；不要靠反覆重啟掩蓋設定差異。

接出 OpenAI-compatible endpoint，但只綁 localhost

在 A 機另開終端，從剛才的 join token 取出完整 multiaddr，啟動 API。固定 commit 的 drift api 原始碼顯示預設只綁 127.0.0.1、預設同時生成數為 1，並支援 API key；先保留這些保守設定。

export DRIFT_API_KEY='請改成只用於本機測試的長隨機字串'
export DRIFT_MAX_RETRIES=2
uv run drift api Maykeye/TinyLLama-v0 \
  --initial_peers /ip4/<A_TAILSCALE_IP>/tcp/31337/p2p/<PEER_ID> \
  --torch_dtype float32 \
  --host 127.0.0.1 --port 8080 \
  --api_key "$DRIFT_API_KEY" \
  --max_concurrent 1 --default_max_tokens 64

要注意一個版本邊界：這個 commit 的 server CLI 有 --revision，但 drift api CLI 沒有同名參數。本文查核當下，TinyLlama 倉庫預設 revision 與上面固定 SHA 相同；真正要長期部署時，不能把這個巧合當完整供應鏈保證，應在 client 程式碼明確傳入 revision，或鎖定並驗證完整下載 manifest 後再上線。這個 TinyLlama checkpoint 的固定 tokenizer 設定沒有 chat template，因此下面先驗證 /v1/completions，不要用 chat endpoint 測它。

curl --max-time 30 -sS http://127.0.0.1:8080/v1/completions \
  -H "Authorization: Bearer $DRIFT_API_KEY" \
  -H 'Content-Type: application/json' \
  -d '{
    "model":"Maykeye/TinyLLama-v0",
    "prompt":"The mesh status is",
    "max_tokens":16,
    "temperature":0,
    "stream":false
  }'

這一關的 PASS 是收到非錯誤 completion、usage 與生成 token，不是要求小型 base model 聽懂 mesh-ok。--max-time 只限制 curl 等待時間；client 中斷不保證後端 generation thread 同步取消。故障演練後若 API 還在重試，停止並重啟 API，再進行下一組測試。

如果另一台應用程式要呼叫，不要立刻改成 --host 0.0.0.0。較容易審核的做法是保持 localhost，另外用 SSH tunnel 或經審核的 Tailscale Serve 私下轉送；Serve 語法曾改版，請依你安裝版本的官方文件操作。若你的目的是把 LLM 服務給 Agent 使用，還可接著看Tailscale AI Agent Fleet 教學。

量測不要猜：單機、雙機、慢節點三組一起看

小模型 smoke test 只證明管線通，不能回答效能問題。正式測試時，先確認同一模型與同一精度確實能在單機放得下，才有公平的單機基線；放不下時，結論只能是「Mesh 讓它可行」，不能宣稱加速。每組固定 prompt、max_tokens 上限、sampling 設定與重複次數，另記錄實際輸出 token 數，冷啟動和暖機後結果分開。

1. TTFT：client 送出請求到收到第一個非空生成內容；不把 HTTP header、role-only 或空 SSE chunk 算成首 token。它包含排隊、路由、prefill 與網路，不能直接等同 prefill。
2. ITL：相鄰兩次串流輸出的間隔；先確認一個 chunk 是否剛好等於一個 token。
3. 每請求 decode rate：(輸出 token − 1) ÷ (最後 token 時間 − 第一 token 時間)。
4. 成功率與錯誤：保留 timeout、缺層、連線重建與 HTTP 狀態，不只抄平均值。
5. 資源：逐機記錄 CPU、RAM、GPU／VRAM 與溫度，才能看出 50/50 是否真的平衡。
6. 網路：記錄 direct 或 relay、RTT 與雙向 throughput；容器 NET I/O 是累積總流量，不能直接叫作 hidden-state bytes。

單一請求延遲近似各階段運算、傳輸、排隊與回程成本的總和；有重疊請求時，持續吞吐量才更接近被最慢 stage 或 link 卡住。這就是為什麼「速度看最慢一棒」是一個好記憶法，但不是精確到可以忽略其他站的公式。

故障注入：加延遲，跟直接拔掉一台，是兩回事

慢節點測試：先保存基線，再用你能控制的 Linux 測試主機在 host 網路層加入固定延遲；tc netem 需要管理權限，不要把 NET_ADMIN 永久加進推論容器。每次變更前先記錄原設定，完成後立刻移除，並重新確認 Tailscale 路徑。macOS／Windows 不要照抄 Linux 指令，改用各平台的測試工具。

斷線測試：使用合成 prompt、有限 client timeout，然後在 B 機按 Ctrl+C 停 DRIFT server，記錄請求是立即失敗、等待逾時，還是重連。兩台各持唯一 shard 時沒有替代路線，預期是完整覆蓋消失；若要驗證 reroute，必須再加一個持有相同 4～7 層的備援節點，否則不能宣稱自動續跑。

CommunityAI 公網不是「比較大的私網」：先換威脅模型

CommunityAI 把 DRIFT 的層接力概念延伸到志願節點網路，並提供桌面介面與本機 OpenAI-compatible endpoint。截至 2026 年 9 月 14 日，最新 GitHub prerelease／tag 是 v0.1.0-alpha.20260909.3，發布於 2026 年 9 月 9 日；alpha 代表介面、風險控制與行為仍可能快速改變。

最重要的不是封包有沒有加密，而是誰必須解密並執行你的請求。CommunityAI 發布版的固定架構文件顯示，完整 request 會交給被選中的 text peer；後續 block workers 收到由請求衍生的 activations。它的固定安全邊界則說明：public libp2p 傳輸加密不能阻止 text peer 記錄內容，也不能證明 peer 誠實推論。因此，公網 alpha 只傳「即使公開也沒關係」的內容。

• 可以放：自製測試句，或已公開、你有權傳送且經檢查不含個資／秘密的文字；合成資料也不得混入真實資料片段或可識別個人資訊。
• 不要放：客戶對話、原始碼、未發布文件、醫療／財務／身分資料、API key、cookie、token、內網位址。
• 輸出也不預設可信：惡意或故障 text peer／block worker 可能回傳錯誤結果；高價值決策要在可信環境重新驗證。
• 暫停分享算力不等於抹除：已交給被選中 text peer 的內容無法靠關閉 app 收回。

若你需要處理私有資料，先停在自己控制的 DRIFT-LLM 私有 Mesh，並參考本機 LLM 安全指南建立金鑰、日誌與網路邊界；「本機」或「VPN」都只是控制的一層，不是自動合格章。

上線前硬化：把模型 hash、容器權限與停機表做完

1. 固定兩種版本，不只記模型名稱

DRIFT 程式碼與 Hugging Face 模型都鎖完整 commit；兩台針對 config、tokenizer、權重與自訂程式建立「路徑＋大小＋SHA-256」manifest 再比對。請記住：兩台 hash 相同只證明檔案相同，若兩台都從同一個不可信來源下載，並不證明它安全。Hugging Face 的模型安全文件也提醒 pickle 類檔案與 remote code 具有程式碼執行風險；能用 safetensors 就優先用，仍要確認來源與 revision。

2. 容器是減少爆炸半徑，不是魔法防護罩

固定 commit 內附的 Dockerfile 以 NVIDIA CUDA 開發映像為底、沒有 USER 指令，預設進入 bash；所以不能直接把它稱為低權限正式環境。若你要自行包裝，至少建立非 root 使用者、唯讀掛載模型、--security-opt=no-new-privileges、保留預設 seccomp、設定 CPU／RAM／PID 上限，且絕不掛 Docker socket、家目錄或整個專案磁碟。從 --cap-drop=ALL 開始驗證；若固定 runtime 明確需要 capability，只加回已證明必要的項目。cap_drop、GPU runtime、rootless Docker 與唯讀檔案系統的組合都要在目標 OS 驗證；Docker 安全文件是配置依據。

3. 寫下「什麼情況立刻停」

• 出現未預期的 public／LAN listener，或 tailnet policy 測試不再通過。
• 模型、程式碼、容器 digest 或 manifest 與核准值不一致。
• 未知 peer 加入、缺層反覆出現、輸出與可信基線持續不符。
• 資源失控、磁碟 cache 無上限增長，或 timeout／錯誤率跨過你預先設定的門檻。
• 測試資料不小心含真實憑證或私人內容：停止請求、輪替憑證、保留必要稽核證據。

怎麼選：單機、DRIFT 私網、CommunityAI 公網

• 模型單機放得下：先用單機。它少了跨機網路與額外節點依賴，也最容易量測。
• 模型放不下，但兩台都由你控制：選 DRIFT-LLM 私有 Mesh，先追求可用性，再判斷效能。
• 想研究志願算力與公網調度：CommunityAI alpha 可當公開資料的實驗場；能否實際生成仍取決於當下是否有完整 block coverage 與可用 text peer，而且它不是私密工作負載的替代品。
• 需要 SLA、審計或高併發：這個雙機教學不是終點；你還需要冗餘 shard、監控、佇列、容量與事件處理設計。

常見問題 FAQ

1. 兩台電腦一定比一台快嗎？

不一定。雙機先解決容量；單一請求會多出跨機傳輸。只有在層分配、硬體、網路與併發模式合適時，特定吞吐指標才可能改善，所以要用同模型、同精度基線比較。

2. 傳的是 hidden state，prompt 就安全了嗎？

不能這樣推論。中間表示不是原始文字，不代表不洩漏資訊；處理它的節點也可能接觸其他請求資料或輸出。敏感 prompt 只在可信節點與隔離網路處理。

3. KV cache 放在哪裡？

主要跟著模型層走。每個 worker 保留自己所服務層的注意力快取；client 另保留能用於路由重建的歷史／輸入。實際生命週期與恢復行為仍以固定版本實作為準。

4. 拔掉 B 機會自動切到 A 嗎？

雙機唯一 shard 不會。A 沒有第 4～7 層，就無法補上 B。要測 reroute，至少要有另一個覆蓋相同區段且已被路由發現的 worker。

5. Tailscale 會不會經過中繼？

可能。無法建立 direct 路徑時可經 DERP 或 peer relay，資料仍端對端加密，但延遲與吞吐可能不同；每次測試都記錄 tailscale status／tailscale ping 顯示的路徑。

6. 可以直接拿 Llama 8B 做第一輪嗎？

可以，但不建議當第一步。先用 8 層小 checkpoint 排除網路、版本與路由錯誤；管線通過後，再依兩台 RAM／VRAM 選擇同架構模型，並重新規劃 block 範圍。

7. CommunityAI 的 public peer transport 已加密，為什麼 text peer 還看得到 prompt？

因為 consumer 仍會把完整 request 交給被選中的 text peer。TLS 保護傳輸中的資料；text peer 端仍要解析、tokenize 並生成。後續 block workers 接收由請求衍生的 activations，而不是原始 prompt，但這也不能視為沒有洩漏風險。

8. 這能當正式服務嗎？

這份雙機配置只是一個驗收起點。正式服務還要補備援 shard、容量規劃、監控告警、金鑰輪替、資料分級、日誌政策與演練過的停機程序。

給新手的 5 個重點

1. 先用小模型證明「路線完整」，再換大模型驗證容量。
2. 第二台機器解決的是放不下，不自動等於更快。
3. 把 TTFT、ITL、decode rate、失敗率、資源與網路路徑一起記錄。
4. 雙機各持唯一一半沒有容錯；要測 reroute，先準備重複 shard。
5. 傳輸加密不會讓執行工作的陌生 peer 變成可信節點。