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架构：大参数与低推理成本的平衡术

MoE（Mixture 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和纯MoE，2024年还出现了一些混合架构的探索。比如有的模型在底层用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更划算。

4.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 常见问题速查表

6. 2024年后的技术演进与个人实践建议

2024年国内AI大模型的发展速度超出了很多人的预期。年初的时候大家还在讨论能不能追上GPT-3.5，到了年底，国内第一梯队的模型在很多任务上已经接近甚至达到了GPT-4的水平。这个进步速度背后是算法、工程、数据、算力多方面共同推动的结果。

从架构趋势来看，MoE已经成为大模型的标配，未来可能会往更细粒度的专家拆分和更动态的路由策略方向发展。多模态能力会从“能看懂图片”进化到“能理解视频和3D场景”。Agent能力会从“能调用几个工具”进化到“能自主完成复杂任务”。这些演进会带来新的应用场景和新的技术挑战。

从个人实践的角度，我有几个建议给正在或者准备进入这个领域的同行。第一，不要只盯着模型本身，工程能力同样重要。一个精心调优的7B模型，在特定场景下可能比一个没调好的70B模型效果更好。第二，重视数据质量。微调也好，RAG也好，数据质量决定了效果的上限。花时间清洗和标注数据，比花时间调参的收益更大。第三，保持学习。这个领域每个月都有新东西出来，今天的最佳实践可能下个月就过时了。保持开放的心态，多动手实验，多跟同行交流。

最后分享一个我自己的习惯：我会维护一个“模型评测集”，里面是我自己业务场景的真实问题和标准答案。每次有新模型出来，或者做了微调、量化、prompt调整，我都会在这个评测集上跑一遍，对比效果。这个评测集不大，几百条数据，但非常有用。它让我不会被各种榜单和宣传带偏，始终以自己业务的实际效果为准。这个习惯坚持了一年多，帮我避免了很多次盲目跟风带来的坑。