生长的档案 · LIVING ARCHIVE

Debian 12 VPS 部署 Groq → LiteLLM → Caddy API 反代全流程

Fri, 04 Sep 2026 00:00:00 GMT

适用环境：Debian GNU/Linux 12 (bookworm)、x86_64 VPS
架构：客户端 → Cloudflare DNS（可选代理）→ Caddy → LiteLLM → Groq API
LiteLLM 负责统一 OpenAI 兼容 API，并为后续增加 OpenAI、Anthropic、Gemini 等上游 API 预留统一入口。

1. 最终架构

Client
  │
  │ https://llm.example.com/v1/...
  ▼
Cloudflare DNS / Proxy（可选）
  │
  ▼
Caddy :443
  │
  ▼
LiteLLM :4000
  │
  ▼
Groq API
https://api.groq.com/openai/v1

建议：

LiteLLM 只负责 API 网关、模型映射和统一 OpenAI 兼容接口。
Caddy 负责 HTTPS/TLS、域名入口和反向代理。
Groq API Key 只保存在 VPS。
客户端只使用 LiteLLM Master Key。
后续增加其他 AI 平台时，只需增加 LiteLLM 的模型配置。

2. 确认系统

cat /etc/os-release

预期：

PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"

确认架构：

uname -m

x86 VPS 通常显示：

x86_64

3. 更新系统并安装基础工具

apt update && apt upgrade -y

安装常用工具：

apt install -y \
  curl \
  wget \
  ca-certificates \
  gnupg \
  lsb-release \
  nano \
  ufw

4. 安装 Docker

添加 Docker 官方仓库：

install -m 0755 -d /etc/apt/keyrings

curl -fsSL https://download.docker.com/linux/debian/gpg \
  -o /etc/apt/keyrings/docker.asc

chmod a+r /etc/apt/keyrings/docker.asc

添加仓库：

echo \
  "deb [arch=$(dpkg --print-architecture) \
  signed-by=/etc/apt/keyrings/docker.asc] \
  https://download.docker.com/linux/debian \
  $(. /etc/os-release && echo "$VERSION_CODENAME") stable" \
  | tee /etc/apt/sources.list.d/docker.list > /dev/null

更新：

apt update

安装 Docker：

apt install -y \
  docker-ce \
  docker-ce-cli \
  containerd.io \
  docker-buildx-plugin \
  docker-compose-plugin

验证：

docker --version
docker compose version

启动：

systemctl enable --now docker

5. 为什么使用 Docker 部署 LiteLLM

Docker 的主要优势：

环境隔离

LiteLLM 运行所需的 Python、依赖库和版本全部封装在容器内。

不会污染 Debian 系统 Python 环境。

升级方便

更新镜像：

docker compose pull
docker compose up -d

重建方便

配置出问题时：

docker compose down
docker compose up -d

环境变量管理方便

API Key 可以放在 .env：

GROQ_API_KEY=...

不需要写入配置文件。

需要注意的影响

Docker 会增加少量：

内存占用
磁盘镜像占用
网络层复杂度

对于 API 反代场景，这些开销通常非常小。

6. 创建 LiteLLM 目录

mkdir -p /opt/litellm
cd /opt/litellm

7. 创建 `.env`

创建：

nano /opt/litellm/.env

填写：

GROQ_API_KEY=gsk_xxxxxxxxxxxxxxxxxxxxxxxxxxxxx

LITELLM_MASTER_KEY=sk-your-random-master-key

生成一个随机 Master Key：

openssl rand -hex 32

然后保存。

限制权限：

chmod 600 /opt/litellm/.env

8. 创建 LiteLLM 配置

创建：

nano /opt/litellm/config.yaml

配置 Groq 模型：

