零基础入门AI大模型：从Transformer原理到本地部署实操

刚开始接触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）：给模型看“今天天气真”，让它预测下一个词最可能是“好”。这个大任务蕴含了一个终极规则：要预测下一个词，模型必须理解语言的语法、语义、事实知识和逻辑关系。在这个过程中，模型被迫学习到了大量的语言规律和世界知识。这就是“通识教育”。

但是，预训练好的模型只能说“能聊天”，并不一定“听指挥”。比如你问“帮我写一份活动策划方案”，它可能给出长篇大论但格式不对、重点不突出。这时候需要进行监督微调（SFT，Supervised Fine-Tuning）：用一批“指令 + 正确回答”的标注数据，教模型学会服从指令、按照特定格式作答。这相当于“专业进修”——从通识通才变成能处理实际任务的专才。

在 SFT 之后，还有一个关键环节叫人类反馈强化学习（RLHF）。SFT 的数据是人工标注的，数量有限，而且标注者写的回答并不一定完全符合“安全、无害、有用”的标准。RLHF 的思路是：让模型输出多个回答，人类标注员排序“哪个回答更好”，训练一个**奖励模型（Reward Model）**来学习人类偏好，再用强化学习算法（如 PPO，Proximal Policy Optimization）调整模型参数，让回答更符合人类的真实偏好。这也是 ChatGPT 类产品“可用性”大幅超过传统对话系统的核心原因。

我用一个表格总结这个过程，方便对照：

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 billion（70 亿）。参数量大不代表模型一定更强，但通常容量更大。有个容易混淆的点：模型文件大小和参数量不是一回事，因为参数在内存/显存中通常以浮点数存储（fp16 每个参数占 2 字节），所以 7B 模型的 fp16 权重文件大概 14GB，量化到 4bit 后约需要 4GB 显存。这个换算公式后面部署时会反复用到。

3. 零基础也能跑通：本地运行一个开源大模型

3.1 环境准备：硬件、软件与模型选择

先说硬件。我踩过的最初级的坑是拿着 8GB 显存的显卡硬跑 13B 模型，结果 OOM（显存溢出）报错。给你一个可参考的表：

如果是 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。

量化是将模型参数的存储精度从 fp16（2 字节）压缩到 int8（1 字节）或 int4（0.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 提示的结构化设计：角色、任务、上下文、要求

很多初学者觉得大模型“笨”，其实是因为提示写得含糊。举个例子，你问“帮我写个方案”，模型并不知道你要什么方案、给谁看、多长篇幅、什么风格。而高手写提示，通常会包含四个要素：

1. 角色（Role）：模型扮演谁？比如“你是一名资深软件架构师”。
2. 任务（Task）：具体要做什么？比如“针对下面的需求，设计一个模块划分”。
3. 上下文（Context）：提供背景材料，比如需求文本、已有代码、数据样例。
4. 要求（Requirement）：输出的格式，比如“用 Markdown 表格输出，包含模块名、职责、接口说明”。

一个对比很明显的提示案例：

• 差的提示：帮我写个道歉信
• 好的提示：

  你是一名擅长职场沟通的资深助理。任务：帮我写一封道歉信。 背景：我昨天因为工作太忙，忘记参加与某位重要客户的会议，导致对方等待半小时。 要求：语气诚恳但不卑微，说明失误原因（不找借口），提出补救措施（重新约会议时间），全文150字以内。

第二个提示之所以效果好，是因为它给模型提供了“角色+任务+上下文+要求”，让模型不再需要猜测。在后面多轮对话场景中，如果想保持风格一致，也可以在每轮提问时把要求重新强调一遍，因为本地运行的模型通常不保留你之前明确表达过的偏好（除非做了对话模板或记忆功能）。

4.2 思维链提示与 Few-shot 示例

**思维链（Chain-of-Thought，CoT）**是让模型分步骤推理的一种提示方式。现在许多模型内置了推理能力，你只需要明确要求它“先一步一步思考，再给出结论”。例如：

你是一道数学题的解题助手。请一步步思考，最后用"最终答案："开头给出答案。 问题：一个长方形的长是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 设为 0，top-p 设为 1；如果你在做闲聊机器人、需要多样化的表达，temperature 调到 0.9 左右效果会好一点。这个参数就是我常说的“大模型调试三件套”的其中两件，另一个是 max tokens（限制输出长度），用来防止模型长篇大论。

5. 常见报错与学习路线避坑

5.1 显存不足与其他高频问题的排查方法

本地跑大模型，几乎每个人都会遇到 OOM（Out of Memory）报错。我遇到过最典型的场景是：用 8GB 显存显卡跑一个 7B 模型，Ollama 自动选择了 Q4 量化，但上下文长度设到了默认的 8192，结果一运行就 OOM。排查的方式很简单：

1. 用显存监控工具确认模型加载时显存占用情况，确认是模型权重占显存还是 KV Cache 占显存。
2. 如果是模型权重占满，换更小尺寸的模型或更高等级的量化（比如从 Q8 换成 Q4）。
3. 如果是 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，也已经比那些收藏了几十篇文章却从未运行过一次模型的人，走得更远了。