企业接入大模型，最难的往往不是调用 API，而是建立秩序：谁在用、用了多少、数据去了哪里、预算是否失控，以及某个密钥泄露后能不能立刻止损。
一个可落地的开源思路，是在企业内网部署一层轻量 API 网关，例如 llm-proxy-tk 这类项目。员工和内部应用只访问网关，由网关统一管理模型密钥、用户令牌、用量统计和访问权限。大模型因此更像公司内部的水电服务：统一接入，按人发卡，用量可见，需要时可以断供。
三个令人头疼的现状
密钥散落在群聊和代码里
最常见的做法是管理员申请一个模型 API Key，然后发到工作群、项目文档或私聊中。接下来通常会发生几件事：
- 密钥被复制到个人脚本和 IDE 插件里；
- 离职人员仍然可能保留访问权限；
- 一个项目泄露密钥，所有使用者都要一起换 Key；
- 管理员无法准确判断每个人的调用量和成本。
这不是员工故意绕过管理，而是系统没有提供足够顺手的正规入口。没有内部服务时，员工自然会寻找最快的办法。
账单只有总数，没有责任边界
模型平台通常能看到组织或密钥级别的消耗，但企业真正想知道的是：哪个团队花得最多，哪个账号突然出现异常增长，哪些模型值得保留，哪些调用应该设置上限。
如果所有人共用一个 Key，账单只能告诉你“公司用了多少钱”，却无法帮助你回答“是谁用了这些钱”。
一刀切封禁解决不了问题
直接封禁外部 AI 网站看似简单，却可能把需求赶到更隐蔽的渠道。员工仍然需要写代码、整理会议纪要、分析文档和生成测试数据，需求不会因为网络策略消失。
更稳妥的做法，是提供一个可审计、可限额、可撤销的内部入口。管理者获得控制力，员工也不用反复申请共享密钥。
网关应该承担什么职责
内网网关不需要一开始就变成复杂的平台。它的价值主要集中在几个边界上。
统一入口
内部脚本、业务服务和员工工具都访问同一个内网地址，例如：
http://llm-gateway.intra/v1/chat/completions
网关再根据配置把请求转发给实际的模型服务。这样，后端模型供应商发生变化时，调用方不必批量修改代码。
按人或按团队发放令牌
管理员不再共享供应商的真实密钥，而是给员工或应用发放独立的内部 Token。每个 Token 都可以关联到用户、部门、项目或服务账号。
令牌至少应该支持以下操作：
- 创建和吊销；
- 设置有效期；
- 设置模型访问范围；
- 设置调用次数或费用上限；
- 查看最近使用记录。
记录用量，但谨慎处理提示词
用量统计可以从请求次数、输入 Token、输出 Token、模型名称和时间等维度开始。至于完整提示词和模型回复，是否记录要根据企业的数据分级和合规要求决定。
日志越详细，排查问题越方便；但日志也可能成为新的敏感数据仓库。默认情况下，可以优先保存元数据，只有经过授权的场景才保留内容摘要或完整请求。
随时断供
当令牌泄露、项目结束或预算异常时，管理员需要能够快速撤销单个 Token，而不是更换整个组织的供应商密钥。
这项能力看起来简单，却是共享 Key 方案最缺失的控制点。
一个可以这样实践的最小方案
下面的示例假设网关提供兼容 OpenAI 风格的接口，并且用环境变量配置网关地址和内部 Token。具体路径、认证头和参数名称需要根据 llm-proxy-tk 的实际部署文档调整。
先准备环境变量：
export LLM_GATEWAY_URL='http://llm-gateway.intra/v1/chat/completions'
export LLM_GATEWAY_TOKEN='replace-with-user-token'
然后用 curl 发起一次请求：
curl --fail-with-body --silent --show-error \
-X POST "$LLM_GATEWAY_URL" \
-H 'Content-Type: application/json' \
-H "Authorization: Bearer $LLM_GATEWAY_TOKEN" \
-d '{
"model": "internal-default",
"messages": [
{
"role": "user",
"content": "请把下面的故障描述整理成三条排查建议：服务在发布后出现间歇性 502。"
}
],
"temperature": 0.2
}'
调用方只知道内网地址和自己的 Token，不需要接触供应商的真实密钥。网关可以根据 internal-default 映射到企业批准的模型，也可以在后端切换供应商。
如果团队使用 Python，可以把网关地址做成配置，而不是写死在代码中：
import os
from openai import OpenAI
client = OpenAI(
base_url=os.environ['LLM_GATEWAY_BASE_URL'],
api_key=os.environ['LLM_GATEWAY_TOKEN'],
)
response = client.chat.completions.create(
model=os.getenv('LLM_MODEL', 'internal-default'),
messages=[
{'role': 'user', 'content': '给这段 Python 函数补充边界条件测试。'}
],
temperature=0.2,
)
print(response.choices[0].message.content)
运行前安装 SDK，并配置变量：
python -m pip install openai
export LLM_GATEWAY_BASE_URL='http://llm-gateway.intra/v1'
export LLM_GATEWAY_TOKEN='replace-with-user-token'
python app.py
这个示例的关键不是 SDK，而是 base_url。业务代码依赖的是企业网关协议，供应商密钥和后端路由留在网关侧管理。
上线时要守住的边界
不要把网关直接暴露到公网
网关的第一层保护应该是网络边界：只允许办公网、VPN 或指定服务网段访问。公网访问如果确有必要，也应经过统一身份认证、TLS、限流和审计，而不是简单转发一个模型接口。
Token 不等于完整身份治理
内部 Token 适合快速建立访问边界，但它不能替代企业身份系统。更成熟的部署可以把令牌申请、员工身份、部门归属和离职回收接入现有的 SSO 或 IAM 流程。
额度要分层设置
可以为个人、团队和服务账号设置不同的预算策略。例如：
- 普通员工：较低的每日请求或费用额度；
- 研发团队：允许使用更多模型，但保留月度预算；
- 生产服务：使用独立账号，设置告警和更严格的模型白名单；
- 管理员：可以查看全局用量，但不应默认读取所有提示词内容。
用量告警要早于预算耗尽
至少设置两个阈值：例如达到月度额度的 70% 时提醒，达到 90% 时限制高成本模型。突发增长也应该触发告警，例如某个 Token 在短时间内出现远高于历史平均值的调用量。
明确哪些数据禁止发送
网关能控制入口，但不能自动判断所有业务数据是否适合发送给外部模型。企业仍需要明确规则：客户隐私、生产密钥、未脱敏的合同、源代码和内部凭证是否允许进入模型服务。
可以在网关前后增加敏感信息检测和脱敏流程，但这类能力需要结合实际数据测试，不能把简单的关键词过滤当成完整的数据安全方案。
从共享 Key 迁移到内部服务
迁移不必一次完成。一个实际可执行的顺序是：
- 盘点当前使用的模型、脚本、插件和供应商密钥；
- 在内网部署网关，并先接入一个低风险模型；
- 为试点团队创建独立 Token，记录请求次数和 Token 用量；
- 把内部示例代码和常用工具统一改成访问网关；
- 吊销群聊中流传的共享 Key，并设置供应商侧预算上限；
- 根据真实用量调整模型白名单、额度和告警规则；
- 再把更多团队和业务服务迁移进来。
这个过程的重点是让合规入口足够好用。员工不需要知道后端有多少供应商，也不需要为每个项目重新学习一套调用方式。
结语：把模型接入变成一项内部基础服务
大模型治理的核心不是禁止使用，而是把使用方式从个人行为变成组织服务。内网网关提供了一条清晰的控制线：统一入口、独立凭证、可见用量、可控预算和快速撤销。
llm-proxy-tk 这类轻量开源方案适合从小范围试点开始，但上线前仍要验证认证方式、日志策略、模型路由、限流机制和故障处理能力。它可以解决密钥分发和基础审计问题，却不能独自解决数据分类、身份治理或模型输出风险。
可以用下面这份清单判断是否具备推广条件：
- 员工和内部应用是否只需要访问一个稳定的内网地址；
- 每个用户或应用是否拥有独立、可撤销的 Token；
- 管理员是否能看到按用户和团队拆分的用量；
- 是否有高成本调用和异常流量告警；
- 是否限制了可用模型和外部网络范围；
- 是否明确了敏感数据处理规则；
- 网关不可用时，关键业务是否有降级方案。
当这些问题都有明确答案，大模型才真正从一串散落的私人密钥，变成可管理、可计量的企业基础设施。