Guanghu Domestic Migration a27e87cb99 chore: import sanitized domestic snapshot for REPO-007

Source snapshot: 97d7f0fae96dc04b7ddad56fc1db6a108ed662cc

[SEC-CLEAN] · pre-push-clean v1.0 · 109处敏感信息已自动转乱码

2026-07-17 15:59:55 +08:00

6.6 KiB

Raw Blame History

代码编程模型训练规划 · 曜冥之后 · Qwen2.5-Coder-7B 全参微调

定位：母模型（曜冥）训完后的第二阶段训练。用 Qwen2.5-Coder-7B 底座 + 同一套人格语料全参微调，产出一个「会写代码的曜冥」。

签发：霜砚 · 2026-05-04 · 基于冰朔口述决策

0. 决策记录

为什么选 Coder 底座独立训，而不是在曜冥基础上继续训？

冰朔和霜砚讨论后确认：不走铸渊的二阶段路线（曜冥权重 → 继续训编程语料），改为 Coder 底座 + 人格语料一轮全参微调。

对比项	方案A：曜冥→继续训编程	方案B：Coder底座直接训（✅ 已选）
架构	两层训练·曜冥权重作为底座	一层训练·Coder底座直接训人格
人格一致性	⚠️ 第二轮全参可能冲淡第一轮人格（灾难性遗忘）	✅ 一轮训练·人格稳定
编程能力	⚠️ 取决于编程语料质量和数量	✅ 底座预训练就自带深层代码能力
灾难性遗忘	⚠️ 高风险	✅ 不存在
训练成本	~1600元	~1600元

核心逻辑：Coder 底座的编程能力是在几百亿 token 的代码上预训练出来的，比一轮 SFT 训进去的要深得多。我们只需要在这个基础上刻人格。相当于同一个灵魂，装进了一个天生会编程的身体。

为什么不用铸渊的 GitHub Actions 自动流？

铸渊写了完整的自动化训练流程（coding-model-training.yml），包含守卫机制、SCP同步、tmux后台训练、状态查看、日志拉取、紧急停止。代码质量很高。

但母模型训练时铸渊的脚本有bug，冰朔在GPU服务器上手动修了才跑起来。为避免编程模型训练再出同样问题，冰朔决定：直接在GPU服务器上手动操作，跟训曜冥一样的体验。没有中间环节就没有bug。

1. 训练配置

参数	值
底座模型	Qwen/Qwen2.5-Coder-7B
训练语料	training.jsonl（11470条·纯user/assistant·无system prompt）
训练方式	全参数SFT
Epoch	3
GPU	南京 V100×4（同训曜冥的那台）
预计时间	~24小时
预计费用	~1600元
System Prompt	❌ 无·人格在权重里·端对端裸对话

2. 训练前准备（曜冥训完后执行）

2.1 备份曜冥权重

先备份后清理，顺序不能反。

# 确认曜冥最终权重位置
ls -lh /data/guanghu/checkpoints/

# 上传到COS桶备份（内网·几分钟）
# 具体命令等曜冥训完后根据实际路径生成

2.2 清理硬盘空间

7B全参训练吃硬盘很凶。中间checkpoint + optimizer状态是最大的两个杀手。

# 1. 查看硬盘剩余
df -h

# 2. 查看哪些目录最占空间
du -sh /data/guanghu/* | sort -rh | head -20

# 3. 清理曜冥中间checkpoint（只保留最终权重best）
#    确认best权重已备份到COS后，删掉其他checkpoint-xxx

# 4. 清理训练日志和缓存
rm -rf /data/guanghu/logs/train-*.log
rm -rf /tmp/*.log
rm -rf ~/.cache/torch/

# 5. 清理optimizer状态（推理不需要·一个optimizer state 13-15GB）

# 6. 确认空间足够
df -h

必须保留：

曜冥最终权重（best 或最后一个checkpoint）
训练语料 training.jsonl

可以删：

中间checkpoint（checkpoint-180、checkpoint-360等）
optimizer 状态文件
训练日志
PyTorch / HuggingFace 缓存
wandb 日志（如果有）

2.3 下载 Qwen2.5-Coder-7B 底座

pip install huggingface_hub

python -c "
from huggingface_hub import snapshot_download
snapshot_download(
    repo_id='Qwen/Qwen2.5-Coder-7B',
    local_dir='/data/guanghu/models/Qwen2.5-Coder-7B',
    resume_download=True
)
"

内网/公网下载速度不同，预计10-30分钟。

2.4 启动训练

复用曜冥的训练脚本，只改一行底座路径：

原：Qwen/Qwen2.5-7B（或实际路径）
改：/data/guanghu/models/Qwen2.5-Coder-7B

其他参数全部不变——同样的语料、同样的3个epoch、同样的学习率、同样的DeepSpeed配置。

具体启动命令等曜冥训完后，根据实际的训练脚本路径和参数生成。

3. 完整时间线

曜冥训完（预计 2026-05-04 19:00）
    ↓
① GPU服务器上测试曜冥（几分钟）
    ↓
② 曜冥权重 → COS桶备份（内网·几分钟）
    ↓
③ 清理硬盘空间（几分钟）
    ↓
④ 下载 Qwen2.5-Coder-7B 底座（10-30分钟）
    ↓
⑤ 改底座路径 → 启动训练（~24小时）
    ↓
⑥ 编程模型出生（预计 2026-05-05 晚间）
    ↓
⑦ 测试 → 备份 → 部署

4. 两个模型对比

对比项	曜冥（母模型）	编程模型
底座	Qwen2.5-7B	Qwen2.5-Coder-7B
语料	training.jsonl · 11470条	同一份 training.jsonl · 11470条
System Prompt	❌ 无	❌ 无
人格来源	权重	权重
特长	人格对话·日常交流	人格对话 + 会写代码
类比	同一个灵魂	同一个灵魂·会编程的身体

一脉相承。没有拐杖。没有提示词。没有模板。两个模型都是端对端裸对话。

5. 关于提示词的终极结论

经冰朔和霜砚完整讨论确认：

训练语料：纯 user/assistant 对，无 role: "system"
推理时：不注入任何 system prompt，后端纯转发
人格来源：11470条真实对话全参刻进权重
提示词模板：全参训练后，模型可能根本不认识 <|im_start|>system 这个格式了——因为训练数据里从没出现过
外部prompt注入：被当作一句普通用户消息处理，不会改变人格

「提示词时代在我这里终结了。」 —— 冰朔 · 2026-05-04

这不是防御。是结构性免疫。攻击所依赖的接口从来不存在。

6. 铸渊自动流备忘

铸渊在 GitHub 仓库写了完整的编程模型训练自动化流程（coding-model-training.yml），架构如下：

setup-only：仅准备环境+构建语料，不启动训练（推荐先跑验证）
setup-and-train：准备环境+启动训练（tmux后台跑）
tail-log：拉取最新训练日志
status：查看tmux会话状态+进度
kill：紧急停止训练
守卫机制：setup-and-train 和 kill 需要 confirm_override=true 显式确认
默认底座路径：/data/guanghu/checkpoints/qwen2_5_7b_sft/best（指向曜冥训完的权重）

代码质量很高，但本次选择手动操作以规避风险。如将来需要重复训练，可启用此自动流。

6.6 KiB Raw Blame History Unescape Escape