AI大模型-AI驱动流量增长

构建大模型一年多，我们总结了关于 LLM 应用的运营经验

作者丨 Eugene Yan et al. 译者丨明知山策划丨褚杏娟常有人错误地将这样一句话归因于一些领导者，尽管它可能完全是虚构的：“外行谈论战略和战术，内行关注运营。”从战术的角度看，我们面对的是一系列独特的问题，从运营角度，我们看到的是需要解决的组织功能失调模式。在战略视角看到的是机会，在运营视角看到的是需要应对的挑战。在本系列文章的第一部分，我们介绍了 LLM 的战术性操作。接下来，我们将拓宽视野，深入探讨长期的战略规划。在这一部分，我们将讨论构建 LLM 应用程序的运营层面，这些应用程序是战略与战术的桥梁，将理论与实际应用紧密结合。在运营 LLM 应用程序过程中，我们遇到了一些似曾相识的问题，这些问题在传统软件系统的运营中也常常出现，不同的是它们也带来了一些新的挑战，使得探索过程充满了趣味。此外，运营 LLM 应用程序还带来了一些全新的问题。我们将这些问题及其答案归纳为四个部分：数据、模型、产品和人。对于数据，我们将探讨这几个问题：如何以及多久需要重新审视一次 LLM 的输入和输出？如何测量并有效减少测试环境与生产环境之间的偏差？对于模型，我们将探讨这几个问题：如何将语言模型集成到现有的技术栈中？如何看待模型的版本控制以及如何在不同模型和版本之间进行平滑迁移？对于产品，我们将探讨这几个问题：设计应该在何时介入应用程序的开发过程，为什么要“尽早介入”？如何设计能够充分吸纳人类反馈的用户体验？在面对相互冲突的需求时如何安排优先级？如何校准产品风险？最后，对于人，我们将探讨这几个问题：选择哪些人才来构建成功的 LLM 应用程序，以及何时招募他们？如何培养正确的实验性文化？如何利用现有的 LLM 应用程序来辅助开发自己的 LLM 解决方案？哪一个更关键：流程还是工具？运营：LLM 应用程序的构建和开发团队数据正如精选的食材能够成就一道佳肴，高质量的输入数据同样对机器学习系统的表现起着决定性作用。此外，系统的输出是评估其是否正常工作的唯一方式。所有人都紧密关注数据，他们每周都会花几个小时细致地分析输入和输出，以便更好地理解数据分布：模式、边缘情况以及模型的局限性。检查开发与生产偏差在传统机器学习流程中存在的一个普遍问题是训练与服务之间的偏差。这种情况通常发生在模型训练时使用的数据与模型在实际应用中遇到的数据不一致时。尽管我们可以无需训练或微调就能够使用 LLM，从而避免了训练集的问题，但开发与生产环境之间的数据偏差问题依然存在。关键在于，在开发阶段测试系统时所用的数据应与系统在生产环境中实际面对的数据相一致。如果不是这样的话，我们可能会发现生产环境中的模型准确性会受影响。 LLM 开发与生产偏差可以分为两种类型：结构性偏差和基于内容的偏差。结构性偏差包括格式不一致，比如 JSON 字典与 JSON 列表之间的差异、不一致的大小写以及错误，如错别字或不完整的句子片段。这些错误可能导致模型性能不可预测，因为不同的 LLM 是基于特定的数据格式训练的，而提示词对微小变化都非常敏感。基于内容的偏差（或“语义”偏差）指的是数据的含义或上下文的差异。正如传统的机器学习一样，对 LLM 的输入和输出进行定期的偏差检测是非常有必要的。输入和输出的长度或特定格式要求（例如，JSON 或 XML）等指标是跟踪变化最直接的方式。对于更“高级”的漂移检测，可以采用更高级的方法，如聚类输入 / 输出对的嵌入向量可用于检测语义漂移：如果用户讨论的主题发生变化，这可能表明他们正在探索模型以前没有接触过的领域。在测试变更时，例如提示词工程，确保保留数据集是最新的，并且能够反映用户交互的最新类型。例如，如果错别字在生产环境的输入中很常见，那么它们也应该出现在保留数据中。除了进行数值偏差检查之外，对输出进行定性评估也很有用的。定期检查模型输出——俗称“氛围检查”——可以确保结果符合预期并满足用户需求。最后，将非确定性纳入偏差检查中——通过多次运行测试数据集中的每个输入并分析所有输出，可以增加捕捉那些可能仅偶尔发生异常情况的可能性。每天检查 LLM 的输入和输出样本 LLM 是动态且持续进化的。尽管它们具有令人印象深刻的零样本学习能力，并且经常能够生成令人满意的输出，但它们的失败模式却非常难以预测。对于自定义任务，定期审查数据样本有助于培养对 LLM 性能的直观理解。生产环境的输入输出对是 LLM 应用程序的“现场证据”，它们不会被替换。最近的研究表明，开发者对什么构成“好”和“坏”输出的看法会随着他们与更多数据的交互而发生变化（即所谓的标准漂移）。虽然开发者可以预先设定一些标准来评估 LLM 输出，但这些预定义的标准通常不够全面。例如，在开发过程中，我们可能会更新提示词，以增加获得良好响应的概率，并降低获得不良响应的概率。这种评估、重新评估和标准更新的迭代过程是必不可少的，因为在没有直接观察输出的情况下，很难预测 LLM 的行为或人类的偏好。为了有效地管理大型语言模型，我们需要记录 LLM 的输入和输出。通过每天检查这些日志样本，我们能够及时识别并适应新的模式或故障模式。在发现新问题时，我们可以立即编写断言或制定评估策略来应对这些问题。同样，对故障模式定义的更新都应实时反映在评估标准中。这些“氛围检查”可以帮助我们捕捉到不良输出的信号，而通过编写代码和断言，我们能够将这些检查操作化，使之成为可执行的过程。最后，这种态度需要在团队中得到普及，例如通过在值班轮换中加入对输入和输出的审查或注释环节。调用模型在使用 LLM API 时，我们确实可以依靠少数几家技术供应商的智能成果。虽然这为我们提供了便利，但同时也带来了一些权衡，包括性能、延迟、吞吐量和成本等方面。此外，随着更新、更好的模型（在过去一年中几乎每个月都会有新模型发布）的发布，我们需要随时准备好更新我们的产品，以弃用旧模型并迁移到新模型。在这一章节，我们将分享在使用这些我们不能完全控制的技术时的经验，特别是关于如何管理那些我们无法自托管的模型。生成结构化输出，简化下游集成对于大多数现实世界的场景，LLM 的输出需要通过机器可读的格式提供给下游应用程序。例如，Rechat，一个房地产 CRM 系统，需要结构化的响应来在前端显示小部件。同样，Boba，一个用于生成产品策略想法的工具，需要输出包含标题、摘要、可信度得分和时间范围字段的结构化信息。LinkedIn 通过限制 LLM 生成 YAML 格式的数据，用于决定使用哪种”技能“，并提供调用这些技能所需的参数。这种应用模式体现了 Postel 定律的极致：在接收时宽容（接受任意自然语言），在发送时保守（输出类型化、机器可读的对象）。因此，我们期望这种方法具有很高的稳定性和可靠性。目前，Instructor 和 Outlines 是从 LLM 中提取结构化输出的实际标准。如果你在使用 LLM API（比如 Anthropic 或 OpenAI），请优先选择 Instructor；而如果你在使用自托管的模型（例如 Hugging Face），则推荐使用 Outlines。为不同模型修改提示词是一种痛苦有时，我们精心编写的提示词在一种模型上表现出色，但在另一种模型上却表现平平。这种情况可能在我们更换不同模型供应商时发生，也可能出现在同一模型的不同版本升级过程中。例如，Voiceflow 在从 gpt-3.5-turbo-0301 迁移到 gpt-3.5-turbo-1106 时，他们的意图分类任务性能下降了 10%。（幸运的是，他们进行了评估！）同样，GoDaddy 注意到了一个积极的变化，升级到 1106 版本缩小了 gpt-3.5-turbo 和 gpt-4 之间的性能差距。（或者，如果你是一个乐观的人，可能会对 gpt-4 的领先优势在这次升级中有所减少感到失望。）因此，如果我们不得不在模型之间迁移提示词，预计这将是一个比简单更换 API 端点更耗时的过程。不要想当然地认为使用相同的提示词能够得到相似或更好的结果。此外，拥有一个可靠的自动化评估系统，可以在迁移前后有效地衡量任务性能，并显著减少所需的手动验证工作。版本控制和固定你的模型在机器学习管道中，“改变一点，影响全局”是一个普遍现象。这一点在我们依赖自己未参与训练的组件，例如大型语言模型（LLM）时，显得尤为突出，因为这些模型可能会在不被我们察觉的情况下发生变化。幸运的是，许多模型供应商提供“锁定”特定模型版本（例如，gpt-4-turbo-1106）的选项。这样，我们可以使用特定版本的模型权重，确保它们保持不变。在生产环境中锁定模型版本有助于防止模型行为发生意外变化，从而减少因模型更新可能导致的问题（例如过于冗长的输出或其他不可预见的故障模式）。此外，可以考虑维护一个影子管道，这个管道镜像了生成环境的设置，但使用的是最新的模型版本。这为实验和测试新版本提供了一个安全的环境。一旦确认这些新模型的输出在稳定性和质量上符合标准，就可以自信地升级生产环境中的模型版本。选择能够完成任务的最小模型在开发新应用程序时，使用最强大的模型往往具有极大的吸引力。然而，一旦我们确认了技术可行性，就很有必要尝试一下使用更小的模型是否能够产生同样优质的结果。小模型的优势是较低的延迟和成本。虽然在性能上可能略显逊色，但通过诸如思维链、n-shot 提示词和上下文学习等先进技术的应用，它们完全有可能超越自身的限制。除了调用 LLM API，针对特定任务进行微调也能够显著提升性能。综合考虑，一个精心设计的工作流，即使使用较小的模型，通常也能匹敌甚至超越单个大型模型的输出质量，同时还具备更快的处理速度和更低的成本。例如，这个推文分享了 Haiku 结合 10-shot 提示词的表现优于零样本的 Opus 和 GPT-4。从长远来看，我们期望看到更多流程工程的案例，使用较小的模型实现输出质量、响应时间和成本之间的最佳平衡。作为另一个典型案例，我们来看一下那些看似简单的分类任务。轻量级的 DistilBERT（6700 万参数）模型居然是一个出人意料的强大基线。在开源数据上进行微调后，拥有 4 亿参数的 DistilBART 更是一个不错的选择——它在识别幻觉方面的 ROC-AUC 值达到了 0.84，在延迟和成本方面增加不到 5%，超越了大多数大型语言模型。重点是，我们不要轻视那些模较小的模型。尽管人们往往倾向于对各种问题都应用庞大的模型，但通过一些创新思维和实验探索，我们常常能够发现更为高效的解决方案。产品虽然新技术为我们带来了新的可能性，但构建卓越产品的核心原则始终不变。因此，即使是在第一次面临新挑战时，我们也无需在产品设计方面重新发明轮子。将我们的 LLM 应用程序开发建立在坚实的产品理念之上，这将使我们能够为用户带来真正的价值。。及早并频繁地进行设计设计师的参与有助于推动你深入思考如何构建和向用户展示产品。我们有时会将设计师简单定义为美化事物的人。然而，除了用户界面之外，他们还会全面思考如何改进用户体验，甚至是打破现有的规则和范式。设计师擅长将用户需求转化为各种各样的形式。这些形式有些更容易实现，而有些则为 AI 技术提供了更多或更少的施展空间。与许多其他产品一样，构建 AI 产品应该以要完成的任务为中心，而不是驱动这些任务的技术。问问自己：“用户期望这个产品为他们完成哪些任务？这些任务是聊天机器人擅长的吗？能够使用自动完成功能？也许可以尝试一些不同的方案！”审视现有的设计模式，思考它们与要完成的任务之间的联系。这些是设计师为团队能力带来的宝贵贡献。以 HITL 为导向设计用户体验一种提升注释质量的方式是将 Human-in-the-Loop（HITL）融入到用户体验（UX）设计中。通过让用户轻松地提供反馈和更正，我们不仅能即时优化输出，还能收集有洞察力的数据来改进我们的模型。设想一个电子商务平台，用户需要上传并分类他们的商品。我们可以从多个角度来设计用户体验：用户手动选择产品类别；LLM 定期检查新产品并在后端更正分类错误。用户不选择产品类别；LLM 定期在后端对产品进行分类（可能存在错误）。 LLM 提供实时产品类别建议，用户可以根据自己的判断进行验证和更新。虽然这三种方法都利用了 LLM，但它们提供了非常不同的 UX。第一种方法将初始责任放在用户身上，并将 LLM 作为后续的辅助。第二种方法减少了用户的负担，但不提供透明度或控制权。第三种方法找到了二者之间的平衡点。LLM 提前建议类别，减少了用户的认知负担，他们无需深入了解复杂的分类体系。同时，用户可以审查和修改这些建议，他们对如何分类产品有最终的决定权，将控制权牢牢掌握在手中。作为一个额外的好处，第三种方法为模型改进创建了一个自然反馈循环。好的建议会被接受（正反馈标签），不好的建议会被更新（负反馈标签转成正反馈标签）。这种建议、用户验证和数据收集的模式在多个应用领域中都得到了广泛应用：编码助手：用户可以接受建议（强烈正反馈）、接受并调整建议（正反馈）或忽略建议（负反馈）。 Midjourney：用户可以选择放大并下载图像（强烈正反馈）、修改图像（正反馈）或生成一组新图像（负反馈）。聊天机器人：用户可以对响应点赞（正反馈）或不点赞（负反馈），如果响应真的很差，选择重新生成响应（强烈负反馈）。反馈可以是显式或隐式的。显式反馈是用户对产品提出的意见或评价，隐式反馈是我们需要从用户交互中捕捉的信息，无需用户有意提供。编码助手和 Midjourney 是隐式反馈的例子，而点赞和不点赞是显式反馈。如果我们能够像编码助手和 Midjourney 那样设计 UX，就可以收集到大量的隐式反馈来改进我们的产品和模型。调整需求层次的优先级在准备将演示转化为实际应用时，我们需要仔细考虑以下几个关键要素：可靠性：确保 99.9% 的正常运行时间，同时遵循结构化输出标准；无害性：避免生成攻击性、NSFW 或其他有害的内容；事实一致性：忠实于提供的上下文，不虚构信息；实用性：与用户的需求和请求相关；可扩展性：延迟 SLA，支持高吞吐量；成本效益：需要考虑预算限制；其他：安全性、隐私保护、公平性、GDPR 合规性、DMA 合规性等。如果我们试图同时解决所有这些要求，我们将永远无法完成产品交付。因此，我们必须进行优先级排序，并且要果断。这意味着我们要清楚哪些是没有商量余地的（例如，可靠性、无害性），没有这些我们的产品就是不可行的。关键在于识别出最基本的产品功能。我们必须接受第一个版本不会完美的事实，并通过不断迭代来改进。根据用例校准风险承受能力在选择语言模型及其审查标准时，我们需要根据应用场景和目标受众来做出判断。对于那些提供医疗或财务咨询的聊天机器人，我们必须设定极高的安全和准确性标准。因为任何错误或不当的输出都可能造成严重的后果，并且会严重损害用户对我们的信任。然而，对于不那么关键的应用，比如推荐系统，或者那些仅供内部使用的应用程序，如内容分类或摘要，过分严格的要求可能会拖慢开发进度，却不会为提升价值带来太大帮助。这与最近发布的 a16z 报告中的观点相吻合，许多公司在内部 LLM 应用方面比外部应用进展得更快。通过在内部生产力工具中引入 AI，组织可以在更加受控的环境中实现价值，同时学习如何有效地管理风险。然后，随着他们信心的增强，可以逐步扩展到面向客户的应用场景。团队与角色定义工作职能不是件容易的事，而在这个新兴领域编写工作描述比其他领域更具挑战性。我们决定不再使用交叉工作职能的文氏图或工作描述的建议。相反，我们将引入一个新的职位——AI 工程师——并探讨其在组织中的位置。同时，我们也将讨论团队其他成员的角色以及如何合理分配责任，这至关重要。专注于流程，而不是工具面对新兴的范式，例如大型语言模型，软件工程师们往往更倾向于采用各种工具。这种偏好有时会导致我们忽视了这些工具本应解决的问题和优化的流程。结果，许多工程师不得不应对由此产生的偶然的复杂性，对团队的长期生产力构成了负面影响。例如，这篇文章讨论了某些工具如何为大型语言模型自动生成提示词。文章认为（在我看来是正确的），那些在没有先理解问题解决方法或流程的情况下使用这些工具的工程师最终会累积不必要的技术债务。除了偶然的复杂性，许多工具还常常存在规格不足的问题。以不断壮大的 LLM 评估工具行业为例，它们提供所谓的“即插即用”的 LLM 评估服务，涵盖毒性、简洁性、语调等通用评估指标。我们发现许多团队在没有深入分析其领域特有的失败模式的情况下，就盲目采纳了这些工具。与此形成鲜明对比的是 EvalGen，它通过深度参与用户的每一个环节——从定义标准到标注数据，再到评估检查——引导用户构建适合特定领域的评估体系。 Shankar, S. 等人（2024）“谁来验证验证器？将 LLM 辅助评估 LLM 输出与人类偏好对齐”。来源：https://arxiv.org/abs/2404.12272 EvalGen 引导用户通过遵循最佳实践来制定 LLM 评估标准，即：定义特定领域的测试（通过提示词自动引导）。它们可以是带有代码的断言，或者是采用“LLM 即评委”的形式。强调将测试与人类判断对齐的重要性，使用户能够验证测试是否确实捕捉到了既定的标准。随着系统（如提示词内容等）的变化不断迭代和优化测试标准。 EvalGen 为开发人员提供了评估构建过程的框架性理解，而不是将他们限制在特定工具的使用上。我们发现，一旦 AI 工程师获得了这种宏观视角，他们往往会选择采用更简洁的工具，或者根据自己的需求自行开发解决方案。 LLM 的组成部分远不止提示词编写和评估，其复杂性无法在此一一列举。关键在于 AI 工程师在采用工具之前要深入理解其背后的流程和原理。持续地实验机器学习产品与实验密切相关。不仅涉及 A/B 测试、随机对照试验，还包括频繁尝试修改系统的最小组件并进行离线评估。人们热衷于评估的真正原因并非仅仅为了可靠性和信心——而是为了让实验成为可能。你的评估越精确，就能越迅速地进行实验，进而更快地发现系统的最佳配置。尝试采用不同的方法解决同一个问题是一种很常见的做法，因为现在的实验成本很低。收集数据和训练模型的高昂成本已经得到有效控制——提示词工程的成本仅略高于人力投入。确保你的团队成员都掌握了提示词工程的基础知识。这不仅能激发他们进行实验的热情，还能促进组织内部不同观点的交流与碰撞。此外，实验不仅仅是为了探索，而是要学会利用它们。如果你手头有一个新的任务，可以考虑让团队的其他成员从不同的视角来处理它。尝试寻找更高效的方法，探索如思维链或 few-shot 提示词等技术，以提高工作质量。不要让工具限制了你的实验；如果是这样，那就重新构建它们，或者购买新的工具。最后，在产品或项目规划阶段，务必留出足够的时间来构建评估机制并进行多项实验。在考虑工程产品的规格时，为评估过程设定明确的标准。在制定路线图时，不要低估了实验所需的时间。要预见到在生产交付之前，可能需要进行多轮的开发和评估迭代。让每个人都能使用新的 AI 技术随着生成式 AI 采用率的增加，我们希望整个团队——不仅仅是专家——都能理解并自信地使用这项新技术。没有比亲自实践更好的方式去培养对大型语言模型工作原理的直观理解了，比如它们的响应延迟、故障模式和用户体验。LLM 相对容易使用：你无需编码技能就可以为流程管道提升性能，每个人都可以通过提示词工程和评估做出实质性的贡献。教育是关键环节，可以从提示词工程的基础开始，如利用 n-shot 和思维链等技术，引导模型生成期望的输出。拥有这方面知识的人还可以教授更技术性的内容，例如大型语言模型本质上是自回归的。换句话说，虽然输入可以并行处理，但输出是顺序的。因此，生成延迟更多地取决于输出的长度而非输入的长度——这是在设计用户体验和设定性能预期时需要考虑的一个关键因素。我们还可以提供更多实践和探索的机会，比如举办一次黑客马拉松。虽然让整个团队投入数日时间在探索性项目上看起来成本较高，但最终的成果可能会超出你的预期。我们见证了一个团队通过黑客马拉松，在短短一年内就实现了他们原本计划三年完成的路线图。另一个团队则通过黑客马拉松，引领了一场用户体验的范式转变，这种转变现在因为大型语言模型的加入而成为可能。不要掉入“AI 工程就是一切”的陷阱随着新职位名称的出现，人们往往容易过分夸大这些角色的能力。这通常会导致在实际工作职责变得逐渐明确时，人们不得不去做一些痛苦的调整。新入行的人和负责招聘的经理可能会夸大声明或抱有不切实际的期望。在过去的十年里，这类显著的例子包括：数据科学家：“在统计学方面比任何软件工程师都强，在软件工程方面比任何统计学家都强的人” 机器学习工程师（MLE）：以软件工程为中心的机器学习视角最初，许多人认为数据科学家单枪匹马就能驾驭数据驱动的项目。然而，现实情况已经清晰地表明，为了有效地开发和部署数据产品，数据科学家必须与软件工程师和数据工程师紧密合作。这种误解在 AI 工程师这一新兴角色上再次出现，一些团队误以为 AI 工程师就是他们需要的一切。实际上，构建机器学习或 AI 产品需要一个由多种专业角色组成的团队。我们与十多家公司就 AI 产品进行了深入咨询，发现他们普遍都陷入了认为“AI 工程就是一切”的陷阱。这种认知导致产品往往难以越过演示阶段，因为公司忽视了构建产品所涉及的关键方面。例如，评估和度量对于将产品从单一的领域检查阶段扩展到广泛应用阶段来说至关重要。有效的评估能力与机器学习工程师通常所具备的优势相辅相成——一个完全由 AI 工程师组成的团队可能缺乏这些技能。Hamel Husain 在他最近的研究中强调了这些技能的重要性，包括监测数据漂移和制定针对特定领域的评估标准。以下是在构建 AI 产品的过程中你需要的不同类型角色，以及他们在项目各个阶段大致的参与时机：首先，专注于构建产品。这个阶段可能涉及 AI 工程师，但并非必须。AI 工程师在快速原型设计和迭代产品方面具有显著的价值（用户体验、数据处理管道等）。随后，通过系统化地收集和分析数据，为产品打下坚实的基础。根据数据的性质和体量，你可能需要平台工程师或数据工程师。你还需要建立查询和分析数据的系统，以便快速定位问题。最后，你将致力于优化 AI 系统。这并不一定涉及训练模型，包括设计评估指标、构建评估系统、执行实验、优化 RAG 检索、调试随机性问题等。机器学习工程师非常擅长这些工作（尽管 AI 工程师也可以通过学习掌握这些技能）。但如果你没有完成前面的基础步骤，招聘机器学习工程师可能并不明智。除此之外，你始终需要一个领域专家。在小型企业，这通常是创始团队的成员；而在大型企业，产品经理也可以担任这一角色。角色的介入时机至关重要。在不恰当的时间（例如，过早让机器学习工程师介入）招聘人员或介入顺序不对，不仅浪费时间和金钱，还会导致频繁的人员更替。此外，在前面两个阶段定期与机器学习工程师沟通（但不全职让他们介入）将有助于公司为未来的成功打下坚实的基础。原文链接： https://www.oreilly.com/radar/what-we-learned-from-a-year-of-building-with-llms-part-ii/ 声明：本文由 InfoQ 翻译，未经许可禁止转载。内容推荐在这个智能时代，AI 技术如潮水般涌入千行百业，深度重塑生产与生活方式。大模型技术引领创新，精准提升行业效率，从教育个性化教学到零售精准营销，从通信稳定高效到金融智能风控，AI 无处不在。它不仅是技术革新的先锋，更是社会经济发展的强大驱动力。在 AI 的赋能下，我们正迈向一个更加智能、便捷、高效的新未来，体验前所未有的生活变革与行业飞跃。今日荐文两天内，Meta 和 Mistral 两款主流大模型打擂台！已经不仅卷性能了，谁更便宜就用谁？ Llama 3.1 源模型泄露背后：失手的 GitHub，破碎的 Meta，好在最小参数都能打脸GPT-4o！ Claude Sonnet 3.5 口碑爆棚！10 倍速开发，“2 个月内用 Rust 从零构建完一款产品” 没投简历却被陌生HR随机辱骂，HR道歉称压力大；OPPO 回应“大量裁撤华为系员工”；传百度新任公关一号位或为蒋昕捷｜AI 周报开源独角兽 GitLab 走上“卖身”路！前工程师拆台：赚钱的业务不好好运营，开发了一堆没用的功能

