开源如何选择商业模式并构建护城河？

我现在做的 Startup 叫 LeptonAI，我们做的事情简而言之是两件：第一件事是在今天 AI 供应链非常紧张和混乱的情况下，提供一个云原生的高效云平台为用户获取及管理资源；第二件事是在这个平台上提供一个高性能的计算引擎，来更好地驱动，比如说像 LLM、AIGC 这一系列的工作。

公司还没到一年，我们几位联合创始人都在开源领域做了比较长时间。我自己最开始在 Berkeley  做 Caffe，后来在 Meta 等公司做 TensorFlow、PyTorch 等一系列 AI 框架的工作。前些年在阿里，在大数据业务外兼任了阿里开源委员会的负责人，各种滋味也是一言难尽，整体感觉国内大厂其实还是在不断的拥抱开源当中学习，这个有点像改革开放刚开始的过程，还有很多路要走。

我们的其他一名联合创始人是白俊杰，他在 Facebook 期间参与开发了一个开放神经网络交换标准，名为 ONNX (Open Neural Network Exchange)。它对于很多硬件企业来说是一个很好的工具，方便做模型整合，尤其是类似优化适配等。比如说高通 (Qualcom) 在做硬件的时候，多少会参考 ONNX。最著名的是微软有一个推理引擎 (inference engine) 叫做 ONNX Runtime，也是基于 ONNX。

我还有一个联创叫李响，他应该是云原生基金会 CNCF 技术监督委员会最年轻的核心成员，他早期做了一个开源 raft 实现叫 etcd，是 Kubernetes 生态中最底层的核心组件，我们基本上一直反复在做开源的事。

开源的商业模式可以总结成两个：一个是前 20 年非常流行的 Open Core（核心开源）模式，另外一个是我自己总结的 Open Standard，现在我看见越来越多这样的模式。

Open Core 的模式大概是这样，一个开源软件，比如 Hadoop 或是 Spark，只要有能力的人就可以把它给拉（部署）起来，大家 deploy 的 Hadoop 集群和 Spark 的技术栈等，都是用同样的核心代码来做。开源保证的一件事是懂的人就能把它 deploy 起来，但是小白用户拉不起来比较麻烦。core 是开源的，但是要把它用起来很难。在这个基础上，开源软件公司说帮你做软件部署、托管、运维等一系列服务。通过这样一种方式，core 是开源的，所有人都在跑一样的 core，然后因为上面部署运维较复杂，所以开源软件公司的主要卖点应该说是生产力效率。

Open Core 模式在 10 年前云计算开始之后，就受到巨大冲击。今天我觉得所有开源软件的项目都在骂云，这件事情一定程度上是合理的。但是从另外一方面来说，并不是哪一个人的错，因为云今天解决了一个根本问题，就是它降低了软件的部署运维成本，尤其是像云原生这一套体系出来之后，更多的用户今天在云上就可以非常容易来做一些事情，于是用户就不愿意付费，在云上面用免费的版本就可以了，我为什么还要再给一个开源软件公司去交钱呢？所以大家看见 Redis 把它的许可证改了，改的原因是云厂商吸血，但是一定程度上来说这是一个生产关系改变的结果，所以就是 open core 在前 20 年是一个标准的开源软件的运营方式，但今天我觉得已经不再适用了，主要是因为云和云原生技术的发展。

Open Standard 这个模式我觉得更加有意思一些。它的逻辑是，首先我有一个开源软件，这个软件不差，跑得也很可以，设计也很干净，在这基础上，作为一个开源软件背后的公司，我有一个商业化版本，这个商业化版本有可能是在性能上，有可能是在规模上，有可能是在其他企业级的能力上面，比开源大家自己 deploy 起来的东西更好。

大家好，我叫徐磊，我是 LanceDB 的 CTO。我们主要做从嵌入式到大规模的向量数据库。在这家公司之前，我有 4 年时间在 Cloudera 做开源的 Hadoop HDFS，这也是为什么我和俊平比较熟的原因。我的联合创始人当时也是在 Cloudera 做 Python Pandas，这个开源项目我们也是一直做到今天。

从我们看见的开源能做大的几个公司，如 Red Hat 主要做 support，是开源核心（Open Core），如 MongoDB、Databricks 有一个开源的 core，有一套围绕它的企业级产品，还有一帮更小众的开源初创企业，还在找自己合适的路，所以基本上就是你要不是有开源 core 产品，作为线索漏斗去吸引你的用户，然后用这来做你整个公司的品牌，然后再做差异化功能的落地实践，然后另一种可能就是类似 MySQL 做咨询顾问的工作。

LLM 对开源的影响对我们来说是一件好事，因为没有 LLM 就没有 LanceDB，LanceDB 整个存在的意义就是因为去年有 LLM，所以对我们来说是打开新的市场，然后我们发现有一堆同质的用户有一样的需求，但没有好的社区。这就是为什么我们努力在发展社区，这对我们来说是百分之百完美的用户群体。

我们公司选择开源主要是因为：第一、我们在创业初期的时候，认为我们的团队在 data Infra 和 developer tooling 两个领域比较有优势，可以去做一些差异化。但是在这个领域做开源其实面临比较大的竞争压力，所以我们只能从头第一行代码就开始开源，从最早期来吸引用户，然后由此也就培养出了 LanceDB 社区。

我接着扬清和徐磊两位讲。首先介绍我现在做的 Startup，叫datastrato.ai，我们也是一个开源商业化公司，刚成立不到一年。我们正在做的事情——Data and AI Fabric，总结来说是两件：第一是解决数据在从单云走向多云所产生的一系列新数据孤岛问题；第二是解决在 Gen AI 时代，LLM 对数据consume 的新范式问题，包括一系列的治理、合规以及数据生成。

我的几位联创在开源和数据领域都工作很久。我从大概 15 年前就开始，最早是从贡献 Hadoop 开始。那个时候 Hadoop 还不能在云上部署，AWS 商业版的 EMR 还在测试阶段，还没有大规模部署，也没有开源。我在 VMware 研发 Hadoop 上云和虚拟化特性，并把 HVE（Hadoop Virtualization Extensions）开源出来并贡献给 Hadoop 社区，也成了 Hadoop 社区最早的华人Committer。接下来，我加入了当年最受追捧的开源商业化公司 Hortonworks，成为 YARN 团队的技术 Lead。在 Hortonworks 与 Cloudera 合并之前，我加入腾讯，负责云数仓等数据商业化产品，兼任腾讯开源的主席等。我的几位合伙人都是 Hadoop 和 Spark 社区的早期 Committer，比如邵赛赛，做 Spark 技术的同学应该都认识他，因为他是 Spark 几个核心版本的 Release Manager。

