SOAR 周冠军笔记 02｜曹议：我是如何给 AI 老师打下手，把进度条推进到 96% 的？

2026-03-12

编者按·进阶与见证

本周，我们见证了曹议选手的成功卫冕。如果说第一周是靠“权重量化”快速破局，这周他则在混合精度量化的细节里更进一步。

目前，冠军成绩距离最高悬赏奖的达成度已高达 96%。这最后的 4% 往往是最硬核的挑战，它考验着选手如何在压榨性能的同时，守住“精度红线”。下周我们是否能见证大奖正式解锁？值得期待！

除了深挖性能优化，本期笔记还有一个重头戏：曹议详细分享了他如何高效辅助 AI 老师进行编码。在处理复杂的算子优化和工程适配时，他总结了一套结构化的指令反馈流程，让 AI 真正成为提升效率的“副驾驶”，从而让自己能专注于核心架构的思考。

不管你是正在冲击榜单的选手，还是对 AI 辅助开发感兴趣的极客，相信本期的“工具流”经验都能给你带来不一样的启发。

作者介绍：曹议（SlightwindSec） 目前在某国产国产计算平台担任大模型（LLM）推理框架开发与模型性能优化工程师 。拥有两年以上一线工程经验，深耕推理加速 、低比特量化等关键技术领域。：以下是作者分享原文。：SORA 2026 第二周

非常荣幸卫冕周冠军。对手都很强大，夺冠实属不易。

工作之余参赛精力有限，这次我主要是给 AI “打下手”：由它构思方向并落地实现，包揽了大部分工作量，我也在这个过程中学到了很多。本文就来和大家分享这套由 AI 主导的推理性能优化流程与心得。

01 比赛规则回顾

比赛的核心目标是 保证模型正确率的前提下，尽可能压低推理耗时。

最终总分的计算公式为：(S₁×40% + S₈×30% + S∞×30%) × 正确性系数 C。其中，S₁、S₈、S_∞ 分别代表单并发、8 并发和不限并发三档压测场景的耗时得分。此外，正确性系数 C 是个严苛的阶梯惩罚项：正确率低于 97% 直接 0 分，达到 99% 以上才能拿到 1.0 的满分系数，中间区间会按比例打折。

02 模型结构代码优化

经过 Claude Code 的分析，我发现模型结构代码中存在一些可以压榨性能的空间。例如，LayerNorm 操作可以和残差连接进行融合，这里我们可以直接复用 SGLang 现成的融合算子。：此外，代码中频繁的类型转换操作也会带来额外的时延开销。原代码将 q、k 转为 FP32 进行 rotary_emb 计算，这样写是为了保证更高的精度，优化掉存在掉精度的风险：

orig_dtype = q.dtype

q, k = q.float(), k.float()

q, k = self.rotary_emb(positions, q, k)

q, k = q.to(orig_dtype), k.to(orig_dtype)

03 混合精度量化

上周我使用了 KV Cache FP8 量化，对模型精度影响极小，带来了近乎“免费”的吞吐量提升。然而，权重的 4-bit 量化虽然进一步拔高了吞吐，却导致精度出现了较大幅度的掉点。

为了解决精度问题，我尝试了一些其他的量化方式，并在实际推理过程中使用了混合精度，在精度掉点可以接受的情况下尽可能降低时延、提高吞吐量。

04 AI 工作流：Gemini 与 Claude 协同协作

这次比赛我主要借助了 Gemini 3.1 Pro（对话与 Deep Research）和 Opus 4.6（Claude Code）来完成任务。整体的配合流程如下：

1. 选择优化方向：首先把详细背景整理好发给 Gemini 3.1 Pro，让它列出一些可行的优化建议。自己选定想尝试的方向后，再让 Gemini 进一步详细拆解，并提供相关的参考资料和开源代码仓库。

2. 梳理 Prompt：明确了具体方向并掌握了初步信息后，开始构思给 Claude Code 的提示词。为了指令更明确，通常我会让 Gemini 帮我润色一下这段 Prompt，把逻辑理顺，描述得更清晰。

给 Claude Code 大佬“端茶倒水”：在本地路径下准备好需要参考的文本资料和代码仓，并在 Prompt 或 CLAUDE.md 中补充好对应的说明，为 Claude Code 提供充足的执行条件。

4. 代码落地与测试闭环：最后把任务交给 Claude Code。我会要求它在修改代码的同时，写好轻量级的时延和精度测试脚本。由于性能优化必须以精度达标为前提，所以每次改动后都会让它重新跑测试，形成完整的优化闭环。

下面举个简单的例子：

**任务目标**

基于当前环境中的 `sglang` fork 仓（支持 `MiniCPM-SALA` 新模型），进行通用性能分析与代码优化。

**性能评估标准**

通过执行 `python scripts/bench_offline.py` 并查看输出末尾的表格来评估性能。重点关注以下 $3 \\times 2 = 6$ 种组合场景：

* **数据类型**：长输入短输出（反映 Prefill 性能）、短输入长输出（反映 Decode 性能）。

* **Batch Size (BS)**：1、8、64。

**约束条件**

1. **稳定性与泛化**：目前的测试用例是简化的静态 Batch，但你的优化必须是通用的。绝对不能破坏库的现有正常功能，也不能导致真实服务化场景（持续发送复杂请求）的性能劣化。

2. **强制配置**：必须保持 `"disable_radix_cache": True`（绝对不可开启 radix cache）。

3. **允许的操作**：你可以修改源码、更改配置开启特性、编写性能采集脚本，或使用 `nsys` 等工具辅助性能分析。

**工作流要求**

1. **先问后做**：不要过度思考。每次准备修改代码或执行耗时测试前，先简单告诉我你的思路，**得到我同意后**再行动。

2. **文档记录**：每次行动并测出结果后，将操作同步记录到总结文档中。要求极简：用 1-2 行说明做了什么修改，用 1 句话总结测试结果（无论性能是否有提升都必须记录）。

请根据上述要求，开始你的探索和优化。第一步你打算怎么做？

致谢：感谢 SOAR 2026 组委会不仅提供了优秀的比赛平台，还在赛程中持续提供耐心的答疑解惑与坚实的问题支撑工作；同时也感谢 SGLang 团队的开源贡献。榜单上的每一次交替都让我感受到大家强悍的技术实力。比赛不仅是竞争，更是互相学习的过程。接下来的赛程还长，祝愿所有参赛选手都能不断突破极限，优化出更完美的结果！我也会继续优化，争取创造新的突破。

🌟 OpenBMB 社区的小伙伴们：

SOAR 2026 稀疏算子加速大奖赛正火热进行中，每周都有新挑战，实时榜单虚位以待 。如果你想在模型推理加速、算子级优化、量化技术上展示你的技术实力 ，我们诚挚邀请你入场参赛，与曹议及更多优秀的小伙伴同台竞技，共同挑战 MiniCPM-SALA 的推理极限！点击下图或访问大赛官网 https://soar.openbmb.cn/ 了解更多。