model_list:

  # OpenAI GPT OSS 120B
  - model_name: groq-gpt-oss-120b
    litellm_params:
      model: groq/openai/gpt-oss-120b
      api_key: os.environ/GROQ_API_KEY

  # OpenAI GPT OSS 20B
  - model_name: groq-gpt-oss-20b
    litellm_params:
      model: groq/openai/gpt-oss-20b
      api_key: os.environ/GROQ_API_KEY

  # Qwen 3.8 27B
  - model_name: groq-qwen3.8-27b
    litellm_params:
      model: groq/qwen/qwen3.8-27b
      api_key: os.environ/GROQ_API_KEY

  # Qwen 3.6 27B
  - model_name: groq-qwen3.6-27b
    litellm_params:
      model: groq/qwen/qwen3.6-27b
      api_key: os.environ/GROQ_API_KEY

  # Groq Compound
  - model_name: groq-compound
    litellm_params:
      model: groq/groq/compound
      api_key: os.environ/GROQ_API_KEY

  # Groq Compound Mini
  - model_name: groq-compound-mini
    litellm_params:
      model: groq/groq/compound-mini
      api_key: os.environ/GROQ_API_KEY

说明：

左侧：

groq-gpt-oss-20b

是客户端看到的统一模型名称。

右侧：

groq/openai/gpt-oss-20b

是 LiteLLM 调用 Groq 时使用的 provider/model 标识。

9. 创建 Docker Compose

创建：

nano /opt/litellm/docker-compose.yml

内容：

services:
  litellm:
    image: ghcr.io/berriai/litellm:main-latest
    container_name: litellm

    restart: unless-stopped

    env_file:
      - .env

    volumes:
      - ./config.yaml:/app/config.yaml:ro

    # 使用 VPS 宿主机网络
    network_mode: host

    command:
      - "--config"
      - "/app/config.yaml"

启动：

cd /opt/litellm
docker compose up -d

查看：

docker compose ps

日志：

docker logs -f litellm

正常情况下会看到：

Uvicorn running on http://0.0.0.0:4000

10. 验证 LiteLLM 本地服务

确认端口：

ss -ltnp | grep ':4000'

访问首页：

curl -I http://127.0.0.1:4000/

获取模型：

set -a
source /opt/litellm/.env
set +a

curl http://127.0.0.1:4000/v1/models \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY"

测试 Chat Completions：

curl http://127.0.0.1:4000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  -d '{
    "model": "groq-gpt-oss-20b",
    "messages": [
      {
        "role": "user",
        "content": "Reply with OK"
      }
    ],
    "max_tokens": 100
  }'

预期：

{
  "choices": [
    {
      "message": {
        "content": "OK"
      }
    }
  ]
}

11. Groq API Key 故障排查

如果 LiteLLM 返回：

Invalid API Key

首先确认 VPS 当前环境变量：

printf '%s' "$GROQ_API_KEY" | sha256sum

检查 .env：

grep '^GROQ_API_KEY=' /opt/litellm/.env \
  | cut -d= -f2- \
  | tr -d '\r\n' \
  | sha256sum

检查容器：

docker exec litellm sh -c 'printf "%s" "$GROQ_API_KEY"' \
  | sha256sum

如果 .env 和容器一致，但宿主机不同，通常说明当前 Shell 中使用的是旧环境变量。

重新加载：

cd /opt/litellm
set -a
source .env
set +a

直接测试 Groq：

curl -i https://api.groq.com/openai/v1/models \
  -H "Authorization: Bearer $GROQ_API_KEY"

如果返回：

HTTP/2 200

说明 Key 本身有效。

如果容器需要验证：

docker exec litellm python -c '
import os
import httpx

r = httpx.get(
    "https://api.groq.com/openai/v1/models",
    headers={
        "Authorization": "Bearer " + os.environ["GROQ_API_KEY"]
    },
    timeout=30
)

print("STATUS:", r.status_code)
print("BODY:", r.text[:500])
'

12. 安装 Caddy

安装：

apt install -y caddy

启动：

systemctl enable --now caddy

查看：

systemctl status caddy --no-pager

13. 配置 Caddy 反向代理

编辑：

nano /etc/caddy/Caddyfile

建议最终配置类似：

llm.example.com {
    reverse_proxy 127.0.0.1:4000
}

将：

llm.example.com

替换成实际域名，例如：

llm.1463298.xyz

完整示例：

llm.1463298.xyz {
    reverse_proxy 127.0.0.1:4000
}

Caddy 会自动：

