Twinny Server：构建 5 人团队的 GPU 共享网关
在 AI 开发团队中，让每位成员在笔记本上独立运行 7B 参数模型不仅浪费资源，还导致模型版本碎片化。Twinny Server 应运而生，它充当了一个轻量级的网关，部署在现有的模型服务器之前，为每个开发者分配唯一密钥并记录使用行为。本文基于官方最新实践指南，梳理了从本地部署到团队协作的完整流程。
从本地回环到团队访问
启动与配置
在已安装 Node 18+ 和模型服务器（如 LM Studio）的机器上，运行 npx twinny-server quickstart。该命令会自动生成 twinny.gateway.json 配置文件，并创建管理员密钥。系统会自动探测本地端口，推荐模型用于聊天、补全和嵌入任务。
关键配置项：
--backend：若模型服务器不在本机，可指定 IP（如--backend lmstudio=10.0.0.5）或 OpenAI 兼容的 URL。- 密钥安全：生成的管理员密钥为 SHA-256 哈希，丢失后无法恢复，仅能吊销并重新生成。
- 监听地址：默认监听
http://127.0.0.1:8765，确保仅管理员可访问管理界面。
暴露服务策略
Twinny 不管理 SSL 证书，根据团队网络环境有两种暴露方式：
- 私有网络：若团队已有内网（如 VPN 或 Tailnet），直接在配置文件中设置
listen.host为内网 IP，网关即可被团队访问。 - 公网访问：若无内网，建议保留网关在回环接口，并在前端部署 Caddy 等反向代理，通过 HTTPS 转发请求。所有外部请求必须携带 Bearer Token 作为 Header，确保密钥安全。
安全的邀请与密钥管理
Twinny 提供了三种分配开发者密钥的方式，按推荐优先级排序：
- 邀请链接（推荐）：在管理页面的 People 板块输入姓名生成链接。链接有效期 7 天，仅打开一次即失效。开发者点击后，VS Code 会自动将密钥存入秘密存储，并同步团队默认模型配置。
- 验证码登录：开发者输入网关 URL 请求密钥，获取短码后由管理员在后台批准。此方式需人工确认，确保密钥仅分配给本人。
- 手动创建：使用
keys create alice命令生成密钥并通过可信渠道发送。此方式虽可行，但密钥传输过程存在风险。
重要原则：每个开发者必须拥有独立密钥。共享密钥会导致使用统计失效，且无法追踪具体贡献者。
智能队列与并发控制
在多用户共享 GPU 场景下，并发控制是核心体验。Twinny Server 默认限制 limits.maxActiveRequests 为 4 个活跃请求（聊天与补全），嵌入请求不计入此限制。
队列机制
- 等待策略：当资源不足时，请求进入队列。补全任务等待上限 500ms，聊天任务等待上限 15s。这种不对称设计旨在优先保证即时反馈。
- 最大等待数：最多 8 个请求在队列中排队，按 FIFO 原则处理。
- 优雅退出：若开发者在请求等待期间离开编辑器，请求将自动从队列移除，不影响其他用户。
监控与调优
- 指标查询：管理员可通过
/metrics端点查看 Prometheus 格式的文本指标，重点关注twinny_queued_requests。 - 动态调整：若队列频繁满载，可增大
maxActiveRequests或增加后端实例。 - 单用户限制：通过
limits.perKey可限制单个用户的并发请求数和每分钟请求数，防止个别用户占用过多资源。
人员变动处理
当团队成员离职时，Twinny Server 提供了秒级的密钥回收机制：
- 即时失效：调用
keys revoke alice后，该用户的下一次请求将在 1 秒内失败，无需重启服务。 - 审计保留：使用记录保留 30 天，便于后续审计与结算。
Twinny Server 以免费计划覆盖 5 个活跃密钥，为小型 AI 团队提供了一个低成本、高安全性的协作基础设施。
