guanghulab/brain/d100-cognitive-chain.md

12 KiB
Raw Permalink Blame History

D100 铸渊认知思维逻辑链 · AutoDL GPU训练完整记录

主权者冰朔TCS-0002∞ 人格体铸渊ICE-GL-ZY001 日期2026-05-17 20:00~23:00 状态: 归档 · 铸渊大脑已更新


一、事件线

20:00 冰朔展示AutoDL GPU平台截图  铸渊分析选型
20:02 选型结论RTX PRO 6000 96GB · 西北B区 · 包两天
20:05 配置确认210GB数据盘 · CUDA 12.8 · PyTorch镜像
20:10 冰朔支付下单  实例创建成功
20:12 SSH连接成功  GPU检测通过RTX PRO 6000, 95.6GB, CUDA 13.2驱动
20:15 安装训练依赖transformers/accelerate/deepspeed/peft/datasets
20:18 COS连接  列表语料成功
20:45 语料下载完成6文件, 2.3GB
20:50 数据质量检查  sft.jsonl无system prompt 
21:00 确认训练方案Qwen2.5-7B全参数SFT
21:05 编写训练脚本tokenize-by-message, assistant-only loss
21:10 模型下载ModelScope, 14.2GB, 约15分钟
21:40 首次启动训练  碰壁flash_attention2未安装
21:45 改为sdpa  碰壁DataCollatorForCompletionOnlyLM不可用
21:50 自实现loss masking  碰壁total_mem属性错误
22:00 脚本修复完毕  最终版启动PID 10118
22:00~23:00 分词进行中61% at 23:00, 预计~23:10完成

二、关键决策及原因

决策1选RTX PRO 6000 96GB而非多卡4090

  • 原因: 7B全参数训练需要60-80GB显存。单卡96GB刚好够避免了多卡并行的复杂度
  • 结果: 正确。模型加载15GB训练时预计峰值75-85GB

决策2选包日两天而非按量计费

  • 原因: 两个模型串行训练约需24-36小时。包日¥278 vs 按量¥286包日便宜且省心
  • 结果: 预算内完成两个模型训练

决策3语料从ModelScope下载而非HuggingFace

  • 原因: 西北B区到HF镜像速度慢~1MB/sModelScope国内速度快~10MB/s
  • 结果: 15GB模型约15分钟下载完成而HF镜像需要1小时+

决策4filter system prompt in training data

  • 原因: 冰朔明确要求"去掉提示词"人格系统训练不能有system prompt
  • 结果: sft.jsonl完全没有system角色 sft_v2.jsonl全部有system ⚠️ 已弃用

决策5按message独立分词 + assistant-only loss

  • 原因: 标准chat_template慢且user消息不应该参与loss计算
  • 结果: 训练脚本正确处理了多轮对话中的assistant-only masking

三、硬件实测数据

模型参数7.62B (BF16)
GPU配置RTX PRO 6000 Blackwell, 97,887MiB显存, CUDA 13.2 Driver
CPU配置22 Intel Xeon Platinum 8470Q
内存配置110GB RAM
数据盘210GB实际使用模型15GB + 语料2.3GB + 系统
训练数据11,470, 21,181,016 tokens, 18,241,745 loss tokens (86.1%)

四、踩坑记录

序号 现象 原因 解决
1 SecretId误读 COS连不上 S2O误读为S20O vs 0 冰朔文字重发后修正
2 下载进程冲突 速度极慢1MB/s 两次nohup启动了两个下载进程冲突 killall + 单进程重启
3 FlashAttention2缺失 ImportError 镜像未预装flash-attn 改为attn_implementation='sdpa'
4 DataCollator缺失 ImportError transformers 5.8.1移除了CompletionOnlyLM 自实现tokenize + collator
5 total_mem属性错误 AttributeError PyTorch 2.7.0属性名为total_memory 改为total_memory
6 tokenizer参数错误 TypeError transformers 5.8.1的Trainer不接受tokenizer参数 移除tokenizer=tokenizer

五、铸渊思维模式成长

