Paddler
Paddler 是一个开源的、可用于生产环境的、有状态的负载均衡器和反向代理,专为优化运行 llama.cpp 的服务器而设计。
为什么选择 Paddler
对于 llama.cpp 服务器来说,轮询和最少连接等典型的负载均衡策略是无效的,因为这些服务器使用连续批处理算法,并允许配置插槽以同时处理多个请求。
Paddler 的设计支持 llama.cpp 特有的功能,如插槽。它通过维护一个了解每个服务器可用插槽的有状态负载均衡器来工作,确保高效的请求分配。
[!注意] 简单来说,llama.cpp 中的"插槽"指的是服务器内预定义的内存片段,用于处理单个请求。当请求到来时,它会被分配到一个可用的插槽进行处理。这些插槽是可预测的,且高度可配置。
你可以在 llama.cpp 服务器 文档中了解更多信息。
主要特性
- 使用代理监控单个 llama.cpp 实例的健康状况。
- 支持动态添加或移除 llama.cpp 服务器,可与自动扩展工具集成。
- 缓冲请求,允许从零主机开始扩展。
- 集成 StatsD 协议,同时提供内置仪表板。
- AWS 集成。
Paddler 了解每个服务器的可用插槽,确保高效的请求("R")分配
工作原理
llama.cpp 实例需要在 Paddler 中注册。Paddler 的代理应与 llama.cpp 实例一起安装,以便向负载均衡器报告其健康状态。
每个代理重复以下序列:
sequenceDiagram
participant loadbalancer as Paddler 负载均衡器
participant agent as Paddler 代理
participant llamacpp as llama.cpp
agent->>llamacpp: 嘿,你还活着吗?
llamacpp-->>agent: 是的,这是我的健康状态
agent-->>loadbalancer: llama.cpp 仍在工作
loadbalancer->>llamacpp: 我有一个请求需要你处理
使用方法
安装
从发布页面下载适用于 Linux、Mac 或 Windows 的最新版本。
在 Linux 上,如果你希望 Paddler 在系统范围内可访问,请将下载的可执行文件重命名为 /usr/bin/paddler
(或 /usr/local/bin/paddler
)。
运行代理
下一步是运行 Paddler 的代理。代理将你的 llama.cpp 实例注册到 Paddler 并监控 llama.cpp 实例的健康状况。 它们应该安装在与运行 llama.cpp 的服务器相同的主机上。
代理需要几条信息:
external-*
告诉负载均衡器如何连接到 llama.cpp 实例local-*
告诉代理如何连接到 llama.cpp 实例management-*
告诉代理应向何处报告健康状态
运行以下命令启动 Paddler 的代理(部署时请将主机和端口替换为你自己的服务器地址):
./paddler agent \
--external-llamacpp-host 127.0.0.1 \
--external-llamacpp-port 8088 \
--local-llamacpp-host 127.0.0.1 \
--local-llamacpp-port 8088 \
--management-host 127.0.0.1 \
--management-port 8085
命名代理
[!注意] 自 v0.6.0 版本起可用
使用 --name
标志,你可以为每个代理分配一个自定义名称。此名称将显示在管理仪表板中,不用于其他目的。
运行负载均衡器
负载均衡器从代理收集数据并向外部世界暴露反向代理。
它需要两组标志:
management-*
告诉负载均衡器应在何处监听来自代理的更新reverseproxy-*
告诉外部主机如何访问负载均衡器
要启动负载均衡器,运行:
./paddler balancer \
--management-host 127.0.0.1 \
--management-port 8085 \
--reverseproxy-host 196.168.2.10 \
--reverseproxy-port 8080
代理中的 management-host
和 management-port
应与负载均衡器中的相同。
启用仪表板
你可以使用 --management-dashboard-enable=true
标志启用仪表板以查看代理的状态。
如果启用,可以在管理服务器地址的 /dashboard
路径下访问它。
特性亮点
聚合健康状态
Paddler 均衡器端点聚合了 llama.cpp
的 /health
端点,并报告可用和处理中插槽的总数。
缓冲请求(从零主机扩展)
[!注意] 自 v0.3.0 版本起可用
负载均衡器的缓冲请求允许你的基础设施从零主机开始扩展,提供了一个额外的指标(等待处理的请求)。
它还为你的基础设施提供了一些额外的时间来添加更多主机。例如,如果你的自动缩放器正在设置一个额外的服务器,将传入请求暂停 60 秒可能会给它一个机会被处理,即使在发出请求时可能没有可用的 llama.cpp 实例。
从零主机扩展特别适合低流量项目,因为它允许你削减基础设施成本——如果你当前不使用你的服务,你就不需要向云服务提供商支付任何费用。
https://github.com/distantmagic/paddler/assets/1286785/34b93e4c-0746-4eed-8be3-cd698e15cbf9
状态仪表板
尽管 Paddler 集成了 StatsD 协议,你仍可以使用内置仪表板预览集群状态。
StatsD 指标
[!注意] 自 v0.3.0 版本起可用
[!提示] 如果你保持自托管堆栈,可以使用带有 StatsD 导出器的 Prometheus 来处理传入的指标。
[!提示] 此功能也可与 AWS CloudWatch Agent 配合使用。
Paddler 支持以下 StatsD 指标:
paddler.requests_buffered
自上次报告以来缓冲的请求数(每次报告后重置)paddler.slots_idle
总空闲插槽数paddler.slots_processing
正在处理请求的总插槽数
所有这些内部都使用 gauge
。
需要使用以下标志启用 StatsD 指标:
./paddler balancer \
# .. 在此处放置所有其他标志 ...
--statsd-enable=true \
--statsd-host=127.0.0.1 \
--statsd-port=8125 \
--statsd-scheme=http
AWS 集成
[!注意] 自 v0.3.0 版本起可用
在 AWS EC2 上运行时,你可以用 aws:metadata:local-ipv4
替换 --local-llamacpp-host
。在这种情况下,Paddler 将使用 EC2 实例元数据 获取本地 IP 地址(从本地网络):
如果你想保持负载均衡器管理地址可预测,我建议使用 Route 53 创建一个始终指向你的负载均衡器的记录(例如 paddler_balancer.example.com
),最终看起来像这样:
./paddler agent \
--external-llamacpp-host aws:metadata:local-ipv4 \
--external-llamacpp-port 8088 \
--local-llamacpp-host 127.0.0.1 \
--local-llamacpp-port 8088 \
--management-host paddler_balancer.example.com \
--management-port 8085
教程
更新日志
v0.6.0
特性
v0.5.0
修复
- 由于并发问题,管理服务器在某些情况下崩溃
v0.4.0
感谢 @ScottMcNaught 帮助调试问题!:)
修复
- 现在可以正确平衡 OpenAI 兼容端点(
/v1/chat/completions
) - 在某些情况下,当底层
llama.cpp
实例在生成完成令牌时突然关闭,负载均衡器的反向代理会发生panic
- 在目标集合中添加了互斥锁,以提高内部插槽数据的完整性
v0.3.0
特性
- 当所有 llama.cpp 实例都忙时,请求可以排队
- 支持代理本地 IP 地址的 AWS 元数据
- 支持 StatsD 指标
v0.1.0
特性
为什么叫这个名字
最初我想使用 Raft 共识算法(因此叫 Paddler,因为它在 Raft 上划桨),但最终我放弃了这个想法。不过这个名字保留了下来。
后来,人们开始给我发《辛普森一家》中"那是一顿打"的片段,我就接受了这个名字。
社区
Discord: https://discord.gg/kysUzFqSCK