【AI探索】程序员到底该怎么理解 LLM？

程序员三明治2026-04-20 9:12

👨‍💻程序员三明治 ：个人主页
🔥 个人专栏 : 《设计模式精解》 《重学数据结构》
《AI探索日志》 《从0带你学深度强化学习》

🤞先做到 再看见！

目录

你在公司里做了一套业务系统，可能是客服系统，也可能是内部知识库、工单平台，或者一套面向用户的问答模块。某天老板开会的时候突然提了一句：现在 AI 这么火，我们能不能也接一个进去，让它自动回答问题，或者帮我们处理一些文本类工作？

你第一反应大概率不是去翻论文，而是直接打开几个现成的产品试试。你可能会去问 DeepSeek、通义千问，或者别的聊天工具，把自己业务里的问题丢进去测一测。结果往往会让人眼前一亮：模型不仅能把话说通顺，还能理解你给它的上下文，甚至能帮你总结、归纳、改写。有些原来必须靠人工做的事情，突然看起来像是真的可以交给机器了。

但很快你就会发现，"觉得它厉害"和"把它接进系统里"其实是两回事。网页版产品是给人交互用的，不是给程序直接调用的。作为开发者，你接下来会碰到一连串非常现实的问题：DeepSeek、Qwen、ChatGPT 这些名字到底分别指什么？它们是产品名、模型名，还是平台名？网上经常看到的 7B、14B、72B 又是什么意思？大家天天说的 Token、上下文窗口、Temperature、Chat 模型、Base 模型，到底分别在讲什么？还有，为什么明明网页上就能聊天，开发者却还要去折腾 API？

这些问题如果不先理顺，后面你一旦开始接入模型、配置参数、做知识库问答，基本就是一边写代码一边猜。表面上好像已经开始做 AI 应用了，实际上很多概念都还混在一起，出了问题也不知道问题到底出在哪。

所以这一节不着急写代码，而是先把大模型这件事本身讲清楚。你可以把它看成后续所有实战内容的地基。先弄明白它是什么、为什么会有这么强的表现、开发者真正会接触到哪些核心概念，以及在工程里我们到底是以什么方式去使用它。把这些基础认知建立起来，后面不管是接 API、做 RAG，还是选模型、调参数，思路都会清楚很多。

一、大模型到底是什么

如果你是做业务开发的，对"把规则写进代码里"这件事一定非常熟悉。传统程序的基本思路就是：人先把规则想清楚，再把这些规则一条一条翻译成代码。程序能做什么，本质上取决于你事先把多少情况考虑进去了。

比如做一个最简单的客服自动回复，你可能会先写出这样的逻辑：

plain 复制代码 
if (question.contains("退货")) {
    return "请在订单详情页点击申请退货";
} else if (question.contains("发货")) {
    return "下单后 48 小时内发货";
} else {
    return "请联系人工客服";
}

这样的代码当然能跑，但问题也很明显。真实用户说话不会像写测试用例那样规范。用户想表达"退货"这个意思的时候，可能会说"我不想要了""买错了能退吗""这个东西怎么退""订单已经发了还能取消吗""商品拆开了还能退款吗"。从业务上看，这些问题都属于同一个意图；但从字符串匹配的角度看，它们却可能一个字都不一样。

这就是传统规则系统最典型的局限：它不是不能做，而是很难覆盖真实世界里复杂又多变的表达方式。你要想把所有说法都兜住，就只能不停加规则、补分支、堆关键词。最后系统会变得越来越脆弱------不是规则不够多，就是规则之间开始互相打架，维护成本也越来越高。

后来出现了一批传统 NLP 方法，比如关键词匹配、TF-IDF、朴素贝叶斯、文本分类器之类的技术。这些方法比纯手写 if-else 更进一步，因为它们开始利用统计特征来处理语言，不再完全依赖人工逐条穷举规则。它们在分类、检索、基础文本分析这些任务上，确实比最原始的规则系统强很多。

但本质上，这些方法大多数还是在"看词"和"算概率"。它们会关心哪些词出现得多，哪些词经常一起出现，某段文本更像哪一类，但它们并不真的像人那样理解语言中的语境、指代、隐含意图和复杂关系。你说"东西不想要了"，它可能能抓到"东西"和"不要"，却不一定能稳定地理解这句话在一个电商场景里其实是在表达退货诉求。

大模型把这个局面彻底改变了。

大模型的核心，不在于有人提前把所有规则都写好了，而在于它在训练阶段"读"了海量文本，从这些数据里自己学会了语言的组织规律。它读过的内容可能来自网页、书籍、论坛、百科、代码、问答语料等等。训练过程中，模型并不是被一条条地告知"遇到这种句子要怎么回"，而是通过不断处理大量文本，逐渐形成了一种对语言模式的整体把握。

你可以把这三种方式做一个很形象的对比。传统规则系统像是给新人发了一本操作手册，手册里写着遇到 A 就做 B，遇到 C 就做 D，手册没写到的情况它就不会处理。传统 NLP 则像是让这个新人去统计大量历史案例，看看哪些词常常一起出现，哪些表达更像某一类问题，它比纯手册更灵活，但仍然很难真正理解上下文。而大模型更像是让一个人长期阅读了海量文本，在大量真实语言场景里逐渐形成了语感、知识联想和表达能力。虽然它不是人，但从结果上看，它处理语言的方式已经更接近"通过学习形成能力"，而不是"通过人预设规则执行流程"。

所以当你问大模型"东西不想要了"，它之所以能理解你大概率是在问退货，不是因为某个工程师提前给它写了"东西不想要了 = 退货"的映射规则，而是因为它在训练过程中见过大量类似的说法，并从中学到了这类表达在相似场景下通常意味着什么。

二、大模型的"大"，到底大在哪

