做这行的人最近两年应该都有同一种体感以前跟别人聊我在做算法对方会问是推荐还是风控现在说我在做大模型对方十有八九会追问一句是调 API 还是自己训。这个追问其实很精准它把大模型开发这件事的核心分野一下子就戳出来了——调用别人封装好的接口和自己把模型跑起来、改得动、接得上业务中间隔着的不是一行代码而是一整套工程认知。这份入门笔记就是写给那批想跨过这道坎的人你可能是有几年后端或前端经验的工程师可能是刚接触 AI 方向的学生也可能是产品或者运维岗想搞清楚这套东西到底吃多少资源、链路有多长。我会从最实际的问题切入——显存怎么算、模型怎么挑、推理框架怎么选、微调到底改了什么、RAG 为什么比微调更适合大多数场景——把一条能真正跑通的学习路线摊开讲尽量让每一步都有可验证的命令和参数而不是停留在概念介绍。1. 大模型开发到底在开发什么很多人一上手就去啃 Transformer 论文啃完发现还是不知道从哪下手。问题出在把研究和开发混成了一件事。做研究关心的是为什么这种结构能work做开发关心的是给定一个已经开源的权重文件我怎么把它变成能对外提供服务、能接自家数据、能控成本的东西。这两件事需要的能力重叠度其实不高入门阶段优先解决后者收益更大。1.1 从用模型到造应用的三层能力模型我把入门路径粗分成三层一层叠一层跳级学容易出现每个词都认识但串不起来的状况。第一层是推理部署。核心目标只有一个让模型在你自己的机器或者服务器上稳定地把一段输入变成一段输出。这一层要搞明白的东西包括显存占用估算、量化格式的差异、推理引擎的选择、以及并发请求下吞吐和延迟的取舍。这一层做通了你至少拥有了一个私有的、可控成本的对话或者生成服务。第二层是能力改造也就是围绕模型做上下文增强或者参数微调。前者是把外部知识在推理时塞进提示里也就是 RAG后者是拿自己的数据去调整模型的一部分参数也就是微调。这两条路的适用边界非常清晰选错了会浪费大量时间知识更新频繁、要求可溯源选 RAG风格、格式、特定任务的表达习惯要固化选微调。第三层是应用工程。到了这一层模型本身反而成了链路中的一环你要处理的是提示词管理、多轮会话状态、工具调用、缓存、限流、失败重试、评测。真正落到业务里的项目工作量的大头往往在这一层而不是模型本身。1.2 入门者最容易走偏的三个方向第一个坑是把时间全花在预训练上。从零预训练一个可用的基座模型需要的数据量和算力投入对个人和小团队来说是不现实的而且即使训出来效果大概率也不如现成的开源权重。入门阶段应该把训练限定在微调这个尺度上。第二个坑是迷信参数越大越好。一个 70B 的模型在单张消费级卡上跑起来要么量化到精度崩掉要么速度慢到没法做交互。实际项目里7B 到 14B 这个量级的模型配上好的提示工程和知识库在很多垂直任务上的表现完全够用而且迭代速度快几十倍。第三个坑是跳过评测。调完提示词、微调完模型感觉好像变好了但没有一套固定的测试集做对比过两周你根本说不清哪个版本更靠谱。从第一天起就准备二十到五十条有代表性的输入输出样例作为回归测试基准这个习惯能省下大量返工。2. 本地部署大模型显存到底该按什么算硬件是绕不过去的现实问题。网上关于配置的讨论经常是我这卡能跑吗这种问法但更准确的问法应该是我要在什么精度、多长上下文、多大并发下跑多大的模型。这三个变量一变结论完全不同。2.1 参数量、精度、显存三者的换算逻辑先记住一个粗糙但好用的公式推理显存 ≈ 权重占用 KV Cache 框架开销权重占用的算法很直接参数量乘以每参数字节数。FP16 每参数 2 字节INT8 是 1 字节4bit 量化大约 0.5 字节。所以一个 7B 模型FP16 下光权重就要 14GB 左右4bit 量化后降到 3.5GB 上下。这就解释了一个常见现象同一张 8GB 显存的卡跑 FP16 的 7B 模型必爆跑 4bit 量化的就很宽裕。KV Cache 是很多人忽略的部分它随着上下文长度和并发数线性增长。计算公式是KV Cache 字节数 2 × 层数 × KV头数 × head_dim × 序列长度 × 并发数 × 精度字节数拿一个典型的 8B 级别模型举例32 层、8 个 KV 头用了 GQA 分组查询注意力、head_dim 为 128、上下文 4096、并发 1、FP16。代入算一下2×32×8×128×4096×2 ≈ 512MB。看起来不多但如果把上下文拉到 32K 并发开到 8这个数字会膨胀到 32GB 以上直接超过权重本身。所以做长文本场景时KV Cache 往往才是真正的瓶颈。2.2 预算有限时的三条现实路线预算在两三千块这个量级基本只能走 CPU 内存的路线或者用二手显卡。CPU 推理的速度取决于内存带宽经验值大概是几 token 每秒做批处理任务可以做实时对话会很煎熬。预算在八千到两万可以上 12GB 到 24GB 显存的卡。这个区间是我最推荐的入门配置24GB 显存能跑 4bit 量化的 14B 模型加中等长度上下文或者 7B 模型 FP16 加较长上下文选择余地很大。再往上就是多卡或者专业卡的路子。这时候考虑的重点就从能不能跑变成每百万 token 的成本是多少属于另一个话题了。注意显存估算只解决装得下不解决跑得快。同样的显存占用下不同推理引擎的吞吐可能差三到五倍这个差异在部署章节里细说。3. 推理框架选型Ollama、llama.cpp、vLLM 分别适合谁选框架这件事很多人是看哪篇文章火就用哪个结果在错误场景里用错工具然后得出这东西不好用的结论。实际上这几个主流方案的设计目标差异极大先把场景想清楚再选能少走很多弯路。3.1 三款主流推理方案对照方案核心定位硬件适配并发能力上手难度典型场景Ollama开箱即用的本地运行时CPU / 各类 GPU弱极低个人实验、桌面助手、原型验证llama.cpp极致轻量的 C 推理CPU / Metal / CUDA弱到中中无 GPU 环境、边缘设备、嵌入式vLLM服务化高吞吐推理以 NVIDIA GPU 为主强中高线上服务、批量任务、多用户共享Ollama 的价值在于把模型下载、格式转换、量化选择、服务启动这些步骤压缩成了一条命令代价是它对并发和高负载场景基本没做优化。llama.cpp 的强项是量化格式丰富、内存占用控制得好在没有独立显卡的机器上几乎是唯一解。vLLM 的核心卖点是 PagedAttention它借鉴操作系统虚拟内存分页的思路来管理 KV Cache把显存碎片降到很低因此在多并发请求下吞吐量优势明显。3.2 用 Ollama 跑通第一次本地推理这是最快能看到结果的一条路适合完全没接触过的同学建立信心。# 安装完成后拉取模型并直接进入交互 ollama run qwen2.5:7b # 查看本地已有模型 ollama list # 以服务方式常驻默认监听 11434 端口 ollama serve服务起来之后可以直接用 HTTP 接口调用curl http://localhost:11434/api/generate -d { model: qwen2.5:7b, prompt: 用三句话解释什么是注意力机制, stream: false }跑通之后建议做两件事。一是把OLLAMA_NUM_PARALLEL和OLLAMA_MAX_LOADED_MODELS这两个环境变量调一调前者控制并发处理数后者控制同时驻留的模型数量理解了它们你就能解释为什么第二个请求进来时慢了一大截。二是打开任务管理器或者nvidia-smi盯着显存看一遍把前面算出来的理论值和实测值对一下这个对照过程比看十篇文章都管用。3.3 vLLM 部署与并发请求到底指什么很多人在查资料时会撞上大模型并发请求这个词理解得比较模糊。简单说并发请求就是同一时刻有多个请求都在等着模型输出。因为大模型是逐 token 生成的一个请求往往要占用几百毫秒到几秒如果串行处理第二个用户就得排队等到天荒地老。所以服务化部署必须解决多个请求交替推进的问题。不同框架的解法不一样。早期做法是静态批处理攒够一批一起算但这一批里最长的序列会拖住所有人。vLLM 用的是连续批处理某个请求生成完了就立刻从批次里退出新请求随时补进来显存利用率高很多。这也是它在高并发下吞吐领先的原因。部署命令大致长这样python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-Instruct \ --tensor-parallel-size 1 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --port 8000几个参数值得单独说。tensor-parallel-size是张量并行度等于用几张卡来切分模型权重单卡就填 1。max-model-len决定最长上下文调大它会按前面说的公式吃掉 KV Cache。gpu-memory-utilization是显存使用上限比例默认 0.9留 10% 给框架和其他进程如果遇到CUDA out of memory却又觉得算得没错先降这个值试试。起来之后接口是 OpenAI 兼容的原来写好的调用代码改一下base_url就能切换这一点对迁移特别友好。提示如果你的场景是单用户偶尔用一下别上 vLLM部署复杂度不划算如果场景是多用户共享或者批量离线任务别用 Ollama 扛吞吐会成为瓶颈。选型标准是并发量不是模型大小。4. 大模型微调LLaMA-Factory 能帮你省掉哪些活微调是这个领域最容易被神化的环节。很多人以为微调是把模型教聪明实际上大多数情况下微调做的是把模型教规矩——让它稳定地按你要求的格式、话术、判断倾向来输出。想清楚这个定位微调的期望值就正常了。4.1 微调之前必须想清楚的三件事第一你的问题能不能用提示工程解决。如果换几版提示词效果就能达标那就不需要微调。微调的隐性成本很高要准备数据、要调参、要评测、还要维护模型版本。第二你的数据量够不够。LoRA 微调对数据量的要求比全参数微调低但一般也要几百到几千条高质量样本才能看到稳定效果。几十条数据也能训只是很容易过拟合表现为在训练集上答得漂亮换个说法就崩。第三你选全参数微调还是参数高效微调。全参数微调会更新所有权重显存需求是推理的几倍7B 模型基本要 80GB 以上显存才舒服。LoRA 只训练一小部分低秩矩阵显存需求大幅下降一张 24GB 的卡就能微调 7B 模型这是个人开发者唯一现实的选择。4.2 数据准备格式比数量更重要LoRA 微调常用的数据格式是指令-输出对整理成 JSON 或者 JSONL{ instruction: 把下面这句话改写成正式书面语, input: 这事儿我觉得不太行, output: 我认为此项方案存在一定可行性风险。 }数据质量上有几个经验性的判断标准。一是多样性比重复性重要同一个意思换五种说法作为五条样本比同一条样本复制五遍有用得多。二是输出风格要一致如果你要求模型输出 JSON那所有训练样本的输出都必须是合法 JSON哪怕一条格式错了模型也会学到坏习惯。三是别混入低质量样本网上抓来的对话数据往往噪声很大清洗的成本通常低于它带来的收益。4.3 LoRA 关键参数的取值逻辑LoRA 有几个绕不开的参数理解了它们的作用调参就不是瞎试了。lora_rankr决定低秩矩阵的维度也就是新增参数的多少。常用值 8、16、32、64。任务越复杂、和你原有数据分布差得越远r 该越大。风格模仿类任务 r 取 8 到 16 往往就够学一种全新的输出结构可能要 32 以上。lora_alpha是缩放系数通常设成 r 的两倍。它和 r 的比值决定 LoRA 分支输出的强度比值太大会让训练不稳。target_modules指定给哪些层加 LoRA。常见做法是覆盖注意力部分的 q、k、v、o 投影层追求更好效果时再加上前馈层的 gate、up、down。模块加得越多显存和训练时间越高。learning_rate在 LoRA 场景下通常比全参数微调大一个量级1e-4 到 2e-4 是常见区间。用 LLaMA-Factory 的话这些参数都在一个 YAML 配置文件里改完直接跑命令llamafactory-cli train examples/train_lora/qwen_lora_sft.yaml一份精简的配置大致是这样model_name_or_path: Qwen/Qwen2.5-7B-Instruct stage: sft finetuning_type: lora lora_rank: 16 lora_alpha: 32 lora_target: q_proj,k_proj,v_proj,o_proj dataset: my_dataset template: qwen cutoff_len: 2048 per_device_train_batch_size: 2 gradient_accumulation_steps: 8 learning_rate: 1.5e-4 num_train_epochs: 3 bf16: true output_dir: saves/qwen_lora这份配置里有几个点是踩过坑才知道的。template必须和模型匹配Qwen 系列用qwenLlama 系列用llama3用错了模型学不到正确的对话边界效果会莫名其妙地差。cutoff_len是截断长度设得比实际样本长度大很多会白白浪费显存。gradient_accumulation_steps是梯度累积等效于把 batch size 放大 8 倍这是在显存不够时提升有效批大小的标准手段。bf16在支持的新卡上开着比 fp16 数值稳定性更好。4.4 微调后的合并与验证LoRA 训完得到的是一个适配器权重文件体积通常只有几十到几百 MB。用的时候有两种方式一是推理时同时加载基座和适配器二是把适配器合并进基座得到一个完整的模型。合并的好处是部署简单坏处是失去了灵活切换多个适配器的能力。验证环节容易被跳过。我的做法是准备一份固定的测试集微调前后各跑一遍人工打分或者用规则校验格式合规率。光看训练 loss 下降没有意义loss 降了但输出变得啰嗦、开始复读、拒绝回答这些情况都真实存在。5. RAG 应用开发让模型接上你自己的知识如果你的需求是让模型知道我们公司的产品手册内容那大概率不该选微调。微调是把知识压进参数里成本高、更新慢、还容易记错RAG 是在推理时把相关资料检索出来塞进上下文更新只需要改数据库而且能给出引用来源可解释性好得多。这就是为什么大多数企业级的大模型应用开发项目骨架都是 RAG。5.1 RAG 链路的完整拆解一条标准的 RAG 链路分两个阶段。离线阶段做文档处理加载原始文档、切分成块、用嵌入模型转成向量、存进向量数据库。在线阶段做检索增强把用户问题也转成向量、在库里找最相似的若干个块、把这些块拼进提示词、交给大模型生成答案。每个环节都有坑。文档解析阶段PDF 里的表格和双栏排版经常被解析成一团乱码行业里有个说法叫垃圾进垃圾出这一步做不好后面全白搭。切分阶段块太大检索不精准块太小语义不完整。嵌入阶段中文场景要选对嵌入模型直接拿英文模型处理中文效果会明显下滑。检索阶段纯向量检索对关键词类的精确匹配不敏感通常要配合关键词检索做混合召回再加一个重排序模型做精排。5.2 切分与检索的关键参数切分长度是第一个要定的事。常见区间是 256 到 512 个 token配合 10% 到 20% 的重叠。重叠的意义在于避免一句话被拦腰截断后两边都读不通属于低成本高收益的设置。召回数量 k 值通常在 3 到 10 之间。k 太小可能漏掉关键信息k 太大则会把噪声塞进上下文反而干扰模型判断而且上下文越长成本越高、速度越慢。我的一般做法是先召回 20 条用重排序模型打分后再取前 3 到 5 条喂给模型。关于RAG 怎么读这个搜索热词顺手说一句。它不是三个字母拼读而是作为一个整体单词读类似拉格。这个小细节在实际交流中挺影响观感的第一次开会听到别人念成 R-A-G 的时候你大概就能判断对方是刚入门的。5.3 一个最小可跑的 RAG 流程用现成的编排工具能快速搭出原型。以本地模型加编排框架为例核心环节无非是配置本地模型的接入地址、加载文档、建索引、组装检索问答链。from langchain_community.document_loaders import TextLoader from langchain_text_splitters import RecursiveCharacterTextSplitter from langchain_community.vectorstores import Chroma from langchain_community.embeddings import HuggingFaceEmbeddings from langchain_community.llms import Ollama loader TextLoader(handbook.txt, encodingutf-8) docs loader.load() splitter RecursiveCharacterTextSplitter( chunk_size400, chunk_overlap60, separators[\n\n, \n, 。, , , , ] ) chunks splitter.split_documents(docs) embedding HuggingFaceEmbeddings(model_nameBAAI/bge-small-zh-v1.5) store Chroma.from_documents(chunks, embedding, persist_directory./db) llm Ollama(modelqwen2.5:7b, temperature0.2) question 手册里对请假流程是怎么规定的 hits store.similarity_search(question, k4) context \n\n.join([h.page_content for h in hits]) prompt f仅根据下面的资料回答问题资料中没有的内容直接回答资料未提及。 资料 {context} 问题{question} print(llm.invoke(prompt))这段代码里有三个值得注意的设计。切分器的分隔符列表把中文标点放在了前面这是为了在中文文档里尽量按句子边界切比按固定字符数硬切效果好很多。temperature设成 0.2 是为了让回答稳定知识问答场景不需要创意。提示词里那句资料未提及就直接说未提及是防幻觉的关键没有这句话模型在检索不到内容时会自己编一个看起来很合理的答案。6. 常见问题排查速查表前面几章偏重怎么做这一章集中说做不出来怎么办。下面这些问题几乎每个入门的人都会撞上至少两三个。6.1 显存、速度、输出质量三类典型故障报CUDA out of memory但显存估算明明够。大概率是 KV Cache 超了尤其是你把上下文长度设得很大或者并发数上去了。先把max-model-len砍一半试再把显存使用比例降到 0.85一般能定位到原因。另外注意nvidia-smi显示的显存会被上一个没退干净的进程占着重启或者杀掉残留进程再看。模型能跑但速度慢得离谱。先确认模型是不是真的跑在 GPU 上。常见情况是装的是 CPU 版本的推理库程序明明没报错实际全在 CPU 上算。再确认有没有用到量化FP16 的 7B 模型在 8GB 卡上虽然勉强能加载但会频繁在显存和内存之间换页速度能慢十倍以上。输出开始复读同一句话。这是解码策略的问题检查 repetition penalty 是不是设得太低或者干脆没设。也有可能是上下文里塞了太多相似内容模型找不到新东西可讲。微调后模型变笨了。先看学习率是不是太大LoRA 场景下超过 3e-4 很容易把模型带偏。再看数据量几百条以下的数据训三个 epoch 基本是在过拟合。还有一个隐蔽原因模板配置和基座模型不匹配导致模型在错误的对话边界上学习。RAG 检索到了内容但回答还是错的。这时候要打印出来看实际召回了什么。很多时候是切分把一句话切断了或者嵌入模型对中文语义的区分度不够。换一个中文优化过的嵌入模型或者引入重排序环节通常能改善。并发一上来响应时间爆炸。这是推理引擎的选择问题单实例的轻量方案在高并发下就是会排队。要么换成对并发做过优化的服务化框架要么起多个实例在前面挂个负载均衡。6.2 排查思路的通用套路把上面这些散点归纳一下排查大模型问题有个固定顺序先确认硬件层模型在哪跑、显存够不够再看配置层参数是不是配错了、模板对不对然后看数据层输入输出长什么样最后才怀疑模型本身。绝大多数问题出在前三层直接怀疑模型能力是最容易走偏的方向。提示调试时务必把完整的提示词和模型原始输出打印出来。很多模型答得不对的问题看到原始提示词就明白了——要么是上下文被截断了要么是模板拼接多了一个换行要么是系统提示被后面的指令覆盖了。6.3 一份可以照着走的学习路线把学习顺序排一下避免东一榔头西一棒子。阶段目标关键动作参考时长第一阶段建立直觉读注意力机制的可视化讲解理解 token、上下文、温度这些基础概念1 到 2 周第二阶段跑通推理用轻量工具在本地跑起一个 7B 模型用接口调通观察显存变化1 周第三阶段服务化部署用服务化框架部署压测并发理解吞吐与延迟的取舍2 到 3 周第四阶段搭 RAG从文档切分到检索问答完整走一遍调切分和召回参数2 到 4 周第五阶段做微调用参数高效方法微调一个模型建立评测集做前后对比3 到 4 周第六阶段应用工程加缓存、限流、评测、多轮会话管理做成可交付的东西持续这个路线里我会特别强调第三阶段不要省。很多人从本地跑通直接跳到搭 RAG结果一到真实并发场景就发现整个方案推倒重来。先理解服务化的约束再往上叠应用返工率低很多。7. 生态变化与几个容易被问到的方向学到这里基本能应付大多数入门级需求了。剩下的是一些方向性的判断这些问题在面试和同行交流里被问到的频率很高提前有个自己的看法会舒服很多。7.1 多模态大模型给开发带来什么变化多模态能力的普及最直接的影响是输入端从一段文本变成了文本加图片加音频。对开发者的影响体现在三块。一是预处理链路变长了图片要缩放、要切分、要控制分辨率因为视觉 token 的消耗往往比文本高一个量级一张高分辨率图片可能顶掉几千个 token 的上下文预算。二是检索方式变了以前只需要文本嵌入现在要处理图文混合的跨模态检索。三是评测更难了文本任务还能用规则校验图像理解的对错很多时候只能靠人工抽样。从工程角度看多模态并没有推翻原有的架构RAG、微调、服务化这些套路都还在只是每个环节处理的数据类型多了。所以入门阶段把文本这条线走扎实扩展到多模态的时候迁移成本并不高。7.2 关于会不会挤压原有方向的观察经常有人问多模态和大模型的普及会不会把原来的一些技术方向挤没了。我自己的观察是被压缩的往往不是方向本身而是那些只停留在工具使用层面的岗位。举个具体的例子图形化编程这类面向青少年的启蒙内容核心价值在于培养逻辑思维和拆解问题的习惯这个目标和模型能不能生成代码是两回事。模型擅长的是把想法快速变成代码但想法从哪来这件事恰恰是需要长期训练的。真正在变化的是门槛的位置。以前会写一个 CRUD 接口就能找到工作现在这部分被自动化得很彻底但能判断一个方案在数据量翻十倍之后还能不能撑住、能在一堆看起来都对的输出里挑出真正靠谱的那个这种判断力的价值反而在上升。7.3 几个实践中的个人体会说几条我在实际项目里踩出来的经验都是文档里不太会写的。第一条别一上来就追求端到端。RAG 的效果不好很多人第一反应是换更大的模型。实际拆开看八成的问题出在文档解析和切分上输入的东西本身就是残缺的换什么模型都救不回来。把每一环单独跑一遍看中间产物长什么样定位效率高得多。第二条给模型留退路。让模型在不确定的时候说我不确定比让它硬编一个答案要好得多。做法上就是在提示词里明确允许它拒答并且在评测时把该拒答的时候拒答了也算作正确。第三条成本要算 token 账。上下文越长、召回条数越多单次请求的成本越高。很多人做原型时不看这个上线后发现账单吓人。做设计的时候就把平均每次请求消耗多少 token当作一个指标盯着会逼着你把提示词写得更精简。第四条版本管理要覆盖提示词。代码用 Git 管是常识但提示词往往散在代码各处改一版就找不回上一版了。把提示词单独抽成配置文件纳入版本管理出了问题能快速回滚做 A/B 对比也方便。第五条先做一个能用的再做一个好的。刚入门的时候最容易陷入无止境的方案调研比来比去两个月过去了还在选框架。挑一个能跑通的方案先做出一个能演示的东西拿到真实反馈之后再优化这个顺序几乎在所有情况下都更有效率。