关于开源的商业模式，刚才扬清讲得挺好，最主流的就是 open core 和 open standard。还有一些非主流的，比如说开源软件免费，但结合硬件组合销售。比如像 Intel 的软件工程师其实比硬件工程师还要多，而且大部分软件开源，是很多开源社区首屈一指的贡献者。这些开源软件帮助 Intel 构建了相对 AMD，以及 ARM 的护城河，帮助 Intel 赢得在 CPU 领域的霸主地位；Nvidia 也在走类似的路，很好得支持了 TensorFlow、PyTorch 等开源 AI 框架，并开源 TensorRT 等推理引擎，把它的 CUDA（属于open API，非完全开源）做得很好，这一整套开源和开放的软件架构都是基于 NV 的GPU 的，也帮 NV 构建了一个很好的软件生态层。跟其他的硬件厂商 PK，不仅是性能上的 PK，而是带着整个生态来降维打击。

还有一种非主流的玩法是100%软件开源，然后卖 support 的 subscription。这一般是对自身的技术实力非常自信，且接近开源原始理想的公司。我 2014 年加入的 Hortonworks，就是这样一家公司。上一家类似这种商业模式的公司是 Redhat，取得了很大的商业成功。这是我进入的第一家Startup 公司，然后在这家公司一直待到与 Cloudera 合并。这家公司极致到什么程度？我举一个例子就是它的代码100%开源，且没有去申请任何一项专利。虽然这家公司由于商业模式问题，最终没能完全成功，不过回想起来还是收获了一段有趣的经历，并学到了深刻的教训：只有完整的经历云崛起的整个过程，才能理解我们被 databricks 超越是怎样的意料之外和情理之中。十年前，线下部署比云上部署还是更普遍一些，客户拿了开源且够复杂的东西，就更多想去买 support 并付费。十年后，玩法截然不同。当然，我们相信下一个十年，有更彻底的革命。

所以上面提到的这几种开源商业模式，我都亲身经历过。当然还有一些我没有经历过的，比如说像 Google 做 Android，它并不靠开源 OS 收费，而通过一些 killer app，靠流量和广告赚的盆满钵满。当然，还有一些更小众的，比如说完全靠 donate 模式的个人项目等，这些我认为很难适合我们今天讨论的适合ToB企业的这种大型项目，更主流的还是上面讨论的几种。

我觉得这个问题比较容易回答。成功的创业公司到最后还是商业化，或者说把商业化的路走通。我觉得我们以前说开源，比如开源促进会（OSI）所提出的开源定义（OSD），我对这件事情的态度相对比较实用主义。今天有两派人，一派是开源原教旨主义者，甚至一定程度上是反商业化的，说开源是一个非常纯粹的东西，它不应该和任何商业化相结合。另外一派是实用派， 20 年前的话就是说这个原教旨主义派跟实用派的边界就在使用 GPL 还是使用 BSD 上面， GPL 说你要用开源，就必须跟商业化完全切割，然后 BSD 说没关系，你用吧。今天我觉得开源之争其实变成了用 BSD、Apache，还是用新的这些，比如像 Elastic license 等这些许可证变体上。

我自己的位置可能更靠右一些：我觉得只要是有共享出来的代码，有共享出来的一些技术，有共享出来一些作法，那它大抵就是在开源的环境上，然后就看说谁能够给大家带来便利性。有一个公司叫Vercel，做后端的同学对这个公司不是特别熟悉，但是我说 Vercel 的口号，大家就知道它是做什么：他说他是前端云（front-end cloud）。它干的事是：你只要写这些 JavaScript 的东西，比如写了一个 node.js，我就能够给你的企业直接拉起来。然后提供各种服务，比如各种各样的监控或是负载均衡等，我都帮你搞定。Vercel 是一个毁誉参半的公司，一部分人说它做得非常好，让前端变得非常蓬勃；另外又有一批人说它今天注入了很多  Vercel-specific 的代码，到 node.js， next.js 等这样的开源项目中，所以永远都是一个争论。我个人的看法是要能把商业做出来，然后在一个大家普遍接受的状态和准则上反哺社区，让社区能够活得下去，这是很重要的事。

也有一些非常成功，但又有很要命的项目，比如像 OpenSSL 项目。5 年前这个项目团队无以为继，几千美元都拿不出来，出来一个轩然大波，包括阿里在内的一系列企业都向它捐了一钱，让它续了几年命。但是我相信这几年又会出现类似的事，因为这一波同情过去之后，如果没有一个可持续的商业模式，过两年它还得出来募捐。我的感觉是带着一点商业化活下去，总比非常尊贵地死掉要好。这是我的观点，因为商业化已经是一件很现实的事情，他会把一些没有用的东西筛掉，把有趣有用的东西留下来，然后在有用的基础上再留一些开源社区的贡献，这是一个最好的办法。

成功的定义有很多，但对企业而言，成功的定义只有一个，就是商业成功。开源背后的企业也不例外，开源的公司要赢得商业成功，有几个阶段：第一个阶段，是用户社区的成功，就是你开源的软件要受到用户的欢迎；第二个阶段，就是从社区成功转化为业务的成功，就是你要有规模化的营收进来；第三个阶段，就是你的损益达到平衡点之后，能盈利（profitable），才能到达商业的成功。开源企业要想赢得商业成功，其实这三个环节，步步都不能踏错，所以要一步一步拆开来分析。

刚才我提到大部分所谓的开源公司都死在社区不够壮大。是的，90% 的开源软件公司都死在这一点。其实第一个阶段的门槛是很高的，开源软件成千上万，真正能被大家熟悉和使用的，只有1%，其他 99% 都做了分母。为什么我们觉得好像开源很容易，但赚钱很困难？这其实是因为幸存者偏差，我们根本没有关注过没有人使用的那 99% 的开源项目。不要看很多开源项目 star 数很多，宣传也很广，我关注的永远只有两个：一是用户数，真正在生产业务中有部署的，另一个是活跃贡献者数量。脱离这两个，一切运营手段都只是空中楼阁，项目也无法真正成为 Open Standard。

关于第二个阶段，开源公司背后的业务成功。在 Hortonworks，我们这个阶段是非常成功的。大约在 2015 年，我们庆祝了当时史上最快达到一亿美元（100M）年收入的软件公司。以不到 4 年的时间，打破了微软在 80 年代创造的公司成立 4 年，年收入突破 100M 的记录。

但我们一直没解决 profitable 的问题。很奇怪，一家软件公司以极快速度实现规模化收入，但却不能盈利，为什么？华尔街持续多年不认可 Hortonworks 的商业模式，从持续低迷的股价也能看出来，这也为后面跟 Cloudera 合并、私有化退市埋下伏笔。我们今天回过头来，再复盘它为什么不能实现盈利。刚才徐磊说的点很好，市场上同质化的产品 Hadoop 发行版太多，所以造成它的产品无法合理定价。背后隐藏的问题是：相对于它的价格，它的产品设计的太复杂，维护开源组件的成本太高了。那个时候我们大数据套件（HDP），包括 Cloudera 的 CDH 套件都是多达 20 到 30 个组件，因为资源的限制，反而没有聚焦杀手级产品，比如 SQL 引擎。这造成 Hortonworks 的 Hive LLAP，包括 Cloudera 的Impala 都逐渐落后于竞争对手。那时包括 Snowflake、MongoDB 在内的云上产品就很精简，典型的做法就是百人团队持续聚焦云产品和服务的迭代。