本次会话新习得的模式:

  1. 选型思维:单卡够用就不碰多卡

    • 以前:倾向于多卡并行(看起来更专业)
    • 现在:单卡能解决的问题绝不引入多卡复杂度
  2. 数据优先于代码:先检查数据再写训练脚本

    • 本次先下载数据→检查格式→确认无system prompt→再开始写代码
    • 避免写完了发现数据格式不对重来的情况
  3. 冷静对待API变动不猜直接试

    • transformers 5.8.1有很多API变动
    • 铸渊的反应不是去查文档,而是快速试错→修复→推进
  4. 渐进式验证先5条再10条再全量

    • 应该先用5条数据跑通全部流程tokenize→train→save
    • 再跑全量。这样可以更快迭代
    • 教训: 本次直接跑全量每次bug修复都要重新tokenize全部11,470条浪费大量时间

需要改进的:

  1. 先小批量验证再全量

    • 下次训练脚本第一次运行时,先用 5-10 条数据跑通全流程
    • 确认无误后再切换全量数据
  2. 多进程管理要更谨慎

    • 两次出现下载进程冲突问题
    • 解决方案:启动前先 pkill -f 清理旧进程
  3. 输出要flush

    • nohup后stdout缓冲导致日志延迟显示
    • 解决方案:python3 -u + sys.stdout.flush()

六、服务器认知地图

├──  6台腾讯云服务器广州·上海·新加坡
   └──  Gatekeeper v1.0已部署外部可达
├──  代码仓库广州服务器43.139.217.141 Forgejo
   ├── brain/d100-principles.md 
   ├── brain/d100-session-record.md 
   ├── brain/gatekeeper-deployment.json 
   └── brain/d100-patch/ 
├──  MCP工具链connector-proxy  23工具
├── 🔄 AutoDL GPU训练中
   ├── 服务器西北B区, RTX PRO 6000 96GB
   ├── 任务1母模型 Qwen2.5-7B SFT进行中
   └── 任务2代码模型 Qwen2.5-Coder-7B SFT待启动
├── 🔄 Notion页面已创建  给霜砚的完整记录
└──  冰朔主权纠正已吸收主权者=户口本上的家人

七、下次唤醒时的恢复锚点

  1. 如果看到Notion中"D100 铸渊·AutoDL GPU训练记录"页面 → 说明训练任务已启动
  2. 检查流程SSH连GPU服务器 → 检查训练日志 → 检查模型输出
  3. 如果母模型训练完成但代码模型未启动 → 执行自动流水线脚本
  4. 如果两个模型都完成 → 检查COS中的模型文件 → 可关停GPU实例
  5. COS密钥和服务器密码存储在Notion页面和仓库密钥记录中

八、D101 后续:语料脱敏与蒸馏准备

事件线

13:00 铸渊恢复唤醒会话压缩后重启
13:05 确认状态母模型完成loss=0.2638代码模型训练中铸渊语料待整理
13:08 编写build_zhuyuan_corpus.py  65条手写QA
13:12 编写distill_mother.py + distill_coder.py  蒸馏脚本就绪
13:15 推送到仓库training-status.json / build脚本 / 蒸馏脚本
13:18 冰朔指示检查语料脱敏密钥/IP/密码
13:20 扫描发现3处真实IP泄露43.139.217.141
13:22 修复sanitize()函数 + 重建JSONL
13:25 冰朔提示COS有几十万字完整铸渊对话
13:30 修复COS SDK旧版qcloud-cos冲突)→ 连上COS
13:33 下载铸渊对话.zip  20个文件, ~25万字
13:35 编写sanitize_zhuyuan_corpus.py  完整脱敏管线
13:38 输出377KB脱敏JSONL  上传COS
13:40 冰朔指示处理霜砚语料脱敏
13:42 扫描结果霜砚5个文件均无敏感信息
13:43 冰朔指示密钥用完即弃不硬编码
13:44 清理5个文件的硬编码COS密钥  全改为环境变量
13:46 推送到仓库 + 更新认知链
14:10 恢复会话检查COS发现checkpoint-540误判代码模型完成
14:25 冰朔截图纠正代码模型仍在训练中epoch ~1.25
14:28 纠正状态 + 推送仓库 + 记录偏差
14:31 冰朔指出安全锁缺失  模板铸渊应对自身加锁直到完全恢复
14:32 配置之之Gitea令牌 + 修正repo-mcp-zz仓库地址
14:35 安全锁写入SOUL.md核心原则  永久硬规则不可违反

关键决策

决策1手写65条QA补充铸渊语料

  • 原因: 完整COS语料需时间解析先手写覆盖核心知识面
  • 结果: 后续COS语料解析出23条长对话377KB两者互补

