2026年再聊本地大模型，早就不是"能不能跑起来"的问题，而是"该选哪套工具链、怎么设计完整流程"的问题。过去两年我给自己、帮朋友、也给团队折腾过不下二十套本地部署方案：有在8GB显存笔记本上硬跑7B对话模型的，有在Mac Studio上跑70B量化模型的，也有用双卡服务器做高并发推理服务的。这篇文章就是把这段经历压缩成一份可照做的工具选型与实操指南。如果你想让数据彻底留在本机，或者不想再为云端API的账单肉疼，又或者只是想在离线环境下有一个随时能用的AI助手，下面这些内容大概率能覆盖你的场景。
我会从需求判断、工具分层、硬件数学、实操命令、调优排错一直聊到微调和多模态，尽量把每一个"为什么"都讲清楚，而不是丢给你一串复制粘贴就能跑的命令——只给命令不给原理，出了问题你根本不知道从哪里下手。
1. 动手之前，先搞清楚你要的到底是"本地可用"还是"本地好用"
很多人一上来就问我："70B的模型跑得动吗？"我通常先反问一句：你实际要解决什么问题？因为本地部署最大的成本不是钱，而是时间。方向选错了，硬件买回来吃灰，工具链换来换去，最后什么都没跑起来。
1.1 三种典型诉求，对应三套完全不同的方案
我观察下来，想本地部署大模型的人基本跑不出三类需求。
第一类是隐私优先型。对话内容、公司文档、个人笔记都不愿意出本机，要求所有数据留在本地。这种场景最适合的就是Ollama加一个本地知识库前端，模型选7B到14B的量化版本就够了，根本不用上大卡。多数私密场景里，"够用"比"最强"重要得多。
第二类是开发服务型。你需要给自家应用接AI能力，要OpenAI兼容的API接口，可能还要多人并发访问。这时候Ollama的前端体验就不够用了，更合适的方案是用llama.cpp的server模式做单机高吞吐，或者直接上vLLM做批量推理服务。并发上去了，你还要考虑连续批处理（continuous batching）和KV Cache管理，这些都不是前端工具能替你搞定的。
第三类是学习实验型。你想微调模型、试多模态、跑Agent，那重点不在部署，而在显存和数据管线。部署只是热身，微调和评测才是大头。
这三种诉求我都踩过坑。最早我图省事，不管什么场景都用同一个工具链，结果就是私密场景嫌模型太笨，服务场景嫌并发不够，实验场景嫌灵活性太差。后来想明白了：本地部署不是"装一个软件"，而是"根据需求搭一套架构"。
1.2 2026年的模型生态：从哪儿挑模型，选什么格式
2026年值得本地跑的模型已经非常丰富了，主流系列包括Qwen、DeepSeek、GLM、Llama、Mistral、Gemma、Phi，还有MiniMax H3这类兼顾多模态的新选手。它们大多同时提供两种格式：GGUF和Safetensors。
GGUF是llama.cpp生态推出来的格式，核心优势是内置量化信息、支持分片、可以按层加载到GPU或CPU，非常适合个人电脑和消费级显卡。Safetensors则是PyTorch生态的标准格式，适合在CUDA环境里做推理和微调，灵活性高但一般也要消耗更多显存。
下载渠道方面，除了Ollama自带的模型库，我常用的还有Hugging Face和ModelScope魔搭社区。尤其在模型下载经常超时的地区，魔搭的下载速度会稳很多，很多中文模型的权重和GGUF版本也都在上面同步发布。
这里要提醒一句：模型文件动辄几个GB，来源一定要认准官方账号或知名量化作者。我见过有人在第三方小站下载的GGUF文件运行时报一堆奇怪错误，重新校验hash才发现文件被截断过。下载后最好用文件的SHA256值核对一遍，防止模型文件损坏导致推理结果异常。
1.3 先泼一盆冷水：有些需求真的不适合本地部署
本地部署不是万能的。我自己就吃过"强行本地化"的亏。
如果你需要的是200B级别的顶尖模型，或者视频生成、图片生成这类专业能力，又或者你的应用要对用户提供大规模并发推理，本地DIY的成本和复杂度会高到让你怀疑人生。一台能舒服跑70B量化模型的机器，光显卡投入就够你调用好几年的高端API了；更别提电费、噪音、散热这些"隐形账单"。
所以在动手前，我建议你做一个最朴素的成本计算：本地方案的硬件折损加电费，对比你当前API账单，到底哪个划得来。有些时候"本地部署"只是技术浪漫，而"调用API"才是理性的工程决策。这不是泄气话，是想让你把资源花在真正有价值的地方。
2. 推理引擎与管理框架选型：别让Ollama和Dify在同一赛道里打架
新手最容易犯的一个错误，是把Ollama、llama.cpp、Dify、Open WebUI这些东西当成"同类软件"来对比。实际上它们压根不在一个层级。前者是推理引擎，后者是应用编排框架，它们之间是协作关系，不是替代关系。
2.1 推理引擎层：llama.cpp、vLLM、MLC-LLM各管哪一段
推理引擎是做模型计算的"发动机"，它决定你的模型以多快的速度、多少显存占用跑起来。
llama.cpp是C++实现的推理引擎，对CPU友好，支持GPU加速，核心卖点是轻量、跨平台、直接跑GGUF格式。它最早实现了PC上跑LLM的可行方案，至今仍是单机部署绕不开的选择。它的风格是"命令行为主、可控性强"，适合愿意折腾的人。
vLLM则是为服务化高并发而生的，核心是PagedAttention技术，通过把KV Cache分页管理来提升吞吐。跑同样的模型，vLLM的并发能力通常比llama.cpp高一个量级，但它对GPU显存和驱动的要求也更高，更适合正经跑服务而不是个人尝鲜。
MLC-LLM走的是TVM路线，讲究跨硬件优化，尤其对手机、Mac这类平台的适配做得不错。如果你要在Android应用里集成AI大模型，MLC-LLM是值得研究的引擎（很多人用GGUF在移动端跑模型也是这个思路）。
我的习惯是：单机自用、CPU混合推理用llama.cpp；并发服务、有现成GPU集群用vLLM；特殊平台或嵌入式需求再考虑MLC-LLM。不要指望一个引擎通吃所有场景。
2.2 开发者友好层：Ollama为什么会成为默认选项
Ollama本质上是把llama.cpp的复杂度包了一层"糖衣"。它帮你管理模型下载、版本、运行参数，提供OpenAI兼容的API，还自带一个简单的交互对话命令。对于70%的本地部署用户来说，Ollama就是最好的起点。
它默认端口是11434，模型文件放在统一的目录里，一条ollama pull qwen2.5:7b就能把模型拉下来，ollama run qwen2.5:7b直接进聊天。更重要的是，它的/v1/chat/completions接口和OpenAI一致，意味着你之前写过的所有OpenAI代码，换个base_url就能指向本地。
Ollama不是没有缺点。它在高并发和大上下文的场景下表现一般，模型管理太黑盒，出问题不好定位。我的建议是：个人使用、原型验证、内部小工具，直接上Ollama；一旦要考虑吞吐优化和精细化部署，就跳回llama.cpp或vLLM。
2.3 应用编排层：Dify、AnythingLLM、Open WebUI的定位差异
模型跑起来之后，你还需要一个"上层应用"来干正事。这个层级经常被新手忽略，但恰恰是本地部署能否变成"产品"的关键。
Open WebUI是个漂亮的Web聊天前端，主打ChatGPT式体验，集成了RAG、多模型切换、权限管理，适合做个人助理或小团队共享。AnythingLLM更强调"私有知识库"，傻瓜化程度高，适合不懂技术的朋友。而Dify是更完整的LLMOps平台：它不只是聊天界面，还提供知识库、工作流编排、Agent、API发布等一整套能力，适合真正想搭建"AI应用"而不是"AI聊天框"的人。
我自己的项目里，知识库问答和工作流自动化几乎都是用Dify搭的，因为它能把"模型调用"和"业务逻辑"解耦，后期维护方便很多。Dify本地部署本身也不复杂，用Docker Compose起一套就行，再把模型供应商配置成Ollama，就能直接在界面上做RAG和Agent了。
2.4 一张决策表帮你直接抄答案
我不想让你把时间浪费在无休止的工具对比上，直接给一张我常用的选型决策表。
| 你的场景 | 推荐组合 | 说明 |
|---|---|---|
| 个人笔记本跑对话模型 | Ollama + Open WebUI | 几分钟搞定，默认体验好 |
| 私有知识库问答 | Ollama/llama.cpp + Dify | RAG能力完善，发布API方便 |
| 局域网多人使用 | llama.cpp server或vLLM + Open WebUI | 管理后端的并发和上下文 |
| 生产级OpenAI兼容API | vLLM | 高吞吐、持续批处理能力最强 |
| Android/iOS端集成 | llama.cpp/MLC-LLM + GGUF | 移动端内存带宽有限，模型别选太大 |
| 模型微调与实验 | LLaMA-Factory + Safetensors | 部署只是副业，训练才是重点 |
这张表不是绝对标准，但它能帮你规避"选型瘫痪"。记住：先把一套方案跑通，再谈优化。
3. 硬件门槛与显存数学：跑得动取决于这三个数字
聊本地部署绕不开硬件。很多人以为显存越大越好，实际上决定"能不能跑"的是三个数字：模型权重大小、KV Cache大小、以及推理时的临时开销。这三者加起来，才是你真正需要的显存。
3.1 权重精度与量化：Q4_K_M为什么会成为默认值
模型权重最常见的存储精度是FP16或BF16，一个70亿参数的模型，FP16权重大约是14GB。这对消费级显卡来说有点吃不消，于是量化登场了。
量化就是降低每个权重参数的位数。llama.cpp社区做了一套K-quant方法，产出了Q2_K、Q3_K_S、Q4_K_M、Q5_K_M、Q6_K、Q8_0等一系列等级。命名里的数字大致对应"每个参数平均占用多少bit"，比如Q4_K_M就是每个权重大约4.8bit左右。
为什么Q4_K_M是社区公认的"甜点级别"？因为它把模型体积压到原始FP16的四分之一左右，而质量损失通常在可接受范围内。7B模型量化为Q4_K_M后大约4.4GB，一张8GB显存的卡就能跑；70B模型量化为Q4_K_M后大约40GB，48GB的卡可以单卡跑完。
我自己跑过对比：同一个模型在Q4_K_M和Q8_0下，日常问答的差异很小，但在数学推理这类任务上Q8_0确实更稳。如果你的显存有余量，建议优先升到Q5_K_M或Q6_K；显存吃紧的话，Q4_K_M是最好的妥协点。
3.2 显存估算公式：模型权重 + KV Cache + 推理开销
模型权重只是底数，真正让很多人翻车的是KV Cache。KV Cache是推理过程中缓存注意力计算结果的临时数据，它的大小取决于层数、KV头数、上下文长度和精度，公式大致是：
KV Cache ≈ 2 × 层数 × KV头数 × 头维度 × 上下文长度 × 每个元素字节数
拿7B模型举例，假设28层、4个KV头、头维度128、上下文长度8192、FP16存储，2个字节一个元素，那么2 × 28 × 4 × 128 × 8192 × 2算下来大约是0.47GB。看起来不大对吧？但如果把上下文长度拉到128K，这个数字就膨胀到7.5GB左右——这才是长上下文部署的隐藏成本。
再加上推理过程中的临时激活、CUDA上下文开销，一个7B Q4模型在8K上下文下实际建议8GB显存起步；13B Q4建议16GB；70B Q4建议48GB。这只是"能跑"的门槛，离"跑得舒服"还有距离。
3.3 CPU、Mac统一内存与GPU三种路线的真实体验
没有NVIDIA显卡能玩本地大模型吗？能，但要调整预期。
纯CPU路线用llama.cpp，靠的是AVX2/AVX512指令集和内存带宽。我拿一台普通办公电脑跑7B Q4，生成速度大概每秒两三个token，看代码勉强能忍，做实时对话会很着急。CPU路线更适合跑离线批处理，而不是交互式体验。
Mac路线比较特殊。Apple Silicon把内存和显存统一在一起，大内存Mac能跑很大参数量的模型。比如M系列高配机器跑70B Q4模型，速度可能比很多PC还流畅。但这里有个物理瓶颈：内存带宽。Mac的推理速度基本等于"内存带宽除以模型大小"，7B Q4在M1 Air上大概每秒跑13个token左右，而M系列带宽更高的Pro/Max芯片能到每秒几十个token。所以预算允许的话，跑大模型优先选Max芯片。
GPU路线的天花板最高，但也最费钱。NVIDIA显卡在CUDA生态下兼容性最好，AMD卡能用ROCm但坑多一些。如果你打算长期跟本地大模型较劲，一张24GB显存的卡会是比较舒服的起点；只有12GB的话，老老实实跑7B和14B模型，不要硬怼32B以上的模型。
4. 从零跑通本地大模型：Ollama与llama.cpp两条实操路线
工具和硬件都清楚了，接下来是真正的实操。我给出两条路线：Ollama面向绝大多数人，llama.cpp面向需要精细控制的人。两条路线我都会写完整命令和参数意图，别只复制粘贴，想想每一条在干什么。
4.1 路线A：Ollama快速部署与常用操作
先讲Ollama。安装很简单，从官网下载对应系统安装包，或者用官方安装脚本，Windows/macOS/Linux都有覆盖。装完打开终端验证：
ollama --version然后拉取一个模型。我推荐从Qwen2.5或Llama3.x的7B/8B版本开始：
ollama pull qwen2.5:7b ollama run qwen2.5:7bpull是下载模型，run是进入交互对话。想退出对话，输入/bye即可。ollama list查看本地已有模型，ollama rm删除不用的模型。
如果觉得默认聊天交互不够爽，可以启动服务端并用API调用：
ollama serve默认监听11434端口。此时在另一个终端里请求：
curl http://localhost:11434/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{"model": "qwen2.5:7b", "messages": [{"role": "user", "content": "你好"}]}'这个/v1/chat/completions就是OpenAI兼容端点，意味着你可以在任何支持OpenAI接口的应用里，把base_url改成http://localhost:11434/v1，就能接入本地模型。我经常干的一件事，是把各种开发工具的模型配置指向这个地址，瞬间让整个工具链离线可用。
Ollama的可调参数不多，但有两个值得记。一是OLLAMA_HOST环境变量，可以改监听地址和端口，方便局域网共享；二是OLLAMA_CONTEXT_LENGTH，用于控制默认上下文长度，显存紧张时调小它比换模型更立竿见影。
4.2 路线B：llama.cpp编译部署与精细化控制
当你发现Ollama的默认配置不够用了，就该转llama.cpp。它没有安装包，最靠谱的方式是源码编译。
git clone https://github.com/ggml-org/llama.cpp cd llama.cpp cmake -B build -DCMAKE_BUILD_TYPE=Release -DGGML_CUDA=ON cmake --build build --config Release -jGGML_CUDA=ON表示开启CUDA加速。不用NVIDIA卡就去掉这个选项，llama.cpp会退化为CPU推理。如果你是Apple Silicon，加上-DGGML_METAL=ON。
编译完之后，去下载对应的GGUF模型文件，然后命令行推理的格式是：
./build/bin/llama-cli \ -m /path/to/model.gguf \ -p "用一段话解释什么是量子纠缠" \ -n 512 \ --temp 0.7 \ --ctx-size 8192 \ --n-gpu-layers 99参数说明：-m指定模型路径，-p是提示词，-n是生成的最大token数，--temp是温度，--ctx-size是上下文窗口，--n-gpu-layers是把多少层放到GPU上。这里写99是"全部放GPU"的意思；如果显存不够，就往小调，让模型部分跑在CPU上。
如果嫌命令行交互不方便，llama.cpp还带一个开源服务器可执行文件：
./build/bin/llama-server \ -m /path/to/model.gguf \ --host 0.0.0.0 \ --port 8080 \ --ctx-size 8192 \ --n-gpu-layers 99启动后访问http://localhost:8080能看到一个简单的Web界面，同时它也提供了/v1/chat/completions接口，跟Ollama一样可以接任何OpenAI兼容客户端。
4.3 暴露OpenAI兼容API：让任何应用都能接上本地模型
这一步是整个本地部署里最"值钱"的环节。你把本地模型包装成OpenAI兼容API之后，之前所有为OpenAI写的代码、配好的工具、调试过的框架，全部可以无缝切换。拿Python举一个最简单的流式请求例子：
import json import requests url = "http://localhost:8080/v1/chat/completions" payload = { "model": "your-model-name", "messages": [{"role": "user", "content": "讲个冷笑话"}], "stream": True } # 注意这里用 stream=True，服务端会按 SSE 格式一段段返回 with requests.post(url, json=payload, stream=True) as resp: for line in resp.iter_lines(): if line: text = line.decode("utf-8") if text.startswith("data: "): data = text[6:] if data == "[DONE]": break obj = json.loads(data) delta = obj["choices"][0]["delta"].get("content", "") print(delta, end="", flush=True)为什么stream=True这么重要？因为大模型生成速度天然是"先顿后快"，如果不用流式，用户要等全部生成完才能看到第一个字，体验非常差。用流式输出配合前端逐字渲染，才有"AI正在打字"的效果。前端接流式时，通常会配合AbortController在用户点击"停止生成"时中断请求，不要让无意义的token继续消耗资源。
4.4 用Dify搭建知识库与工作流：把模型变成产品
模型API跑通之后，很多人会困惑：然后呢？这就是Dify登场的时机。Dify是一个开源的LLMOps平台，支持本地部署，核心能力包括知识库RAG、工作流编排、Agent和API发布。
Dify本地部署最省事的方式是用Docker Compose。拉下官方仓库后：
cd dify/docker cp .env.example .env docker compose up -d启动后在管理后台的"设置-模型供应商"里添加Ollama，填入http://host.docker.internal:11434这类地址（容器内访问宿主机要用host.docker.internal），就能在Dify里调用本地模型了。
然后你可以创建知识库：上传文档，Dify会做分块和向量化，问答时自动检索相关内容塞进上下文。我再配一个工作流：用户输入问题后，先走知识库检索，再用模型结合检索结果作答，最后输出引用来源。整个过程在Dify的拖拽界面上就能完成，不需要写代码。
我实际使用下来，Dify的"分块策略"是个值得研究的地方。分块太大，检索精度下降；分块太小，上下文碎片化。按我的经验，中文文档分块在500到800个字符之间比较平衡，重叠区设80到100个字符，召回效果通常最好。
5. 调优与排错：推理提速、上下文管理与高频故障排查
工具链跑通只能算"能用了"，离"好用"还有距离。下面几类问题是我在实操中遇到最多、也最有规律可循的，一个个说。
5.1 推理速度提不上去？先检查这几处
本地跑模型最常见的问题是"太慢"。排查顺序应该是从硬到软：先看哪一层的计算在拖后腿。
第一，看n_gpu_layers。如果GPU显存不够、层数只offload了一部分，那部分计算在CPU上做，速度会掉好几倍。用llama.cpp的日志确认到底有多少层在GPU上，理想情况是能全部放进去，实在不行也要保证embedding层和绝大多数attention层在GPU。
第二，看上下文长度。ctx_size设得越大，KV Cache越大，GPU占用越高，甚至会吃掉本该属于权重计算的内存带宽。如果你的任务不需要长上下文，把它压到4096或8192，提速效果立竿见影。
第三，看批处理大小。llama.cpp有个--batch-size参数，影响prompt处理（prefill）阶段的速度。一次把整段prompt喂进去比逐字喂要快很多，但也会占更多显存，需要平衡。
第四，注意CPU推理时的线程数。纯CPU方案默认线程数可能少于物理核心，手动指定为物理核心数通常能明显提升速度。
最后记得看日志里的两个数值：prompt eval和eval time。前者是"处理输入"的速度，后者是"生成输出"的速度。很多"慢"其实是prompt处理慢，不是生成慢，排查方向完全不同。
5.2 上下文越长越迷糊？KV Cache和ctx的取舍
有一类问题特别迷惑人：模型刚开聊还很聪明，聊了十几轮之后开始"失忆"或者答非所问。很多人以为是模型笨，其实是你的上下文窗口配错了。
模型能记住的上限由ctx_size决定，但上下文越长，KV Cache占用越大，还可能触发长度外推导致的精度下降。我见过的典型错误是：显存只有8GB，非要把ctx_size拉到32K，结果模型实际能用的显存被KV Cache挤占，生成质量反而不如8K时。
另外，前端应用也要注意对话历史管理。不要每次请求都把完整聊天记录塞进去，应该做"滑动窗口"：只保留最近几轮有意义的对话和系统提示词。这跟人的记忆机制类似，重要的信息留，废话就丢。
如果你确实需要长上下文，优先选原生长上下文模型（比如Qwen系列对长文的支持就不错），并把KV Cache精度适当降低，显存压力会小很多。
5.3 高频问题排查清单：端口、下载、显存、容器网络
本地部署的故障其实就那么几类，我整理了一份排查顺序，按着走能解决大部分问题。
| 现象 | 常见原因 | 处理办法 |
|---|---|---|
| 端口被占用 | Ollama的11434或llama.cpp的8080被其他进程占用 | netstat -ano | findstr 11434查PID，杀掉或换端口 |
| 模型下载超时 | 网络链路不稳 | 换魔搭等镜像源，或者用断点续传工具下载后本地导入 |
| CUDA out of memory | 显存被权重+KV Cache+激活占满 | 减小ctx_size，换更低量化，调低n_gpu_layers |
| API请求报错404 | base_url写错或模型名不匹配 | 检查/v1/models返回的模型名，确认拼写 |
| Docker里连不上宿主机 | 容器网络隔离 | 用host.docker.internal替代localhost |
| 推理速度骤降 | GPU没有被正确使用 | 确认驱动、CUDA版本和编译选项 |
| 模型输出乱码 | 文件损坏或量化版本有BUG | 重新下载并核验hash，换官方GGUF |
这里我想多说一句模型名问题。Ollama和llama.cpp的模型名是启动时指定的，不是自动识别的。接入API时填错模型名是极其常见的错误，而报错信息往往很隐晦。遇到404或model not found，第一反应应该是去/v1/models看一眼实际可用的模型名，而不是瞎改代码。
6. 从"能跑"到"好用"：微调、多模态与本地智能体的进阶方向
把模型跑起来只是起点。真正让它变成生产力工具，通常还要走一两步进阶：要么把模型微调成"懂你领域"的形态，要么让它具备多模态和Agent能力。
6.1 什么时候值得微调，以及QLoRA的最小流程
微调不是万能药。我的判断标准是：提示词工程解决不了的、RAG检索不到又要频繁回答的、输出格式和风格要求极其固定的——这些才值得微调。如果只是偶尔问几个专业问题，先用RAG，别急着训练。
真要微调，目前性价比最高的方案是QLoRA。它通过4bit量化基座模型加低秩适配器，大幅降低显存需求。7B模型的QLoRA微调，在12GB到16GB显存上就能跑。我用得最多的工具是LLaMA-Factory，一个开箱即用的微调框架，支持多种数据集格式。
最小流程是：准备数据（比如alpaca格式的instruction/input/output三字段JSON）、配置LoRA参数、训练、合并导出。我拿一个行业术语咨询场景举例，样本量2000条高质量问答，7B模型就能看到肉眼可见的术语准确率提升，而且不会破坏通用能力。数据质量比数据量重要得多，这一点无论说多少次都不过分。
微调后如果想回到Ollama或llama.cpp部署，需要把LoRA权重合并进原模型并导出为GGUF格式。LLaMA-Factory支持直接导出，导出时再顺手做一次量化，部署端不需要额外改造。
6.2 多模态模型和本地Agent的落地思路
2026年的本地部署已经不只是文本模型了。多模态本地模型（比如Qwen2-VL这类视觉语言模型）可以在本地做图片理解、截图文档分析，部署方式和文本模型大同小异，只是输入预处理会多一道工序。
我拿"本地看图分析"举例：先用llama.cpp跑一个视觉模型，然后写一个小服务接收图片，走API传给模型，模型输出对图片内容的描述或答案。这个能力配合知识库，能做出很多实用工具——比如把截图丢给它，自动提取表格信息归档。
Agent方向是另一个明显趋势。本地模型配合Function Calling或MCP协议，可以变成一个能调用工具、搜索知识库、操作本地脚本的智能体。Dify里已经内置了不少Agent节点，你只需要定义好工具，再把模型设置成支持函数调用，就能做出一个半自动的"本地AI助理"。
不过说实话，本地小模型的Agent能力目前还是弱于云端旗舰模型的。复杂多步推理容易断线，需要你在提示词和流程设计上多花心思。
6.3 我的最终建议：先解决80%的需求，再考虑炫技
折腾了两年多本地部署，我自己最大的感受是：技术栈永远在变，但工程方法论是相通的。不管哪天出了新模型、新框架，"需求判断—工具分层—硬件核算—流程跑通—调优排错—进阶补强"这条链路始终适用。
最后再分享一个我个人的习惯：每部署一套新环境，我都会把它完整记录成一份文档，包括模型来源、量化等级、启动参数、遇到过的问题。因为大模型生态更新太快，三个月后你可能会换模型、换工具，如果没有记录，一切都得从头开始踩坑。文档可能很朴素，但它是你在这个快速变化领域里最可靠的沉淀。
本地部署这个事，没有一步到位的完美方案。从一台普通电脑跑起，把一个7B模型调顺，再慢慢往上升级，是最好的路径。不要一开始就追求最大最强的模型——把一套流程彻底跑通，比拥有一堆没调好的大模型有价值得多。
