Initial commit: obsidian to gitea

article/published/杂谈｜博零总结.md

@@ -0,0 +1,53 @@
+## 杂谈｜博零总结
+
+赶在博一开始前的最后一天，写写过去一年的博零生活的收获、体验和感悟。从 24 年 9.12 进入阿里实习算作正式的科研开始节点，也是正好过去了一年。
+
+![[250913-144507.png]]
+
+### 我的收获
+
+1. 最直接可量化的收获是被老板手把手带飞，比较幸运地一投即中收获了一篇 ATC：[KVCache Cache in the Wild: Characterizing and Optimizing KVCache Cache at a Large Cloud Provider](https://www.usenix.org/conference/atc25/presentation/wang-jiahao).
+2. 参加了不少会（~~旅了不少游~~），作为死宅也是趁着各类开会到处玩了玩。
+3. 参加了 EuroSys'26 的 shadow PC，体验了一下审稿人的心态和学习了审稿流程，对 paper 的 presentation 重要性的认识进一步加强。
+4. 经过一个完整的科研工作流程，也得到了一些关于科研工作流的收获与进步。就输入端来说，读 paper 不再像一年前的小朋友模样，拿到一篇 paper 从头开始一句句往后读，开始有一些自己的 background 在脑中，读 paper 会开始更主动地找自己想要的部分。但是由于当前仍然十分有限的 background，读 paper 和找到对自己想要部分的能力仍需要继续加强。就输出端来说，目前认识到了写作、画图、做 slides 进行输出的重要性，但是在输出端的所有方面都还缺乏锻炼，希望能在未来一年摸索出一些自己就这三方面输出的一些 SOP.
+5. 就合作与沟通有了一些更深的体会。即使本科期间有着各种团队开发、小组合作等任务，但是本科所做的事情大抵是十分确定的，容易有明确的任务分解，大家的信息差不大，需要“有效沟通”的部分并不多。但在科研项目中许多东西本身是不确定的，很多东西是自己在摸索过程中被自己学习到了 latent space 中，在与他人沟通时很容易忽视这些 latent space 中的 context 导致的信息差，导致沟通的不顺畅。自然语言本身存在的 ambiguous 也很容易导致即使是两个人沟通，两个人脑中形成的 figure 也不太一样进而引起误解。目前自己还没探索出好的方式来精确认识自己的 latent space 进而精准地进行表达，只能通过反复 ping-pong 的方式确认是不是在沟通中达成了共识，希望未来能找到更清晰的沟通合作方式。
+6. 这个世界的大部分工作（除了纯数一类的工作需要极端天才的个人英雄主义）想要做出一些有价值的事还是离不开团队合作，做技术与团队合作是两个正交的纬度，学会避免纯粹技术主义的叙事。作为 system 特别是 distributed system 的研究者，最直接的比喻是做技术是 compute、团队合作是 communication，但是在分布式系统中，存在着无数例子告诉我们，一个系统很可能是 communication-bound 的，在团队合作中如何降低 communication 的 overhead 是一个十分值得学习的事情。（如果希望做一些有价值的事，而不仅局限于个人折腾技术的精神愉悦的话）
+
+### 一些遗憾与不足
+
+1. 美签被卡，没去成最后一届 ATC 现场，~~错失波士顿旅游机会~~
+2. 仍然缺乏独立开启一个科研项目的能力，从今年 5 月赶完 ATC final version 之后，似乎就开始了一边感觉挺忙，一边又看起来毫无科研进展的既感觉挺累又感觉很摆的本科毕业假期时光。进入一种探索可能的方向、发现 prior work，怀疑价值，想不到更进一步的工作的循环之中。
+3. 开始科研生活后的拖延症相比之前似乎更严重了，ddl 的到来相比固定每周要交的作业、要写完的 lab 要不规律和慢很多，许多想做的事情最后都变成停留在脑中的想法而没有开启任何行动，目前还没找到好的方式改善这一点。
+4. 很多不足其实在上一部分的收获中已经说到，~~认识到这些不足用乐观的角度看也是收获~~。
+
+### 过去一年读过的一些东西
+
+在从本科向独立做科研的转变中大家或多或少都会有一些迷茫，曾经读过一些来帮助自己更清晰地认识科研、认识读博这件事，了解一些形而上的东西，在此汇总一下。
+
+1. The Ph.D. Grind. 作者介绍了自己读博的各个阶段以及得到的个人成长，让读者能对读博生活有更清晰的预期
+2. 一名系统研究者的攀登之路. 海波老师的一些研究经历与感触
+3. [Useful Thoughts about Research](https://www.eecs.harvard.edu/htk/phdadvice/). H.T. Kung 教授在 Harvard 给的一些关于 research 的实用建议
+4. https://zhaoxiahust.github.io/blog/index.html. 一个关于 system research 的资源汇总的 article list
+
+
+
+
+
+---
+关于沟通
+
+进入实验室以来，感觉到自己的沟通明显变多了，~~有从 I 人变 E 的趋势~~
+
+随着合作和沟通变多，发现了一些明显存在的问题，作为技术人非常容易陷入知识的诅咒，有一些东西即使是自己花了一下午搞懂的，但是在搞懂之后就会进入一种觉得这个东西十分简单、显然等的心态，在与别人沟通时，常常会不自觉地假设别人也非常了解这一块，但是这是一种错误的心态。感觉仍然需要进一步通过刻意训练来避免。
+
+另一方面，除了纯数一类的人类智慧巅峰，可能需要极少数天才做出一些突破，这个世界上的大部分工作要成事还是离不开合作，作为做分布式系统的，也有着许多系统问题能够让人清晰地认识到，一个系统中的通信开销往往是不可忽略的，甚至是 bottleneck，团队合作同样是一个分布式系统，在一个优秀的团队中，也许大家的处理器性能都很强，计算不会成为 bottleneck，但是如何做好沟通降低通信的 overhead 就显得尤为重要。
+
+本科到做研究的转变
+
+本科期间做的事情往往是确定性的，即使是从零开始写一个上万行的玩具编译器，其中做的编译优化等等，也是路径明确的，只需要复现前人提出的各类优化即可。而在研究中，你需要自己第一手地去探索可能性，回答一个不确定的问题。
+
+关于舒适圈
+
+当在向上走时，总是有一个需要走出舒适圈的过程。经过本科几年的代码训练，写代码相比于做科研项目一定是一个更在舒适圈内的事。而可以想象到的，经过几年的科研训练之后，可能做科研会是一个相对在舒适圈内的事情，但是那时可能又有新的舒适圈外的事情，例如如何做团队的组织、如何 social 等等。人生没有所谓的上岸，一岸过后必有下一岸。找到自己喜欢的方式，收敛到一个自己满意的人生节奏点即可。
+
+想要做一套自己的画图工具包、即使现在有了大模型的帮助，科研画图能够很轻松的让大模型写一段代码来画出自己想要的图，但是画图的美观性、个人风格方面，仍然是需要自己来准备一套画图工具包的

article/published/民科｜瞎谈 AI for OS.md

@@ -0,0 +1,27 @@
+## 民科｜瞎谈 AI for OS
+
+> Disclaimer: 本文为民科软文，不涉及任何具体的真实的技术讨论。
+
+前段时间看到 NeuralOS [1] 这个工作，由大模型来模拟 OS 的行为，通过读取键盘、鼠标的操作作为输入，让大模型生成计算机屏幕画面作为输出。其实这件事并不新颖，容易让人想到早期 ChatGPT 刚发布时，就有人让 GPT 扮演一个命令行工具，来模拟输出执行一条命令后的结果。
+
+这类工作自然是看着比较有趣的，但是本质来说脱离了 OS 的范畴（下面贴一段 Wikipedia 的定义）。目前常说的 AI OS，个人认为分为两个层级，一个是目前常出现的 AI PC、AI mobile phone 之类的，提供一些 AI 能力让用户使用更加方便，例如一些办公软件自动化、一个 agent 来自动点外卖等，这些在我看来属于 AI agent 的范畴，他们有可能带来类似从 CLI 到 GUI 变化的一个新变革，但不在本文讨论的 scope 内。另一个则是从传统 OS 定义出发，我们希望抽象和管理硬件资源，同时为上层应用提供各类能力（计算、存储等等），本文希望设想一下 AI for OS 在这传统定义下能够做什么。
+
+> An operating system (OS) is system software that manages computer hardware and software resources, and provides common services for computer programs. [2]
+
+在设想 AI for OS 能够带来什么改变之前，我们先看一下最开始 OS 是如何诞生的。最早期的计算机通过人工纸带打孔以及在超大机房里做电缆插拔来执行一个“程序”，每次只能运行一个“程序”，且需要大量的人力成本来进行“程序”的加载、切换等，资源利用率极低。一个自然的想法是：能不能让计算机自己管理程序的加载、运行、切换和资源分配，由此开始了 OS 的诞生与不断演化，从而有了现今的时间片轮转实现程序的并行，虚拟内存的管理实现程序间的隔离等等。
+
+既然 OS 的本质是对硬件资源提供抽象和管理、对上层应用暴露统一的能力，我们能够看到现今的操作系统仍然有着很多需要大量人力成本的工作，尤其是在分布式、云计算等领域。传统 OS 需要人作为核心决策者，OS 只是静态配置来实现确定性的行为。但现今的系统复杂性越来越高，分布式场景下有着异构节点、不同的网络拓扑、复杂的状态同步问题，在负载侧有着越来越复杂的 workload，任务的多样性越来越高，对于调度机制等也带来了许多新的挑战。而现今面对这些复杂性，都是依靠人类专家付出大量的人力成本来试错、调优，这种事情本不该是 sysetm 哲学希望看到的。
+
+因此本文想要随意畅想一下 AI for OS 可能能够带来什么改变。人类使用工具的最本质需求应该是：我有一个问题，工具能够帮助我解决这个问题。传统 OS 提供的接口（syscall、POSIX 标准等），都是由人告诉机器“你要做什么”，而我们更希望看到的是，由人告诉机器“我想干什么”。我们从上到下来看这个问题：
+
+当有一个足够聪明的系统时，最上层统一提供的接口应该是一些类似于 `run_inference(model="Qwen3-Max", SLO=50ms, budget=$1000, mode="performance_first")` 这样的 API 来直接告诉系统“我想干什么”。那么在我们希望能够提供这样的接口的情况下，我们的系统需要能够做到很多事情。
+
+在系统的调度层面，我们希望有一个类似 AI agent 的智能体来做自动化的调度决策，而不是传统的时间片轮转与优先级队列。从小的方面说一个最简单的需求，我们在做批量化测试时，特别是不同测试可能需要使用的资源（卡数等）不同，目前都需要人工编写脚本编排来依次启动测试任务。一个更加智能的系统应该能够在我告诉系统我需要完成这些测试任务之后，就自动编排调度，在最大化资源利用完成测试任务的前提下，也不会出现 OOM 等现象。从大的方面说，在我们的云厂商中，有着大量的 serverless 需求，这些需求都应该由系统的智能调度决策自动化地解决，从而避免大量的人类专家编写规则与试错调优，进而减少资源利用的 bubble。最终实现用户只需要负责提交任务，以及任务需要满足的 SLO 等性能需求指标、执行任务的预算，系统就能根据需求自动化地做任务调度。
+
+在硬件抽象层面，从传统的 CPU 为中心，到现代的系统已经在面对越来越多样的异构硬件（CPU, GPGPU, NPU, TPU, etc），传统 OS 缺少对各类异构硬件的状态感知，需要各种硬件之间的不同 API 来反复同步状态，任务在不同异构硬件之间的分发与决策也需要大量的人类专家经验来调优（例如在 LLM Infra 领域的很多将部分需求卸载至 CPU 计算的工作）。在 AI for OS 下，我们可能会希望系统层面能够自动感知这些异构硬件的特征、当前状态等等，实时评估当前硬件能够提供的资源，甚至提供对未来的预测能力，以此提供抽象并暴露一些接口，从而屏蔽异构硬件的区别，让上层看到的只是简单的不同资源和能力，从而根据任务需求做自动化地任务分发与调优。
+
+以上纯属民科瞎谈，不涉及任何技术建议，但是技术总归是在不断演进的，仍然需要许许多多踏实的科研工作一步步尝试和推进，从而探索和实现未来科技的可能性。总而言之，我们这些在当代做计算机系统的工程师们，又何尝不是七八十年前那些负责把纸带一个个塞到大型机上运行，同时反复修理大型机故障的人呢？这又本该如此吗？
+
+参考资料：
+[1]  https://arxiv.org/abs/2507.08800
+[2] https://en.wikipedia.org/wiki/Operating_system