由于创业的缘故，2025 年过得特别快，能写自己感兴趣代码的时间也变少了不少。随手记录一些印象比较深刻的事，前面偏向技术，后面偏向生活，比较杂乱，姑且一读。
一月份，DeepSeek 像一道闪电划过天际，其表现令人震撼。趁着春节假期，我在自己的服务器上部署了一个小参数版本试玩，发现当时的 vLLM 对 DeepSeek 的支持还不是特别完善。在 DeepSeek 之前的开源模型普遍不支持 reasoning（推理）能力，因此 vLLM 本身也不支持 reasoning outputs。这导致使用起来非常不便，需要手动区分推理过程和最终输出，尤其在处理流式输出时更为麻烦。
为此，我花了一些时间向 vLLM 提交了一个 PR：[Frontend] Support reasoning content for deepseek r1。由于这一功能涉及流式输出、函数调用等多种推理特性，最初的实现代码交织在一起。为了确保未来其他具备推理能力的模型也能复用，我参考了当时 vLLM 中函数调用解析器的设计，实现了一个比较通用的 reasoning parser。因此改动较大，加上文档约有 1000 行。幸运的是，vLLM 社区当时非常活跃，经过几轮 review 和修改，这个 PR 在一周内就被合并了。即使到现在 vLLM 升级到 v1 版本，这个设计仍然在沿用。
虽然我对模型推理的市场和就业前景持保留态度，但作为一名工程师，性能优化和系统设计带来的挑战本身就非常有趣。后续我也继续围绕 vLLM 参与了一些工作，例如 vllm-production-stack。这个项目基于 LMCache 和 vLLM，旨在 Kubernetes 上部署一个可扩展的推理服务，支持请求路由、KV缓存卸载等特性。
不过，最让我感兴趣的是另一个议题：[Feature]: Support torch.distributed as the runtime for multi-node inference。vLLM 原有的分布式推理依赖 Ray，Ray 虽然是一个优秀的分布式计算框架，但对于部署模式相对静态的模型推理服务而言，它引入的复杂度有些过高。相比之下，PyTorch 自带的分布式通信库 torch.distributed 就简洁很多。在现代生产环境普遍使用 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 希望为其增加 Ray 的分布式支持，对此我仍持保留意见。如果考虑到与上层调度器的兼容性，我认为让 vLLM 支持 torch.distributed，而将调度工作完全交给 Kubernetes，会是一个更清晰的选择。将应用层的调度也统一到 Kubernetes，能获得更一致的运维视角。
说到这个，我觉得 Kubernetes 在事实上已经被 Mesos 的“两层调度”设计理念“夺舍”了。Kubernetes 的 CRD Operator 和自定义调度器，已经成为支持多样化工作负载不可或缺的一部分。事实证明，一个调度器搞定所有场景是非常困难的。
让我们重新说回 AI。仅仅在2025年，美国科技巨头在AI基础设施上的资本支出就已达到惊人的 3000 亿美元——这相当于美国全年关税收入的 1.5 倍。对美国而言，AI 似乎已成为一项“All in”的战略方向。在股市中，英伟达、苹果、微软、谷歌、Amazon 与 Meta 这六家公司的总市值，已占据美股的 30% 以上。
许多分析都从资本支出的角度，预言 AI 在 2026 年将继续高歌猛进。但资本支出是一个滞后指标。数据中心的建设必然早于模型的预训练，而预训练水平的提升虽受益于算力基建，却并非简单的线性关系。即便预训练技术进步陷入停滞，资本支出也可能因建设周期而惯性延续。
那么，大语言模型的预训练是否正在触及瓶颈？关于这一点，我与 Yibo Zhu 在知乎的回答中的看法相似。我们似乎正处在 计算与数据 的边际效益递减曲线上，单纯堆砌算力带来的进步正在放缓。
最后聊聊 Agent 基础设施。人人都在谈论 Agent，但到底什么是 Agent 必需的基础设施？Agent 真的需要全新的基础设施吗？我觉得目前还没有一个清晰的答案。回顾软件工程的历史，基础设施的变革往往源于需求的巨大变化，但需求的巨大变化并不总会引发基础设施的变革。
传统互联网业务复杂度的提升催生了分布式系统的兴起，单体应用被微服务取代，从而诞生了分布式事务、一致性协议、服务网格等一系列新基础设施。而像外卖、新零售这种线上线下融合的新业务场景，虽然在需求和模式上发生了巨变，但其底层基础设施在技术上并未发生根本性变革，只是上层业务形态变得更加复杂。
Agent 可能会在安全性、可观测性等方面提出新需求，但这些需求目前看来，似乎还未达到必须引发基础设施革新的程度。绝大多数 AI 在不同场景的应用，只是让工作负载稍微向计算密集型偏移了一些，比寻常业务多需要一些 GPU，并没有带来基础设施的质变，它们仍然是一个个独立运行的服务。不少所谓的 Agent 基础设施提到的状态管理、工具使用等，也大多是在应用层进行的设计，并未触及基础设施的核心。到最后，你依然需要和之前一样的集群调度系统、虚拟化技术等等。我能看到的 AI 基础设施机会，仍然主要集中在计算和存储领域，具体到产品就是硬件层面的加速卡、芯片，以及软件层面的推理服务产品和数据库/搜索引擎。
在技术之外，也简单分享一下生活。今年三月，我和小徐去日本旅游了几天，距离我们上次出游已有四五年。我们去了大阪，工作日我远程办公，周末一起逛了道顿堀、天守阁，还去了临空城等一些不那么热门的临海小地方。大阪游客之多超乎想象，尤其是道顿堀，完全是人挤人的状态，感觉整座城市都被游客“占领”了。这种地方短期体验不错，长期生活恐怕会让人疲惫。
大阪的旅游资源我觉得不算特别丰富。著名的天守阁游客极多，进去需要脱鞋。我和小徐没做功课，去的时候没穿袜子，光脚走在上面还挺冷。天守阁内部陈设一般，但外面的景色与《刺客信条：影》里的场景极其相似。小徐在工作日独自去了奈良，见到了会鞠躬的鹿，让人不禁感叹，欲望不仅规训人类，也规训动物。
为了办理美国签证，我和小徐还抽空去了一趟武汉。停留时间虽短，但黄鹤楼和藕汤让人印象深刻。黄鹤楼登高望远，江城景色尽收眼底，当然，依旧是人山人海。藕汤则彻底颠覆了我的认知，我原以为就是简单的莲藕清汤，结果端上来是一大砂锅，里面满是粉藕和大块的肉骨，味道鲜美，分量实在惊人。在上海被精致小份和高物价“熏陶”太久，结账时我甚至认真思考，是老板在做慈善，还是我在上海当“冤大头”太久导致认知出现了偏差。
下半年，我们去了美国加州呆了一段时间，多亏有朋友Allen同行，否则生活上会遇到不少困难。湾区的风景确实壮丽，海景与山景交相辉映。不过生活成本也高得惊人，吃饭住宿费用都令人咋舌。除了工作，也见了不少多年未见的老友，下次相聚不知又是何时。
今年玩的游戏不多，没有印象特别深刻的作品。《33号远征队》创纪录地拿了年度最佳，多少有些“人情世故”的成分。《丝之歌》玩了很久，直到弃游也没感受到足够的正反馈。不过，今年十月我捡起了去年十二月发布的《燕云十六声》。刚发布时我觉得手感很差，加上当时可玩的游戏多，很快就弃坑了。今年趁着十一假期重新尝试，却给了我不少惊喜。虽然仍带有一些网游的“味道”，但整体的剧情和玩法设计都可圈可点，是少数能让我玩下去的MMO，在此推荐一下。
写这些文字时翻了翻相册，看到半年前去世的猫，忽然就想起“当时只道是寻常”这句话。当时觉得普通平凡的日子，现在回看却显得那么珍贵。一度不想写下去，但坚持了十年的习惯，也不想断在这里。就简单记下这些吧。希望读到这篇文章的朋友，和我自己，都能够珍惜眼前。
往年总结
- 2024
- 2023
- 2022
- 2021
- 2020
- 2019
- 2018
- 2017
- 2016
- 2015
- 2014
License
- This article is licensed under CC BY-NC-SA 3.0.
- Please contact me for commercial use.
如果你对 AI 系统优化、分布式推理或更多技术实践感兴趣，欢迎到 云栈社区 交流讨论。
发表于 7 天前
|
查看: 18|
回复: 0
