Paddler：用两个组件把 llama.cpp 集群管起来
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 写的 LLM/VLM 负载均衡与服务化平台，把 balancer 和 agent 两个可部署组件叠在 llama.cpp 之上。它想解决的是自托管推理的编排问题，代价是把自己绑在了 ggml 这条技术路线上。
- 适合谁用？
- Paddler 适合已经在用 llama.cpp 或 GGUF 模型、并且需要把推理分散到多台机器上的团队，尤其是那些把请求缓冲当作缩容到零前提的场景。它不适合需要 vLLM 级别连续批处理吞吐、或者依赖非 ggml 推理后端的团队。
- 能商用吗？
- 可以。Apache-2.0 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 58 天前。
- 用什么语言写的？
- 主要是 Rust（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它想解决的是自托管推理的编排问题，不是推理本身
llama.cpp 本身已经能跑推理，但它是单进程的。当你想把四台带 GPU 的机器组成一个推理池，或者想让办公室里的笔记本在空闲时贡献算力，缺的不是推理内核，而是一层调度。Paddler 补的就是这一层。README 的定位写得很直白：开源 LLM 负载均衡器与服务化平台，让用户在自己的基础设施上运行、部署和扩展 LLM。
目标用户分得很清楚。产品团队需要在自己的功能里嵌入推理和向量生成；DevOps 与 LLMOps 团队需要在规模上运行模型；医疗、金融这类对合规和隐私有硬要求的组织，需要数据不出自己的机房；还有一类是想把按 token 计费换成可预测的固定成本。这四类需求的共同点是：他们不想要一个托管的 API，而是想要一个自己能控制的推理端点。
需要说明的是，Paddler 并不训练模型，也不做模型量化。它假设你已经有 GGUF 格式的模型文件，剩下的调度、分发、监控由它负责。
balancer、agent、slot 三层结构
整个系统只有两个可部署组件，这是 Paddler 相对同类项目最核心的设计取舍。
balancer 对外暴露三个服务。inference 服务给应用程序调用，返回 token 或 embedding；management 服务在内部管理整个集群；web admin panel 提供浏览器界面，用来监控、配置和测试。agent 通常部署在另外的机器上，它不直接对外，而是把收到的请求继续下发给 slot。slot 才是真正生成 token 和 embedding 的地方。
关键在于 slot 的实现。README 明确写道，Paddler 使用内置的 llama.cpp 引擎做推理，但 slot 是它自己的实现，每个 slot 维护独立的上下文和 KV cache。这个细节决定了并发行为：请求不是排队进同一个进程，而是被分配到持有独立 KV cache 的 slot 上。agent 上的 --slots 参数控制的就是这个数量。
agent 可以动态加入，这一点 README 特意点出，是为了配合自动扩缩容工具。请求缓冲则让集群可以从零台主机开始扩展。这两条放在一起看，说明 Paddler 的调度模型是面向弹性设计的，而不是面向固定机架的。
启动一个集群只需要两条命令
Paddler 打包成单个二进制文件，README 给出两种获取方式：从 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
三个地址分别对应推理服务、管理服务和 Web 面板。README 说明 --web-admin-panel-addr 是可选的，但加上它才能在浏览器里查看集群状态。
启动一个带 4 个 slot 的 agent：
paddler agent --management-addr 127.0.0.1:8060 --slots 4
agent 通过 --management-addr 连回 balancer 的管理端口，这一点在跨机器部署时要特别注意，127.0.0.1 只在同机测试时成立。
配置模型、聊天模板和推理参数在 Web 管理面板的 Model 分区完成，README 里对应的是模型与提示词两个界面截图。文档还列出了几条起步路径：基础集群搭建、使用管理面板、生成 token 与 embedding、函数调用、语法约束、多模态模型、多 agent 集群，以及跨设备部署。
桌面版是给非运维场景准备的，也是风险最集中的地方
Paddler 有两个版本：面向基础设施的命令行版本，和面向休闲场景的桌面应用。README 把桌面版标为 beta。它的目标场景很具体：把几台笔记本和 PC 拼成本地 AI 集群，或者在办公室搭一个公司内部的第二大脑，全程不碰控制台。README 还描述了一种混合用法，服务器机架上跑 balancer，办公室里某位同事的 RTX 5090 在闲置时临时接入当 agent。
这个场景听起来轻松，但工程含义不轻。临时接入意味着 agent 会随时上下线，而 balancer 的请求缓冲要能吸收这种抖动。桌面版还引入了分发问题：Apache-2.0 允许你分发二进制，但你打包进去的模型权重有自己的许可，这两件事不能混为一谈。README 没有展开桌面版的分发与更新机制，这部分需要自己到桌面应用文档里确认。
如果你的场景是稳定的生产推理，桌面版可以完全忽略，命令行版本是唯一需要关心的东西。
它不解决高吞吐批处理，也不支持非 ggml 后端
Paddler 的推理内核是内置的 llama.cpp。这是一个明确的技术边界，不是可以配置的选项。如果你的团队已经在 vLLM 上跑连续批处理，或者依赖 TensorRT-LLM 的量化路径，Paddler 不是替换品，因为它根本走不到那条路上。
slot 模型也有它的代价。每个 slot 持有独立的上下文和 KV cache，这意味着显存占用随 slot 数量线性增长。--slots 4 不是免费的并发，它是四份 KV cache。在显存紧张的卡上，把 slot 数调高会直接压缩可用的上下文长度。README 没有给出 slot 数与显存占用的换算关系，这个数只能自己在目标硬件上量。
另一个需要留意的点是动态模型切换。README 把它列为关键特性，但没有说明切换过程中正在处理的请求会怎样，是排队、失败还是被丢弃。对延迟敏感的服务来说，这个行为必须在压测里确认，而不是在生产里发现。
还有一点：Paddler 的定位是负载均衡与服务化，它不提供多副本一致性、不提供模型版本灰度，这些要在应用层自己做。
和 llm-d、Docker Model Runner 的路线差异
README 直接把 llm-d 和 Docker Model Runner 列为同类项目，并给出自己的差异点：更少的活动部件，更简单的部署，围绕 ggml 生态构建。
这个对比的实质是架构选择不同。llm-d 建立在 Kubernetes 的调度原语之上，走的是云原生推理网关的路线，能力更强，但你要先有一个能用的 K8s 集群，以及维护它的运维能力。Docker Model Runner 把模型分发和运行收进 Docker 的工作流，优势是复用已有的容器工具链，代价是推理层被封装在容器抽象之后。
Paddler 走的是第三条路：单个二进制，两个组件，agent 通过管理端口回连。它不依赖 Kubernetes，也不需要容器运行时。这个选择让它在小规模自托管场景下启动成本明显更低，但也意味着自动扩缩容、健康检查、滚动升级这些能力要么由 Paddler 自己提供，要么由你外部的工具补齐。README 提到 agent 可动态添加以便集成自动扩缩容工具，这句话的潜台词是：扩缩容的决策逻辑不在 Paddler 里。
维护成本、许可证与代码来源
从发布节奏看，v4.1.0-rc1 到 v4.1.0 间隔约一周，v4.0.1 到 v4.1.0 间隔不到两周，版本迭代比较密集。这意味着升级频率可能不低，如果你的部署对停机敏感，需要为版本切换留出流程。项目使用 Apache-2.0 许可，允许商业使用、修改和分发，附带专利授权条款；分发时你需要保留版权与许可声明。具体的合规判断请咨询法务，这里只陈述许可证标识。
代码来源方面，README 有一段专门回答是否接受 AI 生成代码。项目称所有代码都经过人工审查，大部分为手写，同时也在试验用 AI 生成部分代码，并列举了两处成功的用例：连接核心库的 HTTP 客户端，以及整合现有测试的集成测试框架。这段说明本身是透明的，但也提示了一件事：如果你打算审计这个项目的每一行代码，需要把 AI 参与的部分纳入审查范围。
Rust 生态的另一个隐性成本是 MSRV 1.88.0。从源码构建要求工具链不低于这个版本，老旧的 CI 镜像需要先升级。
什么时候该选它，什么时候该绕开
选它的条件比较清晰：你已经在用 GGUF 模型，需要把推理分散到多台机器，团队规模不大，不想引入 Kubernetes。请求缓冲加动态 agent 的组合，对需要缩容到零的场景特别合适，比如内部工具或者流量有明显波峰的业务。
绕开它的条件同样清晰：你需要非 ggml 后端的推理能力，或者你的吞吐瓶颈在批处理效率而不是请求分发。这两种情况下，Paddler 的架构帮不上忙，换一个项目比在它上面做二次开发更划算。
真正需要动手验证的只有三件事。第一，模拟 agent 掉线，看 balancer 的请求缓冲是否按预期吸收流量，以及恢复后 slot 状态是否干净。第二，在目标硬件上测 --slots 从 1 加到 4 时显存和上下文长度的实际变化，README 没有给这个数。第三，触发一次动态模型切换，观察进行中的请求是被排队、失败还是丢弃。这三个答案决定了 Paddler 能不能进你的生产环境，而它们都只能在自己的机器上跑出来。
编辑结论
Paddler 适合已经在用 llama.cpp 或 GGUF 模型、并且需要把推理分散到多台机器上的团队，尤其是那些把请求缓冲当作缩容到零前提的场景。它不适合需要 vLLM 级别连续批处理吞吐、或者依赖非 ggml 推理后端的团队。上手前先在测试环境确认三件事：agent 掉线后 balancer 的请求缓冲是否按预期工作，动态模型切换在目标硬件上占用多少额外显存，以及 Apache-2.0 的分发条款对你打包桌面版应用意味着什么。
社区笔记