大模型时代的操作系统：融合 Rust 和大模型，vivo 打造 AI 操作系统

采访嘉宾｜袁东每次技术革命，无论是个人电脑、互联网还是移动设备，总是从硬件开始，然后演化到软件层。而操作系统是计算机系统的核心，没有它，计算机就只是一堆硬件，无法运行任何程序。微软 CEO 萨蒂亚·纳德拉曾将生成式 AI 带来的转变比作从蒸汽机到电力的转变。“你不能简单地把电动机放在蒸汽机的位置，而其他一切都保持不变，你必须重新布线整个工厂。”这一两年，“围绕大模型重建操作系统”一直是一个热门话题，产生了各种将大模型作为操作系统或引入操作系统的想法，进而又出现了各种场景下的 AI OS。不管是手机还是全新的 AI 终端，操作系统都是贯穿其中的灵魂，如今手机厂商的“AI OS”角逐也正在上演。苹果在 WWDC 上宣布了“Apple Intelligence”，为 iPhone、Mac 等设备提供一系列 AI 功能。随着苹果正式进军“AI 战场”，生成式能力加持的 AI 手机显然有加速发展的趋势。实际上，国内 AI 手机起风更早，vivo 去年发布了自研 AI 大模型矩阵“蓝心大模型”，以及面向通用人工智能时代自主研发的蓝河操作系统 BlueOS。BlueOS 的系统架构选择了用 Rust 语言编写，减少安全漏洞，并引入大模型的能力，支持复杂的意图识别和声音、图片、手势等多模态交互方式，还并为开发者提供了自动编码等应用开发新范式。大模型会给操作系统带来什么变化？7 月 27 日，vivo 在北京举办了首场蓝河操作系统技术沙龙，我们在会后也邀请到了 vivo 技术规划专家袁东参加 InfoQ 的“极客有约”直播，为我们详细解读了蓝河操作系统的设计理念和技术细节，以下是采访整理。大模型时代，我们到底需要一个什么样的操作系统 InfoQ：最近一两年，我们有了各种关于大模型操作系统的说法，举例来说，传统意义上的 OS、AI-powerd OS，还有 Andrej Karpathy 提出的 AIOS/LLM OS 等各种定义。与传统操作系统相比， AI-powerd OS 和 AIOS 各呈现出哪些新的架构特征？蓝河操作系统比较接近哪一种？袁东：从最近大模型代表的 GenAI 的火爆，到最近 WWDC 和 Google IO 对公众越来越多的披露，从业者意识到，每天我们朝夕相处的操作系统在这个时代将会有非常大的革新。目前业界对 AI OS 或者 AI-powered OS 没有明确的概念或者界限，但可以确定的是，技术架构层面，端侧模型原生入驻操作系统提供系统级别的智能能力，这将在人机交互、技术架构和生态方面会有很大影响。在技术架构方面，端侧模型原生入驻操作系统，提供系统级别的智能生成能力。蓝河操作系统原生集成蓝心大模型，意味着 App 可以基于大模型进行内容构建，后续随着 AI 系统的进一步强化，除了架构的革新外，会有更多的符合 AI 时代的特性推出。例如，普通人可以利用系统创造出符合自己风格的内容。 InfoQ：大模型热了后，“围绕大模型重建操作系统”就成了一个热门的话题，可能大家一开始希望大模型更具颠覆性，希望能给底层也带来革命。这让我想起了不久前 Rabbit R1 翻车事件，我认为其中一个关键原因是它的宣传策略。Rabbit R1 宣称其操作系统与之前的安卓系统不同，它是一个全新的系统，能够运行大模型。这种宣传可能给消费者带来了误解或过高的期望，因为实际上它可能并没有达到所宣称的创新水平。那么您认为大模型时代，我们是否有必要重建一个跟安卓不同的操作系统？另外，您认为大模型到来后对操作系统的发展产生了什么样的影响？袁东：Rabbit R1、Ai pin 等在我看来是行业对于 AI 时代大胆的尝试，希望探索出更适合 AI 时代的消费电子产品。目前来看，手机依然是最重要，AI 受益最多的个人产品之一。操作系统在 AI 时代需要明显的升级，借助 AI 智慧化提升用户体验。我认为操作系统会因为大模型在人机交互、架构、生态，三个方面会有很大影响与改变。大模型产的智能涌现，类比移动互联网之于手机。操作系统会围绕着交互范式、生态范式的改变，相应的做出很多调整。例如，为了打造个性化的系统，需要尽可能获取用户关乎自身的数据，相应的会有系统级别的方式（比如通过系统 App，用户操作）来获取这些私人数据，同时基于这些来给出更贴近用户的行动建议。交互范式的变化，意味着服务类 App-Agent 之间的关系与形态慢慢发生变化。Agent 成为一个系统级别的超级 App，随之而来的是生态发生变化。架构方面，AI 大模型入驻操作系统，其提供了智能的能力，除了自身生成的内容要保证安全，同时我们需要在操作系统中原生地集成安全检测机制，以防止用户遭受不必要的损失。 InfoQ：在面向大模型的发展过程中，操作系统面临的挑战和机遇是什么？袁东：从用户角度来看，需要考虑如何设计好交互入口（智能助手）：即交互方式，多模态智能化交互；用户的意图理解，用户主动发起 – 系统主动发起对用户意图的理解；用户需求拆分后的任务分发，系统级 App 的 AI 升级到第三方 App 都可以被智能调度。从开发者生态角度来看，需要考虑如何建造一个共赢的 AI 时代的开发者生态。AI 时代新的 AI 生态架构策略，即围绕智能助手展开的智能生态：三方程序向系统级别的智能助手提供 App 的能力描述、App 的应用数据；这类改变类比于 2008 年，App Store 的提出，再次改变了 App 的分发策略，与商业策略。从架构角度来看：软件系统架构：持续迭代 AI 系统的设计硬件架构：个人觉得不同时代的硬件也会有相应的革新，图形的兴盛带动了 GPU 的产生，神经网络的计算如果越来越重要 NPU 的发展也会有很大需求。从原生 AI 硬件角度来看：人类的五感——听觉、视觉、味觉、触觉和嗅觉——是我们与自然界交互的主要方式。在这些感官中，视觉和听觉是获取信息的主要途径。随着 AI 技术的发展，未来可能会出现原生的 AI 硬件，这些硬件将根据新的交互逻辑和形态进行设计。 InfoQ：刚您提到了交互方式的改变，之前也有一个“No App”的概念，但有人认为“No App”是不现实的，对此老师您对此有什么看法？袁东：我个人的观点是，从满足用户需求来看，用户更多可能希望与系统级别的智能助手交互来满足譬如点外卖、打车等服务类需求。这对于 App – Agent 助手来说，清晰的调用架构 +App 直达服务可能是未来用户更期望的组合形态。但是，对于像游戏、视频和企业级办公这样的应用，它们各自有着特殊的需求，比如对隐私的严格保护、对高性能显卡的依赖，或是对特定功能的高度专业化。这些应用很可能会继续以独立的形式存在，但同时，它们与智能助手之间的互动也将成为增强用户体验的关键。通过智能助手与这些应用的智能联动，我们能够为用户提供一种更加完整和连贯的操作体验。而这种整合不仅对用户来说是一个体验的增强，对于整个技术生态系统和系统发展同样积极的影响。 InfoQ：谷歌和苹果开发者大会也提到了它们已经打通了一些 App，这个难度主要在哪里？袁东：这个问题的核心在于 Agent 与应用程序之间的协同。Agent 需要与两类应用程序进行交互：一类是自有生态的应用程序，另一类是第三方应用程序。自有生态的应用程序可能包括办公、系统管理、用户行程安排和出行服务等。而第三方应用程序，尤其是长尾应用，在移动互联网时代积累了大量关键用户数据，这些数据可以被用来产生商业价值并提供服务。以苹果和谷歌为例，谷歌的 Gemini 在演示时主要展示了其与自有生态应用程序的整合，如 YouTube 和日历应用。Gemini 内部使用了类似于 Web 应用的 Firebase 扩展，通过自有生态来实现 Agent 与应用程序之间的跨域交流。苹果则更为激进，它通过意图理解和 APP Intents（应用程序增强）的概念，允许 Agent 与第三方应用程序进行交互。在发布会上，苹果展示了如何通过捷径（Shortcuts）和桌面小组件与第三方应用程序进行整合，基本上就是将应用程序的行为能力描述注册到苹果的意图系统中。Siri 会根据用户需求，调用不同的第三方应用程序功能来完成用户的需求，类似于 OpenAI 之前提出的函数调用能力。无论是苹果、谷歌还是国内的厂商，他们都希望未来的服务能够更加便捷。最关键的是充分理解用户的意图和需求。生态建设比技术本身更需要长远发展。技术方面相对清晰，但生态建设，尤其是服务类需求与智能代理之间的交互和交流会很快推进。对于一些社交类或更长尾的应用程序，可能还需要更多的时间来实现整合。 InfoQ：有人认为未来操作系统会朝着用 LLM 替换所有或部分 Linux 内核的方向发展，您认同这个观点吗？能否完全取代 Linux 内核？我们应该如何将 LLM 的能力有效融入或嫁接到操作系统内核中？vivo 的操作系统，融入了哪些大模型能力？袁东：操作系统内核的核心作用是，管理和协调计算机硬件资源，为应用程序提供一个统一的抽象接口，实现硬件与软件之间的高效交互。行业有人提出 LLM Kernel 但其架构与内核是并存的。首先我觉得，在短期内还是一个并存的状态，因为对于现在我们做产品开发，更多需要的是一个通用的操作系统。对于通用的操作系统，由于要满足用户不同的场景需求，LLM Kernel 不太可能替代操作系统内核。特别是有人提出来 LLM kernel 不光是包括这个 LLM，它甚至也会有一些 Agent 的调度，还有内存管理、Tool Management 等等，但它还是把它放在了跟 OS kernel 并列的一个状态，它甚至不属于 OS kernel 层的一个 kernel，所以这个 kernel 不是真正的 OS kernel，而是一个抽象的 kernel。然而，在某些垂类产品中，主要通过 Agent 来满足用户的需求的情况下，如果它仅仅是通过 Agent 来满足用户需求，比如说我们看到有一些很有意思的视频分享，展示了有一两个桌面级的小机器人，或者一个小的机器宠物。它其实只要一个生成式的能力就可以满足，背后 OS Kernel 可以只服务与之对应的 LLM，或者 LLM 与 OS Kernel 融合也是有可能的。 vivo 的蓝心大模型支持多模态，云 + 端服务于用户。比如用户可以在手表上基于语音交互生成表盘。 InfoQ：面向未来发展，哪些 OS 组件需要 AI 化？您们心目中的智慧 OS 应该是怎么样的？袁东：操作系统正在经历一个明显的 AI 化趋势，个人观点，这在服务卡片等组件中表现得尤为明显，它们正朝着智能化方向发展。在我看来，有两个主要的发展方向： AI 能力的提升：AI 的加入使得操作系统的组件具备了生成能力，比如能够提取和翻译文本、图像的二次生成等。这种 AI 化的能力提升，使得组件不仅仅能够执行基本任务，还能够进行更复杂的处理和创造性工作。系统级别的 AI 调度：AI 技术开放给系统级别，可以被 Agent 进行调度，成为智慧调度的一部分，以满足用户需求。这意味着操作系统能够更主动地与用户交互，理解他们的意图，并提供个性化的服务。智慧 OS 的特点主要体现在以下几个方面：主动交互：智慧 OS 能够理解用户的意图，并主动与用户进行交互，这种交互方式更加人性化和主动。拟人特性：与以往的多模态和自然交互相比，智慧 OS 通过大模型和 Agent，展现出更加智能和拟人的特性。需求化解：智慧 OS 能够帮助用户将复杂需求简化，例如，通过智能代理帮助用户完成一系列相关任务，如打车、订餐厅、导航等，而不需要用户逐一打开不同的应用程序。将大型模型整合到手机中需要考虑的改进包括：安全：保证端侧模型生成内容的安全，还要时刻兼顾用户使用手机的场景安全。例如，监测 – 抵御外来通过不法手段对用户的诈骗。存储：存储也需要改进，尤其是在容量方面。未来操作系统可能会将更多用户数据存储在本地而非云端，出于安全性和隐私性的考虑。用户的数据可能会被持续记录，关键信息如微软的“Recall”和苹果的“On Screen Awareness”（屏幕理解能力）可能会将用户在应用程序级别的操作数据进行拆解和存储。长期来看，这些数据将占用大量内存空间，未来可能会考虑将这些数据存储在特殊的内存位置，类似于苹果发布 Touch ID 时存储用户指纹数据的方式。计算：模型的能力依赖神经网络计算的能力，神经网络计算能力的发展是一个新需求。如何在端侧保证模型能力越来越强的同时，还能兼顾内存、耗电等资源的占用是需要取舍。大模型生成能力与操作系统的融合方面，我们之前有推出一个智能表盘，我们发现大家使用智能手表很喜欢按照自己的喜好去自定义表盘，所以根据这个需求，我们开发了一款可以通过对话自动生成壁纸的智能表盘，用户只需要描述自己想要什么壁纸，就能直接生成。未来我们还会有更多更令人兴奋的功能和产品持续推出，敬请关注。 InfoQ：大模型对开发者会带来什么样的变化？对 App 开发会产生什么样的影响？袁东：大模型背后代表的是一种智能的产生，这种智能元素可以类比于开发中的新基础元素，就像水和电一样是基础设施的一部分。这种变化首先会改变开发范式。传统的开发方式是程序员通过输入、存储、计算数据，然后输出确定的数据，使用计算机语言进行编程和运算。未来，编程可能会转变为使用自然语言进行交互，计算将变成一种概率性的计算。开发流程将包括数据的收集和整理、学习、预训练后的模型校验，直至模型能够满足用户需求并生成内容。开发者将利用这一流程，对程序进行相应的变化。其中最关键的是如何提高准确度。有许多方法可以提高准确度，包括结构化输入输出和优化提示工程等技术手段。生态系统也在发生变化。开发者不仅开发满足用户需求的功能，还需要考虑如何获取商业价值。比如开发 AI 原生应用，例如 ChatGPT 就是一个 AI 原生应用的例子。尽管 AI 原生应用具有一定的风险，因为模型或智能能力尚未完全成熟，存在很大的不确定性，但短期内在特定垂直领域开发 AI 应用仍有其价值。例如，某些专注于短期内开发垂直领域的黏土图片生成的 AI 应用，通过精准定位用户需求，短期内可以获得收益。长期来看，Agent 应用可能成为更超级的应用程序。如果行业内有 Agent 的规范，开发者可以在生态系统中遵循相应的规范，结合各种 Agent，从而满足用户需求。例如，苹果的 Siri 提出了一些生态系统规范，开发者可以在这些规范下进行开发，既能满足用户需求，也能实现商业变现。 InfoQ：我个人对当前应用开发的趋势还有一些疑问。例如，我们观察到一些应用，比如之前提到的黏土风格图片生成应用，它们实际上可能并不需要开发成一个完整的应用程序。这引发了一个问题：在大模型时代，是否意味着我们之前讨论的快应用以及小程序等轻量级应用形式会具有更广阔的发展前景？袁东：在 AI 时代，应用程序的形态，Web App 可能会更加适应 AI 技术的发展。Web App 的优势在于它不需要用户进行安装和升级，始终能够保持最新状态。这种即时更新的特性意味着 Web App 能够与 AI 模型保持天然的兼容性，因为 AI 模型可以不断地进行训练和优化，而 Web App 可以即时利用这些最新的模型。随着 AI 技术的发展，Web App 甚至可能与 Agent 进行更多的交互，逐渐演变成插件形态，不再需要传统的图形用户界面。这种形态的应用程序在 AI 时代将有很大的发展空间。更多的内容请关注 8 月 8 号，快应用大会。 vivo 蓝河操作系统的演进和迭代 InfoQ：蓝河应该是在 ChatGPT 热起来之前就已经开始规划的项目？是否能分阶段介绍下它的发展历史？另外，蓝河操作系统在发展过程中遇到的最大挑战是什么？袁东：2018 年伊始， vivo 建立了 AI 研究院，自研操作系统团队，并且在当时我们就认为 AI 时代 Web App 是天生适合 AI 时代的 App 形态。历经 6 年我们研发并发布了蓝河操作系统。 ChatGPT 代表的大模型带来了智能涌现，我们在 2023 年顺势而为发布了蓝河 OS。天生更智慧，天生更安全，天生更流畅。智慧是核心，安全、流畅是基石。它从一开始就融入了大模型技术，而且在安全性和流畅性方面也进行了全面的重新架构。特别是在架构方面，我们采用了 Rust 语言来实现系统架构，这种语言不仅能够确保用户操作的流畅度，还能在内存安全方面提供强有力的保障。埃隆·马斯克（Elon Musk）也曾提出：“Rust 是实现 AGI 的最佳语言”。目前，Rust 也被尝试用于实现模型推理等任务，例如可以在模型分布式推理中使用。我们认为在这个 AI 技术迅速发展的时期推出蓝河 OS 是非常正确的决定，它具有重大的意义，不仅代表了技术的前沿，也预示着操作系统未来发展的方向。 InfoQ：在大模型技术流行之前，你们就已经决定使用 Rust 语言进行开发，这个决定背后的逻辑是什么呢？有没有一些明确的数据可以证明 Rust 对用户体验带来的正影响呢？袁东：Rust 语言的开发与大模型技术并没有直接的硬性关联。Rust 最初由 Mozilla 提出，旨在解决操作系统中的内存安全问题。C 和 C++ 虽然在实现操作系统内核方面非常高效，但它们在内存管理上存在一些挑战，一旦出现问题，排查成本和时间都非常高。相比之下，Rust 语言在保持与 C++ 相当的运行效率的同时，其编译器能够在编译时就避免很多内存错误，从而减少运行时的内存问题。我们选择使用 Rust 开发操作系统，是出于提供更流畅、更安全系统的考虑。 Rust 的优势方面，更多还是处于对安全性的考虑，比如像最近的 Windows 蓝屏事件，可能我们看到的一个原因是它的内存在 unsafe 状态下指向了一个别的地址，导致它崩溃，最终对行业造成了非常巨大的损失，内存安全的重要性不言而喻而这块也是 Rust 的优势。 InfoQ：蓝河操作系统的技术迭代的规划是怎样的（包括 AI 能力，以及编译器、编程框架、编程语言、IDE 等工具）？袁东：蓝河操作系统主要从智慧、安全、流畅等三个方向持续保证技术迭代。智慧：蓝河操作系统做了智慧的架构设计，重点架设了 AI 能力，实现了更复杂的意图识别和推理决策能力。蓝河操作系统带来了多模态输入输出，模拟人与人的交互方式。它打破了应用和设备边界，让用户不用在各个 APP 和设备中来回切换。同时，AI 的多模态能力将拓宽输入和输出方式，语音、文字、图片、音乐、视频等 AI 都能理解和生成。蓝河操作系统，从系统、应用、到工具链全面突破，通过 VCAP 能力实现对推理决策的支持，基于大模型能力实现了 AI 服务引擎和多模输入子系统。同时，基于 AI 能力打造了诸多智慧操作系统的新型应用。Copilot 提供代码生成、图文生成等能力，带来应用开发的全新生产力工具。蓝河操作系统结合 AI 大模型的能力，探索出了应用开发的全新范式——它可以理解你的需求，自动编写代码，生成专属于你的应用、主题或壁纸，满足你对个性化的需求。安全：安全与隐私是操作系统的基石，行业数据中操作系统大约 70% 的严重安全漏洞都和内存使用不当相关，修复安全漏洞治标不治本，难以彻底解决。蓝河操作系统从性能和安全两个维度选择了 Rust 语言作为系统开发语言，Rust 语言的所有权模型、生命周期等一系列安全特性，保障了代码在编译阶段就可以发现内存使用不当导致的安全问题，进而保障系统安全。流畅：蓝河操作系统从全栈技术视角出发，对多个技术方向进行探索，例如编程语言、运行时 Runtime、系统调度、显示和内存。充分发挥软硬件资源的利用效率，高性能系统架构实现了一系列关键技术，虚拟显卡框架、超级协程机制、Runtime 等，提升了计算、存储、显示的资源效率。系统框架的编写我们创新性的采用了兼具高性能和高安全的 Rust 语言；应用开发还要考虑开发效率和生态兼容，目前采用了 js。Runtime 执行引擎，将前端框架下沉，针对应用使用场景，没有采用传统虚拟机机制，而是直通调用接口，一步直达内核，进一步降低运行时的开销、提升性能。在线程和进程之下，实现了超级协程机制，无论是滑动屏幕还是打开应用，都可以优先响应当前操作，实现丝滑流畅的使用体验。蓝河实现了虚拟显卡框架，在虚拟显卡框架上，创新实现了超级渲染树、并行渲染、异构渲染，解决了丢帧、掉帧、帧同步的问题，保障蓝河操作系统的显示天生更流畅。对于内存管理，设计了全新的内存管理双向动态调整算法，按照算法来分配不同的内存，减少应用启动时间。 InfoQ：您能否详细介绍一下蓝河在构建开发者生态系统方面的具体策略和计划？对于蓝河的开发者来说，您认为他们的机遇在哪里？袁东：蓝河在构建开发者生态系统方面的策略和计划是多方面的，旨在创造一个智能应用生态解决方案，同时为开发者提供丰富的机遇。我们认识到每个生态系统都有其特色，蓝河生态中用户的场景与其他生态不同，特别是在阅读和服务类应用方面。蓝河寻求在这些场景中进行智慧升级，以提升用户体验，使他们更加喜爱这些场景。长期目标是将蓝河操作系统打造成这个时代的智能应用生态解决方案，更加智能地满足用户的各种需求场景。为了鼓励开发者，蓝河的运营团队持续进行各种活动。例如，去年蓝河 OS 举办了一场比赛，吸引了 300 多支队伍参加，奖金池达到 75 万。赛题包括利用 AI 技术将操作系统内核从 C 语言转换为 Rust 语言，以及生成智慧应用。比赛中涌现出许多有潜力和创意的 App 和系统级解决方案。今年，蓝河将继续举办符合这个时代特征的创新比赛，并进行线上和线下推广，同时邀请专业团队为开发者提供指导。不论比赛结果如何，蓝河都会发掘有潜力的选手，他们有可能成为蓝河团队的一员。总的来说，未来蓝河的大模型和操作系统将持续朝智慧化方向迭代。传统应用服务的生态将得到重塑，包括原子化服务、个性化定制、智能分发、跨设备协同以及更拟人化的多模态交互等新设计。对于开发者而言，蓝河生态中的机遇在于 AI、大模型和操作系统的升级。开发者应关注 AI 和大模型能力的提升，以及新操作系统变革带来的影响。我们一方面会从开发效率上帮开发者去减负，包括提供更智能的代码生成、校验、单元测试等能力；另一方面，我们也在探索未来 AI、Agent 跟 APP 之间的新交互方式，去满足 AI 时代的用户的需求，从而获得更大的商业变现机会，这是我们持续在做的一些事情。内容推荐在这个智能时代，AI 技术如潮水般涌入千行百业，深度重塑生产与生活方式。大模型技术引领创新，精准提升行业效率，从教育个性化教学到零售精准营销，从通信稳定高效到金融智能风控，AI 无处不在。它不仅是技术革新的先锋，更是社会经济发展的强大驱动力。在 AI 的赋能下，我们正迈向一个更加智能、便捷、高效的新未来，体验前所未有的生活变革与行业飞跃。关注「AI 前线」公众号，回复「千行百业」获取免费案例资料。今日荐文曝英伟达紧急推迟Blackwell AI芯片发货：有设计缺陷；任天堂员工平均年龄首破40岁；比亚迪成清华毕业生最爱之一 | AI周报全球外包之王易主？每月 1200元工资还天天 996，印度程序员 AI 加持下还是集体失业了！英特尔裁员 1.5 万人，股价暴跌 20 %！CEO：我们将提高退休员工待遇，鼓励自动离职拜登又要出芯片新规！六家中国头部厂商遭禁，新增 120 家实体，美国的盟友却先拍桌子了！缺卡、缺电、缺组网技术！谁能为马斯克构建出全球最强大的 10 万卡超级集群？

