大模型能力越来越强，但推理成本也越来越高：参数规模变大，显存占用上升，计算开销增加，长上下文带来更大的 KV Cache，线上服务还要面对延迟、吞吐和并发压力。对于真实业务系统来说，模型不只是“能不能答得好”，还要看它能不能在可接受的成本和延迟下稳定运行。
模型压缩要解决的正是这个问题：在尽量少损失模型能力的前提下，降低参数存储、显存占用、计算开销和生成延迟。它不是单一技术，而是一组面向推理降本提速的系统优化方法，包括量化、剪枝、蒸馏、低秩分解、KV Cache 优化和 Speculative Decoding。
这一篇我们重点看清楚：大模型推理成本到底来自哪里，不同压缩技术分别优化哪一部分，以及在生产环境里应该如何根据瓶颈选择合适的压缩与加速方案。
大模型擅长理解语言、生成内容和进行推理，但如果只停留在文本生成层面，它很难真正进入业务系统。真实应用中的很多任务，并不是生成一段回答就结束，而是需要查询订单、检索文档、执行 SQL、调用接口、读取文件、发送消息，甚至触发一段完整的工作流。
这就需要一种机制，把用户的自然语言意图转换成业务系统可以执行的结构化调用。Function Calling 要解决的正是这个问题：让模型在理解任务之后，能够选择合适的工具，生成符合 Schema 的调用参数，再由应用侧完成校验、执行和结果回传。
大模型擅长理解语言、生成内容和进行推理，但它并不天然连接外部世界。它不知道你电脑里的文件、数据库里的最新记录、浏览器当前页面状态，也不能直接访问企业内部系统。要让模型从“回答问题”走向“完成任务”，就必须让它能够安全、标准化地读取资料、调用 API、查询数据库、访问代码仓库、操作浏览器，并触发业务工作流。
在 MCP 出现之前，每个 AI 应用往往都要自己适配外部工具：代码助手要接文件系统、Git、数据库、终端和浏览器；企业助手要接飞书、Slack、Notion、工单、CRM 和数据平台；不同 Agent 框架又会重复实现类似能力。这会带来典型的 N × M 集成问题：N 个 AI 应用分别适配 M 个外部系统，连接方式、权限模型、工具描述和返回格式都不统一。
大模型能力很强，但并不意味着“随便问一句”就能稳定得到高质量结果。在真实业务系统里，模型输出会同时受到指令、上下文、历史对话、检索资料、工具结果、采样参数和安全策略影响。只要其中任何一环组织不好，模型就可能答非所问、格式不稳定、遗漏关键证据，甚至被恶意内容诱导执行错误指令。
提示词工程和上下文工程要解决的，就是如何把用户意图、任务约束、外部知识和输出要求，组织成模型更容易理解、更容易遵循的输入。Prompt 不是魔法咒语，而是大模型应用里的调用协议；Context Engineering 也不是简单把内容塞满，而是让模型在正确的位置看到正确的信息。
这一篇我们重点看清楚：Prompt、System Prompt、Few-shot、模板化 Prompt、结构化输出、上下文组织和 Prompt Injection 分别解决什么问题，以及如何更稳定、更可控地调用大模型能力。
在大模型落地到真实业务时，经常会遇到一个问题：基础模型能力很强，但并不一定适合当前场景。它可能不熟悉某个行业的表达习惯，不能稳定遵循业务输出格式，也可能在客服、代码审查、合同分析、工单分类这类垂直任务上表现不够一致。
要解决这类问题，常见有两条路线：一条是 RAG，把外部知识检索出来放进上下文，让模型基于资料回答；另一条是微调，用特定任务数据继续训练模型，让模型的行为、表达方式和任务能力更贴近目标场景。
微调本身也有不同层次：从更新全部参数的 Full Fine-tuning，到只训练少量增量参数的 LoRA、QLoRA。前者能力上限更高，但成本更大；后者更轻量、更易落地，也因此成为很多团队适配垂直场景时最常用的方法。这一篇，我们就从全量微调讲到 LoRA，看清楚大模型到底是如何被“定制”的。
大模型能力越来越强之后，一个新的问题会变得越来越重要：模型到底靠不靠谱？
在 Demo 场景里，模型回答得流畅、看起来聪明，往往就足够吸引人。但在真实业务系统里，“看起来对”远远不够。企业知识问答不能编造来源，代码助手不能给出错误的修复建议，RAG 不能越权召回文档，Agent 不能误调用高风险接口，多模态模型也不能把图表、截图或视频内容看错后还自信回答。
所以，大模型进入生产环境之后，核心问题会从“模型能不能回答”，进一步变成“回答是否正确、是否忠于证据、是否稳定安全、是否可追溯、是否能持续评估和改进”。这就是评测与安全要解决的问题：用评测判断能力边界，用安全策略约束风险行为，用监控和回归测试保证系统持续可靠。
过去的 LLM 主要围绕文本展开：用户输入一段文字，模型基于上下文生成回答。这个范式已经足够强大，可以支持问答、总结、写作、代码生成和复杂推理。
但真实世界的信息并不只以文本存在。技术文档里有表格、架构图和流程图；代码排障经常伴随截图、日志和监控曲线；会议内容包含语音、视频和演示材料；移动端 Agent 还需要理解界面布局、按钮位置和操作反馈。
如果模型只能处理文本，它看到的世界是不完整的。很多重要信息会在“转成文字”的过程中丢失，比如图像中的空间关系、图表中的趋势变化、视频中的动作过程，以及界面中的布局结构。这就是多模态要解决的问题。
大语言模型最初主要以对话式交互的形态被广泛使用：用户输入问题，模型基于上下文生成回答。在这一模式下，模型擅长完成信息解释、文本总结、代码生成、问题分析等任务，本质上仍然是一个以“生成答案”为核心的系统。
但在真实业务场景中，很多任务并不止于生成一段文本。它们往往需要模型围绕一个目标，连续完成资料检索、文档阅读、接口调用、代码修改、测试执行、结果分析和错误修正等多个步骤。也就是说，系统需要的不只是语言生成能力，还需要任务分解、外部工具使用、状态维护和基于反馈持续调整的能力。这就是 Agent 要解决的问题。
大模型在预训练阶段已经学到了大量通用知识，但这些知识本质上是“写进参数里的静态记忆”。模型训练完成后，参数不会自动更新；而真实世界中的知识却在不断变化：产品文档会迭代，业务规则会调整，代码仓库会更新，企业内部知识也往往是私有的、动态的、需要权限控制的。
对于企业知识问答、客服助手、代码助手、法律合规、金融研报分析这类场景来说，答案不能只是“看起来合理”，还必须能够基于明确证据，说明来自哪份文档、哪个版本、哪个段落。换句话说，大模型不仅要会回答，还要会查资料、用资料、引用资料。
前面几篇我们已经把 LLM 的几条主线串起来了：从 AI 到 LLM，理解大模型为什么会出现；从数学、算法、Transformer 到 Dense/MoE，理解模型结构和学习机制；再到预训练、后训练、分布式训练、推理服务和长上下文，理解一套大模型系统如何被训练出来、部署出去。到了这里，还有一个更底层的问题需要单独展开：模型训练时，究竟吃了什么？
很多人讨论大模型时，容易把注意力放在参数量、GPU 数量、训练框架、Attention 结构、MoE 路由和推理加速上。但如果把大模型训练看成一条生产线，数据才是最早进入系统的原材料。没有好的数据，再大的模型也只是在更大规模地学习噪声；没有合理的数据配比，模型就会偏科；没有去重和去污染，模型可能只是记住了训练集和评测答案；没有隐私、安全、版权和版本治理，模型能力越强，风险也越难控制。
过去我们使用大模型时，常常会遇到一个很直观的限制：输入太长，模型放不下。一篇几十页的论文、一份完整的技术文档、一个代码仓库、一次持续很久的多轮对话，都可能超过模型能够处理的上下文窗口。
随着模型上下文长度从早期常见的 4K token，扩展到今天的 1M token 级别（例如 Gemini 1.5 Pro，以及后续部分 Claude / GPT / Gemini 系列模型），LLM 的使用方式也开始发生变化。它不再只是回答一个短问题，而是可以阅读完整资料、分析复杂代码、理解长期对话，甚至支撑 Agent 执行长程任务。
如果说推理服务回答的是“模型如何更快、更便宜地生成 token”，那么推理模型回答的就是另一个更接近能力本质的问题：模型如何在复杂任务中不急着给出结论，而是先分解问题、展开推导、检查约束、验证结果，再输出更可靠的答案。
这里的“推理”不再是 Inference Serving，而是 Reasoning。前者关注系统效率：吞吐、延迟、KV Cache、batch 调度和单位 token 成本；后者关注能力机制：模型为什么愿意多想几步，为什么数学、代码、逻辑和规划任务需要更多 test-time compute，为什么 DeepSeek-R1、OpenAI o 系列、Qwen3 thinking mode 都把“思考过程”和“推理预算”变成核心能力。
如果说分布式训练回答的是“大模型如何在千卡集群上训练出来”，那么推理服务回答的就是另一个更贴近线上系统的问题：模型训练完成之后，如何在真实业务流量下稳定、快速、低成本地生成答案。
这里的“推理”需要先做一个区分。它既可以指 Inference Serving，也可以指 Reasoning Model。前者关注模型服务系统：请求如何进入模型、token 如何生成、KV Cache 如何管理、延迟和吞吐如何平衡；后者关注模型能力机制：如何通过长链思考、验证器、强化学习和 test-time compute，让模型更擅长数学、代码和复杂推理。
如果说预训练回答的是“大模型的能力如何形成”，后训练回答的是“这些能力如何被塑造成可用行为”，那么分布式训练回答的就是一个更底层的工程问题：如此庞大的模型，如何真的在成百上千张 GPU 上稳定训练完成？
大模型训练从来不是把一个 PyTorch 脚本复制到很多张卡上那么简单。真正的挑战在于：模型参数放不下，激活值放不下，优化器状态放不下；单卡算力不够，跨卡通信会拖慢训练；训练中还可能遇到 loss spike、节点故障、checkpoint 写入过慢、MoE 负载不均和长上下文显存爆炸。规模越大，问题越不再是单点优化，而是计算、显存、通信、存储、调度和容错的系统协同。
如果说预训练回答的是“大模型的通用能力从哪里来”，那么后训练回答的就是另一个更关键的问题：这些能力如何被稳定、可靠、可控地组织成用户真正可用的行为。
预训练后的 Base Model 已经学到了大量语言、知识、代码、数学和推理模式，但它本质上仍然是一个基于上下文预测下一个 token 的生成模型。它可以续写论文、代码、对话和网页，也可能生成看似合理但不一定真实、安全或符合用户意图的内容。换句话说，Base Model 拥有能力，但还没有被塑造成一个“助手”：它不天然知道什么叫听指令，什么叫有帮助，什么时候应该拒绝，什么时候应该承认不确定，什么时候应该调用工具完成任务。
如果说 Transformer 解决的是“大模型如何理解序列”，Dense 与 MoE 解决的是“大模型如何扩展架构”，多模态解决的是“大模型如何接入更多世界信号”，那么预训练要回答的，就是一个更底层的问题：大模型的通用能力从哪里来？
前几篇我们已经铺垫了大模型的发展脉络、数学基础、算法原理、Transformer 架构和 Dense/MoE 架构。到这里，讨论进入 LLM 训练体系中最关键、最昂贵，也最决定能力上限的一环：预训练。它不是附属步骤，而是基座模型形成语言、知识、代码、推理和迁移能力的主要来源。
过去几年，LLM 能力的提升很大程度上来自 Scaling Law：当模型参数量、训练数据规模和计算量持续扩大时，模型的 loss 往往会呈现较稳定的下降趋势，模型能力也会随之提升。简单来说，规模化训练证明了一件事：更大的模型、更大的数据、更大的算力，通常可以带来更强的模型能力。
但 Scaling Law 也带来了一个现实问题：如果能力提升依赖规模扩展，那么训练成本、推理成本、显存占用和部署复杂度也会同步上升。模型越大，每个 token 需要经过的参数越多；上下文越长，Attention 和 KV Cache 的压力越大；多模态输入又会引入更多 token 和更复杂的计算路径。
前三篇文章里，我们已经分别从三个角度为理解大语言模型打了基础：第一篇看发展脉络，知道 LLM 是怎么一步步演进出来的；第二篇看数学基础，理解向量、概率、损失函数、梯度这些底层工具；第三篇看算法基础，从 NLP、词向量、感知机、神经网络，一路讲到 CNN、RNN 和双向 RNN。到了第四篇，我们终于可以进入现代大语言模型最核心的一块内容：Transformer。
如果说前几篇是在回答“机器如何把语言变成可以计算的问题”，那么这一篇要回答的是另一个更关键的问题：为什么后来的主流大语言模型，几乎都选择了 Transformer 作为核心架构？
前两篇文章分别介绍了大模型的发展脉络和基础数学知识。到了第三篇，我们还需要补上一块很关键的地基：基本的算法原理。不过，这里的“算法原理”并不是一堂严肃的算法课。本文会尽量站在非算法同学的视角，用更通俗、直观的方式，把语言模型背后那些看起来复杂、晦涩的概念拆开讲清楚。
上一篇我们从大模型的发展脉络出发，回顾了语言模型如何从早期的统计方法，一步步走向 Transformer、GPT，以及今天无处不在的大模型应用。如果说第一篇回答的是“LLM 是怎么发展到今天的”，那么这一篇想往下多走一层，回答一个更底层的问题：LLM 为什么能被训练出来？机器到底是怎样把语言变成可计算、可优化、可生成的东西？
无论是 Transformer 里的 Attention，预训练里的 loss，微调时的梯度更新，RAG 里的向量检索，还是 LoRA 里的低秩矩阵，本质上都绕不开几类基础数学概念。不过，这篇并不是要把大家重新拉回大学数学课堂。我们不会从定理证明开始，也不会堆大量公式。更重要的是建立一套直觉：机器如何把文字变成向量，如何计算词与词之间的关系，如何预测下一个 token，又如何通过错误和梯度一步步修正自己。