Paddler：把 llama.cpp 塞進負載平衡器的自架 LLM 服務平台
Open-source LLM/VLM load balancer and serving platform for self-hosting LLMs (and VLMs) at scale 🏓🦙 Alternative to projects like llm-d, Docker Model Runner, etc but with less moving parts and simple deployments built around ggml ecosystem. Runs on CPU and GPU.
秒懂
- 它是什麼？
- Paddler 以單一 Rust 二進位檔提供 balancer 與 agent 兩種角色，內建 llama.cpp 引擎與網頁管理介面，主打比 llm-d、Docker Model Runner 更少的活動零件。本文拆解它的請求路徑、啟動指令、動態模型切換與擴容到零的能力，並指出它不適合哪些場景。
- 適合誰用？
- Paddler 適合已經決定走 ggml 生態、且願意自己管機器的人：產品團隊要 LLM 與 embeddings、不想被 per-token 計價綁住、或資料不能出內網的組織。不適合需要跨多種推論後端（例如同時跑 vLLM 與 TensorRT-LLM）的團隊，因為它綁定自家 llama.cpp 引擎與自製 slot 實作；也不適合把模型權重放在共享儲存、想靠 autoscaling 頻繁換模型的人，動態模型切換在 agent 之間的一致性代價要先量過。
- 可以商用嗎？
- 可以。Apache-2.0 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 58 天前。
- 用什麼語言寫的？
- 主要是 Rust（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
Paddler 要解的是「自架推論的調度層」這個缺口
llama.cpp 本身能跑模型，但它不是服務平台。它不處理多台機器之間的請求分配，不處理某台 agent 掛掉之後流量要去哪，也不處理「現在沒有機器在線，但請求已經進來了」這種冷啟動情境。Paddler 補的正是這一層。README 開頭把動機講得很直白：數位產品與其使用者需要隱私、可靠性、成本控制，以及獨立於封閉原始碼模型供應商的選項。
它的目標讀者寫得比多數開源專案具體。產品團隊要在功能裡放 LLM 推論與 embeddings；DevOps 或 LLMOps 要把 LLM 跑在規模化的環境；處理敏感資料、有合規與隱私要求的組織（醫療、金融）；想擺脫 per-token 計價、改用可預測成本的人；以及需要穩定模型效能來維持 AI 功能體驗的產品負責人。這份名單的共同點是：他們要的是可自行部署的推論服務，而不是一個模型。
值得注意的是它選擇的定位。它不是要做通用推論伺服器，而是明確綁在 ggml 生態上，用內建的 llama.cpp 引擎。這個選擇換來的是部署單純，代價是後端選項被鎖住。
balancer、agent、slot：三層架構與請求路徑
Paddler 的部署單位只有兩個：balancer 與 agent。balancer 對外開三個介面。inference service 給應用程式連進來取 token 或 embeddings；management service 是內部管理通道，agent 靠它註冊與回報；web admin panel 是可選的，開了就能用瀏覽器看整個叢集。
agent 通常部署在各自的機器上，收到請求後再往下分給 slot。slot 才是真正產生 token 與 embeddings 的地方。README 對 slot 的描述是關鍵：Paddler 使用內建的 llama.cpp 引擎做推論，但有自己的 llama.cpp slot 實作，每個 slot 保有自己的 context 與 KV cache。這句話決定了它的記憶體模型。slot 數量不是抽象併發度，而是實際的 KV cache 份數，agent 的記憶體佔用會隨 --slots 線性增加。
請求路徑因此是：應用程式到 balancer 的 inference service，balancer 依 LLM 特性分配給某個 agent 的 management 通道，agent 再挑一個 slot 執行。這條路徑上有兩次跳轉，agent 是可動態加入的，README 說這是為了讓它與 autoscaling 工具整合。請求緩衝則是另一個機制，讓叢集能從零台主機開始擴充：沒有 agent 在線時請求不會直接失敗，而是被緩衝等待。
啟動一個叢集：兩個指令與三個位址
Paddler 自述為單一二進位檔，取得方式有二：從 GitHub releases 下載最新版本，或從原始碼建置，MSRV 是 1.88.0。整個功能都掛在 paddler 這個指令底下，paddler --help 會列出所有可用子命令。
啟動 balancer：
paddler balancer --inference-addr 127.0.0.1:8061 --management-addr 127.0.0.1:8060 --web-admin-panel-addr 127.0.0.1:8062
三個旗標對應三個服務。--inference-addr 是應用程式連的位置，--management-addr 是 agent 連的位置，--web-admin-panel-addr 是選配，開了才能用瀏覽器檢視設定。
啟動一個帶 4 個 slot 的 agent：
paddler agent --management-addr 127.0.0.1:8060 --slots 4
agent 只需要知道 management 位址與自己要開幾個 slot。這裡的 --slots 是唯一直接影響資源的參數，每個 slot 帶自己的 context 與 KV cache，所以 4 這個數字要對照機器記憶體來決定，而不是照抄範例。
README 另外指向幾份文件：安裝、建立基本 LLM 叢集、使用網頁管理面板、產生 token 與 embeddings、function calling、grammars、多模態模型、多 agent fleet、跨多台裝置。這些主題在 README 裡只有連結，實際內容不在本文明確可查的範圍內。
網頁管理面板與桌面版：兩種操作介面
Paddler 內建網頁管理面板，README 列出三個用途。一是監控 fleet，對應 dashboard 區塊。二是新增與更新模型，並自訂 chat template 與推論參數。三是用 GUI 測試推論。這意味著模型設定與推論參數的調整不需要改設定檔重啟，至少從介面描述看起來是如此。
桌面應用程式標示為 beta，定位與命令列版不同。命令列版給基礎設施用，桌面版給比較隨性的場景，例如把多台筆電與 PC 組成區域 AI 叢集，或在辦公室裡弄一個公司共用的 second brain，全程不碰終端機。README 說兩者可以混用：機架上跑一個 Paddler balancer，然後請辦公室裡有 RTX 5090 的同事在不需要全部算力時臨時接進來當 agent。
這個混用情境是 Paddler 相對其他方案的差異點。多數推論伺服器假設節點是同質的、由維運統一管理；Paddler 允許異質、臨時、可插拔的節點加入同一個 balancer。反過來說，這種彈性也代表節點品質參差，balancer 的分配策略在面對效能差距很大的 agent 時會怎麼表現，README 沒有交代。
動態模型切換與從零擴容：能力與代價
README 的關鍵功能清單裡有兩項值得單獨看：request buffering 與 dynamic model swapping。前者是「從零台主機擴充」的前提。當 autoscaling 把 agent 縮到零，balancer 仍然接受請求並緩衝，等 agent 起來再送出去。這對間歇性負載的內部工具很實用，因為它讓「沒有機器在跑」不等於「服務中斷」。
但緩衝有邊界。README 沒有給出緩衝的上限、逾時行為，或緩衝期間請求是否會失敗。這些是需要實測才能確定的事，文件在此處偏薄。
動態模型切換同理。它讓 agent 換掉手上的模型權重，但 README 沒有說明切換期間既有請求怎麼處理、多個 agent 之間如何協調、或模型檔案從哪裡取得。在單機上換模型是幾秒到幾十秒的事，在 fleet 上換模型是另一回事。如果你的使用情境需要頻繁切換模型，這部分的實際行為必須先量測，不能只看功能清單上有這一項。
相對地，觀測性有 metrics，但 README 只列了名稱，沒有列出指標清單或匯出格式。
它不適合誰：綁定 ggml 與自製 slot 的代價
Paddler 最大的限制寫在 README 自己的一句話裡：它使用內建的 llama.cpp 引擎。這代表模型必須是 llama.cpp 支援的格式與架構。如果你的團隊已經在用 vLLM 的 PagedAttention、TensorRT-LLM 的編譯流程，或需要跨多種推論後端做 A/B 比較，Paddler 幫不上忙。它不抽象化後端，它就是後端。
第二個限制來自 slot 的實作方式。Paddler 有自己的 llama.cpp slot 實作，每個 slot 保有自己的 context 與 KV cache。這與 llama.cpp 內建的連續批次處理是不同的取捨：獨立 context 讓每個 slot 的狀態單純、隔離清楚，代價是記憶體效率。想要高併發又不想付多份 KV cache 的團隊，這裡會撞到牆。
第三，agent 是經由 management 通道動態加入的。這對 autoscaling 友善，但也意味著 balancer 需要信任這個通道。README 沒有描述 agent 的認證或授權機制，這在跨網路部署時是個必須自己確認的問題。
最後，README 有一節在講是否接受 AI 生成的程式碼，說明所有程式碼都經過人工審查、多數是手寫，並列出實驗成功的部分，例如連接核心函式庫的 HTTP client，以及整合測試框架。這段揭露本身沒有問題，但它也側面說明專案的測試基礎設施仍在演進。
與 llm-d、Docker Model Runner 的路線差異
README 直接把 llm-d 與 Docker Model Runner 列為替代對象，並用「更少的活動零件、簡單部署、圍繞 ggml 生態」來描述自己的差異。這個對比可以拆成兩層。
llm-d 走的是 Kubernetes 原生的路線，把推論調度做進叢集控制平面。Paddler 相反，它是一個二進位檔，balancer 與 agent 直接執行，不要求 Kubernetes。如果你的環境本來就是 K8s，llm-d 的整合方式更貼合；如果你的環境是幾台獨立機器或機架，Paddler 的啟動成本低得多。
Docker Model Runner 走的是容器化與 Docker 工具鏈的路線。Paddler 不依賴容器執行環境，agent 是原生行程，這讓它能直接吃到主機的 GPU 與 CPU，也讓桌面版這種非伺服器場景可行。代價是少了容器帶來的隔離與部署一致性。
這三者的共同點是都在處理「多節點推論調度」，差別在於調度層放在哪裡：K8s 控制平面、Docker daemon，還是 Paddler 自己的 balancer。選哪個取決於你既有的維運模型，而不是功能清單的長短。
授權、維護成本與升級前要確認的事
Paddler 以 Apache-2.0 授權釋出，預設分支為 main，主要語言是 Rust。Apache-2.0 允許商業使用與修改，並附帶專利授權條款，對企業內部部署通常不構成障礙。這不是法律意見，實際條款仍應由法務確認，特別是如果你打算把 Paddler 打包進對外販售的產品。
維護成本方面，可從 README 觀察到的具體項目有幾項。第一，模型檔案要自己管，README 提到動態模型切換，但沒有描述模型散佈機制，這通常意味著你得自己把權重放到每台 agent 上。第二，agent 的加入是動態的，fleet 的成員會變動，balancer 的設定與監控要能跟上。第三，專案仍在活躍開發，從 release 節奏可以看到從 v4.0.1 到 v4.1.0 之間有 rc 版本，主版本號的推進代表設定或行為有可能變動，升級前應先讀 release notes。
MSRV 是 1.88.0。如果你從原始碼建置，Rust 工具鏈版本低於這個數字就編不過。這個約束會隨專案推進而上升，自行建置的團隊要把它納入 CI 的版本管理。
要驗證的第一件事很具體：用 paddler balancer 與 paddler agent --slots N 起一個最小叢集，把 N 從 1 往上加，觀察 agent 的記憶體曲線，確認 KV cache 的實際佔用符合你的硬體上限，再決定正式環境的 slot 數。這個數字只能量，不能猜。
編輯結論
Paddler 適合已經決定走 ggml 生態、且願意自己管機器的人：產品團隊要 LLM 與 embeddings、不想被 per-token 計價綁住、或資料不能出內網的組織。不適合需要跨多種推論後端（例如同時跑 vLLM 與 TensorRT-LLM）的團隊，因為它綁定自家 llama.cpp 引擎與自製 slot 實作；也不適合把模型權重放在共享儲存、想靠 autoscaling 頻繁換模型的人，動態模型切換在 agent 之間的一致性代價要先量過。上手前先確認三件事：你的模型是否已被 llama.cpp 支援、agent 到 balancer 的 management 通道延遲是否可接受、以及 slot 數量與 KV cache 佔用的記憶體是否符合硬體上限。
社群筆記