1. 大模型三层架构到底在拆什么市面上关于大模型的讨论十篇里有八篇在讲参数规模、榜单排名、又刷新了什么记录。但真正落到工程落地你会发现一个很朴素的事实所有你能看到的新花样本质上都发生在两个地方——输入侧喂了什么输出侧怎么处理。中间那层模型本身反而是最稳定的部分。我把这套逻辑叫做大模型的三层架构。它不是某个官方标准而是我在做 AI 应用开发过程中跟团队反复对齐后沉淀下来的一套认知框架。三层分别是基础模型层、模型服务层、AI 应用层。这三层各管各的事边界清晰出了问题也容易定位。先说说为什么需要这个框架。我见过太多团队一上来就想“搞个大模型”结果把模型选型、推理部署、提示词设计、业务逻辑全搅在一起最后连 bug 出在哪一层都说不清。三层架构的核心价值就是解耦——让每一层只关心自己的职责层与层之间通过明确的接口通信。这三层分别解决什么问题基础模型层解决“模型本身会不会”的问题模型服务层解决“模型能不能稳定、高效地被调用”的问题AI 应用层解决“用户到底要什么”的问题。你去看任何一个能跑起来的 AI 产品不管它包装得多花哨拆开来看都是这三层在协作。提示三层架构不是让你把简单问题复杂化。如果你只是本地跑个 Ollama 玩玩三层可以压缩成一层。但一旦要上生产、要服务多个业务方、要控制成本分层就是刚需。适合谁来参考这套框架我认为三类人最需要一是刚转行做 AI 应用开发的工程师需要一张地图来理解自己站在哪里二是中小团队的技术负责人需要在资源有限的情况下做架构决策三是产品经理需要知道哪些需求是模型能力问题哪些是工程问题。2. 基础模型层选型不是选最强而是选最合适2.1 基础模型层的核心职责与边界基础模型层是整个架构的地基它只干一件事提供从输入文本或图像、音频到输出结果的映射能力。这一层的核心资产就是模型权重本身以及围绕它的一系列训练、微调、对齐的技术栈。很多人把基础模型层和模型服务层混为一谈觉得“我部署了一个模型那部署也是基础模型层的事”。其实不是。基础模型层关心的是“这个模型在给定输入下能产生什么输出”它不关心这个输出怎么被传输、怎么被缓存、怎么被限流。那些是模型服务层的事。基础模型层的关键决策点有三个选哪个基座、要不要微调、微调到什么程度。这三个决策直接决定了你后面两层能玩出什么花样。选错了基座后面提示词工程做得再漂亮也救不回来微调过度模型会丧失通用能力变成一个只会做单一任务的“偏科生”。我个人的经验是基础模型层的选型要遵循“够用就好留有余地”的原则。不要一上来就追求最大参数量的模型因为参数量翻倍带来的推理成本可能是四倍而效果提升可能只有几个百分点。反过来也不要为了省钱选一个明显能力不足的模型后面用工程手段去补往往补不回来。2.2 基座选型的五个关键维度选基座模型我一般从五个维度来评估。这五个维度不是拍脑袋想的是踩过坑之后总结出来的。第一能力匹配度。你的任务到底需要什么能力如果是知识问答那模型的参数化知识储备很重要如果是代码生成那代码训练数据的质量和数量是关键如果是多轮对话那指令遵循能力和上下文保持能力是重点。我见过一个团队用了一个在通用榜单上排名很高的模型去做结构化信息抽取结果效果还不如一个专门优化过的小模型。原因很简单榜单考的是综合能力你的任务可能只依赖其中某一项。第二推理成本。这个成本包括显存占用、推理延迟、吞吐量三个子项。显存占用决定了你能在什么硬件上跑推理延迟决定了用户体验吞吐量决定了你的服务能承载多少并发。这三个指标往往是互相矛盾的——想要低延迟可能就得牺牲吞吐量想要高吞吐可能就得接受更高的延迟。你需要根据业务场景来权衡。第三上下文窗口。上下文窗口决定了模型一次能“看到”多少信息。做长文档分析、多轮复杂对话、代码库理解都需要大上下文窗口。但要注意上下文窗口大不等于模型真的能有效利用那么长的上下文。很多模型标称支持 128K实际在超过 32K 之后效果就明显下降。这个需要实测。第四微调友好度。如果你有微调需求那基座模型是否支持 LoRA、QLoRA 等高效微调方法是否有成熟的微调工具链社区有没有现成的微调脚本这些都很重要。有些模型架构特殊微调起来坑特别多会浪费大量时间。第五生态与许可。模型的许可证是否允许商用社区是否活跃遇到问题能不能找到答案这些看似不重要实际影响很大。我吃过亏选了一个小众模型结果遇到问题连个讨论的地方都没有最后只能自己啃源码。下面这张表是我在实际选型时常用的对比框架你可以直接拿去用评估维度关键问题评估方法权重建议能力匹配度模型在目标任务上的表现如何构建 50-100 条测试用例实测30%推理成本显存、延迟、吞吐是否可接受压测工具实测25%上下文窗口有效上下文长度是多少长文本任务实测15%微调友好度是否支持高效微调查文档、跑通微调脚本15%生态与许可能否商用、社区是否活跃查许可证、看社区活跃度15%2.3 微调什么时候该做什么时候不该做微调是大模型落地绕不开的话题。但我发现很多团队对微调有误解觉得“模型效果不好就微调”。其实微调不是万能药它解决的是特定类型的问题。该微调的场景你需要模型稳定输出某种特定格式比如固定的 JSON 结构你需要模型掌握某个垂直领域的术语和表达习惯比如医疗病历、法律文书你需要模型遵循一套复杂的业务规则而这些规则很难用提示词完整描述。不该微调的场景你只是想让模型知道一些新知识这种情况用 RAG检索增强生成更合适你只是想让模型输出更符合某种风格这种情况用提示词工程往往就够了你的训练数据少于几百条这种情况微调很容易过拟合。我个人的经验法则是先用提示词工程再用 RAG最后才考虑微调。这个顺序不能反。因为提示词工程和 RAG 的迭代成本远低于微调而且可解释性更强。微调是一个“黑盒”操作你很难精确控制模型学到了什么、没学到什么。如果决定要微调数据质量比数据数量重要得多。我做过对比实验500 条高质量、多样化的微调数据效果明显好于 5000 条低质量、重复的数据。数据清洗和构造的时间往往比训练本身还长。注意微调后的模型会“遗忘”一些通用能力。如果你微调后还需要模型处理通用任务要么保留一个基座模型做路由要么在微调数据里混入一定比例的通用数据。2.4 基础模型层的常见误区第一个误区是盲目追新。新模型发布就换结果每次换模型都要重新调提示词、重新做评测团队疲于奔命。我的建议是除非新模型在你的核心指标上有显著提升否则不要轻易换基座。第二个误区是忽视推理成本。选型时只看效果不看成本上线后发现推理成本远超预算。我建议在选型阶段就把成本算清楚包括硬件成本、电费、运维人力。第三个误区是微调数据泄露。把测试集的数据混进了训练集导致评测结果虚高上线后效果暴跌。这个坑很隐蔽一定要在数据划分阶段就做好隔离。3. 模型服务层让模型稳定高效地被调用3.1 模型服务层的核心职责模型服务层是夹在基础模型层和 AI 应用层之间的“中间件”。它的核心职责是把基础模型层的能力包装成稳定、高效、可管理的服务接口。这一层解决的问题包括模型加载和卸载、请求排队和调度、批处理优化、缓存、限流、降级、监控、多模型路由。听起来很杂但核心目标只有一个让上层应用不用关心模型怎么跑只管调用接口就行。我见过很多团队跳过这一层直接在应用代码里加载模型、调用推理。小规模玩玩可以一旦要服务多个业务方、要控制成本、要保证稳定性这种做法的弊端就暴露了模型加载重复占用显存、没有统一的限流导致某个业务方把资源打满、没有监控导致出问题不知道。模型服务层的价值在业务量小的时候不明显业务量一大就体现出来了。它就像餐厅的后厨管理系统——单个厨师炒菜不需要系统但十个厨师同时炒菜没有系统就会乱套。3.2 推理引擎选型vLLM、TGI 还是 Ollama推理引擎是模型服务层的核心组件。目前主流的几个选择各有适用场景。vLLM是目前生产环境用得最多的推理引擎之一。它的核心优势是 PagedAttention 技术能显著提升显存利用率和吞吐量。如果你要部署一个需要服务多并发的模型vLLM 基本是首选。它的缺点是配置相对复杂对硬件有一定要求。TGIText Generation Inference是 HuggingFace 推出的推理引擎跟 HuggingFace 生态集成得很好。如果你用的是 HuggingFace 上的模型TGI 的部署体验会很顺畅。它的批处理调度和流式输出做得不错。Ollama是本地部署的轻量级选择安装简单一条命令就能跑起来。适合个人开发者做原型验证、本地测试。但它的并发能力和吞吐量有限不适合生产环境的高并发场景。选哪个取决于你的场景。我的一般建议是本地开发用 Ollama生产部署用 vLLMHuggingFace 重度用户可以考虑 TGI。推理引擎适用场景优势局限vLLM生产环境高并发吞吐量高、显存利用率好配置复杂、硬件要求高TGIHuggingFace 生态集成顺畅、流式输出好对非 HF 模型支持一般Ollama本地开发原型安装简单、上手快并发能力有限3.3 批处理与调度吞吐量和延迟的平衡术批处理是模型服务层最核心的优化手段。原理很简单把多个请求打包成一个批次一起推理能显著提升 GPU 利用率。但批处理会带来延迟——一个请求要等同一批次的其他请求都准备好才能开始推理。这里就有一个经典的权衡批处理越大吞吐量越高但延迟也越高。怎么平衡我的经验是根据业务场景来定。如果是离线任务比如批量处理文档那批处理越大越好延迟不重要。如果是在线对话用户等着回复那延迟就很重要批处理要小甚至要做连续批处理continuous batching让新请求能插入到正在进行的批次中。vLLM 的连续批处理做得很好它能在推理过程中动态加入新请求不用等当前批次全部完成。这个特性对在线服务非常关键。还有一个技巧是优先级队列。把请求分成高优先级和低优先级高优先级请求优先处理。比如付费用户和免费用户就可以用不同的队列。3.4 缓存策略省钱又提速的利器缓存是模型服务层另一个重要的优化手段。大模型推理很贵如果同一个请求重复来没必要每次都重新推理。缓存分两种精确缓存和语义缓存。精确缓存就是请求内容完全一样才命中实现简单用 Redis 就行。语义缓存是请求内容语义相似就命中需要用一个嵌入模型来计算相似度实现复杂但命中率更高。我一般建议先上精确缓存因为实现简单、效果确定。语义缓存虽然命中率高但有误判风险——两个语义相似但实际需要不同回答的请求如果被判定为同一个就会返回错误结果。缓存的 key 怎么设计我一般用“模型名 提示词 关键参数”的哈希值。注意要把温度、top_p 这些影响输出的参数也纳入 key否则不同参数下的请求会互相污染。提示缓存要注意过期策略。模型更新后旧缓存可能不再适用需要主动失效。我一般会在模型版本号变化时清空相关缓存。3.5 限流、降级与监控限流是保护模型服务不被压垮的手段。我一般从三个维度限流请求频率、并发数、token 消耗量。请求频率限制单位时间内的请求数并发数限制同时处理的请求数token 消耗量限制单位时间内的 token 使用量。三个维度结合能比较全面地控制资源消耗。降级是服务出问题时的兜底策略。比如模型服务响应超时可以降级到一个更小的模型或者返回一个预设的兜底回答。降级策略要提前设计好不能等出问题了再想。监控是模型服务层的“眼睛”。需要监控的指标包括请求量、延迟分布、错误率、GPU 利用率、显存占用、队列长度。这些指标能帮你快速定位问题。我一般会用 Prometheus Grafana 搭一套监控面板出问题一眼就能看出来。4. AI 应用层所有新花样都在这里发生4.1 应用层的本质输入工程与输出工程回到标题那句话所有 AI 新花样只在“输入什么 / 输出怎么处理”。这句话在应用层体现得最明显。你去看市面上所有的 AI 应用拆开来看核心逻辑都是构造输入 → 调用模型 → 处理输出。所谓的新花样无非是在这三个环节上做文章。输入侧的花样包括提示词工程、上下文工程、RAG、少样本示例、思维链、角色设定。输出侧的花样包括结构化输出解析、多轮迭代、结果校验、格式转换、后处理。中间调用模型的部分反而是最标准的。这就是为什么我说基础模型层和模型服务层是“稳定层”应用层是“变化层”。模型本身的能力在短期内不会有大变化但应用层的玩法可以千变万化。4.2 输入工程提示词、上下文与 RAG输入工程是应用层最核心的技能。我把它分成三个层次提示词工程、上下文工程、知识工程。提示词工程是最基础的解决的是“怎么把任务描述清楚”。核心原则是明确角色、明确任务、明确输出格式、给出示例。我见过太多提示词写得含糊不清然后怪模型不聪明。其实很多时候是输入没写好。上下文工程是进阶解决的是“怎么把相关信息有效地组织给模型”。这包括多轮对话历史的管理、相关文档的注入、工具调用结果的整合。上下文工程的关键是信息密度——在有限的上下文窗口里放最有用的信息。知识工程是最高层解决的是“怎么让模型获得它不知道的知识”。RAG 是知识工程的主要手段。RAG 的核心流程是文档切分 → 向量化 → 检索 → 注入上下文。每个环节都有讲究切分粒度、嵌入模型选择、检索策略、重排序都会影响最终效果。我个人的经验是RAG 的效果 80% 取决于检索质量20% 取决于生成质量。很多人把精力花在调提示词上却忽视了检索环节的优化。其实如果检索出来的内容不相关提示词写得再好也没用。4.3 输出工程解析、校验与迭代输出工程是应用层另一个关键环节。模型输出的原始文本往往不能直接用需要经过解析、校验、格式化。结构化输出是最常见的需求。让模型输出 JSON然后解析成程序能用的数据结构。但模型输出的 JSON 经常有格式问题——多了个逗号、少了引号、字段名不对。这时候需要做容错解析或者用支持结构化输出的模型接口。结果校验是保证输出质量的手段。比如模型输出的答案可以用规则校验、用另一个模型校验、或者用外部工具校验。校验不通过就重试或降级。多轮迭代是提升输出质量的方法。让模型先输出一版然后自我批评、自我改进迭代几轮。这个方法在代码生成、文案写作等场景效果不错但会增加推理成本。注意输出工程要考虑异常情况。模型可能输出空结果、输出超长结果、输出不符合格式的结果。这些都要有对应的处理逻辑不能假设模型总是输出正确。4.4 智能体应用层的新范式智能体Agent是最近应用层最热的方向。它的核心思想是让模型不只是回答问题而是能规划任务、调用工具、执行动作。智能体的基本循环是观察 → 思考 → 行动 → 观察。模型根据当前状态决定下一步做什么调用相应的工具然后根据工具返回的结果继续决策直到任务完成。智能体的关键组件包括规划能力、工具调用、记忆管理。规划能力决定模型能不能把复杂任务拆解成子任务工具调用决定模型能不能与外部世界交互记忆管理决定模型能不能记住之前的操作和结果。我做过几个智能体项目最大的体会是智能体的效果高度依赖工具的设计。工具的描述要清晰参数要明确返回结果要结构化。工具设计得好模型调用得就准工具设计得差模型就会乱调。另一个体会是智能体需要设置终止条件。否则模型可能陷入无限循环一直调用工具不停止。我一般会设置最大步数限制超过就强制终止。4.5 应用层的评测与迭代应用层做得好不好不能靠感觉要靠评测。我一般会建一个评测集包含各种典型场景和边界情况每次改动后跑一遍看指标变化。评测指标分两类自动指标和人工指标。自动指标包括准确率、召回率、格式合规率等能快速跑。人工指标包括有用性、流畅度、安全性等需要人工标注。两者结合才能全面评估。迭代的节奏也很重要。我一般会小步快跑每次只改一个变量然后看评测结果。如果一次改多个地方出了问题不知道是哪个改动导致的。5. 三层之间的协作与边界5.1 层与层之间的接口设计三层架构能不能落地关键看层与层之间的接口设计得好不好。接口设计得好每层可以独立演进接口设计得差改一层就要动全身。基础模型层和模型服务层之间的接口我一般定义为模型标识 输入 推理参数。模型服务层根据模型标识加载对应的模型根据推理参数执行推理。这个接口要稳定不要频繁变动。模型服务层和应用层之间的接口我一般定义为标准化的推理 API。应用层不需要知道底层用的是哪个模型、哪个推理引擎只需要调用统一的 API。这样应用层可以方便地切换模型做 A/B 测试。接口设计的一个原则是面向能力而不是面向实现。比如应用层需要的是“文本生成能力”而不是“调用某个具体模型”。这样底层换模型应用层不用改。5.2 常见架构反模式我见过几种常见的架构反模式这里列出来供大家避坑。反模式一应用层直接调基础模型。跳过了模型服务层导致模型加载重复、资源浪费、无法统一管理。小规模可以大规模必出问题。反模式二模型服务层承担业务逻辑。把业务规则写进了模型服务层导致模型服务层变得臃肿无法复用。模型服务层应该只关心推理不关心业务。反模式三基础模型层频繁变动。今天换这个模型明天换那个模型导致上层应用疲于适配。基础模型层应该相对稳定换模型要有充分的评测和灰度。反模式四忽视评测。没有评测集改动靠感觉效果好坏不知道。评测是迭代的基础没有评测就没有迭代。5.3 中小团队的三层架构落地建议中小团队资源有限不可能像大厂那样每层都做得很重。我的建议是基础模型层用现成的开源模型模型服务层用成熟的推理引擎应用层重点投入。基础模型层除非你有非常特殊的领域需求否则不建议自己从头训练。用开源模型 微调性价比最高。模型服务层直接用 vLLM 或 TGI不要自己造轮子。这些引擎已经经过大量生产验证自己造轮子大概率不如它们。应用层这是中小团队最能做出差异化的地方。因为应用层离用户最近对业务理解最深。把精力花在应用层的输入工程和输出工程上投入产出比最高。提示中小团队不要追求“全栈自研”。大模型这个领域分工已经很细了用好现成的工具和模型把精力集中在自己的核心价值上才是明智之举。6. 实操中的常见问题与排查6.1 模型输出不稳定的排查思路模型输出不稳定是应用层最常见的问题。同样的输入有时候输出好有时候输出差。排查思路如下第一步检查温度参数。温度越高输出越随机。如果温度设得太高输出不稳定是正常的。把温度调低看是否改善。第二步检查提示词。提示词是否有歧义是否缺少必要的约束是否示例不够清晰提示词的问题往往表现为输出不稳定。第三步检查上下文。上下文是否太长导致模型“迷失”上下文里是否有矛盾信息上下文窗口是否超限第四步检查模型本身。有些模型在某些任务上就是不稳定这是模型能力问题不是工程问题。这时候要考虑换模型或微调。6.2 推理性能问题的排查推理性能问题表现为延迟高、吞吐低。排查思路如下延迟高检查批处理大小是否过大检查是否开启了连续批处理检查 GPU 利用率是否饱和检查是否有不必要的同步操作。吞吐低检查批处理大小是否过小检查是否有请求排队检查显存是否不足导致频繁换入换出检查是否有 CPU 瓶颈。我一般会用 profiling 工具定位瓶颈。如果是 GPU 瓶颈看是计算瓶颈还是显存瓶颈如果是 CPU 瓶颈看是数据预处理还是后处理。6.3 成本控制的实操技巧大模型推理成本是很多团队的头疼问题。我总结几个实操技巧技巧一分级服务。不同请求用不同大小的模型。简单请求用小模型复杂请求用大模型。可以用一个分类器来判断请求复杂度。技巧二缓存复用。前面讲过的精确缓存和语义缓存能显著降低重复请求的成本。技巧三批处理。离线任务尽量用大批处理提升 GPU 利用率。技巧四量化。用 INT8 或 INT4 量化能显著降低显存占用和推理成本但会损失一些精度。需要评测后再决定是否使用。技巧五按需加载。不常用的模型不要常驻显存按需加载用完卸载。下面这张表是我整理的常见问题速查表问题现象可能原因排查方法解决方案输出不稳定温度过高、提示词歧义调低温度、检查提示词优化提示词、降低温度延迟高批处理过大、GPU 饱和profiling 定位瓶颈调小批处理、升级硬件吞吐低批处理过小、请求排队检查队列长度增大批处理、增加实例成本高模型过大、无缓存分析请求分布分级服务、加缓存格式错误模型不遵循格式检查输出解析逻辑用结构化输出、加校验6.4 几个我踩过的坑坑一忽视 token 计数。上线后才发现 token 消耗远超预期成本失控。后来在应用层加了 token 计数和预算控制才解决。坑二上下文窗口超限。多轮对话聊久了上下文超限模型报错。后来加了上下文截断和摘要机制。坑三模型版本升级导致效果下降。模型服务层自动升级了模型版本结果应用层效果下降。后来锁定了模型版本升级要走评测流程。坑四缓存污染。不同用户的请求命中了同一个缓存导致数据泄露。后来在缓存 key 里加了用户标识。这些坑说到底都是因为对三层架构的边界理解不清。把每层的职责划清楚很多问题在设计阶段就能避免。7. 三层架构的演进与扩展三层架构不是一成不变的。随着业务发展每层都可能需要扩展。基础模型层可能从单一模型扩展为多模型包括不同大小的模型、不同能力的模型、不同领域的模型。这时候需要一个模型路由层来决定请求走哪个模型。模型服务层可能从单实例扩展为多实例集群需要服务发现、负载均衡、故障转移。这时候模型服务层就演变成了一个微服务架构。应用层可能从单一应用扩展为多个应用共享底层的模型服务。这时候需要一个应用网关来管理不同应用的接入。但不管怎么扩展核心的分层逻辑不变基础模型层管能力模型服务层管效率应用层管体验。只要这个边界清晰扩展就不会乱。我个人的体会是三层架构最大的价值不是技术上的而是认知上的。它让你在面对一个新需求时能快速判断这个需求应该在哪一层解决。是模型能力不够那就去基础模型层想办法。是服务不稳定那就去模型服务层优化。是用户体验不好那就在应用层做文章。这种清晰的定位能省下大量试错时间。最后分享一个小技巧如果你不确定一个问题该在哪一层解决就问自己——这个问题换个模型能解决吗能就是基础模型层的问题。这个问题换个推理引擎能解决吗能就是模型服务层的问题。这个问题换个提示词能解决吗能就是应用层的问题。这个简单的判断方法我在实际工作中用了很多次基本都能快速定位。