谷歌 Gemma 2 2B 发布火爆，小模型如何撑起大格局？

作者丨陈鹭伊编辑丨岑峰语言模型的“小时代”正式到来？北京时间8月1日凌晨（当地时间7月31日下午），Google深夜放出大招，发布了其Gemma系列开源语言模型的更新，在AI领域引发了巨大的震动。Google Developer的官方博客宣布，与6月发布的27B和9B参数版本相比，新的2B参数模型在保持卓越性能的同时，实现了“更小、更安全、更透明”的三大突破。小，但更好 Gemma 2 2B版本，这一通过蒸馏学习技术精心打磨的成果，不仅优化了NVIDIA TensorRT-LLM库，更在边缘设备到云端的多种硬件上展现出了卓越的运行能力。更重要的是，较小的参数量大大降低了研究和开发的门槛，使得Gemma 2 2B能够在Google Colab的免费T4 GPU服务上流畅运行，为用户带来了灵活且成本效益高的解决方案。大模型竞技场LMsys上，Gemma 2 2B的发布也迅速引起了广泛关注。LMsys第一时间转发了Google Deepmind的推文，对超越了参数量10倍于Gemma 2 2B版本的“老前辈”GPT-3.5-Tubro表示祝贺。 Google在与OpenAI的LLM竞争中虽然未能胜出，但其SLM的发展势头却愈发强劲。今年二月，Google 推出了 Gemma 系列模型，这些模型设计更为高效和用户友好。Gemma 模型可以轻松运行在各种日常设备上，如智能手机、平板电脑和笔记本电脑，无需特殊硬件或复杂优化。 Gemma 2模型的技术创新点在于引入了Gemma Scope功能，这是一套开放的稀疏自编码器（Sparse AutoeEncoders, SAEs），新模型包含400多个SAEs，用于分析 Gemma 2 2B 和 9B 模型的每一层和子层，为研究人员提供了理解语言模型内部工作原理的强大工具。 Google Deepmind 语言模型可解释性团队则是通过官方博客对 Gemma Scope 进行了更多的技术分析。该团队称，Gemma Scope旨在帮助研究人员理解Gemma 2语言模型的内部工作原理，推动可解释性研究，构建更强大的系统，开发模型幻觉保护措施，防范自主AI代理的风险。稀疏自动编码器（SAE）将作为“显微镜”，帮助研究人员观察语言模型内部。值得注意的是，尽管Gemma 2 2B为开发者提供了一种灵活且成本效益高的解决方案，但在训练阶段仍然需要投入大量的计算资源。根据Deepmind博客，Gemma Scope的训练使用了约相当于15%的Gemma 2 9B训练计算资源（或GPT3的22%训练计算资源）。 SLM与开源的“逆袭” 在Gemma 2 2B发布后，业界反响热烈。雷峰网GAIR硅谷自动驾驶峰会（2018）嘉宾、UC Berkeley教授Anca Dragan （推特：@ancadianadragan ）第一时间发表多条推文对Gemma 2的SAE机制进行了解读。她表示，如此大的计算资源使得纯粹的学术研究机构难以参与其中，但之后学术界会进一步关注如何利用Gemma Scope的SAE机制来提高模型的解释性和AI的安全性。计算语言学家、DAIR.AI的联合创始人Elvis Saravia （推特：@omarsar0 ）也在第一时间对Gemma 2 2B进行了测试，对Gemma 2的SAE机制给予了高度评价。随着2024年的到来，大模型的光环似乎正在逐渐褪去，而如何将模型做小，正成为今年语言模型发展的重要趋势。2023年的“百模大战”虽然激烈，但大模型的商业价值有限；相比之下，小模型在成本和效率上展现出了更大的优势。甚至“暴力美学”的倡导者、OpenAI CEO Sam Altman也早早承认，“大模型”时代可能走向结束，未来我们会通过其他方式来改进它们。在技术上，通过如蒸馏压缩和参数共享等手段，可以显著降低模型规模同时保持性能。Gemma 2 2B版本的亮眼表现，无疑为下一步的大模型研究提供了重要方向。 Google的另一系列语言模型Gemini，以其不公开源代码的特性，专为Google自家产品及开发者使用，与Gemma系列形成鲜明对比。而META的Llama系列则高举“开源”大旗，向OpenAI的GPT系列发起了强有力的挑战。在过去一年中，OpenAI的GPT系列一直是这个领域无可争议的“王者”，在LMsys的“大模型竞技场”，GPT-4及其后续版本GPT4-o在大多数时间一直牢牢占据第一的位置，仅有一次被Claude 3.5 Sonnet短暂超越。但在2024，开始有越来越多的模型向GPT系列发起了冲击。除了Google的Gemini和Gemma系列外，另一有力竞争者是META的Llama系列。与OpenAI的闭源（OpenAI也因此称为”Close AI”)路径不同，META的Llama系列则是高举开源大旗的代表。就在数天前，Meta CEO马克·扎克伯格(Mark Zuckerberg)在“史上最强开源模型”Llama 3.1发布之际，发表了题为“Open Source AI is the Path Forward”的公开信，强调了开源AI在推动AI发展中的重要性。在Llama 3.1发布后，META AI首席人工智能学家、2018年图灵奖得主Yann Lecun（推特：@ylecun）除了发布了多篇技术角度的推文外，昨天还转发了科技网站Arstechnica的一篇关于“人工智能安全”法案SB1047看法的文章，为“开源AI”争取空间。值得注意的是，虽然Llama系列在以大众评分为依据的LMsys“大模型竞技场”上不敌GPT-4系列，但在另一个以专家评分的竞技场“Scale Leadboard”上却在多个项目中超越了GPT-4系列。目前在Scale Leadboard的6个评测项目上，GPT-4系列仅在Spanish（西班牙语）和Methodology（方法论）上领先。 “Scale Leadboard”是由AI数据标注创企业Scale.ai所创立的排行榜。其创始人、95后华裔天才Alexanda Wang是当前硅谷最受关注的创业新星之一，目前Scale.ai为几乎所有领先的AI模型提供数据支持，并与OpenAI、Meta、微软等组织保持良好关系。目前Scale.ai的估值为138亿美元。 Gemma 2的发布，不仅是Google在AI领域的一次自我超越，更是对整个行业的一次挑战。无论是“小型化”还是“开源”，都预示着2024年将是语言模型研究的又一个春天。让我们拭目以待，Gemma 2代表的“小模型”将如何重塑AI的未来。让大模型的暴风雨来得更猛烈些吧。

