Show HN: LLMhop – 一个专为大型语言模型设计的微型无状态路由器，附带 NixOS 模块
一句话看懂：LLMhop 是一个用纯 Go 编写的无状态 HTTP 路由器，它能够根据请求中的模型名称，将请求透明地分发到不同的 OpenAI 兼容推理后端。该项目同时提供了开箱即用的 NixOS 模块，可帮助用户在自托管环境中，将多个单模型推理服务整合到一个统一的 API 端点下。
事件核心：发生了什么
开发者 Mirkolenz 在 GitHub 上发布了 LLMhop，其核心功能是作为一个“模型感知”的轻量级反向代理。当客户端发送一个包含 {"model": "..."} 字段的请求时，LLMhop 会解析这个字段，并根据配置文件将请求原封不动地转发到对应的后端服务上，对未知模型则返回 404。该项目特别针对 vLLM、sglang 这类通常一个进程仅服务一个模型的推理服务器设计，允许用户通过单个端口和统一的前端接口，管理后端的多个推理进程。LLMhop 以单一静态二进制文件分发，零外部依赖，并提供了可选的 bearer token 认证和 token 注入能力，避免客户端令牌泄露至上游服务。其 NixOS 模块不仅包含一个经过安全加固的 systemd 服务，还能自动配置和拉起 llama.cpp、sglang 或 vLLM 的多个 worker 实例。
为什么重要
随着大模型应用走向工程化，自建推理集群的需求日益增长。目前主流的推理框架如 vLLM 和 sglang 每个进程往往只承载一个模型，当集群需要支持多个模型时，就需要一个模型路由层来统一入口。LLMhop 的意义在于以极小的额外开销（无状态、无需数据库）解决了这个“最后一公里”的资源调度问题。它的出现降低了小型团队或个人开发者搭建多模型推理网关的门槛，尤其适合需要同时维护多个自托管模型，例如一个开源模型用于特定任务，另一个用于通用对话的场景。它直接将自托管推理架构从天真的“一个模型开一个端口”升级到了“一个端口，任意模型”的专业形态。
对用户/开发者/创作者的影响
对于需要自托管推理服务的开发者而言，LLMhop 提供了一个比 nginx 更对口、比 Kong 或 Traefik 更轻量的替代方案。具体影响体现在三个方面：第一，运维简化。NixOS 用户可以通过声明式配置，一键部署包含路由器与多个推理后端（如 llama.cpp、sglang、vLLM）的完整推理集群，并且每个后端进程都受到独立的安全沙箱保护。第二，集成兼容性。由于它兼容 OpenAI 的 API 格式，任何使用 OpenAI 客户端的现有应用，如 Chatbox、Open WebUI 或基于 LangChain 的代码，都可以直接通过 LLMhop 切换到自托管模型，只需修改 base URL 和模型名。第三，成本控制。对于 API 成本敏感的创作者，可以通过 LLMhop 将部分高成本请求（如追求速度的使用 OpenAI GPT-4o）和低成本请求（如通用任务使用本地 Llama）混合路由，实现对推理成本的精细化管理。
AI 工具推荐
想把多个 AI 模型放在一个入口？
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。
推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。
值得关注的后续
首先，LLMhop 对请求体有 100MB 的默认上限，对于需要处理大规模图片或视频的多模态模型，实际吞吐表现有待社区验证。其次，NixOS 模块中 sglang 和 vLLM 通过 Podman 容器运行，这意味着需要调用者具备 NixOS 和 Podman 的基本运维能力，这将成为其扩大用户群的一道门槛。最后，LLMhop 的生态扩展值得观察——如果它能发展出动态模型热加载、基于负载的路由策略或对非 OpenAI 格式后端（如 Anthropic 的 Messages API）的适配，将可能从一个工具演进为自托管推理网关的事实标准。
来源：github.com
