这次我们聊的不是某个具体的开源工具而是一条从零开始学大模型的动手路线。按这条路线走一周时间你能完成五件事把大模型在本地跑起来、写清楚提示词、调通接口 API、做一个简单的知识库问答、理解显存和精度的影响最后摸到微调与评估的门口。整条路线不要求你把注意力矩阵推导一遍也不要求你读完整篇 Transformer 论文你只需要有基本的 Python 基础和命令行使用经验就能跟着一步步落地。很多刚接触大模型的人容易卡在同一个地方资料收藏了一堆概念背了不少最后自己电脑上始终没跑起来过任何一个模型。这个问题其实很好解决把“先学原理”改成“先跑模型再复盘原理”就行。你不需要知道 7B、13B 的完整数学推导但你需要知道它占多少显存、用什么工具启动、怎么发一个请求、返回结果是什么格式。这篇文章就按这个思路组织第一天到第二天先把模型跑起来第三天到第四天学提示词和接口第五天做知识库问答第六天看精度和显存第七天了解微调和评估。每部分都给可以直接用的命令和排查方法。如果你之前没有接触过本地部署不要担心下面会给出通用检查清单。如果你已经本地跑过模型可以重点看接口调用、RAG 流程、精度对比和微调评估这几章。整篇文章适合想快速上手大模型应用开发、想把大模型接入自己业务系统、以及准备做本地私有化部署的读者。1. 零基础大模型学习路线速览先给出一条可以执行的一周路线。每一天都有明确的学习主题、交付物和需要验证的节点。这里不把计划铺得特别满每天留出 2 到 3 小时即可重点是每个阶段都要真正跑通一个小任务而不是光看概念。时间学习主题核心任务阶段产出门槛第1天大模型基础概念理解 Token、上下文窗口、自回归生成、采样参数能解释大模型生成一句话的过程几乎为零第2天本地部署与对话用 Ollama 拉取一个开源模型并完成首轮对话本地跑通一个可对话的模型有命令行基础即可GPU 非必需第3天提示词工程掌握指令、角色、少样本示例、结构化输出一套自己写的提示词模板能调用本地模型接口第4天接口 API 开发使用 OpenAI 兼容接口做程序化调用一个批量调用脚本会写简单 Python第5天知识库问答与 RAG把文档或数据库数据加工成模型可用的上下文一个基于本地文档的问答流程会安装 Python 依赖第6天精度与显存分析理解 fp16、fp32、bf16、量化对显存的影响能估算模型权重占用并观察显存曲线有 GPU 环境更好没有也能理论验证第7天微调与评估了解 LoRA 微调、模型测试用例、输出评估一份微调选型建议和测试记录了解 PyTorch 基本概念即可从表格能看出来这条路线不是走学术路线而是走工程路线。你不需要在第一天就背下所有术语只需要在每次遇到新名词时知道它解决什么问题。比如“量化”这个词第 2 天如果显存不够就会用到第 6 天再系统理解它效果反而更好。2. 学习前提、适合人群与使用边界这条路线适合下面几类人有 Python 基础但还没实际调用过大模型接口的开发者。公司内部想引入私有化部署需要先做本地技术验证的工程师。做 AI 产品原型想快速把大模型接到自己业务数据上的产品和技术人员。准备转向大模型应用开发但不知道从哪一步开始的在校学生。不要求你懂数学证明也不要求你从零训练一个模型。这条路线里的“训练”只涉及微调层面的概念理解不涉及真正的预训练。预训练需要大规模数据和大量 GPU不适合作为入门阶段的主线入门阶段应该把注意力放在“使用、调用、部署、评估”这四件事上。使用边界也需要提前想清楚。大模型输出内容是概率分布的结果不代表事实正确尤其在医疗、金融、法律等高风险领域不能直接把模型输出作为决策依据。做本地部署时如果使用内部文档做知识库问答要确保这些文档有合法使用权限不要随意上传未脱敏的隐私数据。涉及人脸、声音、版权文本或图像素材生成时必须先确认授权边界。开源模型虽然有开放权重但不同模型有不同的 License商用前要检查许可证限制。3. 第一周环境准备与前置条件在开始之前先把环境检查一遍。这里给出一份通用检查清单具体版本以当前官方文档为准不要盲目照抄某个特定版本的命令。需要准备的基础环境操作系统Windows 10/11、Ubuntu 20.04 及以上、macOS 都可以。Linux 服务器在部署阶段更省事Windows 建议使用 PowerShell 或 Windows Terminal。Python建议 3.9 以上很多大模型相关的 Python 依赖已经放弃对 3.8 的支持。可以在终端先检查版本。Git拉取开源项目时会用到没有可以安装一个最新版。显卡驱动如果使用 NVIDIA GPU先安装好驱动和 CUDA 运行库。如果只是 CPU 推理可以跳过这一步但推理速度会明显慢。磁盘空间主要取决于要下载的模型大小。一个 7B 模型在量化之后可能只有 4GB 到 8GB但完整精度版本会更大建议预留 30GB 以上磁盘空间。Docker如果计划用容器化部署提前安装 Docker Desktop 或 Docker Engine不是必选项。先执行下面的命令做环境检查# 检查 Python 版本 python --version # 检查 Git 版本 git --version # 检查显卡驱动和 CUDA 信息NVIDIA GPU 适用 nvidia-smi如果nvidia-smi能正常输出显卡信息说明 NVIDIA 驱动没问题。如果没有 NVIDIA GPU也不用停下来后面可以走 CPU 推理路径只是建议选择更小的量化模型。大模型下载是一个容易被忽略的环节。无论是通过 Ollama 拉取模型还是从 Hugging Face 等模型仓库下载权重都需要稳定的网络环境。如果下载中断很多工具支持断点续传可以直接重新执行拉取命令不必反复删除重来。4. 第1-2天理解核心概念并完成本地部署这一阶段的目标是理解大模型使用层必须知道的几个概念然后真正在本地跑起来一个模型。你不用深究模型内部实现但必须知道你在跟什么打交道。4.1 使用层必须记住的几个概念大模型把文本拆成 Token 来处理。Token 是模型内部的最小文本单位一个中文词语可能对应一个或多个 Token英文单词也可能被拆成子词。模型不是按“字”来理解文本而是按 Token 来理解。调用模型时输入和输出的长度上限也用 Token 数来衡量。上下文窗口指的是模型一次能看到的 Token 数量。窗口越大能处理的长文档就越多。不同模型的上下文窗口差异很大在部署前先确认配置。自回归生成则是指模型一个 Token 一个 Token 地预测每生成一个 Token 就会把它拼回输入再继续预测下一个。采样参数会影响生成的随机性和多样性。temperature控制随机性值越低越保守值越高越发散top_p控制候选集合宽度max_tokens则限制最大生成长度。入门阶段可以先从temperature0.7开始等做批量任务时再根据任务类型调整。4.2 用 Ollama 完成本地部署本地部署大模型最常见的工具之一是 Ollama。它把模型下载、模型启动和接口服务打包成比较简单的命令很适合入门。以下命令以qwen2.5:7b作为示例实际模型名需要以你本机下载的版本为准。安装 Ollama 后在终端执行# 拉取模型模型名以实际可用版本为准 ollama pull qwen2.5:7b # 启动对话 ollama run qwen2.5:7b第一次运行会先下载模型等待完成后再输入对话。如果显存不够可以尝试拉取更小的量化模型例如常见的 qwen 系列更小参数版本或者 3B、1.5B 这类体积更小的模型。这个阶段的重心是“能跑起来”而不是“效果最好”。4.3 部署一个可交互的 Web 界面如果不想只在终端里对话可以接一个 Web UI。常见的做法是部署 Open WebUI 或 LobeChat 这类支持 Ollama 的界面工具启动后通过浏览器访问把服务地址和模型名填进去就能对话。这个步骤不是必需的但做演示或给团队试用时更方便。需要说明的是不同 Web UI 项目对 Ollama 的配置方式略有不同。接入时如果找不到模型优先检查 Ollama 服务是否启动并用下面的命令确认模型列表# 查看本地已下载的模型 ollama list # 查看当前加载到内存中的模型 ollama ps4.4 显存不够怎么办本地部署大模型的第一个门槛往往是资源。没有 NVIDIA GPU 的普通笔记本也可以跑但建议选择量化模型或小参数模型推理速度会慢一些。更稳妥的做法是先按 CPU 推理跑通流程再在有 GPU 的机器上切换模型版本。如果你的目标是学会部署流程而不是追求高并发或高质量输出小模型已经足够完成学习任务。第 6 天会专门讨论精度和量化到那时你就能更清楚地判断自己的机器适合跑什么模型。5. 第3-4天提示词工程与大模型接口调用模型跑起来之后接下来要学的是控制它输出的能力。提示词工程和接口调用是大模型应用开发里最核心的两个基本功。5.1 提示词工程的基本公式提示词没有一个万能模板但大多数情况下可以按照“指令 上下文 输入 输出格式”的结构来写。指令告诉模型做什么上下文提供背景信息输入是待处理的数据输出格式用来约束返回结果。一个典型示例你是一名资深数据分析师。 下面是一段用户反馈文本。 请提取其中提到的三个核心问题并用 JSON 数组返回。 用户反馈昨天提交的工单一直没有处理客服也说无法查询进度。这种写法比直接问“帮我分析一下这段话”要稳定得多。关键是把模型要扮演的角色、要完成的任务、要遵循的输出格式都写清楚。5.2 常用提示词技巧角色设定能显著改变回答风格。少样本示例会给模型两到三个输入输出对让模型模仿格式。思维链提示词可以要求模型先写出推理步骤再给结论适合推理类任务。结构化输出则直接让模型返回 JSON方便程序解析。做批量任务时尽量把提示词做成可复用的模板。同一个任务换不同的输入输出格式保持稳定后续处理结果就简单很多。不建议每次手工敲提示词应该把提示词模板保存成文件用代码加载。5.3 通过 API 调用大模型本地模型跑起来后很多工具会暴露一个 OpenAI 兼容接口。这意味着你可以用通用的 API 调用方式把本地服务接到自己的程序里。以 Ollama 常见的 OpenAI 兼容接口为例启动本地服务后可以用 curl 做一次调用curl http://127.0.0.1:11434/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen2.5:7b, messages: [ {role: system, content: 你是一个技术助手。}, {role: user, content: 用三句话解释什么是大模型。} ] }需要注意这里的端口和模型名只是常见示例实际端口号要看本地服务启动时打印的地址模型名要用ollama list查到的真实名称。不同工具的 API 路径也存在差异调用前先确认服务日志或文档。用 Python 调用会更方便做后续开发import requests url http://127.0.0.1:11434/v1/chat/completions payload { model: qwen2.5:7b, messages: [ {role: system, content: 你是一个技术助手。}, {role: user, content: 用一句话总结本地部署大模型的优势。} ], temperature: 0.3, stream: False } response requests.post(url, jsonpayload, timeout120) print(response.json())运行成功后会返回一个包含choices字段的 JSON 结构模型输出在choices[0][message][content]里。这一步能让你的程序真正和大模型对话。5.4 批量任务脚本能调用接口之后批量任务就顺理成章了。批量任务的重点不是一次发多个请求而是把请求数量、失败重试、结果保存和日志记录都处理好。下面是一个批量调用本地模型的示例脚本按行读取问题文件逐个请求模型并把结果写入 JSONL 文件import requests import json import time from pathlib import Path input_file Path(questions.txt) output_file Path(answers.jsonl) prompts [ line.strip() for line in input_file.read_text(encodingutf-8).splitlines() if line.strip() ] results [] for idx, prompt in enumerate(prompts, 1): try: resp requests.post( http://127.0.0.1:11434/v1/chat/completions, json{ model: qwen2.5:7b, messages: [ {role: user, content: prompt} ], temperature: 0.3, }, timeout120, ) resp.raise_for_status() answer resp.json()[choices][0][message][content] results.append({id: idx, prompt: prompt, answer: answer}) print(f{idx}/{len(prompts)} done) except Exception as exc: results.append({id: idx, prompt: prompt, error: str(exc)}) print(f{idx} failed: {exc}) time.sleep(1) with output_file.open(w, encodingutf-8) as f: for item in results: f.write(json.dumps(item, ensure_asciiFalse) \n)这个脚本还不是高并发方案但对入门测试足够了。要注意几点接口服务不是无限制的批量请求时加一个短延时可以降低服务压力失败的任务要记录错误信息方便重跑结果文件建议按日期或批次命名避免覆盖。6. 第5天知识库问答、RAG与批量任务到了第 5 天你已经能调用模型并拿到稳定输出了。接下来的问题是怎么让模型回答你私有的文档和数据库内容。解决办法是 RAG检索增强生成。6.1 什么时候需要用 RAGRAG 解决的问题是让模型在没有训练过的数据上基于你提供的资料回答问题。典型场景包括公司内部制度问答、产品说明书问答、私有文档摘要等。RAG 的好处是不用重新训练模型通过检索把相关内容塞进提示词上下文就能临时获得特定领域知识。大模型并不是一个可靠的数据库。它不能保证记住所有细节也无法感知训练后的新知识。RAG 提供了一种相对可控的方式把知识来源换成你自己准备的材料。6.2 最小 RAG 流程RAG 的最小流程是加载文档、切分文本、生成向量、存入向量库、检索相关片段、把检索结果拼进提示词、交给大模型回答。先看一个基于常见 Python 库的示意流程。这里的依赖库和模型名需要按实际环境调整主要目的是看清整个链路# 示意代码依赖库按实际版本安装 from langchain_community.document_loaders import TextLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_community.vectorstores import FAISS from langchain_huggingface import HuggingFaceEmbeddings loader TextLoader(guide.txt) documents loader.load() splitter RecursiveCharacterTextSplitter(chunk_size500, chunk_overlap50) chunks splitter.split_documents(documents) embeddings HuggingFaceEmbeddings(model_nameBAAI/bge-small-zh-v1.5) vectorstore FAISS.from_documents(chunks, embeddings) query 本地部署大模型需要多少显存 hits vectorstore.similarity_search(query, k3) context \n.join([hit.page_content for hit in hits]) final_prompt f请根据下面的资料回答问题不要编造资料之外的内容。 资料 {context} 问题{query} 这段代码把文档切成固定大小的块转成向量并存进向量库。提问时先从库里检索最相关的三个片段再拼成一个带资料上下文的提示词。这个流程里最关键的参数是chunk_size和chunk_overlap。切分太大会导致单个片段超过上下文限制切分太小又可能丢失完整语义。一般先按 300 到 800 个字符左右测试再用实际效果调整。6.3 关系数据如何变成大模型能读的格式除了文档很多场景还要处理关系数据库里的数据。大模型不能直接读数据库你需要先把查询结果转换成它容易理解的文本格式再拼进提示词。常见的做法是转成 JSON 数组或 Markdown 表格。示例import sqlite3 import json conn sqlite3.connect(demo.db) rows conn.execute( SELECT name, price, stock FROM products LIMIT 5 ).fetchall() data [ {name: row[0], price: row[1], stock: row[2]} for row in rows ] prompt f 以下是数据库查出的商品信息 {json.dumps(data, ensure_asciiFalse)} 请总结这些商品的价格区间并找出库存最低的商品。 这里的关键是“结构化查询 序列化 提示词拼接”的链路。数据库本身不直接进入模型查询结果经过转换后变成模型能理解的普通文本。如果你需要使用知识抽取框架或知识图谱把非结构化文本加工成结构化三元组可以在这一阶段做扩展原理仍然是“先加工数据再喂给模型”。6.4 功能验证方法做完 RAG 之后一定要做功能验证。验证方式很简单准备一个文档里存在但不是常识的问题分别用“直接问模型”和“加 RAG 上下文再问”两种方式测试。如果模型直接回答错误但加了检索上下文后能回答正确说明 RAG 链路是有效的。如果两个答案都是错的先检查检索结果是否包含正确答案再看提示词里是否给了模型足够的约束。RAG 效果不好时大概率出在三个位置文档切分不合理、检索结果不相关、提示词没有明确要求模型只依据资料回答。7. 第6天精度、显存与性能观察到了第 6 天你已经能完成一个完整的大模型应用小闭环部署、调用、批量任务、知识库问答。接下来要解决的是性能和资源问题。7.1 fp16、fp32、bf16 的区别大模型推理和训练过程中经常看到 fp16、fp32、bf16 这几个精度。它们影响显存占用、计算速度和数值稳定性。精度类型位宽相对显存占用特点fp3232 位1 倍基准精度最高显存占用大fp1616 位约 1/2推理常用数值范围较小大数值容易溢出bf1616 位约 1/2指数范围与 fp32 相同大模型训练和推理更稳从参数规模可以大致估算权重占用一个 7B 参数的模型在 fp16 精度下权重部分大约是 14GB7B × 2 字节。这还只是权重文件的理论占用实际推理时还需要计算上下文、KV Cache 和中间激活的显存所以实际占用会高于权重文件大小。13B 模型在 fp16 下权重约 26GB量化之后会更小。bf16保留了和 fp32 接近的指数范围对大模型这种数值动态范围较大的场景更友好所以很多大模型训练直接用 bf16。但它的尾数精度有限训练时通常会结合混合精度策略。7.2 量化与模型格式量化是降低模型体积和显存占用的常用手段。简单理解就是把模型的权重从高精度压缩到低精度比如从 fp16 换成 8bit 或 4bit换来更小的显存占用代价是精度可能轻微下降和推理速度的变化。常见的量化格式有 GGUF、AWQ、GPTQ 等不同工具支持的格式不一样。Ollama 拉取的小参数模型通常已经是量化后的版本所以显存占用比理论权重计算值低很多。做本地部署时如果显存紧张优先考虑量化和更小的模型而不是直接换更大尺寸的模型。7.3 显存占用如何观察观察显存不要只看模型加载后的数字要分别看“空闲状态”和“请求状态”的差别。推荐用下面两组命令# 单次查看 nvidia-smi # 每隔 1 秒刷新观察请求过程中的显存变化 watch -n 1 nvidia-smi在 Windows 上也可以用任务管理器中的 GPU 列查看“专用 GPU 内存”。更细粒度的分析需要借助 profiling 工具但入门阶段用nvidia-smi已经足够。实际显存占用需要以本机测试为准。不同模型版本、不同量化精度、不同上下文长度占用差异非常大。不要拿别人分享的数字直接套用要在自己环境里复测。7.4 影响性能的关键因素影响大模型推理性能的因素主要有几个上下文越长需要缓存的 KV Cache 越大显存占用和延迟都会上升并发请求越多显存占用和调度压力越高批处理大小如果调大吞吐量可能提升但单次请求延迟会变长量化会降低一定精度但通常能大幅减少显存压力。如果显存不够第一选择是换更小的量化模型第二选择是缩短上下文长度第三选择是降低并发和批处理大小。顺序通常不要反很多人先调各种启动参数效果反而不如直接换一个小模型来得直接。如果需要做高并发的本地服务可以了解 vLLM 这类推理框架。它的启动方式更偏向服务化部署对显存和调度做了较多优化。下面是一个通用命令模板实际路径和端口以项目文档为准# 通用命令模板具体参数按 vLLM 版本调整 vllm serve /path/to/model --host 0.0.0.0 --port 8000简单说Ollama 适合快速上手和单机测试vLLM 更适合有一定并发压测需求的服务化部署。入门阶段先用 Ollama 跑通链路再决定是否需要引入更重的推理框架。8. 第7天微调、效果评估与工程化建议最后一天我们把视野从“调用模型”拉高到“改进模型”和“验证效果”。到这一步你已经不是零基础了你会逐渐意识到本地部署只是开始真正的工程问题在后面。8.1 什么时候才需要微调微调是在模型已有能力基础上用特定数据进一步训练模型让它更擅长某个任务。但微调不是万能的也不是所有问题都应该微调。如果你的诉求是“模型应该回答某个领域的问题”通常先试 RAG只有当你希望模型改变输出风格、遵守特定格式、掌握某种长期行为时微调才更合适。微调成本明显高于 RAG。你需要准备高质量标注数据、足够的 GPU 资源和更长的训练周期。入门阶段不建议一上来就微调先把 RAG 和提示词工程做到极限再判断是否有微调的必要。8.2 LoRA 与轻量化微调在微调领域LoRA 是一种常见的轻量化微调方案。它的思路不是更新全部模型参数而是冻结原始权重只训练一小部分低秩矩阵参数能大幅降低显存和计算需求。很多开源工具都支持 LoRA 或 QLoRA 方式微调QLoRA 还会结合量化进一步降低门槛。微调命令在不同的开源工具里差异很大这里不写死具体的工具参数。以常见的开源微调工具为例大致的流程是准备训练数据集整理成对话格式选择基础模型配置 LoRA 参数和训练轮数然后启动训练。执行前一定要看对应工具的官方文档因为参数名和格式变化很快。你需要记住的共性是微调要有数据、要选基础模型、要确定训练策略、要留测试集做效果对比。没有测试集的微调基本等于盲调。8.3 效果评估怎么做很多人在微调后只凭“感觉回答变好了”来判断效果这是不够的。靠谱的做法是准备一套测试用例包含输入、期望输出和打分维度然后在微调前后分别跑一遍对比差异。评估维度可以根据任务类型定义。比如问答类任务可以看回答准确度、完整度、格式规范性、是否出现幻觉代码类任务可以看能否编译通过、逻辑是否正确。入门阶段不需要上复杂框架先用一个 JSON 文件管理测试用例再写脚本批量请求模型并保存结果人工或程序化打分即可。还要注意大模型投毒测试和异常输入测试。你可以故意输入包含恶意指令、越权要求或敏感信息的数据观察模型是否会泄露不该输出的内容。这个环节在正式接入生产环境前非常重要尤其是涉及公司内部数据或隐私数据的场景。8.4 工程化落地建议工程化落地时不要把模型调用裸写在业务代码里。推荐的做法是本地模型独立成一个服务业务系统通过 API 访问任务量上来后增加批量任务队列和失败重试所有请求和输出都记录日志方便复盘。大模型应用开发不只是一个模型调用它至少包含数据处理、提示词管理、接口服务、日志监控、效果评估和权限控制几个部分。第一次做生产化部署时建议先用最小可运行配置验证链路再逐步加并发、加缓存、加模型管理。9. 常见问题与排查方法下面整理了一份常见问题排查表。遇到问题时先看日志再对照表格逐项排查。问题现象可能原因排查方式解决方案模型下载很慢或中断网络不稳定或模型文件较大查看网络状态和下载日志重新执行拉取命令使用下载工具或镜像源Ollama 启动后无法对话模型未正确加载执行ollama list和ollama ps确认模型名并重新拉取服务启动后页面打不开端口被占用或服务未启动查看启动日志和端口占用更换端口或重启服务API 调用超时模型加载较慢或并发过高检查服务端日志和显存延长 timeout降低并发换小模型显存不足导致进程退出模型过大或上下文过长用nvidia-smi观察峰值显存换量化模型、缩短上下文、减少并发输出内容不符合预期提示词约束不够检查提示词是否包含输出格式增加角色、限制和少样本示例批量任务中途卡住某个请求长时间没有返回查看日志中卡住的请求增加超时上限和失败重试机制量化后效果变差精度压缩过大对比量化前后的测试集结果尝试更高位宽的量化版本微调后效果没有提升数据量不足或训练参数不合适检查训练集规模和 Loss扩充数据、调整 LoRA 参数这一周学习过程中最容易踩的一个坑是把大量时间花在配置环境上而忽略了功能验证。环境只是手段跑通一次对话、调通一次接口、完成一次 RAG 检索这些才是真正的进度。到这里一周路线已经完整走完。你可以把这套流程作为以后接触新模型的脚手架先部署再调用再按需做知识库最后根据效果决定是否微调。建议先收藏这条路线然后从“把模型跑起来”这一步开始动手。 零基础一周上手大模型：本地部署、RAG与微调实战路线
这次我们聊的不是某个具体的开源工具而是一条从零开始学大模型的动手路线。按这条路线走一周时间你能完成五件事把大模型在本地跑起来、写清楚提示词、调通接口 API、做一个简单的知识库问答、理解显存和精度的影响最后摸到微调与评估的门口。整条路线不要求你把注意力矩阵推导一遍也不要求你读完整篇 Transformer 论文你只需要有基本的 Python 基础和命令行使用经验就能跟着一步步落地。很多刚接触大模型的人容易卡在同一个地方资料收藏了一堆概念背了不少最后自己电脑上始终没跑起来过任何一个模型。这个问题其实很好解决把“先学原理”改成“先跑模型再复盘原理”就行。你不需要知道 7B、13B 的完整数学推导但你需要知道它占多少显存、用什么工具启动、怎么发一个请求、返回结果是什么格式。这篇文章就按这个思路组织第一天到第二天先把模型跑起来第三天到第四天学提示词和接口第五天做知识库问答第六天看精度和显存第七天了解微调和评估。每部分都给可以直接用的命令和排查方法。如果你之前没有接触过本地部署不要担心下面会给出通用检查清单。如果你已经本地跑过模型可以重点看接口调用、RAG 流程、精度对比和微调评估这几章。整篇文章适合想快速上手大模型应用开发、想把大模型接入自己业务系统、以及准备做本地私有化部署的读者。1. 零基础大模型学习路线速览先给出一条可以执行的一周路线。每一天都有明确的学习主题、交付物和需要验证的节点。这里不把计划铺得特别满每天留出 2 到 3 小时即可重点是每个阶段都要真正跑通一个小任务而不是光看概念。时间学习主题核心任务阶段产出门槛第1天大模型基础概念理解 Token、上下文窗口、自回归生成、采样参数能解释大模型生成一句话的过程几乎为零第2天本地部署与对话用 Ollama 拉取一个开源模型并完成首轮对话本地跑通一个可对话的模型有命令行基础即可GPU 非必需第3天提示词工程掌握指令、角色、少样本示例、结构化输出一套自己写的提示词模板能调用本地模型接口第4天接口 API 开发使用 OpenAI 兼容接口做程序化调用一个批量调用脚本会写简单 Python第5天知识库问答与 RAG把文档或数据库数据加工成模型可用的上下文一个基于本地文档的问答流程会安装 Python 依赖第6天精度与显存分析理解 fp16、fp32、bf16、量化对显存的影响能估算模型权重占用并观察显存曲线有 GPU 环境更好没有也能理论验证第7天微调与评估了解 LoRA 微调、模型测试用例、输出评估一份微调选型建议和测试记录了解 PyTorch 基本概念即可从表格能看出来这条路线不是走学术路线而是走工程路线。你不需要在第一天就背下所有术语只需要在每次遇到新名词时知道它解决什么问题。比如“量化”这个词第 2 天如果显存不够就会用到第 6 天再系统理解它效果反而更好。2. 学习前提、适合人群与使用边界这条路线适合下面几类人有 Python 基础但还没实际调用过大模型接口的开发者。公司内部想引入私有化部署需要先做本地技术验证的工程师。做 AI 产品原型想快速把大模型接到自己业务数据上的产品和技术人员。准备转向大模型应用开发但不知道从哪一步开始的在校学生。不要求你懂数学证明也不要求你从零训练一个模型。这条路线里的“训练”只涉及微调层面的概念理解不涉及真正的预训练。预训练需要大规模数据和大量 GPU不适合作为入门阶段的主线入门阶段应该把注意力放在“使用、调用、部署、评估”这四件事上。使用边界也需要提前想清楚。大模型输出内容是概率分布的结果不代表事实正确尤其在医疗、金融、法律等高风险领域不能直接把模型输出作为决策依据。做本地部署时如果使用内部文档做知识库问答要确保这些文档有合法使用权限不要随意上传未脱敏的隐私数据。涉及人脸、声音、版权文本或图像素材生成时必须先确认授权边界。开源模型虽然有开放权重但不同模型有不同的 License商用前要检查许可证限制。3. 第一周环境准备与前置条件在开始之前先把环境检查一遍。这里给出一份通用检查清单具体版本以当前官方文档为准不要盲目照抄某个特定版本的命令。需要准备的基础环境操作系统Windows 10/11、Ubuntu 20.04 及以上、macOS 都可以。Linux 服务器在部署阶段更省事Windows 建议使用 PowerShell 或 Windows Terminal。Python建议 3.9 以上很多大模型相关的 Python 依赖已经放弃对 3.8 的支持。可以在终端先检查版本。Git拉取开源项目时会用到没有可以安装一个最新版。显卡驱动如果使用 NVIDIA GPU先安装好驱动和 CUDA 运行库。如果只是 CPU 推理可以跳过这一步但推理速度会明显慢。磁盘空间主要取决于要下载的模型大小。一个 7B 模型在量化之后可能只有 4GB 到 8GB但完整精度版本会更大建议预留 30GB 以上磁盘空间。Docker如果计划用容器化部署提前安装 Docker Desktop 或 Docker Engine不是必选项。先执行下面的命令做环境检查# 检查 Python 版本 python --version # 检查 Git 版本 git --version # 检查显卡驱动和 CUDA 信息NVIDIA GPU 适用 nvidia-smi如果nvidia-smi能正常输出显卡信息说明 NVIDIA 驱动没问题。如果没有 NVIDIA GPU也不用停下来后面可以走 CPU 推理路径只是建议选择更小的量化模型。大模型下载是一个容易被忽略的环节。无论是通过 Ollama 拉取模型还是从 Hugging Face 等模型仓库下载权重都需要稳定的网络环境。如果下载中断很多工具支持断点续传可以直接重新执行拉取命令不必反复删除重来。4. 第1-2天理解核心概念并完成本地部署这一阶段的目标是理解大模型使用层必须知道的几个概念然后真正在本地跑起来一个模型。你不用深究模型内部实现但必须知道你在跟什么打交道。4.1 使用层必须记住的几个概念大模型把文本拆成 Token 来处理。Token 是模型内部的最小文本单位一个中文词语可能对应一个或多个 Token英文单词也可能被拆成子词。模型不是按“字”来理解文本而是按 Token 来理解。调用模型时输入和输出的长度上限也用 Token 数来衡量。上下文窗口指的是模型一次能看到的 Token 数量。窗口越大能处理的长文档就越多。不同模型的上下文窗口差异很大在部署前先确认配置。自回归生成则是指模型一个 Token 一个 Token 地预测每生成一个 Token 就会把它拼回输入再继续预测下一个。采样参数会影响生成的随机性和多样性。temperature控制随机性值越低越保守值越高越发散top_p控制候选集合宽度max_tokens则限制最大生成长度。入门阶段可以先从temperature0.7开始等做批量任务时再根据任务类型调整。4.2 用 Ollama 完成本地部署本地部署大模型最常见的工具之一是 Ollama。它把模型下载、模型启动和接口服务打包成比较简单的命令很适合入门。以下命令以qwen2.5:7b作为示例实际模型名需要以你本机下载的版本为准。安装 Ollama 后在终端执行# 拉取模型模型名以实际可用版本为准 ollama pull qwen2.5:7b # 启动对话 ollama run qwen2.5:7b第一次运行会先下载模型等待完成后再输入对话。如果显存不够可以尝试拉取更小的量化模型例如常见的 qwen 系列更小参数版本或者 3B、1.5B 这类体积更小的模型。这个阶段的重心是“能跑起来”而不是“效果最好”。4.3 部署一个可交互的 Web 界面如果不想只在终端里对话可以接一个 Web UI。常见的做法是部署 Open WebUI 或 LobeChat 这类支持 Ollama 的界面工具启动后通过浏览器访问把服务地址和模型名填进去就能对话。这个步骤不是必需的但做演示或给团队试用时更方便。需要说明的是不同 Web UI 项目对 Ollama 的配置方式略有不同。接入时如果找不到模型优先检查 Ollama 服务是否启动并用下面的命令确认模型列表# 查看本地已下载的模型 ollama list # 查看当前加载到内存中的模型 ollama ps4.4 显存不够怎么办本地部署大模型的第一个门槛往往是资源。没有 NVIDIA GPU 的普通笔记本也可以跑但建议选择量化模型或小参数模型推理速度会慢一些。更稳妥的做法是先按 CPU 推理跑通流程再在有 GPU 的机器上切换模型版本。如果你的目标是学会部署流程而不是追求高并发或高质量输出小模型已经足够完成学习任务。第 6 天会专门讨论精度和量化到那时你就能更清楚地判断自己的机器适合跑什么模型。5. 第3-4天提示词工程与大模型接口调用模型跑起来之后接下来要学的是控制它输出的能力。提示词工程和接口调用是大模型应用开发里最核心的两个基本功。5.1 提示词工程的基本公式提示词没有一个万能模板但大多数情况下可以按照“指令 上下文 输入 输出格式”的结构来写。指令告诉模型做什么上下文提供背景信息输入是待处理的数据输出格式用来约束返回结果。一个典型示例你是一名资深数据分析师。 下面是一段用户反馈文本。 请提取其中提到的三个核心问题并用 JSON 数组返回。 用户反馈昨天提交的工单一直没有处理客服也说无法查询进度。这种写法比直接问“帮我分析一下这段话”要稳定得多。关键是把模型要扮演的角色、要完成的任务、要遵循的输出格式都写清楚。5.2 常用提示词技巧角色设定能显著改变回答风格。少样本示例会给模型两到三个输入输出对让模型模仿格式。思维链提示词可以要求模型先写出推理步骤再给结论适合推理类任务。结构化输出则直接让模型返回 JSON方便程序解析。做批量任务时尽量把提示词做成可复用的模板。同一个任务换不同的输入输出格式保持稳定后续处理结果就简单很多。不建议每次手工敲提示词应该把提示词模板保存成文件用代码加载。5.3 通过 API 调用大模型本地模型跑起来后很多工具会暴露一个 OpenAI 兼容接口。这意味着你可以用通用的 API 调用方式把本地服务接到自己的程序里。以 Ollama 常见的 OpenAI 兼容接口为例启动本地服务后可以用 curl 做一次调用curl http://127.0.0.1:11434/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen2.5:7b, messages: [ {role: system, content: 你是一个技术助手。}, {role: user, content: 用三句话解释什么是大模型。} ] }需要注意这里的端口和模型名只是常见示例实际端口号要看本地服务启动时打印的地址模型名要用ollama list查到的真实名称。不同工具的 API 路径也存在差异调用前先确认服务日志或文档。用 Python 调用会更方便做后续开发import requests url http://127.0.0.1:11434/v1/chat/completions payload { model: qwen2.5:7b, messages: [ {role: system, content: 你是一个技术助手。}, {role: user, content: 用一句话总结本地部署大模型的优势。} ], temperature: 0.3, stream: False } response requests.post(url, jsonpayload, timeout120) print(response.json())运行成功后会返回一个包含choices字段的 JSON 结构模型输出在choices[0][message][content]里。这一步能让你的程序真正和大模型对话。5.4 批量任务脚本能调用接口之后批量任务就顺理成章了。批量任务的重点不是一次发多个请求而是把请求数量、失败重试、结果保存和日志记录都处理好。下面是一个批量调用本地模型的示例脚本按行读取问题文件逐个请求模型并把结果写入 JSONL 文件import requests import json import time from pathlib import Path input_file Path(questions.txt) output_file Path(answers.jsonl) prompts [ line.strip() for line in input_file.read_text(encodingutf-8).splitlines() if line.strip() ] results [] for idx, prompt in enumerate(prompts, 1): try: resp requests.post( http://127.0.0.1:11434/v1/chat/completions, json{ model: qwen2.5:7b, messages: [ {role: user, content: prompt} ], temperature: 0.3, }, timeout120, ) resp.raise_for_status() answer resp.json()[choices][0][message][content] results.append({id: idx, prompt: prompt, answer: answer}) print(f{idx}/{len(prompts)} done) except Exception as exc: results.append({id: idx, prompt: prompt, error: str(exc)}) print(f{idx} failed: {exc}) time.sleep(1) with output_file.open(w, encodingutf-8) as f: for item in results: f.write(json.dumps(item, ensure_asciiFalse) \n)这个脚本还不是高并发方案但对入门测试足够了。要注意几点接口服务不是无限制的批量请求时加一个短延时可以降低服务压力失败的任务要记录错误信息方便重跑结果文件建议按日期或批次命名避免覆盖。6. 第5天知识库问答、RAG与批量任务到了第 5 天你已经能调用模型并拿到稳定输出了。接下来的问题是怎么让模型回答你私有的文档和数据库内容。解决办法是 RAG检索增强生成。6.1 什么时候需要用 RAGRAG 解决的问题是让模型在没有训练过的数据上基于你提供的资料回答问题。典型场景包括公司内部制度问答、产品说明书问答、私有文档摘要等。RAG 的好处是不用重新训练模型通过检索把相关内容塞进提示词上下文就能临时获得特定领域知识。大模型并不是一个可靠的数据库。它不能保证记住所有细节也无法感知训练后的新知识。RAG 提供了一种相对可控的方式把知识来源换成你自己准备的材料。6.2 最小 RAG 流程RAG 的最小流程是加载文档、切分文本、生成向量、存入向量库、检索相关片段、把检索结果拼进提示词、交给大模型回答。先看一个基于常见 Python 库的示意流程。这里的依赖库和模型名需要按实际环境调整主要目的是看清整个链路# 示意代码依赖库按实际版本安装 from langchain_community.document_loaders import TextLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_community.vectorstores import FAISS from langchain_huggingface import HuggingFaceEmbeddings loader TextLoader(guide.txt) documents loader.load() splitter RecursiveCharacterTextSplitter(chunk_size500, chunk_overlap50) chunks splitter.split_documents(documents) embeddings HuggingFaceEmbeddings(model_nameBAAI/bge-small-zh-v1.5) vectorstore FAISS.from_documents(chunks, embeddings) query 本地部署大模型需要多少显存 hits vectorstore.similarity_search(query, k3) context \n.join([hit.page_content for hit in hits]) final_prompt f请根据下面的资料回答问题不要编造资料之外的内容。 资料 {context} 问题{query} 这段代码把文档切成固定大小的块转成向量并存进向量库。提问时先从库里检索最相关的三个片段再拼成一个带资料上下文的提示词。这个流程里最关键的参数是chunk_size和chunk_overlap。切分太大会导致单个片段超过上下文限制切分太小又可能丢失完整语义。一般先按 300 到 800 个字符左右测试再用实际效果调整。6.3 关系数据如何变成大模型能读的格式除了文档很多场景还要处理关系数据库里的数据。大模型不能直接读数据库你需要先把查询结果转换成它容易理解的文本格式再拼进提示词。常见的做法是转成 JSON 数组或 Markdown 表格。示例import sqlite3 import json conn sqlite3.connect(demo.db) rows conn.execute( SELECT name, price, stock FROM products LIMIT 5 ).fetchall() data [ {name: row[0], price: row[1], stock: row[2]} for row in rows ] prompt f 以下是数据库查出的商品信息 {json.dumps(data, ensure_asciiFalse)} 请总结这些商品的价格区间并找出库存最低的商品。 这里的关键是“结构化查询 序列化 提示词拼接”的链路。数据库本身不直接进入模型查询结果经过转换后变成模型能理解的普通文本。如果你需要使用知识抽取框架或知识图谱把非结构化文本加工成结构化三元组可以在这一阶段做扩展原理仍然是“先加工数据再喂给模型”。6.4 功能验证方法做完 RAG 之后一定要做功能验证。验证方式很简单准备一个文档里存在但不是常识的问题分别用“直接问模型”和“加 RAG 上下文再问”两种方式测试。如果模型直接回答错误但加了检索上下文后能回答正确说明 RAG 链路是有效的。如果两个答案都是错的先检查检索结果是否包含正确答案再看提示词里是否给了模型足够的约束。RAG 效果不好时大概率出在三个位置文档切分不合理、检索结果不相关、提示词没有明确要求模型只依据资料回答。7. 第6天精度、显存与性能观察到了第 6 天你已经能完成一个完整的大模型应用小闭环部署、调用、批量任务、知识库问答。接下来要解决的是性能和资源问题。7.1 fp16、fp32、bf16 的区别大模型推理和训练过程中经常看到 fp16、fp32、bf16 这几个精度。它们影响显存占用、计算速度和数值稳定性。精度类型位宽相对显存占用特点fp3232 位1 倍基准精度最高显存占用大fp1616 位约 1/2推理常用数值范围较小大数值容易溢出bf1616 位约 1/2指数范围与 fp32 相同大模型训练和推理更稳从参数规模可以大致估算权重占用一个 7B 参数的模型在 fp16 精度下权重部分大约是 14GB7B × 2 字节。这还只是权重文件的理论占用实际推理时还需要计算上下文、KV Cache 和中间激活的显存所以实际占用会高于权重文件大小。13B 模型在 fp16 下权重约 26GB量化之后会更小。bf16保留了和 fp32 接近的指数范围对大模型这种数值动态范围较大的场景更友好所以很多大模型训练直接用 bf16。但它的尾数精度有限训练时通常会结合混合精度策略。7.2 量化与模型格式量化是降低模型体积和显存占用的常用手段。简单理解就是把模型的权重从高精度压缩到低精度比如从 fp16 换成 8bit 或 4bit换来更小的显存占用代价是精度可能轻微下降和推理速度的变化。常见的量化格式有 GGUF、AWQ、GPTQ 等不同工具支持的格式不一样。Ollama 拉取的小参数模型通常已经是量化后的版本所以显存占用比理论权重计算值低很多。做本地部署时如果显存紧张优先考虑量化和更小的模型而不是直接换更大尺寸的模型。7.3 显存占用如何观察观察显存不要只看模型加载后的数字要分别看“空闲状态”和“请求状态”的差别。推荐用下面两组命令# 单次查看 nvidia-smi # 每隔 1 秒刷新观察请求过程中的显存变化 watch -n 1 nvidia-smi在 Windows 上也可以用任务管理器中的 GPU 列查看“专用 GPU 内存”。更细粒度的分析需要借助 profiling 工具但入门阶段用nvidia-smi已经足够。实际显存占用需要以本机测试为准。不同模型版本、不同量化精度、不同上下文长度占用差异非常大。不要拿别人分享的数字直接套用要在自己环境里复测。7.4 影响性能的关键因素影响大模型推理性能的因素主要有几个上下文越长需要缓存的 KV Cache 越大显存占用和延迟都会上升并发请求越多显存占用和调度压力越高批处理大小如果调大吞吐量可能提升但单次请求延迟会变长量化会降低一定精度但通常能大幅减少显存压力。如果显存不够第一选择是换更小的量化模型第二选择是缩短上下文长度第三选择是降低并发和批处理大小。顺序通常不要反很多人先调各种启动参数效果反而不如直接换一个小模型来得直接。如果需要做高并发的本地服务可以了解 vLLM 这类推理框架。它的启动方式更偏向服务化部署对显存和调度做了较多优化。下面是一个通用命令模板实际路径和端口以项目文档为准# 通用命令模板具体参数按 vLLM 版本调整 vllm serve /path/to/model --host 0.0.0.0 --port 8000简单说Ollama 适合快速上手和单机测试vLLM 更适合有一定并发压测需求的服务化部署。入门阶段先用 Ollama 跑通链路再决定是否需要引入更重的推理框架。8. 第7天微调、效果评估与工程化建议最后一天我们把视野从“调用模型”拉高到“改进模型”和“验证效果”。到这一步你已经不是零基础了你会逐渐意识到本地部署只是开始真正的工程问题在后面。8.1 什么时候才需要微调微调是在模型已有能力基础上用特定数据进一步训练模型让它更擅长某个任务。但微调不是万能的也不是所有问题都应该微调。如果你的诉求是“模型应该回答某个领域的问题”通常先试 RAG只有当你希望模型改变输出风格、遵守特定格式、掌握某种长期行为时微调才更合适。微调成本明显高于 RAG。你需要准备高质量标注数据、足够的 GPU 资源和更长的训练周期。入门阶段不建议一上来就微调先把 RAG 和提示词工程做到极限再判断是否有微调的必要。8.2 LoRA 与轻量化微调在微调领域LoRA 是一种常见的轻量化微调方案。它的思路不是更新全部模型参数而是冻结原始权重只训练一小部分低秩矩阵参数能大幅降低显存和计算需求。很多开源工具都支持 LoRA 或 QLoRA 方式微调QLoRA 还会结合量化进一步降低门槛。微调命令在不同的开源工具里差异很大这里不写死具体的工具参数。以常见的开源微调工具为例大致的流程是准备训练数据集整理成对话格式选择基础模型配置 LoRA 参数和训练轮数然后启动训练。执行前一定要看对应工具的官方文档因为参数名和格式变化很快。你需要记住的共性是微调要有数据、要选基础模型、要确定训练策略、要留测试集做效果对比。没有测试集的微调基本等于盲调。8.3 效果评估怎么做很多人在微调后只凭“感觉回答变好了”来判断效果这是不够的。靠谱的做法是准备一套测试用例包含输入、期望输出和打分维度然后在微调前后分别跑一遍对比差异。评估维度可以根据任务类型定义。比如问答类任务可以看回答准确度、完整度、格式规范性、是否出现幻觉代码类任务可以看能否编译通过、逻辑是否正确。入门阶段不需要上复杂框架先用一个 JSON 文件管理测试用例再写脚本批量请求模型并保存结果人工或程序化打分即可。还要注意大模型投毒测试和异常输入测试。你可以故意输入包含恶意指令、越权要求或敏感信息的数据观察模型是否会泄露不该输出的内容。这个环节在正式接入生产环境前非常重要尤其是涉及公司内部数据或隐私数据的场景。8.4 工程化落地建议工程化落地时不要把模型调用裸写在业务代码里。推荐的做法是本地模型独立成一个服务业务系统通过 API 访问任务量上来后增加批量任务队列和失败重试所有请求和输出都记录日志方便复盘。大模型应用开发不只是一个模型调用它至少包含数据处理、提示词管理、接口服务、日志监控、效果评估和权限控制几个部分。第一次做生产化部署时建议先用最小可运行配置验证链路再逐步加并发、加缓存、加模型管理。9. 常见问题与排查方法下面整理了一份常见问题排查表。遇到问题时先看日志再对照表格逐项排查。问题现象可能原因排查方式解决方案模型下载很慢或中断网络不稳定或模型文件较大查看网络状态和下载日志重新执行拉取命令使用下载工具或镜像源Ollama 启动后无法对话模型未正确加载执行ollama list和ollama ps确认模型名并重新拉取服务启动后页面打不开端口被占用或服务未启动查看启动日志和端口占用更换端口或重启服务API 调用超时模型加载较慢或并发过高检查服务端日志和显存延长 timeout降低并发换小模型显存不足导致进程退出模型过大或上下文过长用nvidia-smi观察峰值显存换量化模型、缩短上下文、减少并发输出内容不符合预期提示词约束不够检查提示词是否包含输出格式增加角色、限制和少样本示例批量任务中途卡住某个请求长时间没有返回查看日志中卡住的请求增加超时上限和失败重试机制量化后效果变差精度压缩过大对比量化前后的测试集结果尝试更高位宽的量化版本微调后效果没有提升数据量不足或训练参数不合适检查训练集规模和 Loss扩充数据、调整 LoRA 参数这一周学习过程中最容易踩的一个坑是把大量时间花在配置环境上而忽略了功能验证。环境只是手段跑通一次对话、调通一次接口、完成一次 RAG 检索这些才是真正的进度。到这里一周路线已经完整走完。你可以把这套流程作为以后接触新模型的脚手架先部署再调用再按需做知识库最后根据效果决定是否微调。建议先收藏这条路线然后从“把模型跑起来”这一步开始动手。