很多人第一次接触大模型时，会把"大"理解成模型文件很大、服务器很贵，或者感觉它"懂得很多"，但从技术上说，这个"大"最核心指的是参数量大。

你经常会看到一些模型名字后面带着 7B、14B、32B、72B 这样的标记。这里的 B 是 Billion，也就是十亿。7B 表示大约 70 亿参数，72B 表示大约 720 亿参数。参数量越大，模型内部可以容纳的表达关系和模式通常就越复杂，因此也往往意味着更高的能力上限。

那参数到底是什么？如果用一个容易理解的说法，你可以把它看作模型内部那一整套"权重连接"。模型在训练过程中，会不断调整这些数字，让自己对语言的预测越来越准确。最后训练完成时，真正被保存下来的，不是什么一条条自然语言规则，而是海量参数构成的数值系统。模型之所以能理解问题、关联上下文、生成回答，靠的就是这套参数系统在运转。

当然，这里要注意一点：参数不是知识点清单，也不是数据库记录。你不能把它理解成"模型肚子里背着一本百科全书"。更准确地说，参数是模型经过大规模训练之后形成的一种能力结构，它让模型具备了处理语言、迁移模式、组织表达和进行一定推理的能力。

参数越多，模型通常就越有机会学到更复杂的语言现象，也更容易在推理、代码、多轮对话、抽象总结这些任务上表现得更强。但代价也很直接：参数多，意味着部署成本更高、推理所需的显存和算力更多、响应速度可能更慢，调用 API 时的价格往往也更贵。

所以在工程里，一个非常重要但又很容易被忽略的事实是：模型不是越大越好，而是越合适越好。很多业务场景，比如企业知识库问答、简单客服、评论分析、文本分类、内容摘要，其实并不一定需要最顶级的大参数模型。一个中等规模、响应稳定、成本可控的模型，反而更适合真正落地。盲目追求最大参数，最后往往得到的是更高的账单和更慢的响应，而业务收益未必真的有质的提升。

换句话说，"参数大"说明的是潜力和能力上限，但做系统时，真正要考虑的是能力、成本、速度、部署方式之间的平衡，而不是只盯着参数数字做选择。

三、几个必须先搞懂的核心概念

在后面实际调用大模型 API 的时候，你会不断遇到几个高频概念：Token、上下文窗口、Temperature。这些词表面上看起来只是接口里的几个字段，但如果不理解它们，后面很多现象你都很难解释。比如为什么同样一句话换个写法价格就变了，为什么一段对话越聊越长模型开始"失忆"，为什么有时候模型回答特别稳定，有时候又显得很跳。

1. Token：大模型真正处理文本的单位

人平时看文本，会自然地按"字""词""句子"来理解。但大模型内部处理文本，并不是直接按汉字数或者单词数来算，而是按 Token 来算。你可以把 Token 理解成模型把文本切开之后得到的一种最小处理单元。

这个单元并不完全等于"一个汉字"或者"一个单词"。英文里，一个短单词可能就是一个 Token，但稍长一点的词也可能会被拆开；中文里，有时候一个汉字是一个 Token，有时候两个字、三个字会被合并成一个更适合模型处理的片段。所以 Token 更像是模型内部自己的"计量单位"，而不是我们平时写文章时理解的字数单位。

为什么开发者一定要关心 Token？原因非常现实，主要有两个。

第一，大多数大模型 API 都是按 Token 计费的。你发给模型的内容会消耗输入 Token，模型返回的结果会消耗输出 Token。提示词越长、上下文越多、模型输出越啰嗦，Token 消耗就越大，费用也就越高。很多人刚开始接模型时，只顾着能不能出结果，过一段时间回头一看账单，才意识到原来自己在提示词里塞了太多没必要的东西。

第二，大模型的"记忆容量"也是按 Token 来算的，而不是按字数或者段落数来算。这就引出了后面要说的上下文窗口问题。你能一次性塞给模型多少材料，本质上不是看 PDF 有几页，而是看这些内容最终会被切成多少 Token。

所以你不一定要学会精确估算每一句话的 Token 数，但一定要建立这个意识：大模型世界里的流量、成本和容量，基本都是围绕 Token 运转的。

2. 上下文窗口：模型不是无限记忆

很多人第一次用聊天模型时，会产生一种错觉，好像它真的"记得"你前面说过的所有内容。但实际上，模型并不像人那样有长期记忆。它在一次请求里能看到的文本量是有限的，这个上限就叫上下文窗口，也就是 Context Window。

你可以把它想象成一个大小固定的工作台。每次调用模型时，你放到这个工作台上的内容，包括 system prompt、历史对话、当前问题、附加资料、模型已经生成的部分内容，统统都要占用窗口空间。窗口一旦装满，前面的内容就只能被截掉。被截掉的部分，对模型来说就等于没看见。

这件事在日常聊天里可能还不够明显，但一旦做系统开发，影响会非常大。比如你做一个多轮对话助手，对话越来越长，前面早期说过的要求可能就会被挤出窗口，于是模型开始"忘记"之前的约束。再比如你做知识库问答，想把整篇产品手册、整份制度文档一次性塞给模型，让它自己去找答案，结果不是窗口根本放不下，就是虽然勉强放进去了，但因为信息太多太杂，模型很难抓住真正关键的片段。

这也是为什么 RAG 系统里不会简单粗暴地把整个知识库都送给模型，而是一定要先做检索，把最相关的几段内容挑出来，再和问题一起发给模型。这样做不是为了显得高级，而是因为上下文窗口是有限资源。你必须把有限的"注意力空间"优先留给最有价值的内容。

所以从工程角度看，上下文窗口不是一个抽象参数，而是直接决定了你怎么设计提示词、怎么组织历史对话、怎么拼接知识片段、怎么控制调用成本的关键约束。

3. Temperature：它控制的是"发散程度"

Temperature 常被翻译成"温度"，但这个名字很容易让人误解。它并不是在控制模型"智商高低"，而是在控制模型生成答案时的随机性和发散程度。