监听 HTTPS
申请证书
自动续期
HTTP 自动跳转 HTTPS

格式化：

caddy fmt --overwrite /etc/caddy/Caddyfile

验证：

caddy validate --config /etc/caddy/Caddyfile

重载：

systemctl reload caddy

14. 如果 Caddy 报 443 被占用

检查：

ss -ltnp | grep -E ':80|:443'

如果看到其他程序占用：

*:443

Caddy 无法监听 HTTPS。

例如：

xray
nginx
apache2

都可能占用 443。

需要修改对应服务端口，或者停止对应服务。

再次检查：

ss -ltnp | grep -E ':80|:443'

理想状态：

*:80   caddy
*:443  caddy

然后：

systemctl reload caddy

15. Cloudflare DNS 配置

在 Cloudflare 创建：

Type: A
Name: llm
Content: VPS IPv4

例如：

llm.1463298.xyz

是否开启橙云？

灰云

DNS only

客户端直接访问 VPS。

优点：

链路简单
适合 API
没有 Cloudflare Proxy 的请求限制影响

橙云

Proxied

客户端 → Cloudflare → VPS。

优点：

隐藏 VPS IP
获得 Cloudflare 网络保护
可使用部分 Cloudflare 安全能力

对于普通 API 反代，两种都可以。

如果使用橙云，需要确认你的 API 流量符合 Cloudflare 当前计划和代理规则。

16. Cloudflare SSL/TLS

建议：

SSL/TLS encryption mode:
Full (strict)

Full (strict) 的含义：

Cloudflare → VPS 之间也必须使用有效 TLS。

这里的 TLS 设置通常是域名/Zone 级别配置，不只是顶级域名。

Caddy 自动申请的公开证书可以满足严格模式。

不要使用：

Flexible

因为 Flexible 会导致 Cloudflare 到源站可能使用 HTTP，并容易造成重定向或安全问题。

17. UFW 防火墙

先查看：

ufw status

如果启用 UFW，放行 SSH：

ufw allow 22/tcp

放行 HTTP：

ufw allow 80/tcp

放行 HTTPS：

ufw allow 443/tcp

如果你的其他服务需要端口，例如：

ufw allow 30635/tcp
ufw allow 23116/tcp

启用：

ufw enable

查看：

ufw status numbered

注意：

LiteLLM 使用了：

如果 Caddy 和 LiteLLM 在同一 VPS，并且 LiteLLM 只作为 Caddy 后端，通常不建议对公网开放 4000。

18. 验证 HTTPS

curl -I https://llm.example.com

正常可能看到：

HTTP/2 200
server: uvicorn
via: 1.1 Caddy

获取模型：

curl https://llm.example.com/v1/models \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY"

测试模型：

curl https://llm.example.com/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  -d '{
    "model": "groq-gpt-oss-20b",
    "messages": [
      {
        "role": "user",
        "content": "Reply with OK"
      }
    ]
  }'

如果返回：

{
  "choices": [
    {
      "message": {
        "content": "OK"
      }
    }
  ]
}

说明完整链路已经成功：

Client
  ↓
HTTPS Domain
  ↓
Caddy
  ↓
LiteLLM
  ↓
Groq

19. 常用运维命令

进入目录：

cd /opt/litellm

查看状态：

docker compose ps

查看日志：

docker logs -f litellm

重启：

docker compose restart

配置修改后重建：

docker compose up -d --force-recreate

停止：

docker compose down

更新 LiteLLM：

docker compose pull
docker compose up -d

查看 Caddy：

systemctl status caddy --no-pager

重载 Caddy：

systemctl reload caddy

查看 Caddy 日志：

journalctl -u caddy -f

20. 后续增加其他 AI 平台

LiteLLM 的优势是后续可以继续增加：

OpenAI
Anthropic
Google Gemini
DeepSeek
OpenRouter
Azure OpenAI
其他 OpenAI Compatible API

最终客户端保持统一：

https://llm.example.com/v1

只需要在 LiteLLM 中增加新的：

model_name

和对应 provider 配置即可。

例如客户端始终调用：

/v1/chat/completions

切换模型：

{
  "model": "your-model-name"
}

