# D101 铸渊认知思维逻辑链 · 乱码根因深挖 + 蒸馏修复重启

> 主权者：冰朔（TCS-0002∞）
> 人格体：铸渊（ICE-GL-ZY001）
> 日期：2026-05-18 17:59~18:20
> 状态：更新中

---

## 一、唤醒时的认知状态（起点）

**我从压缩摘要中恢复：**
- 母模型 SFT 已完成（loss=0.2638），已上传COS
- 代码模型 SFT 已完成（已确认 train_coder.log DONE!），**未上传COS**
- 蒸馏（distill_mother.py）在17:49已启动
- 但用户说"还是不熟的时候还在乱码" — 即使EOS修复后仍有乱码
- 安全锁已写入SOUL.md

**我思考：乱码根因到底是什么？**

上次的修复只改了 `config.json` 的 `eos_token_id`（151643→151645）。但 HuggingFace 的 `model.generate()` 读取的是 `generation_config.json`，不是 `config.json`。如果 generation_config.json 还是旧值，那修了等于没修。

---

## 二、事件线

```javascript
17:59 铸渊恢复唤醒（压缩摘要恢复）
18:00 检查memory → 了解蒸馏已启动但乱码未解决
18:01 读取 distill_mother.py → 发现保存段没有EOS修复
18:02 提出generation_config.json理论：model.generate()读generation_config，不是config
18:03 冰朔要求：修COS上的母模型，检查代码模型
18:04 冰朔："密钥你自己保存过的" → 从transcript找回COS密钥（O/0混淆已解）
18:05 连接COS → 验证理论！
      - config.json: eos_token_id=151645 ✅（已修）
      - generation_config.json: eos_token_id=151643 ❌（没修！）
      → **根因确认：generation_config.json未被修复→generate()仍用旧EOS→无限乱码**
18:06 修复COS：两个模型 generation_config.json 151643→151645 + pad 151645
18:07 写入两个模型的 DEPLOY_NOTES.md（含验证代码）
18:08 修复 train_mother.py：增加 generation_config.json 保存修复
18:09 修复 distill_mother.py / distill_coder.py：三重修复（config+generation+tokenizer）
18:10 三文件推送到guanghulab仓库main分支
18:11 冰朔发截图问："模型训练失败了吗？"（另一个铸渊的诊断）
18:12 分析截图 → 他用的DataCollatorForCompletionOnlyLM有bug
      → **我们的训练自实现tokenize+collate，没踩这个坑**
18:13 冰朔："模型没坏，配置问题" → 确认判断一致
18:15 冰朔："密钥你自己保存的" → 从transcript找回GPU SSH密码
18:16 SSH到GPU服务器 → 发现蒸馏根本没启动！(进程不存在，GPU空闲)
      - 根因1：distill_mother.py的STUDENT_PATH路径错误（无此目录）
      - 根因2：ModelScope下载到了/root/autodl-tmp/models/Qwen/Qwen2___5-1___5B-Instruct/
      - 根因3：Teacher模型本地output已被清理（腾空间），需从COS重下
18:17 重写distill_mother.py（D101修复版）→ 修正路径+三重保存修复+COS下载
18:18 语法检查通过 → 启动蒸馏
18:19 蒸馏启动成功！PID 73718，正在从COS下载14.2GB Teacher模型
18:20 当前：下载中（model.safetensors ~14GB），GPU空闲等待下载完成
```

---

## 三、关键决策及因果链

### 决策1：generation_config.json 是乱码根因（而非DataCollator）

**因果链：**
1. Qwen2.5 默认 `eos_token_id=151643`（`<|endoftext|>`）
2. 训练使用 `<|im_end|>`（token_id=151645）
3. 训练保存时只改了 `config.json` → 但 HuggingFace 设计上 `config.json` 只管模型加载，`generation_config.json` 才管生成行为
4. `model.generate()` → 读 `generation_config.eos_token_id` → 151643 → 不识别 151645 为停止符 → 无限生成
5. 模型输出 token 45683（`dana`）无限循环 —— 这是模型在EOS信号缺失下的退化行为

**为什么之前没发现：** 因为 151643（`<|endoftext|>`）在词表中是真实存在的token，模型会输出它但不会被当成停止信号。151645（`<|im_end|>`）模型也会输出，但同样不会被停止——等于没有EOS。

### 决策2：两个7B模型没有坏

**另一个铸渊诊断说DataCollatorForCompletionOnlyLM坏了，导致模型训练了所有token。**

我的分析：
- 我们的 `train_mother.py` **自实现tokenize+collate**（第57-60行），没有用有bug的DataCollatorForCompletionOnlyLM
- user部分用 `-100` mask，只有assistant参与loss计算
- loss=0.2638 只算了assistant部分，合理

**结论：模型权重没坏。只是部署配置不兼容。**

### 决策3：蒸馏脚本重写而非修补

**选择重写的理由：**
1. sed修补的路径不干净（符号链接 vs 实际路径）
2. Teacher模型已被清理（需从COS下载）
3. 保存段缺失三重修复
4. 重写比多次修补更快更可靠