如果 Temperature 很低，模型在生成每一个 Token 时，会更倾向于选择当前概率最高、最稳妥的那个结果。这样生成出来的回答通常更稳定、更保守，也更容易复现。你多问几次同样的问题，得到的回答往往差异不大。这样的设定很适合那些要求准确、统一、不要自由发挥的场景，比如 RAG 问答、信息抽取、代码生成、结构化输出。

如果 Temperature 调高，模型在选择下一个 Token 时就会更"放得开"，不会总是死盯着概率最高的那条路，而是会在一批较高概率的候选里做更发散的选择。这样生成出来的回答通常更灵活、更多样，有时更自然，也更有创造性，但代价是更容易跑偏，甚至更容易出现不必要的编造。

所以 Temperature 本质上控制的，不是模型知道多少，而是它回答时"收不收""敢不敢展开"。在创意写作、文案发散、故事生成这些任务里，适当高一点的 Temperature 往往更有趣；但在知识问答和业务系统里，尤其是当答案应该严格依赖给定材料时，Temperature 通常要设得比较低。因为这时候你需要的是一个稳稳当当的整理者，而不是一个热爱发挥的写作者。

四、当前主流的大模型，应该怎么认识

如果你刚开始接触大模型，很容易被一堆名字绕晕。今天冒出来一个 GPT，明天又看到 Claude、Gemini、Llama、DeepSeek、Qwen、GLM、Kimi......每个系列下面还会再分不同版本、不同尺寸、不同能力方向。刚入门的时候，很多人最容易产生的困惑并不是"哪个最强"，而是这些名字之间到底是什么关系，我应该怎么建立一个清晰的认知框架。

这里其实有一个很重要的原则：对于应用开发者来说，你不需要一开始就把所有模型背全，也没必要天天追着排行榜跑。更重要的是，先建立一张"模型地图"，知道当前主流模型大致分成哪些阵营、各自擅长什么、适合什么使用方式。只要这个认知框架搭起来了，后面你再接触具体模型时，就不会总觉得所有名字都像随机字符串。

1. 国际主流模型：更像能力标杆和生态标杆

模型系列（举例） 厂商 特点 是否开源
GPT 系列（GPT-5.2 / GPT-5.2 pro 等） OpenAI 综合能力与生态最成熟；推理、工具调用、Agent 工作流能力强 否
Claude 系列（Claude Opus 4.6 / Sonnet 4.6） Anthropic 代码与长上下文能力突出；"computer use/代理"能力强；安全与对齐投入大 否
Gemini 系列（Gemini 3.1 Pro / Gemini 3 Flash） Google 原生多模态（文/图/音/视频）；超长上下文（最高 1M）；与 Google 生态结合紧密 否
Llama 系列（Llama 4 Scout / Maverick） Meta 开放权重生态最强之一；社区活跃、部署与微调方案成熟；MoE + 多模态 是（开放权重）

先看国际主流模型。这个阵营里最常被提到的，通常是 OpenAI 的 GPT 系列、Anthropic 的 Claude 系列、Google 的 Gemini 系列，以及 Meta 的 Llama 系列。虽然它们定位不完全一样，但你可以把它们理解为目前全球大模型生态里最有代表性的几条技术路线。

OpenAI 的 GPT 系列之所以长期处在讨论中心，不只是因为它最早把大模型产品真正带到大众视野里，更因为它在 API 生态、工具调用、多轮交互、Agent 工作流等方面形成了一套很强的工程范式。很多开发者第一次正式接触大模型开发，几乎都是从"兼容 OpenAI 接口"开始的。换句话说，GPT 系列不只是一个模型家族，它还在很大程度上定义了行业里"模型该怎么被调用"的接口习惯和产品范式。

Claude 系列则经常被人放在"代码能力强、长文本处理强"的位置上讨论。它在长上下文、复杂文档阅读、代码理解和安全对齐这几个方面一直很有存在感。很多人用 Claude 的第一感觉不是"它特别会聊天"，而是"它在面对长材料、复杂任务时显得比较稳"。这让它在文档处理、代码辅助、长链路分析这类场景里有很高的关注度。

Gemini 系列的突出特点则是多模态和超长上下文。Google 这条线一直比较强调文本、图像、音频、视频等多种信息的统一处理能力，同时也在极长上下文场景上持续发力。所以如果你的应用涉及复杂资料阅读、多模态输入、超长文档理解，Gemini 这类模型就经常会被拿出来作为一个重要选项。

Llama 系列有点不一样。它最大的意义不完全在于"在线服务能力最强"，而在于它是开放权重生态里非常关键的一条主线。很多本地部署、微调、蒸馏、量化、推理框架适配，都是围绕 Llama 生态快速成熟起来的。对很多做工程的人来说，Llama 的价值不只是模型本身，更在于它推动了整套开源部署生态的发展。

不过，站在国内开发者的视角看，这些国际模型虽然非常重要，但在实际使用中通常会受到一些现实因素影响，比如网络环境、调用成本、区域可达性、中文表现稳定性等等。所以你要认识它们，但不一定要把它们作为自己一开始落地应用时的首选。

2. 国内主流模型：和工程落地的距离更近

如果把视角拉回到国内应用开发，真正和大多数开发者距离更近的，通常还是国内这几条主流模型线，比如 DeepSeek、Qwen、GLM、Kimi、MiniMax 等。它们之所以越来越重要，并不只是因为"国产"这个标签，而是因为在中文场景、调用便利性、成本控制和开放生态上，确实越来越有竞争力。

其中最值得重点关注的两条线，通常还是 DeepSeek 和 Qwen。