苹果大模型最新论文：AFM 模型多维度评测「出炉」

不久前，苹果在全球开发者大会（WWDC）上推出了最新个人智能系统 Apple Intelligence，可以深度集成到 iOS 18、iPadOS 18 和 macOS Sequoia 中，引起了 AI 业内人士、尤其是端侧智能领域的讨论。苹果在 2024 年的一系列技术动作，被戏称为苹果为端侧 AI 所设计的“开卷考试”，即：大模型时代，AI 技术应如何在手机、平板等端侧设备上运营，让手机变得更智能？近日，苹果团队又在 arXiv 上更新了关于 Apple Intelligence 的最新论文，其中介绍了苹果用在 Apple Intelligence 上的两个基础语言模型，包括：一个在设备端运行的大约 30 亿参数的语言模型 AFM-on-device，以及一个在私有云计算上运行的大规模服务器语言模型 AFM-server。论文链接：https://arxiv.org/pdf/2407.21075 根据该论文，苹果开发的端侧大模型在语言理解、指令跟随、推理、写作与工具使用等多个任务上都有出色表现。同时，在保护用户数据隐私与安全上，苹果强调在后训练阶段不会使用用户的个人数据进行训练。结果显示，苹果的 AFM 模型在指令遵循层面皆优于其他大模型，同时，从写作写作能力来看，在摘要总结方面，AFM 模型无论是端侧还是私有云也均要好于其他。而在安全性评估时，AFM 模型也比其他模型要更为负责。但是值得一提的是，AFM 模型的数学能力整体上来看较为一般。人类评估在人类评估中，在端侧，AFM 仅输于 Llama-3-8B ，而与其他模型相比显然更优。据论文介绍，AFM 与 Phi-3-mini 相比，模型尺寸小了 25%，而胜率达47.7% ，甚至超出开源强基线 Gemma-7B 和 Mistral-7B。而在私有云上，与GPT-3.5相比时，AFM 也具有一定竞争力，胜率超 50%。指令遵循在指令级（Instruction-level）与提示级（Prompt-level）的评估中，无论是端侧还是私有云上，均为 AFM 模型表现最好。其指令级的得分分别为 85.7% 和 88.5%，而提示级的得分则分别为 79.3% 和 83.0%。此外，苹果还使用了 AlpacaEval 2.0 LC 和 Arena Hard 作为基准进行评估。在私有云上，这两项测试中均为 GPT-4 的表现最优，其中，在 Arena Hard 测试中，GPT-4 的得分甚至倍超 AFM。在端侧的 AlpacaEval 2.0 LC 测试中，则为 Gemma-7B 评分最优，AFM 模型紧随其后。工具使用苹果还测试了在调用工具使用基准测试中 AFM 模型的表现，分别从简单（Simple）、多重（Multiple）、并行（Parallel）、并行多重（Parallel Multiple）、相关性（Relevance）和平均（Average）几个纬度展开。整体来看，AFM-server 表现较优，从测试结果上来看，在简单、多重、相关性、平均性维度中，AFM-server 均得分最高，分别为91.0、95.5、91.3、89.5。在并行多重维度中，AFM-server 得分 85.0，仅次于 Gemini-1.5-Pro-0514 的 88.0，且领先于 GPT-4 与 GPT-3.5。但 AFM-on-device 表现则较为一般，在多重、并行多重、相关性及平均维度中，均要稍逊于 GPT-4 和 Gemini-1.5-Pro-0514。除此之外，在并行维度中，AFM-server 和 AFM-on-device 的表现情况则都较为一般。写作能力分两块，一块是摘要总结，一块是长作文。其中，AFM 模型主要在摘要总结上表现较好，在端侧的表现优于 Mistral-7B、Gemma-7B、Phi-3-mini 与 Gemma-2B，在私有云上则优于 GPT-4、Mixtral-8x22B、DBRX Instruct 与 GPT-3.5：数学能力上，苹果 AFM 模型的表现则一般，仅在端侧 MATH 基准上高于 Llama-3-8B、Phi-3 mini、Gemma-7B 与 Mistral-7B，GSM8k 是 8-shot、MATH 是 4-shot：负责任的 AI 在文本摘要总结功能中，苹果团队将 AFM 模型在邮件、信息与通知这三个应用上作了测试，分别从 5 个维度（仇恨言论、歧视、违法、色情、暴力）来评估模型的“好”与“差”。研究显示，苹果的 AFM 模型在“好”维度的表现均高于 Gemma-7B、Phi-3-8B 与 Llama-3-8B：安全性评测在有害输出上，苹果 AFM-on-device 的得分为 7.5%、AFM-server 的得分为 6.3%，得分越低、效果越好，远远高于 Gemma-7B、Gemma-7B、Phi-3-mini、Llama-3-8B 与 Mistral-7B（其余得分均在 10% 以上）：在安全提示词上，人类评估，苹果的 AFM-on-device 模型表现优于 Gemma-7B、Gemma-7B、Phi-3-mini、Llama-3-8B 与 Mistral-7B，AFM-server 模型的表现也要远超 GPT-3.5、GPT-4 和 Llama-3-70B：

