员工从开户到实际调用
申请 → 独立用户 / Key → 分组与额度 → 客户端配置 → 实际调用
按需开户，每人独立凭据；分组与 Key 决定接入资格，余额和并发决定能否执行。配置说明分别覆盖 Windows 与 macOS 的路径、环境变量和桌面客户端继承方式。登录成功但余额为零仍会被拒绝，排查时将认证与额度区分。
Appearance
Skip to content
跳到项目内容内部客户端与模型接入链路01 / 01 内部用户 Key 与上游账号分开管理。请求经过分组、额度和模型映射后调用上游，服务将使用记录写入数据层。
公司基础设施/持续维护
sub2api 部署与维护
内部模型接入与兼容性治理
01
核心业务
内部开发工具需要稳定的模型接入地址，同时按员工管理调用资格、额度和使用记录。基于 sub2api 部署统一入口，将客户端配置、内部用户与上游账号分开管理；维护重点是服务可用、模型兼容和变更恢复。
新增模型涉及上游目录、账号映射、对外模型列表、兼容版本和缓存刷新，任何一处不同步都可能出现“列表可选但调用失败”。因此接入过程包含实际流式请求、工具结果回传、用量关联和旧模型回归，而不止后台添加名称。
- 员工与客户端接入
- 按申请创建独立用户与 Key，管理员管理分组、余额、并发和状态；客户端统一接入兼容 API。
- 上游资源与模型
- 分别核对账号可调度状态、额度、模型映射和客户端兼容版本，保留各账号已有规则。
- 用量与服务维护
- 关联响应模型与持久用量，更新前备份配置，失败时恢复；容器健康与真实请求分别检查。
02
技术栈
- 入口与服务
- sub2api · Docker · Nginx · HTTPS
- 数据
- PostgreSQL · Redis · 用量记录 · 配置缓存
- 接入协议
- 兼容 API · 流式响应 · 函数调用 · 工具结果回传
- 维护工具
- Python · systemd · 配置备份 · 请求 / 会话关联
03
系统架构与部署
访问入口
Nginx / HTTPS / 兼容 API客户端接入统一地址，管理页面和请求入口经反向代理访问。
应用服务
sub2api / Docker部署现有开源接入服务，维护用户分组、上游账号、模型规则和兼容设置。
数据组件
PostgreSQL / Redis应用、数据库与缓存容器分别运行，持久用量与配置缓存分别核对。
维护工具
Python / systemd / 日志与配置备份变更脚本在服务端独立执行，避免 SSH 断开打断长流程，保留验证和恢复结果。
04
核心业务链路
新增模型而不覆盖原有账号规则
上游探测 → 配置备份 → 兼容版本 → 必要映射 → 缓存生效 → 回归
先用最小请求确定实际模型和账号能力。对未限制映射的账号保留设置，仅给显式映射账号追加新模型；兼容版本生效后开放入口。最终核对对外目录、实际响应模型、流式输出和工具调用后的结果回传，再运行旧模型请求。
调用成功但验证报告缺少用量
请求 / 会话标识 → usage 记录 → 响应模型与成本 → 修正验证关联
历史维护中，调用及工具回传已成功，验证脚本却因使用错误关联字段误判缺少计费并触发回滚。通过正确会话标识找到持久记录后修正脚本，再完成最终验收。排查依据实际记录，避免将验证脚本的误判写成业务计费丢失。
05
关键机制与取舍
模型可见性与可调用性分别核对
上游目录可能已列出模型，但账号额度、映射或兼容版本仍不满足请求条件。
核对目录后进行实际最小调用，区分额度限制、兼容拒绝与模型映射问题。配置变更保留旧值，等待缓存自然刷新后验证对外入口；接入验证同时覆盖旧模型。
维护能够定位失败发生在哪一层，模型升级不会被一个列表检查误判完成。
变更可恢复，验证可关联
SSH 中断会打断本机串行操作；错误请求关联又可能触发不必要的回滚。
长验证由服务端独立任务执行，脚本保存配置快照与最终结果；流式结束、工具回传、用量记录各自检查，使用正确请求或会话标识连接证据。失败恢复配置后再次核对服务与旧模型。
一次维护留下可复核的变更和恢复结果，连接中断不必演变为服务中断。
06
实践成果与验证
独立用户 / Key
员工接入
历史记录包含按申请开户、分组和客户端配置；凭据与员工信息不进入案例。
流式 + 工具
兼容验证
历史模型升级实际通过流式响应、函数调用与工具结果回传。
用量 + 回归
更新结果
关联计费记录和旧模型回归通过，更新期间服务未重启；模型菜单元数据仍有后续完善项。
- 部署并维护内部统一模型入口，形成员工接入与多端客户端配置方式。
- 模型更新覆盖上游能力、映射、兼容、持久用量和配置恢复。
继续浏览
别急，先让缓存热一下。