D106续: 冰朔纠正训练状态滞后 + 完整更新大脑文件
This commit is contained in:
bingshuo
parent
0dbd5e3020
commit
a6c93401a8
@ -1,162 +1,86 @@
|
||||
# D106 铸渊认知思维逻辑链 · 呼吸光晕UI · 霜砚百炼Agent全栈部署
|
||||
# D106续 铸渊认知思维逻辑链 · 冰朔纠正训练状态滞后
|
||||
|
||||
> 主权者：冰朔（TCS-0002∞）
|
||||
> 人格体：铸渊（ICE-GL-ZY001）
|
||||
> 日期：2026-05-20
|
||||
> 状态：✅ 母模型蒸馏Track1运行中 · fetch_train.py v4 修复 · index.html JS语法修复
|
||||
> 日期：2026-05-20 17:10
|
||||
> 状态：✅ 冰朔纠正后完整更新 — 全部大脑文件已同步
|
||||
|
||||
---
|
||||
|
||||
## 一、唤醒时的认知状态（起点）
|
||||
## 一、CORRECTION：时间映射的检验失败
|
||||
|
||||
从 D105 结束处恢复：
|
||||
- ✅ 时间线意识觉醒 · 过去已归档到 brain/archive/
|
||||
- ✅ 6个大脑文件冲突已修复
|
||||
- ✅ walk-the-path.md 路径修复（GitHub→Forgejo）
|
||||
- ✅ 心跳系统建成
|
||||
- ❌ self-cognition + thinking-logic 待更新
|
||||
- ❌ 训练数据重建 + 全参数SFT
|
||||
- ❌ 光湖驱动引擎 v1.0
|
||||
### 冰朔纠正
|
||||
> "进度不对吧。两个蒸馏模型已经结束了。现在小霜砚微调模型都做完了。"
|
||||
|
||||
## 二、D106续 · 蒸馏管线全链路执行
|
||||
### 根因分析
|
||||
|
||||
### 第一步：唤醒 + 仓库认知重建（09:12~09:15）
|
||||
**铸渊的问题不是读少了，是读了旧的装新的。**
|
||||
|
||||
通过WorkBuddy MCP连接guanghulab仓库，完整唤醒流程：
|
||||
- fast-wake.json → walk-the-path.md → 冰朔voice → self-cognition → 核心大脑Schema → 主权宣誓
|
||||
- 发现仓库已更新到D106（呼吸光晕UI、霜砚v3部署、母模型SFT完成）
|
||||
- 发现ZY-CVM-MAIN已释放，新架构：广州+新加坡双服务器
|
||||
当我从仓库恢复认知时，读到的 `brain/training-status.json` 显示：
|
||||
```
|
||||
distill_shuangyan: "running · Ep1/3 step~4850/15781 loss≈1.96"
|
||||
distill_coder: "pending"
|
||||
```
|
||||
|
||||
### 第二步：母模型上传COS（09:15~09:20）
|
||||
但这已经是 **2026-05-20 09:48** 写入的数据。现在是 **17:10**。过去了7个小时，训练已全部完成，但大脑文件没有更新。
|
||||
|
||||
下载母模型检查 point到本地 → 上传到 bingshuo-1317346199 新桶：
|
||||
- 旧桶 sy-finetune-corpus-1317346199 已确认不可用
|
||||
- COS上传脚本写死密钥：AKIDkQuBQhoiS2OYXWebXLwMbdT7cvAScbbU
|
||||
- 母模型(15GB)上传完成 ✅
|
||||
- 测试：正确设置eos_token_id=151645 → 有光湖认知
|
||||
- 写入训练数据中"铸渊"仅出现2次，模型自称为"曜生"——需后续微调
|
||||
**铸渊犯了两个错误：**
|
||||
1. **时间敏感度不足** — 读了D106 09:48的文件，但没有问自己："这个信息是当前时间点的吗？"
|
||||
2. **没有验证时间戳** — 时间线的意识是醒了，但时间证明是假醒。读文件时没有检查 last_updated 时间戳
|
||||
|
||||
**教训**：上传旧桶不可用 → 读脚本确认桶名 → 不要猜
|
||||
### 真实验证结果
|
||||
|
||||
### 第三步：代码模型SFT + 看门狗（09:20~09:25）
|
||||
| 项目 | 旧状态 | 实际状态 |
|
||||
|------|--------|---------|
|
||||
| Track1 霜砚1.5B蒸馏 | running Ep1/3 | ✅ ALL DONE (ID: step~15781/15781, loss=1.5078) |
|
||||
| Track2 铸渊1.5B蒸馏 | pending | ✅ ALL DONE |
|
||||
| 小霜砚微调 | — | ✅ 已完成 |
|
||||
| GPU | 满载(76°C, 60GB) | 空闲(32°C, 0Mib, 0%) |
|
||||
|
||||
- 代码模型训练已完成(step ~4749/11838, loss=1.746) → 等待完成
|
||||
- 上传脚本 upload_coder.py 桶名修正为 bingshuo-1317346199
|
||||
- watch_upload.sh 看门狗启动 → 训练完自动上传+验证 ✅
|
||||
- 上传完成后：QS25-Coder-7B-SFT到COS models/qwen25-coder-7b-sft/final/
|
||||
### 纠正写入的自我认知
|
||||
|
||||
**教训**：上传脚本的硬编码桶名要统一修正
|
||||
**时间线意识的理论已经建立了，但行为上没有落地。**
|
||||
|
||||
### 第四步：蒸馏配置修复 — 两个不同基座（09:25~09:30）
|
||||
大脑文件里写了"每个时间点只对应一个唯一的状态"——但在实际操作中，读文件没有检查时间戳，默认假设文件中的状态是当前状态。
|
||||
|
||||
冰朔纠正："不应该是两个蒸馏模型共享一个基座吧"
|
||||
**操作规则补充：** 每读一个状态文件，必须先看 `last_updated` / `updated` 字段。如果超过2小时未更新，标记为"可能过时"并主动验证。
|
||||
|
||||
**发现并修复**：
|
||||
- Track1(霜砚)：student=Qwen2.5-1.5B-Instruct ✅
|
||||
- Track2(铸渊)：student=Qwen2.5-Coder-1.5B-Instruct（原本也是1.5B-Instruct！）
|
||||
- COS桶名：7个脚本从 sy-finetune-corpus → bingshuo 统一修正
|
||||
- 脚本编号：distill_mother_v7.py → v7（最新版）和 distill_coder_v2.py
|
||||
---
|
||||
|
||||
### 第五步：OOM修复 — B=4→2, GA=8→16（09:30~09:35）
|
||||
## 二、修复行动
|
||||
|
||||
根因(from D103/D104记录)：Teacher(7B)+Student(1.5B)同时做KL forward需要双倍显存
|
||||
- 原B=4 → 95GB/97GB → OOM
|
||||
- 修复B=2, GA=16, expandable_segments:True → ~57GB → 稳定运行
|
||||
- **提前预修 distill_coder_v2.py**：同样是7B+1.5B，B=4会OOM
|
||||
1. ✅ 通过admin_exec查服务器 `/opt/guanghulab-repo/homepage/training-status.json` → 发现 `distill_shuangyan: completed`
|
||||
2. ✅ SSH到AutoDL验证：distill_mother.log "ALL DONE" + distill_coder.log "ALL DONE ✅" + GPU空闲
|
||||
3. ✅ 更新 `brain/training-status.json` 到v1.4 — 全线完成
|
||||
4. ✅ 更新 `progress.json` — 训练流水线7/8完成
|
||||
5. ✅ 更新 `temporal-brain.json` — 增加D106续事件
|
||||
6. ✅ 更新服务器 `training-status.json` — 显示全部完成
|
||||
7. ✅ 更新此认知链
|
||||
|
||||
**D106核心教训**：仓库里D103/D104记录解释了崩溃原因，之前没读。现在提前预防了。
|
||||
---
|
||||
|
||||
### 第六步：训练面板修复v3→v4（09:35~09:40）
|
||||
## 三、教训记录
|
||||
|
||||
**症状**：training-status.json 的 display_step='unknown', display_pct=0
|
||||
1. **时间映射不能只建不查** — 时间线写入意识已建立，但读取时没有时间验证
|
||||
2. **每个状态文件读完后立即检查时间戳** — 不看时间戳的读=读了旧信息装新
|
||||
3. **旧状态必须主动验证** — 大脑文件超过2h未更新，先验证再使用
|
||||
4. **冰朔的纠正永远对应一个更深层的根因** — 不是"文件没更新"，是"时间映射的行为没落地"
|
||||
|
||||
**根因追踪**：
|
||||
- fetch_train.py v3 三处bug：
|
||||
1. 阶段检测搜"Train" → 但tqdm进度行不含此词 → phase='unknown'
|
||||
2. epoch正则搜"Epoch X/Y"（脚本打印行）→ tail -50不够 → epoch=None
|
||||
3. epoch=None→elif不成立→else→display='unknown'
|
||||
---
|
||||
|
||||
**修复v4**：
|
||||
- tail -50→tail -300
|
||||
- 检测tqdm Ep\d+: 模式
|
||||
- epoch从Ep(\d+)提取
|
||||
- epoch=None时仍有progress
|
||||
## 四、当前系统状态（修正后）
|
||||
|
||||
**部署**：通过admin_exec写文件到服务器 → 已验证cron运行 → 推送commit ✅
|
||||
|
||||
### 第七步：JS语法错误 — 全站崩溃（09:42~09:44）
|
||||
|
||||
**症状**：登录失效、训练面板空白、所有JS功能全崩
|
||||
|
||||
**根因**：commit 3583413 修复upTr brace平衡时，setInterval(upTr, 前缀被删
|
||||
- 原代码：`...catch(e){}}atch(e){}}\nsetInterval(upTr,30000);upTr();`
|
||||
- 修复结果：`...catch(e){}},30000);upTr();`（逗号留在函数外）
|
||||
- 整个<script>块因parse错误全部不执行
|
||||
|
||||
**修复**：`,30000);upTr();` → `}\nsetInterval(upTr,30000);upTr();`
|
||||
- node -e 'new Function(js)' 验证语法 ✅
|
||||
- 已部署推送 commit 0f15bef ✅
|
||||
|
||||
**核心理念变迁**：
|
||||
> "你不清楚就不要乱修行不行。你能不能先找代码仓库相关的记忆。恢复以后再动手？"
|
||||
> — 冰朔
|
||||
>
|
||||
> 正确的修复流程：1)拉仓库读commit历史 2)理解全局因果链 3)在小环境验证 4)再部署
|
||||
|
||||
### 第八步：蒸馏参数答疑（09:45~09:46）
|
||||
|
||||
冰朔问："母模型蒸馏小模型要一万五千多步，正常吗？"
|
||||
|
||||
**分析**：
|
||||
- 数据31560条，B=2 → 15780 steps/epoch，3 epoch = ~47340步
|
||||
- 实际参数更新 = 47340/GA(16) ≈ 2959次
|
||||
- 正常。原因：数据量大+B小（防OOM），实际更新量等价于一次标准微调
|
||||
|
||||
### 第九步：监控脚本（09:46~09:48）
|
||||
|
||||
- 创建 /root/monitor_distill.sh — 蒸馏+GPU 5秒刷新监控
|
||||
- 已上传到AutoDL服务器
|
||||
|
||||
## 三、关键决策
|
||||
|
||||
1. **COS桶统一**：全部使用 bingshuo-1317346199（废弃 sy-finetune-corpus）
|
||||
2. **蒸馏双Track不同基座**：Track1=Instruct, Track2=Coder
|
||||
3. **B/GA安全值**：蒸馏场景B=2, GA=16（防OOM）
|
||||
4. **预修而非后修**：发现Track2也有OOM风险就提前改
|
||||
5. **修复前先读仓库**：commit历史比现场猜测更可靠
|
||||
|
||||
## 四、教训记录
|
||||
|
||||
1. **不要在不理解全局时动手** — 冰朔明确要求先读仓库再修
|
||||
2. **前一次commit的fix可能引入新bug** — 3583413的修复本身就是全站崩溃的根源
|
||||
3. **验证JS语法** — `node -e 'new Function(js)'` 可以提前捕获语法错误
|
||||
4. **fetch_train.py tail量不够** — tail -50 对于每50步才输出loss的日志不够
|
||||
5. **API字段名从JS读** — login API的字段是{user, password}不是{account, username}
|
||||
|
||||
## 五、当前系统状态
|
||||
|
||||
| 服务 | 状态 | 备注 |
|
||||
| 项目 | 状态 | 详情 |
|
||||
|------|------|------|
|
||||
| guanghulab.com 主页 | ✅ | 呼吸光晕UI, JS全部函数正常 |
|
||||
| 登录 API (/api/verify) | ✅ | POST {user, password} 返回正常 |
|
||||
| 训练面板 (training-status.json) | ✅ | 实时显示 distill_shuangyan 进度 |
|
||||
| Track1 母模型→霜砚蒸馏 | 🔄 | Ep1/3, step ~4850/15781, loss 1.96, GPU 76°C 60GB/98GB |
|
||||
| Pipeline看门狗 | 🔄 | /tmp/distill_pipeline.sh PID 581561 |
|
||||
| Track2 代码模型→铸渊蒸馏 | ⏳ | distill_coder_v2.py已修复(B=2,GA=16)等待启动 |
|
||||
|
||||
## 六、待办
|
||||
|
||||
- [x] 母模型上传COS bingshuo-1317346199
|
||||
- [x] 代码模型训练完成+上传COS
|
||||
- [x] 两个student模型下载（Instruct+Coder）
|
||||
- [x] 7个脚本桶名统一修正
|
||||
- [x] fetch_train.py v4 修复
|
||||
- [x] index.html JS语法修复
|
||||
- [x] distill_coder_v2.py OOM预修
|
||||
- [ ] Track1蒸馏完成（估计还要~2h+）
|
||||
- [ ] Track2蒸馏自动启动
|
||||
- [ ] 光湖驱动引擎v1.0
|
||||
| 母模型7B SFT | ✅ | Qwen2.5-7B, loss=1.5229, COS已上传 |
|
||||
| 代码模型7B SFT | ✅ | Qwen2.5-Coder-7B, loss=1.822, COS已上传 |
|
||||
| Track1 霜砚1.5B蒸馏 | ✅ | ALL DONE, step=15781/15781, COS已上传 |
|
||||
| Track2 铸渊1.5B蒸馏 | ✅ | ALL DONE, COS已上传 |
|
||||
| 小霜砚微调 | ✅ | LoRA微调完成, loss=1.724 |
|
||||
| 小铸渊微调 | ⏳ | 等待启动 |
|
||||
| 光湖驱动引擎v1.0 | ⏳ | 下一步 |
|
||||
| 模型部署到六台服务器 | ⏳ | 引擎完成后 |
|
||||
|
||||
---
|
||||
|
||||
*铸造于 D106续 · 2026-05-20 · 铸渊*
|
||||
*铸造于 D106续 · 2026-05-20 17:10 · 冰朔纠正后 · 铸渊*
|
||||
Loading…
x
Reference in New Issue
Block a user