企业内网怎么调用大模型 API？踩了一周坑，总结 4 种方案

与虾牵手
6 阅读1分钟

上周安全部门下了道令：所有大模型 API 调用必须走内网，开发机不允许直连外部服务。我这一周把几种方案都试了个遍，踩坑无数，这篇把真实经历和最终选择都写出来。

核心思路就三条路：自建代理网关转发、部署私有化模型、用支持内网白名单的 API 聚合平台做统一出口。具体选哪种，取决于安全合规要求、预算和运维能力。

为什么企业内网调大模型这么麻烦

先说背景。我们是 50 人左右的技术团队，内部有几个项目在用 Claude Opus 4.6 做代码审查、用 GPT-5 做文档摘要。之前开发同学各自拿 Key 直连，安全部门一直睁一只眼闭一只眼。

直到上个月出了事——有人把内部代码片段通过 API 发出去了，安全审计查出来，直接炸锅。于是就有了「所有 API 调用必须走内网统一出口」的需求。

企业内网环境的典型痛点：

  • 开发机不能直连外网，必须走代理或网关
  • 所有请求需要可审计、可溯源
  • 敏感数据不能明文外传，需要脱敏或加密
  • 团队用好几家的模型，Key 散落各处，管理混乱
  • 没有统一管理，月底账单吓人
graph TD
 A[开发者内网机器] -->|❌ 直连外网被禁| B[OpenAI / Anthropic API]
 A -->|✅ 走内网网关| C[统一 API 网关]
 C --> D{路由策略}
 D -->|审计 + 脱敏| E[外部 API 服务]
 D -->|敏感任务| F[私有化部署模型]
 C --> G[日志审计系统]

方案一：Nginx 反向代理（最简单，但坑最多）

第一个想到的方案，也是踩坑最狠的。

思路很简单：在内网搞一台能出外网的服务器，装个 Nginx 做反向代理，开发机的请求打到这台机器，Nginx 转发到 OpenAI/Anthropic。

# /etc/nginx/conf.d/llm-proxy.conf
server {
 listen 8443 ssl;
 server_name llm-gateway.internal.company.com;

 ssl_certificate /etc/nginx/ssl/internal.crt;
 ssl_certificate_key /etc/nginx/ssl/internal.key;

 # 转发 OpenAI 兼容接口
 location /v1/ {
 proxy_pass https://api.openai.com/v1/;
 proxy_set_header Host api.openai.com;
 proxy_set_header Authorization $http_authorization;
 proxy_ssl_server_name on;
 
 # 审计日志
 access_log /var/log/nginx/llm-audit.log detailed;
 
 # 超时设置（大模型响应慢，别用默认60s）
 proxy_read_timeout 300s;
 proxy_connect_timeout 30s;
 }
}

开发侧改一下 base_url 就行：

from openai import OpenAI

client = OpenAI(
 api_key="sk-xxx",
 base_url="https://llm-gateway.internal.company.com:8443/v1"
)

response = client.chat.completions.create(
 model="gpt-4o",
 messages=[{"role": "user", "content": "hello"}]
)

这个方案我折腾了两天才跑通，坑比想象的多：

  1. Streaming 断流：Nginx 默认会 buffer 响应，SSE 流式输出直接卡住。必须加 proxy_buffering off; 和 chunked_transfer_encoding on;
  2. SNI 问题：转发 HTTPS 请求时，不加 proxy_ssl_server_name on 会被目标服务器拒绝
  3. 多模型多后端：想同时代理 OpenAI 和 Anthropic，得写一堆 location 规则，Anthropic 的接口路径还跟 OpenAI 不一样，维护成本直线上升
  4. Key 管理：每个开发者还是要自己管 Key，安全部门不满意

临时应急用用还行，长期维护太糙了。

方案二：自建 API 网关（One API / New API）

社区里比较流行的方案，用开源项目搭一个 API 管理网关。

# 用 Docker 一键部署 One API
docker run -d \
 --name one-api \
 -p 3000:3000 \
 -e SQL_DSN="root:password@tcp(mysql:3306)/oneapi" \
 -e SESSION_SECRET="your-secret" \
 --restart always \
 justsong/one-api

部署完在后台配置各家模型的 Key，然后给每个开发者发一个内部 Token，统一走网关。

优点是有统一 Key 管理、用量统计、配额管理，多模型路由也支持。

