每日报告 — 2026-07-14
日常概述
- 已完成工作： 对 Tianhe3 超级计算机存储进行了针对两位用户的全面审计与清理，识别并归档了关键的 OpenPI checkpoint，同时回收了约 1.7TB 数据。为 Qualcomm 平台上的 GR00T-N1.7 设计了量化流程，成功部署了 Action-Sketcher 推理框架以生成 LIBERO 任务的 2D 可视化轨迹。此外，为 ErrorRecoveryBenchmark 定义了标准数据规范，从损坏的视频资源中恢复文本，更新了 scGHT 评估报告，并对 Gadget 工具包进行了重大基础设施重构。
- 实施方法： 利用 SSH 调度与 Codex/AI 代理执行远程存储审计（清理灰尘），使用基于 Python 的 HDF5 元数据检查，以及交互式清理脚本。实现了 GR00T 的 AIMET SeqMSE 和 SpinQuant 设计，解决了机器人推理中的 MuJoCo EGL/CUDA 映射冲突，修正了数据集来源逻辑，将 Gadget 配置系统重构为单一真实源，并应用 OCR 技术进行媒体恢复。
- 影响： 消除了 HPC 集群中的重大存储瓶颈，建立了可复现的边缘部署量化框架，生成了用于机器人策略训练的关键推理数据集，确保了基准验证的数据完整性，提升了本地开发工具的安全性与可维护性。
执行了高流量日常工作流，重点优化 HPC 存储，在 Tianhe3 上回收了约 1.7TB 数据，完成了 GR00T 量化流程架构的完善，部署并调试了 Action-Sketcher 机器人基准测试，修正了 ErrorRecoveryBenchmark 数据集定义，并对 Gadget 工具包基础设施进行了重构。
任务
架构与策略
- 🔄 GR00T 量化流程架构与脚本 — 定义了四阶段路线图（FP16 Baseline -> SeqMSE PTQ -> SpinVariant -> Profiling）。在 Qwen3 主干上创建了 AIMet SeqMSE 和 SpinQuant 的 Python 基础设施，编写了 Slurm 脚本，在解决超时问题后成功提交了初始环境设置/基线任务。
- ✅ Tianhe3 存储审计与清理执行 — 对 zhaoganlong/tangzijia 区域进行了约 2.7TB 的审计。识别出 OpenPI checkpoint（1.1TB）和 MimicGen 数据为主要消费者。生成并执行了交互式脚本以归档 step-19999 checkpoint 并删除中间文件，回收了约 1.7TB 数据。
- ✅ Action-Sketcher 部署与 LIBERO 推广 — 将 Action-Sketcher 部署到 Tianhe3。修改了推广脚本以捕获规划提示和 2D 草图。解决了 MuJoCo EGL/CUDA 冲突，启用了 GPU 4-7 的并行多 GPU 执行，并收集了 10 项任务的数据轨迹（1 次失败）。
- ✅ ErrorRecoveryBenchmark 数据质量保障 — 定义了标准的训练/评估规范（每类 1,360 个场景），解决了文档/代码冲突。在 Tianhe3 上进行了只读 HDF5 审计以验证元数据来源，并发现人类演示数据集中的模式差异。
- ✅ Gadget 工具包重构与公开发布准备 — 将 Gadget 配置重构为单个仓库本地
config.json，采用失败即止的逻辑。清理了机密信息，重置了公共 GitHub 发布的 git 历史，解决了 Hugo 部署路径解析问题。
实施与修复
- ✅ 媒体恢复与研究报告更新 — 实现了基于 GPU 的 OCR 流程以从损坏的 MP4 视频中提取新文本。更新了 MIHD 进展报告，包含 scGPT-HD ARI 结果，并验证了 rclone sync 的稳定性。
问题与解决方案
关键问题
1. ErrorRecoveryBenchmark 数据来源模糊：论文文档、代码和实际 HDF5 数据在数据集大小和“训练”定义方面存在差异。
解决方案： 用户介入定义了标准计数（1360/1360）。AI 修补了审计脚本以接受异构元数据模式（例如 humandemo_source 与 source_dataset）。
关键洞察： 文档往往落后于代码；明确的“标准”定义和灵活的模式验证对于准确验证基准至关重要。
2. Tianhe3 存储配额与元数据延迟：HPC 审计揭示了 Lustre 元数据延迟与分布式用户配额之间的复杂关系，这些配额与全局空闲空间不同。
解决方案： 使用 dust 进行高效的目录审计。重新编写了 Python HDF5 检查器，仅读取高级属性而非迭代嵌套组。在清理脚本中增加了明确的 LFS 配额检查，以防止归档时拒绝。
关键洞察： 大规模 HPC 审计需要仅基于属性的 introspection；全局空间可用性不能保证特定项目的配额余量。
3. Action-Sketcher 推理失败：遇到 CUDA OOM（设备加载错误）、MuJoCo EGL 设备 ID 与 CUDA_VISIBLE_DEVICES 不匹配，以及 SSH 代理 DNS 故障。
解决方案： 修补了推理代码以明确设置设备。在可见 GPU 上重新映射 MUJOCO_EGL_DEVICE_ID=0，同时本地映射 uv。通过使用缓存的隧道 IP 和主机密钥绕过 DNS 故障，解决了 SSH 连接问题。
关键洞察： 机器人渲染流程通常将 EGL 索引与 CUDA 可见性分离；当 DNS/Proxy 服务不稳定时，远程 HPC 连接可能需要加密绕过。
4. 量化环境与模型访问：初始 Slurm 任务因 UV_HTTP_TIMEOUT 包管理器超时在大型轮上失败；后来被受限 HuggingFace 模型（Cosmos-Reason2-2B）阻塞。
解决方案： 在 sbatch 脚本中增加 -u。调查了 Qwen3 的配置交换，但暂停以等待用户 HF 令牌批准，以保持基线完整性。
关键洞察： 网络超时是 HPC 环境设置中的关键风险；受限模型需要明确的凭证管理，而非架构层面的解决方案。
一般问题
5. SSH 命令引用与缓冲：复杂的 Python 单行脚本因 Shell 转义问题在 SSH 中失败；长的 HDF5 脚本因缓冲而隐藏进度。
解决方案： 改为通过 SCP 上传独立的 Python 脚本以处理复杂逻辑。在远程脚本中启用无缓冲输出（flush=True），以提供实时反馈。
关键洞察： 从本地 CLI 工具远程执行应优先使用文件传输而非内联命令；长运行远程进程必须明确刷新。
6. 视频文件损坏：标准 ffmpeg 提取因下载资源中的 HEVC NAL 单元错误而失败。
解决方案： 实施了关键帧查找策略（-ss）以跳过损坏数据包，使用基于 GPU 的 RapidOCR 恢复有效片段。
关键洞察： 基于时间戳的查找比连续解码更稳健，可用于从结构损坏的多媒体资源中恢复数据。
人类与 AI 方法
战略层面
Benchmark 数据定义（ErrorRecovery）| 角色 | 方法 |
|——|——| | 人类 | 用户定义了训练集与评估集的语义真实值及具体数量，纠正了 AI 认为代码具有权威性的初始假设。 | | AI | AI 进行了机械验证和架构审计，但在没有人类指导的情况下无法识别“论文现实”与“代码现实”之间的矛盾。 |
差异分析： 人类提供了战略意图和业务逻辑；AI 负责战术执行和技术验证。
Gadget 配置架构
| 角色 | 方法 |
|---|---|
| 人类 | 用户要求采用单一真实值来源配置，并采用快速失败机制，拒绝使用旧式回退方案。 |
| AI | AI 重构了不同的模块以符合此架构约束，同时维持过渡阶段的安全性。 |
差异分析： 人类设定了架构边界；AI 负责迁移复杂性处理。
战略数据保留与 AI 保守性（Tianhe3 清理）
| 角色 | 方法 |
|---|---|
| 人类 | 用户实施了严格的保留策略（仅保留第 19999 步检查点），超越标准备份实践以节省空间。 |
| AI | AI 最初基于启发式最佳实践建议保留最终检查和中间检查，仅在用户明确约束后进行调整。 |
差异分析： 人类优先优化资源；AI 默认保留数据，直到被纠正为止。
GPU 资源分配策略
| 角色 | 方法 |
|---|---|
| 人类 | 用户指定了任务与 GPU 的精确映射，以优化运行效率进行并行部署。 |
| AI | AI 生成了复杂的 nohup 调度逻辑和环境变量管理功能，以执行用户的计划。 |
差异分析： 人类定义了逻辑分配；AI 处理过程控制的语法复杂性。
AI 局限性
关键局限性
- AI 依赖启发式假设来制定保留策略和模型可用性，缺乏对明确用户约束（例如“仅第 19999 步”）或外部门控机制的即时意识，且没有人工指导。
一般局限性
- 长时间运行的远程 Python 脚本默认会缓冲输出，直到明确修复前，用户无法看到进度。
- 最初的 MuJoCo 部署尝试未能预见到 EGL/CUDA 设备 ID 映射冲突，需要特定领域知识才能解决。
- AI 最初在通过 SSH 执行远程 Python 时难以处理复杂的 shell 引用问题，导致语法错误，需要迭代调试或文件传输解决方案。
经验教训
关键经验
- 当使用
CUDA_VISIBLE_DEVICES、MUJOCO_EGL_DEVICE_ID时，必须显式设置为本地 Python 进程索引（通常为 0），而非物理 GPU ID。 - 在基于 Lustre 的 HPC 集群上，枚举大 HDF5 组会导致元数据延迟；读取文件属性比迭代结构用于溯源分析要快得多。
- 尽早为实验参数（如数据集大小）建立“标准”真实来源，可避免复杂研究项目中文档落后于代码时的矛盾工作。
- 机器人领域的 HDF5 数据集通常包含语义冗余（例如 v1 与 v2）；在删除或归档前需通过元数据检查确认身份。
实际经验
- 来自本地 CLI 工具的稳健远程执行应优先上传脚本而非内联命令，并为长时间进程启用无缓冲输出以确保可见性。
对话总结
GR00T 量化管道
• Qualcomm 部署的架构设计与初始执行 19:32:47.364 | claude_code 建立了完整的 4 阶段路线图用于 GR00T-N1.7 的量化（FP16 基准 -> SeqMSE PTQ -> SpinVariant -> 分析）。归档了代码库架构设计，生成了旋转/量化脚本，并提交了 Slurm 作业链。进度受阻，等待用户提供的 HuggingFace 凭据以启用门控模型。
Tianhe3 存储管理
✅ HPC 存储审计、分析与清理 19:22:41.312 | codex 对 zhaoganlong 和 tangzijia 用户的 ~2.7TB 使用进行了深度审计。识别出 OpenPI 检查点（1.1TB）和 MimicGen 数据为主要消费者。分析了 HDF5 元数据以区分有效检查点和临时/缓存文件。生成并执行了交互式脚本，归档了最终第 19999 步检查点并删除了约 1.7TB 冗余数据。
Action-Sketcher / WorldModel3DVisualPrompt
✅ 在 Tianhe3 上的部署、调试和并行部署 03:01:24.739 | codex 将 Action-Sketcher 部署到 Tianhe3，修改了部署脚本以捕获规划提示和 2D 草图。解决了关键错误，包括 CUDA OOM（设备加载错误）、MuJoCo EGL/CUDA 映射冲突以及 SSH 代理 DNS 故障。成功在 GPU 4-7 上并行执行 LIBERO 部署，收集了 10 个任务的数据迹线（1 次失败）。
ErrorRecoveryBenchmark
✅ 数据质量验证和状态调查 22:05:27.672 | codex/claude_code 定义了标准的训练/评估规范（1,360 场景），解决了文档/代码冲突。在 Tianhe3 上执行了只读 HDF5 审计以验证元数据来源，并识别了人类演示数据集中的架构差异。制定了缺失检查点和矛盾文档的恢复计划。
Gadget（GitHub Toolkit）
✅ 配置统一、安全清理和公开发布准备
20:17:12.343 | claude_code/cursor
将 Gadget 配置重构为单个仓库本地 config.json 并采用快速失败逻辑。清理了私有路径/机密信息，重置了公共 GitHub 发布的 git 历史，修复了 Hugo 部署路径问题，并标准化了换行符。
媒体与研究报告
✅ 损坏视频恢复和 scGHT 报告更新 19:20:45.816 | claude_code 实现了 GPU 加速 OCR 管道，从损坏视频中提取了约 17k 字符。更新了包含 scGPT-HD ARI 结果的 MIHD 进度报告。验证了 rclone sync 的稳定性用于日常日志记录。