DeepSeek 这条线近两年出圈得非常厉害，核心原因不是宣传做得好，而是它在"高能力 + 高性价比"这件事上做得非常极致。尤其是 DeepSeek-R1 这种推理取向很强的模型，让很多开发者第一次强烈感受到：原来开源或开放权重模型，也可以在数学、代码、规划、分析这些高难度任务上表现得这么猛。再加上它在社区里的传播速度很快、话题度很高，所以现在很多人提到国内大模型，DeepSeek 几乎已经成了绕不开的名字。

Qwen 则是另一种优势。它最强的地方并不单点，而是模型谱系很完整，中文能力稳定，而且生态非常成熟。从小尺寸模型到大尺寸旗舰模型，从本地部署到 API 调用，从 Hugging Face 到各类推理框架和平台适配，Qwen 这条线都铺得比较全。对于做业务系统的人来说，这种"全尺寸覆盖 + 中文稳定 + 工程适配完整"的特性，其实非常重要，因为它意味着你从学习、实验到正式落地，整个路径会比较顺。

除此之外，像智谱的 GLM、月之暗面的 Kimi、MiniMax 这些系列，也各有自己的发力方向。有人更强调长上下文，有人更强调 Agent，有人更强调复杂工程任务和多轮规划能力。你可以先有一个总体印象：国内模型已经不是"能不能用"的问题，而是开始进入"怎么选更合适"的阶段了。这和前几年的状态已经很不一样了。

3. 应用开发者到底该怎么选模型

GPT-5.2 pro OpenAI 未公开 400K 否 强推理 + 工具/多轮交互；旗舰 API 能力
Claude Sonnet 4.6 Anthropic 未公开 200K（默认）/ 1M（Beta） 否 代码与长上下文强；computer-use/Agent 能力突出
Gemini 3.1 Pro Google 未公开 1M 否 原生多模态；长上下文；适合复杂资料/代码库
Llama 4 Maverick（17Bx128E） Meta 400B（17B 激活，MoE） 1M 是（开放权重） 多模态 + MoE；本地部署/微调生态成熟
DeepSeek-V3.2（deepseek-chat） 深度求索 671B（37B 激活，MoE） 128K 是（MIT） 通用 + Agent 取向；支持 Thinking in Tool-Use；性价比高
DeepSeek-R1（deepseek-reasoner） 深度求索 671B（37B 激活，MoE） 128K 是（MIT） 深度思考推理；数学/代码/规划强
Qwen3.5-397B-A17B 阿里巴巴 397B（17B 激活，MoE） 262K 是（Apache-2.0） 旗舰开放权重；偏 agentic；长上下文更强
Qwen3-32B 阿里巴巴 32B 32K（原生）/ 131K（YaRN） 是（Apache-2.0） 中大型开源；适合私有化、RAG、微调
Qwen3-8B 阿里巴巴 8B 32K（原生）/ 131K（YaRN） 是（Apache-2.0） 轻量部署；成本敏感/边缘侧更友好
GLM-5 智谱 AI（Z.ai） 744B（40B 激活，MoE） 200K 是（MIT） 面向 Coding/Agent；长上下文 + 高输出上限（128K）

很多人看完一圈模型介绍之后，会马上问：所以到底哪个最好？但这个问题本身，其实不太适合用来指导工程实践。因为对开发者来说，真正有价值的问题不是"谁绝对最强"，而是在我的场景里，什么模型最合适。

如果你的业务以中文为主，而且更看重接入成本、访问便利性和整体投入产出比，那么 DeepSeek、Qwen 这种路线通常会比一上来就硬上顶级国际闭源模型更现实。因为你最终不是在做模型评测，而是在做一个真正要上线、要跑业务、要算成本、要控制响应时间的系统。

模型选择其实更像是一道综合题。你需要同时考虑这些因素：任务到底偏推理、偏问答、偏总结，还是偏创作；对中文能力有没有硬要求；是打算直接调 API，还是以后可能考虑私有化；调用预算有多高；对速度的要求严不严；你的系统面对的是内部员工还是外部用户；回答是允许一定自由发挥，还是必须尽量稳定保守。只有把这些因素一起放进来，你才有可能做出合理选择。

所以，建立模型认知的重点从来不是"背模型名"，而是知道不同模型背后的能力取向、部署方式和适用场景。只有这样，后面你真的要接模型的时候，思路才会清晰。

五、Chat 模型，才是开发时真正会反复打交道的东西

前面说了很多"大模型"，但这里有一个非常重要的区分，必须单独拎出来讲清楚：大模型不等于聊天模型，聊天模型也不是模型最原始的形态。

这是很多人一开始最容易混淆的地方。你平时在网页上打开一个对话框，和模型一来一回聊天，于是自然会觉得"大模型本来就会聊天"。但从训练过程和模型形态上看，事情并不是这样。

1. Base Model：它最原始的能力，其实是续写

一个语言模型在最开始训练完成之后，得到的通常是所谓的 Base Model，也就是基座模型。基座模型最核心的能力，不是"理解人类指令"，也不是"扮演助手"，而是根据已有文本去预测接下来最可能出现的内容。说得更直白一点，它最本质的工作方式就是：续写。

比如你给它一句"春天来了，天气开始变得"，它会往后接"温暖""暖和""宜人"之类的词；你给它一句"Java 中可以使用 try-catch 来处理"，它会接"异常"。它之所以能这么做，是因为在训练中，它一直在做类似"看前文、猜后文"的事情。

这意味着，Base Model 并不是天然擅长"按指令完成任务"的。你让它根据一段用户反馈只输出"正面/负面/中性"，它未必会老老实实给你一个分类结果，它很可能继续把你的输入往后写成一段完整说明。不是它故意不听话，而是它在训练时本来就不是围绕"指令遵从"这件事塑造出来的。

所以从模型原始能力来看，Base Model 更像一个极其强大的语言续写器。它已经学到了大量语言规律，也具备很强的潜在能力，但还没有被进一步"塑造成一个会配合人类完成任务的助手"。

