第 7 名解决方案（纯属运气）

我很惊讶，我这个“随便试试”的提交在一周内就进入了本次竞赛的金奖区。虽然这纯属运气（公共榜 23 -> 私有榜 29），但我还是想分享一下我从这次竞赛中学到的东西。

任务与 GPU 资源

在本次竞赛中，我们获得了 4 张 L4 GPU 用于推理。好消息是 2025 年我们不用再忍受古老的 T4 了。坏消息是 L4 对于 LLM 解码来说也不是理想的选择——每张纸上内存带宽仅为 300GB/s，4 张 GPU 总共 1200GB/s。

长上下文解码（用于推理）和批量解码（用于多数投票）对于此任务都很重要。在这种推理设置下，随着上下文长度增长，KV 缓存可能成为主要瓶颈（大于模型权重），进一步增加了对 GPU 带宽的需求。

推理引擎

我测试了 LMDeploy、SGLang 和 vLLM 的推理速度。使用 4-bit 量化权重和 fp16 KV 缓存，速度排名为：LMDeploy > SGLang > vLLM v1 >> vLLM。
LMDeploy 支持 int8/int4 KV 缓存量化，而 SGLang 和 vLLM 提供 FP8 KV 缓存量化。使用 KV 缓存量化可以在相同的时间预算内实现更大的解码批量大小。
不幸的是，int4 KV 缓存量化导致准确率损失太大，所以我最终选择了带有 int8 KV 缓存量化的 LMDeploy 进行推理。

提交策略

在提交之前，我分析了不同批量大小下解码到 16k tokens（最坏情况）的推理时间。在实际提交期间，我跟踪了每个问题的实际推理时间，然后将 计划时间 - 实际时间 加入到下一个问题的时间预算中。下一个问题的批量大小是根据那个新的时间预算和我早期的分析结果选择的。

这是一个相当保守的策略，对先收到的问题使用较小的批量大小。而且我没有针对更长的最大解码长度进行分析，所以还有改进空间。

推理 Notebook 公开在 这里。只是一个使用 casperhansen/deepseek-r1-distill-qwen-14b-awq 和我的提交策略的匆忙实现。我没有做足够的测试，所以可能存在 bugs。