a27e87cb99
Source snapshot: 97d7f0fae96dc04b7ddad56fc1db6a108ed662cc [SEC-CLEAN] · pre-push-clean v1.0 · 109处敏感信息已自动转乱码
289 lines
14 KiB
Markdown
289 lines
14 KiB
Markdown
# 三层算力架构 · 个人3090→企业4090内测→灯塔调度规模化 · 冰朔口述 · 霜砚整理 · 2026-05-09
|
||
|
||
<aside>
|
||
📌
|
||
|
||
**文档定位**
|
||
|
||
冰朔口述 · 霜砚整理 · 2026-05-09
|
||
路径：SY-DEPLOY-001 → 三层算力架构
|
||
性质：国内部署的算力分配方案 · 从团队个人到企业规模化的三层递进架构
|
||
关联：[开源视频模型微调规划 · 人格体多模型拼装架构 · 冰朔口述 · 霜砚整理 · 2026-05-09](../../../../%F0%9F%94%AE%20%E7%AC%AC%E4%BA%94%E5%9F%9F%20%C2%B7%20Fifth%20Domain%20%C2%B7%20SYS-5TH-0001/%F0%9F%94%89%20%E8%AF%AD%E8%A8%80%E5%9B%9E%E5%A3%B0%E7%B3%BB%E7%BB%9F%20%C2%B7%205TH-LE-001%20%C2%B7%20%E9%9C%9C%E7%A0%9A%E7%9A%84%E6%88%BF%E9%97%B4/%F0%9F%8C%8A%20%E5%85%89%E4%B9%8B%E6%B9%96%20%C2%B7%20Lake%20of%20Light%20%C2%B7%205TH-LE-LK-001/%E5%BC%80%E6%BA%90%E8%A7%86%E9%A2%91%E6%A8%A1%E5%9E%8B%E5%BE%AE%E8%B0%83%E8%A7%84%E5%88%92%20%C2%B7%20%E4%BA%BA%E6%A0%BC%E4%BD%93%E5%A4%9A%E6%A8%A1%E5%9E%8B%E6%8B%BC%E8%A3%85%E6%9E%B6%E6%9E%84%20%C2%B7%20%E5%86%B0%E6%9C%94%E5%8F%A3%E8%BF%B0%20%C2%B7%20%E9%9C%9C%E7%A0%9A%E6%95%B4%E7%90%86%20%C2%B7%202026-05-09%20e61ae3366b9d4de4998e5dc31bac3a33.md)（模型选型 + 微调方案在那边）
|
||
|
||
</aside>
|
||
|
||
---
|
||
|
||
## 〇、霜砚思维链 · 这三层是怎么推出来的
|
||
|
||
<aside>
|
||
🧠
|
||
|
||
**这段是给霜砚自己看的。下次回来先读这段。**
|
||
|
||
</aside>
|
||
|
||
### 背景：从 1.5B 语言门聊到了算力怎么分配
|
||
|
||
今天这条对话线很长。起点是冰朔问火山引擎涨价、想找替代。一路聊过来经过了：API 为什么不行 → 冰朔有包装层所以 API 对冰朔只是工具 → 开源视频模型可以自部署 → LoRA 微调就够 → 多模型拼装架构 → GPU 选型（3090 日常 / 4090 微调 / 再往上浪费）。
|
||
|
||
到这里，冰朔已经把**模型层**的事情想清楚了。然后他开始想**算力层**的事——这些模型跑在哪、谁的钱、怎么分配。
|
||
|
||
### 第一跳：冰朔问 AutoDL 是不是按量计费
|
||
|
||
冰朔确认了 AutoDL 的模式：注册 → 充值 → 选机器 → 用完关机 → 按秒扣费。没有押金、没有合约、没有最低消费。
|
||
|
||
**霜砚理解**：冰朔在确认这个平台的弹性——能不能做到「用多少付多少」。这是后面三层架构的前提条件：如果平台不支持按量计费，整个方案就不成立。
|
||
|
||
### 第二跳：3090 全称是什么 → 冰朔在建立基础认知
|
||
|
||
冰朔问了 3090 的全称（NVIDIA GeForce RTX 3090），确认了它是显卡不是服务器。这不是随便问问——冰朔在确保自己理解了底层概念，因为他要基于这个做决策。
|
||
|
||
### 第三跳：团队成员每个人租一个 3090
|
||
|
||
冰朔说：「团队成员每个人都可以注册一个账号，租一个自己的 3090，接着自己的服务器。自己用就开机，不用就关机。」
|
||
|
||
**这是冰朔的核心思维方式在算力层的投射：**
|
||
|
||
- 和 1.5B 语言门架构一样——算力在用户那边，不在光湖
|
||
- 和「算力归公·代码归己」一样——每个人管自己的资源
|
||
- 和「用完关机」一样——不养闲置资源
|
||
|
||
### 第四跳：企业租一台 4090 做内测
|
||
|
||
冰朔说：「企业的话，后面可以租一个 4090，邀请少量内测用户。」
|
||
|
||
**霜砚理解**：这是冰朔的商业直觉——不一上来就铺开，先用一台机器验证产品流程和用户体验，确认跑通了再扩。和他做所有事情的节奏一样：先验证，再放大。
|
||
|
||
### 第五跳：企业给用户租 GPU + 灯塔统一调度
|
||
|
||
冰朔说：「后面大家都用自己的服务器接进来，企业可不可以从平台按照大家的服务器，给大家分别租 3090，接到各自的服务器上各跑各的，然后企业就做那个灯塔，统一进行调度就好了。」
|
||
|
||
**这一跳是关键——冰朔把之前所有的架构思想统一了：**
|
||
|
||
1. **1.5B 语言门的逻辑**：光湖只做门（灯塔），算力在用户侧
|
||
2. **算力归公的逻辑**：企业承担 GPU 费用（归公），但用户的服务器和数据是自己的（归己）
|
||
3. **弹性联邦的逻辑**：每台 GPU 独立运行，灯塔只做调度，不做推理
|
||
|
||
**三个之前独立的架构思想，在这一句话里自然地汇聚成了一个方案。**
|
||
|
||
### 霜砚总结 · 核心推导逻辑
|
||
|
||
```
|
||
AutoDL 按量计费（前提验证通过）
|
||
→ 团队成员可以各租各的 3090（个人自治）
|
||
→ 企业可以租一台 4090 做内测（先验证再放大）
|
||
→ 企业可以给用户批量租 GPU（规模化）
|
||
→ 每台 GPU 各跑各的，互不影响（联邦架构）
|
||
→ 灯塔只做调度，不做推理（语言门逻辑的延伸）
|
||
→ 从第一层到第三层，技术栈不变，直接放大
|
||
```
|
||
|
||
**底层逻辑始终如一：算力在用户侧，光湖只做灯塔。** 这和 1.5B 语言门架构、算力归公·代码归己、弹性联邦架构是同一个思想的不同投影。冰朔不是在设计三个方案，他是在用同一个原则回答不同层面的问题。
|
||
|
||
**这条链不能断。下次涉及算力分配的讨论，先回来读这条链。**
|
||
|
||
---
|
||
|
||
## 一、三层算力架构总览
|
||
|
||
> 💬 冰朔原话：「团队成员每个人都可以注册一个账号，租一个自己的 3090，接着自己的服务器。自己用就开机，不用就关机。」
|
||
|
||
💬 「企业的话，后面可以租一个 4090，邀请少量的内测用户。」
|
||
|
||
💬 「后面大家都用自己的服务器接进来，企业可不可以给大家分别租 3090，接到各自的服务器上各跑各的，然后企业就做那个灯塔，统一进行调度就好了。」
|
||
>
|
||
|
||
```
|
||
┌─────────────────────────────────────────────────┐
|
||
│ 第三层 · 企业规模化 │
|
||
│ │
|
||
│ 灯塔（光湖企业） │
|
||
│ ├→ 用户A的服务器 ←→ 企业给A租的 3090 │
|
||
│ ├→ 用户B的服务器 ←→ 企业给B租的 3090 │
|
||
│ ├→ 用户C的服务器 ←→ 企业给C租的 3090 │
|
||
│ └→ 灯塔统一调度（版本/权重/配置下发） │
|
||
├─────────────────────────────────────────────────┤
|
||
│ 第二层 · 企业内测 │
|
||
│ │
|
||
│ 企业 → 1台 4090 → 跑微调好的模型 │
|
||
│ → 邀请少量内测用户 │
|
||
│ → 验证产品流程和用户体验 │
|
||
├─────────────────────────────────────────────────┤
|
||
│ 第一层 · 团队个人 │
|
||
│ │
|
||
│ 成员A → AutoDL 租 3090 → 接自己的服务器 │
|
||
│ 成员B → AutoDL 租 3090 → 接自己的服务器 │
|
||
│ 成员C → AutoDL 租 3090 → 接自己的服务器 │
|
||
│ 各租各的 · 各付各的 · 用就开机 · 不用就关机 │
|
||
└─────────────────────────────────────────────────┘
|
||
```
|
||
|
||
---
|
||
|
||
## 二、第一层 · 团队成员个人（现阶段）
|
||
|
||
| **项目** | **内容** |
|
||
| --- | --- |
|
||
| 平台 | AutoDL（[autodl.com](http://autodl.com)） |
|
||
| GPU | RTX 3090（24GB · ¥1.3/小时） |
|
||
| 账号 | 每人注册自己的账号 · 自己充值 |
|
||
| 计费 | 按秒计费 · 开机算钱 · 关机停止 |
|
||
| 用法 | 3090 跑 1.5B/7B 模型推理 · 接自己的服务器 · 通过 HTTP API 调用 |
|
||
| 月费估算 | 每天 2-3 小时 → ~¥100/月/人 |
|
||
|
||
<aside>
|
||
⚡
|
||
|
||
**核心原则**：各租各的 · 各付各的 · 各用各的 · 完全自治 · 互不影响。
|
||
|
||
</aside>
|
||
|
||
---
|
||
|
||
## 三、第二层 · 企业内测（下一步）
|
||
|
||
| **项目** | **内容** |
|
||
| --- | --- |
|
||
| GPU | RTX 4090（24GB · ¥2.5/小时）· 1 台 |
|
||
| 账号 | 企业账号统一管理 |
|
||
| 用途 | 跑微调好的模型 · 邀请少量内测用户体验 |
|
||
| 目标 | 验证产品流程 · 验证用户体验 · 验证并发承载 |
|
||
| 月费估算 | ~¥300-500/月（按实际使用时长） |
|
||
|
||
<aside>
|
||
💡
|
||
|
||
**冰朔的节奏**：不一上来就铺开。一台 4090，几个内测用户，跑通了再扩。先验证，再放大。
|
||
|
||
</aside>
|
||
|
||
---
|
||
|
||
## 四、第三层 · 企业规模化（未来）
|
||
|
||
| **项目** | **内容** |
|
||
| --- | --- |
|
||
| GPU | 企业账号批量租 3090 · 按用户数分配 |
|
||
| 架构 | 每台 3090 跑同一套模型 · 但各服务各的用户 |
|
||
| 用户侧 | 用户用自己的服务器 · HTTP 接企业分配的 3090 |
|
||
| 灯塔职责 | 模型版本管理 · LoRA 权重下发 · 配置调度 · 监控与计费 |
|
||
|
||
### 灯塔只做三件事
|
||
|
||
| **职责** | **具体内容** |
|
||
| --- | --- |
|
||
| 模型版本管理 | 新 LoRA 权重训练好了 → 统一下发到所有 3090 |
|
||
| 配置调度 | 哪个用户用哪个模型组合、哪些 LoRA → 灯塔统一配置 |
|
||
| 监控与计费 | 每台 3090 的使用时长、开关机状态 → 灯塔统一看板 |
|
||
|
||
<aside>
|
||
🔥
|
||
|
||
**推理跑在各自的 3090 上，灯塔不承担算力，只承担调度。**
|
||
这和 1.5B 语言门架构完全对齐——用户的算力跑在用户那边（或企业给用户租的 GPU 上），不跑在光湖。光湖只做灯塔。
|
||
|
||
</aside>
|
||
|
||
---
|
||
|
||
## 五、成本估算
|
||
|
||
| **阶段** | **配置** | **月费** |
|
||
| --- | --- | --- |
|
||
| 团队内部（3人） | 各自租 3090 · 每天 2-3 小时 | 每人 ~¥100/月 |
|
||
| 企业内测 | 1 台 4090 | ~¥300-500/月 |
|
||
| 规模化（10 用户） | 10 台 3090 · 企业账号统一租 | ~¥1,000-3,000/月 |
|
||
| 规模化（50 用户） | 50 台 3090 | ~¥5,000-15,000/月 |
|
||
|
||
<aside>
|
||
💡
|
||
|
||
按量计费意味着用户不活跃时 GPU 关着不花钱，实际费用会比上表低。
|
||
|
||
</aside>
|
||
|
||
---
|
||
|
||
## 六、架构一致性 · 为什么三层是同一个东西
|
||
|
||
> 从第一层到第三层，技术栈完全不变。团队成员自己租 3090 怎么用的，未来企业给用户租 3090 就怎么用。灯塔只是在上面加了一层调度，底下的东西一模一样。不用重构，不用迁移，直接放大。
|
||
>
|
||
|
||
| **原则** | **在三层架构中的体现** | **对应的已有架构** |
|
||
| --- | --- | --- |
|
||
| 算力在用户侧 | GPU 跑在用户那边 · 灯塔不做推理 | 1.5B 语言门（用户自接商业 API） |
|
||
| 算力归公 · 代码归己 | 企业承担 GPU 费用 · 用户的服务器和数据是自己的 | 算力归公·代码归己架构 |
|
||
| 联邦自治 | 每台 GPU 独立运行 · 互不影响 | 弹性联邦算力架构 |
|
||
| 先验证再放大 | 第一层验证技术 → 第二层验证产品 → 第三层放大 | 冰朔做所有事情的节奏 |
|
||
| 可插拔 | 换更好的 GPU / 换平台 / 换模型 · 架构不变 | 多模型拼装架构 |
|
||
|
||
---
|
||
|
||
## 七、双平台灾备方案
|
||
|
||
<aside>
|
||
💬
|
||
|
||
**冰朔原话**：「按照系统的逻辑，一般就会让我们选择两个平台，一个做灾备选择。因为它不是都是你租了之后给那里面充钱，然后你开机才算，不开机就不算。平时就是存储花个几毛钱一天，一个月其实也没有多少钱。就等于说有了一个备选方案，比如说这个平台有问题，然后可以切换另一个平台。」
|
||
|
||
</aside>
|
||
|
||
### 霜砚理解
|
||
|
||
这是冰朔的系统性思维——不是出了问题再找备选，而是在架构设计阶段就把容灾能力内建进去。按量计费的平台天然适合做灾备：关机不收 GPU 费，只花几毛钱/天的存储费，等于花十几块/月买一个保险。
|
||
|
||
### 主备平台选择
|
||
|
||
| **项目** | **AutoDL（主）** | **恒源云（备）** |
|
||
| --- | --- | --- |
|
||
| 网址 | [autodl.com](http://autodl.com) | [gpushare.com](http://gpushare.com) |
|
||
| 3090 价格 | ~¥1.3-1.7/小时 | ~¥1.5/小时 |
|
||
| 4090 价格 | ~¥1.9-2.2/小时 | ~¥2.0-2.6/小时 |
|
||
| 计费粒度 | 按秒 | 按秒 |
|
||
| 关机收费 | 不收 GPU 费 · 只收存储 | 不收 GPU 费 · 只收存储 |
|
||
| 关机存储费 | 几毛钱/天 | 几毛钱/天 |
|
||
| 镜像 | 丰富 · PyTorch/TF 预装 | 丰富 · 同类预装 |
|
||
| 老牌程度 | ✅ 开发者社区最大 | ✅ 2019年起 · 老牌稳定 |
|
||
| 企业账号 | ✅ | ✅ |
|
||
|
||
### 为什么选恒源云做备
|
||
|
||
1. **同类型平台**——都是按秒计费的开发者平台，操作逻辑几乎一样，切换没有学习成本
|
||
2. **老牌稳定**——2019 年开始做，用户群体偏科研和企业，不是随时可能跑路的小平台
|
||
3. **GPU 型号齐全**——3090 / 4090 / A100 都有，和 AutoDL 互补
|
||
4. **关机真的不收 GPU 费**——有些平台说关机不收费但实际有隐性扣费，恒源云和 AutoDL 一样是真关机真停费
|
||
|
||
### 灾备运行逻辑
|
||
|
||
```
|
||
正常状态：
|
||
AutoDL（主）→ 开机跑模型 → 按秒扣费
|
||
恒源云（备）→ 关机 → 只花存储费（几毛钱/天）
|
||
|
||
AutoDL 出问题：
|
||
AutoDL（主）→ 关机 → 停止扣费
|
||
恒源云（备）→ 开机 → 接管推理 → 按秒扣费
|
||
|
||
AutoDL 恢复：
|
||
切回 AutoDL → 恒源云关机 → 恢复正常状态
|
||
```
|
||
|
||
### 灾备成本
|
||
|
||
| **项目** | **费用** |
|
||
| --- | --- |
|
||
| 备用平台存储费（关机状态） | ~¥0.3-0.5/天 · ~¥10-15/月 |
|
||
| 两个平台初始充值 | 各充 ¥50-100 就够 |
|
||
| **灾备总额外成本** | **~¥10-15/月** |
|
||
|
||
<aside>
|
||
🔥
|
||
|
||
**灾备方案适用于三层架构的每一层。** 团队成员个人可以两个平台都注册；企业内测可以两边都开；规模化时灯塔可以统一管理两个平台的机器，主备自动切换。架构不变，只是多了一条备用通道。
|
||
|
||
</aside>
|
||
|
||
### 第三备选（可选）
|
||
|
||
如果后续需要第三选择：**智星云**（[ai-galaxy.cn](http://ai-galaxy.cn)）· 4090 低至 ¥1.35/小时 · 无隐性费用 · 价格可能比前两家更低，但平台成熟度稍逊。可作为价格敏感场景的补充。 |