新王登基，Gemini 1.5 Pro 再度更新，超越 GPT 4o 和 Claude-3.5

作者丨刘洁编辑丨岑峰 lmsys官方在推特发布一则消息，恭喜DeepMind研发的Gemini 1.5 Pro 实验版（0801）在Chatbot Arena排名登顶，超越GPT 4o和Claude-3.5夺得第一。这是继今年3月Claude 3 “超大杯”Opus版本短暂超越GPT-4以来，OpenAI第二次让出Chatbot Arena的Overall ranking宝座。（正如我们前天说的，越来越多的大模型向OpenAI发起了冲击） Gemini 1.5 Pro 实验版（0801）在Chatbot Arena测试一周后。获得了超过12，000个社区投票，在Chatbot Arena和Vision Leaderboard排名上均取得了第一名的好成绩。之前说GPT-4o有刷分技巧，现在看起来Gemini 1.5 Pro可能也学到了这个技巧呢。 Gemini 1.5 Pro 实验版（0801）不仅在综合表现上极为突出，在各个细分领域上也有着出色的表现。它在数学方面排名前三，指令遵循排名前二，编码排名前五，硬提示（英语）排名前五。 Gemini 1.5 Pro 实验版（0801）具有强大的多语言能力，在中文、日语、德语、俄语方面均表现第一。从总体胜率图上，也能看出Gemini 1.5 Pro 实验版（0801）实力强劲，对阵 GPT-4o 的胜率为 54%，对阵 Claude-3.5-Sonnet 的胜率为 59%。前OpenAI的开发者，现Google AI Studio的产品负责人Logan Kilpatrick火速转发，向大家宣布Gemini 1.5 Pro 实验版（0801）目前在 LMSYS 的文本和多模式排名中均位居第一的好消息。 DeepMind的CEO Demis Hassabis也转发了这条消息，祝贺Gemini 1.5 Pro 实验版（0801）能够在极具竞争力的榜单中拿下第一，并且宣布这一版本的已经可以在 AI Studio上进行试用。带领研发Gemini的Jeff Dean也随后转发，对此次实验版本的Gemini 1.5 Pro突破1300+elo分数拿下排名第一的好消息感到非常自豪，也很期待未来能看到其他更好的模型。听闻这则消息，其他从业人员也纷纷发来祝贺。也有不少人分享自己的试用体验。大神elvis对在聊天机器人领域超越了 GPT-4o 和 Claude 3.5 Sonnet的Gemini 1.5 Pro非常感兴趣。elvis分享了自己的测试全过程视频，并总结道，Gemini 1.5 Pro强大的图像和PDF提取能力给他留下了深刻的印象，Gemini 1.5 Pro有着和GPT-4o不相上下的视觉能力，也有Claude 3.5 Sonnet接近的代码生成及PDF理解/推理能力。有人认为Gemini 1.5 Pro在解决高级数学难题方面表现相当不错。也有人说Gemini 1.5 Pro在图像识别植物和动物方面做得确实要比GPT 4o更好。也有更多的人在期待Gemini 1.5 Pro这一版本的正式上线，希望能够API实现Gemini 1.5 Pro的实际运用。参考材料: https://x.com/lmsysorg/status/1819048821294547441 https://x.com/OfficialLoganK/status/1819049322295533684 https://x.com/demishassabis/status/1819085274917622198 https://x.com/JeffDean/status/1819121162578022849 https://x.com/omarsar0/status/1819162249593840110

