1. 国内AI大模型赛道的整体格局与选型逻辑2024年这一年国内AI大模型领域的变化用“月新日异”来形容一点不夸张。从年初各家忙着晒参数、晒榜单到年中开始拼落地、拼推理成本再到年底大家集体转向Agent和多模态整个行业的节奏快得让人喘不过气。我过去一年陆陆续续接触了十几个不同规模的大模型项目从创业团队的小规模微调到中型企业的私有化部署踩过的坑和积累的经验都挺有代表性。这篇文章不打算写成学术综述而是从一个一线从业者的角度把国内主流大模型的架构差异、能力边界、部署选型和应用场景这几个核心问题掰开揉碎讲清楚。先说说为什么架构这件事值得单独拿出来聊。很多人觉得大模型嘛调API就行了架构跟我有什么关系这个想法在2023年可能还说得过去但到了2024年如果你要做一个正经的AI应用不理解底层架构的差异你连模型选型都做不对。举个例子同样是7B参数的模型基于MoE架构和基于Dense架构的推理成本能差出三到五倍而效果在某些任务上可能只差几个百分点。再比如上下文窗口从4K扩展到128K背后的注意力机制实现方式完全不同直接影响到你的显存占用和推理延迟。这些决策如果拍脑袋做后面填坑的成本会非常高。国内目前主流的大模型玩家大致可以分成几个梯队。第一梯队是百度文心、阿里通义、字节豆包、腾讯混元这几家特点是参数规模大、训练数据多、生态完善基本上都是千亿参数级别的MoE架构。第二梯队是智谱GLM、月之暗面Kimi、百川、零一万物这些各有侧重有的主打长上下文有的主打推理能力架构上也有不少创新。第三梯队就是各种开源模型和垂直领域模型比如Qwen的开源系列、DeepSeek、Yi系列等这些在私有化部署场景里用得非常多。选型的时候我一般会从四个维度来评估任务类型、延迟要求、成本预算、数据合规。任务类型决定了你需要什么能力的模型比如文本分类和摘要用7B就够了复杂推理和代码生成至少得上32B甚至更大。延迟要求决定了你是用API还是本地部署API的延迟通常在几百毫秒到几秒之间本地部署如果硬件到位可以压到几十毫秒。成本预算这个不用多说API按token计费和本地部署的硬件投入是两笔完全不同的账。数据合规在2024年变得越来越重要很多企业客户明确要求数据不能出内网这就直接排除了公有云API的方案。我个人的经验是不要一上来就追求最大最强的模型。先用小模型跑通流程验证业务价值等确认了需求再逐步升级。我见过太多团队花了大价钱部署了70B的模型结果发现实际业务场景里7B的效果就够用了多出来的成本纯属浪费。还有一个容易被忽略的点是模型的迭代速度。国内大模型的版本更新非常频繁基本上每两三个月就有一次比较大的升级。这意味着你在做架构设计的时候一定要把模型层做成可替换的不要把业务逻辑和特定模型的API绑死。我一般会建议在模型调用层加一个适配器层统一输入输出格式这样换模型的时候只需要改适配器的实现上层业务代码不用动。2. 主流架构深度拆解Dense、MoE与混合架构的取舍2.1 Dense架构经典但依然能打Dense架构就是最传统的那种Transformer结构每一层都是全连接的每个token都要经过所有参数的计算。这种架构的好处是训练稳定、推理行为可预测、部署简单。坏处也很明显参数利用率低推理成本随参数规模线性增长。国内纯Dense架构的大模型现在越来越少了但在7B到13B这个参数区间Dense架构依然是主流选择因为在这个规模下MoE带来的收益还不够明显反而增加了工程复杂度。我实测过几个Dense架构的模型比如Qwen2的7B版本和Yi的6B版本在单张A100上跑推理吞吐量大概在每秒30到50个token左右具体取决于batch size和量化方式。如果用INT8量化显存占用可以压到8GB以内消费级显卡比如RTX 4090也能跑起来。这对于中小团队来说是非常友好的不需要昂贵的多卡服务器就能做本地部署。Dense架构的另一个优势是微调相对简单。因为所有参数都参与计算LoRA或者QLoRA微调的效果比较稳定不太会出现MoE那种专家路由不均衡的问题。我在做垂直领域微调的时候如果数据量不大几千到几万条一般优先考虑Dense架构的小模型性价比最高。2.2 MoE架构大参数与低推理成本的平衡术MoEMixture of Experts架构是2024年国内大模型的主流选择没有之一。从文心4.0到通义千问2.5从豆包到混元基本上叫得上名字的大模型都在用MoE。MoE的核心思想是把FFN层拆成多个专家每个token只激活其中一小部分专家这样总参数量可以做得很大但实际计算量只跟激活的参数有关。举个例子一个总参数100B的MoE模型如果每次只激活10B的参数那么推理成本大概相当于一个10B的Dense模型但效果可能接近甚至超过30B的Dense模型。这就是MoE的魔力所在。国内目前比较典型的MoE配置是8个专家选2个或者16个专家选4个激活比例在25%左右。但MoE也不是没有代价的。首先是训练难度大专家路由容易崩溃也就是所有token都跑到同一个专家去了其他专家得不到训练。解决这个问题通常需要加负载均衡损失或者用一些路由策略上的技巧。其次是推理时的显存占用虽然计算量小了但所有专家的参数都要加载到显存里所以显存需求反而比同等激活参数的Dense模型大。最后是微调困难MoE的微调需要特别小心不然很容易破坏专家路由的平衡。我在部署MoE模型的时候踩过一个坑用LoRA微调一个8专家的MoE模型结果微调后模型在某些任务上表现反而下降了。后来分析发现是LoRA的秩设置得太小只影响了部分专家的行为导致专家之间的输出分布出现了偏移。后来把秩调大并且只对注意力层做微调效果就稳定了。所以MoE微调要么全量微调要么就只动注意力层别碰FFN的专家。2.3 混合架构与创新探索除了纯Dense和纯MoE2024年还出现了一些混合架构的探索。比如有的模型在底层用Dense高层用MoE兼顾训练稳定性和推理效率。还有的模型引入了线性注意力或者状态空间模型SSM来替代部分注意力层降低长序列的计算复杂度。智谱的GLM系列在架构上一直有自己的特色GLM-4用的是混合专家架构但在注意力机制上做了不少优化。月之暗面的Kimi主打长上下文在注意力实现上用了不少工程技巧比如Flash Attention的定制版本和分块计算策略。这些创新虽然不像MoE那样成为行业标配但在特定场景下确实能带来明显的优势。从选型角度来说如果你的场景对长上下文要求很高比如处理整本书或者超长文档那Kimi或者类似的长上下文模型是首选。如果追求极致的推理成本那MoE架构的大模型API通常比Dense架构的便宜不少。如果要做私有化部署且硬件资源有限那Dense架构的小模型更实际。3. 应用场景拆解从通用对话到垂直行业的落地实践3.1 通用对话与内容生成通用对话是大家最熟悉的大模型应用场景也是各家模型能力比拼最直接的战场。2024年国内主流模型在通用对话上的表现已经相当不错了日常问答、文案写作、翻译润色这些任务基本上都能达到可用甚至好用的水平。但通用对话场景的竞争已经非常红海了单纯做一个聊天机器人很难做出差异化。我观察到的一个趋势是大家开始往“对话工具调用”的方向走也就是Agent化的对话。比如在对话过程中调用搜索引擎、查天气、订机票、发邮件这些能力让对话机器人的实用性上了一个台阶。技术实现上Agent化的对话需要模型具备Function Calling的能力。国内主流模型现在都支持这个功能但成熟度参差不齐。我实测下来通义千问和文心在这方面的稳定性比较好Function Calling的格式遵循度高不容易出现幻觉调用。豆包在中文场景下的意图理解很准但有时候会过度调用工具。智谱GLM-4在复杂多步调用的场景下表现不错但延迟稍微高一点。做Agent应用的时候我强烈建议加一层输出校验。不要完全信任模型的Function Calling结果尤其是涉及金额、时间、地址这些关键参数的时候。我一般会在调用工具之前加一个规则引擎做二次校验把明显不合理的参数拦截掉。这个简单的措施能避免很多线上事故。3.2 代码生成与开发辅助代码生成是2024年增长最快的应用场景之一。从GitHub Copilot到国内的CodeGeeX、通义灵码再到各家大模型自带的代码能力这个赛道的竞争非常激烈。我过去一年在多个项目里用了不同的代码生成工具感受挺深的。从模型能力来看DeepSeek的代码能力在国内模型中属于第一梯队尤其是在算法题和复杂逻辑实现上生成的代码质量很高。通义千问在工程代码和框架使用上表现不错对Spring、React这些主流框架的API掌握得比较准。文心一言在代码注释和文档生成上比较强适合做代码理解和维护。但代码生成场景有一个很现实的问题上下文长度。实际项目里的代码文件动辄几百上千行加上依赖文件和配置文件很容易超出模型的上下文窗口。2024年主流模型的上下文窗口已经扩展到32K到128K但实际有效利用的长度往往只有标称值的一半左右。我一般会把相关代码片段做裁剪和摘要只把最核心的部分喂给模型这样效果反而比一股脑全塞进去好。3.3 知识库问答与RAG应用RAG检索增强生成是2024年企业级AI应用最主流的架构模式。简单来说就是把企业内部的文档、知识库做向量化存储用户提问的时候先检索相关片段再把片段和问题一起交给大模型生成回答。这个架构的好处是不需要微调模型就能让模型回答特定领域的问题而且可以溯源回答有据可查。但RAG做起来容易做好很难。我见过太多RAG项目demo阶段效果惊艳上线之后用户满意度直线下降。核心问题通常出在检索环节。向量检索的召回率不够高或者检索到的片段和问题相关性不强导致模型拿到的上下文质量很差生成出来的回答自然好不到哪去。优化RAG效果我一般会从几个方面入手。第一是文档切分策略不要简单地按固定长度切而是按语义段落切保持每个片段的完整性。第二是混合检索向量检索加上关键词检索两者结合能显著提升召回率。第三是重排序用一个小的交叉编码器模型对检索结果做精排把最相关的片段排到前面。第四是查询改写用户的问题往往很口语化先用模型把问题改写成更适合检索的形式再去做检索。知识库这块还有一个容易踩的坑是文档更新。很多团队的RAG系统上线之后就不管了文档更新了但向量库没更新导致模型回答的是过时的信息。我建议把文档更新和向量库更新做成自动化的流水线文档一变就触发重新索引保证知识库的时效性。3.4 多模态与智能体应用多模态是2024年下半年开始爆发的一个方向。从GPT-4V到国内的文心一言4.0、通义千问VL、智谱GLM-4V各家都在多模态能力上投入了大量资源。多模态的应用场景也很广泛比如图片理解、文档解析、图表分析、视频摘要等等。我实测下来国内多模态模型在中文场景下的图片理解能力已经相当可用了。比如给一张发票图片模型能准确提取出金额、日期、抬头这些关键信息。给一张折线图模型能描述趋势并给出分析。但在细粒度的视觉理解上比如识别图片中很小的文字或者理解复杂的图表结构跟国外顶尖模型还有一定差距。智能体Agent是另一个热门方向。2024年被称为“Agent元年”各种Agent框架和产品层出不穷。Agent的核心是让大模型自主规划任务、调用工具、执行动作、根据反馈调整策略。这个方向的技术挑战很大尤其是在多步推理和错误恢复上目前的模型还经常出错。我在做Agent项目的时候最大的体会是不要指望模型一次就把事情做对。一定要设计好错误处理和重试机制。比如模型调用了一个工具返回了错误要能让模型理解错误信息并尝试其他方案。再比如模型规划了一个多步任务执行到中间发现某一步不可行要能重新规划。这些容错机制比模型本身的能力更重要。4. 私有化部署与成本控制实战4.1 硬件选型与显存估算私有化部署大模型硬件选型是第一道坎。2024年国内能买到的推理卡主要是英伟达的A100、H100、L40S以及国产的昇腾910B、寒武纪思元等。从性价比来说L40S在推理场景下表现不错48GB显存价格比A100低不少。国产卡在生态适配上还有不少工作要做但如果项目有国产化要求昇腾910B是相对成熟的选择。显存估算有一个粗略的公式模型参数量乘以精度字节数再加上KV Cache和框架开销。比如一个7B的模型FP16精度需要14GB显存加上KV Cache和框架开销实际需要大概18到20GB。如果用INT8量化模型本身占7GB加上开销大概12GB左右。INT4量化可以压到8GB以内但精度损失会比较明显。对于MoE模型显存估算要按总参数量算不是激活参数量。比如一个总参数100B、激活参数10B的MoE模型FP16精度下需要200GB显存至少需要4张A100 80GB。这个成本对于中小团队来说是很高的所以MoE模型通常还是用API更划算。模型规模精度显存需求估算推荐硬件7BFP1618-20GBRTX 4090 / L40S7BINT810-12GBRTX 3090 / 409013BFP1630-35GBA100 40GB / L40S13BINT818-20GBRTX 409070BINT880-90GB2xA100 80GB100B MoEFP16200GB4xA100 80GB4.2 推理框架选型与性能调优推理框架这块2024年国内用得比较多的是vLLM、TGI和TensorRT-LLM。vLLM的优势是PagedAttention显存利用率高吞吐量大社区活跃更新快。TGI是HuggingFace出的跟Transformers生态结合紧密部署简单。TensorRT-LLM是英伟达官方的性能最好但编译和调优比较复杂。我一般推荐中小团队用vLLM部署简单文档齐全遇到问题社区里基本都能找到答案。如果追求极致性能且团队有足够的工程能力可以上TensorRT-LLM。TGI适合快速验证和原型开发生产环境用vLLM或者TensorRT-LLM更合适。性能调优方面有几个参数很关键。首先是batch size增大batch size能提升吞吐量但会增加延迟。我一般会根据业务的延迟要求来反推合适的batch size。其次是KV Cache的管理策略vLLM的PagedAttention在这方面做得很好但也要注意设置合理的block size。最后是量化策略INT8量化通常能带来2倍左右的吞吐提升精度损失在可接受范围内。量化这块我踩过一个坑用GPTQ量化一个模型在通用对话上效果还行但在代码生成任务上质量下降很明显。后来换成AWQ量化代码任务的表现就好很多。所以量化方法的选择要看具体任务不能一概而论。建议量化后一定要在自己的业务数据上做评测不要只看通用榜单。4.3 API调用与本地部署的成本对比成本这块我拿一个实际项目算过账。假设每天处理100万token的请求用某国内主流大模型的API价格大概是每百万token几十块钱一天的成本在几十到一百块左右。如果本地部署一个7B的模型一张RTX 4090大概一万多加上服务器其他配件总投入两万左右。电费按每天10度算一个月电费大概两三百。这样算下来如果API成本每天超过20块本地部署大概两到三年能回本。但这只是纯算经济账。实际决策还要考虑很多其他因素。比如数据合规要求如果数据不能出内网那就只能本地部署成本再高也得上。再比如延迟要求本地部署的延迟通常比API低对于实时性要求高的场景本地部署更有优势。还有可用性问题API服务偶尔会出故障或者限流本地部署至少能保证服务可控。我的建议是如果业务量不大且数据合规要求不高优先用API省心省力。如果业务量大或者有合规要求再考虑本地部署。也可以采用混合方案核心业务本地部署边缘业务用API兼顾成本和灵活性。5. 常见问题排查与避坑经验实录5.1 模型输出质量不稳定的排查思路模型输出质量不稳定是实际项目中最常见的问题。同样的prompt有时候回答得很好有时候答非所问。这个问题通常有几个原因温度参数设置不当、上下文太长导致注意力分散、prompt本身有歧义、模型对某些领域不熟悉。排查的时候我一般会先固定随机种子把温度调到0看看输出是否稳定。如果温度调到0还是不稳定那可能是上下文的问题。把上下文缩短只保留最相关的部分再看看效果。如果还是不行那就是prompt的问题需要重新设计prompt把指令写得更明确把输出格式约束得更严格。还有一个容易被忽略的点是模型的版本。国内大模型的API经常在后台更新有时候你什么都没改但模型的行为变了。所以生产环境一定要锁定模型版本不要用latest这种标签。如果API提供商不支持版本锁定那就要做好输出监控一旦发现质量下降就及时排查。5.2 长上下文场景的性能优化长上下文场景的性能问题主要体现在两个方面推理延迟和显存占用。上下文越长注意力计算量越大延迟越高显存占用也越大。优化长上下文性能我一般会从几个方面入手。第一是使用Flash Attention这个技术能显著降低注意力计算的显存占用和延迟。国内主流推理框架现在都支持Flash Attention部署的时候记得开启。第二是KV Cache的量化把KV Cache从FP16量化到INT8能省一半显存对精度影响很小。第三是滑动窗口注意力对于超长序列不需要让每个token都关注所有其他token只关注一个窗口范围内的token就够了。第四是分块处理把长文档切成多个块分别处理最后再汇总结果。长上下文还有一个坑是“中间遗忘”现象。模型对上下文开头和结尾的信息记得比较牢但中间部分的信息容易忽略。如果你的关键信息在上下文中间模型可能就漏掉了。解决办法是把关键信息放在开头或者结尾或者在prompt里显式提醒模型注意中间的内容。5.3 微调过程中的常见故障与解决微调大模型的时候最常见的故障是loss不下降或者loss震荡。loss不下降通常是学习率太小或者数据量不够可以尝试增大学习率或者增加数据。loss震荡通常是batch size太小或者学习率太大可以尝试增大batch size或者减小学习率。还有一个常见问题是过拟合。微调数据量小的时候特别容易过拟合模型在训练集上表现很好但在验证集上表现很差。解决办法是加正则化比如weight decay、dropout或者用早停策略。LoRA微调的话可以减小秩降低微调的参数量。MoE模型的微调前面提过了这里再补充一点MoE微调的时候要监控专家路由的分布。如果发现某些专家的激活频率明显偏低说明路由可能崩溃了需要调整负载均衡损失的权重。这个监控在训练过程中就要做不要等训练完了才发现问题。5.4 常见问题速查表问题现象可能原因排查方法解决方案输出质量不稳定温度参数过高固定种子温度调0测试降低温度固定随机种子长上下文延迟高注意力计算量大监控显存和延迟开启Flash AttentionKV Cache量化微调loss不下降学习率过小尝试不同学习率增大学习率增加数据量微调过拟合数据量小对比训练集和验证集表现加正则化早停减小LoRA秩MoE路由崩溃负载不均衡监控专家激活频率调整负载均衡损失权重RAG回答不准确检索召回率低检查检索结果相关性混合检索重排序查询改写API调用超时网络或限流检查网络和API状态加重试机制降级到备用模型显存溢出模型太大或batch太大监控显存占用量化减小batch size模型并行6. 2024年后的技术演进与个人实践建议2024年国内AI大模型的发展速度超出了很多人的预期。年初的时候大家还在讨论能不能追上GPT-3.5到了年底国内第一梯队的模型在很多任务上已经接近甚至达到了GPT-4的水平。这个进步速度背后是算法、工程、数据、算力多方面共同推动的结果。从架构趋势来看MoE已经成为大模型的标配未来可能会往更细粒度的专家拆分和更动态的路由策略方向发展。多模态能力会从“能看懂图片”进化到“能理解视频和3D场景”。Agent能力会从“能调用几个工具”进化到“能自主完成复杂任务”。这些演进会带来新的应用场景和新的技术挑战。从个人实践的角度我有几个建议给正在或者准备进入这个领域的同行。第一不要只盯着模型本身工程能力同样重要。一个精心调优的7B模型在特定场景下可能比一个没调好的70B模型效果更好。第二重视数据质量。微调也好RAG也好数据质量决定了效果的上限。花时间清洗和标注数据比花时间调参的收益更大。第三保持学习。这个领域每个月都有新东西出来今天的最佳实践可能下个月就过时了。保持开放的心态多动手实验多跟同行交流。最后分享一个我自己的习惯我会维护一个“模型评测集”里面是我自己业务场景的真实问题和标准答案。每次有新模型出来或者做了微调、量化、prompt调整我都会在这个评测集上跑一遍对比效果。这个评测集不大几百条数据但非常有用。它让我不会被各种榜单和宣传带偏始终以自己业务的实际效果为准。这个习惯坚持了一年多帮我避免了很多次盲目跟风带来的坑。