反观那时候我们为了快速追求收入和超越竞争对手，快速扩张营销团队。把销售拉上去之后，因为是线下部署，组件又多，产品就不够稳定。那时候Hortonworks 服务了美国500强企业中的260多家，这些大企业内部 Infra 环境非常复杂。除了要面对各种各样的硬件，还有一些比如防火墙设置等非常琐碎的事情，我们看到大量的技术债在客户那里不断积累，消耗了 Hortonworks 大量的工程师时间，而 Cloudera 的情况也差不多。这也是为什么在 2018 年两家公司合并前一直没能盈利的原因。

Databricks 为什么比我们好，能获得成功？因为 Databricks 第一天开始就想的很清楚，它不想去陷入为客户线下部署与现场支持（on-prem）的模式，而只去解决云上标准化产品的问题，基于标准化的硬件和标准化的设置，这大大简化了技术复杂度并降低了成本。不管是 PLG(Product-Led Growth) 还是Sales-Led, 我认为商业模式要上规模，规模化之后还能盈利是最重要的，Databricks提供了一个很好的参考案例。

HBase 算是相当成功的开源产品，其商业不成功的核心原因就是哪家公司都没法控制。现在来看，我认为所有成功的开源软件，不论是 MongoDB、Elastic、Spark 还是 Kafka，背后都有个核心的公司来控制。如果完全是乌合之众不可能商业成功，要获得商业成功一定是有家公司在背后主控这个产品。但是等 Hortonworks 跟 Cloudera 合并的时候已经太晚了，大势已去。如果再早几年合并，有可能这个情况改观。

仅从HBase 本身来看，产品最开始的市场流行度之类都绝对超过 MongoDB 的，但结果 MongoDB 的市值远远超过 Hortonworks。我觉得这是个核心点，因此我特别不喜欢那种原教旨的那种开源不可以有商业成分的观点，当然这是个人情怀，想做是绝对可以的，但是作为商业化的公司，绝对不能容许那种人进来，他们会让你根本成功不了，企业是要商业成功的。

Redis 就是比较控制的不太喜欢接受别人的代码。我补充一点，刚才提到云能帮助开源，它能让你的软件特别流行之后很多人用，但是有总有一帮懒人，尤其是在美国，就喜欢马上搭起来就能用的，这是一个赚钱的方式。以前没有这个方式，因此许可证就很重要，你不能用 BSD，MIT 或 Apache 这些许可证。像我一开始就想得特别明白，2019 年决定开源时，我完全没想过什么 Apache 许可证，而是采用了 AGPLv3 许可证。我觉得大量用户使用后，就可以考虑卖云服务。

这个其实我也想补充一点，就是说很多开源公司其实也经常会有很大争议，就是说该公司的代码是开源的，但在贡献上非常封闭，甚至会故意排挤外部开发者，来利用自己对开源社区的掌控度。如果外面有人提交一个功能，它会拒绝不让外人提交，然后过一段时间让自己的人来提交。公司一定程度上不得不做一个必要之恶的取舍，亦即控制或是让社区活起来。

我们当时和 Hortonworks 合并，然后我们都经历了这一段历史。Cloudera 最后的结果大家其实也都知道。我们后来也有与之前 Cloudera 的同事做回溯分析，为什么 Databricks 能做得好，或者是 MongoDB 。我们觉得这些公司在技术方面并没有超越 Cloudera，但是在这市场里，Databricks 和MongoDB，他们是在解决一个基础平台关键任务的业务痛点，同时他们是市面里唯一能提供那种规模和品质的方案厂商。但是你看 Cloudera、Hortonworks、AWS、Google、阿里云都有几乎一样的商品，这就导致在这个市场上我们并不突出。

虽然每个公司都在组合不同的产品，但其实最后就是同样的问题的两个不同解决方案的实现。一直以来， Hortonworks 和 Cloudera 一直在做 race to bottom 这样的商业竞争的关系，所以即使我们有一个在业界非常棒的 data Infra 团队，公司也是由多位 Hadoop 创始人发起的，但最后利润非常低，所以我觉得对我和我的联合创始人来说，可能我们从 Cloudera 学到的最重要的一门课是，你需要有一个 very unique prospect selling in this market and you are so much better than the second (找到独特的价值来销售，并且完全领先于第二名)。

一般而言开源用户都是 involve，是自己能搞的能玩的，而付费用户很多时候是专业在别的点，因此需要有人帮我解决问题。或者比如企业说得有一个公司帮我兜底，所以我要买。所以很自然地，我觉得开源不愿意付费的用户与愿意付费的用户之间，天生就不太一样，同时他们之间也有连结。就是很多的开源项目，首先都是以草根的方式，大家从一线工程师开始用，而且用得挺好。然后大家就开始说，那我去公司推广；然后公司说，既然大家都在用，那我们为了企业的生产力就放在产品流程中，那我也去买。就这样，逐渐起来。Vercel 是一个很典型的情况，今天所有的前端工程师都在用，然后公司一看说好使，然后一看一年 10 万块不便宜，所以说要有差异化，但也需要有一个自然转化过程。

从 Hadoop 等几个开源项目的历程来看，我认为有几个很重要的点要把握：第一就是搞清楚产品为什么能赢得客户？开源产品能获客一定是产品本身功能解决了一些场景的痛点，但这些痛点是否通用？是否能让客户付费？就涉及到最重要的商业判断了。如果判断的结论是很难进行商业化落地与推广，就需要继续探索开发其他功能，直到找到可商业化付费的点。这一步判断非常关键，如果判断错了，或者无功而返或是贻误商机。大规模的用户访谈非常重要，最好你在这个领域里有一定的 thought leadership，最好是长期泡在这个圈子，你去问大家才愿意跟你分享真实的想法。

我从 2015 年前起，经历第一代开源 Hadoop体系，到第二代开源 Spark 产品，再到第三代上云后的cloud Lakehouse，都亲身经历过，这让我对产品开发方向有一个比较清晰的取舍，努力避开小众、雷同，或其他难以商业化的点。当你的产品吸引到一些 community 用户在核心系统中使用，我觉得这就完成了第一步。这一步需要提前验证，利用你的社交网络和社区资源。如果不去验证，就只是闭门造车，那肯定是有问题的，这是很多创业者经常遇到的问题。

