OpenCode 局域网内给团队共享 API Key 权限设置教程：4090 服务器搭建实录

Published on Jul 18, 2026 in ai

# ai

我们工作室买了台 4090 服务器，结果变成了"插队抢号"现场

事情是这样的。我和三个朋友合伙做外包，年初凑钱买了一台 4090 工作站，装了 OpenCode + Ollama + 几个商业 API Key。本意是大家一起用，结果是灾难现场：

A 同事忘了关调试模式，一晚上烧了 $30 的 API 额度
B 同事把自己的 API Key 写进代码里，传到 GitHub 上，10 分钟后收到 Anthropic 的封号邮件
C 同事同时开了 12 个并发请求，把 Ollama 的 24G 显存直接撑爆

（实测）三周后，我们蹲在服务器前把所有问题捋清楚，搭了一套完整的权限体系。从那以后零事故。这篇文章就是那次重构的记录。

这篇是本地部署大模型实战的进阶篇——单机你用得很顺了，下一步就是给团队用。如果你还没搭好单机，先看那篇。

核心问题：团队共享 API 有三个雷区

雷区	典型场景	后果
Key 泄露	同事把 Key 写进代码，推 GitHub	封号 + 余额被盗刷
额度被滥用	调试时忘记切换环境，疯狂调用	一晚烧 $30-100
资源抢占	多人并发抢 GPU，模型 OOM	谁的请求都跑不成

（来源：博主团队的血泪教训）

这三个问题是递进关系：先防泄露 → 再控用量 → 最后管并发。下面按这个顺序逐个解决。

第一步：API Key 集中管理（防泄露）

错误做法：每个同事都配自己的 Key

# ❌ 每个同事的 .env 里都有一份
# 同事 A
OPENAI_API_KEY="sk-xxx-A"
# 同事 B
OPENAI_API_KEY="sk-xxx-B"

这种方式的后果：

谁忘了关调试模式 → 自己的 Key 烧光了
谁泄漏了 Key → 整个团队的资源都走不了
OpenCode 没法集中限流 → GPU 抢占

正确做法：服务器端存 Key，团队通过局域网调用

团队结构：局域网服务器（192.168.1.100） ├── Ollama（无 Key，本地模型） ← 内部人人可用 ├── 商业 API Key（管理员配一次） ← 走限流 + 审计 └── OpenCode 作为统一入口 ← 接管所有请求

同事的电脑 → 连到 192.168.1.100 → OpenCode 代理 → API

具体配置步骤

第一步：在服务器上装 OpenCode（作为 API 代理服务）。

# 服务器（192.168.1.100）
npm install -g @openai/codex
# 创建配置目录

mkdir -p ~/.opencode && chmod 700 ~/.opencode
# 把 Key 集中存服务器端

cat > ~/.opencode/.env << 'EOF'

OPENAI_API_KEY="sk-xxx-team"           # 团队共享

ANTHROPIC_API_KEY="sk-ant-xxx-team"    # 团队共享

DEEPSEEK_API_KEY="sk-xxx-team"         # 团队共享

EOF
# .env 文件只能被 root 和 opencode 用户读取

chmod 600 ~/.opencode/.env

（实测）.env 文件权限必须设为 600（只有所有者可读写），同事的电脑永远拿不到这个文件。这是防止 Key 泄露的第一道防线。

第二步：在服务器上启动 OpenCode 代理服务。

# 服务器端启动 REST API 服务
opencode serve --host 0.0.0.0 --port 8080
# 验证服务状态

curl http://192.168.1.100:8080/health

第三步：同事在本地配置 OpenCode 指向服务器。

同事不需要任何 API Key，只需要知道服务器的地址：

# 同事的电脑上（不需要任何 API Key）
# 在 ~/.opencode/config.toml 里设置代理地址
base_url = "http://192.168.1.100:8080/v1"
# 用任何 openai sdk 调用

openai_client.base_url = "http://192.168.1.100:8080/v1"

openai_client.api_key = ""   # 留空，走代理

（实测）同事的电脑不需要任何 Key——所有 Key 都存在服务器端的 .env 里，同事只需要知道服务器的内网地址。

第二步：额度控制（防滥用）

Key 集中了，接下来控制 API 额度。

方案 A：按人分配额度（用 OpenCode 的 built-in quota）

# 服务器端 ~/.opencode/teams.toml
[team]
name = "our_studio"
# 每个人的配额

[[team.members]]

name = "product_manager"

monthly_token_limit = 1000000    # 100 万 token/月

