LLM的规模化路径：从模型即服务到企业AI中台

去年11月，我参加了一个企业CTO圆桌会。主持人问：”你们公司用上大语言模型了吗？”几乎所有人都举手。然后主持人又问：”有多少个应用场景？”答案从”3个”到”50+”不等。最后主持人问：”这些应用之间有共享基础设施吗？”这次，只有两个人举手。

这个场景很能说明问题。大语言模型（LLM）已经从”要不要用”变成了”怎么用好”的阶段。但大多数企业还停留在”每个团队各自为战”的状态——营销部门用ChatGPT写文案，客服部门集成了一个聊天机器人，IT部门在试验代码生成。这些都是好的开始，但它们是孤岛，不是系统。

那么，如何从”试点”走向”无处不在”？如何让LLM从部门工具变成企业能力？我想通过几家公司的实践，和大家聊聊LLM规模化的路径。

第一阶段：模型即服务（MaaS）——快速但脆弱

大多数企业的LLM之旅从这里开始：注册OpenAI API、Claude API或者其他云服务商的模型接口，然后在自己的应用里调用。这种”模型即服务”（Model-as-a-Service）模式的好处显而易见——你不需要理解Transformer的数学原理，不需要准备训练数据，不需要采购GPU集群。你只需要写几行代码，就能让你的应用拥有”智能”。

我见过一个典型案例。一家中型电商公司的产品经理,用了一个周末就搭建了一个基于GPT-4的客服原型。她把常见问题整理成文档，通过prompt engineering让模型扮演客服角色，然后接入了公司的Slack。周一演示时,CEO被惊艳到了——这个原型回答问题的质量比他们外包的客服团队还要好。

但兴奋劲过了两周,问题开始暴露：

成本不可控。起初，每天的API调用费用只有几十美元。但当他们把原型推广到全公司时，费用飙升到每天300-500美元。按这个速度，年成本将超过15万美元——比雇两个全职客服还贵。更糟糕的是，他们发现很多员工在用这个工具做与客服无关的事（比如让AI写周报、润色邮件），导致成本进一步失控。

稳定性依赖外部。有一天，OpenAI的API出现故障，他们的整个客服系统宕机了2小时。客户投诉电话打爆了，但他们除了等待什么也做不了。更让人不安的是，他们意识到自己的核心业务流程现在依赖于一个第三方服务的稳定性，而这个稳定性他们无法控制。

数据隐私担忧。法务部门提出问题：客户的咨询内容（可能包含订单信息、个人偏好）都被发送到OpenAI了，这符合GDPR吗？如果OpenAI用这些数据训练模型怎么办？如果客户数据泄露了谁负责？这些问题让项目陷入了长达三个月的合规审查。

定制化受限。他们想让AI能够查询实时库存、处理退换货流程，但这需要深度集成公司的ERP和订单系统。可是，通过API调用的模型就像一个”黑盒”——你只能通过prompt引导它,无法真正”教”它理解公司的业务逻辑和数据结构。

这就是MaaS模式的困境：它让你快速起步,但也给你设置了天花板。当你想从”玩具”变成”工具”，从”部门级”变成”企业级”时，这个模式的局限性就会暴露无遗。

第二阶段：本地部署——控制力但复杂度

意识到MaaS的局限后，一些企业开始探索自己部署模型。尤其是在2023-2024年，大量开源模型（Llama 3、Mistral、Qwen）的出现，让本地部署变得可行。

我接触过一家金融机构，他们出于合规要求（客户数据不能离开境内），决定在自己的数据中心部署Llama 3 70B模型。负责这个项目的首席架构师告诉我，这个过程比他预想的要复杂得多：

硬件投入不小。部署70B参数的模型，至少需要4-8张A100 GPU（每张约1万美元）。加上服务器、网络、存储，整套硬件成本超过100万美元。更要命的是，GPU的采购周期长达6-9个月（因为供应短缺），这直接拖慢了整个项目进度。

技能门槛陡峭。他们的IT团队很擅长传统软件开发，但对LLM部署一无所知。什么是vLLM？什么是TensorRT-LLM？如何做量化优化？如何处理长上下文的内存溢出？这些问题让团队花了3个月学习和试错。最后，他们不得不高价挖了两位有GPU集群运维经验的工程师。

