字节跳动谨慎迈出了跨入大模型赛道的第一步。

(资料图片仅供参考)

6 月 28 日下午，字节旗下的火山引擎召开发布会，首次正式公布在大模型领域的研发布局和合作进展，并发布大模型服务平台火山方舟，提供模型训练、推理、评测、精调等全方位功能与服务。

此前，百度、阿里、腾讯、商汤、360 等国内大厂已经相继宣布入局，大部分的做法都是发布一个通用大模型或者数个行业大模型底座，行业客户可以基于这些基础模型和自身拥有的行业数据精调，打造一个服务自身业务的 AI 应用。

但字节的切入方式与其他大厂有明显的不同。火山没有发布自己的通用大模型或者行业大模型，火山方舟聚合了一批第三方生产商开发的大模型底座。

火山引擎向大模型生产商提供构建、训练大模型基座所必须的算力和工具体系，并将这些生产商的大模型聚集到自己的 MaaS 平台，供应给企业使用。这与微软投资算力供给 OpenAI，并基于后者开发的 GPT 模型向企业提供 Azure AI 云服务，有相似之处。

因此，火山引擎介绍的合作案例也与其他大厂有所差异。这场发布会上登台的合作伙伴，包括英伟达这样的上游显卡供应商，以及智谱 AI、百川智能、IDEA 等当下国内第一梯队的大模型开发商。而其他大厂的发布会，介绍的往往主要是金融、文旅、企服等各行各业的合作伙伴。

截至今年 5 月，国内已公开披露的大模型数量达到 79 个。按照火山引擎总裁谭待的说法，未来大模型市场一定不会是一家或者几个寡头垄断，而是一个百花齐放的多模型市场，会有少数几个超级大模型，多个通用大模型，和更多行业/垂直大模型。

企业使用大模型，未来也会呈现「1+N」的模式，除了通过自研或深度合作，形成 1 个主力模型；由于成本和场景复杂多元等原因，在这个主力模型之外，还会有 N 个模型同时应用。

大模型开启了新一轮行业变革，在这个淘金时代，OpenAI、谷歌、MiniMax、百川智能等大模型生产商是时代浪尖的淘金者。而火山引擎要做的，就是要在大模型时代「卖铲子」。

01、火山引擎大模型服务平台——火山方舟

会上，火山引擎发布了自己的 MaaS 平台——火山方舟。

火山引擎总裁谭待在会后接受媒体采访时强调：火山方舟最终服务的是模型的应用方；火山引擎是跟大模型的生产方合作，一部分被精选的大模型厂商在火山方舟上部署，然后对外提供服务。

想让企业用户和大模型生产商加入到火山方舟的生态体系，首先要解决的是数据安全的问题。

火山引擎总裁谭待认为，企业使用大模型，最担心的是数据泄露；如果将大模型私有化部署，企业将承担更高的成本，模型生产方也会担心知识资产安全。「火山方舟」的首要任务，就是做好大模型使用者、提供者和云平台可以互相信任的安全保障。

据火山引擎智能算法负责人吴迪介绍，「火山方舟」已上线了基于安全沙箱的大模型安全互信计算方案，利用计算隔离、存储隔离、网络隔离、流量审计等方式，实现了模型的机密性、完整性和可用性保证，适用于对训练和推理延时要求较低的客户。

此外，「火山方舟」还在探索基于 NVIDIA 新一代硬件支持的可信计算环境、基于联邦学习的数据资产分离等多种方式的安全互信计算方案，更全面地满足大模型在不同业务场景的数据安全要求。

第二，想要让企业可以更高效地打造 AI 大模型应用。一方面要降低企业用户使用大模型打造应用的门槛，另一方面也要降低用户使用大模型服务的成本。

上文提到，火山引擎认为未来企业使用大模型会呈现「1+N」的模式，也就是 1 个自研主力模型+N 个小模型同时应用。比如一个对话式的 AI 服务产品，对话功能的基础是源自企业自研的大模型，但提供文生图、文生视频、特定语种翻译，或者回答医疗、金融等专业领域的问题时，却可以调用其他的小模型。

这样做最大的好处是降低模型的推理成本。吴迪称，训练大模型很昂贵，但是从长期来看，模型的推理开销会超过训练开销。效果和成本的矛盾永远存在，降低推理成本会是大模型应用落地的重要因素，「一个经过良好精调的中小规格模型，在特定工作上的表现可能不亚于通用的、巨大的基座模型，而推理成本可以降低到原来的十分之一。」

举例来说，微软以医学文章数据精调了生物领域的 BioGPT-Large 模型，仅有 15 亿参数，其在 PubMedQA 基准测试中的准确率却优于有着上千亿乃至数千亿参数的大型通用语言模型。

但对企业来说，「1+N」模式的一大痛点就在于开发应用的过程中，需要调用各种不同的大模型。而火山方舟提供的第一个功能就是模型广场，不仅集成了大量的第三方大模型，企业自身开发的大模型也可以通过这个平台进行管理。

吴迪介绍，企业可以用统一的工作流对接多家大模型，对于复杂需求可设置高级参数、验证集、测试集等功能，再通过自动化和人工评估直观对比模型精调效果，在不同业务场景里还可灵活切换不同的模型，实现最具性价比的模型组合。这些自定义指标和评估数据的积累，将成为企业在大模型时代宝贵的数据资产。

