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

‍程序员三明治个人主页 个人专栏: 《设计模式精解》 《重学数据结构》《AI探索日志》 《从0带你学深度强化学习》先做到 再看见目录一、大模型到底是什么二、大模型的“大”到底大在哪三、几个必须先搞懂的核心概念1. Token大模型真正处理文本的单位2. 上下文窗口模型不是无限记忆3. Temperature它控制的是“发散程度”四、当前主流的大模型应该怎么认识1. 国际主流模型更像能力标杆和生态标杆2. 国内主流模型和工程落地的距离更近3. 应用开发者到底该怎么选模型五、Chat 模型才是开发时真正会反复打交道的东西1. Base Model它最原始的能力其实是续写2. Chat Model它是经过“对齐”之后才变得会聊天的3. 为什么 RAG 系统基本都只用 Chat 模型六、本地部署时绕不开的一个词量化什么是量化浮点数精度FP32、FP16、BF16 都是什么量化用更低的精度换更小的体积常见的量化格式量化等级怎么选开发者需要关心吗七、所谓“深度思考”到底是什么东西1. 普通回答和“先想再答”的区别2. 思维链为什么会提升复杂任务表现3. 深度思考并不适合所有场景八、为什么开发者最终一定会走向 API而不是停留在网页端1. 网页端只是把能力“包装”成了产品2. 网页端为什么不适合系统集成3. API 的本质把大模型当成一个远程函数九、这一节真正要建立起来的到底是什么认知十、小结先别急着写代码先把模型这件事看清楚你在公司里做了一套业务系统可能是客服系统也可能是内部知识库、工单平台或者一套面向用户的问答模块。某天老板开会的时候突然提了一句现在 AI 这么火我们能不能也接一个进去让它自动回答问题或者帮我们处理一些文本类工作你第一反应大概率不是去翻论文而是直接打开几个现成的产品试试。你可能会去问 DeepSeek、通义千问或者别的聊天工具把自己业务里的问题丢进去测一测。结果往往会让人眼前一亮模型不仅能把话说通顺还能理解你给它的上下文甚至能帮你总结、归纳、改写。有些原来必须靠人工做的事情突然看起来像是真的可以交给机器了。但很快你就会发现“觉得它厉害”和“把它接进系统里”其实是两回事。网页版产品是给人交互用的不是给程序直接调用的。作为开发者你接下来会碰到一连串非常现实的问题DeepSeek、Qwen、ChatGPT 这些名字到底分别指什么它们是产品名、模型名还是平台名网上经常看到的 7B、14B、72B 又是什么意思大家天天说的 Token、上下文窗口、Temperature、Chat 模型、Base 模型到底分别在讲什么还有为什么明明网页上就能聊天开发者却还要去折腾 API这些问题如果不先理顺后面你一旦开始接入模型、配置参数、做知识库问答基本就是一边写代码一边猜。表面上好像已经开始做 AI 应用了实际上很多概念都还混在一起出了问题也不知道问题到底出在哪。所以这一节不着急写代码而是先把大模型这件事本身讲清楚。你可以把它看成后续所有实战内容的地基。先弄明白它是什么、为什么会有这么强的表现、开发者真正会接触到哪些核心概念以及在工程里我们到底是以什么方式去使用它。把这些基础认知建立起来后面不管是接 API、做 RAG还是选模型、调参数思路都会清楚很多。一、大模型到底是什么如果你是做业务开发的对“把规则写进代码里”这件事一定非常熟悉。传统程序的基本思路就是人先把规则想清楚再把这些规则一条一条翻译成代码。程序能做什么本质上取决于你事先把多少情况考虑进去了。比如做一个最简单的客服自动回复你可能会先写出这样的逻辑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.6Anthropic代码与长上下文能力突出“computer use/代理”能力强安全与对齐投入大否Gemini 系列Gemini 3.1 Pro / Gemini 3 FlashGoogle原生多模态文/图/音/视频超长上下文最高 1M与 Google 生态结合紧密否Llama 系列Llama 4 Scout / MaverickMeta开放权重生态最强之一社区活跃、部署与微调方案成熟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 proOpenAI未公开400K否强推理 工具/多轮交互旗舰 API 能力Claude Sonnet 4.6Anthropic未公开200K默认/ 1MBeta否代码与长上下文强computer-use/Agent 能力突出Gemini 3.1 ProGoogle未公开1M否原生多模态长上下文适合复杂资料/代码库Llama 4 Maverick17Bx128EMeta400B17B 激活MoE1M是开放权重多模态 MoE本地部署/微调生态成熟DeepSeek-V3.2deepseek-chat深度求索671B37B 激活MoE128K是MIT通用 Agent 取向支持 Thinking in Tool-Use性价比高DeepSeek-R1deepseek-reasoner深度求索671B37B 激活MoE128K是MIT深度思考推理数学/代码/规划强Qwen3.5-397B-A17B阿里巴巴397B17B 激活MoE262K是Apache-2.0旗舰开放权重偏 agentic长上下文更强Qwen3-32B阿里巴巴32B32K原生/ 131KYaRN是Apache-2.0中大型开源适合私有化、RAG、微调Qwen3-8B阿里巴巴8B32K原生/ 131KYaRN是Apache-2.0轻量部署成本敏感/边缘侧更友好GLM-5智谱 AIZ.ai744B40B 激活MoE200K是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 这样的小数。举个简化的例子假设模型要判断“今天天气”后面接什么词它内部可能有这样的计算晴 的得分 输入向量 × 0.82 (-0.15) 3.7 雨 的得分 输入向量 × 0.41 0.23 1.2这里的 0.82、-0.15、0.41、0.23 就是参数权重。模型在训练阶段通过海量文本不断调整这些数字让它的打分越来越准。训练完成后这些数字就固定下来保存成文件——这就是你下载到的模型文件。所谓 7B 模型有 70 亿参数意思就是模型里有 70 亿个这样的数字。训练时这些数字通常用高精度的浮点数存储比如 FP1616 位浮点数或 BF1616 位脑浮点数每个参数占 2 个字节。一个 7B 的模型光是存储权重就需要约 14GB 显存。在展开量化之前先搞清楚这些精度格式到底是什么。浮点数精度FP32、FP16、BF16 都是什么计算机用浮点数来表示带小数点的数字。一个浮点数由三部分组成符号位Sign1 位表示正数还是负数指数位Exponent决定数字的范围能表示多大或多小的数尾数位Mantissa / Fraction决定数字的精度小数点后能精确到第几位打个比方假设你在一张小纸条上写快递地址但纸条大小有限总共只能写一定数量的字符号位就像写“寄/退”只需要 1 个字表明方向指数位就像写“省市”字数越多能定位到的地理范围越精确只写“广东”还是能写到“广东省深圳市”尾数位就像写“门牌号”字数越多地址越精确写到“xx 小区”还是能精确到“xx 栋 xx 室”纸条就那么大给“省市”多写几个字指数位多能覆盖的范围就更大给“门牌号”多写几个字尾数位多定位就更精确。不同的浮点格式本质上就是在“范围”和“精度”之间做不同的取舍格式纸条大小总位数省市部分指数位门牌号部分尾数位能寄多远数值范围地址能写多细精度FP3232 格4 字节8 格23 格全球都能寄±3.4×10³⁸精确到xx栋xx单元xx室TF3219 格NVIDIA 专用8 格10 格全球都能寄同 FP32精确到xx栋xx单元BF1616 格2 字节8 格7 格全球都能寄同 FP32只能到xx栋FP1616 格2 字节5 格10 格只能寄本省±65504精确到xx栋xx单元可以看到关键的区别FP32 纸条最大省市和门牌号都写得很详细但太占空间TF32 是 NVIDIA 把 FP32 的门牌号砍短了范围不变但精度降低GPU 内部自动使用BF16 省市部分和 FP32 一样详细8 格所以范围一样大但门牌号只剩 7 格精度最低FP16 把更多格子给了门牌号10 格精度比 BF16 高但省市部分只有 5 格能覆盖的范围小很多用一句话总结每种格式的特点格式位数每参数占用核心特点FP3232 位4 字节传统的“全精度”范围大、精度高但太占显存现在很少直接用来存模型权重TF3219 位—NVIDIA Ampere 架构A100 等引入的格式保留 FP32 的范围但砍掉一半精度GPU 内部自动使用开发者一般不用管FP1616 位2 字节“半精度”体积是 FP32 的一半但能表示的数值范围很小最大约 6.5 万训练时容易溢出BF1616 位2 字节Google 提出的“脑浮点”和 FP16 一样大但把更多位数分给了指数范围和 FP32 一样大牺牲了一点精度换来了训练稳定性FP16 和 BF16 同样都是 16 格的纸条但分配方式完全不同FP16省市部分只给了 5 格门牌号给了 10 格 → 地址写得很细但只能寄本省寄远了就查无此地术语叫溢出BF16省市部分给了 8 格门牌号只剩 7 格 → 全球都能寄但地址写得比较粗可能只到楼栋级别打个比方FP16 就像一个只做同城配送的快递员他能把包裹精确送到你家门口但出了本市就没辙BF16 则像一个全国快递员哪个省都能送到但可能只送到小区门口最后几百米得你自己走。对于大模型训练来说参数的数值变化范围非常大如果“寄不到”溢出就直接算错了而“地址粗一点”精度低一点影响没那么致命。所以 BF16 成了目前大模型训练和推理的主流选择。你在 Hugging Face 上看到的大多数模型默认权重格式就是 BF16。当我们说“原始精度”或“未量化”时通常指的就是 BF16而不是 FP32。量化用更低的精度换更小的体积理解了上面的精度格式之后量化就很好理解了——它就是把模型权重从 BF16/FP1616 位进一步压缩到更低的位数比如 INT88 位整数或 INT44 位整数。精度降低了每个参数占用的空间也就小了精度每个参数占用7B 模型显存估算说明FP324 字节~28 GB全精度现在基本不用来存储模型权重BF16 / FP162 字节~14 GB当前模型的默认精度INT81 字节~7 GB轻度量化效果损失很小INT40.5 字节~3.5 GB主流量化选择效果有一定损失但通常可接受上面的显存估算只是模型权重本身的大小。实际运行时还需要额外的显存用于 KV Cache存储上下文信息、计算中间结果等所以真实显存占用会比表格中的数字更高。一般建议预留权重大小 1.2~1.5 倍的显存。常见的量化格式在 Hugging Face 上下载模型时你会看到各种量化后缀主要有这几种格式全称特点GPTQGPT Post-Training Quantization需要 GPU 推理量化后精度较好社区支持广泛AWQActivation-aware Weight Quantization需要 GPU 推理比 GPTQ 更快精度相当较新的方案GGUFGPT-Generated Unified Format支持 CPU 推理也支持 GPUllama.cpp 生态的标准格式适合没有独显或显存不够的场景简单来说有 NVIDIA 显卡优先选 AWQ 或 GPTQ显卡不够或者想用 CPU 跑就选 GGUF。量化等级怎么选以 GGUF 格式为例你经常会看到 Q4_K_M、Q5_K_M、Q8_0 这样的标注数字越大精度越高、文件越大Q4_K_M4 位量化体积最小适合显存紧张的场景是性价比最高的选择Q5_K_M5 位量化效果和体积的平衡点Q8_08 位量化接近原始精度但体积也大得多对于大多数本地部署场景INT4Q4_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 工作流才真正有可能做得清楚、做得稳。如果我的内容对你有帮助请辛苦动动您的手指为我点赞评论收藏。感谢大家!!