但实际用下来：

  • 运维成本不低，MySQL + Redis + 网关本身，内网还得搞高可用
  • 版本更新频繁，某次升级直接把我的渠道配置搞丢了
  • 遇到新模型（比如最近的 GLM-4.7），得等社区适配
  • 安全审计功能比较基础，满足不了我司安全部门的要求

如果团队有专人运维，这个方案其实还行。但我们团队就我一个半运维（另外半个是 ChatGPT），实在扛不住。

方案三：私有化部署（成本劝退，特定场景刚需）

安全部门最喜欢的方案——数据完全不出内网。

用 vLLM 部署一个开源模型：

# 部署 DeepSeek V3（需要多卡，量力而行）
python -m vllm.entrypoints.openai.api_server \
 --model deepseek-ai/DeepSeek-V3 \
 --tensor-parallel-size 4 \
 --port 8000 \
 --api-key internal-key-123

代码调用跟之前一模一样，改个地址就行：

client = OpenAI(
 api_key="internal-key-123",
 base_url="http://llm-server.internal:8000/v1"
)

我拿 DeepSeek V3 测了一下，4 张 A100 才能跑起来，推理速度大概是 API 服务的 60%-70%。关键是我司没有 A100。

申请 GPU 服务器走了两周流程，最后批下来 2 张 A800。跑了个 Qwen 3-7B，效果跟 GPT-5 差距明显，业务方不买账。

私有化部署适合数据极度敏感（金融、医疗、军工）且预算充足的场景。普通企业用不起，也没必要。

方案四：用聚合平台做统一出口（我的最终选择）

折腾了一圈，发现最适合我们团队的是：找一个支持固定 IP 白名单的 API 聚合平台，内网防火墙只放行这个平台的 IP，所有请求走统一出口。

我最后用的是 ofox.ai，一个 AI 模型聚合平台，一个 API Key 可以调用 GPT-5、Claude Opus 4.6、Gemini 3、DeepSeek V3、GLM-4.7 等 50+ 模型，低延迟直连无需代理，支持支付宝付款，按量计费。

架构变成了这样：

graph LR
 A[内网开发机] -->|内部网络| B[内网 Nginx 代理]
 B -->|防火墙白名单放行| C[ofox.ai 聚合网关]
 C --> D[GPT-5]
 C --> E[Claude Opus 4.6]
 C --> F[DeepSeek V3]
 C --> G[GLM-4.7]
 B --> H[审计日志]

实际代码就改一个 base_url：

from openai import OpenAI

client = OpenAI(
 api_key="your-ofox-key",
 base_url="https://api.ofox.ai/v1"
)

# 想用哪个模型直接切 model 参数就行
response = client.chat.completions.create(
 model="claude-sonnet-4-20250514",
 messages=[
 {"role": "user", "content": "帮我审查这段代码的安全风险"}
 ],
 stream=True
)

for chunk in response:
 if chunk.choices[0].delta.content:
 print(chunk.choices[0].delta.content, end="")

几个关键问题都解决了：

  • 防火墙只需放行一个出口 IP，安全部门签字了
  • 一个 Key 搞定所有模型，不用管各家的鉴权差异
  • Nginx 代理层记录所有请求日志，配合 ELK 做审计
  • 按量计费，后台能看到每个模型的用量

四种方案怎么选

方案部署难度运维成本安全等级多模型支持适用团队
Nginx 反向代理⭐ 低⭐⭐ 中⭐⭐ 中❌ 手动配临时应急
自建 API 网关⭐⭐⭐ 高⭐⭐⭐ 高⭐⭐⭐ 高✅ 好有运维团队
私有化部署⭐⭐⭐⭐ 极高⭐⭐⭐⭐ 极高⭐⭐⭐⭐⭐ 最高❌ 仅开源模型数据极敏感+有GPU
聚合平台+白名单⭐ 低⭐ 低⭐⭐⭐ 高✅ 最好大多数团队

最终落地

我们用的是「方案四 + Nginx 审计层」的组合。内网 Nginx 负责请求审计和敏感词过滤（用 lua-resty 写了个简单的脱敏模块），出口走聚合平台。

上线两周，安全部门没再找我麻烦，开发同学也没抱怨体验变差。唯一遗憾是方案三没跑起来——等哪天预算够了，核心的代码审查任务还是想迁到私有化模型上。

说句掏心窝的话：企业内网调大模型，技术上不难，难的是在安全合规、成本和开发体验之间找平衡。别一上来就想搞最完美的方案，先跑起来，再慢慢迭代。

avatar
文章
阅读
粉丝