作者｜苏霍伊
编辑｜赵健
11月30日，是 ChatGPT 问世一周年的日子。
过去的一年时间已证明，AI 大模型并不是泡沫，作为新一代的生产力工具，它将成为数字化系统的标配，赋能产业数字化发展。
大模型的最显著特征在于其庞大的规模，参数规模通常会达到百亿、千亿，甚至万亿级别。为了更高效地运行这些大模型，算力集群已经升级到“万卡”级别。
但是，当有些人在追求更大参数规模的同时，另一些人则希望把大模型“做小”。
普林斯顿大学计算机科学系助理教授陈丹琦在 2022 年智源大会上就发表了“Making large models smaller（让大模型变小）”主题报告。2023 年 5 月，Google 在 I/O 发布者大会公布了 AI 大计划：让大模型变小、嵌入每一个产品。
而在国内企业界，360 集团创始人周鸿祎的观点极具代表性。在 2023 亚布力中国企业家论坛第十九届夏季高峰会上，周鸿祎表示，在种种因素制约下，中国企业与其像 OpenAI 一样追求“大而全”，不如结合自己的产业、企业，将大模型做“小”。
他认为，可以从行业化、企业化、专业化、垂直化四个方面入手，把大模型做得“小而精”。“在一个公有大模型的基础之上，再来加入企业内部很多知识的训练。这个大模型，我认为未来是企业数字化最核心的数字资产，所以一定要私有化控制，私有化部署。”周鸿祎说。
在“模型大小之争”外，作为一家从网络安全起家的公司， 360 如何布局大模型也引发了「甲子光年」的好奇： 360 如何私有化部署大模型？大模型在 to B 和 to C 场景中应用有何不同？在不同场景中，大模型容易出现哪些“缺陷”？......
带着这些问题，「甲子光年」专访了 360 集团副总裁、360 大模型应用负责人梁志辉。以下为专访实录，经「甲子光年」整理，有删改。
1.「1 + N」或许是最优路线
甲子光年：周鸿祎曾公开表示，要将大模型做“小”，但是 360 智脑也是千亿级别的通用大语言模型，这是否与他的表述有些“自相矛盾”？
梁志辉：首先，我想介绍下我所理解的大模型的“大”。
从整个行业来看，大模型目前有做到万亿级别的，但我国头部的大模型多在千亿级，而初创公司发布的大模型基本上在百亿级。从技术角度看，现在开源模型很多，比如 Llama2 ，基于开源模型、开源数据集和专有文档来训练一个百亿模型并不困难。
我们内部也在探讨，对不同类型的客户需求，我们应该提供什么类型的模型去适配？
对此，我们做了几轮测试，最后会发现所谓的大模型，比如老周（周鸿祎）之前提到类似于 OpenAI 的万卡级别大模型，它存在显著的缺点是迭代慢。从 GPT-3 到 GPT-4、以及业内传已做出的版本 GPT-5 ，它升级换代的周期和成本，对大多 to B 项目是“不可承受之重”。当模型大到一定程度后，所谓船大难调头，其灵活性很难保障。
所以我们目前在尝试为客户提供不同级别的模型，百亿级的和千亿级的大模型都有。从最终结果来看，千亿级的大模型的可塑性会更强，比百亿的大模型更聪明。
在部署过程中，有一点至关重要，即如何让大模型在客户的现场跑起来。在国内无论是做 to B 还是 to C ，大型企业往往选择私有化部署或者专有化部署。但购买一台 8 卡的 A100 服务器，非官方价格大约在 150 万一台，这种情况下即使大企业的购买力也是受限的。
目前我们已有一些项目能够为客户在现场带动千亿模型，但万亿级别的模型还没有。比较容易能过大客户 POC（Proof of Concept）的，基本也是千级别的大模型。不可回避的是，如果选择 A100 这种级别的服务器，其运行成本、采购成本很高。如果能用 A30 或更低级别的显卡带起来，那它的成本则能降至 30 万左右， 许多 to B 的项目就能跑起来了。
大模型所谓的“大”，也可以用模型的迭代周期去评估。比如一个百亿模型，微调的时间大约在两、三天左右，千亿模型可能约两、三周，万亿则更长。
总而言之，大模型的“大”的定性，随着时间会不停变化。可能半年之后，我们再聊这个问题，可能会觉得千亿、万亿、万万亿的大模型都不是问题了。
甲子光年：360 的大模型结构是什么？
梁志辉：我们是多个模型并行在跑。360 有千亿级别的大模型，解决通用知识问题和逻辑推理的问题；也有多个 10B（100亿），或者说 130B（1300亿）的模型，有的模型解决安全语义理解，有的模型解决总结问题。
360 无论是搜索量还是浏览器的使用量都会很大。在这种前提下，我们把大模型的能力引入到传统的 C 端场景里面，其实有很多的挑战。
首先每次调用的成本都是很严重的问题。我们内部统计过，大模型的调用成本大概是搜索的 10 倍以上。搜索我可以免费给大家用，但如果大模型现在多了 10 倍成本呢？我们采取了一种办法：在搜索过程中，如果只用到一些辅助信息，我们就不需要调 130B 大模型，而是调 10B 模型，调用成本就降了将近 30 倍。
在这种场景下，大模型变成一个类似于总结和调用的能力，用户点进去之后要进行多轮对话，10B 解决不了问题的，这时我们会带着 context 放到 130B 里去做多轮对话，甚至是调用搜索的能力做扩展。
甲子光年：千亿、百亿等大模型的应用场景不太一样，那这种大参数大模型和较小参数大模型会是竞争关系，还是在不同的领域有不同的发展？
梁志辉：我认为它们存在一种协同关系。如果采用大型模型进行特定行业的训练，我们会将训练范围扩展到千亿模型的级别。首先，存在迭代周期的问题，其次，具体效果的评估周期非常长。
毫无疑问，千亿模型在高级推理能力方面肯定更为出色。然而，在一些垂直行业中，比如我们尝试使用大型模型来解决模型之间的安全问题时，可能会出现一些问题。例如，大型模型容易受到“催眠”攻击。实际上，它只需要对内容进行检查，而不一定需要如此强大的推理能力。因此，我们估计，未来国内许多公司可能会在百亿级别的垂直模型上投入更多精力。
甲子光年：正如你所说，小型大模型的复杂推理能力相对较差。目前，我们是否尝试在小型大模型上解决这些问题，使得小模型也能具备复杂推理能力？
梁志辉：目前我们并没有朝这个方向努力，我们更专注于使多个模型能够协同工作，实现类似于调度的能力。我们致力于让聪明的大模型能够解决相关领域的问题，具备一种类似于调度的能力。我认为我们需要尊重物理规律，因为如果模型的参数不够大，期望其具备高级推理能力是相当困难的。
甲子光年：从客户视角来看，前端入口可以调用不同的模型吗？
梁志辉：是的，这是我们后端做出的决策，可以根据场景或问题本身进行调度。在智脑上，用户在调用时通常会经历两个阶段。首先是意图识别，用于判断任务，然后再判断是否需要进行搜索。通过意图识别，系统选择调用的模型。我相信很多同行也在采取类似的做法。
甲子光年：大模型在做本地部署时，是否也是多个模型的组合版本？
梁志辉：我们在给 B 端客户部署的时候可能会。比如说有些模型是专门解决对话理解的，有些模型是负责做内容总结，有些模型是负责做内容生产的。
甲子光年：多模型调度的能力有难度和壁垒吗？
梁志辉：这个还是很有壁垒的。在更多的场景里面我们会首推千亿模型。一是千亿模型高阶推理能力更强，二是千亿模型它不必要负责所有的事情，可以让一个通用模型带一个或 N 个垂直模型专门做这个事情。
三是我们希望把这一整套的 know how 封装成低代码的 Agent 框架。在这种开发大模型应用过程里，不再讨论如何训练一个大模型，而是如何训练一个 Agent，让它能够用不同大模型的能力提升智慧和完成复杂的任务。
甲子光年：把多个大模型封装在一起就等同于一个 Agent 吗？
梁志辉：我们内部的定义会复杂一点，我们定义的 Agent 类似于数字人，但这个 Agent 本身具有不同的能力，包含大模型的能力和大模型以外的能力。
它能够执行工具使用、进行数据库搜索和文本理解等任务。当我们让数字人通过重新培养它以提升不同方向的能力时，有些能力需要与大模型底层进行微调预训练。而有些能力实际上与大模型无关。例如，大模型处理严谨的问题，如时间、人物和地点的搜索，实际上并不太切实际。谷歌等搜索引擎之所以比普通的 MySQL（数据库系统）搜索快很多，其中实际上进行了一些权衡。如果我们进行严格的搜索，只能使用传统的关系型数据库，比如 MySQL。
但是，如果我们在追求最强点击或最强使用的场景时，在百度或谷歌等搜索引擎上的搜索并非全面。它可能会给出一个数字限制，例如有 500 万个结果，只选择最好的 50 个。
就问题的回答而言，如果大模型需要准确地召回与时间、地点等相关的信息，那么它还必须学会如何使用 MySQL 数据库。
甲子光年：你是说向量数据库不能替代 MySQL ？
梁志辉：现在来看是的。很多企业内部不见得把所有东西都要向量化，因为向量只解决类似于这种语义匹配的问题。
甲子光年：那 360 有一个千亿模型和多少个百亿级的模型？
梁志辉：我们现在内部并行在跑的可能至少都有三、四个百亿的大模型。
甲子光年：大模型公司想要 to B 的话，是否多为一个千亿以上的大模型外加 N 个小的大模型的模式，这种“1 + N”的模式会是主流路线吗？
梁志辉：一个很关键的点，企业是否有足够的算力去完成百亿、千亿大模型的一次完整预训练，这是物理极限。
其次，一些创业公司基于开源的数据集做增量预训练，但未必能把“1 + N”的模式推起来，这与资源积累有关系。
2.to B与to C全都要
甲子光年：大模型在 to B 和 to C 的要求有何不同？
梁志辉：前段时间我们做内部分享时发现 to C 跟 to B 对大模型要求有很大不同。
如果做 to C，很多时候问题答案的知识性或事实性是唯一的。
但在 to B 场景，比如营销文案、公文等，这类工作是没有唯一答案的。这类工作全靠大模型生成可能不太现实，所以 to B 用户对大模型的要求相对于 to C 用户会更高。to C 的一类问题我们通过一次 prompt（指令）就能回答，但 to B 的问题我们很难只跟大模型只交互一次便解决掉。
甲子光年：to B 场景的要求更高，请用一个具体的场景解释下。
梁志辉：比如现在比较流行用大模型去做知识问答。
知识问答中可能存在很多规章制度，比如报销流程、政务服务中的公积金提取等，to B 的用户在与大模型交互时，他们很难像可以熟练运用 few-shot（少样本）的 AI 专家一样去写提示词。
如果在 to B 场景里面，我们定制一个数字人从事回答任务，可能会存在口语化表述等问题。比如公积金提取人的户籍、是否有发票等，这些都是树状结构的复杂问题。
在这种场景下，如果大模型不能与人进行有效交流，并把缺失的问题补全，而只基于政策文档去反推整个决策树，这种方法解决不了问题。对于此类信息，大模型训练语料不会很多，而生活中更普及的问题多是瀑布流形式的，我们只要知道几个关键节点再顺序执行即可。
在 to B 场景里，如让数据员工写文章或行情报告等，首先需要拆解需求再做树状结构处理，其他更复杂的问题则需要网状结构或者环路的经过多次循环之后才能够解决。
To B 的客户对大模型的高要求也体现在此。
甲子光年：在 to B 的场景中，大模型容易出现哪些“缺陷”？
梁志辉：第一是行业知识。大模型无论多么强调它的参数、数据以及训练过程，它提升的多是通识能力，而不是一个行业的专家能力。
比如我们希望大模型去解决危化品的管理问题，这些内容不能在公开语料中找到。大模型在面对行业问题时，比如化工、金融等，我们会发现它听不懂术语，也不了解行业知识，这种知识缺失是很明显的。
第二是大模型其实最擅长的是内容生成、内容理解和逻辑推理。但对企业内部而言，只具备以上能力是不够的。大模型的幻觉问题、遗忘问题在一段时间内会是一直存在的局限。这些缺失，让大模型用到 to B 上面临许多挑战。
甲子光年：360 是更专注 to B 和 to C 哪个领域？
梁志辉：我们既做 to C 也做 to B。我们在 to C 这一块比较着重推数字人的概念。
我们会分几个场景，一是智脑本身就做成了 APP，里面有不同的数字角色，是以大模型能力做支撑的数字人；第二是战略最强的部分，我们在很多的 PC 上有直接用户的一些场景，包括 360 卫士做了一个桌面的悬浮窗，跟 Windows Copilot 很相似。
我们把用户跟大模型的交互分成三类。
第一种像是传统的 ChatGPT ，我们定义成为 ChatUI，是基于聊天的形式；第二种是把这种 AI 能力封装成 GUI 工具，像 Copilot 等。
不同于前两种打字模式，第三种我们做了类似于沉浸式交互的体验，展示一个活灵活现的“加强版”数字人，他有动作、形象和声音，是多模态的能力在支撑。
甲子光年：360 这种 to B 加 to C 这种模式是否会很“烧钱”？我们为什么会选择“双管齐下”的路线？
梁志辉：其实我们的算力在行业里肯定不是最多的。我们认为，让大家先用得起大模型才是这一次大模型变革里最重要的一点。
大家都觉得大模型是一个很牛的事物，但有多少人真的用过 ChatGPT 或类似的产品，这个数据在国内还是有所保留的。
结合类似 PC 端的办公场景去提供应用，是我们的一个优势，它既能 to C 也能 to B。比如国外现在最火的 Jasper，它有不同的套餐对企业和员工。 如果能够把 to B 的东西 to C 化，像 SaaS 一样开箱即用，这种体验才是最好的。
360 有很多能力会先在 to C 市场做出来找感觉，拿到用户的反馈再不停去做迭代。我们在选择模型的时候，我们有个很重要的标准：模型是不是真的被很多用户用过？大模型很重要的一点是经过 RLHF (Reinforcement Learning from Human Feedback) ，即以强化学习方式依据人类反馈优化语言模型。如果一个大模型没有经过 RLHF，那它就变成了专门为某个项目定造的大模型，它的智能逻辑不会太好。
甲子光年：大模型公司既 to B 又 to C 是一个更好的方式？
梁志辉：对，OpenAI 就是这种形式。OpenAI 为什么要做自己的会员，而不是丢几个企业级的接口？我觉得他肯定也有这种考虑。如果现在的 AI 是没有人参与的 AI，这不太现实，因为很多能力都是动态发展，它不是一个训练出来就静态的东西。
甲子光年：那可以理解为 360 在 to C 领域的布局并不是奔着商业目标，而是打磨产品的更快的、更高效的方式？商业目标可能更多是以 to B 的方式完成的？
梁志辉： 并非如此。10 月底的时候，我们发布了 AI 大会员，把 360 的 AI 的能力结合场景去封装成产品，大概会有 200 多项 AI 的触点。在种场景底下，大概一年几百块的水平，给 C 端用户提供更优质的体验。所以并不是说我们 to C 上不考虑盈利，但我们还是希望把这些产品打磨完善后再谈盈利。
3.AI 原生像是一个散装概念
甲子光年：大模型在行业中通常分为基础层和应用层，你认为基础层和应用层之间的关系是什么？
梁志辉：这个问题可归类为企业究竟是向用户卖电还是卖电器。
现在的大模型公司有点像电力公司，大家都希望发电、售卖电。但现在人们发现只销售电并不能获得很高的价值。国内每 1000 个 token 的成本已经降到了不到 1 分钱。
因此，我认为在未来做应用层时，我们不一定只调用自己的大模型，也许可以通过商务合作、接口合作来实现互通有无。在应用层，人们其实并不太关心是哪个大模型提供服务。应用层对模型的依赖并不高，所以未来各个公司可能会进行顶层的商务合作。
甲子光年：360 现在定位的更多是在哪一层，偏应用层还是基础层？
梁志辉：实际上，我们现在两者都在做。我们主要是一个偏向 Infra（基础设施）的团队，致力于私有化部署大模型以及相应的软件、硬件架构。然而，如果只提供一个大模型，用户可能无法负担得起。因此，我们同时关注应用层和基础层，例如，将 C 端的应用进行 B 端化的封装和改造。
甲子光年：AI native，即 AI 原生目前很受关注，360 是否有关于 AI 原生方面的计划或投入？
梁志辉：我认为当前存在一些趋势，比如 Adobe 这样的公司，它从未提及 AI 原生。但它所开发的AI工具却是那些所谓的 AI 原生公司无法实现的。
在我看来，AI 原生更像是一个散装概念。如果在真正到达用户层面时，过度强调所谓的 AI 原生，有点像饭店声称他们的菜都是 AI 原生的。
因此，是否采用 AI 原生的方法取决于是否有广泛用户接触的场景。比如，让 Photo shop 成为 AI 原生就显得很奇怪，因为它本身的编辑工具非常强大，只需要 AI 来赋能和提升能力便足够。但是，如果产品本身与用户之间没有触点和成熟的应用，比如智能客服，在重新验证时会发现，许多客户在产品交付时，未必能够开发出一个 AI 原生的智能客服。
对用户反馈的总结、管理功能以及信息分级等，都要做成 AI 原生也是不太可能的。因此，在开发类似智能客服的产品时，将大模型应用于智能客服，比重新基于大模型构建一套智能科普系统更为现实。我认为 AI 应用是有需求的，但是不是 AI 原生的应用才有需求，对此我是存疑的。
甲子光年：过去一年左右，大模型技术在实际应用中的进展你认为是快速还是缓慢？与预期相比是低于还是符合进度？目前而言，业内出现越来越多的大模型公司，但真正实现盈利的案例似乎并不多见。
梁志辉：我也有这种感觉，实际上大模型的兴起是在今年才开始的，很多公司也是在今年才深入探讨。不过，全球范围内有一些公司已经取得了不少盈利的案例。
我认为大家对于 AI 付费的看法，相较于传统的 SaaS 付费模式，用户的积极性可能更高。这是一个正向的信号。在过去的大半年中，对于如何从大模型转化到大模型应用的场景，大家可能还没有明确的方向。
甲子光年：你们在和 B 端用户接触时，所接收到的反馈有什么？
梁志辉：不同级别客户的需求是不一样的。
比如政府部门，他们很关心模型到底是不是可信、模型有没有安全问题、内容安全性、价值观安全性有没有保障等。他们会先谈清这些问题，再聊模型的参数、技术能力等问题。
大企业则更关注技术表现， POC 过程里侧重对应的技术指标。
而到中小企业这边，他们会更多询问有没有开箱即用的 AI 工具或者 AI 应用，主要关注降本增效。
在尝试让大模型更好用的过程中，我们经历了两个阶段。首先，我们让大模型能产出更好的文案。其次，我们将大模型与 Agent 框架结合，从而完成更多任务，如行业分析报告等。通过增强知识、技能和逻辑，让大模型规划并完成更复杂的任务。
我注意到国内许多大模型公司首先专注于小红书文案生成，这是一个很典型的案例。但如果只做小红书的文案生成，大模型的功能相对单薄。
我们的目标是打造一个小红书专家，具备实时抓取热点、生成新内容、搜索、自动回答问题等能力，并能跨平台发布稿件和管理评论。我们希望集成一个具有多种技能、行业知识和逻辑推理能力的 AI 数字人，使小红书专家更接近实际应用。
而从简单做到复杂的，调度控制多个能力的集合，就是 Agent。
甲子光年：在大模型应用的落地过程中，你认为最大的挑战是什么？在这个过程中，你们有哪些新的认知？
梁志辉：总结最近的经验，我们认为在大模型应用中，要充分发挥其优势并规避劣势。大模型在内容生成、理解和逻辑推理方面表现出色，但在知识校正和长期记忆方面表现欠佳。在商业场景中，客户更关注性能提升，而非模型过去的表现。为了达到商业标准，大模型需要在技术指标上超越上一代 AI，例如 BERT 模型等。只有满足客户的实际需求，才能赢得项目和实现盈利。
在过去的一个月中，我们一直强调百亿模型的部署。但通过调整，我们验证了千亿模型在客户现场能够进行有效优化。通过技术上的软硬件结合进行优化，已成功迁移并部署了模型。这让我们能够在商业场景中提供更加智能的模型，与竞争对手有所区别。
甲子光年：这是否将成为行业竞争的重点？过去主要部署百亿模型，现在千亿模型的本地部署可能成为竞争的关键因素？
梁志辉：虽然我们没有进行具体的市场调研，但我认为这可能成为行业竞争的一个关键因素。