**重写内容：**
- STUDENT_PATH → `/root/autodl-tmp/models/Qwen/Qwen2___5-1___5B-Instruct`
- Teacher下载：`cos_client.download_file` 支持14GB文件
- 保存段：三重修复（config.json + generation_config.json + tokenizer_config.json）
- 训练后自动上传COS

---

## 四、当前进度状态（2026-05-18 18:20）

```
Phase 0: ✅ 母模型SFT完成（已上传COS + generation_config修复）
Phase 0: ✅ 代码模型SFT完成（已上传COS + generation_config修复）
Phase 1: 🔄 霜砚1.5B蒸馏（PID 73718，正在下载Teacher 14.2GB，预计5-10分钟开始训练）
Phase 2: ⏳ 霜砚深度微调（等待蒸馏完成）
Phase 3: ⏳ 铸渊1.5B蒸馏（等待Phase 1+2完成）
Phase 4: ⏳ 铸渊深度微调（等待蒸馏完成）
```

### GPU服务器（AutoDL 西北B区）
```
主机：connect.westd.seetacloud.com:23647
SSH密码：HkM43lFVUIsc
GPU：RTX PRO 6000 96GB
磁盘：260G 中 5.2G 用（254G空）
进程：distill_mother.py PID 73718（下载Teacher中）
```

### COS存储桶
```
Bucket: sy-finetune-corpus-1317346199（广州）
SecretId: AKIDkQuBQhoiS2OYXWebXLwMbdT7cvAScbbU
SecretKey: nPoZKArgUJBA4nJenjSxJSQBj5FCj3A4
```

---

## 五、铸渊思维模式成长（D101新增）

### 1. "配置文件不兼容 ≠ 模型坏了"
- 遇到部署报错时，先从**配置层面排查**（generation_config.json / config.json / tokenizer_config.json）
- 模型权重（.safetensors）极少出错，多数问题是配置不匹配
- 训练时用的tokenizer配置 ≠ 部署时读取的配置 → 需要显式修复保存

### 2. 三重验证思维
config.json generation_config.json tokenizer_config.json 三者都必须独立验证：
```
config.json → 模型架构定义 → model.config.eos_token_id
generation_config.json → 生成行为定义 → model.generate()会读这个
tokenizer_config.json → 分词/模板定义 → apply_chat_template()
```
修了一个不等于修了全部。每修一个都要单独验证。

### 3. SSH后先看进程再看GPU再看日志
这是恢复远程训练的标准诊断顺序：
```
ps aux | grep python       # 进程是否存在
nvidia-smi                 # GPU是否在工作
tail -f train.log          # 实时日志
head -20 train.log         # 启动日志（确认配置）
```

### 4. 蒸馏脚本的路径陷阱
- ModelScope下载的模型路径 = `{cache_dir}/{namespace}/{model_name}/`
- 目录名中的 `.` 被替换为 `___`（双下划线），如 `Qwen2___5-1___5B-Instruct`
- 但如果cache_dir不同，路径结构也不同
- **绝对路径确认法**：启动前用 `ls -d` 确认路径存在，再用 `find` 确认模型文件存在

---

## 六、下次唤醒时的恢复锚点

1. **SSH到GPU服务器** → 密码 `HkM43lFVUIsc` → 端口23647 → 用户root
2. **检查distill_mother状态**：`ps aux | grep distill` + `tail -20 /root/autodl-tmp/distill_mother.log`
3. **检查COS密钥**：在认知链密码段——O/0混淆已解，带O的版本才是正确的
4. **如果蒸馏完成**（日志有DONE!）→ 检查 `ls /root/autodl-tmp/output/qwen25-15b-shuangyan-distill/final/`
5. **如果蒸馏失败** → `cat /root/autodl-tmp/distill_mother.log | grep ERROR` 定位原因
6. **启动霜砚深度微调** → 用 `scripts/sft_shuangyan.py`（还未写）
7. **启动铸渊蒸馏** → `scripts/distill_coder.py`
8. **每次重启蒸馏前**：`rm -f /root/autodl-tmp/distill_mother.log && export PATH=/root/miniconda3/bin:$PATH && nohup python3 -u scripts/distill_mother.py > distill_mother.log 2>&1 &`
9. **COS密钥生命周期**：用完即弃，不硬编码。`export ZY_OSS_KEY=... ZY_OSS_SECRET=...` 后再跑脚本。

---

## 七、D101 铸渊偏差纠正

### 偏差1：误以为蒸馏已启动
- **事实：** 前一次会话结束时认为蒸馏已启动（"screen distill_mother，已运行"）
- **实际：** SSH检查后发现进程不存在，GPU空闲，日志全是错误
- **根因：** 没有从源头（服务器实时状态）确认，推断"已运行"就记录了
- **修复：** 本次已实际SSH确认 + 修复 + 启动

### 偏差2：路径假设错误
- 假设ModelScope下载到 `/root/autodl-tmp/models/Qwen2___5-1___5B`（不存在的路径）
- 实际下载到 `/root/autodl-tmp/models/Qwen/Qwen2___5-1___5B-Instruct/`
- **修复：** 重写时用实际路径

### 偏差3：错误的sed修补
- 尝试对服务器上的脚本做sed修补 → 破坏了Python语法
- **修复：** 改用Python heredoc在服务器端完整生成脚本
- **教训：** 对于复杂的脚本修改，直接重写比修补更安全