1. 先想清楚AI技术栈为什么需要五层结构这几年AI领域的爆发式发展有目共睹从大模型刷榜到各类AI应用落地行业里几乎每天都有新东西冒出来。但我在实际带项目、做技术选型的时候发现一个很尴尬的问题很多团队和个人开发者手里工具一堆、模型一堆真正要搭一个能上线、能迭代、能赚钱的AI应用时却不知道从哪里下手。AI五层结构这个概念算是我在多次项目复盘后总结出的一套技术栈分层方法。它不是某个官方标准而是把AI应用从底层到顶层拆成五个层次算力基础设施层、模型与算法层、框架与工具链层、应用与交互层、业务与产品层。每一层干每一层的活层与层之间通过标准接口衔接上层不关心下层的实现细节下层不为上层的业务逻辑买单。为什么要做这种分层有一个特别直观的类比你去盖一栋楼不可能把钢筋、水泥、水管、电线、家具全部混在一起浇筑。你一定是先打地基再搭框架然后走管线再装修最后摆家具。每一道工序有明确的交付标准和验收条件出了问题也能精准定位到是哪个环节的责任。AI技术栈其实也一样模型选型出问题你不需要去翻代码应用层逻辑出问题你也不必重新训练模型。这篇文章我会把这五层结构逐一拆开讲包括每一层具体包含什么、选型时怎么思考、我在实操中踩过哪些坑以及每一层目前主流的工具和方案是什么。如果你正在规划一个AI项目或者想把现在混乱的AI代码库重新整理一遍这篇文章应该能给你一个比较完整的参考框架。2. 第一层算力基础设施——整个体系的地基2.1 这一层到底在解决什么问题算力基础设施层是整个AI技术栈最底下的部分包含GPU/CPU服务器、云资源、存储、网络带宽以及底层的运行环境比如CUDA、Docker、Kubernetes等。没有这一层上面的一切都是空中楼阁。很多人会忽视这一层的重要性觉得不就是买台服务器嘛。但实际上AI项目的算力基础设施决策往往会影响到后续几个月甚至几年的开发效率和成本结构。举几个我在实际项目中遇到的问题一是显存不够。训练或者部署一个大模型时模型权重、中间激活值、优化器状态全都要吃显存。比如一个7B参数的模型FP16精度下光权重就是14GB再加上推理时的KV Cache、临时张量一张24GB的消费级显卡跑起来非常勉强。这还只是推理如果要微调激活值和梯度会成倍增加。二是I/O瓶颈。很多人只盯着GPU的算力忽略了数据读取和模型加载的I/O速度。实测下来如果从机械硬盘加载一个13B的模型文件光等模型载入就要好几分钟而如果用NVMe固态并配好内存缓存十几秒就能搞定。三是弹性扩缩容。业务量是有波峰波谷的白天用户多、晚上用户少。如果用的是固定物理机要么在高峰时性能不够要么在低峰时白白浪费算力。用容器化加自动伸缩可以省下不少成本但这也要求底层基础设施足够标准化。2.2 算力选型云上还是自建算力选型主要看三个方面预算、规模、以及对数据隐私的要求。对于个人开发者或者小团队我建议优先考虑云GPU方案。目前主流云厂商都提供了按小时甚至按秒计费的GPU实例比如腾讯云、阿里云、AutoDL等都有比较灵活的方案。以我常用的配置为例单卡A100 80G或者H800跑13B以下的开源模型推理完全够用部署成本相比自建物理机要低很多。对于数据敏感或长期大规模训练的场景自建机房或托管IDC更划算。这里有一个简单的计算思路如果一台8卡A100服务器的年租赁费用高于三年总折旧加电费运维成本并且你的GPU利用率能稳定在60%以上那自建物理机更划算反之用云节点更灵活。模型推理的显存计算公式可以提前记一下显存需求 ≈ 模型参数量 × 每参数字节数 × 系数其中FP16精度时每参数2字节INT8量化后每参数1字节INT4量化后每参数0.5字节。系数通常在1.2~1.5之间用于覆盖KV Cache、临时计算图和框架开销。比如一个7B参数的模型FP16部署最低显存约 7×2×1.2 16.8GB考虑到实际运行余量建议用24GB以上的卡。我在实际项目里还有一个心得如果只是做推理部署优先考虑量化后的模型。用GPTQ或AWQ量化到INT47B模型显存占用能压到5~6GB推理速度反而因为显存带宽瓶颈降低而有所提升。很多开源模型在INT4量化下的精度损失不到1%对业务影响几乎可以忽略。2.3 部署环境容器化是底线不管你用云还是自建我都强烈建议从第一天开始就用Docker容器化部署。AI项目的环境依赖太复杂了Python版本、CUDA版本、cuDNN版本、PyTorch版本任何一个不匹配都可能跑不起来。容器化之后你可以把一套验证过的环境完整打包换机器部署时直接拉起不再重演在我电脑上是好的这种尴尬。更进一步的方案是Kubernetes集群管理。当你有多个模型服务、需要自动扩缩容或者做灰度发布时K8s的价值会非常明显。但要注意K8s的学习和维护成本不低如果项目规模不大用Docker Compose配合简单的负载均衡就足够了不必一上来就上K8s。3. 第二层模型与算法——技术栈的发动机3.1 模型选型的核心逻辑模型层是整个AI技术栈中最核心的部分也是目前行业变化最快的一层。GPT、Claude、Gemini等闭源模型持续迭代Llama、Qwen、DeepSeek、GLM等开源模型也在快速跟进。选模型不是越强越好而是越合适越好。我一般会从这几个维度来评估模型选型任务类型是文本生成、代码补全、对话问答、多模态理解还是Agent规划不同模型在不同任务上的表现差异很大。参数量级和资源约束7B、13B、70B还是更大这直接决定你需要多少算力资源。响应延迟要求实时的Agent交互可能需要低于1.5秒的响应这要求模型推理速度足够快量化或小模型往往是更好的选择。数据安全和隐私要求如果你的业务数据不允许出域就只能选择可以私有化部署的开源模型。成本模型按Token计费的闭源API在频繁调用场景下成本积累很快开源模型自部署前期投入高但边际成本低。我在实际项目中的默认选择是优先用国内的开源模型比如Qwen系列的72B版本或者DeepSeek系模型。原因无他——中文能力强、上下文够长、社区生态活跃关键是私有化部署没有合规和成本顾虑。如果业务对英文生成有更高要求再考虑引入Llama系列或者直接调闭源API。3.2 微调、RAG还是Prompt Engineering确定模型之后紧接着的问题就是怎么让它适配自己的业务目前主流的路径有三条微调Fine-tuning、检索增强生成RAG、以及提示词工程Prompt Engineering。这三条路线不是互斥的而是可以组合使用。对于大多数业务场景我建议先做好提示词工程和RAG。原因很现实微调需要高质量、大规模的领域数据还要投入GPU训练资源和运维精力做不好还可能让模型出现灾难性遗忘。而RAG的思路是模型负责生成检索负责知识把最新、最准确的业务知识放到向量数据库里用户提问时先检索出相关内容再把内容拼进上下文里交给模型生成答案。我做过一个企业知识库问答系统初始版本就是纯提示词工程加RAG。我们把几千篇企业制度文档切分、向量化后存入向量数据库查询时召回TopK相关片段再配合提示词模板让模型基于检索结果回答。这个方案上线后准确率在90%以上而且文档更新时只需要重新入库不需要动模型维护成本非常低。那什么时候才应该做微调呢我总结下来是三类场景一是模型的输出格式有强约束需求比如必须输出特定JSON结构二是模型需要掌握专属的术语体系和逻辑规则比如医疗诊断、法律条文三是业务数据量足够大且标注质量可控。如果这三条都不满足微调大概率不是最优解。3.3 模型评估——很多团队欠下的债模型层最容易忽略的是评估环节。很多团队把模型接进来、跑通demo就上线了结果到真实场景中就各种翻车。我建议在项目一开始就建立一套评估集和评估标准用一组固定的测试问题来度量模型每次迭代的效果。评估维度可以参考这几个方面回答准确率是否正确、相关性是否回答了用户的提问、完整性是否遗漏关键信息、格式合规性JSON输出是否能被直接解析、目标指令跟随度。每个维度按1~5分打分多个测试样本取平均值。迭代模型版本时用同一批测试集跑分对比选型就有据可依了。4. 第三层框架与工具链——连接模型和应用的高速公路4.1 从裸调API到Agent框架模型层之上是框架与工具链层。早期开发AI应用说白了就是用HTTP请求调API把用户输入拼进Prompt拿到输出再拼回界面。这种做法在简单的问答场景下够用但随着应用复杂度提升尤其是引入Agent、多步骤规划、外部工具调用等场景后纯手写代码的效率就太低了。这里就轮到各种框架出场了。目前比较主流的有LangChain、LlamaIndex、Spring AI、AutoGen、Dify等各有各的侧重点LangChain老牌Agent编排框架组件生态丰富适合复杂的链路设计和工具调用。但抽象层级多调试起来需要耐心。LlamaIndex更侧重于数据连接和RAG流程处理文档索引、检索、重排等环节非常顺手。Spring AI如果你是Java技术栈这个框架值得关注。它是Spring生态官方的AI接入方案抽象了一套对接大模型的统一接口对Java开发者非常友好。我在一个企业内部工具项目里用它对接了大模型API原本要写很多胶水代码用Spring AI后代码量缩减了一半以上。Dify开源的应用开发平台可视化编排工作流适合快速做产品MVP也支持接入私有模型。AutoGen微软出品的多Agent对话框架适合Agent之间协作、互相交流来完成任务。框架选型我有一条经验和大家分享不要迷信框架框架是工具不是目的。如果你的场景只是单轮问答加简单检索直接用HTTP请求调用API代码反而更清爽如果需要复杂的Agent规划和多工具协同再引入框架不迟。4.2 RAG链路的核心组件RAG链路是当前AI应用的主流范式其核心组件我梳理一下文档解析和清洗把PDF、Word、HTML等格式的文档解析成纯文本去除页眉页脚、目录、水印等噪音。这一步最容易被低估但实际效果影响很大垃圾进垃圾出。切分策略文档切分长度和重叠度直接影响召回效果。我常用的经验值是按512~1024个Token切分切分之间保留64~128个Token的重叠避免语义被打断。向量化Embedding模型把文本转换成向量用的时候计算余弦相似度。国产方案推荐BGE-M3多语言效果好对中文特别友好而且支持长文档。向量数据库用于存储和检索向量。可选方案有Milvus、Qdrant、Chroma、pgvector等。数据量不大百万级向量以内用pgvector就好可以复用PostgreSQL数据量大再考虑Milvus或Qdrant。重排序初次召回Top50再通过重排序模型比如BGE-Reranker精排到Top5-10可以明显提升问答质量。4.3 代码生成与AI编程工具模型层和框架层之外还有一个容易被忽略的工具层角色——AI编程工具。从热词里可以看出AI编程AI编程工具AI coding关键词热度非常高。这一层本质上是利用大模型的能力辅助人类开发。目前我用得比较多的是GitHub Copilot、Cursor以及Qwen Code系列的本地代码模型。实测下来AI编程工具在以下几类场景中提升效率非常明显写单元测试和常规CRUD代码、根据注释生成函数实现、正则表达式和脚本编写、SQL查询生成等。但AI编程也有明显的坑AI生成的代码看似正确实则可能存在边界条件遗漏或逻辑漏洞。我的习惯是AI生成的代码必须经过Code Review和现有测试用例验证才能合入主分支。尤其是涉及资金、数据安全等核心逻辑时绝不能直接信任AI输出。5. 第四层应用与交互——从模型能力到用户价值5.1 AI应用的产品形态分类上面三层解决的是模型怎么跑起来的问题到了应用与交互层关心的是模型怎么被用户用起来。目前的AI应用产品形态大概可以分成几类对话式应用ChatBot、Agent应用自主完成多步任务、内容生成工具AI绘画、AI漫剧、AI短剧、AI视频、辅助创作工具AI写作、降AI率工具、嵌入式AI功能页面上的智能搜索、智能客服。对话式应用是目前最主流也最好上手的形态。核心是管理好对话上下文、系统提示词和用户消息的区分。我做一个企业客服机器人的时候在提示词里固定了角色设定、回答风格、可参考的知识库引导和兜底话术实测下来用户满意度提升了30%以上。Agent应用的区别在于它会主动规划和执行任务比如帮我查一下这个行业近三年的市场规模并写一份分析报告。实现方式可以用ReAct模式或Plan-and-Execute模式模型先生成行动计划再逐步执行工具调用。也可以直接用Coze、Dify等平台的可视化Agent编排降低开发门槛。5.2 交互设计中的AI特有注意事项AI应用的交互设计和传统软件有不少差异。我这几年总结出几条经验一是响应速度的体验设计。大模型推理在顶尖GPU上也要几百毫秒甚至几秒不能像普通API请求那样等结果回来再显示。实践中常用流式输出流式输出让用户看到文字一个字一个字地生成配合正在思考的动效体验会好很多。实测下来同样2秒的响应时间有流式输出方案的用户跳出率远低于无流式方案。二是上下文长度的管理。大模型的上下文窗口是有限的常见的从8K到256K不等而且上下文越长推理延迟和费用越高。为了避免聊着聊着就忘了前面说过什么需要自己做上下文管理截断早期对话、用摘要压缩历史、或者只保留与当前轮次相关的片段。三是无限制条件下的边界约束。从热词中可以看到无限制AI无审核AI这类词搜索量很大但我要提醒大家这里说的限制应该是产品定位层面的差异化而不是突破价值观和合规底线。在真实的AI应用设计中内容安全始终是底线过滤机制和系统提示词约束必不可少。任何一个有责任感的开发者在做AI产品时都应该把这个问题放在最优先的位置考虑。5.3 AI应用的后端架构AI应用的后端架构相比传统后端多了一个核心代理层用户请求先到达业务服务业务服务再调用模型服务并管理上下文。我常用的架构模式是接入层API网关负责鉴权、限流、日志记录。业务服务层处理具体业务逻辑、会话管理、用户状态。AI编排层调用模型API、管理提示词模板、执行RAG检索、编排Agent流程。模型服务层可能是外部API也可能是自部署的推理服务。数据层业务数据库、向量数据库、缓存Redis。这样分层的好处是每层可以独立扩展模型服务访问量大了就多起几个实例编排层状态多了可以做水平扩容接入层的限流也可以在模型服务过载时保护系统。6. 第五层业务与产品——技术价值的最终出口6.1 商业模式设计模型能力再强最后还是要落到业务层面回答一个问题这个AI应用凭什么让用户付费目前主流的商业模式有这几种按订阅收费按月或按年、按使用量收费按Token或按调用次数、按服务收费定制化交付、以及按分成模式嵌入到实际业务场景比如电商AI导购按转化成交提成。一个比较现实的经验是纯模型API转卖的模式利润空间非常薄因为上游模型API定价随时可能降。真正有定价权的是在你自己的业务场景中利用AI创造了明确增量价值的场景。举个例子做AI客服系统用户愿意付费不是因为客服接入了大模型而是因为人工客服的人力成本降了50%。AI是手段降本是效果用户为效果付费。6.2 测试与质量保障AI应用的测试比传统软件要多一个维度——不仅要测功能正确性还要测模型的输出质量。我在实际项目中推行的做法是单元测试和集成测试照常做覆盖率不低于70%。增加模型输出质量测试用一组固定的测试用例跑提示词模板断言输出包含预期关键词、输出JSON格式可解析。上线前进行回归测试模型升级后用历史问题集回归验证确保能力没有回退。建立用户反馈闭环在页面上提供回答是否有帮助的反馈按钮数据回流后定期分析和优化。6.3 运维与监控AI应用上生产后的运维比传统服务复杂主要体现在两处一是模型服务的可观测性。除了常规的CPU、内存、延迟、QPS还要关注Token消耗、缓存命中率、上下文长度分布、模型回复长度等AI特有指标。这些数据对成本控制和效果优化至关重要。二是数据管线稳定性。RAG链路中文档更新、向量化入库等流程如果出了问题用户端看到的问答质量会悄然下降。需要建立数据管道监控定时检查向量库中的文档数量和数据新鲜度。7. 常见问题与避坑实录7.1 模型部署阶段的坑问题一模型在本地测试没问题部署到服务器后速度慢得离谱。排查思路先看是不是没有用GPU推理检查CUDA是否可用再看是否开启了量化最后看是不是有并发请求排队。问题二多实例部署时经常OOM内存溢出。排查思路检查显存是否真的够用如果不够考虑换小模型或降低并发数。另外模型推理框架如vLLM的显存使用优化比原生PyTorch要好很多切换到vLLM后同等显存下能支撑的并发可以提升好几倍。问题三微调后的模型在开放域对话上变笨了。排查思路大概率是灾难性遗忘。解决方案是微调时混合一部分通用语料或者降低学习率一般建议微调学习率不超过2e-5又或者减少微调步数。7.2 RAG链路的坑问题一检索到的文档明明相关模型却回答得不好。排查思路很可能是切分方式破坏了语义导致关键信息被截断。建议尝试按段落和标题结构切分而非固定长度切分。问题二检索召回率低。排查思路尝试混合检索策略把向量检索和关键词检索结合用重排序模型重新打分后再决定最终给模型的上下文。问题三文档更新了但问答结果没变化。排查思路检查向量化入库流程是否成功执行向量数据库中的旧数据是否被清理。很多团队在文档入库的增量同步上踩过坑。7.3 Agent编排的坑问题一Agent规划任务时陷入死循环。排查思路需要设置最大迭代次数比如最多执行5轮工具调用并配一个任务终止条件比如获取到所需信息后立即结束防止失控。问题二Agent调工具时参数传错。排查思路在工具函数里增加参数校验和错误返回逻辑Agent在收到错误信息后可以自主修正效果比直接崩溃好得多。8. 最后分享一点我自己的体会这套五层结构从算力基础设施Infra一路讲到业务产品层看起来像是把AI项目拆得很碎。但我在实际推进项目的过程中最大的体会恰恰是拆分是为了更好地整合。每一层相对独立可以让不同背景的团队成员各司其职但每一层之间的衔接又需要有全局视野的人来把关——模型选型要考虑到量产成本产品交互要理解模型的局限性业务定价要反推技术方案的性价比。另外一个特别想强调的是AI技术的迭代速度非常快热词榜上的东西可能几个月就过气一次。但分层思考的方法不会过时。无论底层模型换成什么框架更新到什么版本只要你能清晰地把基础设施、模型能力、工具框架、应用交互、业务价值这五层之间的关系想明白任何新技术进来都能快速定位它属于哪一层、能解决哪一层的问题。这比追着追新模型、新工具跑要重要得多。