这周真正值得收的就一条。八月初挂上 arXiv 的一篇论文，干的事很朴素：去开源软件系统里数一数，大语言模型的服务框架到底哪些真的在被用。
serving framework，简单说就是把模型跑起来、对外提供推理服务的那层东西。vLLM、SGLang、TensorRT-LLM、LMDeploy、FlashInfer，论文把这五个翻了个底朝天。
结论不复杂。vLLM 是采用率和关注度最高的那个。服务方法里，并行计算、内存管理、网络剪枝是被用得最多的三类。
为什么单独收这条？因为它拆掉了一个流行的错觉。
网上聊推理栈，总给人感觉大家在搞花式组合。这个框架取长补短，那个方法交叉混搭，仿佛每人手里都有一套精心拼出来的服务栈。论文数完发现，多框架组合使用的情况很少。绝大多数开发者就用一个框架，从头用到尾。
组合在理论上确实有好处，论文自己也承认，不同框架在服务栈不同环节能互补。但实践里没人这么干。为什么，论文没给硬解释，我也不替它编。我的猜测是维护成本。这是猜测，先标在这里。
这条对普通人的意义，比看起来大。
你如果刚起步，正纠结该用哪个 serving 框架、要不要同时学两三个，这篇论文等于替你把答案数出来了：别人也只用一个。工具之间的差距，远小于坚持用下去和反复横跳之间的差距。这个话我之前收 MCP 那期讲过一次，这次算是有了数据撑腰。
另外两条小发现，顺带收着。
一条是框架选择不是随机的。用哪个，跟模型系列、模态、模型规模、部署环境都相关。白话版：不存在一个“最好的框架”，只存在“你这个场景下最合适的”。这话说出来像废话。但每次有人问“vLLM 和 TensorRT-LLM 哪个好”，答案确实就是这个废话。
另一条是仓库层面的观察。这些框架撑起来的活，比“跑个 chat”宽得多：强化学习推理、多模态生成和理解、微服务架构、云基础设施。这个我只看懂了一半，RL 推理那部分的用法还没吃透，先放在这里，懂了再补。
说回那个错觉。我多想了一步。
单框架为主，往坏处看是锁定。整个服务栈长在某一个框架上，迁移成本只会越来越高。论文没讨论这个风险，它做的是经验性描述，不是判断。光看“大家都在用 vLLM”是不够的，得知道这个“都在用”本身有另一面。
不过这段我写着写着有点动摇。对绝大多数人来说，规模根本没到需要操心锁定的程度。先把一个东西用熟，比提前替未来的自己焦虑，健康得多。所以这段就当没写。或者写成：等你真有迁移需求那天，这篇论文还在那里。
最后补一句选这条的理由。这篇是软件工程子领域的论文，做大规模经验性刻画，不提出新方法。这种不发明东西、只看清楚现状的工作，恰恰是普通人最该多看的。新方法的论文三个月就过时，现状刻画能管好几年。判断一篇值不值得跟，看它回答的是“有什么新东西”还是“实际在发生什么”。后者往往更耐放。
本周就这些。
上面有任何一条你试过、或者觉得我讲错了，欢迎告诉我。那篇论文你要是也读了，RL 那部分看懂的，特别欢迎来给我讲讲。
下周见。