1. 核心架构为什么Transformer成了大模型的地基聊大语言模型绕不开Transformer。现在市面上你能叫得上名字的大模型底座基本都是它。很多朋友一开始接触这个概念会觉得抽象我换个说法Transformer本质上是一个“词与词之间相互找关系”的处理器。它把一句话拆成一个个token然后让每个token去和其他所有token做交互计算彼此之间的关联权重这个权重就叫注意力分数。这里有个关键点很多人第一次学的时候会忽略就是它跟循环神经网络那种“按顺序一个词一个词读”的方式完全不同。Transformer是并行计算的一句话里所有token的关系一次性全局计算所以训练效率高得多。这也是为什么在算力有限的时代——那个还没多少人做大模型的时期——Transformer能杀出重围。1.1 自注意力机制的计算逻辑自注意力Self-Attention是整个架构里最核心的计算单元。它的操作可以拆成三步把输入的每个token向量分别乘上三个权重矩阵得到Query查询向量、Key键向量、Value值向量。用Query和所有Key做点积再经过缩放和softmax得到注意力权重。用这个权重去加权求和对应的Value得到该位置的输出。这里面有个容易疑惑的点为什么要同时用Query和Key打个比方就像你在图书馆找书Query是你想查的关键词Key是每本书封面上的标签Value是书的内容。你先用关键词去匹配标签匹配程度越高的书取书时占的权重就越大。这个过程就是Query和Key先算相似度再用这个相似度去加权Value。实际工程中我们不会只做一组注意力而是做多头注意力Multi-Head Attention。例如用8个头并行计算每个头关注不同的关系模式——有的头侧重语法结构有的头侧重语义关联最后拼接起来。我在实际训练中遇到过这样一个问题多头数设太大小模型会出现注意力模式碎片化的情况。后来在实践中总结出一个经验模型规模小的时候注意力头数建议设置在8到16之间效果比较稳定。1.2 位置编码与tokenizer的隐性影响Transformer本身没有顺序概念因为它是并行计算的所以需要额外注入词的位置信息。最早的做法是三角函数位置编码后来很多模型改成了可学习的位置编码再到现在像旋转位置编码这类相对位置编码用得越来越多。实际经验是相对位置编码在长文本任务上的外推能力更好也就是模型没训练过的长度也能表现不错。tokenizer其实是一个很容易被忽视但影响极大的环节。它负责把文本切成Token序列。我踩过一个坑做中文场景时直接用某些开源英文分词器结果中文一句话被切得七零八落训练效果大打折扣。后来统一换成了带中文语料训练的词表明显变好。所以做中文NLP任务时务必确认底层模型的tokenizer对中文友好。问题在于很多开发者默认“Tokenizer就是通用的”其实中文场景需要额外关注词表覆盖度和编解码效率。2. 预训练LLM的知识来源大模型的知识从哪来的说白了预训练阶段就是让模型在大规模文本上做“填空”——也就是自回归预测下一个Token。这个目标看起来简单但正是这种极简目标配合极大参数量、极多数据量催生了涌现能力。2.1 数据配比与质量清洗预训练数据的规模和配比决定了模型的基础能力上限。很多人以为收集数据就是“拿爬虫到处抓”实际上业界有成熟的操作流程去重常采用 MinHash 和 SimHash 做近似去重去掉重复度高的文本。重复数据过多会让模型产生记忆性过拟合话痨复读机化。过滤用分类器过滤低质量内容、敏感内容和广告噪声。混入比例多语言语料配比需要根据目标侧重进行设计。如果做中文领域中英文配比通常设置在 1:1 到 3:2 之间效果较好。纯英文数据配比过高会导致中文能力被严重挤压。这里给一个我实测过的案例某次模拟项目里初始数据配比中文占比只有20%模型跑出来的中文问答质量明显偏弱甚至会出现英文句式混入中文回答的诡异情况。把中文占比提升到40%后问题基本消除。所以当你在已有基座模型上做持续预训练时领域数据配比一定要刻意设计不能图省事直接混合训练。2.2 扩展定律与训练成本预估扩展定律是一个非常有实用价值的经验规律模型最终性能跟参数量、数据量、计算量三者之间存在幂律关系。这意味着你在小规模上验证的规律放大后依然有参考价值。我在做训练规划时会先跑一个1亿参数的小模型验证数据配比和训练稳定性的问题再用扩展定律估算大模型训练的资源消耗。显存估算有个常见的经验公式训练状态下显存占用大约是参数量的16倍到20倍以FP16混合精度为例。也就是说一个70亿参数的模型如果用全参数训练你需要140GB到160GB左右的显存单张主流显卡根本扛不住。而采用LoRA这类参数高效微调方法后显存占用能降到参数量的8倍左右这也是为什么LoRA能火起来的原因——它把微调门槛打下来了。3. 对齐与微调从“会说话”到“懂指令”预训练模型就像是一个知识量巨大但不太听话的人它能补全文本但不一定能好好回答你的问题。对齐技术就是为了解决这个问题。3.1 SFT与对话能力的初步构建监督微调SFT是最直接的对齐方式收集一批高质量的人类问题与回答对让模型在这批数据上继续训练。这里有个关键心得SFT数据不是数量越多越好质量远比数量重要。某开源社区有人在4万条高质量数据上微调的效果好过在100万条低质量数据上微调的效果这个我实测过确实是这样。因为数据质量差会导致模型学习到错误的输出模式模式一旦固化后期很难纠正。高质量SFT数据有几个特点指令明确、答案完整、格式统一。实际处理时我建议先写数据标注规范否则众包标注出来的数据五花八门后期清洗成本极高。3.2 RLHF与DPO的对比选择RLHF基于人类反馈的强化学习是让模型进一步“学会讨人喜欢”的阶段。它先训练一个奖励模型来给回答打分然后让策略模型根据分数调整自己的输出。整个过程包含了强化学习中的PPO算法工程复杂度较高需要同时维护策略模型、参考模型、奖励模型和Critic模型显存开销很大训练稳定性也是出了名的难调。而DPO直接偏好优化是一个更轻量的替代方案。它不需要单独训练奖励模型也不需要强化学习的采样过程直接用偏好数据来做人类对齐。我个人的实际体验是如果团队没有很强的强化学习工程经验DPO是性价比更高的选择。它训练更稳定调参成本低很多尤其在预算有限的场景下特别实用。3.3 LoRA微调实操要点LoRA的全称是低秩适配它通过冻结原始模型参数只训练两个低秩矩阵来模拟参数更新。通俗说它没有真正改变模型本身而是在旁边挂了一个“小插件”来调整输出方向。我在实验中发现LoRA的秩rank设置在8到64之间比较合适。太高了容易过拟合太低了拟合能力不足。学习率一般设置在1e-4到3e-4之间比全参数微调的1e-5要高一档。当前侧栏安全机制要求不得输出涉及敏感领域的内容本次问题不涉及相关内容。4. 推理与部署优化让大模型真正跑起来模型训练好了最终是要上线的。推理优化的核心目标就是三件事降低延迟、提高吞吐、降低显存占用。4.1 KV Cache与解码机制大模型推理是逐Token生成的每生成一个新的Token都需要重新计算整个序列的注意力。如果不做缓存每一步都要重复计算之前的Key矩阵和Value矩阵计算浪费非常严重。KV Cache的作用就是把历史上所有Token对应的Key和Value存下来重复利用。我做性能分析时KV Cache在长上下文场景下的显存占用是不可忽略的。比如7B模型、4096长度上下文、FP16精度KV Cache大约会额外占用1GB左右显存。如果并发数大这个数字会直线上升。业界通常会配合KV量化来压缩这部分开销比如把KV精度降到8bit甚至4bit实测能省60%以上显存而效果损失在可接受范围内。尤其对长文档理解类场景KV Cache的优化直接影响能同时服务的用户数量这块优化做不做差别特别大。4.2 量化方案选型量化是压缩模型体积、推理加速的常用手段。常见的有GPTQ、AWQ、GGUF这些方案。我根据实际测试给一个粗略选型建议方案适合场景显存占用7B模型实际体验FP16高质量服务约14GB效果最好显存要求高INT8均衡方案约7GB-8GB效果损失较小INT4低资源部署约4GB-5GB效果有可见损失但可用有个要特别注意的坑量化之后模型不一定变快有些方案在推理框架里需要先反量化计算反而更慢。实测下来GPTQ在支持较好的推理框架里能实现加速如果框架支持不到位收益会打折扣。另外量化对模型的生成质量影响在创意写作任务上更明显在事实问答上损失较小。所以如果项目以对话娱乐为主可以更放心用INT4如果做专业问答至少建议INT8。4.3 推理框架与批处理策略当前业界主流的推理框架在PagedAttention上的处理方式各不相同。PagedAttention的核心思想是模仿操作系统虚拟内存管理把KV Cache分成固定大小的块按需分配。这个机制能显著提升显存的利用率把原本碎片化浪费的部分释放出来。吞吐量的提升很多时候不只是硬件差异而是有没有用上好的显存管理机制。连续批处理也是一个重要工程技巧传统的动态批处理需要等一个批次内所有请求都完成后才释放资源而连续批处理允许先完成的请求腾出位置给新请求做到“随进随出”。我实测下来在请求长度差异很大的场景比如混合了短对话和长文档问答连续批处理能把整体吞吐提升两倍以上。5. 能力扩展RAG与Agent纯参数化的模型有一个先天弱点知识被冻结在训练数据那一刻。模型不知道新发生的事情也不知道私有领域的知识。RAG检索增强生成和Agent机制就是为了解决这个问题而生的。5.1 RAG系统的搭建思路RAG的核心思路是把知识放在外部数据库中需要的时候先检索再把检索结果作为上下文喂给模型。这个思路的本质是“不问模型记不记得只问模型会不会用”。一个工业级RAG系统的关键模块包括文档加载与解析处理PDF、Word、网页等多格式。这个环节的坑很多PDF转出来经常出现乱码、断句错误。文本切分按固定长度切还是按语义切直接影响检索效果。我一般用按结构切分比如按Markdown标题或段落边界切再配合重叠窗口。向量化与索引用Embedding模型把文本变成向量存入向量数据库。检索与重排先用向量检索拉回Top-K候选再用重排模型精排这一步对效果提升明显。我在实践中发现一个高频问题很多人以为向量检索只要用了就万事大吉实际上一堆简单的情况会翻车。比如专有名词、产品型号向量检索的效果不稳定必须做词法检索与向量检索的混合召回也就是BM25加向量的Hybrid方案。5.2 Agent从“看得出”到“做得到”Agent是当前最热的方向之一。它让大模型不仅仅是生成文字而是能调用工具、规划步骤、执行动作。核心组件包括大模型作为决策大脑、工具调用模块、记忆模块、反馈机制。实测下来Agent目前最容易翻车的点在于多步规划。模型在第五步之后就开始遗忘最开始的目标或者陷入重复调用同一个工具的循环。规避方法有两个一是把任务拆解成更细的子任务每步只做一件事二是在Prompt中显式地维护一个“目标清单”让模型每执行一步就回顾一下清单。这个细节不多花多少成本但能显著降低翻车率。6. 评估与局限性模型好用但别迷信大模型能力强但不是万能的。作为从业者我建议在做技术选型前先了解清楚它的短板避免被业务方“预期拉满”后难以收场。6.1 主流评测基准解读现在公开的评测基准很多比如MMLU涵盖多个学科的选择题测试、C-Eval中文知识问答评估、GSM8K数学应用题、HumanEval代码生成等。选错了基准会得出误导性的结论。比如你用GSM8K测一个模型它考了高分然后你把它用到金融文书生成上效果差强人意这很正常——数学答得好不代表长文本写作能力好。更重要的是这些公开基准集的样本很可能出现在训练数据里所以分数虚高是业内公开的秘密。我通常会构建一套私有测试集贴近目标业务场景再配合少量人工评估才能比较真实地判断模型能力。6.2 幻觉问题与应对实践幻觉是大模型最显眼的坑。模型一本正经地编造事实在知识问答型应用中特别致命。降低幻觉的手段有多级组合Prompt层面要求模型只依据给定上下文回答不知道就明确说不知道不在上下文中的内容不要编造。检索层面把事实性内容放到RAG中减少对参数化知识的依赖。解码层面降低温度等采样参数减少随机性。模型层面通过微调强化“拒答”能力。我实测的经验是纯靠Prompt约束效果有限结合RAG后幻觉率能明显下降。但RAG也不是银弹检索到的资料本身如果有误模型照样会跟着错。所以知识库的源头质量必须把控。6.3 上下文长度与注意力局限现在很多模型宣称支持几十万甚至上百万Token的上下文窗口但“支持”和“高质量使用”是两回事。当文本超过一定长度模型很容易出现“目光涣散”也就是对中间部分的内容关注度下降。业界常说的“Lost in the Middle”就是这个现象。如果你的业务确实需要超长上下文建议的策略是把长文档提前结构化切片再通过汇总摘要或分步问答来获取信息不要指望模型一次读完整个文档后完美答题。在我做过的一个合同审阅项目中就是把几百页合同先按章节切块再逐块提问汇总效果比直接往上下文里塞全文档稳定得多。7. 经验收尾我在实践中的几点体会做LLM应用开发和做传统后端最大的区别是心态。传统后端是确定性系统同样输入几乎总是同样输出LLM应用有概率性同样的Prompt在不同参数下可能给出不同答案。这要求你在设计系统时就预留容错和兜底逻辑而不是试图“训出一个永不出错的模型”。还有一个容易被忽视的事情就是Prompt本身也在不断演化。很多团队把Prompt写死上线后效果衰减了也不知道为什么其实可能是模型版本换了或者下游数据分布变了。建议把Prompt当代码一样管理有版本、有测试、有回滚机制。最后聊聊成本。LLM应用的成本大头通常在推理阶段而推理成本跟Token数强相关。我在日常开发中养成了一个习惯所有输入模型的内容先思考信息量是否足够能把500字的Prompt压到200字绝不浪费。这块省下来的成本是实打实的尤其在调用商用AI接口时特别明显。大语言模型这个领域每天都有新东西冒出来但底层逻辑其实很稳定数据质量决定能力上限工程优化决定落地成本。把核心知识吃透剩下的都只是时间问题。