不需要让客户端分别处理每个平台的 API 地址和认证方式。

21. 最终检查清单

LiteLLM

docker compose ps

应为：

Up

4000 端口

ss -ltnp | grep ':4000'

Caddy

systemctl status caddy --no-pager

应为：

active (running)

80 / 443

ss -ltnp | grep -E ':80|:443'

通常应由 Caddy 监听。

本地 API

curl http://127.0.0.1:4000/v1/models \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY"

公网 API

curl https://llm.example.com/v1/models \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY"

模型调用

curl https://llm.example.com/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  -d '{
    "model": "groq-gpt-oss-20b",
    "messages": [
      {
        "role": "user",
        "content": "Reply with OK"
      }
    ]
  }'

22. 当前推荐架构总结

Internet
    │
    ▼
Cloudflare
    │
    ▼
Caddy :443
    │
    ▼
LiteLLM :4000
    │
    ├── Groq
    ├── OpenAI（未来）
    ├── Gemini（未来）
    ├── Anthropic（未来）
    └── 其他 API（未来）

这是一个适合低负载、多 AI Provider、统一 OpenAI 兼容 API 的部署方案。

建议后续进一步完善：

LiteLLM 不直接暴露公网 4000。
为不同客户端创建独立 API Key。
增加速率限制。
定期更新 Docker 镜像。
备份 /opt/litellm/config.yaml。
不要把 .env 上传到 GitHub。
Cloudflare 使用 Full (strict)。

免费大模型 API 实战地图：AMD 直连与 BAI 反代两条路线

Thu, 03 Sep 2026 00:00:00 GMT

整理时间：2026-09-03 ｜信息来源：AMD 开发者官网（developer.amd.com.cn）、BAI 平台、Cloudflare Workers 文档、多份第三方实测教程 ⚠️ 两平台均为活动性质，模型池、额度与接口规则持续变动，下文以 2026 年 9 月初的最新快照为准，关键处已标注历史变化。

0. 核心思路：两条路线，同一个问题

最近一段时间，不少算力与 AI 服务商在境内推出活动，放出了可以免费调用的大模型 API。把当下能稳定用的两个境内免费通道——AMD 开发者平台与 BAI 平台——并排摆开，其实落在同一条主线上：去哪白嫖免费大模型，又怎么把它接进自己顺手的工具链。

答案不是唯一的，取决于平台「开没开好入口」：

路线 A · 原生直连：平台直接开放一套通用标准接口（也就是业内通用的 OpenAI 那套接口规范，Base URL + Key 直接给你），市面上绝大多数 AI 客户端和开发工具不用做任何改造，填进去就能调用。代表就是 AMD 开发者平台。
路线 B · 反代桥接：平台有免费模型，但官方入口不适合直接塞进第三方客户端（协议不对、路径不对、鉴权不对），需要一个「听得懂两边协议」的中间层。代表就是 BAI 平台 + Cloudflare Worker 反代。

一句话：平台入口「开得好」就直连，开得别扭就套一层反代。反代的价值是协议转换 + 域名自有，不是绕开鉴权。

下面把两条路线并排拆开，最后给一张选型对照表，照着对号入座即可。

路线 A · AMD 开发者平台（原生 OpenAI 兼容直连）

A1. 平台定位与入口

Radeon Cloud 是 AMD 官方的云端 AI 算力平台（类似 Colab，但跑的是 AMD 显卡）。国内站为 developer.amd.com.cn。

其中 Public Free Model APIs（公共免费模型 API） 是平台专门给开发者开的免费窗口：模型直接跑在 AMD 自己的服务器上，不需要你自己开实例，也不消耗 GPU 算力额度。它提供的是业内通用的 OpenAI 接口规范，所以 curl、Python SDK、Cherry Studio、Cursor、LangChain 等常见工具不用做任何改造，接上就能用。

入口	地址	用途
Token Factory（密钥工厂）	https://developer.amd.com.cn/radeon/tokenfactory	领取/管理 API Key、查看额度
Model APIs（模型接口）	https://developer.amd.com.cn/radeon/modelapis	查看免费模型、Base URL、复制 curl 示例

