由于创业的缘故，2025 年过得特别快，我也没有太多时间去记录和反思。同样地，能够写一些自己感兴趣的代码的时间也变少了不少。随手记录一些印象比较深刻的事情吧，前面可能偏向技术，后面可能会偏向生活。比较杂乱，姑且一读。
一月份 DeepSeek 像一道闪电划过天际，我也被深深地震撼到了。趁着春节假期，我部署了一个小参数的版本在自己的服务器上玩了一阵子，发现 vLLM 对于 DeepSeek 的支持在那时还不是特别好。在 DeepSeek 之前的开源模型，都不支持 reasoning 的能力，因此 vLLM 并不支持 reasoning outputs，因此使用起来非常不方便，需要手动区分推理和最终输出部分，在流式输出的时候更是如此。
因此我花了一些时间，给 vLLM 提交了 PR [Frontend] Support reasoning content for deepseek r1。因为本身这一功能涉及到 streaming，function calling 等不同的推理特性，最开始实现的时候代码交织在了一起。为了确保未来其他 reasoning 模型也能复用，参考 vLLM 那时的 function calling parser 的设计，实现了一个比较通用的 reasoning parser。因此改动比较大，加上文档一共有 1000 行左右。但那时 vLLM 的社区非常活跃，经过了几轮的 review 和修改，最终 PR 在一周内就被合并了，现在 vLLM 到了 v1 版本也仍然在沿用这个设计。
虽然我一直不是特别看好模型推理的市场以及就业前景，但作为一个工程师来说，性能优化和系统设计的挑战还是非常有趣的。后续我也继续围绕 vLLM 继续参与了一些工作。比如 vllm-production-stack，基于 LMCache 和 vLLM 在 Kubernetes 上部署一个可扩展的推理服务，能够支持 request routing，kv offloading 等特性。
不过最让我感兴趣的是 [Feature]: Support torch.distributed as the runtime for multi-node inference。本身 vLLM 的分布式推理需要依赖 Ray，Ray 虽然确实是一个很好的分布式计算框架，但对于部署非常静态的模型推理服务来说，使用 Ray 会增加不少复杂度。相比之下，PyTorch 自带的分布式计算功能就要简单很多，尤其是在现代生产环境普遍使用 Kubernetes 的情况下，使用 torch.distributed 作为分布式推理的后端会更加方便。我花了一些时间实现了一个原型，脱离了 Ray 后分布式推理就非常简洁：
# single node, multi-gpu
torchrun --nproc-per-node=n python -m vllm.entrypoints.openai.api_server $args
# multi node, on node 0
torchrun --nnodes 2 --nproc-per-node=n --rdzv_backend=c10d --rdzv_endpoint=${node_0_ip:port} python -m vllm.entrypoints.openai.api_server $args
# multi node, on node 1
torchrun --nnodes 2 --nproc-per-node=n --rdzv_backend=c10d --rdzv_endpoint=${node_0_ip:port} python -m vllm.entrypoints.openai.api_server $args
类似这样的命令就可以启动一个多节点的分布式推理服务了，这跟 SGLang 的设计很像。不过我观察到 SGLang 社区也有 issue 希望为 SGLang 增加 Ray 的分布式支持 [Feature] Support Ray Backend for distributed inference，我自己还是持保留意见。如果要考虑上层调度的兼容性，那我认为 vLLM 支持 torch.distributed，调度完全交给 Kubernetes 会是一个更好的选择。Application 层面的调度也交给 Kubernetes 来做，会拥有一个更加统一的调度视角。
说到这个，我觉得 Kubernetes 已经事实意义上被 Mesos 的双层调度设计夺舍了。Kubernetes 的 CRD operator 和自定义调度器，已经成了支持不同工作负载不可或缺的一部份。事实证明 One for all 是很难做到的。
重新说回 AI，仅在今年，美国科技巨头在AI基础设施上的资本支出就已达到惊人的 3000 亿美元——这相当于美国全年关税收入的 1.5 倍。对于美国而言，AI 似乎已成一个 “All in” 的战略方向。在股市中，英伟达、苹果、微软、谷歌、Amazon 与 Meta 这六家公司的总市值，已占据美股的 30% 以上。
许多分析都从资本支出的角度，预言 AI 在 2026 年将继续高歌猛进。但资本支出是一个滞后指标。数据中心的建设必然早于模型的预训练，而预训练水平的提升虽受益于算力基建，却并非简单的线性关系。即便预训练技术进步停滞，资本支出也可能因建设周期而惯性延续。
那么，大语言模型的预训练是否正在触及瓶颈？关于这一点，我与 Yibo Zhu 在知乎的回答中的看法相似。感兴趣的朋友可以去看看。
最后聊聊 agent infra，人人都在谈论 agent，但到底什么是 agent 需要的基础设施？Agent 是不是需要新的基础设施？我觉得目前还没有一个清晰的答案。回顾软件工程的历史，基础设施的变革往往源于需求的巨大变化，但是需求的巨大变化并不一定会带来基础设施的变革。传统互联网的业务复杂度提升带来了分布式系统的兴起，使得单体应用逐渐被微服务取代，从而诞生出了分布式数据库事务，分布式一致性协议，服务网格等一系列新的基础设施。而新的线上线下一体化业务场景，比如饿了么、美团等，在需求和模式上发生了巨大变化，但是基础设施的技术上并没有发生根本性的变革，只是上层业务形态变得更加复杂了。
Agent 可能存在一些安全，可观测性等方面的需求，但是这些需求并没有达到需要基础设施变革的程度。绝大多数 AI 在不同场景的应用，只是稍微往计算密集的工作负载方向偏移了一些，比寻常的业务多需要一些 GPU，并没有带来基础设施的变革，仍然是一个个独立的服务在运行着。不少 agent infra 提到的 state management，tool use 等等，也都是在应用层面进行的设计，并没有触及基础设施层面。到最后你依然需要的是跟之前一样的集群调度系统，虚拟化技术等等。我能看到的 AI infra 的机会仍然只有计算和存储，具象化到产品就是硬件层面的加速卡，芯片，和软件层面的推理服务产品和数据库/搜索引擎。
最后分享一下生活。今年 3 月份我和小徐去日本旅游了几天，距离我们上次旅游已经要四五年了。这次我们去了大阪，工作日的时候我在远程办公，周末的时候我们一起逛了道頓堀，天守阁，还有几个并不那么热门的临海的小地方，临空城什么的。大阪是一个人山人海的城市，我从没有见过这么多游客。尤其是道頓堀，简直就是人挤人的节奏。感觉整个大阪都被游客给占领了。这种地方对于我来说，呆几天体验一下还不错，但如果长期生活的话，估计会被折磨死。
大阪的旅游资源我自己觉得不是特别多，其中著名的天守阁游客非常多，进去需要脱鞋，而我和小徐没有事先调研，去的时候没穿袜子，光脚走在上面还挺冷的。虽然天守阁里面不是非常有意思，但是外面的景色跟刺客信条影里的风景极其相似。小徐自己在工作日还去了奈良，见到了会鞠躬的鹿。欲望不仅会规训人类，也规训动物。
为了办理美国签证，我和小徐还在周末去了一趟武汉。武汉呆的时间不久，给我印象最深的是黄鹤楼和藕汤。黄鹤楼的风景确实不错，登高望远，江城尽收眼底，就是仍然是熟悉的人山人海。藕汤倒是让我印象深刻。我本来以为藕汤就是简单的莲藕做成汤，以为没有多少。我和小徐去店里点了不少菜，上菜后发现藕汤份量极大，还有大量的肉骨，很好吃但量实在太大。在上海被小份量的饮食和超高物价洗脑太久，以至于吃完结账的时候我还在认真思考是老板做慈善还是我在上海做冤大头做久了脑子坏掉了。
下半年的时候我们去了美国加州呆了一段时间，多亏是跟 Allen 一起去的，不然我们是无法生存的。湾区的风景确实非常棒，海景和山景交相辉映，非常漂亮。不过生活成本实在太高了，吃饭和住宿的费用都非常惊人。去了后除了工作外，还见了不少多年未见的朋友，下次见面不知道是什么时候了。
今年我玩的游戏不是特别多，没有什么印象特别深的作品。33 号远征队创历史的年度最佳奖项记录，人情世故。丝之歌的正反馈直到我退游也没感受到。不过今年 10 月我捡起了去年 12 月就发布的燕云十六声。刚发布时候我感觉手感好差，再加上那时候有很多游戏可以玩，很快就弃坑了。今年趁着十一假期，我重新玩了一下，确实给了我很多惊喜。虽然还是有网游的味道，但整体的剧情和玩法设计都非常不错。这是为数不多让我觉得玩得下去的 MMO 游戏，推荐给大家。
写这些时翻了翻相册，看到半年前去世的猫，忽然就想起“当时只道是寻常”这句话。当时觉得普通的日子，现在回看却那么珍贵。一度不想写下去，但坚持了十年的习惯，也不想断在这里。就简单记下这些吧。希望读到这篇文章的朋友和我自己都能够珍惜眼前。
往年总结
License
- This article is licensed under CC BY-NC-SA 3.0.
- Please contact me for commercial use.