从 1.x 迁移

先说结论§

• 不能原地升级——不存在「拉个新镜像就升上去」这条路
• 没有数据导入工具——渠道、密钥、分组都需要在 2.0 里重新配置
• 1.x 仍然可用——维护线继续存在， 文档保留在 1.4.x 文档，不急的话可以先不动

需要做的是：另起一套 2.0，配好、验证、再把流量切过去， 旧的那套在回滚窗口内保持不动。

为什么不能升级§

2.0 重写了数据模型。最根本的变化是概念层级从一层变成了两层： 1.x 里「分组」同时承担了上游配置和对外授权两个职责； 2.0 把它拆成了分组（朝上游）和访问密钥（朝应用）。

这不是加几个字段能兼容的差异——旧数据里没有任何信息可以推导出 「哪些应用该被授权用哪些分组」。所以与其提供一个会猜错的导入工具， 不如让你在 2.0 里明确配一遍。配置量通常不大，而且只需要做一次。

概念对照§

三层还是两层这件事容易记混，详见 核心概念。

请求地址的变化§

这是应用侧唯一必须改的东西。1.x 需要把分组名拼进路径， 2.0 不需要：

# 1.x：地址里带分组名
http://host:3001/proxy/你的分组名/v1/chat/completions

# 2.0：固定地址，用哪个分组由访问密钥和模型名决定
http://host:3001/v1/chat/completions

换句话说，2.0 里应用只需要一个基础 URL 和一把访问密钥。 以后你在管理台增删分组、换服务商，应用侧都不用再动。

并行部署§

关键是两套实例的四样东西必须完全分开，任何一样共用都可能出问题：

• 端口——2.0 用一个新端口，别占用 1.x 正在用的
• 数据目录 / Docker 卷——必须是全新的，不要复用
• 数据库——用新库；哪怕都是 MySQL 也要分开建库
• OAuth 回调端口——若要用订阅账号，注意端口是独占的， 见 订阅账号

# 1.x 保持原样运行，不要动它

# 2.0 clone 到另一个目录
git clone --depth 1 --branch v2 \
  https://github.com/tbphp/gpt-load.git gpt-load-v2
cd gpt-load-v2
cp .env.example .env

# 在 .env 里把端口改成未占用的，例如 3002
# PORT=3002

docker compose up -d

起来之后按 快速开始 配置： 建分组、填密钥、选模型、发访问密钥。

切流量前的验证§

逐项确认，再动生产流量：

1. 每个分组都能跑通——用真实模型各发一个请求，不要只测一个分组
2. 模型名对得上——2.0 里模型是分组级声明的， 确认应用请求的模型名在对应分组里已开放
3. 协议匹配——访问密钥要勾选应用实际使用的协议
4. 看一眼监控——请求日志里确认路由走向符合预期， 见 监控与排障
5. 过一遍上生产清单——特别是密钥备份与网络边界， 见 安全与上生产

建议先把一个非关键应用切到 2.0 跑一段时间， 确认无误后再切其余的。

回滚§

因为是并行部署，回滚就是把应用的地址和密钥改回 1.x， 没有数据迁移需要撤销。