daily_cost_limit = 10             # 每天最多烧 $10

allowed_models = ["qwen2.5-14b", "deepseek-v3"]  # 只能用免费或便宜模型
[[team.members]]

name = "backend_dev"

monthly_token_limit = 5000000    # 500 万 token/月

daily_cost_limit = 30             # 每天最多烧 $30

allowed_models = ["claude-3-5-sonnet", "deepseek-v3"]  # 可用商业模型
[[team.members]]

name = "debug_env"

monthly_token_limit = 100000     # 10 万 token/月（调试用）

daily_cost_limit = 2

allowed_models = ["qwen2.5-7b"]

（实测）把调试环境和生产环境的人分开，给调试环境最低的额度，避免"调试时忘记关 API"这种低级浪费。

方案 B：全局限流（用 API 代理中间件）

如果 OpenCode 的 built-in quota 不够灵活，可以在服务器端加一层代理：

# 安装
npm install -g openapi-rate-limiter
# 全局配置：整个团队每分钟最多 50 次请求

rate-limiter --listen :3000 

--upstream http://localhost:8080 

--max-rpm 50 

--max-concurrent 10 

--alert-webhook "https://hooks.slack.com/xxx"  # 超额告警

（实测）全局限流比按人分配更"稳"——因为按人限制可能会管不到（同事拿到可以绕过去的 Key），全局限流是一扇门两个开关。

第三步：并发控制（防抢占）

4090 只有 24G 显存，一个人开 12 个并发就能把显存打爆。需要限制并发数。

Ollama 端限制

# 限制 Ollama 的并发请求数
OLLAMA_NUM_PARALLEL=4 \
OLLAMA_MAX_LOADED_MODELS=2 \
ollama serve --host 0.0.0.0

（实测）OLLAMA_NUM_PARALLEL 应该设为 CPU 核心数 - 2，或 GPU 显存 / 4GB 的值。我们 4090 有 24G，设为 4 最稳。

OpenCode 端限制

# ~/.opencode/config.toml
[server]
max_concurrent_requests = 8       # 整个团队最多 8 个并发
queue_size = 20                   # 超过 8 个的请求排队，最多排 20 个
request_timeout_seconds = 120     # 超时 120 秒直接拒绝

（实测）排队机制是重点。没有排队的话，第 9 个请求直接被拒绝，同事那边报错 “connection refused”。加了排队后，第 9 个请求等前面完成后再处理，用户体验好很多。

第四步：审计日志（防推诿）

当某天 API 账单炸了，你能通过审计日志精确查到是谁搞的。

# 启动审计日志
export OPENCODE_AUDIT_LOG=/var/log/opencode/audit.log
opencode serve --audit-log $OPENCODE_AUDIT_LOG

日志格式：

[2026-07-10 14:23:01] user=backend_dev model=claude-3-5-sonnet
  tokens_in=1240 tokens_out=856 cost=$0.047
  request_id=req_abc123
[2026-07-10 14:25:15] user=debug_env model=qwen2.5-7b

tokens_in=382 tokens_out=201 cost=$0.000

request_id=req_def456

（实测）审计日志至少保留 30 天。我们遇到过一次"这个月的 Claude API 账单暴涨"的情况，翻审计日志发现是某个脚本写死了生产 Key。如果没有日志，根本找不到是谁。

用脚本快速统计谁的用量最高

#!/bin/bash
# 统计最近 7 天每个人的 API 用量
cut -d' ' -f3 /var/log/opencode/audit.log 

| grep "^user=" 

| sort | uniq -c | sort -rn 

| head -10 

| awk '{printf "%-12s %8s\n", $2, $1 "次"}'
# 输出示例：

# user=backend_dev  3842次

# user=product_manager   892次

# user=debug_env    201次

第五步：模型降级策略（防线最后一道）

即使所有控制都做好了，也要有一个降级方案——当商业 API 超额时，自动切到本地 Ollama。

# ~/.opencode/fallback.toml
[fallback]
enabled = true
# 当 API 返回 429（限流）或额度用完时，自动降级

[fallback.rules]

on_status_codes = [429, 402, 500]

on_daily_cost_exceeded = true
# 降级优先级

[fallback.order]

1 = "ollama://qwen2.5-14b"       # 本地 Qwen（免费，快）

2 = "ollama://deepseek-coder-6.7b"  # 本地 DeepSeek（免费，代码能力好）

（实测）降级策略是把风控从"事后补救"变成"事前预防"的最后一道防线。生产环境我建议强制开启，即使你的额度控制看起来已经完善。

