Opod：为自有 GPU 提供统一 OpenAI 兼容端点的自托管 AI 网关

opod-io/opod-core · Self-hosted AI gateway for the GPUs you already own: one OpenAI-compatible endpoint across many machines. Engine-agnostic (Ollama, vLLM, SGLang, llama.cpp, MLX-LM), load-aware routing, one model sharded across nodes, API keys, Prometheus + OpenTelemetry. Go, Apache-2.0, no telemetry.

GitHub原文发布未知首次收录 2026-10-13上架 2026-10-13 07:02

☆ 收藏查看项目 ↗

ELI5：它是什么，解决什么问题

Opod 是一个用 Go 编写的自托管 AI 推理网关，将多台自有机器上的开源权重模型聚合为单一的 OpenAI 兼容端点（/v1/chat/completions 与 /v1/embeddings）。它不绑定推理引擎，可对接 Ollama、vLLM、SGLang、MLX-LM、llama.cpp，提供负载感知路由、跨节点分片大模型、API Key 与 join token、Prometheus 与 OpenTelemetry 观测能力，核心无厂商外发流量，仅以 CLI 和 HTTP API 形式提供，无内置 UI。

# self-hosted # OpenAI API # llm-gateway # local-inference # model-serving

核心能力与快速开始

★ 2 · Go

能做什么: 提供 OpenAI 兼容的 /v1/chat/completions 与 /v1/embeddings 网关接口；引擎无关地对接 Ollama、vLLM、SGLang、MLX-LM、llama.cpp；负载感知路由（同一模型多节点负载均衡、按放置路由不同模型）；跨节点分片超大模型（llama.cpp RPC、vLLM + Ray、SGLang 启动器）；引擎错误或超时按目录回退链重试；API Key 身份、作用域与过期、join token 与按 key 用量事件流；Prometheus 与 OpenTelemetry 可观测性；内置 47 个精选目录模型及任意 HuggingFace / Ollama 模型；多机异构硬件（Apple Silicon、NVIDIA、AMD）统一纳管。
适用场景: 团队在自有 GPU 或 Apple Silicon 机器上运行开源权重模型（Qwen、Llama、DeepSeek 等），通过一个 URL 与一个 API Key 向 Cursor、Aider、Continue、Codex CLI 或任意 OpenAI SDK 提供推理服务；将超出单机显存的大模型分片到多台机器；在局域网或自建 VPN 内让请求不出内网；为团队成员按人分配带作用域和有效期的 API Key 并追踪用量；把自托管模型接入现有 CI、脚本与 SSH 工作流。
项目形态: 可直接使用的工具
部署方式: 自托管。单静态 Go 二进制，支持 macOS（Apple Silicon）与 Linux（x86_64、arm64），提供 .deb / .rpm 包与 install.sh 安装脚本，目录数据内嵌于二进制；多节点通过 leader 与 join token 以明文 HTTP 在局域网或自建 VPN 内组网；核心无厂商外发流量。
主要依赖: 需要自行准备推理引擎（Ollama、vLLM、SGLang、MLX-LM 或 llama.cpp 之一）；worker 需能访问 leader 的 8080 端口；硬件推荐、显存与磁盘要求见 README 的硬件建议章节，具体数值材料未完整给出；未说明 API 成本信息。
使用限制: 核心为 CLI-only 推理运行时，不包含 UI 与控制台；产品化能力（控制台、邀请、厂商外发与云密钥池、路由链、回调与 sink、费用预算、用量/审计查询 API、护栏实现、自动更新检查）不在核心内，属于控制平面 opodcp；仅面向 OpenAI 协议线格式，其他协议需在网关前加 shim；无遥测；未说明模型授权与商用限制、并发上限与性能指标。
许可证: Apache-2.0
最近推送: 2026-10-12 20:12

官方入门项目文档核对 README 依据 ↗

资料检查：2026-10-13 07:00 · 卡片整理：2026-10-13 07:00
卡片由 AI 根据仓库资料整理，未进行安装或运行验证

职业应用

程序员

将 Cursor、Aider、Continue、Codex CLI 或任意 OpenAI SDK 指向自托管的 Opod 端点，让这些编码工具使用自有 GPU 上的开源权重模型（如 Qwen、Llama、DeepSeek）完成代码编写与辅助，避免把专有代码发送给第三方 API。

查看内容依据

Point Cursor, Aider, Continue, Codex CLI, or any OpenAI SDK at Opod. It just works.

官方使用入口 ↗

由 AI 根据来源材料整理，未进行安装或运行验证

相似资源

hearth：为本地推理服务器提供队列调度与容量共享的 OpenAI 兼容接入层

hearth 是一个位于本地推理服务器前面的接入与调度层，用于解决单张 GPU 同时只能承载一个模型、多个请求争抢不同模型导致反复换权重的问题。它对外提供 OpenAI 兼容的 /v1/chat/completions 与 /v1/models 接口（含流式），客户端只需把地址指向它即可。核心能力包括带优先级、老化防饿死、按调用方限额并优先复用已加载模型的队列；可选的路由规则、控制台 /ui、调用方 API Key 与用量统计、多后端（多服务器、多显卡、局域网内其他机器、非 OpenAI 协议后端）、云端 provider 后端、模型可用性金丝雀探测，以及在可信节点之间出借/借用闲置算力。

ScreenMind：本地化屏幕记忆与检索对话工具

ScreenMind 是一款 AI 驱动的屏幕记忆应用，通过内容变化检测捕获屏幕截图，使用 Gemma 4 多模态模型在本地完成视觉分析、语音转写与推理，构建语义与关键词混合检索的可搜索历史记录，并支持基于屏幕记忆的对话问答、会议转写总结、Agent 自动化、MCP 集成与数据分析面板。项目强调全部数据与推理留在本机、无遥测、提供敏感信息过滤与静态加密等隐私措施。

Syntropic137：面向 Claude Code 与 Codex 的自托管多智能体工作流编排平台

Syntropic137 是一个自托管的智能体工程平台，用于把 Claude Code 和 Codex 组织成可重复的工作流：每个阶段可独立选择 harness 与模型，在隔离的 Docker 工作区中执行，并将每次工具调用、token、成本、对话与产物永久写入可查询的事件存储。它提供 GitHub 原生触发（自愈 CI、PR 驱动流程、评论自动响应）、工作流市场、阶段间产物流水线与跨模型委派，并支持通过 CLI（syn）管理、运行和观察执行。

KMJ CodeBridge：通过 MCP 插件将 ChatGPT 等客户端安全接入授权开发机与 VPS

KMJ CodeBridge 是一个基于 MCP 协议的桥接工具，把 ChatGPT、Claude 及兼容 MCP 客户端连接到经管理员授权的电脑和 VPS 项目上，用于受限范围内的代码阅读、编辑、Git 操作以及经过校验的构建与测试。它采用网关加设备代理的架构：网关负责认证、策略与任务状态，设备代理只发起出站连接，工作范围限定在管理员批准的项目根目录内，写操作有哈希与前置条件校验，质量门禁只能运行管理员配置的命令，不暴露通用远程 shell。项目主打本地 LLM 优先，通过回环地址上的 Ollama 使用已安装模型进行有界草稿生成，不会自动下载模型或回退到付费云端推理。项目处于活跃开发中的开发者预览阶段，采用 Apache-2.0 许可，需要 Node 24+。

这是基于来源内容整理的摘要。原文链接失效后，本页摘要和讨论仍会保留。