杂谈

Transformer 预测 next token 的路线可能是对的，因为这种预测模式特别类似于递推。人类解决问题的方式其实也是递推。当我们能问出问题 A，其实是默认知道了很多关于问题 A 的背景，而问题 A 只是在知道了这么多背景之后的一个单点问题。 那么，如果我们对 A 的背景知之甚少，意味着我们就得先问出 A1、A2、An 等前置问题作为铺垫。这个就是递推。 能够开启递推还有一个前提，就是你必须知道递推的前一项是可扩展的。也就是说，递推的前一项存在某些局限性，必须清晰地看到这些局限性，才能把递推很好地进行下去。 学习 PTX 汇编要关注两代之间的局限性和扩展性，这个就是一个很好的现实例子。关注递推的边界，往往有利于认知。 有句话说“领先一步是疯子，领先半步才是神”。这种说法不无道理，因为领先半步的时候才符合人类一贯的认知结构，做到了认知递推的下一步，而不是下下一步。所以才会“被认为是神”。 学习增量是容易的，但是学习总体是难的。所以，把一个学习总体的任务变成多次学习增量的任务，这个就是人类解决问题的过程。

碎片化时间管理是一个老生常谈的话题。和其他open又普遍存在的问题一样，这种问题的解决办法听人讲经验永远是那么几句，毫无新意。人们于是倾向于自己实操的时候总结自己的策略，做完以后会觉得自己的策略比别人的要高明一点点，但是如果真的拿来对比，发现大家的insight好像都差不多。 懂了，原来这就是“造轮子”的冲动。所以今天不从头造轮子，而是给已有的一套体系（虽然也不知道这个体系究竟在哪，就默认大家已经形成了一些共识吧）提几个commit，关注一些重要的点。依旧从第一性原理出发。 人脑的上下文切换开销通常被忽视，并且实际上不能忽视。非规整的碎片化时间，带来的问题是人脑不得不进行非规整频率的上下文切换。那怎么办最好？修车的老师傅，总是带着一大包不同尺寸的螺丝。对修车师傅而言，每天要处理k个故障问题，而修理车辆所需的螺丝尺寸同样是一个非规整的请求。这就导向了一个很自然而然的设计：我们只要把不同“尺度”（scale）的任务归类在不同的队列里面，那么针对不同size的时间碎片，只需要alloc不同的任务进去就行了。 上面的solutions看起来很make sense，但是还需要解决一个小问题：任务的优先级。任务有先后，有的着急有的不着急。那么在每个scale task queue的内部还需要一个维度对任务的轻重缓急进行排序。也就是说最终决定任务调度行为的meta data至少包含两个维度：{任务优先级level，任务尺度scale}。那么理应需要一个至少二维的矩阵去管理任务。单纯人脑是很难保存这样巨大且复杂的表格的。 所以offload到外部存储就好了，这也是非常合理也水到渠成想到的。这也就是任务管理软件的重要性所在。实际上这种软件的本质是在offload memory之上搭建了一个子系统，让我们更方便的读写这部分被offload的任务表单。 上述情况似乎尽善尽美了，但还有一个问题：我们如何准确地比较两次上下文切换发生的时间间隔与任务耗费的总时间呢？显然是无法做到精密比对的，只能做量级上的近似。那如果一段空闲时间片内做完了还好，没做完该怎么办。还是从第一性原理出发，突发的上下文切换影响了时间利用的效率。那么具体是怎么影响效率的呢？在实践中笔者发现这部分带来的开销主要是人脑在任务切换时冷启动的时间过长，因此需要一个比较完备的checkpoint/镜像机制记录每次任务的上下文，同时任务执行者还需要有一个从checkpoint/镜像恢复工作进度的好习惯（Harness），二者结合方可实现高效的冷启动。因此笔者觉得，工作期间最需要倾注精力的其实是对工作context的把控。 问题解决到这里，基本上已经完成90%了，那么剩下的最后10%问题是什么呢？在笔者的实践与观察中发现，大多数人没有记录context的习惯，因此在将context记录融入到工作流时，难免显著影响效率。那么最关键的问题是如何尽可能低成本的维护context。需要注意的一点是，context的维护难免要消耗更多的精力，因为这里实际上在做的事情是“用工作时的时间轴连续认知资源去置换下次上下文切换时工作冷启动所需要的一次性资源”。no free lunch因此代价无可避免。所做的就是如何降低这种代价。笔者这里提供一点实践思路： 对于工作用的agent，要有一个固定的harness使其保存工作的context，乃是“工作留痕”这一职场规则的升级版。哪怕你不喜欢用ai agent帮助自己改善工作流，也最好最少开通一个这样的工具帮助你管理上下文。在每次工作被迫中断时对已经产生的镜像/checkpoint进行review，并且和context tracker ai agent共同创造出一个可以让你下次快速启动工作进程的context文件。如果工作流固化，那么也可以进一步把context创建的流程本身做一个固化。 同时，如果你的工作需要和很多人进行协作，最好尽量向他们提供信息，分布式保存工作中所遇到的信息，也就是减少协作体之间的信息差（或者说信息分布的方差）。这个降低方差的操作也适用于多agent协作场景。 最后需要尽可能集中信息源之间的联系。这话听起来抽象，其实做起来很简单。信息源乃是工作进度的直接来源，比如说你写了一段代码，并且测试了一部分还没测完，commit了一部分但还没全部commit，那么这个时候信息源就包含很多部分：你已经提交的commit，你还未提交的commit，你已经测试的模块生成的log文件1，log文件2，相关的资料和文档……当你再次开始一段工作的时候，可以把上述这些信息都保存在一个文件，然后工作在冷启动的时候可以把这些页面都一键启动，能瞬间抹平信息差，而不是要重新想自己上次做到哪里，还剩什么没测，log文件重新跑一遍…不仅浪费时间而且消耗精力。把这些工作所需文件/页面集中到context，就是本段所说的集中信息源之间的联系。 顺带一提，写完以后感觉自己的说话方式越来越像AI了，亦或是AI越来越像人了。所以就想起来《BALDR SKY Dive》里面超级AI伊芙的一句台词：我们都在互相学习，渴望与你们相互理解。