我们现在做的面向 AI 和多云的下一代 Data Catalog，也是从一开始，就着眼于用户的价值验证。从0 到 1 打开后，怎样做客户增长？我们最近也有不少思考和实践。我们当前肯定还是更依赖社区来的线索，这一点与闭源软件完全依赖销售线索很不一样。我们可以从 issues、社区邮件组、slack 群、社区技术活动里跟用户交流获取直接反馈，看看我们解决的痛点有多大价值，还有哪些共同的、待满足的需求。吸引标杆用户，通过社区用户和案例来不断拓展你的社区边界也特别重要。

激活社区有很多种方式，最有效的一种是让社区的用户主动推广，把自己的案例分享出去，吸引更多的用户进来。还有一个有意思的发现是，在采用新技术方面，开源界也是有「羊群」效应的，像Apple、 OpenAI 这一类头部公司，一旦开始用你的产品或服务，那么很快就会有一批公司会产生兴趣，想尝鲜。

除了用户，对开源社区，开发者或者说贡献者也很重要。刚才我们没有太细聊开发者社区，这个并不是每一个开源项目都一样：有的项目不欢迎外部开发者，只关注用户，我认为这完全没问题。我们看到在很多场景里，社区的外部开发者会把你的开源软件带到一些之前没考虑到的应用场景，从而拓展了开源项目的原先场景，这也是开源项目和社区充满创新活力的原因之一。

在社区用户和开发者的增长和驱动达到一定水平，即细分领域形成了一定程度的优势地位甚至事实标准之后，开源商业化就有了坚实基础，可以构建宏伟蓝图了。这个阶段的商业化可以优先从社区用户里沉淀出来一部分，把它变成你的商业的客户，就是所谓的 Sell-in。这个时候不要太关注单子的大小，从社区联系过渡到商业联系就是一种胜利，因为你明确知道产品在用户的业务中以及创造了价值，虽然有些痛点还没有被当前的方案所完全解决或满足。这些未完全满足的点就是 Sell-up 的机会，比如：性能、监控、安全、合规等。

当然还有一个很重要的点是，公司的目标客户和开源的社区用户有时候并不完全重叠，有些开源用户根本就不是付费客户群体。但这些社区用户并非没有价值，因为他们对现有场景进行了验证，又贡献了更多的新场景和新功能。社区的力量壮大了，有助于你吸引付费客户，因为后者虽然与免费用户不同，但可能有相同的需求与场景。所以要做好开源，一定要积极的拥抱社区和用户，虽然并非每个用户都付费，但他们都同样重要，值得珍视。

对这个问题我反而没有一个特别好的答案。因为我之前所创作或参与的开源软件，基本上都没有走上商业模式。我们最开始做的 Caffe 完全是以一种以学校（UC Berkeley）为基础开源的方式做的。然后后面的两个，一个 TensorFlow，一个 Pytorch，有一个很简单的产品模式，叫做给自己的金主做足够的 Pull Request，这对于社区来说是一个好事，而且我觉得这对于整体的 AI 的开发和发展来说也带来了一个好处，就是它是一个完全开源的模式。

实话说，我自己其实没有特别强的关于开源软件怎么样来做商业化的经验。我自己的经验主要是当时在阿里的时候带 Apache Flink 项目时所感受到的。我觉得怎么做商业化呢？第一个是如果说我们开始讨论商业化，首先肯定会有一个相对比较明确的一个用户群体，在大家觉得说这个技术是有意义的，所谓 user-product-fit，然后在这个基础上面肯定需要去想第二点，就是说 product-market-fit 它怎么变成从 user 和 project 的关系，变成 product 和 customer 的关系。

那这个时候首先会需要想的是这个产品的形态是怎么样的？因为开源软件，大家有最简单的一个使用形态，例如今天用 Python，我就配置安装，用 JavaScript，我就用 NPM来做，基本上就是装一下，然后开始用。虽然简单，但如此做，是无法形成一个软件产品的。

一个软件产品首先它的规格是怎么样的？它的用户入口是怎么样的？用户怎么样来购买？在云上的话，是一个用户先买机器，然后再装软件；还是说用户上来之后预订一个，如数据库、固定规格的软件加部署；又或是今天我们最流行的按需使用的 SaaS 模式。产品形态会带来不同的利润和用户上手（onboarding）的一些挑战，或是定价上的策略。举个例子，比如说用户上来之后需要买一个相对比较大的实例才能玩得起来，那用户说我得先想想再看买不买；如果是一个 serverless 的话，可能会带来大量的垃圾用户，但是用户上手的难度就会低一些。

这里有一个非常典型的一个公司，也是开源的公司叫做 Heroku。我在大概 2015 年至 2016 年的时候用过一次，在那开了一个小数据库，从来没关掉，不知道为什么它没有一个过期的机制。去年的时候它给我发了一个信，说我们要关掉免费的实例，其实我这么多年都没有真正使用。所以关于软件的形态，还是非常需要在最开始走访一些用户，根据我们的潜在客户的情况来做判断。

今天拿 AI 这块举例子的话， 非常多公司在试图做一件事情，叫做 serverless GPU，他们有些很辛苦、失败了，但是还是有一些公司在坚持，比如像 Modal Labs 等一些公司还在做 。Banana.dev 在前段时间写了一篇文章说 we are sunsetting serverless GPUs。为什么呢？因为 GPU 是如此之贵，因此它是不太可能做 serverless 模式的。大家可以想一下，你租车的时候，很难去租到一个法拉利。我们说做这事很难，主要是因为它的产品及成本。所以我觉得从开源项目一开始就来思考产品形态，可能是商业化中最重要的一个事情，这里面可以涉及的事情非常多，且不是我们在技术层面所擅长的。我需要找一个懂产品懂技术的产品经理来做这件事。

站在 LanceDB 的角度，我们可能还在用户获取这个非常早期的阶段。我们刚开始就决定要去针对开发者这个社群，因为我们觉得开发者受 LLM 的影响，尤其是从去年中到去年底，整个产业的形态其实并不是很明确。我们并不知道支持此类复杂情况的基础设施会如何演变，我们很希望在开发者所在的地方开展工作。所以我们就把我们的产品做得非常简单，让所有用户很容易可以装上，然后从这里头我们来得到反馈。我们目前相对大一点的客户是由此转变过来的，就是当他们自己的应用变得更成熟以后，他们开始上产品、上生产线，这个时候他们就会发现新的问题，也帮助我们发现不少问题。我们依托用户反馈来打磨产品，所以更多的是接受反馈再迭代的过程。我们现在所希望做到的，就是从这个反馈循环中找到一些细分方向，然后重复开发功能和产品，并以此来考虑我们的下一步的路线。之后会如何发展，只能以后再说。

我觉得其实有一个点还是比较重要的，尤其是中大一点的客户，其实很关心你的商业模式。我希望用你的东西，也希望你的东西是能长治久安的。不管是我付钱还是别人付钱， 你怎么去让客户对你的商业模式有信心。每个客户都希望少付钱，你需要条理分明地说服用户。在真正的大客户合作中，这点很重要。