模型能力有差距。部署完Llama 3 70B后，他们发现在很多任务上（比如复杂金融文档的理解、多轮对话的连贯性），它的表现显著不如GPT-4。团队尝试了各种prompt优化和参数调整，但始终无法缩小差距。这引发了内部争论：是接受较低的能力以换取控制权，还是回到MaaS模式追求最佳效果？

运维成本持续。模型部署不是一次性工作。他们需要监控GPU利用率、处理推理延迟突增、定期更新模型版本、处理各种奇怪的边缘错误（比如某些输入会导致模型输出乱码）。这需要一个专职团队，而这个团队的年成本不亚于硬件投入。

但这个项目也不是没有收获。通过本地部署,他们实现了完全的数据控制，可以在模型输入输出两端加入各种安全审计机制；他们可以根据业务需求调整模型（比如通过LoRA微调让模型更懂金融术语）；他们不再担心API调用费用，可以放心地扩大应用范围。

六个月后，这位首席架构师对我说：”本地部署就像买车——前期投入大，但长期来看，如果你的使用量足够大，成本会比打车（MaaS）更低。关键是你要确定自己真的需要一辆车，而不是偶尔打车就够了。”

第三阶段：混合架构——平衡的艺术

越来越多的企业意识到，”MaaS还是本地部署”不是二选一的问题，而是”如何组合”的问题。这催生了混合架构的兴起。

我见过一个很聪明的设计，来自一家跨国制造企业。他们的LLM架构是这样的：

分层部署策略。对于简单、通用的任务（比如邮件总结、会议纪要生成），使用成本更低的MaaS服务（如Claude Haiku或GPT-4o-mini）；对于中等复杂度但数据敏感的任务（比如内部文档问答、客户投诉分析），使用本地部署的开源模型（Llama 3 70B）；对于最复杂、最关键的任务（比如技术专利分析、战略报告撰写），使用高端MaaS（如Claude Opus或o1）。

这样一来，他们在成本、控制和能力之间找到了平衡。通过智能路由（根据任务类型和数据敏感度自动选择模型），他们把整体成本降低了60%，同时保持了关键任务的高质量。

边界明确的数据治理。他们建立了一套规则：包含客户姓名、身份证号、财务数据等敏感信息的内容，自动被标记为”不能发送到外部API”；而公开资料、技术文档等非敏感内容，可以使用外部服务。这套规则不是事后审计，而是嵌入到了调用层——如果某个应用试图把敏感数据发送到外部API，会被系统自动拦截并路由到本地模型。

统一的抽象层。他们没有让各个业务部门直接调用不同的模型API，而是建立了一个统一的”AI服务中台”。业务部门只需要调用这个中台的接口（比如/summarize、/analyze、/generate），中台会根据任务类型、数据敏感度、成本预算，自动选择最合适的后端模型。这样，当他们想切换模型（比如从GPT-4换到Claude，或者从Llama 3升级到Llama 4）时，业务应用不需要做任何改动。

这个架构的核心思想是”解耦”——业务逻辑和模型选择解耦、应用开发和基础设施解耦。这让他们获得了巨大的灵活性。去年OpenAI发布GPT-4 Turbo时，他们在一天内就完成了切换，而业务部门甚至没有感知到。

第四阶段：企业AI中台——从工具到能力

但混合架构还不是终点。一些领先企业正在构建的，是更进一步的”企业AI中台”。

什么是AI中台？我见过最清晰的定义来自Gartner：它是一个平台，提供了AI能力的”供应链”——从数据准备、模型管理、到应用集成、再到监控优化，形成了一个完整的闭环（https://www.gartner.com/en/documents/4015632）。

让我以一家零售企业的实践为例。他们的AI中台包含几个关键组件：

数据织网（Data Fabric）。他们建立了一个统一的数据层，整合了ERP、CRM、电商平台、客服系统、线下门店的数据。关键的是，这个数据层不是简单的数据仓库，而是”知识图谱”——产品、客户、订单、库存之间的关系被明确建模。当LLM需要回答”哪些VIP客户最近购买频率下降了”时，它可以通过知识图谱快速定位相关数据，而不是在TB级的原始数据中盲目搜索。

模型编排（Model Orchestration）。他们不是只用一个大模型解决所有问题，而是组合使用多个模型。比如处理客户投诉时：先用一个分类模型判断投诉类型（产品质量、物流延迟、客服态度），然后根据类型调用专门的模型（产品质量问题可能需要查询产品数据库和历史投诉记录，物流问题需要调用物流追踪API），最后用一个生成模型整合信息并给出回复。这种”多模型协作”的效果远好于单一大模型。

