2026-07-28 16:58:00
上次参与离职赛道，还是十一年前写下为啥我要从阿里离职的时候。虽然语言风格和心境在这十来年里都发生了不小的变化，但是很开心自己还有当年做出转变的勇气。
什么时候开始有改变的念头呢？大概是有一次晚上走路回家突然出现了幻觉，我发现同一条回家的路已经走了五六年了，一时间产生了时空穿梭感，几年前就在走，现在还在走，明年也会走。
于是我开始尝试改变回家的路线，每天绕一条不同的弯路，穿过一个不同的小区，先反向走一段然后再回头，就这样每天变换路线、绕路寻找一些新鲜感。很快，二十分钟的路被我拉长到了一个多小时，最后我开始了一天绕到三环、一天绕到四环的大圈模式。顺便提一句，在三环的蓟门桥和四环的京张铁路公园天桥上，都能无意间发现很漂亮的夜景，相机完全记录不了那种发现的喜悦。
等到连这么逛都开始觉得无聊时，公司终于搬家了，结果你猜怎么着，只是搬到了隔壁的一栋楼，路线完全没发生变化。而且还搬回了十年前我刚来灵雀云时的那栋写字楼，又回到最初的起点，记忆中你青涩的脸。
当时间走到第十年时，我突然想起了当初来时给自己定下的目标。当年还是大众创业、万众创新的时候，我还想着未来要自己创业。但是没啥经验，所以还是先加入一个初创公司，十年后公司要么已经暴毙了，要么已经成功上市了，不管成功还是失败，我都能攒一波经验。结果十年过去了，这两件事都没发生，当时想的还是太简单了。
不过这些年经营 Kube-OVN 也算内部半创业了，我也发现我并不适合自己单干。主要原因是我本能地排斥把自己的东西拿出去商业化，我希望能把自己精心打磨的东西和赚钱这两件事分开。我更喜欢的方式是在 Issue 列表里像渣男翻牌子一样，没有什么心理负担地去临幸一个问题并把它解决，而不是签一个商业合同，陷入一段有责任的关系中。这种心态做社区还好，做公司肯定死了。
于是最近一年，我开始全职搞社区，不再管项目上的事情，但很快就感受到了 AI 对整个开源社区的冲击。当社区里所有的 Issue、PR 和 Comment 都由 AI 生成时，人和人之间的情感连接就消失了，社区完全变成了一个 Token 众包的生产模式。花了半天时间古法 Review 代码，对方一分钟就改完，再让你 Review 时的那种绝望感，很多开源社区的 Maintainer 应该都体验过。而且在大量使用 AI 编程后，自己和项目之间的情感连接也变淡了，感觉这是 AI 生出来的野孩子，自己也莫名其妙地从孩子亲妈慢慢变成了后妈。然后我就开始产生虚无主义了，觉得一切事情 AI 都能做，自己做什么都没有意义了。和其他 AI 讨论虚无主义时，我得到的都是一些片汤话，DeepSeek 却给了我下面这么一句：
如果外部世界没有现成的意义，那我们自己就是意义的唯一来源。这很艰难，但也意味着完全的自由。
然后我想明白了，人生的意义应该是自己定义的。
接下来我就开始考虑全面转型 AI 的事情了。ChatGPT 出现后，其实我预测对了很多事情，比如刚出现的时候，大家说文字工作者要不行了，但 AI 还不会思考，写程序肯定比不过程序猿。我当时的判断是，程序这个东西是可验证的，搜索空间也更小，反而是 AI 更容易解决的问题。现在来看，AI 写出的文字还是很容易被识别且让人反感的，但是已经几乎没人再手写代码了。再比如 DeepSeek 春节爆火前，我就已经发现它能力不一般，开始当自来水了。
前一阵听罗福莉在播客里说，MiMo 团队在组建的时候，很多人都没有相关的经验，但是都可以直接上手去训练模型。我当时就想，现在已经没有这个时间窗口了，没有经验的人已经很难从零开始参与大模型训练了。然后就发现，尽管我对 AI 的认知和判断不少都是对的，但是由于没有行动，这些机会窗口就这么关上了。比如 ChatGPT 出现后应该重仓寒武纪，比如发现 DeepSeek 后应该在春节前炒 DeepSeek 概念股，更应该想办法尽早参与这个浪潮。
之前一直犹豫，一个很大的原因是 Kube-OVN 社区这两年还是比较成功的。我们已经慢慢把非红帽系的 KubeVirt 厂商包圆了，现在 Kube-OVN 的主力用户都是欧洲的各大通信运营商和主权云。虽然我们从来不说要做国际化，也不做推广，也从来不找大厂站台，但在我们不断打磨产品的过程中，这件事已经自然发生了。但是这种成功在一定程度上也成了我转型 AI 时无法割舍的一部分。
接着，我在三月份查出了肾结石，折腾了两个月，做了两次碎石手术才把一侧的结石排干净。另一侧的结石由于位置原因不好排出，也不好做手术，相当于还埋了一个雷。一方面感受到了 AI 浪潮的窗口正在关闭，另一方面又感受到了自己年富力强的时间窗口也要关闭了。想到这就没啥好再犹豫的了，之前的成功应该成为之后旅程的后盾，而不应该成为前进的阻碍。
即使在 AI 的竞争中失败了，Kube-OVN 也能为我提供骨灰盒和棺材板的本钱。十一年前我还啥都不是，都敢放下在杭州还没盖好的房子，降薪来灵雀云，从结果上看也没什么负反馈，为什么现在又变得犹犹豫豫呢？
于是我就上路了，而且是一路催着、赶着，不管不顾地要加速上船，一个来月就搞定了。这一路要感谢 yihong 大哥的帮助和精神氮泵，大哥的 tg 频道 里有很多资料，都是我这段时间学习时要用到的。
尽管前路艰险，但是我很高兴自己又找回了十一年前的勇气，可以再去浪一把。
2026-07-17 18:26:00
Kimi K3 发布时提到了 LatentMoE，恰巧最近在看 CS336 的时候也了解到了 LatentMoE。当时初看的时候就感觉这是一个很适合扩展模型规模的方法，现在看到它在 K3 这个 2.8T 参数量级的模型落地了。
MoE 的最初理念是通过更好的稀疏性降低训练和推理的计算量，本质上是一个在计算能力有限的情况下，尽可能 Scale 模型规模的方法。它的做法是把传统的 FFN 层切分成多个小的 expert，然后在前面加一个 router 每一层只激活部分的 expert 来降低计算量。如下图左侧所示。
这种方法从计算量的角度确实会带来显著的下降，但同时引入了通信的复杂度。因为 token 在经过 router 计算之后需要发送到被选中的 expert，而不同的 expert 可能分布在不同的 GPU 甚至不同的机器上，一份 token 就需要被不同 GPU 多次从显存和网络中加载，每个 expert 计算完后还会把数据再发送回去，这会挤占很宝贵的内存和网络带宽。而在推理过程中内存带宽的问题会更严重，MoE 中这种类似存储写放大的效果会对整体吞吐量带来很大的影响。
针对这个通信放大的问题，LatentMoE 并没有尝试去改变通信拓扑，它的解决方法是通过压缩和解压的方式降低传输量。具体的做法很类似 DeepSeek MLA 使用的压缩 KV Cache 的方式，首先通过一个压缩矩阵将 token 压缩到低维，接下来发送给各个 expert，各个 expert 计算完后发送回原先 token 所在的 GPU，再通过一个还原矩阵还原到原先的维度。详细的过程可以参考 DeepSeek MLA – 为成本优化而生的注意力机制。
和 MLA 类似，这个压缩并不是无损的，但是从最终的性能表现来看在 4x 的压缩率并扩展 expert 数量，性能可以得到保持。这其实也代表了最近几年来的一个演进趋势，不断地降低精度，降低密度，为的都是规模的提升，规模提升了性能就上去了，每个细节部分的精度可以为了规模的提升而让步。
另一方面由于引入了压缩和解压的计算，这一部分的计算量是增加了的，但是由于后续的 expert 维度降低，整体计算量并没有太大变化。但是由于内存通信占据了绝大多数的时间开销，即使计算量增加也是值得的。这也是 LLM 的一个性能优化的范式，尽可能降低内存的开销而不是只关注计算量的下降。
Kimi K3 当前的博客里说使用的是 Stable LatentMoE，很有可能是 LatentMoE 的一个变种，期待后续的技术报告详细解释。
随着模型规模不断变大，其实可以看到一个明显趋势：大家在降低各个维度的精度，以尽可能提升模型规模。具体来说，包括数据类型从 FP32 一路降到 FP8、MoE 只激活部分 expert、MLA 对 KV Cache 进行压缩、各种 Sparse Attention 选择性计算和压缩 Attention，以及 LatentMoE 对 token 进行压缩。
所有这些方法都在尽可能减少扩展模型规模时的阻碍。期待能看到更多模型架构创新和更大规模的模型。
2026-06-12 20:00:00
回看 DeepSeek 从 V3 到 V4 的这一年里，如何降低长上下文的开销一直是研究的一个重点。从 V3.2 开始，DeepSeek 引入了 DSA，直接把 V3.1 的价格降低了 50%。这个技术在 V4 中也得到了延续，并成为实现 1M 上下文的关键技术之一。这里会谈一下我对 DSA 思路的理解。
原始的 Attention 计算需要计算每个 Token 和它之前所有 Token 的相关性，得出当前 Token 在当前上下文的一个向量值，因此随着输入输出序列不断增加，整个 Attention 计算的复杂度趋近于 O(n^2)。
这也就意味着随着序列增长，总计算量会平方增长，这成为了一个主要的性能瓶颈，也是很多模型在超过一定序列长度后价格大幅上升的原因。为了解决 Full Attention 的二次方计算问题，就出现了很多 Sparse Attention 机制，试图避免成本的快速上升。
为了避免二次方的 Attention 计算，一个很直接的想法就是只选择和当前 Token 关系最大的一批 Token 计算 Attention。这个想法不仅很符合直觉，在 Attention 的实际计算中也会发现序列里大部分 Token 和当前 Token 的关系计算值是接近于 0 的，我们在预测下一个 Token 时，很多时候只要看序列里的关键信息就可以了。
一个很直接的思路就是滑动窗口只计算附近 K 个 Token 的 Attention，这个方法的好处是简单，计算复杂度稳定，但是局限性也很明显，那就是会丢失长距离的信息。
为了解决长距离丢失的情况，还有一种分层的注意力机制，使用一部分 Token 作为全局 Token，再加上局部滑动窗口的 Token，用全局 Token 来弥补长距离的信息。但是这就带来了新的问题：这些少数的全局 Token 应该如何选择？随着序列变长、任务目标发生变化，全局 Token 是不是又该重新调整？
不管是滑动窗口还是分层的注意力其实都是通过简单的局部性策略选择 Token，并不是真正根据 Token 实际的相关性来选择 Token。其实 Attention 的计算过程中就会计算出 Token 之间的相关性分数，我们直接取其中的 Top-K 作为选择的 Token 是否可行呢？
当然可以，但此时 Attention 的计算已经完成了，再做 Top-K 已经没有多少优化的意义了。但是如果我们可以通过计算复杂度更低的方式来快速选择出 Top-K 再进行 Attention 计算就有意义了，这就是 DSA 试图做的事情。
DSA 的核心组件是一个 Lightning Indexer 的选择器，它会根据当前 Token 给上下文的所有 Token 打一个分数，然后选择 Top-K 进入后续的 Attention 的计算。
而这个 Indexer 的分数计算就是去预测 Attention 计算的相关性分数。而它的结构也和 Attention 的结构很相似，Attention 是有 QKV 三个向量矩阵，而 Indexer 使用 WQK 三个向量矩阵，计算过程也是基本类似的。这就带来了一个新的疑问，这个 Indexer 其实是在模拟 Attention 的行为，那它的复杂度难道不应该和 Attention 是一致的吗？
按照我的理解，其实复杂度确实是一致的，还是 O(n^2)，但是这个 Indexer 由于任务简单可以使用更少的特征，更低的精度，ReLU 这样更高效的算子，在工程上把复杂度的常数部分大幅降低。这有点类似于用同样的股票预测模型结构，Attention 是要预测股票第二天的价格，Indexer 是要预测股票第二天涨跌的概率，把上涨概率最高的 Top-K 选择出来给 Attention 做价格预测。尽管结构上相似，但是预测涨跌概率的难度要比预测价格低很多，可以选择更少的参数和更快速的算法。由于 Indexer 是根据 Attention 结果来训练的，也可以粗略地理解为 Indexer 是从 Attention 蒸馏出来的。
DSA 的本质是在 Attention 的计算前加了一个选择器，这个选择器需要尽可能精确地预测出哪些 Token 和当前 Token 相关，又需要尽可能低的计算复杂度避免选择器的复杂度接近 Attention 的复杂度。DSA 的做法是使用了和 Attention 类似的结构，使用更少的参数量和更高效的算子，以及只预测大小关系而不是预测具体分数来降低选择器的复杂度。尽管整体复杂度还是 O(n^2)，但是通过把常数项降低数十倍，实现了在不牺牲模型性能的情况下成本大幅下降。
2026-05-26 18:00:00
Claude Code 在 2.139 版本引入了 Agent View，可以在一个界面里直接浏览多个项目下所有运行中和已结束的 session，方便更好地进行 session 管理和并行开发，在单个 terminal tab 下就能完成大量并发工作。
在我看来，这是一个 Agent 交互体验模式的重大提升，现阶段人们对它的重要性是大大低估了。
尽管这不是一个模型或者能力层面的更新，但这种用户体验的重新组织，极大提升了并行开发的效率。我之前其实已经回退到了线性开发的模式，因为我发现自己很难在多个任务之间进行快速的切换和响应。但是用了 Agent View 之后，我发现我可以开始大量并发工作了。
多 session 无法快速并发。 之前如果想并发，需要不断地开窗口、开 Claude Code 再执行任务。但这个流程普通人很难适应。在我的意识里，开窗口是个很重的操作，而且当下发一个任务后，模型很快就开始输出了，注意力很自然就被吸引过去了，很难不去看直接开下一个窗口。而在 Agent View 里，任务默认是异步的，输入完 prompt 后直接后台执行，留下的输入框是给下一个任务准备的，不会有当前任务的干扰，很自然地就过渡到了下一个任务。避免了窗口的创建，对心智成本是一个很大的下降，把”启动”这一步变得容易了。
多 session 难以管理。 我之前为了并行处理，甚至写了个简单的 hook 让 Claude 每次执行完发铃声并且弹窗让我知道状态，但在多窗口的情况下还是很容易错过消息，忘记哪个窗口现在是什么状态。现在的 Agent View 里可以按状态展示 session，很轻松地看到哪个 session 等待我的输入，哪个还在工作，哪个已经完成。同样在一个窗口里快速浏览状态进行下一步操作，避免了窗口的切换。
git worktree 管理困难。 其实之前也可以通过 git worktree 来实现并发代码修改的隔离，但是 git worktree 的使用模式和普通开发流程还是有区别，并且还要求每次启动 Claude Code 的时候添加对应的参数，增加了额外的心智负担。而且之前的 session 是和 worktree 绑定的，很容易出现找不到的情况。在 Agent View 里的 session 如果涉及更改会自动启用 worktree 做隔离，对于使用者来说完全不知道有 worktree 的存在，极大降低了使用门槛。
多个项目并发管理困难。 现在直接在输入框 @ 项目名，就可以在项目目录下执行 Claude Code 操作，会直接使用对应目录的 Claude Code 配置，同样无需开窗口切换项目，减少了对人类上下文切换的开销。
此外 Claude Code 还设计了一系列快捷操作来让 Agent View 更加方便。比如非 Agent View 管理的 session 可以通过 /bg 命令直接加入到 Agent View；通过键盘 <- 快速切换回 Agent View；通过 Space 展示 session 最近的会话并快速回复。一切的设计其实都是希望用户尽可能停留在 Agent View 页面，而不是进入到具体的某个 session 里。
这个设计理念很值得注意，它不是在现有模式上加一个管理面板，而是在尝试重新定义人与 Agent 的交互方式：从一个对话窗口变成一个有状态的任务面板。
当然，我也发现了它存在的几个问题：
这些问题不影响我对这个方向的判断，Agent View 这种交互模式未来会成为标配。人们的注意力也会逐渐从当个 session 的管理，转移到更多工作的编排。
2026-03-16 00:03:00
最近一周基本都在和肾结石作斗争了，记录一下过程，有想体验的小伙伴可以来看看。
这次肾结石的前两天我一直以为是深蹲拉伤，主要原因是我对肾的位置理解一直是错的。我一直以为肾是在下腹部的位置，其实后背部肋骨下方就是了。之前看人体器官图几乎从来没看过背面，但凡看过就能发现后腰从上到下只有一个泌尿系统，但凡后腰疼大概率是肾的问题。
上周五的时候站着站着毫无征兆的腰就感觉和被扎了一下疼起来，当时就直接倒在床上吱哇乱叫了，从肋骨下方一直到骨盆半个腹部都开始抽搐起来，时间持续了大概五分钟才慢慢消失。现在想来应该是肾结石刚脱落，一下子卡到输尿管了，没卡住一会儿又掉回到肾里了。
好了之后发现一旦坐起来或者走一会儿路就会再这么来一下，躺着不动就没事，人就不敢动了，就按腰部拉伤来处理了。静养了一天感觉还不错，周日的时候觉得差不多了，就开始不怎么躺着了，结果一下来了个大的。
这次是坐着的时候感觉有点不舒服就躺下去了，然后疼痛不断升级，半个腹部感觉都拧在一起，接下来半边身子都麻了，舌头都动不了只能靠嗓子发声，然后另半边身子也开始发麻，眼睛里都是星星，眼看整个人就动不了了。而且这次完全没有消退的迹象，第一波刚好了一点还没缓过来第二波就又来了，每次都是半个腹部扭在一起全身发麻，一波一波的连绵不绝。我一度担心自己会不会半身不遂，疼的开始想生死的问题了，十来分钟后果断叫 120 把自己搬走了。
现在想起来应该是前几天活动比较少，肾结石都是刚卡到输尿管就掉下来了，周日活动多了一些彻底卡进输尿管掉不回去了，所以就一直疼下去不可能再恢复了。
我们这边是老小区，机动的救护车还比较多，感觉十分钟都没有救护车就到了，说一下你要去哪个医院就行，感觉和打车也差不多。
由于一开始我一直以为是锻炼拉伤，直接去了骨科，大夫觉得我疼的位置不太对转到了胸外科，胸外科拍了个 CT 大概两个小时出了结果，发现肋骨没问题，但是扫到了肾说是能看到有两个结石，于是把我转到了泌尿科。
由于我当时对肾的位置还有理解错误，还纳闷肋骨扫描怎么能扫到肾，想自己借着 AI 看 CT 结果，发现 CT 拍了 600 多张片子于是作罢。
泌尿科开了个腹部 CT 、血常规和尿常规，结果就是白血球高有炎症，尿红蛋白高有血尿，左侧输尿管卡了一个 6 毫米一个 4 毫米两块结石。由于 6 毫米是自然排出上限，大夫的建议是先等自然排出，一周后还有症状的话再看是超声波碎石还是微创手术取出来。
最后就是开了止疼药和消炎药，让我多喝水多蹦，疼的受不了就吃止疼药，一周后再看。我看有的疼痛等级指数介绍肾结石已经是最高级了，能和自然分娩坐一桌，想到可能还有一周整个人是崩溃的。当时都想直接去手术取出来了，不过想了想手术还是有创伤，理智战胜了冲动，还是打了针止痛回家了。
由于结石已经卡住了，不疼是不可能了，我发现蹦跶一阵疼痛会缓解一些，就只能在疼痛刚起来的时候赶快去蹦一阵，不然一旦疼劲上来就又动不了了。整个晚上基本上就是疼的时候就赶快去蹦，不疼了就闭眼躺一会儿，等再疼了再去蹦，最后到四点后才睡了一会儿，六点多疼起来就是循环继续。
这个过程中应该是结石划伤了输尿管伴随着炎症开始低烧，由于排尿管被堵住了明显感觉排尿偏少，而且肚子里有一大坨水，蹦的时候能感觉甩来甩去。
这样蹦了两天感觉疼痛点从肋骨慢慢往骨盆转移了，然后就不会那么疼了，但是还会有一波波的酸痛，应该是伤口被摩擦的感觉。蹦了两天后，基本也抬不起脚了，发烧和没睡觉的乏力感也上来了，后面两天一直在睡觉，等到这个周五的时候才基本不疼了，排尿也基本正常，肚子里也没一大坨水了。下周约个时间去医院再做一次 CT 看看结石是排出去了还是掉到膀胱里了，还有没有其余的没脱落的结石。
这次肾结石后立刻就老实了，我是从来没想到过可以这么疼。查了一些资料，主要原因应该还是喝水太少了，尿液沉积形成的。其他一些可能的诱因有含糖饮料可能会提升尿液浓度，可乐里的磷酸（有糖无糖都含有）会导致磷酸盐析出，茶叶里的草酸也会导致草酸盐析出。
所以想来普通的腰疼其实也有概率是肾结石排出的原因，只是没堵那么长时间，体积也没那么大。我现在看到可乐就开始腰疼，有想体验的小伙伴可以考虑可乐和浓茶当水喝，看看多久可以体验到这种感觉。
2026-01-27 23:23:51
看了下 DeepSeek OCR 2 的论文，以我二把刀的知识分析一下。
这次是一个视觉模型编码器架构上的创新，主流的视觉模型编码器的方式是把图片分成一个个小块，变成一个个 token，然后按照从左上到右下逐行扫描的顺序一个个输入给模型。这其实和现在的 LLM 工作原理很像，只不过 LLM 是一串文本的 token，这里是一个个图片块的 token。然后还是 attention 那套两两比较，计算出每个 token 之间的关联关系，这样就可以通过不同 token 之间 attention 的权重关系得出不同图像块之间的关联，模型也就理解了整个图片。
看上去这个思路很好，统一了图片和文本的处理方式，但是图片和文本有个显著的区别，文本可以看做是一个一维的表现形式，你从左到右按顺序读，文本的逻辑大概率也是按照这个方向展开的。但是图片是个二维的表现形式，图片的逻辑并不是按照从左上到右下，图片里可能有斜线有曲线甚至有螺旋线，还是按照从左上到右下拆成的一维顺序是不是最有效的？至少人类看图片是不遵循这个顺序的。
虽然通过位置编码的方式可以把位置信息也加入到 attention 的计算，但是主流的位置编码也是基于文本一维顺序做的，是不是能很好的对图片这种二维表现形式进行位置编码呢？
DeepSeek OCR 2 的架构创新就在这里，他们在编码器里附加了一个小型的 LLM 可以推理出图片之间各个块的因果关系，然后按照关联关系对 token 进行重排序。可以认为模型是按照逻辑顺序去看图片而不是无脑的从左上到右下，这个逻辑顺序也会更接近人看图片的顺序。
性能提升，开销下降这属于 DeepSeek 的常规操作这里就不提了。我在想有没有可能视觉模型才是能力更强的模型的方向？
论文里提到这个模型主要作用还是读文档来生成语料，给 V 系列的语言模型用，但有没有可能把 OCR 系列和 V 系列直接融合。一方面图片里其实包含了文本里无法体现的内容信息，另一方面图片还比文本更节约 token。
按照 DeepSeek 一贯喜欢融合模型的作风，我觉得可以期待一下 V4 是个有初步视觉能力的模型了。
