跳转至

笔记

AI 辅助写作与幻觉风险

本站大部分博客和笔记会借助 GPT 等先进模型辅助撰写,包括但不限于资料整理、结构梳理、表达润色和草稿生成。AI 能降低写作成本,但也可能引入事实错误、概念混淆、引用缺失和看似合理的幻觉内容。

因此,除非特别标注,我不保证文中内容完全准确。如果你将这些内容用于学习、工作或决策,请务必自行查证原始资料,并结合上下文判断其可靠性。

劝退指南:不是博客,而是笔记,甚至是草稿

写笔记是为了让自己看懂,写博客是为了让别人看懂,不一样的,认真做好后者对自己各方面能力的提升会非常大(比如表达能力),其实很多时候记笔记就是写几段自己能看懂的表达,很随性,但写博客更像是写一篇论文,需要自己先彻底搞明白一个东西后才能输出1

我一直努力将内容写成博客。但是后来发现,根本没有时间和心思,来为别人解释很多事情。我的想法最多是解释给多年后忘记一切的自己听,让我还能快速看懂。能达到这点,这些内容的意义对于我就已经足够。

现在拥抱 AI 之后,我更愿意把这些内容理解为 AI 时代的阶段性理解产出。AI 降低了知识获取、信息筛选和文本生成的门槛,但它并不会自动替代人的理解:一个概念为什么重要、如何与已有知识连接、在哪些边界条件下成立,仍然需要自己反复判断、实践和修正。

所以,我仍然会继续更新这些文档。它们不是面向所有读者的完整教程,而是我在某个阶段借助 AI、资料阅读和个人实践,对相关概念形成的理解快照。未来的我可能会推翻、重写或补充其中很多内容,这也是笔记存在的意义。

从读者的角度,我并不会推荐任何人阅读这个网站的内容:因为你会遇到以下令人烦躁的场景

  1. 完整性差:某些笔记写着写着就没有了,内容是残缺的。甚至只有一个标题。(这是因为我没有时间填充内容,或者我的研究和注意力转变方向了,弃坑了弃坑了~)
  2. 可读性一般:很少有起承转合的解释语句,笔记的内容逻辑几乎全部靠多级标题维持.
  3. 笔记间关联性低:从读者的角度是看不到本人是如何使用多级文件夹,来组织划分笔记间的内容逻辑。如果你在搜索栏找不到你想要的关键词,那大概率我没接触到这方面的内容。
知识是自然聚类和融合的,但需要两级的文档来过滤内容和撰写正文。小而全、无懈可击的内容应该是所追求的

导致这种情况,其实和我对知识产出过程的理解有关,我认为过程是 知识是自然聚类和融合的

  1. 接触到领域对象(新建文件夹)
  2. 阅读各种文献网站(零散的知识进行简单的聚类)
  3. 上手实践和研究(踩了许多坑,有或多或少的感悟)。

而且三者的占比是前面远大于后面,这样看来我这网站大部分的内容岂不是都是笔记的草稿

我以这样的方式撰写我的正式的毕业论文时,发现这样的处理有利有弊:

  1. 优势:
    1. 速度?:能快速的罗列出内容,填充了大量垃圾内容
    2. 完备性:保留所有必要的相关信息,
  2. 劣势:
    1. 对工作进度的误判:罗列的大量页数迷惑了自己,以为进度很快。其实仔细思路内容的有效性、逻辑关联性。核心观点的提炼。遣词造句都极其耗费时间。
      1. 最重要是导致只看页数的领导对你工作速度的误判导致的嫌弃:一周前就看见里论文写了60页了,怎么两周了还没写完。或者你都60页了快结束了,来帮帮我弄这个~阿米诺斯~
    2. 需要返工:重新整理罗列的垃圾内容,至少需要三倍以上的时间才能整理好。

总结:知识是自然聚类和融合的思想是没错的,但是在实际生产应用时需要两级的信息筛选过滤体系:区分出正文内的todo内容和未整理的archived信息。通过将罗列的完备信息初步分类归档(有基础的逻辑)以待后续使用,正文精心撰写每一句话保证不需要大量返工。

Building Large-Scale AI Systems on Ascend: Training, Inference, and Multimodal Optimization

导言

谭邵杰,中国科学技术大学本硕毕业,现任华为昇腾训练开发工程师,专注于 Ascend NPU 上的大模型训练推理框架优化、多模态模型迁移、分布式并行训练、RL 优化与量化推理加速。

AI 训练推理框架与异构加速优化工程师,长期聚焦 Ascend NPU 生态下的大模型训练、推理、多模态迁移、分布式并行、RL 训练与量化优化。

DualPath KV Loading

导言

Agentic LLM 的每轮新增输入很短,累计上下文却很长。高 KV Cache 命中率把重复计算变成了外部存储读取,但传统 P/D 分离系统只让 Prefill 节点承担读取,结果往往不是 GPU 算力不足,而是 Prefill 侧 Storage NIC 先堵住。DualPath 的核心不是压缩 KV,也不是换一种 Attention,而是把 Decode 侧闲置的存储入口和计算网络一起纳入 KV 加载路径,再用 QoS 与两级调度防止新路径干扰推理。本文进一步判断:昇腾 AIV 直驱可以成为其中一段细粒度 RDMA 控制路径的候选优化,但不能直接替代 DualPath 系统。