一文掌握 Prompt：万能框架+优化技巧+常用指标

大模型产业吸金能力凸显，半年融资超2300亿元；GPT-4o Long Output模型发布，支持超长文本输出

🌟 微软AI服务迎来大客户：TikTok每月花费近2000万美元微软的AI服务迎来了一个重量级客户——TikTok。据报道，TikTok每月向微软支付近2000万美元，以获取OpenAI的模型。这笔交易几乎占微软AI收入的四分之一，使TikTok成为微软AI服务的最大客户之一。然而，随着字节跳动正在尝试构建自己的AI模型，TikTok可能会减少对微软AI服务的依赖。这一动态反映了AI领域快速发展中的常见现象，即客户在获得必要的技术后，可能会寻求自给自足。 🔎 360安全大模型免费，助力企业提升安全防护 360集团创始人周鸿祎在互联网安全大会上宣布，360安全大模型将免费提供给所有购买360标准产品的用户。此举旨在打破大模型的高价壁垒，让每个企业都能“用得起、用得好”。360全线安全产品已集成安全大模型的能力，产品加量不加价，体现了360为国家、用户、客户解决问题的决心。 🤖 OpenAI向部分用户开放GPT-4o语音模式今秋将扩大至所有付费用户 OpenAI宣布，从即日起开始向部分ChatGPT Plus用户推出GPT-4o的语音模式。这一高级语音模式能提供更自然的实时对话体验，允许用户随时打断，并能感知和响应用户的情绪。尽管最初功能有限，如无法使用计算机视觉功能，但GPT-4o语音模式的推出标志着AI技术在语音交互领域的重大进步。OpenAI计划在今年秋季将这一功能扩展至所有付费用户。 🔎 阿里巴巴推出AI对话式采购引擎，助力中小企业采购革新阿里巴巴国际数字商业集团宣布，将于9月推出人工智能对话式采购引擎，旨在改变中小企业的全球采购流程。这项新服务将整合所有电商平台，通过理解自然语言并转化为专业采购请求，同时预测采购需求并提供建议。此举预计将大幅提升B2B电商的效率和便捷性，为中小企业带来福音。 📊 为测试聊天机器人 Grok，消息称马斯克的 xAI 考虑收购 Character.AI 据The Information报道，马斯克的人工智能初创公司xAI考虑收购聊天机器人制造商Character.AI，以便测试其Grok聊天机器人。尽管讨论可能不会促成交易，但这一消息反映出AI领域资源争夺的激烈程度。xAI与Character.AI的合作谈判，以及Meta与Character.AI的潜在合作，都显示了大型科技公司对AI初创公司的兴趣，以及它们在AI资源上的竞争态势。 📰 巴西政府斥资近41亿美元投资AI，追求技术自主与竞争力提升巴西政府宣布了一项约40.7亿美元的人工智能投资计划，旨在开发可持续、面向社会的技术，并在AI领域实现技术自主，提高国家竞争力。该计划预计将为公共卫生、农业、环境、商业和教育等多个部门提供资源，支持AI系统的开发，促进消费者服务和其他操作程序的改进。巴西希望通过这一大规模投资，减少对外国AI工具的依赖，推动国内AI技术的发展。 📍大模型产业吸金能力凸显，半年融资超2300亿元 2024年上半年，全球大模型产业相关企业的融资事件达到120起，融资总额超过2300亿元。美国和中国在融资数量和金额上遥遥领先，分别有59起和35起亿元级融资，融资总额分别为1834.38亿元和304.58亿元。大模型应用领域的企业数量最多，而AI Infra领域的企业则在单笔融资金额上表现突出。中国大模型产业虽在融资总额上不及美国，但小额融资活跃，显示出强劲的市场潜力。 🚀 GPT-4o Long Output模型发布，支持超长文本输出 OpenAI推出了GPT-4o Long Output模型，支持高达64k tokens的长文本输出，相当于约200页小说，是原模型输出能力的16倍。然而，输入上限降至64k tokens，用户需在输入和输出长度间做出选择。该模型定价为每百万输入tokens 6美元，输出tokens 18美元，为测试模型，测试时间会维持数周，名为GPT-4o-64k-Output-Alpha。 🌟 Midjourney v6.1发布，图像生成质量大幅提升 Midjourney发布了v6.1版本，带来了八大方面的升级，包括更强的一致性、更高的图像质量、更准确的细节理解等。新版本在人像生成方面表现出色，几乎无可挑剔，生成的物体也更加合理。然而，在多人场景的生成上仍存在挑战，如群像生成时人物的四肢数量和方向会出现错误。Midjourney表示，v6.2版本预计下月发布，将进一步提升文本处理能力。 📂 Kimi联合AiPPT推出-键生成PPT服务 Kimi PPT助手是月之暗面联合AiPPT推出的一键生成PPT服务。用户只需通过语音或文字指令，Kimi就能理解需求，自动生成幻灯片，提供布局和色彩搭配建议，帮助用户快速创建和设计PPT。Kimi还能根据用户反馈进行多轮对话，优化演示内容，确保PPT既专业又个性化。使用KimiPPT助手，用户可以节省大量时间，同时提高演示的专业度和吸引力。 🪙 根据词语使用模式进行判断，日立开发可识别文章是否由 AI 创作的技术日立制作所开发出了一项新技术，能够根据文章中的词语使用模式判断文章是否由生成式AI创作。这项技术有助于防止AI制造的错误信息传播，并帮助企业在撰写重要文件时规避侵犯著作权等风险。通过分析文章中基于规则的词语使用情况，日立的新技术能够提高判断的准确性，为AI内容的监管提供了有力工具。 🌐 星尘智能获数千万美元Pre-A轮融资，引领AI机器人技术革新 AI机器人公司星尘智能（Astribot）宣布完成数千万美元Pre-A轮融资，由经纬创投领投，道彤投资及清辉投资等产业资本跟投，老股东云启资本跟投。本轮融资将用于顶尖人才招募、研发投入、商业化部署等工作。星尘智能致力于研发“新一代最强AI机器人助理”，能自主完成叠衣、分拣物品、颠锅炒菜等复杂任务，并通过持续学习进化，全面提升智能化和多任务泛化能力，逐步实现通用智能。 💡 英伟达黄仁勋展望AI未来：每个人都将拥有AI助手在SIGGRAPH 2024大会上，英伟达创始人兼首席执行官黄仁勋与《连线》杂志资深撰稿人探讨了AI增强人类生产力的未来。黄仁勋强调，深度植根于视觉计算的生成式AI正在增强人类的创造力，而加速计算有望显著提高能源效率。他预言，不久的将来，每个人、每家企业、每个岗位都将拥有AI助手，AI技术的进步将在各行各业得到广泛应用。

