自托管用户的本地 LLM API 网关

自托管开源工具的用户（如 AppFlowy、Flowise 的自部署用户）想用本地或私有的 LLM，但很多应用的 OpenAI 端点被硬编码为 api.openai.com。信号中的原话："This prevents usage over proxies where the normal site may be blocked, or usage with compatible apis such as azure's openai or localai"。用户被迫提交 feature request 等官方适配，或在代理/兼容 API（Azure OpenAI、LocalAI）之间反复受阻。痛点真实但程度中等（pain 均为 3），且集中在少数开源项目的 issue 区。

自托管开源生产力工具（笔记、工作流自动化类）的重度用户，已在本机跑 LM Studio / LocalAI 等本地模型、重视数据隐私或受网络限制无法直连 OpenAI 的开发者与极客。市场规模小：信号仅来自两个开源项目的 issue 区，互动量低（score 15-25），属利基需求。

• 本地 OpenAI 兼容网关：在本机运行一个监听 443/自定义端口的反向代理，完整实现 OpenAI API 规范的请求/响应格式。
• 透明改道：对端点硬编码的应用，通过 hosts 劫持 + 自签证书（或环境变量）把 api.openai.com 的流量转到本地网关，应用无感知。
• 多上游路由：网关后端可配置 LocalAI、LM Studio、Azure OpenAI 等任意 OpenAI 兼容服务，按模型名路由请求。
• 密钥与日志：统一管理上游密钥，提供本地请求日志便于调试。 AI 角色：本身不跑模型，而是充当 LLM 流量的路由与协议适配层。

OpenAI API 正成为事实标准：LocalAI、LM Studio 均主动兼容其规范，LangChain 已支持 local base path，信号显示 2023 年底起用户对本地/兼容端点的诉求集中出现——但生态拼图里缺一块"让端点写死的应用也能接入"的通用适配层。

做：本地起一个 OpenAI 兼容的反向代理服务；配置上游为 LocalAI / LM Studio / Azure OpenAI 等兼容端点；提供把请求从 api.openai.com 透明改道到本机网关的接入指引（hosts + 证书，或应用内可配置 base URL 时的直接填入）；简单的请求日志与模型路由规则。不做：模型下载与管理、微调、应用内插件、移动端、团队协作功能。

• 需求侧最脆弱：三条信号全是免费功能请求，AppFlowy / Flowise 官方一旦实现自定义 base URL（AppFlowy 已有相关 issue 在推进），第三方方案的存在理由即消失。
• 付费意愿不明：目标用户是自托管开源用户，天然偏好免费方案，独立收费产品很难切入。
• 技术风险：对硬编码端点的应用需要 TLS 拦截或系统级重定向，安装门槛高、易出兼容性问题。
• 生态依赖：上游（LocalAI、LM Studio、Azure OpenAI）的 API 兼容性变化会直接影响产品可用性。