这两年只要聊技术绕不开三个字大模型。不管是写代码的、做产品的、跑数据的还是学校里的学生都在问同一个问题这东西到底怎么一步步变成今天这样的我花了不少时间整理了一份学习笔记把从统计语言模型到 Transformer再到 GPT、LLaMA 这些路线的来龙去脉都梳理了一遍。这篇博文就是那份笔记的完整版适合刚入门想建立全局认知的人也适合已经在用大模型但是对底层演进脉络一知半解的开发者。这篇笔记不堆公式、不贴论文长段摘抄而是围绕几个核心问题展开为什么之前那么多年语音识别、机器翻译都在做但直到 Transformer 出现才真正爆发为什么 OpenAI 走的是“大力出奇迹”的路线而 Meta 却偏要把 LLaMA 开源出来上下文长度、多模态、MoE 这些词到底解决的是什么具体痛点以及当你自己动手微调、量化、部署一个大模型时最常踩的坑都在哪里。这篇笔记适合当作你的第一份大模型学习地图。1. 从统计语言模型到Transformer大模型的前世今生很多人以为大模型是 ChatGPT 出来之后凭空冒出来的其实它的根很深。语言模型这个方向至少已经走了七十年今天我们看到的一切都是这条长线里一茬一茬积累出来的结果。1.1 语言模型的老祖宗n-gram 到神经网络语言模型最早的语言模型叫 n-gram 模型核心逻辑非常简单一个词出现的概率取决于它前面 n-1 个词是谁。比如二元模型bigram里学习后面接笔记的概率就是通过统计大量语料中学习笔记这个片段出现的频率来估计的。这套思路在机器翻译、语音识别里统治了很多年但它有一个致命的问题数据稀疏。如果一个词组在训练语料里压根没出现过模型就只会给出一个零概率整个句子就被判了“死刑”。为了解决这个问题研究者们折腾过平滑技术、回退模型但本质上还是在同一个框架里打补丁。到了 2003 年Bengio 那篇《A Neural Probabilistic Language Model》算是打开了新大门。它把词映射成低维向量也就是现在常说的词嵌入word embedding然后丢进一个前馈神经网络里去预测下一个词。这看起来只是把“离散符号”变成了“稠密向量”但背后是一个很大的思想转变相似语义的词在向量空间里距离更近。这样一来即便某个词组没出现过如果它的词向量跟另一个常见词组接近模型也能给出一个合理的概率估计。不过那个年代算力太弱神经网络模型的规模也就几百万参数效果并没有把 n-gram 彻底按在地上摩擦所以神经网络语言模型在很长一段时间里只是学术界的小众爱好。1.2 Word2Vec 带来的转折点如果你去翻大模型的学习资料几乎绕不开 2013 年的 Word2Vec。这东西不是语言模型本身而是一种高效的词向量训练方法但它把“词的向量表示”这个概念彻底带火到了工业界。Word2Vec 有两种训练思路CBOW 用上下文预测中心词Skip-gram 用中心词预测上下文。它的厉害之处在于训练完的词向量有很强的语义规律性。最经典的一个例子是国王 - 男人 女人 ≈ 女王。这说明模型的向量空间里语义关系以“方向”的方式被编码了。我当初第一次跑 Word2Vec 的时候有一次把“北京”和“上海”的向量差值拿去算了一顿发现羽果往“首都”的方向偏移明显当时最大的感受是原来机器“理解”语言的方式和人类完全不一样它是一种几何式的理解。这个认知对后来理解 Transformer 的注意力机制很有帮助因为本质上它们都是在高维空间里做“方向”和“位置”的运算。1.3 2017 年 Transformer 横空出世一切开始加速真正让大模型成为可能的分水岭是 2017 年那篇《Attention Is All You Need》。Google 团队提出 Transformer 架构的时候本来是为了做机器翻译但它的设计让训练和推理都有了质的改变。Transformer 最大的特点是完全依赖注意力机制Attention来建模词与词之间的关系不再需要 RNN 那种顺序结构。这意味着两件事可以并行计算。RNN 必须一个词一个词地往后推算Transformer 可以把整个序列一次性丢进去做矩阵运算训练效率直接起飞。可以建模长距离依赖。RNN 处理长句子的时候早期信息会被逐渐“稀释”而 Attention 机制里任何一个词都可以直接“看到”序列里任意位置的词长距离依赖不再是问题。这三个特性——语义向量化、并行化、长距离建模——凑在一起给后来的“规模扩展”铺平了路。如果说 Word2Vec 证明了“向量能表示语义”Transformer 则证明了“这种表示可以随着规模变大而持续增强”。从此以后大家都开始往同一个方向疯狂加参数、加数据、加算力大模型的军备竞赛正式开始。2. 那些被反复刷新的关键概念参数量、上下文长度与多模态大模型发展的历史本质上也是几个关键指标被不断刷新的历史。参数量从亿级涨到万亿级上下文长度从 2K 扩到 1M输入从纯文本变成图文音视频混合每一步背后都有明确的工程或产品驱动力。2.1 参数量到底意味着什么很多刚接触大模型的人会问参数量越大是不是一定越聪明这里需要拆开看。参数量Parameters可以理解为模型的“记忆容量”和“建模能力”的综合体现。一个 7B70 亿参数模型能装下的知识量肯定比 1B 模型大得多但“更大”不等于“更好”还要看训练数据和训练方法的匹配度。GPT 系列的发展特别直观。GPT-1 有 1.17 亿参数效果只能用“能生成通顺句子”来形容GPT-2 跳到 15 亿参数已经可以生成有一定连贯性的文章GPT-3 直接干到 1750 亿参数才出现了“零样本学习”这种让人眼前一亮的能力。OpenAI 在这条路上验证了一个朴素但有效的规律当模型规模跨过某条线之后会涌现出小模型不具备的能力。不过这里有个容易被忽略的细节不是所有公司都有能力训练千亿参数模型。训练一个 175B 模型的算力成本对绝大多数团队来说是天文数字。所以后来业界分化出了两条路线要么堆超大模型追求极致能力要么用 7B、13B、70B 这种“中等规模”模型配合精细训练在特定领域做到够用。我自己的经验是70B 的模型在推理质量上确实比 7B 强不少比如在代码生成、长文本理解这些场景里差别很明显但 7B 模型经过好的微调在垂直领域也能打得过没有微调的 70B 通用模型。参数量的价值必须结合训练数据的质量和针对性来判断。2.2 上下文长度从 2K 到 1M 的工程突破上下文长度Context Length是另一个被疯狂内卷的指标。最早 GPT 系列只有 2048 个 token这就意味着你扔给它一篇文章它只能“看到”前两千来个 token 的内容再往后就直接忽略了。对于问答、摘要这类场景还好但如果你让它读一本书、分析一份财报、理解一个大型代码仓库那完全不够用。后来各家开始卷上下文窗口Claude 从 100K 干到 200KGemini 宣称 1M国产模型也有不少直接标配 128K。这个数字从 2K 涨到 1M表面上是“能读的东西变多了”本质上其实是工程上的巨大胜利。因为 Transformer 的注意力机制是 O(n²) 复杂度序列长度翻一倍计算成本涨四倍。想要支持超长上下文必须在注意力计算上做优化比如稀疏注意力、滑动窗口、KV Cache 压缩等。这里我建议所有做大模型应用的人一定要把“上下文长度”当成一个成本参数而不是“能力参数”来看。因为你的 prompt 越长模型推理的时间越长API 费用也越高。我在实际做 RAG 应用的时候就经常遇到“明明模型支持 128K但塞太多 token 之后首字延迟高得离谱”的情况。上下文长是能力上限但不是让你每次都顶着上限用的。2.3 多模态人类输入方式的回归大模型最早只能处理文本因为训练数据主要就是网页文本。但现在你打开任何一个主流大模型产品都可以直接上传图片、音频、视频这就是多模态化。多模态的路线有两种主要做法。一种是“拼接式”也就是把图片切成块之后也转成 token跟文本 token 一起丢进模型另一种是“统一式”从一开始就用一个模型同时处理多种模态的数据。2025 到 2026 年这段时间多模态大模型的进展特别夸张。图片问答已经不是简单的“这是什么”而是可以帮你分析图表、识别流程图、看图写代码。语音交互也做到了端到端低延迟。这背后的核心问题是不同模态的信息如何在同一个向量空间里对齐。文本里的“猫”和图片里的“猫”怎么让模型意识到它们是同一个概念这是多模态研究的核心难点。对于普通开发者多模态带来的直接机会是以前需要接一堆 OCR、语音识别、图像识别服务才能完成的任务现在一个模型全搞定。比如我最近在做的一个票据识别工具以前是“OCR 提取字段 规则解析 人工校验”三步走现在直接丢一张票据图片给多模态模型json 结构就出来了准确率还不低。这就是多模态大模型在工程上最直观的价值。3. 从论文到工程微调、量化、部署与私有化落地光会看论文、刷跑分不算真正理解大模型。无论你是做产品还是做研究迟早会走到这一步拿到一个开源模型想办法让它适配自己的数据再把它部署到自己的服务器上。这个过程里踩过的坑比想象中多得多。3.1 微调让通用模型变成行业专家大模型训练分两大阶段预训练Pre-training和微调Fine-tuning。预训练是花几百万美元在几千亿 token 的通用语料上训练基础模型让它学会“语言的一般规律”。微调则是在基础模型之上用更小规模的高质量数据做进一步训练让它学会某种特定风格或特定领域的知识。现在提到微调绝大多数时候指的是参数高效微调最主流的方法是 LoRALow-Rank Adaptation。LoRA 的思路不是去改原始模型的全部参数而是训练一个低秩矩阵作为“补丁”挂在原始模型旁边。这样做的好处非常明显显存占用低一张消费级显卡甚至都能跑。训练速度快不用动底层的几十亿参数。微调完只是一个几百 MB 的小文件随时可以热插拔。在实际操作中我建议刚上手的人不要一开始就微调。先用提示工程Prompt Engineering试试不行再考虑 RAG检索增强生成最后才轮到微调。因为微调虽然效果好但它需要准备数据集、调参数、防过拟合一份高质量的训练集可能就得准备两星期。我的经验是数据质量远比数据量重要。一份十万元的精品数据效果可能比一万条从网上爬来的杂数据还好。做微调的时候有四个核心超参很值得反复实验学习率Learning Rate一般从 1e-5 到 2e-5 起步太大容易训崩太小效果不明显。训练轮数Epoch3 到 5 轮是常见区间轮数太多容易过拟合。批次大小Batch Size受显存限制一般 1 到 8 之间梯度累积可以弥补小批次带来的不稳定。LoRA 秩Rank通常 8 到 64 之间秩越大能学到的信息越多但显存和过拟合风险也越高。3.2 量化与推理优化小显卡也能跑大模型微调完模型之后如果你打算在本地部署遇到的问题往往不是“效果行不行”而是“跑不跑得动”。一个 7B 模型如果用 FP16 精度加载光权重就要占 14GB 左右显存很多人的显卡只有 8GB、12GB。这时候就得用量化Quantization。量化的核心思想是把模型权重从高精度FP16/BF16压缩到低精度INT8/INT4让模型体积变小、推理速度变快代价是精度稍微损失一点。实际用下来INT8 量化在大多数任务上跟原始精度几乎没有区别INT4 会有轻微损失但可用性依然很高。目前最流行的量化工具是 llama.cpp 和 Ollama。llama.cpp 支持跑 GGUF 格式的量化模型Ollama 则把模型管理、量化、API 调用全部封装好了一个命令就能跑起来ollama run qwen2.5:7b说实话我第一次用 4GB 显存的旧笔记本跑通 7B 模型的时候挺惊讶的。虽然每秒只能输出几个 token但至少能跑通了。这说明量化对于个人开发者来说是刚需技术。推理阶段还有一个重要组件叫KV Cache。它缓存了历史 token 的 Key 和 Value 矩阵这样每次生成新 token 的时候不需要重新计算所有历史信息。代价是它会占用额外显存上下文越长KV Cache 越大。所以你会发现模型可以支持 128K 上下文但如果你真塞满 128K显存可能直接爆掉。3.3 企业私有化部署数据安全才是第一优先级很多企业不直接用公共 API是因为数据敏感性。比如医疗病历、金融交易记录、内部代码这些数据绝对不能离开企业的边界。所以“私有化部署”成了大模型落地最核心的场景之一。私有化部署的架构通常长这样模型层找一个开源基座模型Qwen、DeepSeek、LLaMA、GLM 等按需微调。推理引擎层vLLM、Ollama、LM Studio 或者 TensorRT-LLM 来把模型跑起来。应用层FastGPT、Dify 这类平台负责做知识库上传、工作流编排和 API 封装。外围服务向量数据库Milvus、Chroma、pgvector做 RAG 的检索再叠加一个权限管理。这套组合拳的好处是模型完全在自己手里数据不出内网同时还保留了对模型行为做审计的可能性。我提醒过很多人一个容易忽略的问题私有化部署并不等于“一劳永逸”。模型是要迭代的数据是要更新的安全补丁也是要打的。你以为私有化就没人能攻击你了其实针对本地模型的“投毒攻击”data poisoning和“越狱攻击”jailbreak都是真实存在的。做私有化不只是跑一个容器那么简单它是一个需要持续维护的系统工程。3.4 免费 API 与本地部署的取舍现在市面上有大量免费的模型 API 可以白嫖比如 DeepSeek、通义千问、智谱等各家都有自己的免费额度政策。对于程序员来说想快速做一个 Demo直接调免费 API 是最快的方式几分钟就能拿到返回结果。但“免费 API”有几个限制需要注意限流每分钟请求次数有限。上下文限制免费档一般比付费档短。数据政策有些免费 API 会声明数据可能被用于模型训练。模型版本滞后免费档通常跑的不是最新最强的模型。所以我的建议是开发调试阶段用免费 API 最划算生产环境要么买付费 API 拿 SLA要么私有化部署核心流程。不要把一个业务的命脉绑在免费 API 上哪天服务商改政策你连哭都来不及。4. 大模型评测、常见问题与避坑经验等你真正开始用大模型、做大模型会发现“能跑通”和“用得好”之间隔着一条巨大的鸿沟。下面是我在实际操作中总结出来的评测方法和高频踩坑记录。4.1 大模型怎么测才靠谱大模型的评测是个很微妙的事情。外行看跑分内行看场景。如果你只是拿着标准 benchmark比如 MMLU、GSM8K、HumanEval去对比两个模型很容易得出一个和实际体验完全不符的结论。原因很简单标准 benchmark 测的是“通用能力”但你的业务场景是具体的。比如你做一个法律文书生成工具一个模型在数学考试里拿 99 分另外一个只拿 70 分但后者对法条的引用准确性高很多那它在你的场景里就是更好的模型。我在评测一个模型的时候通常会搭一套“私有评测集”从真实业务数据中抽 50 到 100 条代表性问题。把同一个问题分别丢给多个模型拿到输出。请业务方同学或者领域专家人工打分或者按规则自动打分。这套流程看起来土但比任何公开跑分都管用。跑分只能给你一个初筛的方向真正做决定还是要落在业务数据上。而且要注意评测集的答案最好做成“参考答案 评分规则”因为大模型的输出往往不是唯一解太死板的校验规则容易误杀。另外现在有一些专门做模型评测的平台比如 OpenCompass、LMSYS Chatbot Arena它们收集大量用户的匿名投票来给模型排名。这种“真人盲测”的口味有时候比跑分更接近实际体验因为用户不会关心你用了什么技巧他们只关心“这个回答我用起来顺不顺”。4.2 数据标注与数据污染问题做微调或者评测的时候数据质量永远是首要问题。很多初学者直接去开源数据集上爬数据结果训练出来的模型不仅效果差还容易出现“答非所问”的情况。数据标注的时候我踩过几个大坑这里集中说一下标注者不作为让非专业人员瞎标数据里全是错误答案模型越训越笨。格式不统一有人用“问题... 回答...”这种格式有人用 JSON模型训练完连指令都识别不利索。缺乏困难样本训练集里全是简单问题模型学不到真正的推理能力一遇到稍微复杂的任务就崩。大模型数据标注还有一个特别的骗局用大模型标注大模型数据。比如你用 GPT-4 生成了一万条微调数据再拿这些数据去微调一个 7B 模型效果会和“蒸馏”有相似之处但如果你不加筛选就直接用往往会把 GPT-4 的幻觉也一并学了过来。正确的做法是要对生成的数据做人工抽检和清洗尤其是那类涉及事实性知识的问题必须人工核实答案的准确性。4.3 上下文长度与代码开发的实操问题许多开发者在用大模型辅助写代码时会遇到“模型上下文不够用”的情况。比如你想让它重构一个类但这个类有一百多行你还想让它参考另一个文件里的工具函数这加起来可能就超过上下文限制了。我常用的几种应对方案拆分任务把大任务拆成小任务每次只给模型一个文件的上下文。使用 RAG把代码库做索引让模型先通过检索找到需要的代码片段再拿去问答。优先选用支持长上下文的模型如果你确实需要让模型一次看完整份代码建议选 128K 以上的模型或者本地部署一个长上下文版本。还有一个小技巧写代码提示词的时候尽量让模型“先解释再写”。让它先说清楚思路再给代码比直接让它输出代码更能稳定拿到高质量结果。4.4 一个真实的避坑清单我在社区分享过一份“大模型落地避坑清单”这里挑几条最常被问到的展开讲讲。模型总是“一本正经胡说八道”怎么缓解 幻觉是当前所有大模型的通病。最有效的手段是让模型学会说“不知道”。你在系统提示词里明确写“如果信息不在提供资料中请直接回答‘未找到相关信息’”能明显减少胡编答案的情况。另外把答案的“出处”抓出来要求模型给出引用来源也能大幅提升可信度。模型越狱攻击怎么防 任何对外提供服务的模型都要考虑提示词注入Prompt Injection的问题。攻击者会在输入里塞一些恶意指令试图覆盖系统提示词。一个比较笨但有效的方法是对输出做校验确保模型输出的内容符合预期格式同时对输入做敏感词和异常模式过滤。涉及 RAG 的场景还要小心“检索结果投毒”攻击者把恶意文本排在检索结果前面诱导模型输出有害内容。用了 API 但响应特别慢是模型差吗 这是非常常见的问题。响应慢可能不是因为模型性能差而是因为你喂的上下文太长前面说过 KV Cache 的问题、服务器排队、或者你的网络出口有问题。排查顺序应该是先看 API 延迟指标再看输入 token 数量然后考虑切换到更快的推理引擎。本地跑模型总是 OOM显存不足怎么办 有三个方向换更小的量化版本比如 4bit调小最大生成长度或者切换到 CPU 推理虽然慢但至少能跑。如果你用的是 vLLM还可以开启“prefix caching”和“chunked prefill”来降低显存压力。4.5 国外开源生态与国产模型的互补目前开源大模型的生态已经相当丰富国外有 LLaMA、Mistral、Gemma 这些国内则有 Qwen通义千问、DeepSeek、GLM智谱、Baichuan 等。国产模型这几年的进步非常快尤其是在中文理解、长文本和代码生成这几个维度上很多开源版本的表现已经和国际一线模型处于同一梯队。我自己比较常用的组合是通用对话Qwen 系列中文好指令泛化能力强。代码生成DeepSeek 系列代码推理和补全效果非常突出。私有化部署7B 和 14B 级别的模型加 INT4 量化单卡就能跑。低成本高并发硬实力不够就搭配 vLLM 做吞吐优化。如果你有条件用国外模型做对比建议不要只看规模要多看具体任务上的实测效果。有些 7B 模型在代码场景的推理速度和质量真的比 13B 的通用模型还好。模型选型不是一个“越大越好”的单选题而是一个根据场景做匹配的多选题。5. 大模型学习路线从新手到上手的进阶路径最后这部分聊一聊“怎么学”。我经常看到有人一上来就买一堆大模型深度学习的课程或者直接去找论文原文结果不到两周就放弃了。原因是这条路太陡缺乏一个渐进的过程。5.1 新手期先会用再懂里如果你的目标是能上手做应用我建议第一步就是用 API。找任何一家支持免费额度的模型服务注册一个账号把官方文档里的第一个示例代码跑通你会获得第一次正向反馈。之后再尝试改改 prompt让它帮你写周报、翻译文本、总结文档慢慢建立对模型表现的直觉。这个阶段不用管什么微调、量化那些都属于工程优化问题。你需要理解的是“大模型能干什么、不能干什么、什么样的输入能得到什么样的输出”。至少要知道“上下文窗口”这个概念知道为什么同一个问题换个问法结果完全不同。当你能熟练使用三四个主流平台的 API 时就可以开始了解 Token 是怎么计算的、为什么计费按 Token 算而不是按字数算。这一步虽然简单但它会帮你建立对后续所有工程优化的基本意识。5.2 进阶期本地跑模型感受工程的“重量”当你对 API 的调用已经非常熟练下一步是尝试本地部署一个开源模型。你可以从 Ollama 开始它几乎把所有的环境配置全部封装掉了几条命令就能跑起来一个模型ollama pull qwen2.5:7b ollama run qwen2.5:7b跑通之后你会立刻遇到第一个现实问题我的显存不够。这个时候再引入量化、推理引擎等概念会比纯粹看文档理解得深得多。如果说调用 API 能让你学会站在岸上看游泳那本地部署就是让你真正下水扑腾感受水的阻力。这个阶段如果有余力建议自己动手把 vLLM 部署起来或者用 FastGPT/Dify 搭一个简单的知识库问答系统。这样你就把“模型 推理 应用”的完整链路都打通了真正进入大模型工程的世界。5.3 开拓期微调一个属于你自己的模型再往后就是微调。我不建议新手一上来就微调大模型但当你已经积累了足够多的“任务判断经验”比如你知道自己的业务场景里模型为什么回答不好、差在哪里这时候微调的价值才会真正体现。动手前先问自己三个问题我的任务里模型当前的失败点是什么提示词工程和 RAG 都已经试过了吗为什么还不够能不能拿出至少一两百条高质量的训练样本都确认了再去跑 LoRA。刚开始可以不用自己写训练代码用一些已经封装好的框架就行比如 LLaMA Factory、Axolotl。顺带提一嘴现在市面上的免费课程和 PDF 资源非常多找一套口碑好、更新及时的教程作为主线比零散地到处看博客效率高得多。但不管看什么教程记得一定要动手跑代码。大模型的学习本质上是在“踩坑中长出来的”。5.4 一点个人的经验总结写了这么多最后聊几句真心话。大模型发展史这条线看起来是各种技术名词的堆叠但真正理解它之后你会发现每个阶段的转折点都源于一个简单的追问“现在这个方案痛点到底在哪里”以我个人实际操作来看最有用的学习方法不是背熟多少篇论文而是“带着问题去看历史”。当你被长上下文显存问题折磨过一遍再去看稀疏注意力的论文会有一种豁然开朗的感觉。当你被模型幻觉坑过一次再去理解 RAG 的设计思想立刻明白那才是解决幻觉的第一优先级。所有的理论学习都要落到“能支撑你做出更好的工程决策”上这才是大模型笔记真正的意义。 
长河君 · 2026/10/26 6:25:05 · 阅读 1.2k 大模型学习路线图：从Transformer到微调部署的完整笔记
这两年只要聊技术绕不开三个字大模型。不管是写代码的、做产品的、跑数据的还是学校里的学生都在问同一个问题这东西到底怎么一步步变成今天这样的我花了不少时间整理了一份学习笔记把从统计语言模型到 Transformer再到 GPT、LLaMA 这些路线的来龙去脉都梳理了一遍。这篇博文就是那份笔记的完整版适合刚入门想建立全局认知的人也适合已经在用大模型但是对底层演进脉络一知半解的开发者。这篇笔记不堆公式、不贴论文长段摘抄而是围绕几个核心问题展开为什么之前那么多年语音识别、机器翻译都在做但直到 Transformer 出现才真正爆发为什么 OpenAI 走的是“大力出奇迹”的路线而 Meta 却偏要把 LLaMA 开源出来上下文长度、多模态、MoE 这些词到底解决的是什么具体痛点以及当你自己动手微调、量化、部署一个大模型时最常踩的坑都在哪里。这篇笔记适合当作你的第一份大模型学习地图。1. 从统计语言模型到Transformer大模型的前世今生很多人以为大模型是 ChatGPT 出来之后凭空冒出来的其实它的根很深。语言模型这个方向至少已经走了七十年今天我们看到的一切都是这条长线里一茬一茬积累出来的结果。1.1 语言模型的老祖宗n-gram 到神经网络语言模型最早的语言模型叫 n-gram 模型核心逻辑非常简单一个词出现的概率取决于它前面 n-1 个词是谁。比如二元模型bigram里学习后面接笔记的概率就是通过统计大量语料中学习笔记这个片段出现的频率来估计的。这套思路在机器翻译、语音识别里统治了很多年但它有一个致命的问题数据稀疏。如果一个词组在训练语料里压根没出现过模型就只会给出一个零概率整个句子就被判了“死刑”。为了解决这个问题研究者们折腾过平滑技术、回退模型但本质上还是在同一个框架里打补丁。到了 2003 年Bengio 那篇《A Neural Probabilistic Language Model》算是打开了新大门。它把词映射成低维向量也就是现在常说的词嵌入word embedding然后丢进一个前馈神经网络里去预测下一个词。这看起来只是把“离散符号”变成了“稠密向量”但背后是一个很大的思想转变相似语义的词在向量空间里距离更近。这样一来即便某个词组没出现过如果它的词向量跟另一个常见词组接近模型也能给出一个合理的概率估计。不过那个年代算力太弱神经网络模型的规模也就几百万参数效果并没有把 n-gram 彻底按在地上摩擦所以神经网络语言模型在很长一段时间里只是学术界的小众爱好。1.2 Word2Vec 带来的转折点如果你去翻大模型的学习资料几乎绕不开 2013 年的 Word2Vec。这东西不是语言模型本身而是一种高效的词向量训练方法但它把“词的向量表示”这个概念彻底带火到了工业界。Word2Vec 有两种训练思路CBOW 用上下文预测中心词Skip-gram 用中心词预测上下文。它的厉害之处在于训练完的词向量有很强的语义规律性。最经典的一个例子是国王 - 男人 女人 ≈ 女王。这说明模型的向量空间里语义关系以“方向”的方式被编码了。我当初第一次跑 Word2Vec 的时候有一次把“北京”和“上海”的向量差值拿去算了一顿发现羽果往“首都”的方向偏移明显当时最大的感受是原来机器“理解”语言的方式和人类完全不一样它是一种几何式的理解。这个认知对后来理解 Transformer 的注意力机制很有帮助因为本质上它们都是在高维空间里做“方向”和“位置”的运算。1.3 2017 年 Transformer 横空出世一切开始加速真正让大模型成为可能的分水岭是 2017 年那篇《Attention Is All You Need》。Google 团队提出 Transformer 架构的时候本来是为了做机器翻译但它的设计让训练和推理都有了质的改变。Transformer 最大的特点是完全依赖注意力机制Attention来建模词与词之间的关系不再需要 RNN 那种顺序结构。这意味着两件事可以并行计算。RNN 必须一个词一个词地往后推算Transformer 可以把整个序列一次性丢进去做矩阵运算训练效率直接起飞。可以建模长距离依赖。RNN 处理长句子的时候早期信息会被逐渐“稀释”而 Attention 机制里任何一个词都可以直接“看到”序列里任意位置的词长距离依赖不再是问题。这三个特性——语义向量化、并行化、长距离建模——凑在一起给后来的“规模扩展”铺平了路。如果说 Word2Vec 证明了“向量能表示语义”Transformer 则证明了“这种表示可以随着规模变大而持续增强”。从此以后大家都开始往同一个方向疯狂加参数、加数据、加算力大模型的军备竞赛正式开始。2. 那些被反复刷新的关键概念参数量、上下文长度与多模态大模型发展的历史本质上也是几个关键指标被不断刷新的历史。参数量从亿级涨到万亿级上下文长度从 2K 扩到 1M输入从纯文本变成图文音视频混合每一步背后都有明确的工程或产品驱动力。2.1 参数量到底意味着什么很多刚接触大模型的人会问参数量越大是不是一定越聪明这里需要拆开看。参数量Parameters可以理解为模型的“记忆容量”和“建模能力”的综合体现。一个 7B70 亿参数模型能装下的知识量肯定比 1B 模型大得多但“更大”不等于“更好”还要看训练数据和训练方法的匹配度。GPT 系列的发展特别直观。GPT-1 有 1.17 亿参数效果只能用“能生成通顺句子”来形容GPT-2 跳到 15 亿参数已经可以生成有一定连贯性的文章GPT-3 直接干到 1750 亿参数才出现了“零样本学习”这种让人眼前一亮的能力。OpenAI 在这条路上验证了一个朴素但有效的规律当模型规模跨过某条线之后会涌现出小模型不具备的能力。不过这里有个容易被忽略的细节不是所有公司都有能力训练千亿参数模型。训练一个 175B 模型的算力成本对绝大多数团队来说是天文数字。所以后来业界分化出了两条路线要么堆超大模型追求极致能力要么用 7B、13B、70B 这种“中等规模”模型配合精细训练在特定领域做到够用。我自己的经验是70B 的模型在推理质量上确实比 7B 强不少比如在代码生成、长文本理解这些场景里差别很明显但 7B 模型经过好的微调在垂直领域也能打得过没有微调的 70B 通用模型。参数量的价值必须结合训练数据的质量和针对性来判断。2.2 上下文长度从 2K 到 1M 的工程突破上下文长度Context Length是另一个被疯狂内卷的指标。最早 GPT 系列只有 2048 个 token这就意味着你扔给它一篇文章它只能“看到”前两千来个 token 的内容再往后就直接忽略了。对于问答、摘要这类场景还好但如果你让它读一本书、分析一份财报、理解一个大型代码仓库那完全不够用。后来各家开始卷上下文窗口Claude 从 100K 干到 200KGemini 宣称 1M国产模型也有不少直接标配 128K。这个数字从 2K 涨到 1M表面上是“能读的东西变多了”本质上其实是工程上的巨大胜利。因为 Transformer 的注意力机制是 O(n²) 复杂度序列长度翻一倍计算成本涨四倍。想要支持超长上下文必须在注意力计算上做优化比如稀疏注意力、滑动窗口、KV Cache 压缩等。这里我建议所有做大模型应用的人一定要把“上下文长度”当成一个成本参数而不是“能力参数”来看。因为你的 prompt 越长模型推理的时间越长API 费用也越高。我在实际做 RAG 应用的时候就经常遇到“明明模型支持 128K但塞太多 token 之后首字延迟高得离谱”的情况。上下文长是能力上限但不是让你每次都顶着上限用的。2.3 多模态人类输入方式的回归大模型最早只能处理文本因为训练数据主要就是网页文本。但现在你打开任何一个主流大模型产品都可以直接上传图片、音频、视频这就是多模态化。多模态的路线有两种主要做法。一种是“拼接式”也就是把图片切成块之后也转成 token跟文本 token 一起丢进模型另一种是“统一式”从一开始就用一个模型同时处理多种模态的数据。2025 到 2026 年这段时间多模态大模型的进展特别夸张。图片问答已经不是简单的“这是什么”而是可以帮你分析图表、识别流程图、看图写代码。语音交互也做到了端到端低延迟。这背后的核心问题是不同模态的信息如何在同一个向量空间里对齐。文本里的“猫”和图片里的“猫”怎么让模型意识到它们是同一个概念这是多模态研究的核心难点。对于普通开发者多模态带来的直接机会是以前需要接一堆 OCR、语音识别、图像识别服务才能完成的任务现在一个模型全搞定。比如我最近在做的一个票据识别工具以前是“OCR 提取字段 规则解析 人工校验”三步走现在直接丢一张票据图片给多模态模型json 结构就出来了准确率还不低。这就是多模态大模型在工程上最直观的价值。3. 从论文到工程微调、量化、部署与私有化落地光会看论文、刷跑分不算真正理解大模型。无论你是做产品还是做研究迟早会走到这一步拿到一个开源模型想办法让它适配自己的数据再把它部署到自己的服务器上。这个过程里踩过的坑比想象中多得多。3.1 微调让通用模型变成行业专家大模型训练分两大阶段预训练Pre-training和微调Fine-tuning。预训练是花几百万美元在几千亿 token 的通用语料上训练基础模型让它学会“语言的一般规律”。微调则是在基础模型之上用更小规模的高质量数据做进一步训练让它学会某种特定风格或特定领域的知识。现在提到微调绝大多数时候指的是参数高效微调最主流的方法是 LoRALow-Rank Adaptation。LoRA 的思路不是去改原始模型的全部参数而是训练一个低秩矩阵作为“补丁”挂在原始模型旁边。这样做的好处非常明显显存占用低一张消费级显卡甚至都能跑。训练速度快不用动底层的几十亿参数。微调完只是一个几百 MB 的小文件随时可以热插拔。在实际操作中我建议刚上手的人不要一开始就微调。先用提示工程Prompt Engineering试试不行再考虑 RAG检索增强生成最后才轮到微调。因为微调虽然效果好但它需要准备数据集、调参数、防过拟合一份高质量的训练集可能就得准备两星期。我的经验是数据质量远比数据量重要。一份十万元的精品数据效果可能比一万条从网上爬来的杂数据还好。做微调的时候有四个核心超参很值得反复实验学习率Learning Rate一般从 1e-5 到 2e-5 起步太大容易训崩太小效果不明显。训练轮数Epoch3 到 5 轮是常见区间轮数太多容易过拟合。批次大小Batch Size受显存限制一般 1 到 8 之间梯度累积可以弥补小批次带来的不稳定。LoRA 秩Rank通常 8 到 64 之间秩越大能学到的信息越多但显存和过拟合风险也越高。3.2 量化与推理优化小显卡也能跑大模型微调完模型之后如果你打算在本地部署遇到的问题往往不是“效果行不行”而是“跑不跑得动”。一个 7B 模型如果用 FP16 精度加载光权重就要占 14GB 左右显存很多人的显卡只有 8GB、12GB。这时候就得用量化Quantization。量化的核心思想是把模型权重从高精度FP16/BF16压缩到低精度INT8/INT4让模型体积变小、推理速度变快代价是精度稍微损失一点。实际用下来INT8 量化在大多数任务上跟原始精度几乎没有区别INT4 会有轻微损失但可用性依然很高。目前最流行的量化工具是 llama.cpp 和 Ollama。llama.cpp 支持跑 GGUF 格式的量化模型Ollama 则把模型管理、量化、API 调用全部封装好了一个命令就能跑起来ollama run qwen2.5:7b说实话我第一次用 4GB 显存的旧笔记本跑通 7B 模型的时候挺惊讶的。虽然每秒只能输出几个 token但至少能跑通了。这说明量化对于个人开发者来说是刚需技术。推理阶段还有一个重要组件叫KV Cache。它缓存了历史 token 的 Key 和 Value 矩阵这样每次生成新 token 的时候不需要重新计算所有历史信息。代价是它会占用额外显存上下文越长KV Cache 越大。所以你会发现模型可以支持 128K 上下文但如果你真塞满 128K显存可能直接爆掉。3.3 企业私有化部署数据安全才是第一优先级很多企业不直接用公共 API是因为数据敏感性。比如医疗病历、金融交易记录、内部代码这些数据绝对不能离开企业的边界。所以“私有化部署”成了大模型落地最核心的场景之一。私有化部署的架构通常长这样模型层找一个开源基座模型Qwen、DeepSeek、LLaMA、GLM 等按需微调。推理引擎层vLLM、Ollama、LM Studio 或者 TensorRT-LLM 来把模型跑起来。应用层FastGPT、Dify 这类平台负责做知识库上传、工作流编排和 API 封装。外围服务向量数据库Milvus、Chroma、pgvector做 RAG 的检索再叠加一个权限管理。这套组合拳的好处是模型完全在自己手里数据不出内网同时还保留了对模型行为做审计的可能性。我提醒过很多人一个容易忽略的问题私有化部署并不等于“一劳永逸”。模型是要迭代的数据是要更新的安全补丁也是要打的。你以为私有化就没人能攻击你了其实针对本地模型的“投毒攻击”data poisoning和“越狱攻击”jailbreak都是真实存在的。做私有化不只是跑一个容器那么简单它是一个需要持续维护的系统工程。3.4 免费 API 与本地部署的取舍现在市面上有大量免费的模型 API 可以白嫖比如 DeepSeek、通义千问、智谱等各家都有自己的免费额度政策。对于程序员来说想快速做一个 Demo直接调免费 API 是最快的方式几分钟就能拿到返回结果。但“免费 API”有几个限制需要注意限流每分钟请求次数有限。上下文限制免费档一般比付费档短。数据政策有些免费 API 会声明数据可能被用于模型训练。模型版本滞后免费档通常跑的不是最新最强的模型。所以我的建议是开发调试阶段用免费 API 最划算生产环境要么买付费 API 拿 SLA要么私有化部署核心流程。不要把一个业务的命脉绑在免费 API 上哪天服务商改政策你连哭都来不及。4. 大模型评测、常见问题与避坑经验等你真正开始用大模型、做大模型会发现“能跑通”和“用得好”之间隔着一条巨大的鸿沟。下面是我在实际操作中总结出来的评测方法和高频踩坑记录。4.1 大模型怎么测才靠谱大模型的评测是个很微妙的事情。外行看跑分内行看场景。如果你只是拿着标准 benchmark比如 MMLU、GSM8K、HumanEval去对比两个模型很容易得出一个和实际体验完全不符的结论。原因很简单标准 benchmark 测的是“通用能力”但你的业务场景是具体的。比如你做一个法律文书生成工具一个模型在数学考试里拿 99 分另外一个只拿 70 分但后者对法条的引用准确性高很多那它在你的场景里就是更好的模型。我在评测一个模型的时候通常会搭一套“私有评测集”从真实业务数据中抽 50 到 100 条代表性问题。把同一个问题分别丢给多个模型拿到输出。请业务方同学或者领域专家人工打分或者按规则自动打分。这套流程看起来土但比任何公开跑分都管用。跑分只能给你一个初筛的方向真正做决定还是要落在业务数据上。而且要注意评测集的答案最好做成“参考答案 评分规则”因为大模型的输出往往不是唯一解太死板的校验规则容易误杀。另外现在有一些专门做模型评测的平台比如 OpenCompass、LMSYS Chatbot Arena它们收集大量用户的匿名投票来给模型排名。这种“真人盲测”的口味有时候比跑分更接近实际体验因为用户不会关心你用了什么技巧他们只关心“这个回答我用起来顺不顺”。4.2 数据标注与数据污染问题做微调或者评测的时候数据质量永远是首要问题。很多初学者直接去开源数据集上爬数据结果训练出来的模型不仅效果差还容易出现“答非所问”的情况。数据标注的时候我踩过几个大坑这里集中说一下标注者不作为让非专业人员瞎标数据里全是错误答案模型越训越笨。格式不统一有人用“问题... 回答...”这种格式有人用 JSON模型训练完连指令都识别不利索。缺乏困难样本训练集里全是简单问题模型学不到真正的推理能力一遇到稍微复杂的任务就崩。大模型数据标注还有一个特别的骗局用大模型标注大模型数据。比如你用 GPT-4 生成了一万条微调数据再拿这些数据去微调一个 7B 模型效果会和“蒸馏”有相似之处但如果你不加筛选就直接用往往会把 GPT-4 的幻觉也一并学了过来。正确的做法是要对生成的数据做人工抽检和清洗尤其是那类涉及事实性知识的问题必须人工核实答案的准确性。4.3 上下文长度与代码开发的实操问题许多开发者在用大模型辅助写代码时会遇到“模型上下文不够用”的情况。比如你想让它重构一个类但这个类有一百多行你还想让它参考另一个文件里的工具函数这加起来可能就超过上下文限制了。我常用的几种应对方案拆分任务把大任务拆成小任务每次只给模型一个文件的上下文。使用 RAG把代码库做索引让模型先通过检索找到需要的代码片段再拿去问答。优先选用支持长上下文的模型如果你确实需要让模型一次看完整份代码建议选 128K 以上的模型或者本地部署一个长上下文版本。还有一个小技巧写代码提示词的时候尽量让模型“先解释再写”。让它先说清楚思路再给代码比直接让它输出代码更能稳定拿到高质量结果。4.4 一个真实的避坑清单我在社区分享过一份“大模型落地避坑清单”这里挑几条最常被问到的展开讲讲。模型总是“一本正经胡说八道”怎么缓解 幻觉是当前所有大模型的通病。最有效的手段是让模型学会说“不知道”。你在系统提示词里明确写“如果信息不在提供资料中请直接回答‘未找到相关信息’”能明显减少胡编答案的情况。另外把答案的“出处”抓出来要求模型给出引用来源也能大幅提升可信度。模型越狱攻击怎么防 任何对外提供服务的模型都要考虑提示词注入Prompt Injection的问题。攻击者会在输入里塞一些恶意指令试图覆盖系统提示词。一个比较笨但有效的方法是对输出做校验确保模型输出的内容符合预期格式同时对输入做敏感词和异常模式过滤。涉及 RAG 的场景还要小心“检索结果投毒”攻击者把恶意文本排在检索结果前面诱导模型输出有害内容。用了 API 但响应特别慢是模型差吗 这是非常常见的问题。响应慢可能不是因为模型性能差而是因为你喂的上下文太长前面说过 KV Cache 的问题、服务器排队、或者你的网络出口有问题。排查顺序应该是先看 API 延迟指标再看输入 token 数量然后考虑切换到更快的推理引擎。本地跑模型总是 OOM显存不足怎么办 有三个方向换更小的量化版本比如 4bit调小最大生成长度或者切换到 CPU 推理虽然慢但至少能跑。如果你用的是 vLLM还可以开启“prefix caching”和“chunked prefill”来降低显存压力。4.5 国外开源生态与国产模型的互补目前开源大模型的生态已经相当丰富国外有 LLaMA、Mistral、Gemma 这些国内则有 Qwen通义千问、DeepSeek、GLM智谱、Baichuan 等。国产模型这几年的进步非常快尤其是在中文理解、长文本和代码生成这几个维度上很多开源版本的表现已经和国际一线模型处于同一梯队。我自己比较常用的组合是通用对话Qwen 系列中文好指令泛化能力强。代码生成DeepSeek 系列代码推理和补全效果非常突出。私有化部署7B 和 14B 级别的模型加 INT4 量化单卡就能跑。低成本高并发硬实力不够就搭配 vLLM 做吞吐优化。如果你有条件用国外模型做对比建议不要只看规模要多看具体任务上的实测效果。有些 7B 模型在代码场景的推理速度和质量真的比 13B 的通用模型还好。模型选型不是一个“越大越好”的单选题而是一个根据场景做匹配的多选题。5. 大模型学习路线从新手到上手的进阶路径最后这部分聊一聊“怎么学”。我经常看到有人一上来就买一堆大模型深度学习的课程或者直接去找论文原文结果不到两周就放弃了。原因是这条路太陡缺乏一个渐进的过程。5.1 新手期先会用再懂里如果你的目标是能上手做应用我建议第一步就是用 API。找任何一家支持免费额度的模型服务注册一个账号把官方文档里的第一个示例代码跑通你会获得第一次正向反馈。之后再尝试改改 prompt让它帮你写周报、翻译文本、总结文档慢慢建立对模型表现的直觉。这个阶段不用管什么微调、量化那些都属于工程优化问题。你需要理解的是“大模型能干什么、不能干什么、什么样的输入能得到什么样的输出”。至少要知道“上下文窗口”这个概念知道为什么同一个问题换个问法结果完全不同。当你能熟练使用三四个主流平台的 API 时就可以开始了解 Token 是怎么计算的、为什么计费按 Token 算而不是按字数算。这一步虽然简单但它会帮你建立对后续所有工程优化的基本意识。5.2 进阶期本地跑模型感受工程的“重量”当你对 API 的调用已经非常熟练下一步是尝试本地部署一个开源模型。你可以从 Ollama 开始它几乎把所有的环境配置全部封装掉了几条命令就能跑起来一个模型ollama pull qwen2.5:7b ollama run qwen2.5:7b跑通之后你会立刻遇到第一个现实问题我的显存不够。这个时候再引入量化、推理引擎等概念会比纯粹看文档理解得深得多。如果说调用 API 能让你学会站在岸上看游泳那本地部署就是让你真正下水扑腾感受水的阻力。这个阶段如果有余力建议自己动手把 vLLM 部署起来或者用 FastGPT/Dify 搭一个简单的知识库问答系统。这样你就把“模型 推理 应用”的完整链路都打通了真正进入大模型工程的世界。5.3 开拓期微调一个属于你自己的模型再往后就是微调。我不建议新手一上来就微调大模型但当你已经积累了足够多的“任务判断经验”比如你知道自己的业务场景里模型为什么回答不好、差在哪里这时候微调的价值才会真正体现。动手前先问自己三个问题我的任务里模型当前的失败点是什么提示词工程和 RAG 都已经试过了吗为什么还不够能不能拿出至少一两百条高质量的训练样本都确认了再去跑 LoRA。刚开始可以不用自己写训练代码用一些已经封装好的框架就行比如 LLaMA Factory、Axolotl。顺带提一嘴现在市面上的免费课程和 PDF 资源非常多找一套口碑好、更新及时的教程作为主线比零散地到处看博客效率高得多。但不管看什么教程记得一定要动手跑代码。大模型的学习本质上是在“踩坑中长出来的”。5.4 一点个人的经验总结写了这么多最后聊几句真心话。大模型发展史这条线看起来是各种技术名词的堆叠但真正理解它之后你会发现每个阶段的转折点都源于一个简单的追问“现在这个方案痛点到底在哪里”以我个人实际操作来看最有用的学习方法不是背熟多少篇论文而是“带着问题去看历史”。当你被长上下文显存问题折磨过一遍再去看稀疏注意力的论文会有一种豁然开朗的感觉。当你被模型幻觉坑过一次再去理解 RAG 的设计思想立刻明白那才是解决幻觉的第一优先级。所有的理论学习都要落到“能支撑你做出更好的工程决策”上这才是大模型笔记真正的意义。