★ FEATURED ARTICLE 刚开始接触AI大模型的人最容易遇到的情况就是资料铺天盖地但每篇都只讲一个点不够系统。要么一上来就是数学公式把人劝退要么全是概念罗列看完还是不知道怎么动手。我整理这份学习笔记的时候给自己定了个规矩每个概念必须说清楚“是什么、为什么需要、解决了什么问题”同时配上我自己实际跑过的命令和代码让零基础的朋友也能照着做。这篇就是第一弹聚焦AI大模型的基础认知、核心架构和上手路径后面再逐步深入训练、微调和部署。1. 大模型到底“大”在哪里核心概念与能力边界1.1 从“模型”到“大模型”关键的三个维度的跃迁想理解大模型得先知道普通模型是怎样的。以传统的图像分类模型为例输入一张猫的图片模型输出“猫”的标签本质上是一个“输入到输出的映射函数”。这类模型参数少则几万多则几百万任务单一训练数据量也小通常几万到几百万条样本就够了。大模型则完全换了一个赛道。业内通常把参数规模在数十亿Billion级别以上的预训练语言模型称为大模型但这还只是表象。真正让它区别于传统模型的是三个维度的同时跃迁数据规模训练数据从“万级”跳到“万亿级token”这些数据覆盖了网页、书籍、代码、论文等各种人类知识文本。参数规模模型容量大幅提升能记住的知识模式和规律更多。如果把模型比作一个容器参数就是容器里的“记忆单元”参数越多能装下的语言规律和世界知识就越多。训练方式从“针对单一任务训练”变成“大规模预训练 任务微调/提示学习”。模型先在海量文本上进行自监督学习本质上是“填空”或“预测下一个词”形成通用能力再通过少量数据适配具体任务。用生活化的方式理解传统模型像是一个只学会了“辨认苹果”的小型工具而大模型像是受过通识教育的大学生你给他一本《苹果种植手册》他很快就能学会种苹果甚至能触类旁通地理解果树的病虫害防治。核心能力方面大模型之所以被称为“基础模型”Foundation Model是因为它具备强大的通用性和涌现能力。通用性指同一个模型可以处理翻译、摘要、问答、代码生成、逻辑推理等多种任务涌现能力则是指当模型规模突破某个阈值后会突然出现小模型不具备的能力比如上下文学习In-Context Learning、思维链推理Chain-of-Thought等。一个只有几亿参数的小模型无论怎么训练也很难涌现出“三步推理解决数学应用题”的能力这正是“大”的另一层意义。1.2 常见大模型类型与典型代表本着实操优先的原则我先按“能不能直接拿来改、拿来跑”把市面上常见的大模型分成三类方便你决定从哪一类入手。第一类开放权重模型。这类模型发布权重你可以在自己的机器上下载、运行甚至基于它做微调。典型的有 Llama 系列Meta 发布、Mistral 系列欧洲研究团队发布、Qwen 系列国内团队发布、DeepSeek 系列等。这类模型是目前学习研究的首选也是我这套笔记里绝大多数实操案例的基础。你可以用一张消费级显卡如 RTX 4090就能跑 7B 左右的模型做推理量化之后 13B 模型也能勉强运行。第二类闭源 API 模型。典型的有 GPT 系列、Claude 系列、Gemini 系列以及国内各大厂提供的 API 形式大模型如通义千问 API、文心一言 API 等。它们能力最强但你只能通过 API 调用无法拿到权重文件。适合做应用开发不适合做底层机理研究。第三类多模态大模型。这类模型不仅能处理文字还能处理图片、音频、视频。典型的有 GPT-4o支持文本图像音频输入、Qwen-VL 系列文本图像等。多模态模型发展的本质是让模型像人一样综合多种感知通道来理解问题比如截图问“这个报错应该怎么解决”它可以直接读取图片中的代码报错信息。从学习路径来说我的建议是先用开放权重模型跑通推理和微调的完整流程理解模型的基本运作逻辑然后尝试 API 调用学习工程化部署最后再探索多模态模型扩展应用边界。不要一上来就追新、追大先把基础链路走通后面换任何模型都只是换配置的事。2. 大模型背后的关键技术Transformer 原理与训练流程2.1 为什么是 Transformer从 RNN 的瓶颈说起在 Transformer 出现之前处理序列数据如文本、语音时序信号的主流架构是 RNN循环神经网络及其变体 LSTM长短期记忆网络。RNN 的原理是“按顺序逐步处理序列”就像一个人逐字阅读一句话每读一个字把前面的记忆累积到当前的状态里。这种方式的致命弱点在于当序列很长时早期的信息会被“遗忘”而且必须等前一步算完才能算下一步训练并行性极差。举个例子处理“小明昨天在公园里捡到一只受伤的小狗他带回家细心照顾今天_______”这句话RNN 处理到句尾时“小狗”这个关键信息可能已经被稀释了导致模型难以准确预测空格里填“小狗”还是“小猫”。Transformer 这一架构发表于 2017 年的论文《Attention Is All You Need》它做的革命性改变有两个其一注意力机制Attention。模型在处理每个词时不是只依赖上一个词的输出而是直接扫描序列中的所有词按“相关性”分配注意力权重。就像你读这句话时虽然“小明”和“小狗”之间隔了 20 个字但你依然能建立“他”指代“小明”、“它”指代“小狗”的联系。这个设计让模型能直接捕获长距离依赖。其二并行计算。Transformer 不再逐字处理而是把一句话当作一个整体一次性并行计算。以“小猫在睡觉”为例模型同时计算“小猫”“在”“睡觉”这三个词之间的注意力关系训练效率大幅提升。并行能力是它能支撑千亿级参数训练的前提——没有并行训练一次大模型的时间会不可接受。2.2 预训练与微调大模型的“通识教育”与“专业进修”大模型的训练完整来说分为两阶段预训练Pre-training和微调Fine-tuning。预训练阶段模型在海量无标注文本上做自监督学习。最常见的目标是“预测下一个词”Next Token Prediction给模型看“今天天气真”让它预测下一个词最可能是“好”。这个大任务蕴含了一个终极规则要预测下一个词模型必须理解语言的语法、语义、事实知识和逻辑关系。在这个过程中模型被迫学习到了大量的语言规律和世界知识。这就是“通识教育”。但是预训练好的模型只能说“能聊天”并不一定“听指挥”。比如你问“帮我写一份活动策划方案”它可能给出长篇大论但格式不对、重点不突出。这时候需要进行监督微调SFTSupervised Fine-Tuning用一批“指令 正确回答”的标注数据教模型学会服从指令、按照特定格式作答。这相当于“专业进修”——从通识通才变成能处理实际任务的专才。在 SFT 之后还有一个关键环节叫人类反馈强化学习RLHF。SFT 的数据是人工标注的数量有限而且标注者写的回答并不一定完全符合“安全、无害、有用”的标准。RLHF 的思路是让模型输出多个回答人类标注员排序“哪个回答更好”训练一个**奖励模型Reward Model**来学习人类偏好再用强化学习算法如 PPOProximal Policy Optimization调整模型参数让回答更符合人类的真实偏好。这也是 ChatGPT 类产品“可用性”大幅超过传统对话系统的核心原因。我用一个表格总结这个过程方便对照阶段数据特点目标类比预训练海量无标注文本万亿 token 级学习语言规律和知识通识教育监督微调SFT少量指令与回答对十万~百万级学会服从指令、格式化输出专业进修RLHF人类偏好排序数据对齐人类价值观、提高安全性和有用性社会行为规范训练2.3 Token、上下文窗口与参数三个绕不开的基础概念想动手跑大模型这三个概念你必须刻进脑子Token词元模型处理文本的最小单位。它不一定等于一个“字”或一个“词”。比如“我爱你”这句话在英文模型里可能被切成两个 token“I”“love you”在中文模型里可能是“我”“爱”“你”三个 token也可能是“我爱你”整体一个 token具体取决于分词器Tokenizer的训练规则。我实际做文本统计时发现中文文本占用的 token 数大约是字符数的 0.6 到 1.0 倍取决于模型和分词方式做 API 计费和上下文长度规划时千万别按字符数算。一个直观的规律模型中每个词都有唯一对应的 token ID模型预测时实际上是输出一个“下一个 token ID 的概率分布”然后从这个概率分布里采样一个 ID再把 ID 翻译回文字。因此生成速度的指标是“每秒生成多少个 token”而不是“每秒多少个汉字符号”。上下文窗口Context Window模型一次能“看到”的最大 token 数量。早期的 GPT 系列上下文窗口只有 2K后来的开源模型普遍扩展到 8K、32K 甚至 128K。这意味着你给模型输入的文章长度、历史对话轮次都被这个窗口限制超出部分会被直接截断。处理长文档时正确的做法不是“一次全塞进去”而是分段摘要或检索关键段落后再输入。参数Parameters模型的权重和偏置是训练过程中学到的“知识”的具体表现形式。7B 模型指参数量为 7 billion70 亿。参数量大不代表模型一定更强但通常容量更大。有个容易混淆的点模型文件大小和参数量不是一回事因为参数在内存/显存中通常以浮点数存储fp16 每个参数占 2 字节所以 7B 模型的 fp16 权重文件大概 14GB量化到 4bit 后约需要 4GB 显存。这个换算公式后面部署时会反复用到。3. 零基础也能跑通本地运行一个开源大模型3.1 环境准备硬件、软件与模型选择先说硬件。我踩过的最初级的坑是拿着 8GB 显存的显卡硬跑 13B 模型结果 OOM显存溢出报错。给你一个可参考的表模型规模显存要求GPU 推理4bit 量化推荐硬件1B ~ 3B2GB ~ 4GB大部分近两年的笔记本集成显卡都能勉强跑但推荐独立显卡7B ~ 8B6GB ~ 8GBRTX 3060 / 4060 及以上13B ~ 14B10GB ~ 12GBRTX 3090 / 4080 及以上70B40GB或使用 CPU 内存推理速度慢A100 / 多卡并行如果是 CPU 内存推理7B 量化模型需要至少 16GB 内存速度大概每秒 2~5 个 token体验相当煎熬只适合验证流程。软件环境我建议直接用 llama.cpp 或者 Ollama这两个是目前对新手最友好的工具。Ollama 的优点是安装即用一条命令就能拉起模型服务llama.cpp 更适合喜欢折腾和了解底层原理的人。我这里以 Ollama 为例因为它屏蔽了大部分底层细节让你能先跑通再深入。3.2 从零到能聊天的 10 分钟实操安装 Ollama 这一步我直接说一下关键点你需要去官方网站下载对应平台的安装包它支持 Windows、macOS、Linux。Windows 安装后命令行里输入ollama --version能看到版本号就说明成功了。然后找一个中文能力不错的小模型来跑例如 qwen2.5:7b这是 Qwen 2.5 系列 70 亿参数的模型中文能力出色7B 这个规模对消费级显卡非常友好。在命令行里执行ollama run qwen2.5:7b第一次运行会自动从模型仓库下载权重大约 4.7GB 左右。下载完成后你会进入一个交互式对话界面直接输入中文问题试试 用一句话解释什么是大语言模型模型会在那里逐 token 地“打字”输出回答。这个过程就是典型的大模型推理Inference——加载权重、输入 prompt、逐 token 生成输出。如果不想用交互式会话也可以写一个最简单的 Python 脚本通过 Ollama 提供的 HTTP API 调用模型import requests response requests.post( http://localhost:11434/api/generate, json{ model: qwen2.5:7b, prompt: 写一段关于机器学习的比喻, stream: False } ) print(response.json()[response])拿到这段代码后你只需要运行pip install requests安装依赖然后运行脚本即可。这是我对所有新人的建议先把“命令行交互”和“API 调用”这两条路都走通后面做任何工程化开发都建立在这个基础上。3.3 量化与显存优化用最小的成本跑最大的模型跑大模型时“显存不够”是最高频的问题。解决的常规手段有四种量化Quantization、KV Cache 管理、批处理大小调整、CPU offload。量化是将模型参数的存储精度从 fp162 字节压缩到 int81 字节或 int40.5 字节从而让模型占用的显存几乎呈比例下降。我在 llama.cpp 或 Ollama 中经常用 Q4_K_M 这个量化等级它是在“质量损失”和“资源占用”之间做得比较均衡的选择。你在 Ollama 的模型标签里看到qwen2.5:7b-q4_0、qwen2.5:7b-q8_0之类的后缀就是不同的量化等级。KV Cache 是 Transformer 推理过程中的“临时记忆”它存储了当前序列已经计算过的键值对。这个缓存的大小也占显存且随序列长度线性增长。如果你做长文本生成KV Cache 会非常大。所以当你看到-OOM 报错时先考虑降低num_ctx上下文长度参数或在 Ollama 的配置文件里调低上下文上限比如从默认的 4096 降到 2048可能就解决问题了。我实测过一个场景在一张 24GB 显存的卡上跑 7B 模型Q4 量化上下文长度设为 8192 时显存占用约 8GB上下文拉到 32768 时显存占用直接翻倍。这个比例非常直观所以当你只是做简单的问答不必盲目拉长上下文。4. 提示工程入门让大模型真正“听懂”你的话4.1 提示的结构化设计角色、任务、上下文、要求很多初学者觉得大模型“笨”其实是因为提示写得含糊。举个例子你问“帮我写个方案”模型并不知道你要什么方案、给谁看、多长篇幅、什么风格。而高手写提示通常会包含四个要素角色Role模型扮演谁比如“你是一名资深软件架构师”。任务Task具体要做什么比如“针对下面的需求设计一个模块划分”。上下文Context提供背景材料比如需求文本、已有代码、数据样例。要求Requirement输出的格式比如“用 Markdown 表格输出包含模块名、职责、接口说明”。一个对比很明显的提示案例差的提示帮我写个道歉信好的提示你是一名擅长职场沟通的资深助理。任务帮我写一封道歉信。 背景我昨天因为工作太忙忘记参加与某位重要客户的会议导致对方等待半小时。 要求语气诚恳但不卑微说明失误原因不找借口提出补救措施重新约会议时间全文150字以内。第二个提示之所以效果好是因为它给模型提供了“角色任务上下文要求”让模型不再需要猜测。在后面多轮对话场景中如果想保持风格一致也可以在每轮提问时把要求重新强调一遍因为本地运行的模型通常不保留你之前明确表达过的偏好除非做了对话模板或记忆功能。4.2 思维链提示与 Few-shot 示例**思维链Chain-of-ThoughtCoT**是让模型分步骤推理的一种提示方式。现在许多模型内置了推理能力你只需要明确要求它“先一步一步思考再给出结论”。例如你是一道数学题的解题助手。请一步步思考最后用最终答案开头给出答案。 问题一个长方形的长是8厘米宽是5厘米它的面积比周长大多少模型如果直接推理可能会出错但要求它分步骤列出“面积 8 * 5 40”“周长 2 * (8 5) 26”“差值 40 - 26 14”准确率就明显提升。这个技巧在大模型学习场景里非常常用。**Few-shot少量示例**是指在你提出正式问题前先给模型几个输入与输出的示例让它“照着这个格式模仿”。比如你希望模型把你提供的文章总结成三句话你可以先给它一个示例文章xxx 总结第一句……第二句……第三句……然后放一篇新文章模型就会按照相同的格式输出。这种方式对格式控制非常有效代价是多占用一些上下文 token。注意本地模型的上下文长度有限Few-shot 示例不宜过多。我个人的经验是 3~5 个示例即可覆盖大部分格式控制需求再多不仅浪费 token还可能让模型被示例带偏。4.3 温度、Top-p 与随机性控制模型生成文本时并不是每次都选概率最高的那个词而是带一定随机性。控制这个随机性有两个核心参数Temperature温度取值范围通常 0~2。温度越低输出越保守、确定温度越高输出越发散、多样。做信息提取、代码生成时我通常设为 0.1~0.3做创意文案、头脑风暴时设为 0.8~1.2。Top-p核采样模型会从概率最高的词开始累加直到概率总和超过 top-p 阈值然后在这一小批词里按概率随机选。实践经验是temperature 和 top-p 只需重点调一个不要同时剧烈调整否则输出会变得难以预测。如果你在一个严格场景比如批量生成结构化 JSON里希望每次答案尽量一致建议 temperature 设为 0top-p 设为 1如果你在做闲聊机器人、需要多样化的表达temperature 调到 0.9 左右效果会好一点。这个参数就是我常说的“大模型调试三件套”的其中两件另一个是 max tokens限制输出长度用来防止模型长篇大论。5. 常见报错与学习路线避坑5.1 显存不足与其他高频问题的排查方法本地跑大模型几乎每个人都会遇到 OOMOut of Memory报错。我遇到过最典型的场景是用 8GB 显存显卡跑一个 7B 模型Ollama 自动选择了 Q4 量化但上下文长度设到了默认的 8192结果一运行就 OOM。排查的方式很简单用显存监控工具确认模型加载时显存占用情况确认是模型权重占显存还是 KV Cache 占显存。如果是模型权重占满换更小尺寸的模型或更高等级的量化比如从 Q8 换成 Q4。如果是 KV Cache 占满降低上下文长度num_ctx或减少并发请求数。另一个高频问题是因为网络问题导致的模型下载失败。Ollama 从公有仓库下载模型时偶尔会遇到连接中断或下载卡在 99%。这种情况下我通常先执行ollama stop停掉当前进程删除半截下载缓存然后重新执行ollama pull。如果你所在的环境下载速度极慢可以考虑配置镜像源这是国内环境常见的加速手段。5.2 学习路线的三个建议与三个“不要”结合我的经验给刚入门的朋友三个建议建议一先跑通再深挖。很多人卡在“要先读懂 Attention 公式才能跑模型”的观念里。我的看法正相反先通过 Ollama 和现成模型跑通推理流程建立“模型会输出什么”的直观感受再回头看原理公式理解深度完全不同。模型是你最好的老师对着公式观察模型的输入输出变化比只看书有效得多。建议二用任务驱动学习而不是按章节啃。与其从“深度学习基础”开始学不如给自己设定一个小任务比如“实现一个调用大模型的长文本摘要工具”。遇到问题就去查、去问、去实验这个过程积累的经验比按部就班刷课快得多。我就是这样从零开始在三天内完成了一个本地个人知识库问答工具的原型。建议三多模型对比建立“模型性格”认知。同一句话给不同模型可能得到风格迥异的回答。在跑通第一个模型后建议你再拉一个不同系列的模型对比比如同时跑 qwen2.5 和 llama3.2 的 7B 模型感受它们的语气、中文能力、代码能力差异。这个过程能帮你理解模型的能力差异不只是“参数大小”还和训练数据分布的差异密切相关。三个“不要”不要一开始就尝试 70B 以上大模型的本地部署——你的设备和心理都会受挫。不要盲信“更大一定更好”——实测中220 亿参数的 Medium 模型在指定中文任务上表现可能不如经过了中文专项微调的 70 亿参数模型。不要在没跑通基础流程前直接学 RLHF——你连正常的推理和微调都还没跑过理解奖励模型和策略梯度基本等于凭空想象。循序渐进在这条路上永远是最高效的。5.3 下一步深入方向的选择跑通了本地模型、理解了提示工程之后摆在你面前的是三条方向第一条是应用开发学怎么把大模型嵌入实际产品比如开发聊天机器人、文档问答、智能助手。核心技术栈是 FastAPI、LangChain、向量数据库等。适合工作里需要快速落地 AI 功能的人。第二条是模型微调学怎么用自己的数据调整模型行为比如让模型学会你公司的文档风格、学会特定领域的术语。核心技术栈是 Hugging Face PEFT/LoRA、SFT 流程。适合想把大模型变成“行业专家”的人。第三条是模型底层研究深入探索模型内部机制、训练优化、推理加速甚至自己训练一个小规模的模型搞懂训练过程中的每一个细节。适合想做科研或进入大模型基础研发岗位的人。我个人认为如果你不确定走哪条就先把“应用开发”这条线学好因为它是需求最大、上手最快、正反馈最强的路径。等你积累了足够多的实践经验自然会发现自己对哪一块更感兴趣。任何一条路深入下去都需要配合动手实践反复打磨光看不练学了三周最后还是只会“跑通 Ollama”。写在最后的体验分享如果让我分享一个最有价值的实操习惯那就是写学习日志。我把自己每次跑模型时的报错、参数调整、推理结果都记录下来包括“当时用了什么量化、上下文多长、生成了什么质量的回答”。这个习惯帮我快速避开了许多重复的坑比如记下了“Q4_K_M 在 7B 模型上质量损失可接受但 Q3 以下质量明显下降”这类经验几乎每次选模型都能用到。另一个小技巧是当你测试一个模型在特定任务上的能力时不要只看一次输出而是跑五次。因为大模型生成带有随机性第一次回答得好不代表稳定。同一个 prompt 连续测试五次如果每次回答质量都很高才说明模型确实具备这个能力如果时好时坏那就要考虑通过提示工程或者微调来加固。学大模型这件事门槛并不在于数学而在于“动手”。哪怕你今天只会照着文档命令行里敲一条ollama run也已经比那些收藏了几十篇文章却从未运行过一次模型的人走得更远了。
阅读完成 · 觉得有帮助？