Mooncake Store KV Cache

导言

Mooncake Store 的 KV Cache 管理很像 PagedAttention:两者都采用 切块、间接寻址、按块复用与淘汰。但它们解决的不是同一层问题。PagedAttention 管理单个推理实例内的 GPU KV Block;Mooncake Store 管理跨请求、跨实例、跨节点的 DRAM 与 SSD 副本。

理解二者关系的关键,是先区分 页表KV 数据页:页表记录当前请求的逻辑块对应哪个 GPU 物理块,真正跨显存、内存和 SSD 分层迁移的是 K/V 张量数据,而不是页表本身。

Distributed KV Cache Management

导言

长上下文把 KV cache 从一块 GPU 临时张量,逐步推成了跨 GPU、CPU、SSD、NIC 和远程内存流动的分布式状态。表面上,近几年的论文分别在做分页、卸载、压缩、P/D 解耦、远程复用或直通访问;从更抽象的角度看,它们其实都在回答同一个问题:如何分布式地管理一批有依赖、可重算、持续增长且必须按时到达的数据?

本文以放置、组织、传输为主轴,把命名、依赖、正确性、调度与故障恢复作为支撑平面,纵向回看 2022—2026 年的演化,横向比较七类设计范式,并推演下一阶段可能出现的三条路径。研究截止日期为 2026-08-24

Mooncake

导言

Mooncake 是 Moonshot AI 为 Kimi 长上下文服务设计的 KVCache-centric 推理架构。它不再把 KV Cache 视为某张 GPU 上随请求消失的临时副产物,而是把它提升为跨 Prefill、Decode、CPU DRAM、SSD 与高速网络统一调度的系统资源。本文先用直觉解释,再从 P/D 解耦、Mooncake Store 与 Transfer Engine、缓存感知调度、Chunked Pipeline Parallelism 四个机制展开,并明确论文、当前开源代码与教学重构之间的证据边界。

KV Cache Fundamentals

导言

KV Cache 是自回归大模型推理中最重要的运行时状态之一。它把各层历史 token 已经算出的 Key 和 Value 留在缓存里,使后续步骤只处理新 token,而不必反复计算整个前缀。

这不是免费的加速:模型用持续增长的显存驻留换取更少的重复计算。理解这一交换,才能解释为什么生成会加快、长上下文会吃显存、并发容量可能下降,以及为什么修改提示词中间的 token 会使其后的缓存失效。

AIV Direct Drive

导言

“AIV 直驱”是昇腾通信优化语境中的常见简称。最稳妥的理解是:让运行在 AIV(Vector Core)上的 Kernel 直接编排和提交通信工作,避免由 Host CPU 或 AICPU 为每一次细粒度传输继续充当中间调度者。它优化的是通信控制路径;真正搬运字节的仍是 HCCS、RoCE、RDMA 或 URMA 等通信机制与硬件。

Long-Context KV Cache Systems

导言

本文调研 2021—2026 年 SIGCOMM、NSDI、OSDI、SOSP、EuroSys、USENIX ATC、FAST、MLSys、ISCA、HPCA、ICML 和 NeurIPS 中与长序列、大规模 LLM 推理及 KV cache 管理直接相关的工作,重点关注分页、压缩、稀疏选择、复用、分层存储、卸载、Prefill/Decode 解耦、远程传输、GPU Direct Storage、CXL 和网络内计算。

检索截至 2026-08-24。会议归属以官方 proceedings 或会议程序为准;仅有 arXiv 或项目技术报告的工作被单独列出,不能与正式顶会论文混为一谈。

Modern Matchmaking System

导言

当代成年人并不只是缺少认识异性的渠道,更缺少一种低冒犯、低浪费、可逐步建立信任的了解方式。工作压力压缩了交往时间,陌生人之间又缺乏共同经历;吃饭、看电影和交换兴趣爱好可以判断相处是否舒服,却很难及早暴露城市选择、生育、金钱、父母照护、职业规划和冲突处理等长期问题。

本文不试图发明一套“灵魂伴侣算法”,而是从古代婚姻流程中提取分阶段确认、双向披露、可信中介和体面退出等机制,再用现代关系研究、平等原则与隐私保护重新设计。目标不是替人决定应该爱谁,而是让两个人更早看见:能否共同经营一个长期生活系统。

WaferLLM Co-Design

导言

WaferLLM 是一篇很适合学习软硬协同设计的系统论文。它没有把晶圆级芯片当作“更大的 GPU”,也没有从某个孤立 Kernel 开始优化;论文先用 PLMR 模型提炼硬件的不可回避约束,再依次重做 LLM 的并行策略、数据布局、KV Cache、GEMM/GEMV 和推理运行时。

本文是系列第一篇,只回答两个问题:WaferLLM 的总体设计链是什么,以及这条链上有哪些值得单独深挖的方向。MeshGEMM 的对齐、循环移位、Interleave、缓冲区生命周期与完整伪代码会放在后续专文中。