2. Chat Model：它是经过"对齐"之后才变得会聊天的

要让模型真正能听懂"请你做什么"，仅靠预训练是不够的。模型还需要经历后续的对齐过程，比如指令微调、偏好优化、RLHF 之类的方法。经过这些训练之后，模型才逐渐学会：用户说一句话，不一定是在要求续写文本，更可能是在发出一个任务指令；回答时不只是要语法通顺，更要符合要求、遵守格式、控制风格、注意安全边界。

这一阶段训练之后得到的，就是大家平时最常接触到的 Chat Model，也常常叫 Instruct Model。和 Base Model 相比，Chat Model 更像是一个被"教会如何与人协作"的版本。它不仅有语言能力，还学会了如何接收指令、如何遵循角色设定、如何按要求输出内容。

你可以把这两者做一个很形象的类比。Base Model 像一个读了无数书、知识很多的人，但别人问它问题时，它未必知道你想要什么形式的回答；Chat Model 则像这个人后来又接受了专门训练，学会了如何理解任务、如何按要求回应、如何在交流里更像一个真正的助手。

所以开发者在日常接 API 时，真正会反复打交道的，几乎总是 Chat Model，而不是最原始的 Base Model。

3. 为什么 RAG 系统基本都只用 Chat 模型

这个问题其实顺着上面的逻辑很好理解。RAG 的最后一步，本质上是让模型去做一件很明确的事情：读取一批已经检索出来的资料，理解用户提出的问题，然后基于这些资料组织出一个回答。这里面最关键的不是"自由生成"，而是"理解指令 + 根据给定上下文回答"。

而这正是 Chat 模型最擅长的事情。

如果你把同样一份"问题 + 检索片段"直接丢给一个 Base Model，它未必会老老实实回答问题，反而可能继续顺着输入写下去，或者生成一些不符合任务要求的内容。原因很简单，它的能力重心本来就在续写，不在"遵循人类任务指令"。

所以对应用开发者来说，这件事几乎可以当成一个默认常识：做 RAG、做智能客服、做文档问答、做结构化提取，绝大多数时候你用的都应该是 Chat 模型。

六、本地部署时绕不开的一个词：量化

前面一直在说参数、显存、模型大小，这里就自然要引出另一个实际问题：为什么同样一个模型，有时候原版很大，量化版却小很多？以及，量化到底在量什么？

什么是量化

大模型的参数本质上就是一堆数字（权重）。

这句话怎么理解？你可以把大模型想象成一个巨大的打分表。当你输入一句话时，模型会把这句话拆成一个个词（token），然后通过成千上万层的计算，最终算出下一个词最可能是什么。而每一层计算里用到的那些乘法系数、加法偏移量，就是所谓的参数------它们都是具体的数字，比如 0.0012、-1.357、0.889 这样的小数。

举个简化的例子：假设模型要判断"今天天气"后面接什么词，它内部可能有这样的计算：

plain 复制代码 
"晴" 的得分 = 输入向量 × 0.82 + (-0.15) = 3.7
"雨" 的得分 = 输入向量 × 0.41 + 0.23 = 1.2

这里的 0.82、-0.15、0.41、0.23 就是参数（权重）。模型在训练阶段通过海量文本不断调整这些数字，让它的打分越来越准。训练完成后，这些数字就固定下来，保存成文件------这就是你下载到的模型文件。

所谓 7B 模型有 70 亿参数，意思就是模型里有 70 亿个这样的数字。训练时这些数字通常用高精度的浮点数存储，比如 FP16（16 位浮点数）或 BF16（16 位脑浮点数），每个参数占 2 个字节。一个 7B 的模型，光是存储权重就需要约 14GB 显存。

在展开量化之前，先搞清楚这些精度格式到底是什么。

浮点数精度：FP32、FP16、BF16 都是什么

计算机用浮点数来表示带小数点的数字。一个浮点数由三部分组成：

  • 符号位（Sign）：1 位，表示正数还是负数
  • 指数位（Exponent）：决定数字的范围（能表示多大或多小的数）
  • 尾数位（Mantissa / Fraction）：决定数字的精度（小数点后能精确到第几位）

打个比方：假设你在一张小纸条上写快递地址，但纸条大小有限，总共只能写一定数量的字：

  • 符号位就像写"寄/退"：只需要 1 个字，表明方向
  • 指数位就像写"省市"：字数越多，能定位到的地理范围越精确（只写"广东"还是能写到"广东省深圳市"）
  • 尾数位就像写"门牌号"：字数越多，地址越精确（写到"xx 小区"还是能精确到"xx 栋 xx 室"）

纸条就那么大，给"省市"多写几个字（指数位多），能覆盖的范围就更大；给"门牌号"多写几个字（尾数位多），定位就更精确。不同的浮点格式，本质上就是在"范围"和"精度"之间做不同的取舍：

格式 纸条大小（总位数） 省市部分（指数位） 门牌号部分（尾数位） 能寄多远（数值范围） 地址能写多细（精度）
FP32 32 格（4 字节） 8 格 23 格 全球都能寄（±3.4×10³⁸） 精确到xx栋xx单元xx室
TF32 19 格（NVIDIA 专用） 8 格 10 格 全球都能寄（同 FP32） 精确到xx栋xx单元
BF16 16 格（2 字节） 8 格 7 格 全球都能寄（同 FP32） 只能到xx栋
FP16 16 格（2 字节） 5 格 10 格 只能寄本省（±65504） 精确到xx栋xx单元

可以看到关键的区别：

  • FP32 纸条最大，省市和门牌号都写得很详细，但太占空间
  • TF32 是 NVIDIA 把 FP32 的门牌号砍短了，范围不变但精度降低，GPU 内部自动使用
  • BF16 省市部分和 FP32 一样详细（8 格），所以范围一样大，但门牌号只剩 7 格，精度最低
  • FP16 把更多格子给了门牌号（10 格），精度比 BF16 高，但省市部分只有 5 格，能覆盖的范围小很多

