大模型开发的学习材料现在非常多，线上动辄几百集、上百小时的视频教程也很常见。很多人收藏完之后，仍然不知道第一步该做什么。问题的根源不是“学得不够多”，而是没有把知识挂到一条可执行的工程主线上：模型怎么装、接口怎么调、私有知识怎么注入、模型怎么部署、什么时候才需要微调。这篇文章按这条主线整理一份可落地的学习与实践路径，手把手完成从本地模型部署、Python 调用、RAG 检索问答到 vLLM 生产部署和 LoRA 微调的完整闭环。命令和代码都按最小可运行原则给出，落地时再根据你的系统、显卡和业务数据做调整。
1. 先建立大模型开发的学习地图，再决定从哪一步开始
1.1 大模型开发不是单一技能，至少包含三条主线
很多初学者把“大模型开发”理解成一个动作，实际上它是三件差异很大的事。
第一条线是应用开发。它面向业务场景，核心工作是调用现成的大模型，把提示词、上下文、工具调用、检索逻辑组合成可用的产品功能。这里的重点不是训练模型，而是设计输入输出、控制成本、处理错误。第二条线是模型工程，包括模型选型、量化、部署、推理优化、微调。它更接近传统的后端和机器学习工程，需要理解显存、吞吐、延迟、数据质量。第三条线是平台工程，负责把模型服务变成稳定可靠的内部能力，包括日志、监控、限流、权限、灰度发布和回滚。
这三条线不是先后关系，而是交叉递进的关系。应用开发要求你至少会部署一个模型、能看懂接口返回；模型工程要求你能判断一个效果问题到底该调提示词、调参数还是调数据。如果一开始就把精力铺在三条线上，很快就会因为知识点离散而放弃。
1.2 为什么“先部署、再应用、最后微调”这个顺序最稳
一个比较稳妥的学习顺序是：先本地部署模型，再写应用调用，然后处理私有知识和检索，最后才进入微调。原因是每一步都为下一步提供验证基础。
先部署模型，你会理解模型文件、量化精度、显存占用和推理服务之间的关系。模型跑起来之后，再写 Python 调用，你会理解 API 协议、超时、流式输出和生成参数。当单个模型回答不了业务问题的时候，你会自然理解 RAG 为什么能补充知识。最后，只有当你积累了足够多“提示词解决不了”的案例，微调才有意义。
这个方法也避免了一个常见误区：刚学会调用 OpenAI 风格的接口，就直接去准备微调数据。微调之前如果连评估样本都没有，你根本分不清微调带来的变化是变好还是变坏。建议把每个阶段的完成标志定义成“交付物”，而不是“看完多少集视频”。
下表列出了五个阶段的学习目标和常见误区，方便你快速定位自己当前的位置。
| 阶段 | 核心目标 | 关键产出 | 常见误区 |
|---|---|---|---|
| 基础阶段 | 理解大模型能做什么、不能做什么 | 一个本地可聊天的模型 | 只背概念，不跑模型 |
| 应用阶段 | 掌握 API 调用、提示词、生成参数 | 一个问答脚本 | 直接把参数调到极端 |
| 部署阶段 | 掌握推理服务、量化、并发 | 一个可对外访问的模型服务 | 没有接口验证就开始部署 |
| RAG 阶段 | 掌握检索、切分、向量化 | 一个带私有知识的问答系统 | 盲目堆框架 |
| 微调阶段 | 掌握数据处理、LoRA 训练、评估 | 一份微调前后对比报告 | 用几百条脏数据训练全参数 |
2. 本地部署一个 7B 模型：先让模型跑起来
2.1 先确认硬件能支撑什么规模的模型
大模型推理的主要瓶颈是显存。模型权重需要占用显存，推理过程中的激活值、KV Cache 也要占用显存。相同的模型参数量，精度越低，占用的显存越少。常见做法是使用 4 bit 量化，例如 Q4_K_M、q4_0 这类格式。
下面是不同规模模型在量化条件下的显存参考值。要注意，这只是粗略估算，实际占用还取决于上下文长度、并发数和推理引擎。
| 模型规模 | 精度 | 权重显存参考 | 适合场景 |
|---|---|---|---|
| 1.5B 到 3B | 4 bit | 约 2 到 4 GB | CPU 推理、端侧设备 |
| 7B 到 8B | 4 bit | 约 5 到 8 GB | 入门学习、小业务 |
| 13B 到 14B | 4 bit | 约 9 到 12 GB | 中等效果要求 |
| 70B 左右 | 4 bit | 约 40 GB 以上 | 复杂任务、生产环境 |
如果只有 16 GB 内存的笔记本，没有独立显卡，也可以先用 1.5B 或 3B 的小模型跑通全流程。学习阶段的重点不是追求最强效果，而是让整条链路能转起来。
2.2 安装 Ollama 并拉取模型
Ollama 是目前本地部署大模型最省事的工具之一。它把模型下载、量化格式、推理服务封装成一条命令，并且提供了兼容 OpenAI 风格的 HTTP 接口，方便后续用代码调用。
Linux 或 macOS 环境可以使用官方安装脚本，Windows 环境直接下载安装包即可。
# Linux/macOS 环境使用官方脚本安装 curl -fsSL https://ollama.com/install.sh | sh # 安装后确认版本 ollama --version # 拉取一个 7B 中文模型 ollama pull qwen2.5:7b # 查看本地已有模型 ollama listqwen2.5:7b里的7b是标签，表示 7B 参数的版本。标签不同，模型文件的精度也可能不同。拉取模型前可以用ollama pull触发下载，也可以先到 Ollama 模型库页面确认标签含义。模型下载通常需要几个 GB 的磁盘空间，建议先执行df -h确认磁盘剩余空间。
这里要注意：命令行脚本安装方式适合学习环境。内网生产环境通常不会使用curl | sh这种方式，而是把安装包和模型文件提前放在内网仓库，离线安装。
2.3 启动服务并验证接口
模型拉取完成后，启动服务：
# 前台启动服务 ollama serve另开一个终端直接聊天，验证模型能否正常响应：
ollama run qwen2.5:7b也可以直接通过 HTTP 接口验证：
curl http://localhost:11434/api/chat \ -H "Content-Type: application/json" \ -d '{"model":"qwen2.5:7b","messages":[{"role":"user","content":"用两句话解释什么是大模型"}],"stream":false}'返回的 JSON 中包含message.content字段，即模型生成的回答；eval_count和eval_duration可以用来估算生成速度，单位是 tokens/s：
生成速度 = eval_count / (eval_duration / 1e9)如果这个速度只有个位数，说明设备性能有限，可以换更小的模型或量化版本。启动服务时如果提示 11434 端口被占用，需要先排查是哪个进程占用了端口。
Ollama 的常用命令整理如下，方便速查。
| 命令 | 作用 | 常见使用场景 |
|---|---|---|
ollama pull <model> | 下载模型 | 首次安装或换用新模型 |
ollama list | 查看本地模型 | 确认模型是否已安装 |
ollama serve | 启动服务 | 提供 HTTP 接口 |
ollama run <model> | 交互式聊天 | 快速验证模型效果 |
ollama rm <model> | 删除本地模型 | 释放磁盘空间 |
3. 用 Python 调用本地模型，完成第一个应用
3.1 最小问答脚本
当 Ollama 服务运行在 11434 端口时，本地就相当于有一个可编程的大模型服务。用 Python 调用时，最直接的方式是使用requests请求 HTTP 接口。
先安装依赖：
pip install requests然后创建ask.py：
import requests resp = requests.post( "http://localhost:11434/v1/chat/completions", json={ "model": "qwen2.5:7b", "messages": [{"role": "user", "content": "用三句话解释什么是RAG"}], "temperature": 0.7, "stream": False, }, timeout=120, ) data = resp.json() print(data["choices"][0]["message"]["content"])运行：
python ask.py这段代码里有两个关键点。第一，/v1/chat/completions是 OpenAI 兼容接口，路径里的/v1/不能省略。第二，timeout要设置得足够大，因为大模型生成速度取决于机器性能，首次请求可能还要加载模型到内存。
如果你希望用官方 OpenAI SDK 的写法，也可以安装openai包，把base_url指向本地服务：
pip install openaifrom openai import OpenAI client = OpenAI( base_url="http://localhost:11434/v1", api_key="ollama", # 本地服务不校验 key，但字段不能少 ) resp = client.chat.completions.create( model="qwen2.5:7b", messages=[{"role": "user", "content": "介绍一个你熟悉的技术栈"}], temperature=0.7, ) print(resp.choices[0].message.content)使用 OpenAI SDK 的好处是，后续从 Ollama 切到 vLLM 或其他兼容服务时，业务代码基本不用改，只需要换base_url。
3.2 流式输出怎么处理
上面的写法是一次性等待完整回答。对用户来说，首字延迟会很高，体验很差。生产应用通常使用流式输出，让模型生成一个字就推送一个字。
import requests resp = requests.post( "http://localhost:11434/v1/chat/completions", json={ "model": "qwen2.5:7b", "messages": [{"role": "user", "content": "写一段产品介绍"}], "stream": True, }, timeout=300, stream=True, ) for line in resp.iter_lines(): if not line: continue if line.startswith(b"data: "): line = line[6:] if line == b"[DONE]": break # 这里需要按 JSON 解析 import json chunk = json.loads(line) content = chunk["choices"][0]["delta"].get("content", "") print(content, end="", flush=True)流式返回的每一行以data:开头，最后以[DONE]结束。解析时要注意delta里不一定每次都包含content，需要先get再处理。如果直接按完整 JSON 解析，会因为缺少字段而报错。
3.3 生成参数如何影响回答质量
调用接口时，temperature、top_p、max_tokens等参数会直接影响输出。很多初学者喜欢把temperature调到 0，认为这样最稳定，实际效果并不一定好。
| 参数 | 含义 | 常见默认值 | 调大影响 | 调小影响 |
|---|---|---|---|---|
temperature | 采样随机性 | 0.7 | 更发散、更有创意 | 更保守、更稳定 |
top_p | 累积概率截断 | 0.9 | 候选词更多 | 候选词更少 |
max_tokens | 最多生成 token 数 | 视模型而定 | 回答更长 | 回答可能被截断 |
repeat_penalty | 重复惩罚 | 1.1 左右 | 减少重复 | 可能绕口或语义断裂 |
实际使用中，事实问答类任务建议temperature设置在 0.2 到 0.5，创意写作可以设置在 0.7 到 0.9。max_tokens不要贪大，设得过大既浪费显存，也会让回答冗长。如果你的输出经常被截断，先检查是不是max_tokens不够，而不是盲目换模型。
这里有一个常见误区：认为temperature=0就能完全复现结果。实际上，数值计算、并发调度和 KV Cache 的差异仍然可能导致微小波动。不要用“固定种子”去期待绝对一致，而是通过系统提示词和输出解析来保证稳定性。
注意：生成参数不是越多越好。先固定一组常用参数跑通流程，再针对你的业务场景做 A/B 对比，观察具体指标变化，而不是凭感觉反复调整。
4. 用 RAG 把私有知识接入模型
4.1 为什么私有知识场景优先选 RAG
大模型训练完成之后，知识是固定的。业务文档、内部制度、产品手册这些私有知识，模型不可能知道。要让模型回答这些问题，常见方案有两个：RAG 和微调。
RAG 的基本思路是：先把文档切成片段，做向量化存入向量库；收到问题时，先从向量库检索最相关的片段；最后把片段拼进提示词，让模型基于这些材料回答。它的优点是知识更新快、不需要重新训练、回答可以追溯到原文。
微调则适合让模型改变表达方式、学会特定工具调用、掌握领域术语，但它不适合持续变更的知识。常识性判断是：知识问题先用 RAG，风格和能力问题才考虑微调。
4.2 向量库和 Embedding 模型怎么选
RAG 的核心依赖是向量检索。向量库负责存储和搜索文本向量，Embedding 模型负责把文本转成向量。选型时最关键的是：Embedding 模型的语言能力是否匹配你的文档语言。
常见向量库选型如下。
| 向量库 | 部署复杂度 | 适合规模 | 适用场景 |
|---|---|---|---|
| Chroma | 低 | 十万级以下 | 学习、原型验证 |
| Faiss | 中 | 百万级 | 离线检索、自建服务 |
| Milvus | 高 | 百万级以上 | 生产环境、大规模检索 |
| pgvector | 中 | 十万到百万级 | 已有 PostgreSQL 的技术栈 |
学习阶段建议直接用 Chroma，它支持持久化到本地目录，API 简单。生产环境再根据数据规模选 Milvus 或 pgvector。
Embedding 模型推荐先使用中文效果稳定的轻量模型，例如BAAI/bge-small-zh-v1.5。这类模型文件不会太大，普通开发机可以运行。
4.3 最小 RAG 实现
先安装依赖：
pip install sentence-transformers chromadb创建一个rag_demo.py，先用三份模拟文档建立向量库：
from sentence_transformers import SentenceTransformer import chromadb # 1. 加载 Embedding 模型 encoder = SentenceTransformer("BAAI/bge-small-zh-v1.5") # 2. 准备文档 docs = [ "公司报销需要提交发票和审批单，审批通过后三个工作日内打款。", "出差住宿标准按城市分为三档，一线城市每晚不超过500元。", "请假三天以内由组长审批，三天以上需要部门负责人审批。", ] # 3. 对文档做向量化并写入本地向量库 client = chromadb.PersistentClient(path="./chroma_db") collection = client.get_or_create_collection("qa") collection.add( ids=[str(i) for i in range(len(docs))], documents=docs, embeddings=encoder.encode(docs).tolist(), ) # 4. 检索 query = "出差住宿标准是多少？" results = collection.query( query_embeddings=encoder.encode([query]).tolist(), n_results=2, ) for doc in results["documents"][0]: print(doc)第一次运行会下载 Embedding 模型。如果下载速度慢，可以把下载源指向国内镜像站：
export HF_ENDPOINT=https://hf-mirror.com检索到相关片段之后，再把片段拼进提示词，调用本地模型生成回答：
import requests context = "\n".join(results["documents"][0]) prompt = ( "请根据下面的资料回答问题。如果资料中没有相关内容，请直接说明不知道。\n" f"资料：\n{context}\n\n" f"问题：{query}\n" ) resp = requests.post( "http://localhost:11434/v1/chat/completions", json={ "model": "qwen2.5:7b", "messages": [ {"role": "system", "content": "你是一个严谨的客服助手。"}, {"role": "user", "content": prompt}, ], "temperature": 0.2, "stream": False, }, timeout=120, ) print(resp.json()["choices"][0]["message"]["content"])这一步就形成了 RAG 的最小闭环：文档切分、向量化、检索、拼接提示词、模型生成。后续要优化的点包括更细的切分策略、重新排序、召回率评估和构建更大的知识库。
4.4 检索效果怎么验证
RAG 最怕的不是模型不好，而是检索不到正确内容。建议用一组覆盖业务场景的问题来做验证，每个问题记录：期望命中的文档、实际命中的文档、模型最终回答是否正确。
| 验证维度 | 检查方式 | 常见问题 |
|---|---|---|
| 切分粒度 | 观察片段是否语义完整 | 片段太小导致上下文缺失 |
| Embedding 匹配 | 换不同模型对比召回结果 | 中英文模型不匹配 |
| 检索排序 | 检查n_results返回的前几个片段 | 正确片段排在后半部分 |
| 回答忠实度 | 比较回答是否基于检索片段 | 提示词里没有限制“不知道” |
如果检索结果相关但回答错误，问题多半在提示词；如果检索结果本身不相关，要优先改切分和 Embedding，而不是改模型参数。
5. 从学习环境到生产环境：改用 vLLM 部署
5.1 Ollama 和 vLLM 的定位差异
Ollama 适合个人电脑、开发环境和快速验证。它底层同样使用了社区成熟的推理库，但对普通使用者隐藏了细节。vLLM 则是更偏生产环境的推理引擎，核心优势是 PagedAttention、Continuous Batching 等优化带来的高吞吐和高并发。
| 对比项 | Ollama | vLLM |
|---|---|---|
| 定位 | 一键本地部署、开发调试 | 高性能生产推理 |
| API | OpenAI 兼容 | OpenAI 兼容 |
| 并发能力 | 一般 | 高 |
| 显存优化 | 有，但面向易用性 | 面向吞吐优化 |
| 适合场景 | 学习、单机、内部工具 | 多用户、高 QPS、服务集群 |
判断标准很简单：如果只是自己调试，用 Ollama 足够；如果需要给部门或多用户提供服务，建议用 vLLM。你也可以先用 Ollama 完成功能原型，再切换到 vLLM，因为两个服务的接口都是 OpenAI 风格，切换成本主要在配置和部署脚本。
5.2 vLLM 部署与接口验证
安装 vLLM 前建议先确认 GPU 型号和驱动版本，不同版本对算子支持有差异。安装命令：
pip install vllm新版本推荐使用vllm serve启动：
vllm serve Qwen/Qwen2.5-7B-Instruct \ --port 8000 \ --max-model-len 8192早期版本使用的命令是：
python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-Instruct \ --port 8000 \ --max-model-len 8192两种写法的启动逻辑一致，具体以你安装的 vLLM 版本为准。启动前最好先确认模型已经下载到 Hugging Face 缓存目录，否则服务会在启动时联网拉取模型。
启动后验证：
curl http://localhost:8000/v1/models能看到模型列表说明服务已经就绪。接着验证对话接口：
curl http://localhost:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{"model":"Qwen/Qwen2.5-7B-Instruct","messages":[{"role":"user","content":"你好"}],"stream":false}'将 Python 应用里的base_url从http://localhost:11434/v1改成http://localhost:8000/v1，模型名改成 vLLM 启动时的模型名，即可完成切换。这里建议把模型名和接口地址做成配置项，避免部署环境变化时改代码。
5.3 生产环境还需要补上的工程能力
模型服务能跑通和能在生产环境稳定运行是两件事。上线前至少要补齐以下能力。
第一，GPU 资源监控。nvidia-smi可以查看显存占用，但生产环境还需要配套指标采集，持续记录显存使用率、GPU 利用率和温度。
第二，限流与配额。多用户共用模型服务时，如果没有限流，一个用户的长请求可能占满整卡。建议在服务入口增加按用户、按接口的限流配置。
第三，日志与链路追踪。每个请求要记录模型、输入长度、输出长度、耗时、错误信息。调试生成结果异常时，这些日志是最直接的线索。
第四，优雅降级。模型服务不可用时，业务侧要有兜底返回，不能直接抛 500 错误。常见的做法是设置超时、熔断和备用小模型。
第五，配置外置。模型名、端口、温度、超时时间都要放在配置中心或环境变量里，不要写死在代码中。这样切换模型或调整参数时不需要重新发布。
注意：生产环境一定要先设计“服务不可用”时的表现，再设计“服务可用”时的效果。很多事故不是模型不行，而是没有超时和降级策略。
6. 微调：只有数据解决不了问题时才需要
6.1 先判断该不该微调
微调的成本比很多人想象得高。它需要构造训练数据、准备 GPU、训练多轮、评估回归。所以动手之前，建议先按下面的表格做一次判断。
| 需求类型 | 首选方案 | 什么情况才考虑微调 |
|---|---|---|
| 模型不知道私有知识 | RAG | 知识无法结构化、检索效果差 |
| 输出格式不稳定 | 提示词 + few-shot | 格式要求极其严格，规则无法表达 |
| 需要模仿特定文风 | 提示词 + 示例 | 数据量充足、风格稳定 |
| 需要模型学会工具调用 | 提示词 + 函数声明 | 多次工具调用链路复杂 |
| 需要领域术语准确 | 术语库 + RAG | 术语间关系复杂且依赖全局语境 |
一个值得记住的原则：先用提示词和 RAG 把效果做到上限，把那些确实无法解决的问题集中整理，再决定微调。如果连基础应用都没跑通就微调，你很难判断效果变化来自训练还是来自巧合。
6.2 用 LoRA 做最小微调训练
LoRA 是参数高效微调方法。它冻结原始模型参数，只训练一小部分新增的低秩矩阵，显存占用和训练时长都远低于全参数微调。对于 7B 级别模型，LoRA 是入门微调的合理起点。
准备训练数据时，先把样本整理成统一的 JSON 格式：
[ { "instruction": "请把下面的文本改写为客服口吻。", "input": "墨盒没到，订单很久没更新。", "output": "您好，非常抱歉让您久等了，我马上帮您核对该订单的发货进度。" } ]然后安装依赖并加载模型：
pip install transformers peft datasets acceleratefrom transformers import AutoModelForCausalLM, AutoTokenizer from peft import LoraConfig, get_peft_model model = AutoModelForCausalLM.from_pretrained( "Qwen/Qwen2.5-7B-Instruct", device_map="auto", torch_dtype="auto", ) tokenizer = AutoTokenizer.from_pretrained("Qwen/Qwen2.5-7B-Instruct") lora_config = LoraConfig( r=8, lora_alpha=16, target_modules=["q_proj", "k_proj", "v_proj", "o_proj"], lora_dropout=0.05, task_type="CAUSAL_LM", ) peft_model = get_peft_model(model, lora_config) peft_model.print_trainable_parameters()print_trainable_parameters会输出可训练参数占比，通常只有 1% 到 2%。r是低秩矩阵的秩，lora_alpha控制新增参数的缩放比例。两者越大，可学习容量越大，但也不代表越大越好，容量过大会破坏已经训练好的能力。
真正的训练循环还需要构造对话模板、设置批大小、学习率、日志保存，代码量会更多。这里不建议直接照搬网上任意训练脚本，而是先阅读你所用模型官方仓库的微调示例，再替换成自己的数据。训练完成后，用peft_model.save_pretrained("my_lora")保存 LoRA 权重，推理时再加载回基础模型。
6.3 微调项目如何验收
微调后必须用没有参与训练的数据来评估。准备 50 条以上覆盖典型场景的测试样本，记录微调前后模型的输出，逐条判断是变好、变差还是没变化。
| 评估维度 | 判断方式 |
|---|---|
| 目标能力 | 是否解决了最初想解决的问题 |
| 通用能力 | 原来的总结、翻译、代码能力是否退化 |
| 稳定性 | 相同问题多次回答是否一致 |
| 安全性 | 是否出现偏离任务的内容 |
建议把微调前的输出留存为基线快照。没有基线对比，所有“看起来变好了”的判断都不可信。
6.4 微调阶段常见的三个坑
第一个坑是数据质量差。几百条数据里如果存在错别字、标签不一致、输入输出不匹配，模型会学习到错误模式。宁可数据少而干净，也不要数据多而脏。
第二个坑是过拟合。训练轮数太多会让模型把训练数据背下来，测试集指标虚高，线上表现却很差。至少划分训练集和验证集，观察验证集损失停止下降时就应该停止训练。
第三个坑是灾难性遗忘。微调后模型可能忘了原本会做的事。解决办法是混入一部分通用数据，并且在验收阶段专门测试原有的通用能力。
7. 一套可复用的大模型故障排查清单
7.1 模型拉取或加载失败
模型文件拉取失败是最常见的入门问题。现象通常是下载卡住、报 checksum mismatch 或提示文件不存在。
| 问题现象 | 常见原因 | 检查方式 | 处理建议 |
|---|---|---|---|
| 拉取卡住 | 网络不稳定、模型文件大 | 查看下载进度、测试其他网络 | 换个网络时段重试，或配置镜像站 |
| checksum mismatch | 下载文件损坏 | 重新ollama pull | 删除本地缓存后重拉 |
| 模型名不存在 | 标签拼写错误 | 在模型库页面确认名称 | 使用准确的model:tag |
| 加载时 OOM | 显存不足 | nvidia-smi查看显存 | 换更小模型或量化版本 |
检查优先级是：磁盘空间、网络连通性、模型名、显存。很多人一上来就怀疑 GPU，实际上磁盘不够也会导致拉取失败。
7.2 显存不足
显存不足的报错在 Ollama 里可能表现为服务退出，在 vLLM 或 PyTorch 里则表现为CUDA out of memory。显存占用不仅来自模型权重，还来自上下文长度和批大小。
| 场景 | 检查命令 | 常见应对 |
|---|---|---|
| 显存占用过高 | nvidia-smi | 换量化模型、减小max-model-len |
| 推理时突然 OOM | 观察请求上下文长度 | 限制输入长度、减小 batch |
| 多用户并发 OOM | 查看并发连接数 | 增加限流、减少并发 |
如果 7B 模型在你的机器上无法运行，不要硬撑，先换成 1.5B 或 3B 模型跑通流程。学习阶段用更大的模型并不等于学得更多。
7.3 生成内容质量差
生成结果不对，先区分是“模型不懂”还是“输入没给够”。检查顺序如下：
- 系统提示词是否清晰说明了角色和规则。
temperature是否过高导致发散。- 输入上下文是否被截断，关键信息是否在截断范围外。
- RAG 场景中，检索到的片段是否真的相关。
- 是否在提示词中明确要求“不知道就说不知道”。
如果以上都正常，再考虑换模型或微调。
7.4 从现象到根因的排查顺序
很多问题看起来在模型层，实际在应用层。建议按下面这张表从低到高排查。
| 层级 | 检查内容 | 常用方式 |
|---|---|---|
| 服务层 | 服务是否存活、端口是否监听 | curl http://localhost:11434/api/health |
| 硬件层 | 显存、GPU 利用率 | nvidia-smi |
| 请求层 | 请求参数、超时、重复请求 | 打印请求体和响应状态码 |
| 模型层 | 是否加载正确模型 | ollama list |
| 应用层 | 提示词、检索结果、解析逻辑 | 打印中间变量和日志 |
排查时只改一个变量，不要同时调整模型、参数和提示词，否则无法定位真正原因。
8. 从学习到就业：八周练习计划与工程清单
8.1 八周练习计划
学习大模型开发，不建议按视频顺序从头看到尾。更有效的方式是按周完成一个可演示的工程产物，用产物牵引学习。
| 周次 | 主要任务 | 学习重点 | 交付物 |
|---|---|---|---|
| 第 1 周 | 安装 Ollama，本地跑通 7B 模型 | 模型、量化、服务启动 | 一段本地问答的 curl 记录 |
| 第 2 周 | Python 调用本地模型 | API 协议、流式、超时 | 一个带流式输出的问答脚本 |
| 第 3 周 | 整理提示词测试集 | 系统提示词、少样本示例 | 20 条测试用例及输出记录 |
| 第 4 周 | 做一个最小 RAG | 切分、向量化、检索 | 一个带私有知识的问答 Demo |
| 第 5 周 | 部署 vLLM 并对比 | 吞吐、并发、参数调整 | 一份 Ollama 与 vLLM 对比记录 |
| 第 6 周 | 准备微调数据 | 数据清洗、格式统一 | 一份 500 条左右的训练数据集 |
| 第 7 周 | 跑一次 LoRA 微调 | 训练脚本、显存控制 | 一份微调前后输出对比 |
| 第 8 周 | 整体整理和复盘 | 文档、评估、改进 | 完整项目文档和演示录屏 |
8.2 每个阶段要交付什么
每个阶段都要有一个别人能直接看到或直接运行的产出。
第 1 到第 3 周，交付的是能跑的脚本和测试记录，证明你已经理解请求和响应。第 4 周，交付的是一个带业务主题的 RAG Demo，例如“内部制度问答”。第 5 周，交付的是性能对比数据，证明你能从开发环境走向生产部署。第 6 到第 7 周，交付的是微调实验报告。最后一周，把所有内容整理成项目文档，把过程、结果、代码、模型选用理由写清楚。
这份项目经历比“看完一套教程”有说服力得多。找工作或接项目时，面试官更关心你能否独立把模型部署起来、能否定位一个接口问题、能否说明为什么选 RAG 而不是微调。
8.3 学习环境与生产环境的差异
同一个项目在学习环境跑通后，进入生产环境还需要补齐很多细节。
| 维度 | 学习环境 | 生产环境 |
|---|---|---|
| 模型获取 | 在线拉取 | 内网仓库、离线镜像 |
| 服务启动 | 前台命令 | 进程守护、容器编排 |
| 配置 | 写死在脚本中 | 配置中心、环境变量 |
| 监控 | 无 | 指标采集、告警 |
| 安全 | 本机可用 | 鉴权、白名单、数据脱敏 |
| 成本 | 不关注 | Token 消耗、GPU 利用率 |
| 回滚 | 重启即可 | 多版本、灰度、备份 |
8.4 上线前检查清单
把这个清单放在项目发布前逐项核对，能减少大部分线上问题。
- 模型来源和许可证是否确认，是否可以商用。
- 输入内容是否包含敏感信息，日志是否需要脱敏。
- 是否配置了超时、限流和降级策略。
- 是否记录了请求耗时、输入输出长度和错误码。
- 是否评估过上下文长度成本，是否限制了最大输入。
- 是否准备了模型版本更新后的回归测试集。
- 是否验证过服务重启后能自动恢复，模型是否预热。
- 是否检查了磁盘、显存、端口、依赖版本。
大模型开发的学习过程，最终拼的不是看过多少份教程，而是能否独立完成“部署一个模型、封装一个接口、解决一个业务问题”这个最小闭环。如果只能选一件事开始，先把一个 7B 模型在本地跑起来，再看接口返回里的每一个字段。把每一步都留下可运行的脚本和可对比的记录，遇到文档里没有的问题时，按照服务层、硬件层、请求层、模型层、应用层的顺序排查，你会比单纯跟视频学快得多。