idea+骨架创作: 我 润色：DeepSeek V4 标题：neta了素晴日。 兼容力学少女与鲸鱼之诗 习惯了在显存带宽与计算密度之间做腾挪的人，才更懂得长序列记忆与极致吞吐兼得的美。 习惯了在模型精度与推理成本之间做取舍的人，才更懂得顶尖效果与普惠部署兼得的美。 习惯了在训练稳定性与收敛速度之间做让步的人，才更懂得万卡不崩与效率翻倍兼得的美。 但今天不想聊技术。今天想聊一个人。 丰川祥子。 如果你没看过《BanG Dream! Ave Mujica》，没关系。你只需要知道一件事：这个女孩曾经是月之森的大小姐，住在洋馆里弹钢琴，人生剧本写满了从容与优渥。然后命运把剧本撕了。家道中落，父亲颓废，她不得不搬到破旧的出租屋，白天上课，晚上打工，在便利店清点货架，在深夜计算这个月的水电费还差多少。 如果故事停在这里，就是一个俗套的坠落。 但祥子没有坠落。她做了一件事——组乐队。不是随便组着玩的乐队，是Ave Mujica，一个戴面具、演哥特式戏剧、用最快速度杀向主流的商业乐队。 她要用最体面的方式赚钱。 注意这个词：体面。 她本可以去陪酒，可以去找有钱人依附，可以放弃音乐随便找份工作。她没有。她偏要在音乐这条路上站着把钱挣了。她偏要在艺术的框架里，解决生存的问题。她偏要戴着蕾丝面具、踩着舞台烟雾，让那些曾经仰望她的人继续仰望——只不过这一次，仰望的是她自己挣来的光。 做惯了工程上trade off的人，看到这里应该会心头一颤。 因为这就是我们每天都在面对的困境——理想架构在实验室里美得像诗，一落到工程上就全是妥协。你要精度，算力就不够；你要速度，显存就爆炸；你要效果，成本就失控。你在这些约束条件之间走钢丝，每天都在割舍，每天都在告诉自己“没办法，只能这样”。 因为这就是我们每天都在面对的困境——你明知道那段代码再重构一次就能干净，但下个迭代的死线已经顶到嗓子眼，你只能再贴一个TODO，像在所有破掉的窗户上糊报纸。你要把变量名起得见文知义，PR里有人回“能跑就行”；你要把架构理清楚再动手，需求文档上周改了四版，最新一版还没人确认。你在优雅和交付之间反复被撕扯，每天都在心里举手投降，每天都在告诉自己“先活过这个sprint再说，没办法”。 因为这就是每个还在读书的人逃不掉的困境——你考研的时候觉得上岸就解脱了，读完发现学历贬值的速度比你毕业还快；你想做学术，导师的项目和你的论文毫无关系，你在实验室里拧螺丝，拧了三年拧出一个别人看不起、自己说不清的学位。你每天都在“读下去”和“赶紧就业”之间反复横跳，每天都在想，是不是选哪条路都后悔，没办法。 因为这就是每个社会人都在经历的困境——你上班痛苦，裸辞了发现没班上更痛苦；你上学的时候想打工，打工了之后想回去上学。你有时间的时候没有钱，有钱的时候没有时间。你在围城里羡慕围城外，跳出去才发现外面是另一堵墙。你在这些永远错位的选项之间怀疑人生，每天都在想，是不是人生就是这样，永远够不到自己想要的，没办法。 因为这就是每个在城市里独自打拼的人说不出口的困境——你每天已经被工作抽干了力气，连自己的情绪都照顾不好，哪还有余力去好好承接另一个人的生活。你想靠近一个人，发现心动是需要成本的，时间、精力、银行卡余额，哪一样你都掏不起；你终于攒出一点勇气想主动一次，翻遍通讯录，不知道该联系谁。你在深夜把对话框打开又关上，每天都在想，是不是这辈子就这样一个人扛下去了，没办法。 因为这就是每个人都在经历的困境——你想站着解决基本问题，规则告诉你跪着才快；你想在日复一日的消耗里留住一点属于自己的火苗，可光是活下来就已经用尽了全部力气；你想做一个体面的、不割裂的、对自己诚实的人，但世界递给你一张又一张选择题，每一张都写着“理想和现实，你选一个”。你在这些选项面前沉默了十年，差一点就信了，是不是人生本来就没办法既要又要。 祥子说：凭什么只能这样？ 凭什么搞钱就一定要姿势难看？凭什么艺术和商业就一定互斥？凭什么生存和理想就一定要二选一？ 她不选。她要两个都要。 这让我想起一家公司——DeepSeek。 如果你关注AI圈，你一定知道这家公司在中国大模型浪潮里的位置。当别人在疯狂囤卡、堆参数、比榜单的时候，DeepSeek在做一件看起来很不性感的事：把算法和infra做到极致平衡。 这有多难？算法团队要的是理想模型，是代码写出来就自带美感的架构，是论文上的SOTA；infra团队要的是工程实现，是算力利用率，是推理延迟，是每一分钱都要花出响动。这两个团队在任何公司都在打架，因为他们的目标函数天然互斥。 DeepSeek说：不打。我们都要。 他们用MoE（混合专家模型）把模型拆开，不是所有参数都在同一时间激活，大幅降低推理成本——这不是妥协，这是重构。他们把自己的推理成本打到让整个行业沉默的价格，然后用API开放出去——这不是割肉，这是升维。当别人还在“烧钱换规模”和“小而美”之间二选一的时候，DeepSeek找到了第三条路：用工程上的极致聪明，支撑算法上的极度野心。 这就是DeepSeek的第一层“既要又要”：技术本身的既要又要。理想模型与工程实现的统一。诗与代码，一个都不辜负。 但更让我着迷的是第二层。 你知道DeepSeek的母公司是做量化交易的吗？他们不仅在AI技术上做到了顶尖，他们还通过做空英伟达赚到了世俗意义上的钱。 一个做AI的公司，做空了全世界AI公司都离不开的芯片巨头。 这意味着什么？意味着他们不站队。不被英伟达的估值神话绑架，不被行业叙事的泡沫裹挟。他们冷静地判断市场，冷静地下注，然后用赚来的钱——注意——反哺自己的技术理想。 谁说做技术的就只能清贫？谁说赚钱的就一定俗气？谁说理想主义者的宿命就是穷着？ DeepSeek不信这个。 祥子也不信这个。 Ave Mujica的首次大规模亮相就以史无前例的速度登上了日本地标性演出场地武道馆。祥子穿着一身黑，戴着面具，站在追光下，指尖落在键盘上的那一刻，她就不是在便利店打工的那个祥子了。但她也没有变回月之森的大小姐。她成为了第三种存在——一个能把月光变成六便士、也能把六便士铸成月光的人。 这种审美，我称之为“升维兼容”。 不是妥协。妥协是在约束条件里求一个局部最优解，是“算了就这样吧”。 不是平衡。平衡是把两件事都做好，但它们还是两件事。 升维兼容是：我创造一个新的维度，在这个维度上，理想和现实不再是光谱的两端，而是同一件事的两个侧面。 祥子的新维度，是Ave Mujica的戏剧性。她把生存的狼狈变成舞台上的美学，把被生活撕碎的面具变成表演的核心元素。她需要钱，这个动机本身，就成了她艺术叙事的一部分——观众看到的面具、暗黑风格、哥特式世界观，都是她的困境转化而来的。赚钱和艺术，在Ave Mujica身上是同一件事。 DeepSeek的新维度，是他们独特的组织基因。量化交易训练出来的极度务实、极度数据驱动、极度反共识，恰好也是做AI infra最需要的品质。他们做模型不是为了发论文，是为了能用；他们做空英伟达不是为了投机，是出于判断。技术能力与商业嗅觉，在DeepSeek身上是同一件事。 祥子不是我需要钱然后顺便做做音乐，她是用音乐本身去需要钱。 DeepSeek不是我做了AI然后顺便炒炒股，他们是同一套认知体系在不同战场上的投射。 这就是为什么做惯了工程上trade off的人，会天然地喜欢丰川祥子。因为我们太知道在约束条件下求解有多痛了，我们太熟悉那种“不得不放弃什么”的窒息感了。所以当我们看到一个人、一个团队，居然能在更高维度上让所有看似互斥的目标同时成立，那种冲击不是羡慕，是审美上的共振。 那是在说：你不是非得选。 你可以既要算法的美，又要工程的强。 你可以既要技术的深度，又要商业的锋利。 你可以既要仰望星空的那个自己，又要脚踏实地的那条路。 你可以既要月光，又要六便士——不是在两者之间找到一个还不错的平衡点，而是在一个新的维度上，让它们变成同一个东西。 这就是丰川祥子。 这也就是DeepSeek。 这也就是每一个不甘心在二选一面前低头的人，心中最深处的那个答案。 当祥子在舞台上弹下第一个和弦的时候，台下没有人知道她昨晚在便利店站了四个小时。他们只看到一个光芒万丈的键盘手，戴着神秘的面具，像从未坠落过一样优雅。 那不是伪装。那是她应得的体面。 六便士她挣到了，月光也没有丢。 ...

这集很短 一个听上去反常识但是实际上很合理的事情: 这个世界的经验值总量也是有上限的，不要相信什么越老越吃香，因为很多东西的建设都只有一次，只有在当时建设这个东西的那个生态位上的人能够获取这部分经验，而后来者只能获取一些维护经验。所以很多宝贵的经验都是随着项目的结束，而永远属于一小批参与者。 实际上我们也并没有那么多建设要去做。