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

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

一、先说三个扎心的现状

过去一年，我接触了不少中小企业和团队，发现大家用大模型的方式惊人地一致：
现状一： 密钥在群里裸奔。**
某个员工注册了 DeepSeek 账号，把 API Key 发到工作群里，全组共用一个 Key。谁用超了不知道，谁泄露了说不清，月底账单一出来，互相猜是谁干的。
现状二： 数据在公网上"裸奔"。**
更隐蔽的风险是： 员工为了让工作更高效，直接把产品代码、客户合同、财务数据贴进各种公开网页版的对话框。数据出了域，你连它去了哪儿都不知道。等出了事，追溯无从谈起。
现状三： 接了一个模型，被一个模型绑架。**
团队写代码时用 Claude，做中文内容用 DeepSeek，跑本地部署用 Ollama------每个客户端一个地址、一个 Key、一套配置。想从 A 模型切到 B 模型，所有接入方都要改一遍；想统一统计各模型的用量，发现根本没有数据。
这三个问题的共同根源是： 大模型在企业内部缺一个"总闸门" 。
就像公司不会让每个员工自己拉一根电线、打一口井，大模型这种生产资源，也需要一个统一入口。

二、思路：不卖算力，只做"自用网关"

先划清边界： 这篇文章说的不是做对外业务、不是转售 API、更不是搭平台卖 token------那是另一条充满合规风险和红海竞争的路。
我们讨论的是一个更朴素、也更快落地的场景：

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

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

1. 统一出口：所有客户端只认一个内网地址，底层接哪家模型、换哪家模型，外面无感知

2. 按人发卡：每个员工/部门/应用一个独立 `sk-` 密钥，密钥绑定到各自该用的模型

3. 真实密钥不下发：上游厂商的 API Key 只存在网关里，员工手里永远是网关发的"内卡"

4. 用量可审计：谁调了多少次、烧了多少 token，按天/周/月一目了然

5. 随时断供：员工离职、密钥泄露，一键吊销或重置，秒级生效

6. 数据可选不出域：敏感业务接本地 Ollama / vLLM，网关照常管理

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

三、架构：一层很薄的"智能总闸"

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

css 复制代码

员工A的IDE ──┐                        ┌──▶ 本地 Ollama (qwen3)
员工B的脚本 ──┤   ┌──────────────┐     ├──▶ 本地 vLLM (deepseek-coder)
部门C的应用 ──┼──▶│  llm-proxy-tk │─────┼──▶ DeepSeek 云端 API
网页版对话  ──┤   │  统一 /v1/*   │     └──▶ Claude / 其它 OpenAI 兼容上游
            ──┘   └──────────────┘
              每人一把 sk- 密钥，按密钥路由、鉴权、计量

Auto
代码解读复制代码

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

arduino 复制代码

curl http://gateway.你的内网:9000/v1/chat/completions \
  -H "Authorization: Bearer sk-张三的密钥" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "deepseek-chat",
    "messages": [{"role": "user", "content": "帮我总结这份合同"}],
    "stream": true
  }'

Bash
代码解读复制代码

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

四、六个落地场景，讲透它能干什么

场景 1：密钥管理------从"群里裸奔"到"按人发卡"

在管理后台给每个员工、每个应用发放独立密钥，可以设置过期时间（比如外包人员给三个月）：
密钥未绑定上游时走默认上游，绑定了就固定路由到指定模型
列表里只显示 sk-ab12** 脱敏前缀，明文只在创建时回显一次
密钥泄露/丢失？点一下"重置" ：立即换发新钥，旧值即刻失效，名字、绑定关系、历史统计原封不动------相当于换了锁芯没换门

场景 2：多模型并存------告别供应商绑架

"上游管理"里可以同时配置任意多个模型服务： 本地 Ollama、本地 vLLM、DeepSeek 云端、智谱、任何 OpenAI 兼容端点。
每个上游标注协议类型（OpenAI / Anthropic）和可用模型清单。网关会自动做双方言翻译：OpenAI 客户端的请求可以打到 Anthropic 协议的上游，流式 SSE 照样翻。这意味着团队里的老代码一行不改，就能从 A 模型迁到 B 模型------迁移的成本，从"改 N 个客户端"变成"改 1 个后台配置"。

场景 3：用量审计------每个 token 都有账

这是我最推荐企业关注的能力。网关自动解析每次调用的 usage 并落库，统计页提供：
日 / 周 / 月三种粒度的调用量与 token 趋势
密钥 × 周期矩阵：一眼看出哪个部门这个月烧了多少钱
输入 / 输出 token 分开统计，缓存命中 token 单独一列------对用了提示词缓存的团队，这就是省钱报表
每个密钥的请求次数、最后使用时间
月底老板问"AI 这块花了多少、谁在用、用得值不值"，导出数据就能回答。

场景 4：数据不出域------敏感业务的底线

财务、法务、核心代码这类数据，接公开 API 终究心里不踏实。把 Ollama 或 vLLM 部署在内网 GPU 机器上，作为网关的一个上游：
员工用同一把密钥、同一个地址，无感切换到本地模型
数据全程不出公司网络
用量统计照常工作，本地模型烧的是电费，也照样记 token------方便评估"这个场景值不值得上一张卡"

场景 5：内置对话页------顺手解决"网页版裸奔"

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

场景 6：权限分级------不是人人都是管理员

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

五、部署有多简单？

一页纸说完。

Docker 方式： **