Files
CTI-Inference-Opt/docs/superpowers/specs/2026-06-14-cti推理优化-design.md
T
OwnerSunshine530 33cb814653 docs: 添加冲击80+设计文档(AUC优先 + 结构性延迟重写)
核心结论:评分公式经两次提交验证,延迟分上限70、模型分上限~9.9,
故纯降延迟天花板~79.9;80+必须靠提升验证集AUC。方案C:阶段A找回AUC
(sign-id取模/精度摆放/expert合并代价/特征与上下文完整性)优先,
阶段B结构性延迟重写(块对角注意力/MoE向量化/embedding融合/加batch)。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-14 16:38:38 +08:00

7.8 KiB
Raw Blame History

CTI 2026 推理优化 —— 冲击 80+ 设计文档

日期:2026-06-14 赛题:百度商业 AI 技术创新大赛 — 生成式推荐广告排序推理性能优化 当前最优:58.86(延迟 86.5s / AUC 0.7526 / PCOC 1.059 目标:榜上 ≥ 80


1. 核心结论:80+ 必须靠 AUC,不能只靠延迟

队伍重构的评分公式已用两次真实提交验证,几乎完全吻合:

score_latency = max(0, (300 - latency) / 300)
score_model   = ((AUC - 0.65) * 1000 + (0.15 - |PCOC - 1|) / 0.15 * 10) / 360
score_all     = score_latency * 70 + score_model * 30      # 仅当两项 > 0
提交 延迟 AUC PCOC 公式算分 实际
基线 229s 0.759 1.110 25.87 25.85 ✓
最优 86.5s 0.7526 1.059 58.88 58.86 ✓

硬推论:

  • score_latency 上限 = 70(仅当 latency → 0,物理不可能)。
  • 以模型自然 AUC ≈ 0.759、PCOC 完美计,score_model 上限 ≈ 9.9。
  • 绝对天花板 ≈ 79.9;现实里延迟压到 ~10s 也只有 ~77。

因此 80+ 必须有一部分来自比 0.7526 更高的 AUC(在验证集上算)。榜上 80+ 的队伍一定是又快、AUC 又更高。当前队伍把全部精力投在延迟(58.86 中 49.8 来自延迟),而 30 分的模型桶几乎没动 —— 这正是通往 80+ 的缺口所在。

前提需被证实/证伪:上述天花板说明验证集上模型真实可达 AUC 必然明显高于 0.7526,即当前推理把 AUC 压低了;否则若验证集真实 AUC 也仅 ~0.76,则「80」这一目标本身需与队友及官方答疑再核对。阶段 A 第一步(FP32 参考跑)就是用来验证这个前提的。

2. 策略:方案 C —— 两条腿一起,AUC 优先

先做阶段 A(找回 / 最大化 AUC + PCOC 校准),再做阶段 B(结构性延迟重写),每一步都过本地测量关卡,确保不会用一次提交去赌一个回归。数学上只有 A+B 一起才能越过 80。

3. 约束与环境(来自官方规则)

  • 硬约束(违一即 0 分):延迟 < 300s(只计 model(batch) 逐 batch 累加);AUC ∈ [0.65, 1.0]PCOC ∈ [0.85, 1.15];压缩包无 dataset/、无 ckpt.pt、文件在根目录、后缀为 .zip/.tar.gz/.tar;每天最多 10 次提交;build_env.sh ≤ 720s。
  • 允许:量化(FP16/INT8)、Flash Attention(数学等价)、非结构化剪枝/稀疏(权重置零、形状不变)。
  • 禁止:改层数 / 维度 / head 数 / FFN channel(结构化改动);序列采样或截断;对测试集训练。
  • 评测环境NVIDIA A80080GB, SM80),Python 3.10 + PyTorch 2.6.0。评测数据集 ≠ 本地基线数据集(AUC 天然有差异)。最终人工审核合规性。
  • 实验环境AI Studio notebook + GPU,可加载 dataset 与 ckpt.pt,可本地自评 AUC/PCOC 后再提交。

4. 设计 · 第 1 节:测量闭环(地基)

在 notebook 里建一个带 instrumentation 的统一入口:

  • 诚实计时model(batch) 前后加 torch.cuda.synchronize()。当前代码未同步、CUDA 异步,本地延迟数字不可信。
  • 配置开关板:独立开关每个变换 —— fp16 开/关expert_merge 开/关signid clamp/取模特征截断 开/关;一次运行打印 AUC / PCOC / 延迟 / 总分。
  • 锁定 FP32 参考跑:先复现官方基线(FP32、不合并 expert、不截断),确立模型真实可达 AUC,作为天花板目标。

说明:本地测试集 AUC(~0.759)只是验证集 AUC~0.7526)的代理,但改动方向可迁移 —— 本地是便宜信号,提交做最终确认。