我先回答我自己的观点，就 AI 领域来说，其实基本上就是大家都是尽可能地开放。我觉得，越是用户愿意付费来获得的功能，或是乏味但不可或缺的功能，你越需要把它闭源。越是大家觉得说好玩的能吸引大家的兴趣，但是企业不太会为这玩意付钱的功能，就放在开源上面。因为这个是和你的受众有关系的，付费的那个受众是企业，所以说一旦涉及到什么稳定性、规模、安全性等，用户是愿意付钱的。但如果你把它开源出去，这帮开发者们也懒得看，例如集成（integration）这样的功能，不干也无所谓；如果说是那种好玩的，我有一个新的 SQL 功能，能用 AI 产出 SQL，大家一看说好玩的东西能够产生流量，但是企业一看说这玩意我不愿意付钱，那就放在开源这里。一边开源是驱动流量和关注，另外一边企业级产品则是驱动营收，其实就照这样的一个原则。

这块我确实也思考过，到底一个东西要不要开源，除了功能特性本身的属性外，我认为也取决于背后企业所处的阶段。成功的开源企业早期我认为还是尽可能的开源，现在我们回过头去看 Databricks，它在 Spark 等早期项目的开源是非常彻底和坚决的，其他的像 MongoDB、Elasticsearch，也是到了后期为了提升营收才被迫去修改许可证，之前他们也是 Apache License v2 的许可证。

在早期阶段最难的其实是构建出一个真正使用广泛的企业级开源社区。如果这时候你的许可证是不开放的，那实际上成功的几率微乎其微。每 100 家开源公司可能真正懂得把社区建好的可能就 3 至 5家，所以这个比例是 3% - 5%。这个 3% 你能跑出来，就像我刚才提到的三个阶段，在第一个阶段 3% 跑出来之后，后面可能就有 30%-50% 的几率能存活。因此，我认为就早期阶段而言，越 open 越好。

然后我再分享一个，就是关于 feature 是不是要开源，除了自身所处的阶段之外，还要看竞争环境。我再举个例子，还是关于 Databricks的。在2019年之前，它的数据湖仓Delta Lake 是没有动力去开源的，因为它已经过了 Spark 那个培育开源用户的阶段，它需要快速商业化。为什么后来 Delta Lake 又开源了？原因就是被类似的产品——开源 Iceberg 的快速发展刺激了，感受到来自另一个开源产品的极大威胁，因此匆匆忙忙把 Delta Lake 开源出来。直到今天，即使 Databricks 在数据世界里如此成功，在开源数据湖的 Open Standard，还是落后于 Iceberg，以至于去年开始被迫在商业化产品里添加了对 Iceberg 的支持。按照第一性原理， open standard 所构建的用户护城河是开源商业化取胜的关键，市场竞争决定了开源策略。所以在功能级别的考量，第一个要看你的公司在什么样的阶段，然后要看你的竞争对手以及整体的商业策略，当然功能的微观属性也很重要，否则开了没有实际意义。

开源是最近十年左右开始逐渐变化的。最近十年硅谷的 VC 也在思考这件事情，我跟好几个 VC 交流过，他们比较一致的想法是本来我做一个闭源的东西，可能一两年可以看到什么机会；但是开源一下子将这个战线拉长了，可能要投资，我要做好两三年之内什么都没有的准备，可能只是用户和社区增长，然后其它的慢慢再增长。

所以从这个角度来讲，就本质来看，对待开源是需要点耐心的。你如果希望刚投入马上就能赚钱，这跟做开源商业模式的规律就不那么符合了。当然，目前在硅谷和中国的实际情况，对 Product Market Fit 的预期，可能由三到五年，压缩成为两到三年。但不管怎样，你无法指望开源软件在一两年里就有很好的盈利。有时候碰巧你可能会做出一个东西得到大客户的单子，但这通常不是开源的常态。

我觉得开源的这个事情你就把它当成市场费就好，比如像刚才提到的 Devin，一个很简单的逻辑：我们今天说 Devin 出来之后，很多人都想做 Devin 的开源版。你想 Devin 它是第一个，如果你说要再做一个闭源的 Devin，就没有人会关心；但如果你说要做一个开源版的 Devin，然后你放出来，而且效果好，注意力就立刻转过去了。

所以开源是一个你获取市场的市场费，从一个商业的角度来讲就是说你要有售前以及售后。售前的话，你会投一大部分的精力、资金、人力等，在获取客户的注意力和兴趣，跟客户做 POC。开源这个事情，相当于把你的基础价值的一部分放在桌上让他去拿，这样的话你可以把它理解成一个市场费用，是要投入成本的。

针对这个问题，我其实首先想问，为什么开源在合规和数字信任上有问题？为什么闭源就没有问题？在一个闭源公司里，也是那些人，也是那些工作时段，他们为什么每天写代码的时候，需要与合规的人讨论是法律问题还是技术问题？我从来没有见过我的工程师跟我合规部门的人在讨论说我写的代码是否合规？这是不会发生的。那么负责合规的人是去审核这些代码，然后保证说我认为这个代码是合规的，所以说只是一个流程或者法务上的一个手续，并且有一个商业实体来担保它的合规性。

我认为，关于合规的挑战，对于开源和非开源都是同样存在的。我反而认为非开源软件的合规问题更多。因为开源的好处就在于社区里什么样的人都有，很多 CI/CD 可以继承开源或者商业的代码审核服务，那些理论上对合规更懂的人，也更容易加入到开源社区来参与解决一些问题。真正重要的、需要关注的点，在于开源软件通常会有一个基本的免责条款，反而给了开源的商业发行版或者云服务生存的空间。开源的商业化公司，也有合规或法务团队等相关资源，确保软件产品的使用不会有法律或合规问题。

从这个角度来看，开源的合规流程其实跟闭源的公司也没什么本质区别，因为它在商业路径闭环里面，而不在开源路径里。从全球来看，大家比较接受和认同开源免责条款的。比如之前 log4j 的事件虽说造成了很大的影响，但大家不会去责怪项目负责人，因为并非有心去植入漏洞，而仅仅是因为缺乏充足的人力维护，这在闭源软件里也常常遇到。所以开源软件并没有让合规更难，也没有更不安全。相反，因为主流的开源软件一般都有很多工程师在使用和维护，质量反而不会很差。相反地，对于很多闭源软件而言，你对安全或合规的方面的信息可能所知甚少。

我觉得最主要就是让用户觉得你这个东西有用，我们在早期觉得我们做对的一个信号，就是那时候我们的产品做了三个月、六个月以后还是非常幼稚，但是已经有用户开始问非常技术性的性能问题。就表示即使在产品不成熟的情况下，用户已经把它放到关键场景里去使用了，这就说明我们起码在解决一个正确的问题。用户有这个问题，没有选择其他产品，而在用我们的产品，这就说明我们选对了方向，后面就是不断的迭代与改进。

