★ FEATURED ARTICLE 1. 先搞明白大模型的几个底层概念很多人一上来就找“大模型学习路线图”到处收藏资料结果越存越焦虑。我觉得问题不在资料不够而是在动手之前缺少一套能帮你判断“该学什么、什么是重点”的认知框架。大模型这个领域看着庞杂但核心概念就那么几个。先把这些底层概念磕明白再去看路线、框架、源码你会发现方向感完全不同。1.1 训练与推理大模型的两个阶段大模型落地到实际项目里一定绕不开两个阶段训练和推理。训练是把海量文本喂给模型让模型通过预测下一个词的方式学习语言的统计规律。这个过程消耗的是算力和时间产出的是一堆权重参数。推理则相反是拿着训练好的权重输入一句话让模型生成回答。我们平时用的 ChatGPT、本地部署的 Ollama 服务全部处于推理阶段。理解这两个阶段的区别特别重要因为它直接决定了你的硬件需求。训练阶段哪怕用微调这种轻量方式也得考虑显存能否装下模型和梯度推理阶段则主要看显存能否装下模型权重和 KV Cache。我见过不少新手在部署一个 7B 模型时以为“能跑起来”就万事大吉结果上下文一拉长就 OOM显存溢出。这就是没分清推理时 KV Cache 对显存的动态占用它和序列长度直接挂钩。1.2 参数、上下文、量化与多模态参数量是大模型最显眼的标签。7B、14B、72B这里的 B 指 Billion也就是十亿。参数越多模型理论上越聪明但推理成本和显存需求也水涨船高。拿 7B 模型来说FP16 精度下光权重就要占 14GB 显存这也是为什么很多人的显卡“刚好能跑”却又总是爆显存的原因。上下文窗口Context Window解决的是“模型一次性能看多少内容”的问题。从早期的 4K、8K到现在常见的 32K、128K上下文越长越能处理长文档、长对话。但长上下文的代价是推理时的 KV Cache 占用呈线性甚至超线性增长这也是 OOM 的高发地。量化则是为了在性能和资源之间找平衡。简单说就是把模型权重的精度从 FP16 降到 INT8 或 INT4用精度换体积和推理速度。GGUF、GPTQ、AWQ 是三种最常见的量化格式。GGUF 在 llama.cpp 和 Ollama 上用得最多适合 CPU 和混合推理GPTQ 针对 GPU 做了优化AWQ 在激活感知上做文章。新手不需要研究太深知道“量化是让大模型在普通硬件上跑起来的核心技术”就够了。多模态则是让模型能同时理解文本、图像、音频等多种输入。像 Qwen2.5-VL、Llama 3.2 Vision 这类模型就是把视觉编码器和语言模型拼接后做统一训练。如果你后续做知识库、图片理解类应用多模态基本是标配。2. 系统性入门路线把学习拆成四个阶段我看过太多“大模型学习路线图”了都是从 Python 语法讲到 Transformer 源码再讲到分布式训练。这套路线不是不对而是对绝大多数人来说——太长、太理论、太容易劝退。我建议反着来先学会用再学会部署然后进阶到微调最后啃应用开发。每一个阶段都能产出看得见的结果这种正反馈很重要。2.1 阶段一会用 API建立体感这个阶段的目标是熟练掌握提示词工程Prompt Engineering和上下文工程Context Engineering能通过 API 或 Web 端让模型稳定地完成具体任务。不要小看这一阶段现实中 80% 的场景靠提示词就能解决不需要微调和部署。提示词工程的核心是给模型明确的任务指令、角色设定、输出格式和示例。你会慢慢发现模型的回答质量很大程度取决于你把问题定义得多清楚。上下文工程则更进一步它关注的是如何把外部知识放进上下文里让模型基于给定的资料回答问题这就是 RAG检索增强生成的思路。写科研论文、分析股票 K 线、做 PPT 大纲本质上都是提示词和上下文调优的结果。这个阶段的资料首选各家大模型厂商的官方文档和示例仓。OpenAI、Google、阿里 Qwen、智谱等等都有很好的中文文档。别急着背 prompt 模板要理解为什么这样写有效。我自己的经验是把常用的任务摘要、改写、结构化抽取各写 20 条提示词慢慢你就有感觉了。2.2 阶段二会部署掌握模型服务化会用 API 之后你会发现开源模型的圈子更精彩而且没有调用次数限制和隐私顾虑。这个阶段的目标很明确在自己电脑或服务器上跑起一个开源模型并提供一个标准的 OpenAI 兼容 API 接口。推荐从 Ollama 入手因为它对新手极度友好。安装后一条命令ollama run qwen2.5:7b就能把模型跑起来。之后进阶到 vLLM它更强调吞吐量和生产环境支持连续批处理和 PagedAttention高并发场景下优势明显。llama.cpp 则适合追求极致轻量的场景纯 CPU 推理也能跑。这个阶段你会接触到 GGUF 格式、显存管理、并发参数、上下文长度设置等一系列工程问题。把这些问题一个一个解决掉你对大模型推理的整个流程就有了扎实的理解。相关关键词里面出现了“Windows 11 部署大模型 hermes”“本地部署大模型让个人电脑智能化”……这正是这个阶段会遇到的典型场景。2.3 阶段三会微调打造专属能力微调Fine-tuning解决的是提示词搞不定的事情。提示词能改变模型的说话方式但改变不了模型不知道的知识。比如你想让模型学会你公司的内部术语、特定的代码风格、某种专业知识体系就得靠微调把知识“注入”到权重里。这个阶段不用自己从零训练模型主流做法是拿开源基座模型如 Qwen2.5-7B、Llama-3.1-8B做增量微调。常用的有 LoRA、QLoRA 这类参数高效微调技术它们在冻结大部分权重的基础上训练一小部分额外参数显存门槛大幅降低。以 Qwen2.5-7B 在单张 24GB 显存的显卡上做 LoRA 微调为例训练批次大小batch size设为 1梯度累积步数设为 8使用 INT4 量化加载基座模型显存占用可以控制在 16GB 左右。这意味着 RTX 4090 甚至部分 4060 Ti 16GB 都可以玩得转。工具方面LLaMA-Factory 是中文社区最流行的微调框架配置简单图形界面也很友好适合动手实操。微调完了不能只看 Loss 下降就完事还要做效果对比验证。拿微调前后的模型在同一批测试问题上跑一遍你会发现领域术语明显变准了但也要警惕过拟合带来的通用能力下降。这个阶段是理解大模型“可塑性”的关键一步也是很多行业应用的第一步。2.4 阶段四会开发从模型到产品最后一个阶段是把你掌握的模型能力封装成真正的产品功能。这里的技术栈很清晰后端负责对接大模型 API 或自建推理服务前端负责交互和流式展示中间用 SSE 或 WebSocket 传数据。相关的热词里有“基于什么技术栈封装 AI 交互逻辑”“通过 SSE 流式输出实现大模型回答实时渲染配合 abort”。这已经是标准的工程师视角了。后端建议用 Python FastAPI 或 Java Spring AI。FastAPI 的 async 特性和 SSE 支持非常丝滑Spring AI 则适合已经重度使用 Java 技术栈的团队。前端需要处理流式输出用 fetch 的 ReadableStream 或 EventSource 逐块接收 Token 并渲染同时配合 AbortController 实现“停止生成”按钮。移动端方面Android 集成 GGUF 模型做本地推理也已经成熟工具链有 llama.cpp 的 Android JNI 封装、MediaPipe LLM Inference API 等。到这个阶段你已经具备了独立完成一个完整的“大模型应用”的能力。从模型选型、部署、提示词设计到前后端联调整套链路都能自己扛下来。这四步走完你就不再是“只会聊聊天”的 AI 爱好者而是一个能把大模型落地成产品的人。3. 本地部署实战让开源模型跑在你自己的机器上“本地部署”是热度最高的关键词之一也是最容易踩坑的环节。很多人卡在环境配置和显存不足上。我把这部分的关键细节掰开揉碎讲清楚。3.1 硬件配置怎么选显存是硬门槛本地部署第一个问题你的电脑能不能跑核心判断依据是显存。以下是不同参数量模型在常见精度下的显存参考模型规模FP16 权重显存INT4 量化后显存推荐显卡1.5B约 3GB约 1.5GB8GB 即可流畅7B约 14GB约 5GB12GB 以上14B约 28GB约 8GB24GB 稳妥72B约 144GB约 40GB多卡或量化 CPU offload注意这只是权重显存推理时的 KV Cache 还要额外占 1GB 到 8GB取决于上下文长度。所以我的建议是如果只是体验和开发7B 量化模型配 12GB 显存是最舒服的组合如果有微调需求直接上 24GB。另外热词里出现了 “rx6750gre训练大模型”。这里多说一句AMD 显卡不是不能用但生态和 NVIDIA 相比差距明显。NVIDIA 有 CUDA 和 cuDNN几乎所有框架开箱即用AMD 要靠 ROCm兼容性和安装难度都高不少。RX 6750 GRE 属于中端卡跑 7B 模型的推理基本没问题但想做 GPU 微调还是建议 NVIDIA 显卡。如果你是认真的入门者不要在这上面省钱。3.2 部署工具怎么选Ollama、vLLM 还是 llama.cpp选对工具能省掉一半的坑。下表是我实际用过之后的对比工具上手难度推理速度并发能力适用场景Ollama极低中等中本地体验、轻量开发vLLM中等高高生产服务、高并发 APIllama.cpp中等中低CPU 推理、移动端、边缘设备AirLLM中慢低显存极小场景通过磁盘交换运行超大模型新手第一站强烈推荐 Ollama。它把模型下载、量化管理、API 提供封装成简单命令内部用 llama.cpp 做推理引擎。启动后自动暴露http://localhost:11434/v1的 OpenAI 兼容接口这意味着你写代码时不用区分是调 OpenAI 还是调本地模型统一用 OpenAISDK 即可。vLLM 则适合对吞吐量和并发有要求的场景。它用 PagedAttention 优化了 KV Cache 的内存管理批量推理时吞吐量是普通推理框架的数倍。如果你之后要把模型做成一个多人使用的服务vLLM 是首选。AirLLM 是个特例它允许在 4GB 甚至更小的显存上跑 7B、13B 模型原理是分层加载把不同层的数据在显存和内存之间调度。速度慢一些但确实解决“能不能跑”的问题。3.3 从下载到调用一条完整的部署流程以最常用的 Ollama Qwen 模型为例整条链路不长# 安装 ollamaLinux/macOS curl -fsSL https://ollama.com/install.sh | sh # 拉取模型并运行 ollama pull qwen2.5:7b ollama run qwen2.5:7b此时你就能在终端和模型对话了。但这还不够我们还需要一个 API 接口。Ollama 默认已经在11434端口提供了 OpenAI 兼容接口直接用 curl 测试curl http://localhost:11434/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen2.5:7b, messages: [{role: user, content: 你好请介绍一下你自己}], stream: false }返回的 JSON 结构和 GPT 的接口长得很像只是 base_url 变成了本地地址。这也是为什么我说 Ollama 是开发者的好测试工具——你的业务代码完全可以只维护一个 base_url 的配置开发和线上切换零成本。3.4 部署中的性能调优与三个细节跑起来只是第一步跑得舒服需要调几个参数。首先是num_ctx上下文窗口长度它直接影响 KV Cache 大小。Ollama 默认只有 2048稍微聊长一点就“失忆”调成 8192 或 16384 体验会好很多。代价是显存占用上升7B 模型的 KV Cache 在 8K 上下文下大约增加 1GB 到 2GB。其次是并发参数。Ollama 默认并发数是 1如果多个人同时访问会排队。可以设置环境变量OLLAMA_NUM_PARALLEL4让多个请求共享模型权重提高吞吐量。但注意并发增加同样会放大 KV Cache 占用显存不足时不要乱开。最后是温度temperature。推理服务默认的 temperature 可能不适合你的场景。做代码生成建议调低到 0.2做创意写作可以调高到 0.8。不要傻傻地一直用默认值。我个人在实际部署中最大的体会是如果显存紧张优先减小上下文长度而不是换更小的模型。很多任务 4K 上下文足够但模型从 7B 降到 3B回答质量下降是肉眼可见的。调参的顺序应该是先控制上下文再考虑量化程度最后才考虑降模型规模。4. 微调实战让通用模型变成领域专家微调另一个高频关键词也是很多行业从业者真正需要的技能。这里我不会讲太多理论重点放在“什么时候该微调”和“一套能跑通的最小流程”上。4.1 微调 vs 提示词什么时候必须微调在投入微调之前先做个判断。以下场景优先考虑微调模型总是无法遵循你要求的风格或格式提示词怎么写都带不回来你的领域有极强的专业术语和内部知识模型回答经常出现“一本正经胡说八道”你希望高频推理时降低成本把一个大模型的答案转移到一个小模型上知识蒸馏的场景。如果只是想让模型参考几个 PDF 或网页来回答问题优先做 RAG而不是微调。RAG 改的是输入微调改的是权重——前者的成本低得多改起来也灵活不会引入灾难性遗忘。微调是“灌入知识、改变行为风格”RAG 是“提供临时参考材料”两者定位完全不同。4.2 数据准备微调最重要的一环数据质量决定了微调上限。哪怕是 500 条高质量数据效果也可能好过 5 万条脏数据。微调数据的主流格式是 Alpaca 格式一个 JSON 文件里每一行包含三部分{ instruction: 请根据给定的需求给出 Python 代码示例, input: 写一个函数输入字符串输出反转后的字符串, output: def reverse_string(s):\n return s[::-1] }instruction 是任务指令input 是任务输入可以为空output 是期望输出。整理数据时有几条实战经验每条数据都要覆盖一个具体的业务场景不要写通用废话output 必须是模型“学得会”的格式不要夹带主观情绪注意指令的多样性。同一个语义换十种问法模型才不会过拟合到特定句式。我第一次做微调时花了整整两天清洗数据训练反而只花了一个下午。效果差异巨大这一点怎么强调都不过分。4.3 用 LLaMA-Factory 跑通微调全流程LLaMA-Factory 是目前最省心的微调工具。安装很简单git clone https://github.com/hiyouga/LLaMA-Factory.git cd LLaMA-Factory pip install -e .训练时可以写一个轻量 YAML 配置我的常用配置大概是这样model_name_or_path: Qwen/Qwen2.5-7B-Instruct template: qwen stage: sft finetuning_type: lora lora_rank: 8 lora_alpha: 16 dataset: my_dataset cutoff_len: 2048 learning_rate: 2e-4 num_train_epochs: 3 batch_size: 1 gradient_accumulation_steps: 8 quantization_bit: 4 output_dir: outputs/qwen7b-lora其中finetuning_type: lora是我们只训练低秩矩阵这比全量微调节省约 90% 的显存。quantization_bit: 4进一步把基座模型加载精度降为 INT4这一套组合之下单张 24GB 显卡就能跑 Qwen2.5-7B 的训练。训练结束后模型会保存 LoRA 适配器权重。进行推理时可以用 LLaMA-Factory 自带的 CLI 加载并合并也可以导出合并后的模型再接入 Ollama 或 vLLM。要注意合并模型前记得备份原始权重LoRA 合并是不可逆的合错了就要重新下载。导出后先用测试集对话确认输出没有崩坏再部署到服务。4.4 微调效果评估别只看 Loss训练日志里 Loss 下降是应该的但它只能说明模型“拟合了训练数据”不代表它在真实任务上更好。我的评估办法是准备 20 到 50 个真实业务问题微调前和微调后各跑一遍人工打分。评估维度包括回答的准确率、格式遵循程度、是否出现胡言乱语、通用能力下降多少。举个例子我微调过一个小型客服模型知识回答准确率从 68% 提升到了 92%但数学能力下降了不少。这就是灾难性遗忘的典型表现。解决办法是在训练数据里混入 10% 左右的通用数据保住通用能力或者降低学习率训练轮数控制在 3 轮以内。微调不是“训练一轮就行”而是“拿测试集反复验证哪个 checkpoint 最平衡”。5. 应用开发把模型能力封装成产品部署、微调都搞定之后最后一步是把模型变成用户能用的功能。这部分涉及一些前后端工程问题我挑几个最常被问的展开讲。5.1 技术栈选型封装 AI 交互逻辑“封装 AI 交互逻辑”是很多后端开发的第一痛点。其实大模型接口本质上就是一个 HTTP 接口难点在于流式响应和异步处理。我推荐的技术栈组合如下后端Python FastAPI 或 Java Spring AI前端React/Vue fetch 流式读取消息格式SSEServer-Sent Events接口兼容统一走 OpenAI 格式以 FastAPI 为例对接 Ollama 或 vLLM 时后端代码可以写得非常简洁。FastAPI 的 StreamingResponse 天然支持 SSE直接把上游的 token 流透传给前端即可。Spring AI 则内置了 ChatClient 接口和流式回调机制Java 团队用起来省力很多。核心思路是后端拿到模型返回的每个 token 都立刻通过 SSE 推给前端不等完整回答生成。这样用户看到的就是打字机效果体验远好于“转圈等完整输出”。5.2 SSE 流式输出与 abort 取消请求的完整实现SSE 流式输出是必会技能。下面给一套最小可用的前后端实现。服务端伪代码from fastapi import FastAPI from fastapi.responses import StreamingResponse from openai import OpenAI app FastAPI() client OpenAI(base_urlhttp://localhost:11434/v1, api_keyollama) def generate_stream(messages): response client.chat.completions.create( modelqwen2.5:7b, messagesmessages, streamTrue, ) for chunk in response: delta chunk.choices[0].delta if delta.content: yield fdata: {delta.content}\n\n app.post(/chat) async def chat(request: dict): messages request[messages] return StreamingResponse( generate_stream(messages), media_typetext/event-stream, headers{Cache-Control: no-cache, X-Accel-Buffering: no} )注意那个X-Accel-Buffering: no的 header它用来告诉 Nginx 不要把响应缓冲后再发否则前端会等好一会儿才看到第一段文字。前端用 fetch 流式读取const response await fetch(/chat, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ messages }), signal: controller.signal }); const reader response.body.getReader(); const decoder new TextDecoder(); while (true) { const { done, value } await reader.read(); if (done) break; const text decoder.decode(value); // 解析 SSE 数据并追加到 UI }“停止生成”按钮对应的就是controller.abort()。核心逻辑是创建一个 AbortController把它的 signal 传给 fetch用户点停止时调用 abort浏览器会立刻断开连接后端流式生成也会因为写入中断而停止。别小看这个细节没有 abort 功能的“停止生成”是假的前端断了但后端还在傻跑白耗算力。5.3 Android 端集成 GGUF 模型移动端本地跑模型也是近年的热点Android 集成 GGUF 模型的做法是用 llama.cpp 编译出 Android 的 .so 库通过 JNI 调用或者直接使用 MediaPipe LLM Inference API。选择模型时要注意手机显存/内存普遍在 8GB 到 16GB通常只能流畅跑 1.5B 到 3B 的量化模型。7B 模型在旗舰机上虽然能跑但速度偏慢首 Token 延迟可能在 2 到 3 秒不一定适合实时对话场景。提示移动端集成 GGUF 时一定要选择合适的量化版本如 Q4_K_M。这是质量和体积的平衡点比 Q8 体积小一半质量损失却很小。5.4 提示词工程与上下文工程的区别最后专门说一下这两个概念。提示词工程关注的是“怎么说清楚任务”常见手段包括角色设定、少样本示例、思维链引导。上下文工程关注的是“给模型看什么资料”比如 RAG 中检索回来的文档片段、多轮对话的历史摘要、以及需要抑制的无关内容。一个典型的 RAG 问答流程中提示词的写法相对固定“根据以下资料回答问题”。真正影响回答质量的是你塞进上下文的资料是否精准、是否去噪。所以你会看到很多应用不花大力气调提示词而是投入大量精力做知识库清洗、分块和检索排序。理解了这一点你就理解了大模型应用中“上下文为王”的底层逻辑。6. 常见问题与排查技巧实录这一部分是我特别想分享的因为都是真实踩过的坑。我用表格整理几个高发问题附上判断思路和解决方案问题现象根本原因排查方法解决方案部署后显存直接爆满上下文设置过长KV Cache 暴涨查看启动日志计算 KV Cache 占用调低 num_ctx从 2048 开始逐步增加首 Token 延迟特别高模型体积大权重加载慢观察显卡功耗曲线换量化版本或用 vLLM 的 continuous batching微调后模型胡言乱语学习率过高或数据有重复查看训练 Loss 是否震荡降低学习率到 1e-4 以下清洗重复数据API 接入后前端很久不见响应Nginx 缓冲了 SSE 流抓包看响应是否被缓存加 X-Accel-Buffering: no 头模型回答总是“复读机”采样参数设置不当检查 temperature 和 top_ptemperature 降低或用 top_k 限制候选本地部署后中文回答质量差基座模型中文语料占比低换中文友好的模型改用 Qwen、Yi 等中文原生模型显存不足但还想跑大模型没有做量化或 CPU offload查看权重精度用 GGUF Q4 量化开启部分层 CPU offload“大模型投毒测试”这类关键词近年也频繁出现本质上是模型的数据安全和鲁棒性问题。从应用方角度要注意的是避免让模型接触未经授权的私有数据以及防范提示注入——恶意用户通过在输入中夹带指令试图绕过系统约束。生产环境里应当在接入层做输入过滤、输出合规检查不要裸奔地把模型接口暴露到公网。这也应该成为一套必修的纪律而不是追加功能。除了上面再补充两个经验第一新手最容易忽略的是版本对齐。Ollama、vLLM 这些工具迭代极快不同版本对模型格式的兼容性不同。报错时先看版本号许多诡异问题都是“模型是新的工具是旧的”导致的。检查顺序永远是版本兼容性 显存 参数配置 代码逻辑。第二善用日志。Ollama 可以设置OLLAMA_DEBUG1打印详细运行日志vLLM 的日志会明确告诉你 KV Cache 分配了多少、剩余多少。很多问题看日志比看报错信息管用得多。实际调试时不要只看 stderr要多翻 stdout 里框架自己打印的性能指标。还有一点关于免费的 API 资源。“免费大模型 API”和“大模型下载平台”相关的资料很杂很多人找半天发现是套壳或者过期。我的经验是优先认准模型厂商官方渠道。开源模型从 Hugging Face 直接下载或者从 ModelScope 下载国内速度快得多商业 API 的免费额度看清限速和有效期再接入。免费额度是用来测试功能的不是用来跑生产的这个心态要摆正。写在最后一条系统入门的可行路径我从 API 调用到本地部署再到微调、应用开发这套链路完整走下来大概花了两三个月。中间无数次卡在显存溢出、数据格式不对、Nginx 缓冲这些“小问题”上但每解决一个对整套系统的理解就深一层。我个人在入门阶段最后悔的事情不是学得慢而是在资料上太贪多。今天看一个技术博客明天存一个视频教程真正动手的时间却很少。大模型是个实践性极强的领域尤其是本地部署和微调这两块光看不做等于没学。把 Ollama 装上、跑通一个 7B 模型再试着用 LLaMA-Factory 微调一个你熟悉领域的小数据集合哪怕结果不完美那种“打通全身经脉”的感觉比看完一百篇教程都值钱。最后分享一个实用的小技巧把“跑通本地模型”作为第一个里程碑时间定在一到两天内完成。这一关过了后面自然有好奇心和信心继续推进。别一开始就奔着训练 72B 模型去那是基础设施玩家的事不是入门者该干的事。
阅读完成 · 觉得有帮助？
