大模型三层架构实战：从基础模型到应用层的完整拆解

1. 大模型三层架构到底在拆什么1.1 从一个真实困惑说起过去两年我身边做应用开发的朋友几乎都问过同一个问题大模型这东西到底该怎么接进自己的系统里有人一上来就研究微调显卡买了两张数据集标了三个月最后发现业务方要的只是一个能自动填表的助手也有人把提示词写得花里胡哨结果上线后一遇到长文档就崩因为上下文窗口根本装不下。这些坑的根源其实都指向同一件事没有把大模型应用拆成清晰的层次。大家习惯把它当成一个黑盒输入一句话输出一段文字然后就没了。可真正跑在生产环境里的系统从来不是这么简单。我后来总结出一个特别朴素的框架叫大模型三层架构。它不是什么官方标准而是从大量实际项目里抽象出来的通用结构。这三层分别是基础模型层、模型服务层、应用层。听起来有点像传统软件里的 MVC但内核完全不同。MVC 拆的是代码职责而这三层拆的是能力边界——谁负责理解语言谁负责调度资源谁负责对接业务。一句话概括所有 AI 新花样本质上都只在回答两个问题——输入什么给模型以及输出怎么处理。中间那层模型本身反而是最不需要你操心的部分。1.2 三层各自负责什么先把三层的职责摆清楚后面所有讨论都围绕它展开。基础模型层就是那些参数量动辄几十亿、几百亿的大模型本体。它可以是开源的 Qwen、Llama 系列也可以是各家提供的闭源模型。这一层的核心能力是语言理解与生成它决定了系统的能力上限。你让它做数学推理它得真有推理能力你让它读长文档它得真有足够长的上下文窗口。这一层你通常改不动只能选。模型服务层是很多人忽略但最关键的一层。它负责把基础模型包装成一个稳定、可调用、可管理的服务。包括推理加速、并发控制、上下文管理、提示词模板、结果后处理、缓存、限流、监控等等。这一层做得好不好直接决定你的应用是能扛住一百个用户还是只能自己玩。本地部署用 Ollama、llama.cpp云端用各家 API本质上都是在解决这一层的问题。应用层才是业务方真正看到的东西。它负责把用户的需求翻译成对模型的调用再把模型的输出翻译成用户能用的结果。一个智能客服、一个文档助手、一个代码补全工具都是应用层。这一层最贴近业务也最容易被低估——很多人以为调个 API 就完事了其实真正的工程量全在这里。1.3 为什么这个拆法比按技术栈拆更有用市面上讲大模型的文章大多按技术栈拆训练、微调、推理、部署、提示词工程。这种拆法对研究者友好但对做应用的人不友好。因为做应用的人关心的不是“模型怎么训练出来的”而是“我怎么把它用起来”。三层架构的好处在于它把变化的部分和不变的部分分开了。基础模型层变化最慢选型定了基本不动模型服务层变化中等随着流量和需求调整应用层变化最快业务一改就得跟着改。你只要盯住应用层和模型服务层的接口基础模型换了也不影响上层。我见过太多团队把这三层搅在一起结果模型一升级整个应用推倒重来。也见过团队把提示词硬编码在业务代码里改一句话要发一次版。这些都是没拆清楚的代价。2. 基础模型层选型比调优更重要2.1 选模型先看三个硬指标基础模型层的核心工作只有一个选对模型。这一步做错后面全是白费力气。我一般看三个硬指标。第一是上下文窗口。这决定了模型一次能读多少内容。处理合同、论文、长对话窗口不够直接歇菜。现在主流模型动辄 32K、128K但要注意窗口大不代表效果好很多模型在长上下文里会“迷失中间”开头结尾记得住中间全忘。选型时一定要拿真实长文档测。第二是推理能力。这决定了模型能不能做多步思考。简单的分类、抽取、改写小模型就够复杂的逻辑推理、代码生成、数学计算得上大模型。我一般用几个固定难题做横向对比比如多步数学题、带约束的代码题看哪个模型稳定通过。第三是部署成本。这包括显存占用、推理速度、并发能力。一个 70B 的模型效果再好如果一张卡跑不动、响应要十几秒那也没法用在实时场景。中小团队尤其要算这笔账。2.2 开源与闭源怎么选这是被问得最多的问题。我的经验是看数据敏感度和调用量。数据敏感、不能出内网的场景只能选开源模型本地部署。这时候要考虑的是硬件够不够、量化后效果掉多少、推理框架选哪个。数据不敏感、调用量不大的场景直接用闭源 API 更省事省下的运维成本远超那点调用费。但有个中间地带值得注意混合使用。核心敏感数据走本地小模型通用任务走云端大模型。这种架构在模型服务层做路由应用层完全无感。我做过一个项目本地跑一个 7B 模型处理用户隐私信息云端调大模型做创意生成整体成本降了一半效果还没打折。2.3 微调到底该不该做微调是基础模型层里最容易被滥用的操作。很多人一上来就想微调觉得这样才“专业”。但我的观点很明确能用提示词解决的绝不微调能用检索增强解决的绝不微调。微调真正适合的场景只有两类一是风格对齐比如让模型固定用某种语气、某种格式输出二是领域术语比如医疗、法律里的专有表达提示词说不清楚。除此之外大部分需求都能用提示词加检索搞定。而且微调有代价。你需要准备高质量数据集需要显卡需要反复调参还需要在模型升级时重新微调。这些成本加起来往往比多写几行提示词高得多。我见过一个团队花两个月微调模型最后发现效果还不如精心设计的提示词模板。实操心得先花一周把提示词打磨到极致再花一周搭检索增强如果还不满意再考虑微调。这个顺序能帮你省下大量时间和算力。3. 模型服务层把模型变成稳定服务3.1 本地部署的三种主流方式模型服务层的第一件事是把模型跑起来。本地部署目前有三条主流路线各有适用场景。Ollama是最省心的选择。一条命令拉模型一条命令起服务自带 API 接口。适合个人开发、快速验证、小规模使用。缺点是并发能力弱配置选项少生产环境要谨慎。llama.cpp是性能党的选择。它用 C 写的量化支持好CPU 也能跑显存占用低。适合资源受限的环境比如个人电脑、边缘设备。缺点是配置复杂需要自己编译、调参。vLLM是生产环境的首选。它专为高并发设计支持连续批处理、显存优化吞吐量比前两者高一个数量级。适合有 GPU、要扛流量的场景。缺点是部署门槛高对硬件有要求。选哪个取决于你的场景。个人玩Ollama 足够小团队内部用llama.cpp 加个简单封装也行真要上线服务vLLM 是绕不过去的。3.2 提示词模板该放在哪一层这是个架构问题很多人放错地方。我的答案是放在模型服务层不要放在应用层。原因很简单。提示词是模型调用的“参数”不是业务逻辑。如果把它硬编码在应用代码里改一个词就要发版测试、回滚都麻烦。放在服务层可以做成配置随时调整还能做 A/B 测试。具体做法是服务层维护一套提示词模板应用层调用时只传业务参数。比如一个摘要功能应用层传“待摘要文本”和“摘要长度”服务层负责拼装成完整提示词。这样提示词优化和应用迭代就解耦了。3.3 输出后处理为什么必须做模型输出是“生”的直接给用户看往往不行。后处理是模型服务层的核心职责我一般做四件事。格式清洗。模型爱加“好的以下是……”这种废话也爱用 Markdown 但格式乱。后处理要统一去掉前缀、规范格式。结构化解析。如果要求模型输出 JSON它可能给你带一堆解释文字。后处理要提取出真正的 JSON解析失败还要有兜底。敏感内容过滤。这是合规底线。模型可能生成不当内容后处理要过一遍过滤规则。长度截断。模型可能啰嗦后处理要按业务要求截断或摘要。这四件事看起来琐碎但缺一个都会出问题。我见过因为没做 JSON 解析整个功能上线的第一天就崩了。3.4 缓存与限流被低估的稳定性保障模型调用又慢又贵缓存和限流是服务层的两道保险。缓存分两种。一种是结果缓存同样的输入直接返回上次结果。适合问答、翻译这类确定性任务。另一种是语义缓存输入不同但意思相近时复用结果。这个要用向量相似度判断实现复杂但省得多。限流是防止系统被打垮。模型推理是重资源操作并发一高就排队。限流要按用户、按接口、按模型分别设阈值超了就给友好提示而不是让请求堆积到超时。这两件事在 demo 阶段看不出价值一上生产就是救命稻草。4. 应用层所有花样都在这里发生4.1 输入侧怎么把业务需求翻译成模型能懂的输入应用层的第一半工作是输入构造。用户的需求是模糊的模型的输入要求是精确的中间这层翻译就是应用层的价值。最基础的是提示词组装。把系统指令、用户输入、上下文、示例拼成一个完整提示。这里有个技巧把最重要的指令放在开头和结尾因为模型对首尾更敏感。进阶一点是检索增强。用户问的问题模型不知道答案那就先从知识库里检索相关内容塞进提示词里。这就是 RAG 的核心。检索质量直接决定回答质量所以向量化、分块、重排这些环节都要调。再进阶是工具调用。模型自己不会查天气、不会算账但可以告诉它“有个工具能查天气”让它决定什么时候调用。这就是 Agent 的基础。应用层要负责把工具描述清楚把调用结果喂回模型。4.2 输出侧怎么把模型输出变成用户能用的结果应用层的另一半工作是输出处理。模型给的是文本用户要的是结果中间这层转换同样是应用层的价值。最简单的是格式化展示。模型输出 Markdown前端渲染成富文本输出 JSON前端解析成表格。复杂一点的是多轮交互。模型一次回答不完整应用层要判断是否需要追问把历史对话管理好控制上下文长度。再复杂的是结果校验。模型可能胡说应用层要能识别并纠正。比如让模型输出代码应用层要能编译检查让模型输出数据应用层要能验证格式。4.3 一个完整应用层的拆解示例拿一个“制度条例学习助手”举例这是热词里提到的场景。用户上传一份制度文件然后提问助手基于文件回答。输入侧用户上传文件应用层先做文档解析切成小块向量化存进知识库。用户提问时先把问题向量化检索最相关的几块拼进提示词。模型服务层调用模型传入拼好的提示词拿到回答。这里要控制上下文长度不能把整个文件塞进去。输出侧模型回答可能带引用应用层要解析出引用来源展示给用户。还要做敏感词过滤防止模型说出不当内容。这个流程看起来简单但每一步都有坑。文档解析要处理各种格式检索要调相似度阈值提示词要防注入输出要防幻觉。这些细节才是应用层的真正工作量。4.4 应用层的常见架构模式应用层不是铁板一块常见的有几种模式。单轮问答最简单一问一答不记历史。适合工具类场景。多轮对话记历史能追问。适合客服、助手类场景。难点在上下文管理太长要摘要太短会失忆。工作流把任务拆成多步每步调一次模型。适合复杂任务比如先分类、再抽取、再生成。难点在流程编排和错误处理。Agent模型自己决定调什么工具、走什么流程。适合开放式任务。难点在可控性容易跑偏。选哪种取决于业务复杂度。我的建议是从最简单的开始不够用再升级。很多团队一上来就搞 Agent结果发现单轮问答加检索就够了。5. 三层之间的接口设计5.1 应用层与模型服务层的契约这两层之间的接口是整个架构的命脉。设计得好两层可以独立演进设计得差改一处动全身。我一般定三个原则。第一接口只传业务参数不传模型细节。应用层不该知道用的是哪个模型、温度设多少这些是服务层的事。第二输出结构固定。不管底层模型怎么换服务层返回给应用层的结构要稳定比如统一返回{content, references, tokens}。第三错误要分类。模型超时、内容被过滤、参数错误要返回不同的错误码应用层才能分别处理。5.2 模型服务层与基础模型层的适配这两层之间的接口核心是适配器模式。不同模型的调用方式不一样有的用 OpenAI 兼容接口有的用自家 SDK。服务层要封装一层适配器对上提供统一接口对下适配不同模型。这样做的好处是换模型不改上层。今天用 A 模型明天换 B 模型只要适配器改一下应用层完全无感。我做过一个项目从开源模型切到闭源 API只改了几十行适配代码业务代码一行没动。5.3 配置与密钥管理这是容易被忽略但很重要的细节。模型服务的地址、密钥、超时时间都不该硬编码在代码里。要用配置文件或环境变量管理不同环境用不同配置。密钥尤其要注意。不要提交到代码仓库不要打印到日志不要传给前端。我见过因为密钥泄露被刷爆账单的案例教训很深刻。6. 常见问题与排查技巧实录6.1 模型输出不稳定怎么办这是最高频的问题。同样的输入两次输出不一样。原因通常是温度参数太高。温度控制随机性越高越随机。做确定性任务时把温度调到 0 或接近 0。如果调了温度还不稳定可能是提示词有歧义。模型在两种理解之间摇摆。这时候要把提示词写得更明确加上“必须”“只能”这类约束词。还有一种可能是上下文太长。模型在长上下文里注意力分散输出就飘。这时候要精简上下文只留最相关的部分。6.2 响应太慢怎么优化响应慢有三个来源模型推理慢、上下文太长、并发太高。模型推理慢换更小的模型或用量化版本。上下文太长做检索而不是全塞。并发太高加缓存或限流。还有一个容易被忽略的点流式输出。不等模型生成完再返回而是生成一点返回一点。用户感知的等待时间大幅缩短。这个改动很小效果很明显。6.3 模型胡说八道怎么防幻觉是大模型的固有缺陷只能缓解不能根除。我的做法是三道防线。第一道提示词约束。明确告诉模型“不知道就说不知道”“只基于给定材料回答”。第二道检索增强。让模型基于真实材料回答而不是凭记忆。第三道输出校验。对关键信息做交叉验证比如让模型输出引用来源应用层检查来源是否真实存在。这三道防线下来大部分幻觉能挡住。剩下的就要靠人工审核或用户反馈了。6.4 成本失控怎么控成本失控通常是因为没做缓存、没做限流、用了过大的模型。先上缓存同样的请求不重复调模型。再上限流防止异常流量。然后评估模型选型简单任务用小模型复杂任务才用大模型。还有一个技巧批量处理。多个请求合并成一次调用摊薄开销。适合离线任务。6.5 常见问题速查表问题现象可能原因排查方向解决手段输出不稳定温度过高、提示词歧义检查温度参数、审查提示词降温、明确约束响应慢模型大、上下文长、并发高看推理耗时、上下文长度、QPS换小模型、检索替代、加缓存胡说八道幻觉、无依据生成检查是否有检索、提示词是否约束加检索、加校验、加引用成本高无缓存、无限制、模型过大看调用量、缓存命中率加缓存、限流、模型分级格式乱后处理缺失检查输出解析逻辑加格式清洗、结构化解析上下文溢出窗口不够、历史太长看 token 数摘要历史、检索替代、换大窗口模型7. 三层架构的落地建议7.1 小团队怎么起步小团队资源有限不要一上来就搞全套。我的建议是从应用层切入服务层用现成的基础模型层选开源的。应用层先跑通一个最小闭环验证需求真实存在。服务层直接用 Ollama 或云 API别自己造轮子。基础模型层选一个中等规模的够用就行。等业务跑起来再逐步优化服务层加缓存、加限流、加监控。等流量大了再考虑换更强的模型或自建推理集群。7.2 什么时候该拆层三层架构不是一开始就要拆得清清楚楚。早期可以混在一起快速验证。但有几个信号出现时就该拆了。一是模型要换。如果换模型要改业务代码说明没拆干净。二是提示词要频繁调。如果改提示词要发版说明该把提示词挪到服务层。三是多人协作。如果两个人改同一份代码老冲突说明该按层分工了。四是性能出问题。如果分不清是模型慢还是应用慢说明该加监控、该拆层了。7.3 监控该看哪些指标三层架构的监控要分层看。基础模型层看推理耗时、显存占用、吞吐量。模型服务层看调用量、成功率、缓存命中率、限流触发次数。应用层看用户请求量、端到端延迟、错误率、用户反馈。这些指标要能串起来看。用户反馈慢能一路查到是模型慢还是检索慢还是网络慢。没有这套监控出了问题就是盲人摸象。7.4 我踩过的几个坑最后分享几个我实际踩过的坑都是血泪教训。坑一把提示词写死在代码里。改一个词要发版测试回滚都麻烦。后来挪到配置中心效率提升十倍。坑二没做输出解析。模型输出 JSON 带解释文字前端直接崩。后来加了健壮的解析和兜底才稳定下来。坑三没做限流。一次活动流量暴涨模型服务被打垮整个系统雪崩。后来加了限流和降级才扛住。坑四模型选型只看效果不看成本。用最大的模型跑最简单的任务账单吓人。后来做了模型分级简单任务用小模型成本降了七成。坑五没做缓存。同样的请求反复调模型又慢又贵。后来加了结果缓存和语义缓存响应快了一倍。这些坑说到底都是没把三层拆清楚。拆清楚了每个问题都能定位到具体层解决起来就有章法。三层架构不是什么高深理论就是把“模型”“服务”“应用”三件事分开想。分开之后你会发现所有 AI 新花样真的只是在回答两个问题输入什么输出怎么处理。把这两个问题想透剩下的都是工程细节。