mostlygeek/llama-swap

如果你在同一台机器上跑多个本地模型，又厌倦了手动管理端口、启动脚本和各种客户端配置，llama-swap 值得一试。它由一个 Go 二进制加一份 YAML 配置组成，只监听一个地址，根据请求里的模型名找到对应后端进程，需要时才启动它。

解决什么问题

在一块 GPU 上，开发者可能想同时用聊天模型、嵌入模型，偶尔还要跑图像或语音模型，并且希望同一个客户端都能调用。按常规做法，每个后端都要手动启动在独立端口上，客户端要按模型改配置，空闲进程还可能一直占着下一个模型需要的显存。llama-swap 把这一步换掉：客户端始终面向一个 OpenAI 或 Anthropic 风格的端点，代理按模型名匹配配置中的启动命令，拉起进程后转发响应。最终得到的是一个稳定地址，背后挂着多个模型，切换由代理完成，客户端不用感知。

有什么不同

llama-swap 不内置推理引擎，而是把每个模型当成配置里的一条命令。因此它对后端保持中立：README 列出了 llama.cpp 及其分支、vLLM、stable-diffusion.cpp、audio.cpp、ComfyUI、whisper.cpp，并声明可对接任何 OpenAI/Anthropic 兼容服务。升级或替换推理服务时，不需要改动这一层路由配置。

代理暴露的端点也不止聊天：包括 completions、responses、embeddings、语音合成与转写、图像生成与编辑、Anthropic messages 和 token 计数，以及 llama.cpp 的 rerank、infill 等路由。实时 Web UI 提供 playground、token 指标和请求/响应查看，还能手动加载、卸载模型（README）。主要代价在配置：价值取决于每条模型的启动命令写得是否准确，而且它本质上是进程管理器，不是模型管理器，多出来的进程层对纯文本客户端不可见。

谁值得试

适合只有一块 GPU、但希望一个本地端点服务多个模型和多个工具的人：编辑器插件、脚本和聊天客户端都指向同一主机，按模型名切换即可。如果只固定运行一个模型、从不切换，代理只会多一跳和一份配置文件，收益有限。Docker 用户有明确路径：统一镜像打包了 llama-server、ik-llama-server、stable-diffusion.cpp、whisper.cpp 和 audio.cpp，分 CUDA 12、CUDA 13 和 Vulkan 版本（容器镜像）；旧版镜像跟随 llama.cpp 自己的 server 容器，但没有图像、语音和 ik-llama-server 支持（旧版基础镜像）。非容器环境可用 Homebrew、MacPorts、WinGet 或发布二进制，其中 MacPorts 和 WinGet 由社区维护，并非项目官方组成部分（WinGet issue）。

使用条件与边界

核心前提是有本地推理硬件，以及至少一个配置能启动的后端服务；llama-swap 本身不提供模型权重或推理引擎。按需切换意味着某个模型的第一次请求要承担启动时间；在常见配置下，有限的显存同时只能容纳一个模型。统一 Docker 镜像按 GPU 区分：CUDA 13 覆盖 Ampere 到 Blackwell，CUDA 12 面向被 CUDA 13 放弃的旧卡，Vulkan 面向 AMD 等支持 Vulkan 的 GPU，所以镜像和硬件要对上（README）。

日常维护主要是改配置：新增模型或调整启动参数都要编辑模型列表；后端升级由你负责，项目有意不锁定引擎。README 也注明了一些端点限制，例如 /props 必须带 ?model= 查询参数，且会忽略 autoload。

HotRepo 点评

仓库创建于 2024-10-04，HotRepo 唯一记录的榜单观测是 2026-10-25：当日进入每日 Trending 榜，6,073 stars，当天 +12。仅凭这一次快照，无法判断热度能否持续。采用前建议先看与你后端对应的配置示例：项目的价值取决于你的服务启动命令能否被清晰表达，以及预加载行为是否符合你的工作流程。