02、火山引擎的大模型「朋友圈」

火山引擎畅想的前景非常理想，但要做到有一个前提，就是大大小小的大模型开发商需要聚集到火山引擎。数据安全是他们愿意接入火山引擎的必要条件，但显然不会是充分条件。火山引擎吸引大模型开发商合作的基础，在于其掌握的算力资源，也就是过去囤积的大量 GPU。

去年 ChatGPT 发布后，国内 AI 算力紧张已经算是行业半公开的秘密，而字节跳动拥有国内最丰富的算力资源。

据《晚点 LatePost》报道，字节今年向英伟达订购了超过 10 亿美元的 GPU（约合 70 亿元人民币），到货和没到货的 A100 与 H800 总计有 10 万块。而 2022 年全年，英伟达数据中心 GPU 在中国的销售总额大约为 100 亿元，也就是说，仅字节一家公司今年的订单可能已接近英伟达去年在中国销售的商用 GPU 总和。

大部分团队没有条件购买大量 GPU 训练大模型，从火山引擎采购算力也就不足为奇。而对火山引擎来说，大模型生产商发展越好，业务量越大，反过来就需要购买更多的算力。所以在这方面，大模型生产商和火山引擎有着相同的诉求。

今年 4 月，火山引擎宣布与国内 70% 的大模型生产商达成合作，原因也在于此。

会上，火山引擎重点介绍了第一批加入火山方舟的大模型，包括百川智能、出门问问、复旦大学 MOSS、IDEA 研究院、澜舟科技、MiniMax、智谱等多家 AI 科技公司及科研院所的大模型，并已启动邀测。

而首批邀测的企业，则包括金融、汽车、消费等众多行业的客户。北京银行 CIO 龚伟华表示，大模型与客户营销、办公协同、数据智能的结合，在金融应用场景有巨大潜力。北京银行将与「火山方舟」合作，在算力优化、模型精调等方面展开研究，共同推动金融风控、营销等模型应用落地。

除了第三方的客户，吴迪介绍，在火山方舟平台推向市场之前，已经利用众多的内部产品打磨和改进平台。字节跳动有 10 余个业务线正在探索接入和试用，在代码纠错等研发提效场景，文本分类、总结摘要等知识管理场景，以及数据标注、归因分析等方面探索，利用大模型能力促进降本增效。

但是，对于这些内部尝试何时面向用户，吴迪向极客公园表示：还需要一些时间，把大模型应用好是一个需要长周期打磨的事。

火山引擎总裁谭待进一步补充：有一些应用对用户是无感知的，因为它是在已有的环境中去提升效率，而不是像 ChatGPT 这种大模型原生应用，用户能明显感知到是一个大模型来做这个事情。比如客服这个场景，回答时需要检索知识库，但现在通过大模型去给它一些提示，但跟你对话的还是那个对应的客服，只是它的效率高了。

03、字节跳动的下一步

目前来看，字节/火山布局大模型第一阶段的思路已经非常清晰。

从商业上看，火山引擎就是卖水卖铲子的思路。凭借火山引擎的技术体系，加上此前算力资源的积累，做管道和前期的底层服务应该是没有任何问题，所以在这个阶段把基础工具开放出来，帮助大家做好大模型，或者更直接说，从收益上的考量，这个阶段发布技术体系工具比发布大模型的收益值更高。

但有一个很重要的问题是：今天卖铲子的字节，未来会不会下场淘金？

答案是肯定的。谭待告诉极客公园，其内部也有团队在研发大模型。如果做好了，也会上到方舟平台对外提供。此前字节副总裁杨震原也曾向财新回应：字节跳动对大模型也在做一些学习和研究，现在还没有什么结果，也没有大模型产品落地时间表。

但这存在一个问题，就是如何平衡自家大模型和其他第三方的关系。对此，谭待表示，自家的模型只会是众多模型中的一个，其余的是客户自己的选择，不需要火山来平衡，一个企业未来一定会在多个场景用多个模型，因为每个模型在不同场景的性价比是不一样的，这会是一个开放的市场。

正式入局后，不少行业人士看好火山引擎在大模型领域的市场份额会在接下来一段时间快速飙升，原因主要有三个：

第一是因为基础需求。字节本身在云服务这个层面是国内用量排在前三的公司，就算火山引擎，最终只是为了服务字节这一个生意而建，它的收益和投入产出比都是相当可观的。

第二是产品能力。字节这套体系迭代出来的产品工具向外传递，在云服务里的积累和产品化的能力会非常的强，从这个维度来说，对于很多中小开发者，甚至有体系的开发者是很有吸引力的。

第三是因为生态系统成熟。字节本身在云服务这套体系并不是只做了火山引擎，字节在上下游的广告分发、基础设施建设，开发工具等维度都有完善和成熟的生态链，甚至早几年还收购了开发者社区。有着可靠的基础体系，完整的工作链条和生态社区。

过去字节布局国内云服务市场的痛点，在于起步较晚，飞书要挑战已经成熟的钉钉、企业微信，而云服务的特点就是前期获客难，但获客后由于用户迁移成本太高，所以轻易不会更换。

今天的大模型是一条全新的赛道，所有云服务厂商又回到了同一起跑线，对于想要打开云服务市场的字节和火山而言，这也是十年难得一遇的机遇。

编辑/lambor