别再让员工偷偷用ChatGPT了：用一台内网网关，把大模型变成"自来水"

企业接入大模型，最难的不是技术，是秩序。本文分享一个开源思路： 在内网部署一层轻量API网关（llm-proxy-tk），让大模型像公司内部的水电一样——统一接入、按人发卡、用量可视、随时断供。

过去一年，我接触了不少中小企业和团队，发现大家用大模型的方式惊人地一致：

现状一： 密钥在群里裸奔。**

某个员工注册了DeepSeek账号，把API Key发到工作群里，全组共用一个Key。谁用超了不知道，谁泄露了说不清，月底账单一出来，互相猜是谁干的。

现状二： 数据在公网上"裸奔"。**

更隐蔽的风险是： 员工为了让工作更高效，直接把产品代码、客户合同、财务数据贴进各种公开网页版的对话框。数据出了域，你连它去了哪儿都不知道。等出了事，追溯无从谈起。

现状三： 接了一个模型，被一个模型绑架。**

团队写代码时用Claude，做中文内容用DeepSeek，跑本地部署用Ollama——每个客户端一个地址、一个Key、一套配置。想从A模型切到B模型，所有接入方都要改一遍；想统一统计各模型的用量，发现根本没有数据。

这三个问题的共同根源是： 大模型在企业内部缺一个"总闸门" 。

就像公司不会让每个员工自己拉一根电线、打一口井，大模型这种生产资源，也需要一个统一入口。

先划清边界： 这篇文章说的不是做对外业务、不是转售API、更不是搭平台卖token——那是另一条充满合规风险和红海竞争的路。

我们讨论的是一个更朴素、也更快落地的场景：

企业自建一层大模型API网关，只对自己人服务。

它要解决的问题清单很明确：

这就是llm-proxy-tk这个项目的定位——一个基于FastAPI的轻量大模型网关，SQLite存数据、Docker一键起，单文件部署，专门给"自用"场景设计。

整个系统一句话就能说清：

调用方拿到的是一个 标准OpenAI格式的接口 ：

对员工来说，体验和直接调官方API没有任何区别——改个base_url就接上了。所有的"秩序"，都发生在网关这一层。

在管理后台给每个员工、每个应用发放独立密钥，可以设置过期时间（比如外包人员给三个月）：

密钥未绑定上游时走默认上游，绑定了就固定路由到指定模型

列表里只显示sk-ab12** 脱敏前缀，明文只在创建时回显一次

密钥泄露/丢失？点一下"重置" ：立即换发新钥，旧值即刻失效，名字、绑定关系、历史统计原封不动——相当于换了锁芯没换门

"上游管理"里可以同时配置任意多个模型服务： 本地Ollama、本地vLLM、DeepSeek云端、智谱、任何OpenAI兼容端点。

每个上游标注协议类型（OpenAI/Anthropic）和可用模型清单。 网关会自动做双方言翻译 ：OpenAI客户端的请求可以打到Anthropic协议的上游，流式SSE照样翻。这意味着团队里的老代码一行不改，就能从A模型迁到B模型——迁移的成本，从"改N个客户端"变成"改1个后台配置"。

这是我最推荐企业关注的能力。网关自动解析每次调用的usage并落库，统计页提供：

日/周/月三种粒度 的调用量与token趋势

密钥 × 周期矩阵 ：一眼看出哪个部门这个月烧了多少钱

输入/输出token分开统计， 缓存命中token单独一列 ——对用了提示词缓存的团队，这就是省钱报表

每个密钥的请求次数、最后使用时间

月底老板问"AI这块花了多少、谁在用、用得值不值"，导出数据就能回答。

财务、法务、核心代码这类数据，接公开API终究心里不踏实。把Ollama或vLLM部署在内网GPU机器上，作为网关的一个上游：

员工用同一把密钥、同一个地址，无感切换到本地模型

用量统计照常工作，本地模型烧的是电费，也照样记token——方便评估"这个场景值不值得上一张卡"

管理后台自带一个聊天界面： 流式输出、Markdown渲染、代码高亮、多轮上下文。员工日常问答不需要再去外面的网页版—— 与其堵，不如给一个更顺手的 。管理员还能直接在对话页选择任意密钥、任意上游模型做调试，排查问题不用curl。

后台账号分 管理员/查看者 两种角色： 查看者能看统计、看密钥列表，但发卡、重置、改上游这些写操作只有管理员能做。审计和操作分离，权责清晰。

Docker方式：**

没有数据库要装（SQLite文件即数据），没有消息队列，没有K8s。一台普通的内网服务器，五分钟从零到可用。内网机器没有外网？项目还提供了离线部署包，pip依赖全部本地化，前端渲染库也全部vendor本地打包，断网环境照常跑。

实事求是，边界也要讲清楚：

它不做计费充值 ——没有余额、扣费、订单。内部成本核算用统计报表就够了，真要对外卖token是另一回事（也不建议做，那是红海）

它不做内容安全审核 ——违规内容过滤需要接专门的内容安全服务

它不是高可用集群 ——单实例+ SQLite，定位是中小团队的内网总闸，不是日均亿级调用的平台

一句话： 它是给"想管好自己人怎么用AI"的团队用的，不是给"想做AI生意"的人用的。

项目地址：github.com/boonya-hrgk/llm-proxy-tk（开源，仅供学习与内部使用）

如果这篇文章对你有帮助，欢迎点赞、在看、转发给正在为"密钥裸奔"头疼的朋友。