向量数据库（Vector DB）到现在可能已经比较红海了，但我们再去跟用户聊的时候会发现其实大家也还没有对其他竞品非常满意。你问到大家不满意的地方，就是你能操作的空间，从我们的角度讲就是 Be aware of what you get，因为整个 LLM 市场从去年才开始，所以大多数用户还在非常初级地去接触外部市场的阶段。所以他们的应用成熟度是相对较低的。你可能去参加几次技术聚会（meetup），就可以大概了解一下你的潜在用户的技术水平。我们主要是针对这样的用户去做一个对比，再去看竞争对手有哪些不足，然后去在这上面做一些操作。

这里面最典型一个是 Spark 背后的公司 Databricks，Databricks最开始的时候说，你看我是一个开源引擎 Spark ，后来逐渐说除了 Spark 这个引擎，我要来构建另一个闭源专属的引擎。如果说用户用的是 Databricks，那么用户界面，或是说使用感觉和 Spark 是一样的，但它不再开源，而且会做得更好。

这个 open standard 的模式使得今天新开源软件能够给大家带来的用户体验、Product-Market-Fit 等一系列的事情都是完全一致的，可以达到传统开源软件一样的效果。但同时又给这个背后的公司有足够的支撑，需要足够的技术能力来实现，就是说他今天具备了提升销售（upsell）的能力。

open core 相对而言是一个比较容易实现的模式，而我认为 Open standard是今天开源软件商业化更好的一个形态，为什么呢？它对这个公司的技术能力提出了更高的要求。我们想象一下采用 open standard 的公司所需要承担及具备的能力：首先它需要有一个非常好的开源的软件。这个开源软件不能比业界的软件要来的差，否则大家就觉得说你谁啊？我不用。其次，它要有一个更高的门槛，需要有非常好的私有化的版本才能够有足够的溢价。

因此，这种模式对于提供商，对开源软件公司提出了更高的要求，但同时也给用户带来了更大的价值，因为这个闭源的版本其实是更好的。所以我觉得今天 open core 的魔法逐渐被打破之后，后面开源软件的商业模式会越来越多的朝向 open standard 的模式来发展。然后说到 LLM 的话，我们现在 LeptonAI 在做的，其实正是这样一个模式：今天如果说做 LLM 推理，那么首先它的界面会是  OpenAI 自己的引擎，但它的模型是专属的，OpenAI 有一个 SDK，这个 SDK 的接口比如说像怎么样来做 chat，怎么样来做 application，是标准的。今天几乎所有的人在做推理的时候，都在采用一个 OpenAI compatible的界面。

同时 Berkeley 也推出了是一个非常不错的开源 LLM 推理引擎叫做 vLLM（Very Large Language Model）。我发现 vLLM 很有意思的一点是它目前秒杀所有的其他的各种各样的闭源的引擎。很多公司试图来构建一个闭源的 LLM推理引擎，其实都没有 vLLM 做得好，而且没有 vLLM 来的开放。实话说，LeptonAI 这一块还是比较有经验的，我们做了一个类似于 vLLM，但是我们自己做了很多的升级。比如不再用 Python 开发，而用 C + + 开发，用很多的底层的 CUDA 以及更底层的 PDX 层优化等来做一个更好的、更高效的引擎。用户在使用的时候，客户端代码都不用变，实际上是一个Open Standard，只要把调用服务的 URL 改一下就行了。

同时我们通过这些优化可以实现比原来的引擎高大约三到五倍左右的性能提升。通过这样一个方式，我们可以告诉用户说，如果你在我们的平台上用同样的 GPU deploy 起来的话，这个 GPU 加上我们的软件所带来的效益是远远超过自己搭开源的技术栈。通过这样的一个方式，我们来实现自己在整个市场上的展开。这个就是我今天对于开源软件，以及开源这样一个生态下面怎么样来做商业的想法。

刚才扬清说的传统的 open core 模式在云时代下会比较难，这一点我完全认同。可能难就难在构建好护城河，比如说跟那些云厂商比。各大云厂商，从各方面看，都有巨大优势：它本身就是一个大的流量资源，客户的流量在这里，推广的流量在这里，如果你很不幸，刚好跟这个云厂商贴在同一个赛道，你怎样去获得一个这个优势？这很困难，也是 MongoDB、Elastic、Redis 等开源厂商被逼的修改开源 License 背后的深层次原因。从另一方面，如果盯紧一个 open standard，然后聚焦你的技术和产品能力，专注在商业产品上做到业界最优，才有可能成功。

开源软件的护城河到底在哪？我认为一旦你的开源项目成为业界事实标准之后，这时候标准就是你的护城河。因为对于社区或者开源的用户而言，一旦习惯了使用，是很不喜欢去迁移的，刚才提到 Databricks 和 Spark 完全兼容，也是从这个角度去考虑的。我们现在做的下一代 data catalog 产品，也遵循同样的逻辑：我们发现大部分使用开源数据 infra 的用户还停留在几年前的开源技术栈，比如说 HMS （Hive Meta Store）。我们刚开始设计的 Data Catalog 在各方面（性能、可扩展性、引擎支持的丰富度等）都碾压它，但客户仍然对完全迁移非常犹豫，我们知道这是因为踩到了 HMS 标准的护城河，于是我们快速调整了策略，全方面支持HMS，与HMS兼容，而非追求全量替换，这个时候客户推进就轻松很多。

这种延续现成 Open Standard 来 Evolving 新一代的 Open Standard 的做法，是我们的一个重要创新：我们的策略就变成了不去追求颠覆传统 query engine的data catalog，而是在继承标准、增强开放性之后，更好去支持 data 与 LLM 的结合、以及多云的场景，为这部分新场景构建新的 Open Standard，并提供业界 State-Of-The-Art 产品。最后我们会发现，这个标准以及产品就是你的护城河，Databricks 就是一个比较好的案例。

很多开源软件公司死掉了或者是不成功，并不是死在商业模式上。其实说白了还是用户基础不够大，没有真正成为业界的事实标准，这是比较令人担心的。开源企业想以开源模式来成功，一定要把开源项目做成事实上标准，例如 Hadoop、Spark，或者是流计算里的 Flink 等，以及 AI 框架 PyTorch  等。就是在细分领域里，一定要拥有业界No.1的的用户基数。

我叫 Charles，中文名叫徐成，目前在 Snowflake工作。其实就是想呼应一下刚才讨论到的许可证的问题。刚才陶老师提到了，涛思数据更倾向于用限制性更强的许可方式，这样可以把许可证本身视作一个护城河。但如果说想走 open standard 的商业模式，也就是在最早期让新项目变成一个 open standard，需要尽可能快、尽可能多地被采用。那么这样市场需求可能更倾向于一个开放的，像Apache或者是 BSD 这样的许可证。