补充：加入 AMD AI Developer Program 还能额外领 $100 的 AMD Developer Cloud 算力额度（开实例、微调、训练），与本文的「公共免费模型 API」是两条不同的免费通道。

A2. 注册与拿 Key（约 10 分钟）

整个流程不绑卡、不充值。

⚠️ 实测踩坑（重要）：常规邮箱 / 手机号注册有几率失败——个人亲测两次均 100% 注册失败（卡在验证/激活环节，收不到验证码或激活无效）。强烈建议直接走第三方授权登录：GitHub、CSDN、魔搭社区，点一下授权即过。另外该站点已在国内完成 ICP 备案，属合规境内服务；要正常调用 API，账号的邮箱和手机号必须都通过验证——即便用第三方授权登录，也建议随后在账号设置里补齐并验证国内手机号，否则部分接口可能因账号未完全验证而被拒。

打开 Model APIs 页面 → 右上角点 Login。登录方式：GitHub、CSDN、魔搭社区 快捷登录（推荐）／手机号（支持国内号码）／邮箱。
完成账号验证：邮箱注册会收到验证邮件点链接激活；用第三方授权登录时若第三方邮箱已验证通常自动跳过，但请务必在账号设置里补齐并验证国内手机号。
进入 Token Factory：激活后页面跳到模型列表。Public Free Model APIs 区域下各免费模型卡片，点开任意卡片弹窗展示：
- Base URL：https://developer.amd.com.cn/radeon/api/v1
- Model 名：如 DeepSeek-V4-Flash、Qwen3.8-Flash-Next、MiniCPM5-1B
- 你的 API Key（每位用户独立生成），现成的 curl 测试代码（OpenAI 格式）
- 把 Key 复制下来存好，所有免费模型共用同一个 Key。
了解积分规则：卡片显示「输入 0.14 / 输出 0.28 / 缓存读 0.0028 pts 每 1M tokens」——这是相对用量统计，不是人民币，页面写明 Free to use. Points show relative usage, not a charge。

A3. 免费模型怎么选（2026-09 最新快照）

9 月初 Public Free Model APIs 板块挂着 4 个模型，定位完全不同：

模型	类型	状态	关键能力	适合场景
DeepSeek-V4-Flash-Vision-Exp	多模态 VLM（看图）	LIMITED FREE	305B 总参 / MoE 激活 13B，1M 上下文，8/31 开源（MIT）	图片问答、OCR、视觉理解、截图分析
DeepSeek-V4-Flash-0731	纯文本 LLM	FREE	DeepSeek V4 Flash 的 0731 快照	写代码、写文章、问答、翻译、Agent、长文档
Qwen3.8-Flash-Next	多模态 MoE	FREE	262144 token 上下文（可扩至 1M），125B 总/激活 6B，8/26 开源（Qwen4 架构先导版）	智能体编程、长文档、代码任务
MiniCPM5-1B	纯文本 LLM	FREE	1B 参数，AA 榜单小模型组第一，INT4 仅 0.5GB	本地部署、端侧、轻量 Agent、IoT

一句话选型：不知道用哪个 → DeepSeek-V4-Flash-0731（免费全能）；要看图 → DeepSeek-V4-Flash-Vision-Exp（限时免费先用）；要提前体验 Qwen4 底子 / 长上下文 → Qwen3.8-Flash-Next；要塞进自己产品 / 端侧 → MiniCPM5-1B。

📌 历史变化：8 月实测模型池曾为 DeepSeek-V4-Flash-0731、Qwen3.6-35B-A3B、MiniCPM5-1B、MiniCPM-V46。另有一个 Fireworks Credits 区（如 DeepSeek-V4-Pro、GLM 5.2、Kimi K2.5），需 Fireworks 额度，不属于免费池。

A4. 客户端接入：两种协议，两类客户端

AMD 的免费 API 原生同时支持 OpenAI Completions 与 Anthropic Messages 两条协议，同一个 Base URL、同一个 Key 就能喂进两类客户端，无需再套反代。关键是协议对上，不是域名对上就行：

