我先复查了 Issue #52 已有实现和前期 PR，随后在 VisDrone 上重新跑通了剪枝、LoRA10 恢复和动态调度三组对照。复现过程中遇到两个会改变实验结论的统计问题：路由利用率只保留最近一次快照，以及 recovery 后同一个 epoch 被重复计入调度。下面给出修复方法、完整测量结果和我对这些结果的判断。
1. 实验问题
0.05 / 0.10 / 0.15 / 0.20 / 0.30 五档阈值是否真的产生不同物理结构；- 剪枝后的 10-epoch LoRA 恢复能否补回精度，同时保留资源收益；
- 基于专家利用率 Gini 的动态平衡损失调度能否改善收敛或稳定性；
- 训练发生 recovery/retry 时，事件计数和调度状态是否仍然可信。
2. 实验约束
- 数据集：VisDrone，训练集/验证集分别为
6471/548 张图；
- 校准集：训练集确定性 10% 子集，seed 42，实际选中并观测
647/647 张图、81 batches、32527 instances；
- 校准信号：soft contribution，并将 signal 与输入 checkpoint SHA-256 绑定；
- 延迟：同一单卡硬件类别、FP32、batch 1、640×640、仅模型 forward，采用双顺序测试，每个顺序 50 次 warmup、500 次正式采样；
- 动态对照：相同 seed、数据、batch、输入尺寸和初始模型状态 SHA-256。
过程中确认了两个容易导致误判的问题：验证路径不会按预期应用 fraction，因此正式校准使用显式确定性图片清单；如果符号链接解析到源目录，还可能破坏图片与标签映射，因此正式产物同时校验选中样本、实际观测样本和非空标签。
3. Gini 动态调度
动态组在一个 epoch 内累计全部 batch 的专家利用率，对逐层 Gini 取均值并更新：
ema_t = beta * ema_(t-1) + (1 - beta) * gini_t
coeff_(t+1) = clip(
base_coeff * exp(alpha * (ema_t - target_gini)),
min_balance_coeff,
max_balance_coeff
)
当路由更集中时提高 balance-loss 系数；当路由较均衡时降低系数，为专家分化保留空间。该功能默认关闭。
调度采用 accepted-epoch 语义：只有 epoch 通过验证和 recovery 检查后才提交调度状态与 trace。被 recovery 拒绝的 epoch 会清空统计，但不会推进 EMA、事件计数或 trace。
4. 专家剪枝结果
五档逻辑阈值实际只形成两种物理结构：
0.05–0.20：均为 no-op，专家数保持 3/3/3/3；0.30：唯一非平凡结构，专家数变为 2/2/3/3。
| 方案 |
专家结构 |
mAP50-95 |
mAP50 |
P95 forward |
Params |
GFLOPs |
| Dense baseline |
3/3/3/3 |
0.203575 |
0.350382 |
13.379 ms |
2.653 M |
8.49 |
| Threshold 0.30 direct |
2/2/3/3 |
0.123546 |
0.242145 |
13.210 ms |
2.625 M |
7.89 |
阈值 0.30 的 mAP50-95 相对下降约 39.3%，而 P95 model-forward 只改善约 1–2%。在绝对 mAP50-95 降幅不超过 0.01 的预设约束下，没有可接受的 Sweet Spot。
.05–.20 仍作为五档逻辑实验保留在机器可读结果中，但不能把同一个 no-op 结构解释为四种不同优化结果。
5. LoRA10 恢复
仓库当前的原生 LoRA 路径实际训练 adapters 和 detection head，结果表按这一训练范围记录。
| 方案 |
Best mAP50-95 |
Final mAP50-95 |
P95 forward |
GFLOPs |
| Baseline LoRA10 |
0.181443 |
0.00491 |
22.103 ms |
10.81 |
| Pruned LoRA10 |
0.142967 |
0.00946 |
22.024 ms |
10.20 |
恢复没有达到原始 dense baseline 0.203575，还增加了推理计算和延迟。两组训练后期都出现质量坍塌，因此不能只报告 best checkpoint 而忽略 final checkpoint。
6. 动态调度三组对照
修正后的动态组严格生成 epoch 1..10 共 10 条 accepted-epoch trace。每轮包含 3236 = 4 × 809 次路由观测，最终：
opportunity_count = 10
event_count = 10
nontrivial_action_count = 10
| 实验组 |
平衡策略 |
Best mAP50-95 |
Best epoch |
Final mAP50-95 |
| Fixed Baseline |
固定 1.0 |
0.03551 |
4 |
0.00750 |
| Gini Dynamic |
EMA 指数调度 |
0.04144 |
6 |
0.00905 |
| Fixed-Low Ablation |
固定 0.3 |
0.03950 |
4 |
0.00493 |
动态组平均/最终 Gini 为 0.04615/0.01058，平均/最终 balance-loss 系数为 0.82399/0.80416。
三组都出现明显 late-stage quality collapse，最终 mAP50-95 仅为各自最佳值的 21.1%、21.8% 和 12.5%。由于固定基线最终值已经坍塌，三组都在 epoch 1 达到“Issue 所定义的基线最终精度 95%”，形式上的收敛比例均为 1.0，但该指标不再具有科学区分力。
动态组在这个单 seed、10-epoch 实验中的最佳值和最终值略高于固定基线，只能视为候选现象，不能证明收敛加速或稳定质量收益。
7. 场景化建议
- 服务器端：当前五档阈值中没有满足质量门槛的非平凡剪枝点，建议保持 no-op；
- 边缘端：
.30 的质量损失远大于当前 PyTorch forward 延迟收益，也不建议使用；
.10/.20 当前没有发生物理剪枝，因此不单独列为部署配置。
8. 代码和实验脚本
- 完整 epoch 的路由利用率累计；
- accepted-epoch 调度与 recovery-safe trace；
opportunity/event/nontrivial-action 三类事件计数；- signal/checkpoint SHA-256 绑定；
- 物理剪枝后专家、router 与
top_k 的结构检查；
- 五档逻辑阈值到唯一物理结构的去重执行；
- 双顺序延迟 benchmark；
- 5×2 结果组装与三目标 Pareto 分析；
- 没有可行点时明确返回“未观察到 Sweet Spot”。
当前整合分支相关回归：
代码与复现材料：
9. 结论与限制
这组实验没有给出适合边缘端或服务器端的剪枝阈值，动态调度也没有表现出稳定的收敛优势。比较确定的结论是：当前信号、阈值和恢复配置还不足以形成可部署的 Sweet Spot。配套脚本保留了完整测量记录，也允许最终结果为“没有推荐点”。
这组数据来自 VisDrone、单 seed、10-epoch 动态短实验和单一 GPU 硬件类别。下一步应先得到稳定的长周期基线，再进行多随机种子验证，并预先定义一个不依赖 collapsed-final checkpoint 的收敛目标。
欢迎维护者对提交拆分、稳定基线和后续实验优先级提出建议。
我先复查了 Issue #52 已有实现和前期 PR，随后在 VisDrone 上重新跑通了剪枝、LoRA10 恢复和动态调度三组对照。复现过程中遇到两个会改变实验结论的统计问题：路由利用率只保留最近一次快照，以及 recovery 后同一个 epoch 被重复计入调度。下面给出修复方法、完整测量结果和我对这些结果的判断。
1. 实验问题
0.05 / 0.10 / 0.15 / 0.20 / 0.30五档阈值是否真的产生不同物理结构；2. 实验约束
6471/548张图；647/647张图、81 batches、32527 instances；过程中确认了两个容易导致误判的问题：验证路径不会按预期应用
fraction，因此正式校准使用显式确定性图片清单；如果符号链接解析到源目录，还可能破坏图片与标签映射，因此正式产物同时校验选中样本、实际观测样本和非空标签。3. Gini 动态调度
动态组在一个 epoch 内累计全部 batch 的专家利用率，对逐层 Gini 取均值并更新：
当路由更集中时提高 balance-loss 系数；当路由较均衡时降低系数，为专家分化保留空间。该功能默认关闭。
调度采用 accepted-epoch 语义：只有 epoch 通过验证和 recovery 检查后才提交调度状态与 trace。被 recovery 拒绝的 epoch 会清空统计，但不会推进 EMA、事件计数或 trace。
4. 专家剪枝结果
五档逻辑阈值实际只形成两种物理结构：
0.05–0.20：均为 no-op，专家数保持3/3/3/3；0.30：唯一非平凡结构，专家数变为2/2/3/3。3/3/3/32/2/3/3阈值
0.30的 mAP50-95 相对下降约 39.3%，而 P95 model-forward 只改善约 1–2%。在绝对 mAP50-95 降幅不超过0.01的预设约束下，没有可接受的 Sweet Spot。.05–.20仍作为五档逻辑实验保留在机器可读结果中，但不能把同一个 no-op 结构解释为四种不同优化结果。5. LoRA10 恢复
仓库当前的原生 LoRA 路径实际训练 adapters 和 detection head，结果表按这一训练范围记录。
恢复没有达到原始 dense baseline
0.203575，还增加了推理计算和延迟。两组训练后期都出现质量坍塌，因此不能只报告 best checkpoint 而忽略 final checkpoint。6. 动态调度三组对照
修正后的动态组严格生成 epoch
1..10共 10 条 accepted-epoch trace。每轮包含3236 = 4 × 809次路由观测，最终：1.00.3动态组平均/最终 Gini 为
0.04615/0.01058，平均/最终 balance-loss 系数为0.82399/0.80416。三组都出现明显 late-stage quality collapse，最终 mAP50-95 仅为各自最佳值的 21.1%、21.8% 和 12.5%。由于固定基线最终值已经坍塌，三组都在 epoch 1 达到“Issue 所定义的基线最终精度 95%”，形式上的收敛比例均为
1.0，但该指标不再具有科学区分力。动态组在这个单 seed、10-epoch 实验中的最佳值和最终值略高于固定基线，只能视为候选现象，不能证明收敛加速或稳定质量收益。
7. 场景化建议
.30的质量损失远大于当前 PyTorch forward 延迟收益，也不建议使用；.10/.20当前没有发生物理剪枝，因此不单独列为部署配置。8. 代码和实验脚本
opportunity/event/nontrivial-action三类事件计数；top_k的结构检查；当前整合分支相关回归：
代码与复现材料：
9. 结论与限制
这组实验没有给出适合边缘端或服务器端的剪枝阈值，动态调度也没有表现出稳定的收敛优势。比较确定的结论是：当前信号、阈值和恢复配置还不足以形成可部署的 Sweet Spot。配套脚本保留了完整测量记录，也允许最终结果为“没有推荐点”。
这组数据来自 VisDrone、单 seed、10-epoch 动态短实验和单一 GPU 硬件类别。下一步应先得到稳定的长周期基线，再进行多随机种子验证，并预先定义一个不依赖 collapsed-final checkpoint 的收敛目标。
欢迎维护者对提交拆分、稳定基线和后续实验优先级提出建议。