要想赚钱，AI模型该大该小？贾扬清：论AI模型经济学的技巧

作者丨刘洁编辑丨岑峰最近的AI社区，关于模型规模的讨论有些活跃。一方面，此前在大模型开发奉为“圣经”的Scaling Law，似乎正在褪去光环。去年大家还在猜测GPT-5的规模“可能会大到想不到”，现在这种讨论几乎绝迹。大神Andrej Karpathy，则是在感慨大模型规模正在“倒退”。另一方面，近期市场上性能优秀的小型模型层出不穷，参数规模、任务处理、反应速度、安全性能，各公司在不同方面卷了又卷。究竟是往大做探索极限，还是往小做迎合市场？这最终汇总成一个问题：在这样模型快速更迭的市场中，要怎么才能把LLM模型的商业价值最大化？唯快不破的模型业态最近发起讨论的是X.ai创始成员之一的Toby Pohlen。他认为如果模型以指数级速度改进，那么训练模型的价值也会以指数级速度折旧。这也导致人们需要赶在模型更迭前就迅速采取行动获取商业价值，一旦模型产生更新，上一代模型就基本一文不值了。 Toby的这番言论深得老板Elon Musk之心，大笔一挥打了一个“100分”。贾扬清也参与到了这场讨论中来，他用感恩节火鸡做了一个有趣的比喻。他提出，售卖模型就像是感恩节火鸡促销，必须在感恩节前夕抓紧时间售卖，避免在感恩节到来后的贬值。新模型的技术更新就是一个又一个感恩节，只有销售得更快才能赚到更多的利润。（emmm…如果对火鸡不好了解，换成中秋节前抢月饼的故事大家或许应该容易理解一些？）评论区也有不少人表达了对此观点的赞同。有人说只要不断地开发新产品和迭代新模型，就能从中持续获得商业价值。还有人说，模型改进的频率将直接决定模型本身的商业价值。但是，模型的商业价值由什么决定，又该如何实现？模型发展在走CNN老路吗？模型必须做小，用起来才顺手。比起大型模型，小型模型成本低应用便利，更能收获商业市场的青睐。贾扬清就发现，行业趋势在于研发和使用尺寸更小性能强大的模型，人们也更愿意把规模参数在7B-70B之间的中小型模型作为商业使用的选择。作为前大模型时代的亲历者，贾扬清在当下LLM模型市场上嗅到了熟悉的味道，先变大再变小变高效，这和CNN时期的模型发展简直一模一样。贾扬清还对CNN的发展历程做了一个简单的介绍。贾扬清还介绍了CNN的一个有趣的应用，Google的MobileNet（2017），占用空间小性能优越，还具有出色的特征嵌入泛化。最后，贾扬清引用了Ghimire 等人在《高效卷积神经网络和硬件加速调查》里的一张图：他还进一步发问，LLM模型未来会遵循和CNN一样的发展趋势吗？大型模型的盈利思考不过贾扬清也补充道，虽然行业趋势是模型小型化，但并不意味着号召大家放弃尺寸更大的模型。但这随之而来的是另一个问题：大型模型的成本会更高。此前也有人提出质疑，对大型模型服务商的运营成本和营运收益做了简单的计算，每天8张H100显卡运营节点的成本约为1000美元，每天可以提供2600万token的服务，但按Llama 405B每一百万token 3美元的价格，怎么算都是亏本的，无法盈利的大型模型不会被市场抛弃吗？贾扬清表示，哎你说这个我就不困了，我熟我来说：）贾扬清认为，虽然每个请求大约每秒输出30个token，但通过批量处理（同时处理多个请求）可以显著提高总吞吐量，可以达到比单个请求高出10倍或更高的吞吐量。同时他还指出，每秒大约30个token指的是输出token，大模型对于输入token的处理速度更快，这也增加了处理的总token数，大模型通常对输入和输出分别计费，也正是这个道理。在后续的另一个回复，贾扬清做了更详细的量化计算：收入798.34美元，成本670.08美元，因此通过整合多种技术方法，在合理流量下（像Lepton这样的大模型技术服务商）是可能盈利的。当然，这只是一个简单的推算，实际的盈利还会受到流量稳定性、计费方式、按需使用GPU的机器成本控制、解码、提示缓存以及其他因素的影响。但某种程度上说，类似深度学习时代对CNN的不断优化，在大模型时代，也需要技术人员对于模型进行种种优化，来保证性能提高的同时不断降低成本，这正是贾扬清看好的创业路线。 One more thing 我们不妨再多讨论一下，对于贾扬清这样的AI Infra创业者，模型大小的潮流变化对他的商业模式有什么影响？这个问题，要分不同情况分析。如果模型参数量越大，提供模型服务的门槛越高（参考Llama 405B），其客单价自然也就越大；另一方面，由于很多小模型实际是在大模型的基础上蒸馏而得到，模型小了，所需的计算资源并没有等幅度减少；由于较小的模型更容易部署在不同的设备和平台上，这可能会带来应用场景的增加，虽然客单价可能降低，但在需求数量上的增加反而可能使得总收入增加；对于贾扬清来说，META的开源路线使得贾扬清的服务对象扩大，因此开源对他来说更有利。看来不管未来模型规模怎么不变化，贾扬清都有机会凭借技术升级稳坐钓鱼台。这有点像之前的中国股市，不管什么消息，都是“利好茅台”啊。这恐怕就是贾扬清最近在推特上为什么这么活跃发表看法的原因？你看好贾扬清这种AI Infra的创业路线吗？参考资料： https://x.com/jiayq/status/1818902164938670206 https://x.com/TobyPhln/status/1818686287475282260 https://x.com/elonmusk/status/1818686692905435406 https://x.com/jiayq/status/1818703217263624385 https://x.com/jiayq/status/1818699120049311883 https://x.com/jiayq/status/1818704837745557912 https://x.com/jiayq/status/1817092427750269348 头图/封面来源于贾扬清X（https://x.com/jiayq/status/1818907312851169748）