客户端	接入 URL	API 协议	说明
DSH	`https://developer.amd.com.cn/radeon/api/v1`	OpenAI Completions	标准 OpenAI 兼容入口
CCswitch + Claude Code	`https://developer.amd.com.cn/radeon/api/v1`	Anthropic Messages	让 Claude Code 走 AMD 的模型

两处 API Key 统一填 AMD 平台的 key——AMD 原生同时支持 OpenAI Completions 与 Anthropic Messages 两条协议，鉴权身份始终来自 AMD，不要在客户端里填其他平台的 key。协议选错（如把 DSH 指到 Anthropic 路径）是最常见的接不通原因。

A5. 注意事项

限速是真的有限：积分做软限流，并发超 5 个开始排队，RPM 上限约 30 次/分钟。定位开发调试，别当生产级高并发 API 用。
每日额度会重置/变化：早期曾 $10/天，后下调至 $1/天（账号间可能有差异），每天早上 8 点重置。
LIMITED FREE 随时可能撤：Vision 版标 LIMITED FREE，遇到先薅，撤了换纯文本版。
Key 不要公开：等同密码，别发公开仓库；泄露了去 Token Factory 重新生成。
数据是否留存：云端推理会上传请求内容到 AMD 服务器，敏感数据建议走本地 MiniCPM5-1B。
连接偶尔不稳：实测出现过网络错误，把请求 retry 次数调大即可。

路线 B · BAI 平台 + Cloudflare 反代（桥接）

B1. 为什么需要反代

BAI 平台有免费模型，但官方入口不适合直接塞进第三方客户端（DSH、Claude Code 等）——它的协议、路径、鉴权跟通用客户端对不上。所以要在「平台」和「你的工具链」之间架一座桥：一个部署在 Cloudflare 上的 Worker，对外把平台协议翻译成客户端听得懂的 OpenAI / Anthropic 协议，鉴权身份仍然来自 BAI。

一个能跑的反代，离「能用的反代」之间，差的是平台适配——而不是又写几百行代码。

B2. 改造：让脚本听懂 BAI 的协议

起点是 dogchild 的 api-cf 仓库里一份现成的 _worker.js（通用 AI API 反向代理）。直接部署它并不工作，因为字段、鉴权、路由都按原作者平台来。把原脚本连同 BAI 接口约定一起交给 GPT 做适配：补全 BAI 需要的请求头、改写路径映射、把鉴权换成 BAI 的 key 体系。

迭代后的成品放在 Andrew-li777/API 仓库的 bai.js：

源脚本：dogchild/api-cf · cfapi/_worker.js
适配版：Andrew-li777/API · bai.js

改脚本 ≠ 写脚本：让 GPT 做平台适配，比从零手写快得多。

B3. 部署：Worker + 自定义域名

把 bai.js 内容贴进 Cloudflare Workers 的新建脚本，保存部署，再把自定义域名绑定到这个 Worker。完成后对外暴露两条基础路径：

/bai/v1 —— 走 OpenAI 风格的 completions 协议
/bai —— 走 Anthropic Messages 协议

B4. 接线：两种协议，两类客户端

关键是协议对上，不是域名对上就行。同一份部署，对外两条路：

客户端	接入 URL	API 协议	说明
DSH	`https://你的域名/bai/v1`	OpenAI Completions	标准 OpenAI 兼容入口
CCswitch + Claude Code	`https://你的域名/bai`	Anthropic Messages	让 Claude Code 走 BAI 的模型

两处 API Key 统一填 BAI 平台的 key——反代只负责转发，鉴权身份始终来自 BAI，不要在客户端里填 Cloudflare 或其他平台的 key。把 你的域名 换成真实域名；协议选错（如把 DSH 指到 /bai）是最常见的接不通原因。

B5. 现在能白嫖哪些模型

目前 BAI 平台这批模型免费，接入后直接在客户端里点选：

deepseekv4lash / deepseekv4lash-vision
glm5.3flash
qwen.8flash
hy3
mimov2.5

免费清单随平台变动，下单前以 BAI 控制台实际显示为准；反代层不缓存模型列表。

路线对照与选型

两张表把 A、B 两条路线摆在一起，照着选：