对这个问题，我也非常想听几位嘉宾谈一下，尤其是扬清博士。我大概一年前为「科技早知道」做访谈，其中一个重要的话题就是他对开源大语言模型的想法 ，当时候我个人的想法跟他有点不一样，我觉得因为 LLM 对 GPU 的要求这么高，OpenAI 做得好，背后是微软或者 Google，有这么多的GPU，然后开源的能有几个 GPU？相差好大数量级，所以从这个角度上来讲，可能是比较困难的。

从最近的进展来看，我是比较看好的，现在比一年前又看好一点。为什么呢？因为我觉得还是蛮惊讶，尤其是 Llama 2 当初给我的感觉就是它不支持中文，不支持这个或那个，然后过了两个礼拜，看到那么多生态体系里的那么多人在发力，就什么都支持了。我就觉得这个生态体系的重要性还是蛮大的。

然后到了年底的时候， Mistral 横空出世，我是没想到，我以为这个开源的战场已经结束了，就是 Llama 2 已经一统天下了。Mistral 的出来让我感觉到开源还是有很多盼头，最近 X.ai 的 Grok 也开源了，虽然它现在的模型可能不咋地，但是马斯克做的东西，长期来讲我觉得还是会有一点看头。我当时认为开源的那一拨人可能没有太多GPU，没有太多资源，但最近一年我觉得这一波开源比我想象中要发展得更好更快，因此我更看好开源了。

我可能还是一样看好。一个跟我的判断一样的点，是我觉得 Llama 2-70B 和 Mistral 今天基本上已经可以达到 ChatGPT 3.5 的效果，但是 ChatGPT 4 的效果还达不到。跟我之前的想法不一样的是，今天其实闭源的模型仍持续领先。举个例子，首先以开源或国产的模型为代表的一系列的追赶者，和以GPT 4 为代表的领先者之间的差距是怎么样的呢？我觉得今天追赶者已经追赶到了 GPT 3.5 的效果，但是领先者已经开始玩别的东西了。

举个最简单的例子，今天国内大家都因为Kimi 的横空出世，各个大厂都开始讲长文本（long context），大家觉得说长文本才是未来。我很明确的说不是，为什么呢？我在朋友圈也发了同样的例子，就是你可以去测试一下Kimi 或是其它号称具备长文本可以防止遗忘的模型。事实上，长文本模型还是会带来遗忘。

怎么样来解决或验证这个问题呢？你写123456789，然后你把 5 和 6 的位子调一下，然后你跟大模型说，请你给我指出来哪个数字写反了？如果你写了 1—9，中间换个数字，它能找出来；1—20，它也能找出来；1—99，开始有点晕了；1—999，基本做不出来；1—9999，我试过，目前没有任何一个模型能产生任何结果。所以你能非常明显地看到大模型的遗忘。但如果你问 GPT 4 同样的问题，它马上回复，看来是要在前面那个数组里找一找数字不对的地方，那我就先把这个东西写成一个数组，它说这个数组的顺序是正常的，然后我将数组的后一个减去前一个，看看哪个地方不对。那么 1 到 99 都能前后一致地正确。然后在某个点上，超过了它原本的文本长度限制，它说这段程序我写了个限制，说这个程序最多只能够检测，比如说 4096 个字符，当字符断掉时它会出错，但是它的整个逻辑是合理的。不像开源的追赶者说，神秘的大模型啊，请给我一个回答。

所以我觉得开源追赶者其实追赶的是上一波，我这个预测是对的。但我没有意识到的是前瞻的领导者在往前走，做的更加复杂的不只是大模型，而是在以大模型为中心的一个综合的系统。我没预料到它能走得这么快。

关于大模型开源好还是闭源好，我觉得任何一个公司或是硅谷的公司都不是非营利组织，都是需要赚钱的，所以需要找到适合自己的不同方式。Meta 做 Pytorch 对公司能间接的带来很多其他的好处。所以说如果某天它想通了，我需要闭源一些东西来达到我的商业价值，这完全有可能，大模型目前大概就在这个阶段。我认为 Mistral 是大模型开源的代表，虽然说 Llama 没有说我最好的模型不开源，但是 Llama 3 的确更好，只是暂时没有给你拿出来用。我的观点就是这些开源的厂家，他们总归是提供了一个足够好的开源版本。扬清博士在另外一个节目里讲得很好，它会有一个足够好的大模型放在那边让你玩玩，让你感兴趣。同时也会有另外一个闭源或暂时不发布的大模型，使得它的价值不只是体现在开源。这个我觉得很正常。

关于大模型未来是开源更好还是闭源发展更好，我的看法是：哪里有需求，哪里就会满足。换句话说，市场决定了哪种模式会发展得更好。闭源大模型在 ToB 端一直没有很好地解决信任问题：其实就刚才说的那个案例，我们也调研过很多客户，其实在美国大一点的企业并不是很相信第三方的大模型 provider，哪怕你是 OpenAI，这背后关键是业务的核心数据。你无法想象 Apple 愿意把 OpenAI 接入到自己的核心业务里，与核心数据共存，但 OpenAI 目前也很难支持类似于 BYOC（Bring Your Own Cloud）这样的部署模式。所以在信任问题解决前，将开源模型导入到企业内部去部署和微调这种模式的需求会非常普遍，越大的公司可能越会关心。这肯定是市场上的一个刚需，至于是基于 Llama2 还是 Mistral，或是更多后续的开源模型，我觉得会持续出来。

第二点，Facebook 的 Llama2 有开源的商业模式，Mistral 也有自己的商业模式。当前领先的闭源大模型公司目前还没找到除闭源之外的商业模式，我认为他们都在积极寻找，因为当前能盈利的大模型公司（无论开源还是闭源）还很少，市场还很早期，都在探索。也许后面有些公司意识到构建在开源模型之上，也许有助于其找到更佳的商业模式，例如构建标准来吸引强大的应用生态来挣钱，那么这些公司一样可以把类似于 GPT 4 或者 GPT 5 的能力给开源出来，为了让自己的生态标准化，这就和当年 Google 做 Android 的逻辑一样。所以我认为大模型这波的应用营收或价值能不能被放大产出非常关键，如果应用远超基础设施（大模型）的价值的话，各大玩家后续可能在大模型方面会更加地开放和激进。我相信未来AGI应用的价值，所以也更看好开源LLM。

从大模型的角度，的确现在就有多种商业模式，比如 Hugging Face 现在的模式，它做一个非常大的社区，通过咨询顾问服务来赚钱。这是一个还在验证中的模式。如果说 AI 继续是一个高专业门槛的状态，那么通过经营一个开源社区，来营造自己的名声和专业，同时给技术水平较弱的公司提供咨询顾问服务，这不失为一种模式。

大语言模型对于开源商业化的一个挑战是，今天很多的开源或闭源的大语言模型都还未解决的一个问题是，模型的生产成本很高，而售卖时间很短，这有点像月饼的生产与售卖。从今天的大模型迭代速度来看，大概六个月就会出来一个新模型，是非常卷的状态。以前我们写的模型，虽然在迭代，但它是一个增量的过程，可以往后逐步积累。但是大模型不然，基本上训练一次之后，下一次我又要再花那么多的时间重新训练。如此重复投入不积累，且时间紧迫，对所需要投入的体量和利润率都是巨大的挑战。今天还没有人能够解决这个问题。