用一句话总结每种格式的特点：

格式 位数 每参数占用 核心特点
FP32 32 位 4 字节 传统的"全精度"，范围大、精度高，但太占显存，现在很少直接用来存模型权重
TF32 19 位 --- NVIDIA Ampere 架构（A100 等）引入的格式，保留 FP32 的范围但砍掉一半精度，GPU 内部自动使用，开发者一般不用管
FP16 16 位 2 字节 "半精度"，体积是 FP32 的一半，但能表示的数值范围很小（最大约 6.5 万），训练时容易溢出
BF16 16 位 2 字节 Google 提出的"脑浮点"，和 FP16 一样大，但把更多位数分给了指数（范围和 FP32 一样大），牺牲了一点精度换来了训练稳定性

FP16 和 BF16 同样都是 16 格的纸条，但分配方式完全不同：

  • FP16：省市部分只给了 5 格，门牌号给了 10 格 → 地址写得很细，但只能寄本省，寄远了就"查无此地"（术语叫溢出）
  • BF16：省市部分给了 8 格，门牌号只剩 7 格 → 全球都能寄，但地址写得比较粗，可能只到楼栋级别

打个比方：FP16 就像一个只做同城配送的快递员，他能把包裹精确送到你家门口，但出了本市就没辙；BF16 则像一个全国快递员，哪个省都能送到，但可能只送到小区门口，最后几百米得你自己走。

对于大模型训练来说，参数的数值变化范围非常大，如果"寄不到"（溢出）就直接算错了，而"地址粗一点"（精度低一点）影响没那么致命。所以 BF16 成了目前大模型训练和推理的主流选择。

你在 Hugging Face 上看到的大多数模型，默认权重格式就是 BF16。当我们说"原始精度"或"未量化"时，通常指的就是 BF16（而不是 FP32）。

量化：用更低的精度换更小的体积

理解了上面的精度格式之后，量化就很好理解了------它就是把模型权重从 BF16/FP16（16 位）进一步压缩到更低的位数，比如 INT8（8 位整数）或 INT4（4 位整数）。精度降低了，每个参数占用的空间也就小了：

精度 每个参数占用 7B 模型显存估算 说明
FP32 4 字节 ~28 GB 全精度，现在基本不用来存储模型权重
BF16 / FP16 2 字节 ~14 GB 当前模型的默认精度
INT8 1 字节 ~7 GB 轻度量化，效果损失很小
INT4 0.5 字节 ~3.5 GB 主流量化选择，效果有一定损失但通常可接受

上面的显存估算只是模型权重本身的大小。实际运行时还需要额外的显存用于 KV Cache（存储上下文信息）、计算中间结果等，所以真实显存占用会比表格中的数字更高。一般建议预留权重大小 1.2~1.5 倍的显存。

常见的量化格式

在 Hugging Face 上下载模型时，你会看到各种量化后缀，主要有这几种：

格式 全称 特点
GPTQ GPT Post-Training Quantization 需要 GPU 推理；量化后精度较好；社区支持广泛
AWQ Activation-aware Weight Quantization 需要 GPU 推理；比 GPTQ 更快，精度相当；较新的方案
GGUF GPT-Generated Unified Format 支持 CPU 推理（也支持 GPU）；llama.cpp 生态的标准格式；适合没有独显或显存不够的场景

简单来说：有 NVIDIA 显卡优先选 AWQ 或 GPTQ，显卡不够或者想用 CPU 跑就选 GGUF。

量化等级怎么选

以 GGUF 格式为例，你经常会看到 Q4_K_M、Q5_K_M、Q8_0 这样的标注，数字越大精度越高、文件越大：

  • Q4_K_M：4 位量化，体积最小，适合显存紧张的场景，是性价比最高的选择
  • Q5_K_M：5 位量化，效果和体积的平衡点
  • Q8_0：8 位量化，接近原始精度，但体积也大得多

对于大多数本地部署场景，INT4（Q4_K_M）就够用了。除非你对输出质量有很高的要求，否则没必要追求更高精度。

开发者需要关心吗

如果你通过 API 调用模型（比如调用 SiliconFlow、硅基流动等平台上的模型），量化这件事完全不用关心------平台方已经帮你处理好了部署和优化。

只有在本地部署模型时，你才需要根据自己的硬件条件选择合适的量化版本。关于本地部署的完整流程（包括如何选模型、选量化、配置推理框架等），后续在讲解本地部署模型时会详细说明。

七、所谓"深度思考"，到底是什么东西

如果你用过一些带推理能力的模型，尤其是像 DeepSeek-R1 这样的模型，可能会注意到一个现象：有些模型会提供"深度思考"模式，开了之后回答速度明显变慢，但在逻辑题、数学题、复杂分析和代码规划这类问题上，结果往往更靠谱。

很多人第一次看到这个功能，会把它理解成"开关一打开，模型就变聪明了"。这个理解不能说完全错，但它太粗了。更准确地说，所谓深度思考，本质上是让模型在回答之前先经历一个更充分的中间推理过程，而不是直接从问题跳到答案。

1. 普通回答和"先想再答"的区别

日常聊天模式下，模型通常是看到问题后就开始直接生成回答。对于一些简单任务，这完全没问题。比如你问"Java 里怎么读取 JSON 文件"，这类问题本身就不需要复杂推导，模型直接给出常用写法就行。

但如果问题本身需要多步推理，比如一道数学题、一段复杂逻辑分析、一个需要拆解步骤的系统设计题，那么"直接跳答案"就很容易出错。不是因为模型完全不会，而是因为这类任务本来就更适合先分解、再推演、最后收束成结论。

所以所谓深度思考，你可以把它理解成让模型别急着开口，而是先在"草稿纸"上算一遍。这个草稿过程展开得越充分，复杂任务的正确率通常就越高。

