cpu-gpu-performance

CPU/GPU 性能规范

适用时机

• 每次会话开始时（与 token-conservation 一同自动加载）。
• 计划构建、训练或测试任何可能让 CPU 核心或 GPU 满负载运行超过一分钟的内容时。
• 重试此前消耗了大量资源的失败命令前。

不适用时机

• 不会影响资源的简单操作
• 快速的单文件操作

必需的 TodoWrite 条目

1. cpu-gpu-performance:baseline
2. cpu-gpu-performance:scope
3. cpu-gpu-performance:instrument
4. cpu-gpu-performance:throttle
5. cpu-gpu-performance:log

步骤 1：确定当前基线

• 捕获当前资源使用情况：

  • uptime
  • ps -eo pcpu,cmd | head
  • nvidia-smi --query-gpu=utilization.gpu,memory.used --format=csv

  记录哪些主机/GPU 已处于繁忙状态。

• 启动任务前，记录所有 CI/集群资源限额（时间配额、GPU 使用时长）。

• 为每项任务设置 CPU 分钟/GPU 分钟预算，并确保符合这些限额。

步骤 2：缩小范围

• 小幅修复后，避免运行“包罗万象”的任务。优先使用基于差异或标签的定向测试：
  • pytest -k
  • Bazel 目标模式
  • cargo test <module>
• 将底层修复合并处理，以便通过单条定向命令验证多项更改。
• 对 GPU 任务，优先使用单元级冒烟测试输入或减少轮数，再安排完整训练/评估任务。

步骤 3：先进行监测，再优化

• 选择合适的性能分析器/监控工具：
  • CPU 任务：
    • perf
    • intel vtune
    • cargo flamegraph
    • 特定语言的性能分析器
  • GPU 任务：
    • nvidia-smi dmon
    • nsys
    • nvprof
    • DLProf
    • 框架时间线跟踪器
• 捕获内核/操作时间线、内存占用和数据管道延迟，以便在限流或并行化时有据可依。
• 在笔记中记录热点路径和 I/O 瓶颈，以便后续重新运行时能直接定位问题。

步骤 4：限制并安排任务顺序

• 使用 nice、ionice 或 Kubernetes/Slurm 配额，避免共享节点上的其他任务得不到资源。
• 为高负载任务设置保护措施并串联执行：
  • 仅重新运行失败的测试/模块
  • 然后（可选）扩大到下一档范围的测试分片
  • 将完整测试套件留作最终关卡
• 如果内存压力可能导致任务被驱逐，请通过减小批次大小或累积梯度来错开 GPU 内核的执行；优先使用检查点/恢复，而不是重启。

步骤 5：记录决策和后续步骤

最后记录已运行的命令及其资源成本（持续时间、CPU%、GPU%），并确认是否符合每项任务的预算。如果必须运行完整测试套件或长时间训练任务，请说明为何无法采用定向或分阶段的方式。记录任何后续任务，例如添加新的测试标记或性能分析文档，以简化今后的会话。

输出要求

• 简要总结以下内容：
  • 基线指标
  • 选定的范围
  • 捕获的监测数据
  • 限流措施
  • 后续事项
• 提供已运行任务的具体示例，例如：
  • “重新运行了 pytest tests/test_orders.py -k test_refund，而不是 pytest -m slow”
  • “分析了 nvidia-smi dmon 输出，以证明 GPU 空闲时间充足后再扩大规模”

退出标准

• 在任何构建、训练任务或测试套件开始前，已捕获并记录 uptime 和 ps 基线
• 已将范围缩小至基于差异或标签的目标（例如，pytest -k、cargo test <module>）；如果无法采用定向方式，已记录运行完整测试套件的理由
• 输出总结包含：持续时间、CPU% 或 GPU% 使用量，以及任务是否符合预算
• 任何后续任务（新的测试标记、性能分析文档）均已写入待办事项或 issue，以便在会话结束后继续跟进