一、赛题理解与总体思路我们是本次华为“揭榜挂帅”赛道的“全都对队”，我们在本次比赛中取得了擂主奖项。在对赛题进行分析时，我们意识到，面对的是一项覆盖 训练—推理—算子级优化 的全流程性能挑战。赛题要求选手不仅能调优模型效果，更需深入昇腾 NPU 底层，对推理链路进行系统级重构。我们的判断是：只有从训练端减负、推理端提效、算子端深挖三个层面同时发力，才能在 NPU 上发挥出模型的极致性能。二、训推一体：从源头降低计算压力我们先从训练侧着手，目标是在不显著牺牲精度的前提下，减少模型在推理阶段的无效计算。SFT 阶段的输出规范化在 SFT 中，我们将 CoT（Chain-of-Thought）和最终答案严格约束为比赛指定格式，使模型从训练阶段就习惯于“结构化回答”。强化学习阶段加入长度惩罚在 RL 中，我们设计了带 长度惩罚项 的 Reward Function：冗余输出将触发指数级负奖励。这种训练策略促使模型自然收敛为“简洁表达”。实验显示：输出 Token 数量减少约 30%，有效降低了推理端的算力压力，同时保持了接近原精度。三、底层打磨：深度利用 CANN 软件栈在推理侧，我们利用 CANN 软件栈，对算子、图模式、内存等维度进行了深入优化。启用 torch.npu 图模式小 batch 推理时，算子下发的开销会显著影响吞吐。我们将 PyTorch 动态图编译为 NPU 静态计算图：原理： 将执行流固化，使编译器能够进行更激进的融合与调度优化。收益： 消除 Python Launch Overhead，并提升算子融合、内存复用效率。FFN 多算子融合我们基于 CANN 自定义算子，将 FFN 中若干线性变换与激活操作 融合为单一 Kernel，从而显著减少 NPU 显存 ↔ 计算单元之间的往返。四、架构级创新：推理吞吐的倍增策略在推理架构层，我们通过引入新技术与调整策略，突破了吞吐瓶颈。EAGLE 3 投机解码传统自回归逐 Token 解码速度受限。我们采用 EAGLE 3 架构：Draft Model 并行生成候选序列；大模型一次性并行验证。结果： 在不损失精度的前提下，解码速度提升约 1.5 倍。取消 Chunked Prefill（基于赛题场景的反直觉选择）行业内常用 Chunked Prefill 用于降低单次 Prefill 对延迟的影响，但它并不提高硬件利用率。在本次评测“侧重高吞吐、并行请求充足”的条件下，Prefill 拆分反而带来调度开销，降低整体 TPS。因此我们选择完全关闭 Chunked Prefill，吞吐量得到提升。KV Cache 前缀缓存 + 输入截断针对赛题大量重复 System Prompt，我们引入 Prefix Cache：相同前缀自动复用 KV Cache，免去重复计算。严格控制输入长度，避免少量长尾请求拖慢整个 Batch。五、效果验证与最终成绩通过“算法优化 → 架构创新 → 底层算子融合”的三级联动，我们实现了最终性能突破：吞吐性能： B 榜达到 707 tokens/s，排名第一。输出质量： 在严格格式约束下，模型保持精度且无冗余废话。关键经验：性能优化必须坚持 算法—系统—硬件协同设计（Co-Design），任何单一层面的调优都难以实现全局最优。结语技术优化永无止境。本次比赛中，感谢老师的指导、队友的投入，以及华为云成熟的算力基础与 CANN 生态。未来，我们将继续探索 NPU 推理优化的更多可能，为大模型的真实应用场景带来更高效的系统性能。

比赛缺少仿真参数，但是又官方限制了若干阈值，如-108，-110。总所周知，仿真参数不同，信号强度大相径庭，难以和官方仿真平台中的结果贴合。感觉比赛不是很合理

假设有一条SQL: select * from t1,t2 where t1.id=t2.id 是否可以通过某种方法，实现只对其中的t2表开启并行处理？

鲲鹏920的64核云实例在高并发场景（如Web服务器、大数据处理）下，如何通过NUMA绑定或调度策略减少核间延迟？

     我最近开发了一个maven项目，想使用spark读取/写入greenplum的数据，但是由于jdbc的传输速度限制。所以想采用greenplum-spark connect这个连接器。当我使用--jars将项目和这个依赖包一起提交上去的时候出现了jar包冲突 报错:classnotfound。  同时自己搭建了一套开源集群，相同的步骤 spark读取/写入greenplum 并且也使用这个连接器--jars提供第三方依赖包，正常读取数据。    所以我想有没有办法忽略集群中的依赖。只使用fat-jar和--jar提供的