第五名解决方案

首先，我要衷心感谢 XTX Markets 和 Kaggle 举办了这场精彩的竞赛。组织如此质量和规模的活动是一项重大的工作。我也向所有参赛者的 dedication 和贡献表示赞赏。

解决方案详情 (运气 + 14b-awq + lmdeploy):

• 公共榜单分数: 28
• 私有榜单分数: 29
• 模型: Deepseek-R1 Distill-Qwen-14B-AWQ (HuggingFace 链接 - MIT 许可证)
• 推理服务器: lmdeploy (GitHub 链接 - Apache 2.0 许可证)
• Notebook: Kaggle Notebook 链接
• 关键参考: Vladimir Demidov 的公开 Notebook
• HF Endpoints 的 E2E 处理程序: HuggingFace 链接
• 计算资源 (达到获胜提交所需): Kaggle 的 L4x4 GPU (每周 15 小时)

概述

与 Vladimir Demidov 的公开 Notebook 相比，我使用了 DeepSeek-R1 Distill-Qwen 模型的 14B-AWQ 版本，并使用 lmdeploy 实施推理，相比 vllm 吞吐量提高了 28%。我从 imagination-research 团队分享的公开模型和讨论中学到了这些——非常感谢他们的见解。

我将第 5 名的成绩主要归功于幸运的环境，因为一个几乎相同的提交在公共榜单上只获得了 23 分。我与那些可能有更多贡献或开发了更强模型但未经历同样有利结果的人分享这一结果。希望每个人在未来的事件中都有机会受益于类似的幸运。

最后，我还分享了在本次竞赛中应用的一种模拟技术，它将评估计算从 O(N) 减少到 O(1)。为了避免潜在的提交浪费或轻微的性能下降，我直接采用了 Vladimir Demidov Notebook 中的答案提取/投票代码和提示（虽然我自己也有版本）。我非常感谢原作者的工作。

吞吐量

与 vllm 相比，lmdeploy 在 14b-awq 设置下将吞吐量提高了 28%。

• 吞吐量测试代码：Kaggle 链接
• 我在竞赛期间放弃了 vllm engine v1，因为我无法在公共榜单上用 engine v1 复现 Vladimir Demidov 的分数，并且论坛上也报告了准确性下降的问题。（后来，似乎过拟合才是实际原因。）
• 注意：根据 imagination-research 团队和 tascj 的优秀解决方案总结，使用 int8 kv 量化可以在不牺牲准确性的情况下进一步提高吞吐量。

细节与策略

运行细节:

• temperature: 0.9
• top_p: 0.9
• min_p: 0.05
• stop_words: ['</think>']
• batchsize: 9
• seqlen: 13500

策略:

• 为了避免复杂性，我对所有问题使用相同的 batchsize 和 cutoff 长度，只是为了确保整个运行在大约 4.5~4.7 小时内完成。
• 对于每个问题，9 个请求并发运行，并在 seqlen 13500 处截断。应用多数投票来获取答案。
• 注意：问题级别的早停策略可以节省大约 4.5~9% 的 token 而不损失准确性（见下一节）。然而，它可能会带来 bug，并且在竞赛期间在 lmdeploy turbomind 中实现它似乎很耗时，所以我没有应用它。

模拟

概述:

通过交替评估步骤，进行模拟可以帮助将计算资源从 O(N) 节省到 O(1)。它在竞赛期间帮助我节省了大量的提交和计算资源。

常规评估:

对于每个新方案：
    使用 llm 生成该方案的足够样本
    获得评估结果

模拟:

使用 llm 生成足够的样本作为“真值”
对于每个新方案：
    从“真值”中采样该方案的输出（直到评估结果收敛）
    获得评估结果

注意，模拟的第 1 步只需要进行一次，在评估新方案时不需要生成新的输出。此外，更多的样本会导致更准确的“真值”。

代码：Kaggle 链接

我进行模拟的目的包括：

• 网格搜索 - batchsize & seqlen
• 网格搜索 - temperature
• 估计早停的好处和损失

网格搜索 - Batchsize & Seqlen:

我经验性地使用 max_question_time = 410s 来估计 seqlen 和 batchsize，以确保整个运行在 4.5~4.7 小时内完成，结果如下：

• 模拟运行表明，最佳 (batchsize, seqlen) 位于 (10, 13300) 或 (9, 13800)。

网格搜索 - Temperature:

• 对于 14b 模型，Temperature 0.9 似乎比 temperature 0.8 具有可观察到的优势：

• 同时，temperature 0.85/0.95 似乎并不比 0.9 更好：

估计早停的好处和损失:

• 根据模拟，在 batchsize 9 时，激进的早停策略节省约 9% 的 token，而保守策略节省约 4.5%。当 batchsize < 12 时，激进策略和保守策略都没有准确性损失。

策略细节如下：

• 保守策略
  • 停止条件：running_requests + 2nd_most_answer <= 1st_most_answer
• 激进策略
  • 此外，停止条件：1st_most_answer >= current_answers * (80% - (current_answers - 5) / (batchsize - 5) * 30%)
  • 即，在线性插值之间：
    • 当获得 5 个答案时，4 个一致答案
    • 当获得所有答案时，50% 一致答案

失败的尝试

AWQ 增强

groupsize 128 -> 32: lmdeploy 不支持

定制 AWQ:

1. calib_data:
   • mit-han-lab/pile-val-backup -> 来自 lightr1-stage2.json 的选择性样本（感谢 LightR1 团队的工作），问题 + 解决方案
2. max_calib_data_seqlen:
   • 512 -> 20000
3. 增加样本数

注意：虽然原始 AWQ 论文显示 AWQ 对校准数据具有鲁棒性且不需要大规模数据，我还是做了一次尝试。

AIME25 结果显示，带有 8 个校准样本的 14b-awqv2（即定制 AWQ）表现优于 14b-awq-casperhansen。然而，在我 few 次提交尝试中，它未能超越 14b-awq-casperhansen。

SFT

我未能进行 SFT，因为推理任务的序列长度太大，没有足够的 GPU 显存来适应，即使使用 lora 也会导致 GPU OOM。

无法复现公开 Notebook

我无法在自己的代码中复现 Vladimir Demidov 的 Notebook 分数。我花了 20 次提交，二分查找代码差异，最终发现以下任一更改都会导致分数从 23~26 下降到 18~21：

1. 仅将 vllm engine 从 v0 更改为 v1
2. 仅使用不带 seed 的 vllm-0.6.3.post1 engine v0

致谢

最后，我想再次感谢 XTX Markets 和 Kaggle 举办了这场精彩的竞赛，感谢所有参赛者的 incredible 努力和 dedication。我也深深感谢在整个旅程中支持我的每一个人。他们的鼓励 truly invaluable。