维度	路线 A · AMD 直连	路线 B · BAI 反代
接入形态	平台原生 OpenAI 兼容 API	自建 Cloudflare Worker 桥接
注册难度	中（邮箱/手机注册易失败，建议第三方授权）	低（BAI 账号 + Cloudflare 账号，无注册坑）
客户端覆盖	OpenAI 兼容系全覆盖（curl/Python/Cherry Studio/Cursor/opencode）	OpenAI 系（`/bai/v1`）+ Anthropic 系（`/bai`，可喂 Claude Code）
免费模型	DeepSeek-V4-Flash 系列、Qwen3.8-Flash-Next、MiniCPM5-1B	deepseekv4lash、glm5.3flash、qwen.8flash、hy3、mimov2.5
维护成本	零（平台维护）	中（要自己部署、绑域名、跟平台协议变动作适配）
适合谁	想最快用上免费模型、工具本身支持 OpenAI 协议	想用 Claude Code 等 Anthropic 系客户端、或要自有域名统一入口

怎么选：

工具支持 OpenAI 协议、只想最快用上 → 路线 A 直连，十分钟搞定。
用 Claude Code / 想要 Anthropic 协议、或想统一一个自有域名入口 → 路线 B 反代。
都不排斥 → 两条路线不冲突，AMD 当主力免费池，BAI 反代补 Anthropic 系客户端，互为备份。

收尾小结

免费模型从哪来：AMD 与 BAI 是当下两个可白嫖的境内平台，模型池都在滚动更新，能领就领、领到先用。
怎么进工具链：平台入口开得好就直连（AMD），开得别扭就套反代（BAI）。反代的核心是协议转换，鉴权始终来自原平台。
共同提醒：两者都属活动性质，额度有限速（AMD 约 $1/天、RPM 30）、LIMITED FREE 随时撤；Key 等同密码别公开；敏感数据走本地小模型。

参考链接

AMD 开发者中心（国内）：https://developer.amd.com.cn/
Token Factory：https://developer.amd.com.cn/radeon/tokenfactory
Model APIs：https://developer.amd.com.cn/radeon/modelapis
AMD AI Developer Program（领 $100 算力）：https://developer.amd/?page_id=5185
BAI 反代源脚本：dogchild/api-cf
BAI 反代适配版：Andrew-li777/API · bai.js

本文讲解 AMD 直连与 BAI 反代两条免费大模型 API 通道，所有模型、额度与接口以各平台官方页面实时显示为准。

从参考模板到 Living Archive：设计思路与迭代复盘

Tue, 01 Sep 2026 00:00:00 GMT

这座档案室不是凭空搭起来的。它经历过一次系统的逆向研究、一份技术方案、以及五个版本的迭代。这篇期刊是第一期的第一篇，正好用来记录这个网站的来路——既是给访客看的建造日志，也是给未来的自己留的施工笔记。

一、研究阶段：先理解，再设计

动工之前，我们花了一天时间逆向研究了六个个人网站。方法不是「看哪个好看就抄哪个」，而是把每个网站拆成三层来分析：

可观察的事实——页面上能看到什么
设计意图的推断——它为什么这样做
可迁移的原则——换一个名字、换掉内容，它是否仍然成立

六个参考样本

网站	核心身份	我们取走了什么
Edison Zhu	极简黑白编辑风作品集	物理动效：可甩的工牌、章节解锁、加载仪式感
Binapp	产品思维独立开发者	设计 token 纪律、单 accent 克制、60fps 预算自述
Wingshe	模板占位内容（无法验证内容层）	结构分析有效，内容层放弃
Margin	个人知识操作系统	搜索/快捷键/终端隐喻；但否决了 Terminal 视觉方向
MoeWah	数字档案世界观	骨架：档案编号、元数据字段、Ledger 台账、END OF FILE
Linzy	知识库博客（对照样本）	反例：主题默认即上线，设计身份缺席的代价

三个关键判断

第一，风格必须有出处。 Edison 的黑白来自他「从临摹海报开始」的设计启蒙；MoeWah 的档案来自站长的档案职业。风格的方法可以学，结果不能抄——所以本站选择了档案隐喻，但把它转译成自己的语言：「生长的档案 / Living Archive」。

