员工从开户到实际调用
- 1申请
- 2独立用户 / Key
- 3分组与额度
- 4客户端配置
- 5实际调用
按需开户，每人独立凭据；分组与 Key 决定接入资格，余额和并发决定能否执行。配置说明分别覆盖 Windows 与 macOS 的路径、环境变量和桌面客户端继承方式。登录成功但余额为零仍会被拒绝，排查时将认证与额度区分。
Skip to content
跳到项目内容内部客户端与模型接入链路01 / 01 内部用户 Key 与上游账号分开管理。请求经过分组、额度和模型映射后调用上游，服务将使用记录写入数据层。
项目速览
业务背景
部署现有模型接入服务，支持内部客户端使用并维护模型更新与故障恢复。
负责范围
- 服务部署
- 员工接入
- 模型兼容
- 用量与恢复
独立用户 / Key
员工接入
历史记录包含按申请开户、分组和客户端配置；凭据与员工信息不进入案例。
流式 + 工具
兼容验证
历史模型升级实际通过流式响应、函数调用与工具结果回传。
20 → 64 MiB
请求体上限
按日志中实际超限请求调整反向代理上限，服务未重启。
01
核心业务
内部开发工具需要稳定的模型接入地址，同时按员工管理调用资格、额度和使用记录。基于 sub2api 部署统一入口，将客户端配置、内部用户与上游账号分开管理；维护重点是服务可用、模型兼容和变更恢复。
新增模型涉及上游目录、账号映射、对外模型列表、兼容版本和缓存刷新，任何一处不同步都可能出现“列表可选但调用失败”。因此接入过程包含实际流式请求、工具结果回传、用量关联和旧模型回归，而不止后台添加名称。
- 01员工与客户端接入
- 按申请创建独立用户与 Key，管理员管理分组、余额、并发和状态；客户端统一接入兼容 API。
- 02上游资源与模型
- 分别核对账号可调度状态、额度、模型映射和客户端兼容版本，保留各账号已有规则。
- 03用量与服务维护
- 关联响应模型与持久用量，更新前备份配置，失败时恢复；容器健康与真实请求分别检查。
02
技术栈
- 入口与服务
- sub2apiDockerNginxHTTPS
- 数据
- PostgreSQLRedis用量记录配置缓存
- 接入协议
- 兼容 API流式响应函数调用工具结果回传
- 维护工具
- Pythonsystemd配置备份请求 / 会话关联
03
系统架构与部署
访问入口
Nginx / HTTPS / 兼容 API客户端接入统一地址，管理页面和请求入口经反向代理访问。
应用服务
sub2api / Docker部署现有开源接入服务，维护用户分组、上游账号、模型规则和兼容设置。
数据组件
PostgreSQL / Redis应用、数据库与缓存容器分别运行，持久用量与配置缓存分别核对。
维护工具
Python / systemd / 日志与配置备份变更脚本在服务端独立执行，避免 SSH 断开打断长流程，保留验证和恢复结果。
04
核心业务链路
新增模型而不覆盖原有账号规则
- 1上游探测
- 2配置备份
- 3兼容版本
- 4必要映射
- 5缓存生效
- 6回归
先用最小请求确定实际模型和账号能力。对未限制映射的账号保留设置，仅给显式映射账号追加新模型；兼容版本生效后开放入口。最终核对对外目录、实际响应模型、流式输出和工具调用后的结果回传，再运行旧模型请求。
调用成功但验证报告缺少用量
- 1请求 / 会话标识
- 2usage 记录
- 3响应模型与成本
- 4修正验证关联
历史维护中，调用及工具回传已成功，验证脚本却因使用错误关联字段误判缺少计费并触发回滚。通过正确会话标识找到持久记录后修正脚本，再完成最终验收。排查依据实际记录，避免将验证脚本的误判写成业务计费丢失。
05
关键机制与取舍
01模型可见性与可调用性分别核对
- 约束
- 上游目录可能已列出模型，但账号额度、映射或兼容版本仍不满足请求条件。
- 做法
- 核对目录后进行实际最小调用，区分额度限制、兼容拒绝与模型映射问题。配置变更保留旧值，等待缓存自然刷新后验证对外入口；接入验证同时覆盖旧模型。
- 效果
- 维护能够定位失败发生在哪一层，模型升级不会被一个列表检查误判完成。
02变更可恢复，验证可关联
- 约束
- SSH 中断会打断本机串行操作；错误请求关联又可能触发不必要的回滚。
- 做法
- 长验证由服务端独立任务执行，脚本保存配置快照与最终结果；流式结束、工具回传、用量记录各自检查，使用正确请求或会话标识连接证据。失败恢复配置后再次核对服务与旧模型。
- 效果
- 一次维护留下可复核的变更和恢复结果，连接中断不必演变为服务中断。
03慢与失败先定位到链路，再决定改哪里
- 约束
- 员工反馈大文件请求失败、部分请求很慢，直觉上会归因于服务器资源不足。
- 做法
- 从网关日志统计状态码分布与请求体大小：413 来自反向代理的请求体上限，上限从 20 MiB 调到 64 MiB；408 按出口聚合后发现集中在少数出口，属于上传链路问题。
- 效果
- 修复前日志中有 47 次超限、最大约 28 MB，修复后真实流式请求 2.47 秒，服务未重启；当日 6,098 次请求中 237 次 408，其中 235 次集中在 4 个出口。只验证了低推理档位与短上下文。
06
AI 协作开发
这套服务本身就是团队 AI 编程客户端的模型接入层；故障排查、配置修改和新模型启用由 Agent 执行，员工的客户端配置文档也由 Agent 编写。
- Agent 负责
413 问题的最小修复
从日志中找到 47 次超限请求，只把请求体上限从 20 MiB 调到 64 MiB；先备份，再 nginx -t，再 reload，并测试 64 MiB 与 64 MiB + 1 字节两个边界。
- 回滚演练
两次回滚都按设计生效
启用新模型时 SSH 中断触发完整回滚，计费核对用错字段又触发一次；两处原因修好以后再重试。
- 客户端规范
密钥文件权限与粘贴约束
员工客户端配置文档要求密钥文件权限设为 600，不在对话和工单里粘贴密钥。
只验证了低推理档位与短上下文，更高档位与长上下文不写成已支持。
07
阶段成果
- 部署并维护内部统一模型入口，形成员工接入与多端客户端配置方式。
- 模型更新覆盖上游能力、映射、兼容、持久用量和配置恢复。
继续浏览
别急，先让缓存热一下。