长上下文效率
⚠️ 占位内容。Leon 与该方向 owner 请来填。下方结构是模板。
我们关心：让百万 token 级别推理在 lab 单机集群上跑得起、跑得快。
我们不关心：纯文本压缩 / 信息检索式的 long-doc QA（更像系统集成问题）。
该方向的 owner
Section titled “该方向的 owner”关键论文（外部）
Section titled “关键论文（外部）”- DeepSeek-V4 研究深度解析 —— 当前 SOTA 的长上下文设计
- 混合注意力机制 (SWA + CSA + HCA) —— 核心架构
- 待补：MLA 原论文（DeepSeek-V2）
- 待补：StreamingLLM, Longformer, Mamba/RWKV 长序列方向
我们的工作（内部）
Section titled “我们的工作（内部）”占位。Leon 来补：组里当前在做的相关项目、已投/已发的论文。
- 项目 A：xxx（owner / 状态）
- 项目 B：xxx
- arXiv 链接 / 内部代码库链接
我们关心的开放问题
Section titled “我们关心的开放问题”- CSA / HCA 的混合比例如何随任务自适应？
- 长上下文与 MoE 路由的耦合如何稳住？
- 1M context 在 8×H800 上推理的真实瓶颈是哪一段？
- KV cache 异构分层（DRAM / SSD）的 hit-rate 怎么建模？
推荐阅读路径（给新人）
Section titled “推荐阅读路径（给新人）”- 第一周：DeepSeek-V4 概览 + V4 研究深度解析
- 第二周：混合注意力机制（SWA / CSA / HCA 三层）
- 第三周：补齐前置概念
- 第四周：动手 —— 在我们 baseline 上跑一次 1M context 推理（见
/internal/playbooks/，待开放）
该主线的”组内立场”
Section titled “该主线的”组内立场””占位。Leon 写：相对其他组在这条线上，我们组的独特立场是什么。
例：我们倾向于把”百万上下文”当作系统问题来解，而非纯算法问题。所以我们组的工作里训练 / 推理 / 服务是耦合的，单独看任何一篇论文都未必看到全貌。
有问题或想加入这条主线？ 在底部评论区留言，或直接给 PI / owner 发消息。