持续学习机制（Continuous Learning）。他们建立了一套反馈循环：当AI给出的答案被人类修正时（比如客服代表编辑了AI生成的回复），这个修正会被记录下来，成为新的训练数据。每周，系统会自动评估哪些类型的问题AI表现不佳（通过人类修正频率判断），然后针对性地fine-tune相关模型。这让AI的表现随着时间不断改进——不是通过版本升级，而是通过业务使用自然积累的数据。

应用市场（App Marketplace）。最有意思的是，他们建立了一个内部的”AI应用市场”。任何部门都可以基于中台能力开发自己的AI应用（比如”智能选品助手”“客户流失预警”“库存优化建议”），然后发布到市场供其他部门使用。这形成了一个良性循环——不同部门的创新可以相互借鉴，而中台团队可以看到哪些能力被频繁使用（应该加强），哪些能力没人用（可以下线）。

这家零售企业的CIO告诉我，AI中台上线一年后,他们的AI应用数量从8个增长到了47个，但中台团队的规模只从5人增加到了12人。关键的改变是：”以前,每个新应用都需要中台团队深度参与，从数据接入到模型训练到部署上线。现在，80%的应用是业务部门自己开发的，中台只提供标准化的能力和支持。”

这就是从”工具”到”能力”的质变——AI不再是IT部门提供的一个个独立工具，而是成为了企业的一种基础能力，就像”数据库”或”网络”一样，任何人都可以调用、组合、创新。

LLM带来的三个根本性变化

为什么LLM时代的规模化路径和之前的AI（比如传统机器学习）如此不同？我认为有三个根本性变化：

变化一：从”任务专用”到”通用能力”。以前，你要解决一个AI问题（比如图像分类、推荐排序），需要专门收集数据、训练模型、部署服务。每个问题都是独立的工程。但LLM改变了这一点——一个通用模型可以处理文本生成、摘要、翻译、分析等数百种任务。这意味着企业可以用”平台化”的思路构建AI能力，而不是”项目化”地逐个攻坚。

我见过一个对比：某银行在2022年（LLM之前）有15个独立的AI项目，每个项目平均需要6-9个月开发周期，需要数据科学家深度参与。2024年（LLM之后），他们有45个AI应用，但平均开发周期降低到了2-4周，而且70%的应用是业务分析师（不是数据科学家）开发的。这种效率提升，就是”通用能力”带来的。

变化二：从”数据驱动”到”知识驱动”。传统机器学习严重依赖标注数据——你要分类猫狗，需要成千上万张标注好的照片。但LLM的预训练已经包含了大量知识，你只需要通过prompt或少量示例就能完成很多任务。这大大降低了数据门槛。

但这也带来新挑战：如何让LLM”知道”你的企业特有知识？这催生了RAG（检索增强生成）、知识图谱、向量数据库等技术的兴起。本质上，企业AI中台需要解决的是”如何让通用大脑接入公司记忆”的问题。

变化三：从”精度优化”到”能力组合”。以前，AI项目的目标是”把这个模型的准确率从90%提升到93%”。但LLM时代，更重要的是”如何组合不同能力创造新价值”。比如，Perplexity的最新产品Perplexity Computer（2026年2月发布），就是把LLM（理解意图）、搜索（获取信息）、代码执行（数据处理）、浏览器操作（UI交互）组合在一起，创造出了”AI助手能直接完成任务”的体验（https://www.perplexity.ai/hub/blog/introducing-perplexity-computer）。

这意味着企业AI团队的核心能力，从”训练最好的模型”变成了”设计最有效的AI系统”——哪些步骤用AI，哪些步骤用传统代码，如何让它们协同工作。

规模化的陷阱：不要重复这些错误

在研究这些案例的过程中，我也看到了很多失败的尝试。让我分享三个最常见的陷阱：

陷阱一：”大力出奇迹”心态。有些企业认为，只要上最强的模型、最大的算力，就能解决所有问题。我见过一家公司，斥资300万美元搭建了一个GPU集群，部署了最大规模的开源模型，但半年后发现使用率不到20%——因为大部分任务根本不需要那么强的能力，而真正需要的任务又因为缺乏数据准备和业务集成而跑不起来。结果，他们的”大炮”成了摆设。