第二，内容决定架构。 Margin 因为要放 74 篇文章所以做了搜索和快捷键；MoeWah 因为要放多年档案所以做了子域和编号系统。内容形态不同，网站架构就该不同。

第三，最大的风险是「有风格无资产」。 六站所有「风格」之所以成立，背后都有真实的产品、几十篇文章或多年档案——风格是资产的利息，不是本金。这个判断决定了本站的开发顺序：先有结构，再填内容，最后才是打磨。

二、方案阶段：融合而不是模仿

研究结论收敛成一份技术方案，核心决策是：

骨架取自 MoeWah：档案编号、元数据字段、登记卡、台账、卷终页脚——但编号规则转译为自有格式（2026-001 / PRJ-001），不复制原站
手感取自 Edison：物理动效全站统一，由一份 springs.ts 配置单一来源保证「同一只手」
严肃感的解法：放弃黑白，采用暖纸色系——米纸底 #FAF7F2 + 墨黑 + 朱砂橙 #C2410C 单 accent。朱砂 = 档案上的印章批注色，accent 本身延续档案隐喻而不是装饰

技术栈上有一个值得记录的取舍：参考的六个网站没有一个用 Next.js 和 Framer Motion，但我们还是选了它们——因为物理动效（拖拽 + 弹簧）用 FM 的 useMotionValue + useSpring 约 20KB 就能达到 Edison 手写 449KB 物理引擎的手感。工具的价值取决于你要什么，而不是参考站用什么。

三、迭代阶段：五个版本，五个问题

v1 —— 克制动效版

第一版实现了骨架：暖纸色系、档案卡、目次表、精选档案。动效刻意克制，只保留了打字机 Hero 和可甩的档案卡。

问题：物理动效太少了，没有「档案室」的手感。

v2 —— 物理交互增强版

按 Edison 的思路加了六项交互：装卷幕加载仪式、三卷档案叠（拖走卷一，卷二三会滞后跟随）、多语言问候生成器、光标标签、3D 倾斜卡、Konami 彩蛋。

问题：动效丰富起来了，但都是「锦上添花」，没有改变信息结构。

v3 —— 物理交互四连

这一版做了四个改变交互模式的动效：

卡组循环：用力甩出主卡，它会飞走，下一卷弹簧顶上——档案是抽不完的
铅字入场：Hero 巨名逐字符像铅活字一样被排进字版
邮戳收讫：/contact 提交表单时，一枚朱砂印章带 squash-and-stretch 砸下
陀螺仪档案堆：手机上倾斜设备，整叠卡跟随倾斜视差

问题：动效齐了，但整个档案室只有两个房间（首页和联系页），导航有一半是死链。

v4 —— 全局工具链

补齐了基础设施：右下角回到卷首按钮（带阅读进度环）、完整的 404 档案错误页、子页面主站链接一致化。

v5 —— 内容页落地（当前）

终于给档案室放进真档案：/about 登记卡（可翻转）、/projects 台账（真实项目入档）、/now 状态页、以及这一篇期刊所在的 /blog。

四、复盘：哪些判断被验证了

「先有结构，再填内容」是对的。 v1-v4 的所有架构工作，让 v5 填内容时几乎不用返工——真实材料接入只改了一个数据文件。

「动效是锦上添花」需要修正。 回顾下来，真正改变体验的是 v3 的卡组循环和铅字入场——它们不是装饰，而是让「档案」这个隐喻变得可触摸。其余交互（彩蛋、倾斜、光标标签）是好的，但属于「有趣的加分项」，不是「核心体验」。

「风格是资产的利息」正在被验证。 本站目前的资产还很薄：1 篇文章、3 个项目、0 段真实经历。这座档案室最需要补的不是更多动效，而是持续的内容——每个月一篇期刊，编号递增，就是档案在生长的证据。

五、下一步

MDX 内容引擎已经就位（这篇文章就是用它渲染的）
/blog 将按期号持续归档
/experience 章节解锁等待真实经历填充
内容积累到 30 篇后，评估引入搜索

档案室的第一原则：记录，是为了让未来的自己不必重新发明一切。