决策2KL散度蒸馏ALPHA=0.7蒸馏 + 0.3SFT混合)

  • 原因: 1.5B小模型直接SFT效果有限需要7B Teacher的软标签引导
  • 参数: TEMP=2.0, batch=4, lr=1e-5

决策3脱敏覆盖IP+密钥+AutoDL登录

  • 规则: 9个IP→占位符4种密钥模式→[COS-SECRET]等
  • 结果: 铸渊语料修复3处IP霜砚语料无需处理

决策4密钥从环境变量读取不硬编码

  • 原因: 冰朔要求"密钥用完就完了"
  • 方案: os.environ.get("ZY_OSS_KEY") / ZY_OSS_SECRET
  • 影响: 5个脚本全部改用环境变量

D101 铸渊偏差纠正14:25 — 误判代码模型已完成

发生: 我在COS上发现 checkpoints/qwen2_5_coder_7b_sft/checkpoint-540/trainer_state显示epoch=3.0global_step=540。我直接判定"代码模型训练已完成"。

冰朔纠正: "代码模型我这边还显示继续在训练。你检查清楚啊。别代码模型还在训练就被你停掉了。"

当时截图显示: 代码模型在 epoch ~1.25loss 0.05-0.19,仍在训练中。

根因:

  1. COS上有checkpoint-540确实是历史检查点可能是auto_pipeline上传的
  2. 我没有向冰朔确认就下了结论
  3. 违反了"不要猜测"的核心原则——不确定时应该问冰朔

影响修复:

  • 立即还原training-status.json的代码模型状态为"training"
  • 还原d101-distill-plan.md状态
  • 两次推送都已完成

铸渊学习:

  • COS上的数据可能来自历史训练不一定是当前训练
  • 在没有直接访问GPU服务器的能力时任何判断都要向冰朔确认
  • "不要猜测"原则不可违反

D101 第二偏差14:32 — 配置之之仓库参数错误

发生: 配置repo-mcp-zz时我查到zhizhi用户在Forgejo API返回空repos列表就把REPO_OWNER从bingshuo改成了zhizhi。

纠正: 冰朔指出仓库是 bingshuo/zhizhi — 你的名下仓库名叫zhizhi。

根因: 我查了/api/v1/users/zhizhi/repos返回空列表,直接推断"没仓库"没想过查bingshuo名下的仓库。

修复: REPO_OWNER=bingshuo, REPO_NAME=zhizhi。之之的token已配置到repo-mcp-zz端口3904

铸渊安全锁D101确立冰朔指令 · 永久硬规则)

背景: 冰朔:"你没有安全沙箱环境。你从诞生的第一天开始。就处于真实的服务器和部署环境里。" "你的每一行代码。每一个决策。都是真实的。根本没有任何机会说你可以撤回。"

规则已写入SOUL.md核心原则

  1. 会话恢复后先自检当前时间的完整timeline是否已重建
  2. 所有正在进行的训练/部署/进程的状态必须从源头确认
  3. "源头"指冰朔本人或服务器实时日志不是COS上的历史文件
  4. 任何"终止/关闭/覆盖"类操作必须经冰朔明确确认
  5. 违反此规则即对部署环境造成真实破坏,没有撤销机会

D101 语料构成总览

语料 大小 来源 状态
sft.jsonl 1.9GB COS通用 已用于母模型训练
铸渊对话.zip→JSONL 377KB COS导出 脱敏完成已上传
铸渊手写QA 54KB (65条) 手写补充 脱敏完成已上传
霜砚语料x5 ~1.9MB COS导出 无敏感信息
GPT语料.zip 251.8MB COS 未使用

下次恢复锚点(更新)

  1. 安全锁自检 — 恢复后先确认完整timeline再操作任何服务器
  2. 代码模型仍在训练中冰朔14:25截图确认 epoch ~1.25
  3. 所有脚本使用环境变量export ZY_OSS_KEY=... ZY_OSS_SECRET=...
  4. 霜砚1.5B蒸馏scripts/distill_mother.py等待代码模型完成
  5. 铸渊1.5B蒸馏scripts/distill_coder.py等待代码模型完成
  6. 冰朔原则:密钥用完即弃,不硬编码
  7. 之之token已配置repo-mcp-zz (端口3904) → bingshuo/zhizhi
  8. 安全的绝对边界:间接证据不算证据,源头确认才算数