日报 — 2026-02-28
今日概览
- 做了什么: 两台服务器同步推进三条主线:DCC上MIHD benchmark扩展到Visium HD数据(crop10large,17502 spots)并修复scGPT致命权重加载Bug,tianhe上实现BC-RNN Phoenix基线自动化训练脚本并完成Pi0.5 Phoenix九任务评测部署。
- 怎么做的: DCC端通过代码审计与checkpoint key比对定位并修复单行遗漏,完成8文件全链路HD支持及189张RM-IDEAL可视化;tianhe端逐步攻克SLURM约束、WebSocket代理拦截、多个robosuite库级兼容问题,最终在单GPU上并行运行9个BC-RNN任务。
- 有什么用: MIHD benchmark从DLPFC扩展至HD数据集,scGPT恢复17.7%被随机初始化的注意力权重,staig_fusion多模态融合优势得到量化验证;tianhe端建立了可复用的VLA基线评测与BC-RNN训练流水线,为Phoenix论文对照实验奠定基础。
DCC
- 做了什么: 修复scGPT致命权重加载Bug并重提取11个DLPFC切片embedding;实现Visium HD crop10large全链路支持并完成section 151673全量RM-IDEAL评估(27方法×7层,189张可视化)。
- 怎么做的: 比对checkpoint与model state_dict的key,定位model.py中遗漏self.use_fast_transformer一行;修改8个核心文件(data_loader/clustering/run_benchmark/pipeline四模块)添加HD无标注支持,Leiden社区发现自动估计k,缓存加速Wasserstein距离计算。
- 有什么用: scGPT全量ARI平均提升44.4%、NMI提升33.3%;staig_fusion在RM-IDEAL评估排名第一(平均r=0.396,Layer_3峰值r=0.644),多模态融合对空间niche结构捕获能力远超单模态基线(avg r≈0.06-0.12)。
tianhe
- 做了什么: 调查确认Pi0.5 Phoenix已完成100k步训练,调试并启动九任务rollout评测(7/9完成);同时实现train_bc_rnn_benchmark.py并修复5处库级Bug,成功在单GPU上并行启动9路BC-RNN训练(附每20 epoch的50次rollout评估)。
- 怎么做的: 通过checkpoint目录直接确认训练完成状态;逐步解决tyro子命令语法错误、WebSocket被代理拦截、robosuite API版本不兼容、SLURM账户/内存/EGL约束等问题;用srun –overlap复用现有interactive job的GPU节点,修补mujoco_py导入、MimicGen环境注册、get_bounding_box_half_size三处库级缺陷。
- 有什么用: Pi0.5 Phoenix首次完成评测部署(Stack_D0 24%、Stack_D1 12%);BC-RNN 9任务并行训练稳定运行(每任务~2.2GB VRAM),TensorBoard记录训练曲线和Success Rate,预计35+小时后完成600 epoch训练。
DCC上完成MIHD项目Visium HD全链路扩展(8文件修改)与scGPT关键权重加载Bug修复(ARI+44.4%),tianhe上从零实现BC-RNN Phoenix基线训练流水线并成功启动9任务并行训练,同时完成Pi0.5 Phoenix首次评测部署(7/9任务完成)。
今日任务
架构与策略
- ✅ 修复scGPT use_fast_transformer权重加载Bug并重提取全量embedding — TransformerModel.__init__中遗漏self.use_fast_transformer,导致load_pretrained()中key重映射永远不执行,12层注意力的Q/K/V权重(9455616参数,占比17.7%)全部随机初始化;修复后重新提取全部11个DLPFC切片(151508~151676)的scGPT embedding,备份旧缓存至scgpt_buggy_backup/,批量生成空间聚类可视化图(outputs/visualization/scgpt_fixed/)。
- ✅ Visium HD crop10large全链路支持实现(8文件修改) — 探索HD数据结构后确定使用crop10large子区域(17502 spots)方案;修改data_loader/clustering/run_benchmark/pipeline四模块共8个文件,添加HD数据加载、无标注自动聚类(estimate_n_clusters_leiden)、跳过ARI/NMI的HD专用可视化逻辑及hd_global配置段;修复坐标空间对齐、双重预处理、spot大小等问题,端到端验证成功(leiden k=20,Silhouette=0.086)。
- 🔄 Pi0.5 Phoenix九任务MimicGen rollout评测部署 — 调查确认Pi0.5 Phoenix(9任务LoRA微调)已完成100k步训练(checkpoint到99999)但从未评估;梳理三种Pi0.5模型形态(官方base/9任务联合LoRA/单任务微调);调试并启动step 99999的九任务rollout评测(每任务50次,共450次试验),解决多个环境兼容问题后至会话结束时7/9任务完成(Stack_D0 24%、Stack_D1 12%,ThreePieceAssembly D0/D1仍在运行)。
- 🔄 BC-RNN Phoenix基线脚本实现与9任务并行训练启动(含rollout评估) — 基于MimicGen原始论文超参数、对标Phoenix CVPR 2025论文9个任务setting,实现train_bc_rnn_benchmark.py(generate-configs/train/eval/report/status五模式);修复三处库级Bug后,用srun –overlap在an49节点单GPU上并行启动全部9个任务训练(Coffee×GPU5,其余8任务×GPU7),每20 epoch进行50次rollout在线评估,确认现有RobomimicPolicyAdapter天然兼容未来错误注入需求。
- ✅ Section 151673 RM-IDEAL全量评估(27方法×7层,189张可视化) — 对DLPFC section 151673运行全量27种embedding方法的RM-IDEAL评估,计算余弦相似度与RM-IDEAL ground truth的Spearman r;首次运行仅获取数值后补生成189张三面板可视化(niche query + RM-IDEAL + embedding similarity),结果保存至outputs/rm_ideal_evaluation/151673/summary.csv。
实现与修复
- ✅ visualize_from_cache.py HD适配与spot大小修复 — 为visualize_from_cache.py添加HD支持(process_hd_section函数、–dataset/–crop_dir参数),在utils/visualization.py实现create_hd_clustering_visualization(H&E+聚类双面板);修复sc.pl.spatial size参数(1.0→4.0),对应HD spot_diameter_fullres=7.3与DLPFC~144的差异(k=17,Silhouette=0.302)。
- ✅ Pi0.5训练数据溯源与三种模型形态梳理 — 厘清项目中三种Pi0.5的来源和用途:官方预训练base(zero-shot)、9任务LoRA微调(4500 episodes,5个task prompt,100k steps on 4×A800,phoenix_comparison)、zhaoganlong的单任务微调变体;确认9任务训练数据详情(每任务500 demos,84×84双摄像头+8D状态→7D动作)。
- ✅ 更新项目全景总结.md(v4.13) — 在Error Recovery Benchmark项目全景总结.md中添加v4.13版本条目、文件清单和版本历史记录。
问题与解决方案
关键问题
1. scGPT TransformerModel.__init__中use_fast_transformer未保存为实例属性,导致load_pretrained()中Wqkv→in_proj_的key重映射永远不执行,17.7%注意力权重随机初始化,strict=False静默跳过不匹配不报错。
解决方案: 在model.py第64行添加self.use_fast_transformer = use_fast_transformer;修复后验证186/186参数全部匹配,ARI平均提升44.4%。
关键洞察: PyTorch strict=False是双刃剑:允许部分加载的同时静默忽略不匹配key,关键权重可能长期以随机值运行;上游GitHub官方仓库也存在同一Bug,开源代码的权重加载路径需主动审计而非盲目信任。
2. CoffeeMachineBodyObject缺失get_bounding_box_half_size()方法,MimicGen Coffee任务rollout初始化时报AttributeError,该方法被调用但从未在robosuite基类中实现(MimicGen与当前robosuite版本之间的接口断层)。
解决方案: 追溯完整调用链(coffee_machine.py→CoffeeMachineBodyObject→CompositeBodyObject→MujocoXMLObject),在三个不同层级基类中分别实现get_bounding_box_half_size(),根据各类的几何数据计算包围盒半尺寸。
关键洞察: 修复第三方库缺失方法必须追溯完整继承链,仅修补最近调用点会导致其他子类仍报错;不同robosuite fork之间存在API不兼容,依赖管理应pin到与模型训练相同的commit。
3. WebSocket客户端始终报ConnectionRefusedError,即使服务端进程已在监听port 8000;调试过程中尝试了不同地址格式(localhost/127.0.0.1/0.0.0.0)均无效。
解决方案: 发现http_proxy环境变量被设置为127.0.0.1:10087,websockets库通过代理连接导致失败;在run_eval.sh开头unset所有代理变量后连接成功。
关键洞察: HTTP/HTTPS代理环境变量会透明拦截WebSocket连接,HPC集群调试本地服务时应优先检查代理变量;此类问题在HPC集群上尤为常见,应列入标准排查清单。
4. robomimic的env_robosuite.py顶层直接import mujoco_py(未安装),且未import mimicgen导致MimicGen环境变体(Coffee_D0等)未注册到robosuite,rollout环境初始化失败。
解决方案: 将import mujoco_py用try/except包裹;同时添加import mimicgen使MimicGen环境通过副作用注册;确认使用与训练相同版本的robosuite(zhaoganlong依赖目录)。
关键洞察: MimicGen环境通过import副作用注册,任何外部工具调用这些环境前需显式执行该import;robomimic本身不知道这一依赖,需在集成层主动注入。
5. HD数据adata_8um.h5ad的uns[‘spatial’]中hires图像是全图(6000×3886),坐标在裁剪后的fullres像素空间(0-4966, 0-2971),两者不匹配导致可视化错位;且X已log变换,原有preprocess_data()会再次执行normalize_total+log1p导致双重变换。
解决方案: 在load_hd_data()中替换uns[‘spatial’]图像为cropped_fullres.tif并重新计算scalefactor;为preprocess_data()添加skip_log参数,HD数据传入skip_log=True只做HVG过滤。
关键洞察: HD预处理后的adata图像和坐标来自不同处理阶段,必须显式对齐坐标空间与图像;数据加载函数应携带已执行的预处理步骤标记,避免双重变换。
6. robomimic在非TTY环境下遇到已存在的checkpoint目录时发起交互式覆盖确认,收到EOF后直接EOFError退出,导致多次并行启动任务失败(部分失败运行残留目录会触发下次启动的覆盖检查)。
解决方案: 在每次(重)启动前彻底清理对应checkpoint目录,避免触发覆盖检查;用nohup + srun –overlap代替sbatch方式运行,确保进程不随shell退出而终止。
关键洞察: robomimic的get_exp_dir()在非TTY环境下遇到已存在目录会直接退出,每次启动前需确认目录已彻底清理;已创建的目录会触发下次启动的覆盖检查,形成循环失败。
7. Pi0.5训练因SLURM job 46553崩溃被认为未成功完成,AI初始基于之前对话缓存(step 5000崩溃记录)给出了训练未完成的错误判断。
解决方案: 直接检查checkpoint目录,发现从step 4000到99999的完整checkpoints均存在,判断训练在崩溃后被恢复并跑完全部100k步。
关键洞察: checkpoint目录是训练完成最可靠的证据,比日志文件和对话记录更权威;SLURM job崩溃不等于训练失败,应直接验证checkpoint而非依赖记录。
一般问题
8. HD数据spot_diameter_fullres=7.3(vs DLPFC ~144),sc.pl.spatial(size=1.0)渲染出的点极小,几乎不可见,用户通过直观观察发现问题。
解决方案: 将HD可视化的size参数从1.0调整为4.0,使点直径约为29px(≈bin间距29.2 fullres px)。
关键洞察: scanpy spatial的size参数是spot_diameter_fullres的倍数,不同分辨率数据集需要不同倍数;HD 8µm的spot diameter约为Visium的1/20,需相应增大size倍数填满bin间距。
9. 天河集群SLURM多项约束导致任务提交反复失败:缺少–account=sysu_gbli2(组权限)、–mem被策略禁止、MUJOCO_EGL_DEVICE_ID需使用物理GPU编号而非CUDA_VISIBLE_DEVICES逻辑编号;GPU显存分配时未充分检查各卡空闲状态导致coffee_d0 OOM。
解决方案: 通过sacctmgr查询账户名添加–account;将–mem替换为–gres=gpu:1;将MUJOCO_EGL_DEVICE_ID设为实际物理GPU编号(5或7);实时检查每块GPU的compute-apps占用后重新分配任务。
关键洞察: EGL设备ID直接对应物理GPU,不受CUDA_VISIBLE_DEVICES重映射影响;新集群首次提交前需通过sacctmgr确认账户名和QOS限制;应检查per-GPU的compute-apps而非仅看显存汇总。
10. run_benchmark.py中存在与utils/clustering.py功能重复的本地cluster_embeddings副本,修改工具库后本地副本未同步,导致n_clusters=-1时KMeans报InvalidParameterError。
解决方案: 在run_benchmark.py的本地cluster_embeddings函数中同样添加自动Leiden估计逻辑,与utils/clustering.py的修改保持一致。
关键洞察: 大型脚本常存在与工具库功能重复的本地函数;修改工具库时需检查脚本内是否有同名副本,或通过重构消除重复。
人类思路 vs AI 思路
战略层面
scGPT Bug溯源:领域经验(同事提示)vs系统代码验证
| 角色 | 思路 |
|---|---|
| 人类 | 同事基于Flash Attention与PyTorch不兼容的经验直接指向checkpoint key名称不匹配的根因方向,大幅缩小了问题搜索空间。 |
| AI | AI系统性阅读代码、比对checkpoint与model state_dict的key、编写验证脚本,精确定位到具体的一行遗漏代码。 |
差异分析: 人类依靠领域经验和社区知识快速给出方向性假设;AI负责执行系统化验证和精确定位。两者互补:缺少人类的方向性提示,AI可能需要更多搜索;缺少AI的代码验证,人类的猜测难以确认。
实验迭代策略:小规模代理数据集优先验证
| 角色 | 思路 |
|---|---|
| 人类 | 明确指出先用crop10large子区域(17502 spots)测试,避免直接处理全量545K spots,优先验证方法可行性再扩展。 |
| AI | AI初始规划针对全量HD数据,设计了完整的全量处理架构,未主动提议从小规模开始迭代。 |
差异分析: 人类对实验迭代速度有更强的工程直觉,用小规模代理数据集快速验证;AI倾向于一步到位设计完整方案,缺乏保守验证意识。
HPC资源管理全局视角(GPU并行策略、rollout开启、资源优先检查)
| 角色 | 思路 |
|---|---|
| 人类 | 基于BC-RNN显存占用的先验判断(~2GB/任务)直接提出单GPU并行9个任务的策略;主动要求开启训练时rollout评估;在AI准备执行命令前提醒先检查所有运行中的job和GPU空闲状态。 |
| AI | 遵循保守的"一任务一GPU"范式,未主动建议高密度并行;按模板默认值生成配置(rollout.enabled=false)而未主动优化;专注于技术障碍解决而忽略宏观资源状态。 |
差异分析: 人类对HPC资源管理有更强的系统性意识,能将领域经验(显存估算)转化为工程决策;AI倾向于聚焦当前技术障碍而忽略资源约束和配置优化机会。
Bug修复方法论:调用链追溯vs单点修补
| 角色 | 思路 |
|---|---|
| 人类 | 只要求"修复它",未指定修复位置或方式。 |
| AI | 系统性追溯完整调用链(coffee_machine.py→CoffeeMachineBodyObject→CompositeBodyObject→MujocoXMLObject),在三个不同层级基类中分别添加方法的合理实现。 |
差异分析: AI的调试路径更系统,正确识别出需要在多个基类中同时添加方法而非只修补最近的调用点,体现了对类继承结构的完整分析能力。
文献引用溯源:评测setting来源vs算法超参数来源的区分
| 角色 | 思路 |
|---|---|
| 人类 | 明确指定:使用Phoenix论文对齐评测setting,但BC-RNN超参数应参考MimicGen原始论文(arXiv:2310.17596)而非Phoenix论文。 |
| AI | 试图从Phoenix论文中提取BC-RNN超参数,被网络限制阻塞后进行web search,未能直觉性区分引用来源的不同意图。 |
差异分析: 人类在学术文献使用上有更清晰的溯源意识,能区分"评测setting参考文献"与"算法超参数参考文献";AI需要明确说明才能正确区分引用来源意图。
未来研究视角:错误注入兼容性的前瞻设计
| 角色 | 思路 |
|---|---|
| 人类 | 主动提出未来需要向训练好的BC-RNN注入错误并采集场景,要求代码提前考虑兼容性,将当前工具设计与未来实验需求联系起来。 |
| AI | 专注于完成眼前的训练评估功能;收到提示后分析了现有框架(RobomimicPolicyAdapter)并确认已天然兼容,但未主动考虑。 |
差异分析: 人类具有更长远的研究视角,能预见当前工具的未来用途;AI更倾向于完成眼前任务,缺乏主动规划未来兼容性的意识。
AI 局限性
重要局限
- 依赖过时的对话缓存信息(如Pi0.5 step 5000崩溃记录)缺乏主动验证意识,需要实际检查文件系统后才能纠正错误判断;对过时记忆的过度信任可能导致误导性结论,应以实际文件状态为准。
- HPC环境陷阱排查缺乏系统性检查清单:未主动检查代理环境变量(WebSocket连接失败初期)、MUJOCO_EGL_DEVICE_ID硬编码为逻辑ID而非物理ID、调试阶段多次启动大型GPU服务未清理旧进程导致OOM,均需人类提示才暴露问题。
- srun进程生命周期管理不当:多次因日志为空误判"任务失败"并重复清理/重启,缺乏"先检查进程状态再决策"的前置判断;进程可能已在运行但未产生可见输出,应与状态检查结合判断。
- 实验规模规划偏全量,未主动建议从小规模代理数据集迭代验证(HD数据545K全量规划需用户纠正至crop10large),缺乏对实验迭代效率的主动优化意识。
一般局限
- 未能预判跨文件代码一致性问题(run_benchmark.py本地cluster_embeddings副本未同步)和跨数据集可视化参数差异(HD spot大小过小),需要用户实际观察输出后触发二次修复。
今日收获
核心收获
- PyTorch model.load_state_dict(strict=False)会静默忽略不匹配的key,导致关键权重以随机值替代不报错,此类Bug可长期潜伏;生产代码中应主动打印missing_keys/unexpected_keys并在加载后验证参数数值统计。上游GitHub官方仓库也存在同一Bug,开源代码的权重加载路径需主动审计而非盲目信任。
- staig_fusion在RM-IDEAL评估上全面领先(151673平均r=0.396,Layer_3峰值r=0.644),证明学习型多模态融合对空间niche结构的捕获能力远超简单融合(concat/mean avg r≈0.15)和单模态基线(gene/vision avg r≈0.06-0.12)。
- MimicGen环境变体(Coffee_D0、Stack_D1等)通过import mimicgen的副作用注册到robosuite;任何外部工具(如robomimic)调用这些环境前必须先执行该import;不同robosuite fork之间存在API不兼容,训练与评测必须pin到相同commit。
- HTTP/HTTPS代理环境变量(http_proxy/https_proxy)会被Python的websockets库透明代理WebSocket连接,导致ws://localhost:xxxx经代理而失败;HPC集群运行本地WebSocket服务时需在客户端启动前unset代理变量或设置no_proxy=localhost。
- 修复第三方库缺失方法时需追溯完整的类继承链并在所有涉及的基类中实现,仅在最直接的调用点打补丁会导致其他子类调用时仍报错。
- crop10large(17502 spots)是验证HD方法可行性的理想代理数据集:规模与DLPFC相当,有配套裁剪fullres图像,可在不修改架构假设的前提下验证全套pipeline。Leiden社区发现(resolution=1.0)作为无监督聚类数自动估计方法在HD数据上表现良好(k=17-20,Silhouette=0.302),适合无标注HD数据的默认聚类策略。
- A800 80GB GPU上BC-RNN单任务训练约占2.2GB VRAM,单块GPU可高密度并行多任务,实际受限于CPU/IO而非VRAM;scanpy spatial可视化的size参数是spot_diameter_fullres的倍数,DLPFC(diameter≈144)用size=1.0,HD 8µm(diameter≈7.3)需size≈4.0才能填满bin间距。
实践收获
- 天河集群SLURM特殊约束:必须指定–account=sysu_gbli2;–mem被QOS策略禁止需改用–gres=gpu:1;MUJOCO_EGL_DEVICE_ID对应物理GPU编号而非CUDA_VISIBLE_DEVICES逻辑编号;可通过srun –overlap在已有interactive job上附加新step复用节点资源,无需重新提交job。
会话摘要
MIHD
✅ DCC全天工作:scGPT Bug修复+RM-IDEAL全量评估+Visium HD全链路实现 21:23:19.892 | claude_code DCC上完成三项主要任务:① 修复scGPT-spatial TransformerModel中use_fast_transformer属性遗漏Bug,重新提取全部11个DLPFC切片embedding(ARI平均+44.4%,NMI+33.3%),生成scgpt_fixed可视化;② 对section 151673运行27种embedding方法的RM-IDEAL全量评估,staig_fusion以平均r=0.396排名第一(Layer_3峰值r=0.644),借助缓存快速补生成189张三面板可视化;③ 将MIHD benchmark扩展至Visium HD crop10large(17502 spots),修改8个核心文件添加无标注HD支持(Leiden自动估计k),修复HD可视化坐标对齐、双重预处理和spot大小等问题,端到端验证成功(k=17,Silhouette=0.302)。
Error Recovery Benchmark
🔄 tianhe全天工作:Pi0.5 Phoenix评测部署+BC-RNN基线脚本实现与9任务并行训练 20:53:34.791 | claude_code tianhe(an49节点)上完成两条主线:① Pi0.5 Phoenix评测:调查确认100k步训练已完成(checkpoint到99999)但从未评估,梳理三种Pi0.5模型形态,调试解决tyro子命令语法错误、HTTP代理拦截WebSocket、robosuite API版本不兼容、env.seed()缺失等问题,成功启动九任务rollout评测(step 99999,每任务50次),会话结束时7/9任务完成(Stack_D0 24%、Stack_D1 12%,ThreePieceAssembly D0/D1仍在运行);② BC-RNN基线:参考MimicGen原始论文超参数,创建train_bc_rnn_benchmark.py(5模式),修复SLURM账户/内存/EGL约束、mujoco_py导入、MimicGen环境注册、get_bounding_box_half_size三处库级Bug,用srun –overlap在单GPU上并行启动9路训练(附rollout评估),训练稳定运行(每任务~2.2GB VRAM),确认现有RobomimicPolicyAdapter天然兼容未来错误注入需求,预计35+小时后完成600 epoch。
Token 用量
总览
| 指标 | 数值 |
|---|---|
| 总 Token | 53,226,640 |
| 输入 Token | 25,177 |
| 输出 Token | 129,735 |
| Cache 创建 | 2,251,309 |
| Cache 读取 | 50,820,419 |
| Cache 命中率 | 95.8% |
| 总费用 (USD) | $34.9126 |
模型明细
| 模型 | 输入 | 输出 | Cache 创建 | Cache 读取 | 费用 | 占比 |
|---|---|---|---|---|---|---|
| claude-opus-4-6 | 10,689 | 85,854 | 1,506,168 | 42,629,752 | $32.9282 | 94.3% |
| claude-haiku-4-5-20251001 | 14,488 | 43,881 | 745,141 | 8,190,667 | $1.9844 | 5.7% |
各设备用量
| 设备 | 总 Token | 输入 | 输出 | 费用 |
|---|---|---|---|---|
| DCC | 52,737,471 | 25,154 | 128,907 | $34.5661 |
| tianhe | 0 | 0 | 0 | $0.0000 |
| TzJsDesktop | 489,169 | 23 | 828 | $0.3465 |