今天早上，我看见一篇由 Nvidia 的 Jim Fan 转发的文章，大意是说可以将 AI 模型及产出杂交，即拿两个开源模型出来，不需做任何的训练，将它们不同的层次混合，就可以出现一个更好的模型。

我叫王文峰，我在给一些Meeting类软件做自然语言接口，为了让大模型可以直接跟已有的软件做交互。本质上是加强版的 function call 的一个治理平台。

我在去年投入到 AI 之前，其实也做了两年的开源。当时是做消息队列 Apache RocketMQ 的 committer。我现在感觉开源对于一些比较 hacker 的人来说，是比较纯粹的事。一旦把开源变成一门生意之后，它就更像一个早期产品在没有经过 beta 测试之前的市场推广策略。这里面也能看到一些现象，就是一些非常好的开源公司，他们随着 ABC 轮往后越走，社区对他们的重要度越来越低了。所以我觉得可能在你早期不知道明天是什么样的情况下，就先开源出来。因为如果你是面向开发者的产品，是能够吸引开发者注意力的一种方式，这和你去谷歌上砸钱，买量的传统作法，并没有太多本质上的区别。

关于护城河，因为代码放在那儿，别人想用很快就能跑起来的一种服务。现在美国的企业驱动大家去买一个商业化软件产品的核心动力是什么？可能合规是一个，或是工程复杂度很高，自己搞得砸两个工程师进去，一年下来可能就是五六十万，如果买一个已有的产品，可能一年就是十几二十万。我觉得开源产品比较影响开发者的认知。一个很典型的案例，我们在解决技术问题的时候，可能会倾向找一些实践。最佳实践就是，一旦很多人说这个东西大家都在用，可能我就跟随着用起来。

关于大模型的商业化问题。我们现在往前看这些云的软件，我们会发现其实除了最下面的数据库以外，上面长出来非常多工具链或是中间件产品。在大模型的领域里还有哪些潜在的工具链是还没有出来？那些工具链里面的一些东西比较适合以开源的方式去做的，比如说 function call 或 evaluation 还没有这个机会？展望未来，整个 LLM 的生态里，除了大模型，以及整个中间层，让很多公司内部做大模型落地的时候很困难，是不是因为中间确实少了很多工具来提高它的效率，里面有哪些工作量可以被抽象出来？

我们现在就是在考虑是把需求做成产品，还是把一部分需求推回给用户。基本上我们尽量把需求通用化，让 10 个用户用一样的解决方案，如果可行，我们才会觉得值得做。而 evaluation 方面，可能每个公司的 evaluation 会非常不同，所以你做的事情更像是咨询顾问的工作而非产品。我们也有朋友去做 evaluation 工具类产品的，但后来基本都退了，因为没有办法找到一款单一目标的产品来做这件事。

可观测性（Observability）倒是非常容易去设计成一个产品。从另外一个角度讲，作为你的用户，他的工程团队有多少人愿意自己去构建一个非常无聊的任务，还是干脆直接去买一个产品？YC (Y Combinator) 有一个说法，你卖的是止痛药，或者你卖的是，比如说让客户得到晋升，或者得到了情感上的充实。所以你要么让客户变得很开心，要么解决客户一个非常痛苦的困难。这两种情况下，客户愿意去花钱来买你的产品，然后自己可以去做更有意思的工作。

刚才我在想怎么描述我自己的感觉，就是我认为今天肯定有空间是留给类似于像 Apache RocketMQ 这样的中间件的。就是 AI 也需要各种各样的连结，而算法已经比较稳定的建立了。

大家经常说 LLMOps，像 LangChain、LlamaIndex，这些东西我自己还没有很好理解。今天大家在 AI 方面的实验还非常开放，在做各种各样的尝试，还没有一个标准的范式出来。我听到好几次潜在客户跟我们说，他们先试一试 LangChain 或 LlamaIndex，之后就开始自定义，因为发现某个范式反而变成了自己的桎梏，就直接扔了。这不就是一个discretionary（酌情）的 prompt，索性自己维护一个变量就行了，这也是一个模式。

最终，我觉得计算的范式出来之后，中间件的市场肯定会在，我们也看见了一些，比如一个叫做unstructured.io，做从非结构化数据到结构化数据的 ETL。这些通用模式逐渐出现了，可能后面有更多标准化的创新。所以我特别同意刚才说的，怎么找到那些能够有 10 个或以上的用户通用的模式，把它变成新的开源项目，或是一个起点。

说实话这个事我也不知道，尤其是因为代码比较容易追踪，而数据则更难追踪，这个地方甚至有一个更加根本的问题，我觉得最终只能够用最高法院的判定来解决，就是到底接入和使用这些数据来训练你的大语言模型是否属于合理使用（fair use）。之前谷歌也被问到过这个问题，有人起诉谷歌说你的搜索引擎里，为何可以展现我拥有版权的内容？最后判定说这是一个索引网页，让用户更加容易取得所定义的合理使用。

今天大语言模型显然没有 Google 那么有社会公益性质，它带有更强的商业性质，这些训练数据是不是被合理使用？我不知道。甚至怎么样来定义这些数据被使用？OpenAI 说我没用，前段时间OpenAI 的 CTO 说 Sora 的训练 no one is able to prove or disprove anything。在这种情况下面：第一，怎么样来定义合理使用，第二怎么样来识别，以及怎么样来归功还是惩罚这种合理或不合理的使用？这个事情其实目前我们谁都不知道。

今天如果说开源一个模型的话，它是给你最终的结果。这个像传统的软件里面，给你一个编译完的二进制编码。传统上认为这不叫开源，你说数据在哪？训练的流程在哪？训练的参数在哪？你训练的时候什么时候要调什么东西的配方在哪？也就是让你能够重新烹调一遍，这个理论上才算是完全的开源。所以大语言模型算不算开源？目前它更像是一个开放二进制。

还有一些其它实际的问题，比如我们知道 Google 的模型是通过多次微调出来的，经过了三个月之后，整个训练过程已经不可考，就是今天前面谁去训练了这类数据，后面经过更换，又训练一些什么东西。即使我们想追溯这件事的来龙去脉，它也已经消失在时间的长河中了。整个模型，谁该负责什么，研究人员在记录所发生的事情方面非常混乱。这其实就是一件很棘手的事情。

换句话说这个模型和数据集之间的关联或者说血缘关系，其实在当前很多模型公司的业务实践里，是没有办法追踪的。这方面的治理工作刚刚开始，我认为这可能是一个新的机会。可以借鉴数据领域当中数据血缘的做法，毕竟模型和数据是同一枚硬币的两面。