软件开发是大语言模型最早展现规模化价值的领域之一。代码不仅具有语言的表达能力，还具备严格语法、明确依赖和可执行反馈。模型生成的结果可以通过编译器、静态检查和自动化测试进行验证，使 AI 能够形成“生成、执行、观察、修正”的完整反馈闭环。
AI Coding 的形态也由此不断演进：早期产品主要在编辑器中预测下一行代码；随后开始结合当前文件、仓库结构和开发者指令完成跨文件修改；如今，Coding Agent 已经能够调用文件系统、终端、Git 和测试工具，围绕一个工程目标持续探索、实现和验证，最终交付可审查的代码变更。
大语言模型的单次推理本身近似无状态：模型只能看到当前请求、上下文以及参数中已有的知识，并不会自动保存跨会话的用户状态。一次对话结束后，用户偏好、项目背景和未完成任务如果没有被外部系统记录，下一次交互时仍需要重新提供。
长上下文可以让模型一次读入更多历史，却不等于真正的记忆。持续拼接聊天记录不仅会增加 Token 成本和推理延迟，还会引入大量无关信息；更重要的是，它缺少独立的写入、检索、更新、冲突处理和删除机制。能“放下历史”，不代表能准确找到并使用历史。
大模型上线并不意味着能力建设结束。真实用户的问题远比训练集复杂：业务规则持续变化，输入分布不断漂移，RAG、工具和 Prompt 也会频繁升级。模型在离线评测中表现良好，进入生产环境后仍可能出现幻觉、格式错误、工具误调用和安全误判。
这些线上失败既是问题，也是改进模型和系统的重要数据来源之一。通过采集反馈与执行轨迹、定位失败原因、挖掘高价值样本，再经过标注、训练、评测和灰度发布，系统可以把真实问题持续转化为经过验证的能力提升。
大模型应用长期以云端推理为主：用户将请求发送到服务器，由 GPU 集群完成计算并返回结果。云端能够承载更大的模型，也便于统一更新和管理，但它始终受到网络延迟、推理成本、数据隐私和离线可用性的约束。
随着大模型进入输入法、语音助手、本地文件检索、相册理解和手机 Agent 等场景，推理需求开始向用户设备延伸。这些任务通常高频、实时，并涉及大量本地敏感数据，完全依赖云端不仅成本较高，也难以保证稳定的响应速度与隐私边界。
大模型能力越来越强，但推理成本也越来越高：参数规模变大，显存占用上升，计算开销增加，长上下文带来更大的 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 训练体系中最关键、最昂贵，也最决定能力上限的一环：预训练。它不是附属步骤，而是基座模型形成语言、知识、代码、推理和迁移能力的主要来源。