第 20 名解决方案 - 使用 32b 模型生成大量代码

我看到目前发布的 10 个排名更高的解决方案都在使用 14b 模型，并且（除了顶级解决方案外）它们似乎都专注于生成足够长的推理路径，以便最终生成文本（框选）答案。

我的解决方案略有不同。我使用的是 32b 模型，并且放弃了尝试生成足够多的 token 来获得框选答案。
相反，在 5k-6k token 处，我强制模型多次生成代码。每个任务总共生成多达 108 个 Python 程序。
最终答案的选择不是通过多数投票，而是通过具有精心选择权重的加权算法。

如何在本地运行：

1. 将单元格 2 中的问题集（不含第一行）复制到相应的文件（dq_data5e.py 或 dq_data4h.py）。
2. 将单元格 3 中的代码（以 T = True 开头）复制到文件 solve.py。
3. 更改为：
   submit = F
conf_pc = T
4. 将 llm_path 更改为模型的位置。
5. 将 prior_time_per_task 设置为之前运行的每个任务的平均时间，或者设置 use_control = F。
6. 使用以下命令运行：
   python3 solve.py save_dir=1 save_prefix=A runs=1 gpus=0,1
   每次运行更改 save_prefix。

工作原理：

快速总结：

• 使用 vLLM 服务的 32b 模型
• 从初始 7 个提示开始
• 每个任务生成多达 108 个程序，以及多达 9 个框选答案
• 在大约 7k token 后结束生成
• 平衡框选答案和代码答案的重要性
  • 缩小具有长公共前缀的代码答案组的权重（降低重要性）
  • 对于相同的框选答案和代码答案给予大量奖励
  • 对短代码进行惩罚
  • 对答案值较小进行惩罚

此外：

• 温度从 0.7 降低到 0.2，代码生成温度为 0.15
• 某些提示在强制生成代码之前重写问题
• 某些初始提示要求 LLM 首先用数学符号重写问题
• 利用 async-await 在 12 秒超时的情况下运行代码，同时由 LLM 生成文本
• 自适应控制根据剩余时间和每个任务使用时间的正则化估计来选择生成的最大 token 数

在生成代码的同时，我继续生成推理路径，有时这会给出一个很好的框选答案。
我构建启动提示的方式使得所有未完成的推理路径和最后一波未完成的代码块在同一 token 数处结束，因此生成的 token 树在固定深度被切断。
这一切都很快，因为 vLLM 可以重用具有相同前缀的提示的 KV 缓存条目。

该程序自动为更简单的任务使用更少的时间，因为如果 LLM 早期返回框选答案，那么整个子树将更快生成，这将加快生成剩余子树的速度。

我使用了一个在该竞赛中流行的来源的模型，未经微调：
https://huggingface.co/casperhansen/deepseek-r1-distill-qwen-32b-awq
这是蒸馏到 Qwen 2.5 架构的 Deepseek R1，具有 320 亿权重，采用 4-bit AWQ 量化。

明显的潜在改进：

• 使用更好的模型。该代码适用于任何大小的模型，只需调整常数 prior_time_per_task。
• 截至目前，LLM 推理引擎尚未充分利用多个 GPU，特别是当使用较小的草稿模型进行推测性解码时，两个模型都量化为 4-bit。此处 token 生成速度应该可以提高 2 倍以上。