点击下方卡片，关注【Xbotics具身智能实验室】公众号
你想要的这里都有~~
作者/木木
7月底，媒体人张小珺在其访谈节目《商业访谈录》中，与游凯超进行了一次长达三小时的深度访谈。游凯超是开源大模型推理引擎 vLLM 的核心维护者之一，也是由该项目团队孕育而生的创业公司 Inferact 的联合创始人兼首席科学家。在这次访谈中，他围绕开源基础设施的成长路径、社区与商业化的关系、以及从一群志愿者走向公司化组织的完整过程，分享了大量一线经验和判断。这些经验和判断，也为我们思考 Xbotics 社区自身接下来该如何发展提供了一份可参照的样本。本文基于该访谈内容进行二次整理与讨论，如有侵权请联系删除。
Xbotics 最初并没有公司的形式，它更像一个自然生长起来的技术共同体。一群来自不同城市、不同学校和不同公司的开发者，因为对机器人和具身智能的共同兴趣聚在一起，讨论技术、分享项目、组织活动，一点点把社区的影响力做大。这种方式构成了社区宝贵的起点。
随着参与者越来越多，合作企业、课程、开发者计划、校园活动和项目交付逐渐增加，我们开始面对一个新的问题：一个靠
着兴趣和热爱聚起来的社区，怎样进一步成长为一个能够长期建设技术、组织开发者并承担行业责任的共同体？
最近听到游凯超分享他在 vLLM 项目里的经历，觉得很值得参考。
vLLM 最开始是伯克利几位学生的一项研究项目，2023 年开源后，游凯超于 2024 年加入，成为核心维护者之一，后来这个项目慢慢发展成了全球都在用的大模型推理基础设施。
这段经历也让我们看到，一群最初靠兴趣聚起来的开发者，是怎样逐渐形成社区、基金会和公司这样的多层组织结构的；也让我们看到，在 Coding Agent 快速发展的时代，开源社区身上那种真正不可替代的价值。这里把这些内容整理出来，和大家一起分享。
很多开源项目起步时，只是一群人凑在一起写代码。真正让它走远的，是后来慢慢共同承担起来的技术判断、组织协调、治理机制、资源投入和长期责任。这些东西攒到一起，才让一群人真正拧成了一股绳。这一点，Coding Agent 做不到。
对于 Xbotics 来说，真正值得思考的问题，是怎么让社区从聚起一群人，走向共同完成一件长期有价值的事。这比单纯把社区人数做大重要得多。
一、开源的起点：相信好项目总会有人使用
游凯超对开源软件的兴趣很早就有了。
2019年，他在加州大学伯克利分校进行暑期研究时，开始认真考虑做机器学习系统。但他也有一个顾虑：自己没有名气，即使投入时间做出一个系统，也可能没有人使用。
于是，他问伯克利计算机系教授 Ion Stoica：
“我如果想做一个机器学习系统，但是可能又没有人用，那我做这个系统的时间是不是浪费了？”
Ion Stoica 回答得很直接：
“只要是一个好的软件，总会有人用的。”
这句话没有让游凯超立即改变研究方向，却在他心里埋下了一颗种子。一个软件有没有价值，不取决于作者是否有名，而取决于它能不能解决问题，能不能真正被人使用。
此后几年，他开始陆续参与开源软件建设。
2020年，他加入本科同学翁家翌发起的“天授”强化学习框架，成为早期贡献者，参与完善数据处理、异步采样和多智能体训练等基础功能。2023年，他又与合作者将 Efficient ConvBN 方法贡献给 OpenMMLab 和 PyTorch，帮助使用者减少模型训练所需的时间和显存。
这些工作并不只是把代码公开出来。代码进入开源社区以后，还要被其他人使用、发现问题，再在一次次反馈中继续修改。
在游凯超看来，开源也不一定只发生在代码里。
“开源不一定是算法，也包括一些技术心得的分享，社区自由沟通的过程。”
从2016年开始，他便持续在知乎分享技术经验、研究方法与个人思考。写作不仅是向外界输出，也是检验自己是否真正理解了一件事情：
“你没有办法清楚、清晰地写下来，说明你对它还不够了解。”
因此，他对开源的理解从一开始就不只停留在公开代码上。做软件、分享经验、和社区交流，这些事情后来慢慢连在了一起。
二、加入别人的项目：开源不一定要从“我是创始人”开始
很多技术人员愿意创建自己的开源项目，却不一定愿意长期维护一个并非自己发起的项目。
因为在传统的学术和创业叙事里，“创始人”“第一作者”“原创者”往往被赋予了更高的价值。加入一个已经存在的项目，意味着个人名字未必出现在最显眼的位置，也很难把项目完全归属于自己。
但游凯超加入vLLM时，并没有过度纠结这一点。
vLLM最初来源于伯克利的PagedAttention研究。项目开源时，已经有论文作者和早期维护者。游凯超大约在2024年成为第四位主要全职投入的核心成员之一。他不是最初发起人，但他认为这并不重要：
“我觉得不需要，更多看你能在里面做什么贡献。”
当时的vLLM发展很快，却处于严重缺人的状态。相比重新发起一个属于自己的项目，他更看重的是这个项目所处的历史位置。
ChatGPT已经证明了大模型的巨大价值。行业中的大量注意力仍集中在如何训练模型，但模型训练完成之后，必须通过推理系统才能进入真实应用。游凯超判断，推理会成为整个大模型产业不可绕开的基础设施，而vLLM有机会成为其中最重要的项目之一。
他形容自己当时的想法是：
“我觉得这个历史机遇摆在面前，我觉得值得投入精力去维护它。我就尽己所能地去帮助它吧。”
这种投入背后的驱动力，并不是短期收益。
游凯超谈到，不同的人可能追求金钱、权力或者职位，而他更重视的是：
“我追求的就是意义，就是我做的事情是不是有意义。”
在他看来，vLLM有足够重要的历史意义，值得投入。早期加入项目的很多成员也有类似判断。艰难的维护环境反而筛选出了一批真正热爱开源、热爱技术的人。他们共同维护项目多年，最终自然成为后来创业公司的初始团队。
这说明，一个开源项目最初的组织基础，并不是劳动合同，而是共同的价值判断：
我们是否相信这件事情值得被做成。
三、从维护代码到建设社区：真正的社区不是拉群和发内容
2024年，vLLM的主要任务是将研究原型重构为生产级系统。到2025年，随着DeepSeek等中国开源模型快速发展，vLLM开始面对另一项任务：建立中国开发者与全球社区之间的连接。
vLLM诞生于美国，最初主要使用Slack和英文进行沟通。从形式上看，中国开发者也可以加入；但在实际参与过程中，存在两个明显障碍。
第一是语言。国内开发者更习惯用中文讨论复杂技术问题。
第二是工具。由于现实环境的差异，国内开发者使用Slack等海外协作工具并不总是方便。
游凯超回国后，从零开始搭建vLLM中文社区，建立公众号、知乎、小红书等内容和沟通渠道。但这些只是外部可见的部分。
真正重要的工作，是他开始走访国内模型公司，了解这些企业如何使用vLLM，遇到了什么问题，新模型将采用怎样的结构，哪些能力需要提前支持，以及社区现有设计在哪些地方无法满足真实部署需求。
“把大家串起来。”
这里的“大家”，既包括国内模型公司、硬件公司和云厂商，也包括海外核心维护团队和普通开发者。
因此，社区建设并不只是扩大用户数量。真正有价值的社区，需要完成多种连接：
让用户的问题能够传递给维护者，让模型公司的设计能够提前与推理引擎对接，让硬件厂商的能力进入系统适配路线，也让国际开源项目能够真正吸收中国开发者的需求和贡献。
社区的价值，不是制造热闹，而是降低不同参与者之间的信息损耗和协作成本。
面对中国模型密集发布、社区人员持续流动以及系统不断重构的压力，游凯超对那段经历的总结非常克制：
“我不敢说我们做得非常好，只能说我们撑过来了。”
这句话或许比“社区快速增长”更接近大型开源项目的真实状态。
开源基础设施的成功，不是某一次发布制造了多大的声量，而是在模型、硬件、人员和需求不断变化时，项目依然没有中断，用户依然可以使用，问题依然有人处理。
四、开源不等于没有决策
当一个项目只有几个人时，很多事情可以依靠非正式讨论解决。
但当项目拥有数千名贡献者，背后还有芯片厂商、云厂商、模型公司和软件企业参与时，“所有人平等讨论，直到形成共识”并不是一种可持续的治理方法。
vLLM采用分级治理结构。
最上层是少数能够最终拍板的核心决策者。游凯超将这一角色称为“仁慈的独裁者”：
“我们有几个我们叫做仁慈的独裁者，就是可以最终拍板的。”
在日常沟通中，核心团队会尽量平和地听取各方意见；但在涉及重大架构、项目方向和长期维护成本时，必须有人作出最终决定：
“如果有重要的决定要拍板，或者说我们有的时候有一些比较强烈的坚持的时候，那这个时候大家得听我们的。”
在核心决策层之外，还有十余名负责重要模块的核心维护者、数十名负责日常代码开发的Committer，以及更大规模的社区贡献者。NVIDIA、AMD、Red Hat、Amazon、Google等公司也会投入资源参与维护，核心团队还需要协调不同企业之间的合作。
在成熟开源社区中，真正具有决策权的，通常不是声音最大的人，而是对项目理解最深、投入时间最长、承担后果最多的人。
核心团队每周会讨论接下来需要推进的重点事项，其他日常交流则更多通过公开Channel完成。整体上，它既不像传统公司那样依靠严格的上下级关系，也不是完全松散的兴趣小组，而是一种围绕技术责任形成的分层组织。
五、治理最难的不是决定做什么，而是决定不做什么
开源项目规模变大后，最稀缺的资源往往是注意力。
每个用户都有自己的使用场景，也都可能认为自己的需求非常重要。如果维护者试图满足所有人，系统会迅速陷入功能膨胀：
每增加一个特性，都要考虑它与数百种模型、不同硬件和其他功能的兼容；每保留一个已经不再主流的接口，都意味着未来还要持续测试、修复和适配；每接受一个短期需求，都可能给长期架构增加新的分支。
因此，游凯超认为，大型开源项目最重要的工作，是确定优先级。
“仁慈的独裁者”有时必须作出并不讨好用户的决定。
比如从vLLM中删除Beam Search。仍有推荐系统开发者认为该功能非常重要，并持续向团队表达不满。但核心团队判断，Beam Search已经不符合当前大模型推理的主要工作负载，继续维护只会让模型适配和推理引擎架构变得越来越复杂。
他的解释是：
“仁慈的独裁者就意味着有些时候你需要对方向进行一些取舍，就是不能够做一个老好人。”
项目的主要优先级被放在大模型、大集群和主流推理负载上。对于几百兆的小模型等非核心场景，团队不会投入同等资源。
这背后是一条重要的开源治理原则：
开源项目不是公共许愿池。
开放意味着用户可以提出需求、参与讨论和贡献代码，但不等同于维护者必须满足所有需求。项目方向必须围绕长期价值，不只围绕短期抱怨进行摇摆。
一个成熟维护者的价值，往往不在于写了多少代码，而在于拒绝了多少会让系统失控的功能。
六、为什么志愿者社区最终无法独立支撑基础设施
很多开源项目的早期，都依靠成员的业余时间和个人热情运转。
但当项目进入生产环境后，这种模式会遇到非常具体的限制。
首先是人力的不确定性。
开源贡献者有自己的学业、工作和家庭安排，会不断加入和离开。社区可以向参与者提出请求，却很难要求某个人在明确时间内完成一个持续数月的关键功能。
一个企业可以安排季度目标、确定负责人并追踪进度；一个松散社区只能请贡献者“尽力而为”。
这使开源社区能够完成很多局部功能，却很难支撑需要长期连续投入的基础设施建设。
第二个限制是算力。
2024年，模型规模相对较小时，单台机器甚至单张GPU就可以完成不少开发和测试。随着模型和部署规模增大，许多优化必须在集群环境中完成。
但企业可以向社区临时提供一台机器，却很难长期提供一整个集群。
游凯超形容当时的情况是：
“为了做一些集群级别的优化，我们就只能去各处乞讨。”
团队可能先花一个月说服企业提供机器，拿到资源后又必须迅速完成所有实验，因为机器一个月后就会到期。资源甚至可能因为企业内部紧急项目被临时收回。
这种环境下，开发者无法稳定规划技术路线，大量精力被消耗在寻找和协调资源上。
第三个限制是法律主体。
vLLM需要提前支持尚未发布的新模型和新硬件，合作方会提供保密信息，并要求签署NDA。
问题是：
“这个保密协议谁来签？这是一个很尴尬的问题，开源社区它不是一个实体。”
企业还需要确认哪些人会接触信息、参与者是否会发生变化、其中是否存在竞争对手，以及一旦泄密由谁承担责任。
这些事情都不是一个松散社区能够解决的。
当项目同时面临稳定人力、集群资源和法律责任问题时，成立公司就不再只是商业选择，转而成为项目继续发展的必要条件。
游凯超后来总结，当时的情况已经非常明确：
“没有一个公司的支持，这个项目已经无法继续往下发展。”
七、基金会和公司分别解决两种问题
很多人会认为，一个项目一旦成立公司，就意味着它会逐渐从公共社区变成公司的私有资产。
vLLM采取的路径并不是把项目直接归属于公司，而是先将项目捐赠给PyTorch Foundation，再由核心团队成立公司，承担技术维护和商业化工作。
基金会主要解决的是开放性和长期中立问题。
游凯超说，将项目捐给基金会的意思是：
“这个项目它至少不会变成一个闭源的项目，就是它始终是开源的。”
vLLM的商标等公共资产由基金会持有。核心团队即使成立公司，也不能直接将vLLM闭源，并继续以原有社区名义对外经营。
为什么不把项目长期放在伯克利或某个实验室中？
因为学校和实验室并不是适合永久维护项目的组织形式。学生会毕业，实验室会重组，负责人会变化，研究中心本身也有生命周期。
基金会则是独立法人，可以长期持有商标、拥有法律团队、接受捐赠并为项目提供治理保障。
但基金会不会替项目编写代码，也不会负责每一次模型适配和性能优化。具体的技术工作仍然需要核心维护团队完成。
公司解决的是另一组问题：全职人力、算力采购、合同、NDA、商业合作和长期执行。
游凯超解释，公司是vLLM技术管理和日常运营的重要参与者，但项目仍属于公共开源生态。Red Hat、NVIDIA、AMD等其他企业同样可以参与维护，也可以围绕项目进行商业化。
他说：
“我们只是作为一个技术参与者和技术领导者，在引领它的发展。”
基金会、公司与社区由此形成三种不同角色：
基金会保证项目不会被某家公司私有化；公司提供稳定资源和执行能力；社区则提供真实需求、广泛使用和多方参与。
基金会是保险杠，公司是发动机，社区是道路和交通网络。
三者缺少任何一个，项目都很难成为长期基础设施。
八、商业化并不必然背叛社区，关键在于钱流向哪里
开源项目成立公司后，社区最担心的问题通常是：商业客户的需求会不会凌驾于公共项目之上？
那么就要坚持原则，不接受与社区长期方向冲突的商业项目。
公司选择的商业合作，应当同时推动vLLM本身的发展。例如，某家模型公司付费要求提前支持一种新模型结构，只要这一能力最终能够进入开源项目，并服务更多用户，那么商业投入就在强化公共基础设施。
相反，如果一个客户要求团队开发与社区方向冲突的私有功能，公司可以直接拒绝。
成立公司后，社区合作反而变得更顺畅。
过去，企业想提供资金或算力，却不知道资金应该进入谁的账户；购买机器和云资源时，也需要合法的采购主体。合作方想签署NDA，社区又没有法人资格。
公司成立后，这些问题得到缓解。游凯超表示，社区和合作伙伴并没有因此降低信任，反而一直期待核心团队成立公司。开源与商业并非天然冲突。真正危险的不是开源项目赚钱，而是商业收益被私有化，维护成本却继续留给社区。
九、为什么应该由核心团队创立公司
大型科技公司拥有更强的资金、算力和工程团队，看起来似乎比创业公司更适合维护开源项目。
但游凯超认为，如果由某一家大厂直接主导，项目很容易带入该公司的立场。
芯片厂商会优先优化自己的硬件，云厂商会优先服务自己的云平台，模型公司会优先支持自己的模型。其他企业可能因此降低参与意愿，担心项目逐渐成为竞争对手的工具。
而由长期维护项目的核心团队成立创业公司，有两个优势。
第一，团队拥有完整的技术历史。
许多架构选择、历史问题和合作关系并没有全部写在文档中，而是存在于长期维护者的经验里。原有核心团队继续负责，可以保证技术路线的连续性。
第二，团队拥有社区正当性。
他们不是突然收购项目的外部资本，而是与社区共同经历了项目最困难的阶段。合作伙伴知道这些人为什么作出某些决定，也知道他们长期坚持开源的立场。
游凯超认为，重要开源项目能否成功，需要三个条件：
首先，必须解决一个真正重要、大家都关心的问题。否则项目没有成长的根基。
其次，需要有一个稳定组织在背后运营和支撑。
最后，创始团队或核心团队需要持续推进项目，保证技术和社区的延续性。
他说：
“创始团队需要在这撑着。”
一旦项目的主心骨发生变化，新的团队不仅需要理解代码，还要重新建立合作伙伴信任、恢复组织记忆，并重新形成决策权威。
AI可以帮助生成代码，却无法自动继承一个社区多年积累的信任关系。
十、对我们Xbotics社区的经验
首先，社区需要明确建设什么。具身智能领域不缺少新概念和项目名称，真正稀缺的是愿意长期维护同一套公共技术资产的开发者。Xbotics应鼓励有能力的成员成为某一技术方向的长期维护者——无论是仿真工具、数据采集、模型部署，还是文档与新手体验。成员的价值不只在于“创建了什么”，更在于“让什么项目持续活了下来”。
其次，现有的媒体内容、课程、活动和厂商资源，必须从孤立的业务模块走向闭环。内容是入口，活动是连接，项目才是沉淀。开发者遇到的问题应被系统收集，企业需求应沉淀为通用接口，教程和Demo应能被他人复现和继续维护。只有当一场活动不仅留下照片和文章，还留下可复现的代码、Issue和文档，才算产生了真正的社区价值。
第三，成熟社区的重要能力是主动取舍。Xbotics需要优先投入具有公共价值的任务——任务与数据标准化、统一接口、仿真到真机模板、可复现基准等。对于高度定制化、无法沉淀为通用能力的需求，应当敢于拒绝。开源项目不是公共许愿池，需要有承担决策责任的人拒绝那些会让系统失控的功能。
最后，具身智能基础设施既不能只靠松散社区的热情，也不能交给某一家机器人公司。Xbotics的潜在价值恰恰在于不绑定单一厂商，能够连接不同高校、企业和开发者，寻找真正具有公共价值的部分。中立性需要机制保障：公开接口、明确许可证、公开提案、一致的接入条件。更合理的组织方式是形成多层结构——社区定义公共问题，核心团队保持技术连续性，公司提供资源和执行力，中立治理保证公共属性。
社区的正规化不等于放弃热情，而是保护这种热情不被无休止的临时工作耗尽。Xbotics最终要回答的问题是：当行业热度变化之后，是否仍然有人愿意把这些基础工作继续做下去。
-END-
Ask Me Anything｜提问箱
对文章有疑惑，或想聊更深？欢迎把你的问题丢给我们：技术方案、实操踩坑、课程与资料、项目合作、职业发展，都可以问。
怎么问：在评论区留言，或私信公众号
我们会做什么：每周集中整理高质量问题并公开回复，重点问题邀请作者或嘉宾深度解答；典型问题会加入知识库并持续更新。
提问小提示：尽量说明「你的目标—当前做法—期望产出」，附上必要信息（硬件/软件版本、数据规模等），能更快获得有用答案。
一起把问题变成知识，推动社区进步 🚀