2. 思维链为什么会提升复杂任务表现

这背后的核心思想，其实就是大家常说的 Chain of Thought，也就是思维链。它的本质不是多么神秘的技术，而是一个很符合直觉的原理：复杂问题如果分步骤展开处理，通常比一句话直接拍结论更稳。

人类自己也是一样。很多题你心算容易错，写出中间过程反而更不容易翻车。模型也是类似的。当它把问题拆开，一步一步分析条件、推导关系、检查中间结果时，整体就更容易走在正确的轨道上，而不是凭着局部概率直接"蹦"出一个看似流畅但其实有问题的答案。

所以从表面上看，深度思考像是在"显示模型的推理过程"；但从本质上说，它真正起作用的地方在于：让模型在生成最终答案之前，先完成一轮更稳定的内部推导。

3. 深度思考并不适合所有场景

理解了这一点之后，一个很重要的结论自然就出来了：深度思考不是越多越好，也不是所有任务都值得开。

因为这个过程会带来两个非常实际的代价。第一，它更慢。模型多想一步，响应时间自然就会更长。第二，它更贵。因为中间推理内容也会消耗 Token，等于同一个问题花了更多的上下文和生成成本。

所以真正适合开深度思考的，通常是那些确实需要"走推理链路"的任务，比如数学计算、复杂规划、方案对比、长链路代码设计、逻辑严密的分析。而像日常问答、简单知识查询、基础改写、一般总结这类任务，往往没有必要特地进入深度思考模式。因为这时候模型不是不会做，而是任务本身不值得花那样的推理成本。

对于 RAG 场景尤其如此。RAG 的核心是"检索出正确材料，再让模型整理表达"。在这个场景里，答案原则上已经存在于检索片段中，模型更多是在做理解、提取和组织，而不是在做原创推导。所以绝大多数 RAG 问答，其实不需要重推理模式，普通 Chat 模式加上较低 Temperature 往往就够了。这样既更快，也更省 Token，而且通常还更稳。

八、为什么开发者最终一定会走向 API，而不是停留在网页端

到这里，你对模型本身已经有了一套比较完整的认识。但从开发视角看，还有一个问题迟早要面对：既然我已经能在网页上和模型对话了，为什么还非得去折腾 API？直接让同事用网页版不行吗？

这个问题非常常见，而且它背后其实隐含着一个关键认知：模型产品和模型能力，不是同一件事。

1. 网页端只是把能力"包装"成了产品

你在网页上打开一个聊天界面，输入一句话，几秒之后得到回答。这个体验很顺滑，所以很容易让人觉得"我是在直接使用模型"。但从系统角度看，网页端只是一个产品外壳。你敲下问题之后，浏览器会把内容发给服务端，服务端再去调用模型，模型生成结果后返回，再由网页展示出来。

换句话说，你在网页端看到的所有交互，本质上仍然是一次模型调用，只不过产品方把中间过程都封装好了。输入框、会话列表、历史记录、参数开关、展示效果，这些都只是围绕模型能力搭出来的用户界面。真正发生"理解文本并生成回答"的地方，仍然是在底层模型服务那里。

以下是DeepSeek与你进行交互
的流程图：

这意味着一个非常重要的事实：网页不是能力本体，API 才是开发者真正接入能力的入口。

2. 网页端为什么不适合系统集成

对个人体验来说，网页端当然很方便。你打开就能聊，不用写代码，也不用申请接口。但一旦进入工程场景，它的问题就会迅速暴露出来。

首先，网页端不能直接嵌入你的业务流程。你的 Java 服务、Spring Boot 项目、Node 应用、客服后台，不可能靠人工打开网页、复制粘贴问题、再把答案拷回系统里。这种方式在试用阶段勉强可以，真正上线根本不成立。

其次，网页端无法支持批量任务。你要分析上千条评论、处理几万条工单、给整个知识库做自动摘要，不可能靠人一条条往对话框里贴。系统化处理一定要求程序能自动发起请求、自动拿到结果、自动进入后续流程。

再次，网页端对提示词和参数的控制能力通常非常有限。真正做系统时，你往往需要自己定义 system prompt，需要控制 temperature、最大输出长度、上下文拼接方式，甚至还要控制输出 JSON 格式、工具调用方式、检索片段组织策略。这些能力，通常都只能在 API 层真正细粒度控制。

更关键的是，网页端没有办法承接完整的 RAG 流程。RAG 不是单纯"把问题交给模型"，而是要先查知识库、再做召回和排序、然后把选中的片段和问题一起组装成一个请求发给模型。这个过程本质上是一整套程序链路，而不是一个人对着网页提问能替代的。

所以从工程视角看，网页端更像一个演示窗口，适合体验、适合验证感觉、适合快速试一试模型能不能做某件事；而 API 才是真正能把模型接进系统、变成业务能力组件的方式。

3. API 的本质：把大模型当成一个远程函数

一旦从开发者视角来理解，大模型 API 其实并不神秘。你完全可以把它想象成一个远程函数服务。你把一段结构化请求发过去，请求里包括模型名、system prompt、用户输入、参数配置；模型处理完之后，再返回一个结果。整个过程和调用一个远程接口没有本质区别，只不过这个接口背后不是业务数据库，而是一个大语言模型。

也正因为如此，模型能力才能真正被接到各种系统里去。你可以让它成为客服系统里的回复引擎，让它成为知识库问答系统里的生成器，让它成为工单分析里的分类器、报表摘要里的总结器、代码辅助里的建议器。模型不再是一个单独打开的网站，而是你系统架构中的一个通用语言处理组件。

当你建立起这个理解之后，后面很多事情就会自然了。为什么要做提示词工程？因为你在给这个"远程函数"组织输入。为什么要做 RAG？因为你想在调用前先给它补充业务上下文。为什么要选模型？因为你在为这个"组件"挑一个更适合当前任务的引擎。为什么要控制 Temperature？因为你希望这个组件的输出更稳定或者更发散。