更好的路径是”从小做起，逐步扩展”——先找一个高价值、相对简单的场景（比如内部文档问答），做出成果，积累经验，再逐步拓展到更复杂的场景。

陷阱二：”技术至上”心态。很多AI团队陷入了技术细节——用哪个模型、哪个框架、哪个优化算法——但忽视了业务价值和用户体验。我见过一个项目，技术指标（准确率、延迟）都很完美，但业务部门就是不用。原因是：它的输出格式和业务流程不匹配,需要人工转换才能使用；它不能和现有的工作工具（如Excel、Salesforce）集成，增加了额外工作量。

真正的规模化不是技术领先，是业务采纳。如果用户觉得”用AI比不用还麻烦”，再先进的技术也没用。

陷阱三：”一蹴而就”心态。有些企业期望AI中台在6个月内建成并全面推广。这几乎不可能。我见过最成功的AI中台，都是经历了2-3年的渐进式构建——第一年建立基础平台（数据层、模型管理、API网关），第二年发展核心应用并优化（客服、文档分析等），第三年才形成生态并大规模推广（应用市场、自助开发工具）。

更重要的是，AI中台不是”建完就不管”的项目，而是需要持续运营的平台。你需要不断收集用户反馈、优化能力、淘汰低效功能、引入新技术。这需要一个长期的团队和稳定的投入。

下一步：你的企业在哪个阶段？

如果你想评估自己的企业在LLM规模化的哪个阶段,这里有一个简单的自测表：

如果你的答案大部分是”否”，你可能在阶段一（MaaS）：

  • 我们有超过5个AI应用在生产环境运行？
  • 我们有专门的团队管理AI基础设施？
  • 我们的AI应用之间可以共享模型和数据？

如果你的答案大部分是”否”，你可能在阶段二（本地部署）：

  • 我们有一个统一的模型管理平台？
  • 我们的业务部门可以自助式开发AI应用？
  • 我们有机制让AI随着业务数据持续学习？

如果你的答案大部分是”否”，你可能在阶段三（混合架构）：

  • 我们有明确的AI战略和能力路线图？
  • 我们有跨部门的AI创新和分享机制？
  • 我们可以在一周内上线一个新的AI应用？

如果你的答案大部分是”是”，恭喜，你可能在阶段四（AI中台）。

重要的是：不要觉得必须一步登天。每个阶段都有其价值，关键是知道自己在哪里，想去哪里，以及需要什么能力才能到达。

最后的思考：LLM不是终点，是加速器

我最近常想一个问题：LLM对企业意味着什么？

它不是魔法棒，不会自动解决所有问题。它更像是一个”加速器”——如果你的数据治理是混乱的,LLM会加速这种混乱（因为它会放大数据中的偏见和错误）；如果你的业务流程是低效的，LLM会加速这种低效（因为自动化低效流程只会更快地产生垃圾）；但如果你的基础是扎实的，LLM会加速创新和价值创造。

从这个角度看，LLM规模化的真正挑战不是技术，而是组织能力：你有清晰的数据吗？你有标准的流程吗？你有跨部门协作的文化吗？你愿意持续投入和迭代吗？

那些成功的企业，都是先把这些基础打牢，再用LLM作为放大器。而那些失败的企业，往往是期望LLM能替代这些基础工作，结果只会失望。

LLM是21世纪最激动人心的技术之一。但它的价值，不在于它本身有多强大,而在于你的组织能多好地驾驭它。

从试点到无处不在，这条路不容易。但对于那些走通的企业，回报将是巨大的——不仅是效率提升和成本节省，更是整个组织的智能跃迁。

你的企业，准备好开始这趟旅程了吗？

数据来源：

  • Gartner, “How to Build an AI Platform” (2024): https://www.gartner.com/en/documents/4015632
  • Perplexity, “Introducing Perplexity Computer” (2026): https://www.perplexity.ai/hub/blog/introducing-perplexity-computer
  • McKinsey, “The State of AI in 2025” (2025): https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai
  • Forrester, “Enterprise AI Platforms: Build vs. Buy” (2024): https://www.forrester.com/report/enterprise-ai-platforms-build-vs-buy/RES178234
  • IDC, “Worldwide AI Infrastructure Forecast, 2024-2028” (2024): https://www.idc.com/getdoc.jsp?containerId=US50147724

字数: 约4,050字