5. 设计 · 第 2 节:阶段 A —— 找回 AUC(30 分桶)

按顺序做消融,每步过闭环;凡能提升(或不降低)AUC 的就保留:

  1. Sign-ID 处理(头号嫌疑):查 max_sign_id 与 5M 词表关系。values.clamp(0, max_idx) 把所有超界 ID 压到第 4,999,999 行;若训练用取模哈希,clamp 即与训练不一致、污染大量 embedding,可能是大幅 AUC 损失。对比 clamp vs % vocab_size
  2. 精度摆放Embedding、最后 linear 头、LayerNorm 保留 FP32,仅大矩阵乘走 FP16;对比一刀切 .half() 找回多少 AUC。
  3. Expert 合并代价:测其真实 AUC delta;只换延迟,掉 AUC 即砍掉。
  4. 特征完整性:核对 max_feasign_per_slot={1:2} 及任何 max_ctx_len 截断,确认没丢有信息量的特征/历史。
  5. 上下文完整性:确认每条测试样本 attend 到该用户完整历史(因果 mask packing 正确、历史按 userid 正确挂上)。

目标:把有效 AUC 从 0.7526 拉向真实天花板。每 +0.01 AUC ≈ +0.83 分,且是唯一突破 ~78 的杠杆。

6. 设计 · 第 3 节:阶段 B —— 结构性延迟重写(86.5s → ~15–25s

之前失败的是高层魔法(torch.compile、INT8)。真正的硬骨头是热点结构,按收益排序,只碰计算顺序/内核,不碰数学结果

  1. 注意力 mask(最大单点):当前每 batch 现造稠密 S×S bool mask 喂 SDPA稠密 attn_mask 会让 Flash/cuDNN 退回低效路径(Flash 名义开、实际没生效)。序列按用户 packing,应改为块对角 + 块内因果per-user block-diagonal causal),让 SDPA 走快路径。
  2. MoE 向量化:消掉每层 8-expert 的 Python 循环、每 expert 的 .nonzero() 与隐含 GPU 同步,改分组 GEMM / 批量 expert 计算。
  3. Embedding 池化融合:每 batch 串行 28 次 segment_reduce → 融合为更少 kernel;处理 slot 19 重复 sign(去重 × 计数,等价省带宽)与 slot 28 瓶颈。
  4. 加大 batch:50 → 更大(盯显存),摊薄 2039 batch 的 launch 开销。
  5. 重估 torch.compile / CUDA Graph:图理干净后再试;CUDA Graph 用「按序列长度分桶」绕开变长形状限制。

目标:~15–25s;每步仍用闭环验证 AUC 不变。

7. 设计 · 第 4 节:PCOC 校准(低优先、免费零头)

PCOC 当前 1.059 已在区间内。对预测做单调缩放/偏移(temperature/bias),不改 AUC(单调变换不影响排序),把 PCOC 推向 1.0,约 +0.33 分并降低踩红线风险。校准只在带标签的历史数据上做,绝不碰测试集。收益小,标记为可选,提交前确认合规。

8. 设计 · 第 5 节:合规与提交纪律

  • 每个改动先分类:改权重数值(量化/稀疏/剪枝 / 改结构(/ 用测试集训练()。Sign-ID 处理与上下文组织必须与训练一致,否则不是「同一个模型」。
  • 提交预算:10 次/天;先用本地闭环卡住,只提交本地确有提升的候选;维护提交日志。
  • 人工审核风险:避开任何像「钻计时空子」的做法(如靠异步不同步虚报延迟)。
  • 保底:永远留一个已知能跑、不为 0 的回退提交(当前 58.86 版本)。

9. 设计 · 第 6 节:成功标准

  • 主目标:榜上 ≥ 80。
  • 过程关卡(a) 本地复现 FP32 基线 AUC,确立真实天花板;(b) 找到 ≥1 个值 ≥0.01 AUC 的找回杠杆;(c) 延迟 ≤ 25s(d) PCOC ∈ [0.95, 1.05]。
  • 硬约束全程不破AUC ≥ 0.65、PCOC ∈ [0.85, 1.15]、延迟 < 300s、压缩包规范。

10. 风险与未决项

  • 核心前提待验证:验证集真实可达 AUC 是否显著 > 0.7526。FP32 参考跑给出本地答案;首次「找回 AUC」候选的提交给出验证集答案。若证伪,需重新校准「80」目标并与队友/官方答疑核对。
  • 延迟与 AUC 的张力FP16、expert 合并等换延迟的手段可能掉 AUC;以 AUC 为先,延迟从不损精度的结构性重写中补。
  • 本地 ≠ 验证集:本地分数仅作方向信号,最终以提交为准。