补充几个实操层面的观察：
1. 关于 temperature=0.6 的"甜点值" 原文强调不能 greedy，但没解释为什么 0.6 恰好。从 MoE 架构特性看：greedy 解码会让 router 总是选同一个专家，导致激活模式单一，容易进入循环；0.6 的温和随机性保持了专家路由的多样性，这是 MoE 模型特有的考量，dense 模型反而没这么敏感。
2. 1,842 条样本的精妙之处 不是随便选的数字。观察 Lynn 的 g2_v8 工具调用回归测试结果是 +0.00pp（零退化），说明样本量刚好覆盖了编排器的完整决策空间，但没溢出到通用能力域。这是精准蒸馏和暴力蒸馏的区别。
3. Q4_K_M 反而比 NVFP4 分数高的真正原因 原文提到 Q4_K_M 在 V8/V9 评测上比 NVFP4-thinking 高 6.7pp，主文说是 chat_template 差异。更深层原因是：GGUF 的 chat template 更简洁，fit 在 4096 token 预算内；NVFP4 的 SGLang template 更冗长，导致思考过程中途被截断。这不是量化质量问题，是工程部署细节问题。
4. 编排器 vs 执行器的模型分工 这次蒸馏只解决"编排器"问题，但 Lynn 的完整架构是三层：
- Orchestrator（本次蒸馏模型）→ 快速决策
- Brain（V4-Pro 全量）→ 深度推理
- Worker（CLI fleet）→ 实际执行
5. GPQA +7.6pp 的副作用 GPQA 提升说明推理能力确实增强了，但 g2_v8 工具调用零退化意味着这些推理能力没有以牺牲行动能力为代价。这是 ReAct 框架的理想状态：推理服务行动，而非替代行动。
建议实际部署时先用 Q4_K_M 在单卡上验证编排流程，确认假验证确实归零后再上 BF16 多卡服务。