跳转至

笔记

劝退指南：不是博客，而是笔记，甚至是草稿

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

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

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

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

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

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

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

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

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

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

  1. 你们坚持写 blog 的原因是什么？ ↩

  • 分类于 AI
  • 需要 2 分钟阅读时间

Vllm Basic

导言

HW24年狠抓了训练，但是推理性能稍微落下，dsv3的出现，强化学习的爆火，反过来对推理性能提出了很高的要求。为此高性能的vllm推理框架变成了hw首先适配的目标。

  1. 一方面我需要大致了解vllm框架的设计，
  2. 另一方面，我主要需要关注vllm-ascend实现了哪些接口。
  • 分类于 Overview
  • 需要 1 分钟阅读时间

Code Project Reading

导言

来hw的这小半年成，从PTA到MM又来到DeepseekV3，接触了很多代码，但是却还是常陷入代码细节阅读困境，难以理解如天书般的垃圾代码。往往陷入代码细节，一读读几天，并且经常难以产出阶段性成果。

如何快速代码上手，

  1. 通过代码外资料(LLM介绍，流程结构图，开源完善实现),
    1. 快速理解代码背后的概念，。e.g.，MOE，EP
    2. 简单了解开源代码实现思路，亮点。
  2. 跑通最小样例，通过执行调用栈（类似VizTrace），从整体和上层来理解当前代码框架。
  3. 聚焦没有实现的代码部分，或者性能瓶颈，递归仔细分析。

Next of My Ascend Career

导言

作为卖NPU AI加速卡的软件员工， 目标是将昇腾的底层算力与上层多模态应用需求精准对接，释放昇腾AI算力，让客户看到NPU的性能、性价比、易用性、客户自身业务的使用需求。

AI Post Traning: RL & RHLF & DPO

导言

Deepseek 的 GRPO 方法展示了强化学习的潜能。

RLHF 利用复杂的反馈回路，结合人工评估和奖励模型来指导人工智能的学习过程。而DPO 采用了更直接的方法，直接运用人的偏好来影响模型的调整。

Step-Video论文介绍了Video-DPO, 这类训练中最后通过人工标注优化的方法。

  • 分类于 Programming
  • 需要 4 分钟阅读时间

宛如泥潭的大型项目开发困境

导言

当时我选择一线的原因是决定能最解决客户，每个工作能产生最大的价值。

通过一段时间的开发，我感觉在一线开发就像在泥潭里前进：走得越快越远，泥潭陷得越深，前进阻力越大。

困境为何而来，如何解决困境，是我想讨论的重点。

  • 分类于 software
  • 需要 2 分钟阅读时间

Continuous Integration, CI

导言

在交付PTA需求的时候，发现需求在测试人员的更大的测试规模下出现了问题：

在增多了不同的测试样例，和不同的测试设备(910A,910B,310P)时；程序是否可执行，性能是否达标，精度是不是正常；都有待监控。

说明在开发过程中，我构建个人的每日测试框架，持续监控开发的测试和性能。

集成 windmill-labs / windmill。