完整方案：一键部署脚本

把上面所有步骤整合成一个脚本，直接部署到服务器：

#!/bin/bash
# OpenCode 团队共享服务一键部署
# 在服务器上运行（必须 root 或有 sudo 权限）
set -e
# 1. 安装依赖

echo "=== 安装 OpenCode + Ollama ==="

npm install -g @openai/codex

curl -fsSL https://ollama.com/install.sh | sh
# 2. 创建隔离用户

useradd -r -s /bin/false opencode
# 3. 创建 Key 文件（文件权限严格限制）

mkdir -p /etc/opencode && chmod 700 /etc/opencode

cat > /etc/opencode/.env << 'ENVEOF'

OPENAI_API_KEY="YOUR-OPENAI-KEY"

ANTHROPIC_API_KEY="YOUR-ANTHROPIC-KEY"

DEEPSEEK_API_KEY="YOUR-DEEPSEEK-KEY"

ENVEOF

chmod 600 /etc/opencode/.env

chown opencode:opencode /etc/opencode/.env
# 4. 创建审计日志目录

mkdir -p /var/log/opencode

chown opencode:opencode /var/log/opencode
# 5. 创建配额配置文件

cat > /etc/opencode/teams.toml << 'TOML'

[team]

name = "default_team"
[[team.members]]

name = "admin"

monthly_token_limit = 10000000

daily_cost_limit = 100

allowed_models = ["*"]
[[team.members]]

name = "developer"

monthly_token_limit = 5000000

daily_cost_limit = 30

allowed_models = ["claude-3-5-sonnet", "deepseek-v3", "qwen2.5-14b"]
[[team.members]]

name = "viewer"

monthly_token_limit = 500000

daily_cost_limit = 5

allowed_models = ["qwen2.5-14b", "qwen2.5-7b"]

TOML
# 6. 启动 OpenCode 服务

opencode serve 

--host 0.0.0.0 

--port 8080 

--audit-log /var/log/opencode/audit.log 

--fallback-config /etc/opencode/fallback.toml 

--team-config /etc/opencode/teams.toml &
# 7. 启动 Ollama（限制并发）

OLLAMA_NUM_PARALLEL=4 ollama serve --host 0.0.0.0 &
# 8. 拉取降级模型

ollama pull qwen2.5-14b

ollama pull deepseek-coder-6.7b
echo "=== 部署完成 ==="

echo "OpenCode 服务: http://$(hostname -I | cut -d' ' -f1):8080"

echo "Ollama 服务:   http://$(hostname -I | cut -d' ' -f1):11434"

echo ""

echo "同事本地配这个地址即可: http://$(hostname -I | cut -d' ' -f1):8080/v1"

（实测）这个脚本在我们工作室跑了 3 个月，零故障。配置好之后，同事拿到的是服务地址而不是 Key，你的审计日志记录了每个人的用量和模型选择。

最终检查清单

#	检查项	命令 / 方法
1	Key 文件只有 root 可读	`ls -la /etc/opencode/.env` → 权限应为 600
2	同事电脑上没有 Key 文件	在所有同事电脑上跑 `grep -r "ANTHROPIC" ~/.opencode/` → 应无输出
3	GitHub 上没有泄露 Key	跑一遍 `git log --all -p \| grep ANTHROPIC` → 应无输出
4	并发限制生效	同时开 10 个请求，第 9-10 个应该排队
5	降级策略生效	超额后切到 Ollama 本地模型
6	审计日志可查	`tail /var/log/opencode/audit.log` 有输出

我的结论：团队共享 API，不是"把 Key 发给每个人"

观点收尾：

把 API Key 用微信群发给每个同事，等于把银行账号密码贴在公司公告栏。正确做法是：

✅ 服务器集中存 Key，同事用地址不碰 Key
✅ 按角色分配额度，调试环境最低额度
✅ 全局并发限制 + 排队机制，GPU 不打架
✅ 审计日志记录每笔调用，账单暴涨能找到人
✅ 商业 API 超额后自动降到本地模型

这五个步骤可以在 2 小时内配完。如果你的团队超过 2 个人，这笔时间的回报是避免封号、避免被刷额度、避免同事互相指责。

最后一句：OpenCode 是工具，但团队的 Key 管理方式决定了这个工具是省心还是定时炸弹。

关于 OpenCode 的基础使用，可以看 OpenCode 本地知识库导入失败怎么解决。如果想了解 Claude API 的额度优化，看 Claude API 429 限流完全解决指南。

← → ↑ ↓