跳到正文

#DeepSeek

今日 3 条
今天10月2日周五
  1. InfoQ 中文82

    DeepSeek 开源昇腾平台基础设施组件，覆盖 TileLang、计算库与分布式通信库

    DeepSeek 宣布开源一组面向华为昇腾算力平台的基础设施组件，包括 TileLang 高级语言编译工具，以及 DeepGEMM、DeepEP、TileKernels、FlashMLA 和 DeepSelect 的昇腾平台实现。官方称这些组件与此前英伟达平台开源组件一一对应，覆盖矩阵运算、跨设备通信、常规向量计算与访存、稀疏注意力和数据筛选，并披露团队与华为共同推进基于昇腾 950 的 128 卡超节点方案，对计算和通信进行联合优化。 迁移价值不在“全部可用”，而在接口对齐程度与限制条件。DeepGEMM-Ascend 的 API 与 DeepGEMM 兼容，但昇腾版量化缩放因子存储格式与英伟达版不同；DeepEP Ascend 的公开 buffer API 对齐英伟达版并支持 FP8 数据分发，但流水线并行、上下文并行和数据并行的部分通信能力仍在开发中。FlashMLA 覆盖稀疏注意力的预填充和解码，但仓库中部分融合内核及稠密注意力内核仍仅支持 CUDA；DeepSelect 昇腾实现目前仅支持 BF16 输入。TileKernels 昇腾后端要求 CANN 9.2.0 及以上，DeepEP Ascend 也未验证其他昇腾代际或 CANN 版本。 事实是这批开源代码为昇腾环境提供了算子编写、计算和通信执行层可复用组件，且多数组件围绕昇腾 950 验证。推断是 API 对齐会降低已有 CUDA 调用代码的迁移成本，但数据布局、精度格式、算子覆盖和软件栈版本仍会决定实际可用性。猜测是这代表 DeepSeek 与华为合作从云端推理服务适配进一步下沉到编译工具与基础库联合优化，但完整模型部署效果仍取决于上层框架、模型实现和集群环境集成。

    推荐理由：若团队评估昇腾迁移，这篇把 API 兼容边界、精度格式差异和 CANN/硬件验证范围讲清了，能减少盲目复用。

  3. arXiv cs.AI78

    论文发现角色分工 QA 中推理链主要改变验证判断而非答案准确率

    这篇论文研究在角色分工 QA 流程中，reasoner 向 verifier 传递的 rationale 究竟提供了什么。作者在固定证据和候选答案的前提下，只改变跨边界传递的 rationale，并在 400 条 MuSiQue、HotpotQA 和 2WikiMultiHopQA 样本上用 DeepSeek 同时作为生成器和验证器进行测试。 结果显示，忠实 rationale 相比不传 rationale 对答案准确率几乎没有提升；但被破坏的 rationale 会显著改变 verifier 对支持关系的判断。盲验证提示下，无害改写只让支持判断偏移 0–2.5%，破坏性 rationale 则偏移 10–22%；显式 rationale-checking 提示会把同一模式放大到 34–55%。最终答案变化较小，为 2–30%，且只有 2.9–35.3% 的被破坏支持翻转同时伴随答案变化。人工审计进一步显示，42 个有效破坏样本中有 16 个属于 corruption-overtrust，而模型接受的 10 条被破坏 rationale 中有 9 条被人工拒绝或标记为不清楚。 该研究给出的事实是，rationale 共享不应只被评估为提高答案准确率的通道，更应被当作验证消息机制来评估。由此可以推断，多智能体 QA 或 Agent 流水线如果直接透传推理链，可能引入新的失败面：验证器会被表面连贯但实质损坏的解释牵引，而不是独立复核证据。论文中的跨模型与任务边界检查还表明，这一通道何时被放大、何时失效，取决于具体提示和任务结构。

    推荐理由：它把 rationale 传递从“提升答案”重新界定为“验证消息干预”，可改变多智能体 QA 中是否该透传推理链的设计判断。