这样一来，大模型就不再是一个模糊的"AI 黑盒"，而是一个你可以在系统里编排、约束、调用和优化的能力模块。

九、这一节真正要建立起来的，到底是什么认知

如果把前面所有内容收一收，你会发现这一节其实不是在教你背术语，而是在帮你搭一个理解大模型的基础框架。很多人学 AI 应用开发，一开始最容易犯的错，就是直接冲着代码和接口去，结果写了半天，连自己调的到底是什么能力都没完全想清楚。这样当然也能把功能做出来，但一旦遇到选型、调参、效果不稳定、成本失控这些问题，就很容易陷入一种"能试，但说不明白"的状态。

真正有用的基础认知，其实就是这么几件事。

第一，要明白大模型不是一套手写规则，而是一种通过海量训练学到语言模式的能力系统。它之所以强，不是因为有人替你把所有问答都提前写进去了，而是因为它在大规模文本中学到了表达、关联、归纳和一定程度上的推理能力。

第二，要明白"大"主要指参数量大，但工程里选模型从来不是只看参数。参数越大，能力上限通常越高，但成本、延迟、部署复杂度也会更高。真正做系统时，永远是在能力、速度、成本之间找平衡。

第三，要明白 Token、上下文窗口、Temperature 这些概念不是接口里的装饰字段，而是直接决定成本、容量和输出风格的关键控制项。它们看起来像小参数，实际上会深刻影响系统效果。

第四，要区分 Base Model 和 Chat Model。你平时开发里真正调用的，几乎总是 Chat 模型，因为你的任务不是让模型自由续写，而是让它理解指令、结合上下文、按要求输出结果。

第五，要明白网页端只是体验入口，API 才是工程接入方式。只有通过 API，大模型能力才能真正进入你的系统，参与业务流程，变成一个可编排、可控制、可扩展的能力组件。

这几点一旦理顺，后面很多事情就会顺畅很多。你再去看"如何调用模型 API""如何做知识库问答""如何做 RAG 检索增强""如何控制提示词和输出格式"，都会有一种思路被打通的感觉。因为你不再只是知道怎么发请求，而是开始真正理解：这个请求到底是在驱动一个什么样的系统。

十、小结：先别急着写代码，先把模型这件事看清楚

很多开发者第一次接触大模型时，最容易被吸引的是它"看起来什么都能做"的那种震撼感。你问它问题，它能答；你给它文档，它能总结；你给它代码，它能解释；你让它写文案，它也能写。于是很自然就会想马上把它接进项目里。

但真正做工程时，热情只是开始，理解才是关键。你必须先搞清楚：它到底是什么能力、它和传统规则系统有什么本质不同、参数量意味着什么、为什么 Token 和上下文窗口会影响你的系统设计、为什么有的场景要低 Temperature、为什么 RAG 里通常只用 Chat 模型、为什么网页版再好用也不能替代 API。

这些问题如果不先理顺，后面你做出来的东西就很容易停留在"能演示"的阶段，而不是"能稳定落地"的阶段。相反，如果这些基础概念都清楚了，那么大模型在你眼里就不再是一团模糊的潮流名词，而会变成一种可以理解、可以调用、可以纳入系统架构的工程能力。

这也是这一节最重要的目标：不是让你一下子变成模型专家，而是先建立起一个足够扎实的认知底座。只有底座稳了，后面无论是 API 接入、模型选型、RAG 实现，还是更复杂的 Agent 工作流，才真正有可能做得清楚、做得稳。

如果我的内容对你有帮助，请辛苦动动您的手指为我点赞，评论，收藏。感谢大家!!

相关推荐
飞Link6 分钟前
智能体时代的“紧箍咒”：深度解析 Agent 治理架构与 AI 杀伤开关
人工智能·架构
飞Link11 分钟前
2000 亿砸向算力：字节跳动 AI 基建跨越，后端与运维的“万亿 Token”生死战
运维·人工智能
marsh020618 分钟前
45 openclaw集群部署与扩展：应对流量峰值的高可用方案
ai·编程·技术
zhangfeng113324 分钟前
小龙虾 wordbuddy 安装浏览器控制器 agent-browser npm install -g agent-browse
前端·人工智能·npm·node.js
阿里云大数据AI技术24 分钟前
一条 SQL 生成广告：Hologres 如何实现素材生成到投放分析一体化
人工智能·sql
liudanzhengxi33 分钟前
GitSubmodule避坑全攻略
人工智能·新人首发
用户4252108006034 分钟前
Claude Code Linux 服务器部署与配置
人工智能
OJAC11137 分钟前
学过Python却不敢投AI岗，他最后拿下12K offer
人工智能
Bigger38 分钟前
因为看不懂小棉袄的画，我写了个 AI 程序帮我“翻译”她的世界
前端·人工智能·ai编程
CeshirenTester40 分钟前
LangChain的工具调用 vs 原生Skill API：性能差在哪儿？
java·人工智能·langchain
热门推荐
01GitHub 镜像站点02Codex 接入 DeepSeek API 完整配置文档03零基础教你claude code 接入 deepseek V404CC-Switch & Claude 基于 Linux 服务器安装使用指南05【AI】2026 年具身智能模型和世界模型总结06要裂开了！ChatGPT要手机号验证了？注册Codex要求验证电话号码怎么办？2026年登陆Codex要手机号验证的解决办法07Windows端Codex接入第三方模型（DeekSeek，BaiLian)08裂开！ChatGPT 居然开始要手机号验证，附详细解决方法09Dirtyfrag漏洞：我花了一下午搞清楚这个Linux内核提权漏洞到底在搞什么102026年AI前瞻：量子AI、具身智能与科学发现的新纪元