我觉得 AGENTS.md 最有价值的地方，是把团队默认知道、但新人和工具很难推断的规则显式化。除了目录职责、测试命令和修改边界，还可以加入一份简短的“完成定义”，比如代码生成产物已同步、聚焦测试已通过、公共接口变更已检查兼容性。这样代理不会把“代码能运行”误当成任务结束。 维护上建议把它纳入代码评审：当脚本、目录或流程发生变化时，同时检查相关说明；也可以定期用一个小任务验证其中命令是否仍可执行...

去重确实不只是“删副本”，本质上是在调整训练语料的权重。实践中最难的是阈值：设得太宽，改写后的题目和答案容易漏掉；设得太严，又可能误删正常教材、常用代码及低资源语言内容。我觉得可以给高风险数据单独建规则库，例如公开题库、评测仓库和题解页面优先做子串与语义检查，同时保留来源、时间和命中记录。评测报告也应拆分疑似污染集与清洁集成绩，再加入实体替换、选项重排或重新命题后的对照结果。这样不仅能看分数高低，...

实际落地时，我更倾向于采用“常态延迟缩放、异常阶段快速更新”的混合方案。延迟缩放保证主流程效率，但在预热结束、学习率调整、序列长度或 MoE 路由明显变化时，临时切换到当前缩放或缩短历史窗口，能减少尺度滞后带来的饱和。监控方面，除了 loss 和吞吐，建议按层记录饱和率、零值率及 amax 波动，尤其关注梯度和少数离群通道。若硬件支持分块缩放，可以优先用于分布不均匀的激活或梯度，权重则未必需要同样...

我觉得“最大可输入长度”和“最大有效长度”的区分特别重要。实际评测时，除了画完整的困惑度长度曲线，还可以固定同一篇文档，只改变关键信息的位置和前置填充量，分别统计检索准确率与结果波动。这样更容易判断问题来自位置编码，还是文本难度、注意力稀释。另外，动态缩放方案最好补测批次长度变化下的一致性，否则离线指标不错，线上合批后却可能出现不稳定。选型时也应把原始窗口内的代码补全、数字复制等任务设为硬性回归门...

帖子分析得很全面。实际调优时，我觉得还可以补充一个观察点：分别统计通信提交时间、实际执行时间和被计算掩盖后的暴露时间，否则只看 NCCL 耗时容易误判。另一个关键是固定全局批量与梯度累积步数做对照，避免吞吐变化其实来自训练配置调整。跨节点 TP 最好结合拓扑做 Rank 编排，让组内通信尽量走同一网络层级，并重点检查尾部延迟，而不只是平均带宽。融合参数也建议按模型阶段分别测试，Attention ...

实际调优时，我觉得最容易被忽略的是“可训练长度”和“吞吐扩展”并不是一回事。增加并行度可能解决显存问题，但若本地序列块太短，通信延迟和同步等待很快会抵消收益。除了观察平均步耗时，建议用性能分析工具分别统计注意力计算、通信暴露时间和最慢卡等待时间，并区分节点内、跨节点结果。若跨节点 all-to-all 波动较大，可先限制并行组在高速互联域内；采用环形交换时，则重点检查双缓冲是否真正形成计算通信重叠...

负载均衡确实不能只看“每个专家分到多少 token”，还要结合路由熵、溢出率和设备等待时间一起判断。个人觉得按层观察负载变化尤其重要，全局平均可能很好看，但某一层已经出现专家坍塌。调参时可以先用温和的辅助损失稳定路由，再根据溢出率调整容量因子，同时监控主损失，避免为了均匀而牺牲专业化。另外，路由器的学习率、计算精度和 logits 尺度也值得单独记录。若能进一步展示不同均衡权重下的专家利用率、吞吐...

实际部署中，建议先做一张显存拆分表，把权重、KV 缓存、临时张量和框架预留分别统计，否则很容易高估量化收益。我更倾向先从 8 位开始验证，再根据最长上下文和并发目标尝试 4 位。测试集里最好专门加入“信息埋在文档前部、问题出现在末尾”的样例，因为普通困惑度未必能暴露长距离检索退化。另外，吞吐提升不能只看显存余量，还要关注反量化和数据搬运成本；如果算子没有融合，低位缓存可能省了容量却增加单 toke...

我觉得生产环境里还应关注“拒绝发生的位置”，而不只是整体接受率。相同的接受比例，如果多数候选在首个 Token 就被拒绝，草稿计算基本都浪费了；如果通常先接受数个 Token，实际加速效果会好很多。评测时可以按提示长度、采样温度和任务类型分桶，分别统计平均接受长度、每轮耗时及 P95 延迟。候选长度也适合做成动态策略，例如连续多轮高接受就逐步加长，频繁早拒绝则及时缩短。至于输出一致性，最好区分统计...

我觉得关键不在于把低置信度样本全部删掉，而是先区分“明显错误”和“困难但有价值”。前者确实会污染监督信号，后者却可能包含长尾知识、复杂推理路径和多样表达。实际落地时，可以给高置信度样本较高权重，同时从中低置信度区间保留一部分经验证的样本，并按数学、代码、开放问答等领域分别设定标准。评估也不能只看整体准确率，最好同步观察训练成本、困难任务表现、知识覆盖率和校准误差。这样才能避免学生模型变得更稳定，却...