企业官网建设流程全解析

先说个反直觉的结论：本地部署开源大模型，真正卡人的不是“显卡贵不贵”，而是“显存够不够、工具没选对”。

我从去年开始系统性折腾本地模型，从最初拿一台只有16GB内存的MacBook Air硬跑Llama 2，到后来在台式机上用4060 Ti 16GB跑Qwen2.5和DeepSeek-R1，再到帮朋友在Jetson Orin Nano上落地边缘推理，一路踩了不少坑。现在的局面是：主流开源模型的部署已经非常成熟，Ollama、llama.cpp、LM Studio这些工具已经把门槛压得很低，普通人完全可以在自己的电脑上把Qwen、Llama、DeepSeek全部跑起来。

这篇文章是我把三个模型家族的本地部署完整跑过一遍后的工程记录，覆盖Qwen、Llama、DeepSeek，也覆盖Ollama、llama.cpp、LM Studio、LlamaFactory、Dify、VSCode接入等常用工具链。无论你是想自己玩玩、做团队离线知识库，还是给产品接一个可控的模型底座，都可以照着这篇来。我尽量按“先算账，再动手，最后排雷”的顺序写，每一步为什么这么做、常见坑在哪里，都会说清楚。

1. 硬件账先算清：本地部署的显存模型与量化选择

1.1 显存与模型大小的换算关系

很多人上来就问“我的电脑能不能跑”，其实核心就一句话：模型能不能跑起来，主要看显存/统一内存够不够，其次才是算力快不快。

这里给一个粗算公式：模型权重如果以FP16精度加载，1B参数大约需要2GB显存。也就是说7B模型FP16需要约14GB显存，14B模型要28GB。但实际很少有人会用FP16跑本地模型，因为显存太紧张，大家都会用量化压缩权重。

在4-bit量化下，7B/8B模型的权重只有4~5GB左右，再加上KV Cache、CUDA context这些运行时开销，显存需求大概是：

这个表是估算值，不同量化方案会有点差异，但方向是对的：显存大小决定了你能跑哪一档的模型，而不是显卡的“型号名”。一块4060 Ti 16GB的实际部署体验，很可能比一块24GB显存的老卡更从容，因为16GB能跑的模型范围已经覆盖了绝大多数本地场景。

1.2 四种典型硬件方案

我身边实际有人跑本地模型，基本就是下面四种路子：

第一种：NVIDIA显卡的台式机/服务器。这是最省心的方案，CUDA生态最完整，Ollama、llama.cpp、LlamaFactory全部原生支持。预算不高的选3060 12GB或4060 Ti 16GB，预算够的选3090/4090 24GB，二手3090性价比目前还不错。如果团队已经有服务器，基本就是往上面装环境就行。

第二种：Apple Silicon的Mac。M系列芯片的统一内存既能当内存又能当显存用，Metal加速在Ollama和llama.cpp里都支持得不错。16GB内存的M1/M2能跑7B/8B模型，32GB内存可以比较舒服地跑14B，64GB内存可以去挑战32B模型。实测M1 16GB跑Qwen2.5 7B的Q4量化，速度大概在20~30 token/s，日常写代码、查资料完全够用。

第三种：纯CPU服务器。很多人公司里有一堆退役的Xeon服务器，没有好显卡，但内存很大。用CPU跑完全可行，内存16GB以上就能跑7B模型，32GB可以跑14B。代价是速度慢，大概每秒1~5个token，但如果你只是做离线批量处理、文本分类、摘要生成，慢一点完全无所谓，部署成本几乎为零。

第四种：边缘设备，比如Jetson Orin Nano。功耗只有几瓦到十几瓦，适合做嵌入式、机器人、车载这类场景。后面我会专门用一章讲这个，它跑小参数量模型的体验比大多数人的预期好。

1.3 量化是什么：GGUF、GPTQ、AWQ

新手听不懂“量化”很正常，我用一句话解释：模型训练出来时权重是32位或16位浮点数，占空间大；量化把这些浮点数压缩成4位或8位整数，体积小很多，跑起来显存需求也低很多。代价是精度有所损失，但现代量化方案做得很好，Q4量化和FP16的差距在大多数任务里几乎感知不到。

现在本地部署最常见的三种量化格式：

• GGUF：来自llama.cpp生态，是目前兼容性最好的格式。Ollama、LM Studio、llama.cpp、Dify都能直接吃GGUF。它的特点是CPU/GPU混合推理很灵活，显存不够的部分会落到内存里照样跑。
• GPTQ：老牌GPU专用量化格式，主要用在显存完全够的场景，用ExLlamaV2或AutoGPTQ推理，显存效率高，速度也不错。
• AWQ：近两年很热门的激活感知量化方案，质量和GPTQ相当，某些场景更稳。同样需要GPU推理框架支持。

我的建议很简单：新手无脑选GGUF格式的Q4_K_M量化版，兼容性最好，工具链最完善，出问题最容易找到解决方案。等跑通了之后再尝试GPTQ/AWQ追求更高速度，那时候你已经知道自己在干什么了。

2. Ollama部署三条主流模型：桌面到服务器一把梭

2.1 安装与基础命令

Ollama是我现在最推荐的入门工具，它把模型下载、运行、OpenAI兼容API全给你包好了，命令简单到不像是在跑大模型。

Windows直接下载Ollama安装包点两下就完事。macOS可以用Homebrew：

brew install ollama

Linux服务器一条命令：

curl -fsSL https://ollama.com/install.sh | sh

装完先记住这几个命令，日常90%的操作都在里面：

ollama pull <模型名> # 下载模型 ollama list # 查看本地已有模型 ollama run <模型名> # 进入交互式对话 ollama serve # 启动后台服务（默认常驻） ollama ps # 查看当前加载的模型 ollama stop <模型名> # 释放显存

2.2 拉取并运行Qwen、Llama、DeepSeek

Ollama的模型仓库地址是ollama.com，想找热门模型直接去上面搜就行。三个模型家族的拉取命令我实测都是这样：

# Qwen系列 ollama pull qwen2.5:7b-instruct ollama pull qwen2.5-coder:7b # Llama系列 ollama pull llama3.1:8b # DeepSeek系列（注意是官方蒸馏版） ollama pull deepseek-r1:7b ollama pull deepseek-r1:14b

这里必须说清楚一件事：DeepSeek官方那个671B超大模型，本地根本跑不动，那需要多张A100/H100级别的企业级硬件。Ollama仓库里的deepseek-r1系列，是官方用DeepSeek-R1的推理能力蒸馏到Qwen和Llama小模型上得到的版本，7B、14B、32B、70B都有。日常本地部署说的“DeepSeek可以跑”，指的都是这些蒸馏版小模型，体验已经相当不错，尤其在数学和逻辑推理类任务上。

拉下来之后直接运行：

ollama run qwen2.5:7b-instruct

输入问题就能对话。想退出交互模式，输入/bye即可。场景不同选择也不同：写代码用qwen2.5-coder，通用助手用qwen2.5:7b-instruct或llama3.1:8b，数学推理用deepseek-r1:14b效果明显更好。

2.3 Modelfile自定义：上下文、温度与系统提示词

很多人不知道Ollama可以通过Modelfile自定义模型行为。比如你觉得默认上下文太短、回答太“正经”，可以用Modelfile改：

FROM qwen2.5:7b-instruct PARAMETER temperature 0.7 PARAMETER num_ctx 8192 PARAMETER top_p 0.9 SYSTEM "你是一个严谨的中文技术助手，回答尽量简洁，不要废话。"

保存为Modelfile，然后：

ollama create my-qwen -f Modelfile ollama run my-qwen

num_ctx是上下文窗口长度，默认通常只有4096，调大到8192或16384能“记住”更多历史对话，但显存占用也会涨。temperature是随机性，0.7是比较均衡的默认值，逻辑推理类任务我习惯调到0.3以下，减少胡编乱造。

2.4 OpenAI兼容接口：让所有程序都接上本地模型

Ollama最大的杀手锏是它内置了一个兼容OpenAI接口的HTTP服务，默认跑在11434端口。这意味着你不需要任何额外代码，所有能调OpenAI API的程序都能直接改一行地址换成本地模型。

curl http://localhost:11434/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "qwen2.5:7b-instruct", "messages": [ {"role": "user", "content": "你好，简单介绍一下自己"} ] }'

返回的JSON结构和OpenAI一模一样。后面第6章要说的Dify、VSCode插件、Codex CLI，本质上都是通过这个接口把本地模型接进业务系统。

另一个实用技巧：如果想把模型目录放到独立硬盘，避免C盘爆掉，设置环境变量OLLAMA_MODELS指定目录；如果想让局域网内其他机器访问，设置OLLAMA_HOST=0.0.0.0。这些都可以写在系统环境变量里，重启Ollama服务生效。

3. 不想用Ollama的替代路径：llama.cpp与LM Studio

3.1 llama.cpp的设计定位

Ollama固然方便，但如果你想更精细地控制推理过程，或者要在没有官方支持的平台上运行，那就绕不开llama.cpp。这是一个用C/C++实现的大模型推理引擎，最早由ggerganov发起，GGUF格式就是它的杰作。Ollama早期本身就是基于llama.cpp的思路封装了一层，后来才逐渐有了自己的runtime，但底层逻辑一脉相承。

llama.cpp最大的优势是轻量、无依赖、极致兼容。它不需要Python环境，不依赖NVIDIA独占的框架，CPU能跑，显卡能加速，Windows、Linux、macOS、甚至Jetson都能编译运行。很多老机器跑不了官方模型，就是靠llama.cpp救回来的。

3.2 编译、运行与关键参数

如果你不需要编译，直接去GitHub Release页下载对应平台的预编译包就行。想在Linux上启用CUDA加速，需要自己编一次，但过程不难：

git clone https://github.com/ggerganov/llama.cpp cd llama.cpp cmake -B build -DGGML_CUDA=ON cmake --build build --config Release -j

编译完核心的可执行文件有两个：llama-cli用于命令行对话，llama-server用于启动一个带OpenAI兼容API的HTTP服务。实际部署时我基本只用后者：

llama-server -m ~/models/qwen2.5-7b-instruct-q4_k_m.gguf \ -ngl 99 \ -c 8192 \ --port 8080

解释一下几个关键参数：

• -m：模型文件路径，用llama.cpp必须自己去下载GGUF文件，一般去HuggingFace搜模型名加GGUF关键字。
• -ngl：把多少层放到GPU上跑，99就是“尽量全放”，显存不够就降到20或10，剩下的层会落到CPU，速度慢一些但能跑。
• -c：上下文窗口长度。这个值直接影响显存占用，纯CPU环境甚至影响内存占用，不要盲目拉满。
• --fa：开启Flash Attention，能明显降低长上下文时的显存需求，新版默认很多已经开了。
• --cache-type-k/q：对KV Cache做量化，实测能省不少显存，质量损失很小。

启动后访问http://localhost:8080/v1/chat/completions就是OpenAI兼容接口，用法和Ollama几乎一样。

3.3 LM Studio：可视化调参

如果你不想碰命令行，但又想像用桌面软件一样管理模型、对比不同模型的效果，就用LM Studio。它本质上是一个把llama.cpp包起来的图形化工具，界面友好得多。

它的使用逻辑是：在软件里搜模型、下载GGUF文件，然后在“加载模型”界面拖一个滑块选择GPU offload的层数，设置上下文窗口，点加载就能对话。左侧是普通聊天界面，右侧是推理参数面板，切换模型对比效果非常方便。

LM Studio也自带一个local API server，启动后同样暴露OpenAI兼容接口。我做模型评测的时候特别喜欢拿它来快速切换模型，一台机器上装好几个模型，谁好谁坏一目了然。

3.4 什么时候该用哪个工具

很多读者会问：这几个工具到底选哪个？我的判断标准很简单：

• Ollama：服务化部署、接入业务系统、跨机器复现环境，优先用Ollama。它的模型管理最方便，团队里一台机器配好后其他人直接连。
• llama.cpp：要精细调参、跑老机器/特殊硬件、自己编译研究底层，用llama.cpp。它是“万能底牌”。
• LM Studio：纯本地探索、多模型对比、完全不想碰命令行，用LM Studio。它是“实验台”。

其实这三者不是互斥的，很多人电脑上三个都装，各干各的活。

4. Jetson Orin Nano边缘部署：低功耗跑Qwen的实测方案

4.1 为什么要折腾边缘设备

桌面显卡跑大模型自然爽，但功耗轻松两三百瓦，体积又大，很多场景根本用不上。Jetson Orin Nano这类开发板整板功耗才7~15W，却能提供接近入门独立显卡的算力，特别适合做边缘盒子、机器人、智能摄像头、车载终端这类对功耗和体积敏感的场景。

还有一个很多人忽略的优势：数据不出设备。医疗、金融、隐私敏感的场景不需要把数据传到云端，本地模型推理天然满足合规要求。我在第6章讲的Dify离线知识库，如果跑在Jetson上，那就是一套完全物理隔离的AI服务。

4.2 环境准备与功耗模式

Jetson Orin Nano Developer Kit有两种配置，8GB和16GB版本。8GB版跑7B模型的Q4量化比较紧张，16GB版会从容很多。第一件事是刷JetPack系统，如果只是做推理，JetPack 5.1.2以上都可以，其中自带CUDA、cuDNN、TensorRT的运行时。

刷完系统后，先把功耗模式调到最大性能：

sudo nvpmodel -m 0

nvpmodel -m 0是15W最大性能模式，-m 1是10W省电模式。实测性能释放对推理速度影响很大，能接受散热噪音就长期用-m 0。另外Jetson默认风扇策略偏保守，如果长时间满载推理，建议手动开风扇防止降频：

sudo sh -c 'echo 255 > /sys/devices/pwm-fan/target_pwm'

4.3 在Jetson上部署Qwen

Jetson上部署模型有两条路。第一条最省事：Ollama官方已经支持Jetson平台，直接一条命令：

curl -fsSL https://ollama.com/install.sh | sh ollama pull qwen2.5:7b-instruct ollama run qwen2.5:7b-instruct

Ollama在Jetson上会自动检测CUDA环境并使用GPU加速，这个体验比我自己手动编译llama.cpp顺滑太多。如果你想更细粒度控制，第二条路就是llama.cpp手动编译，cmake -DGGML_CUDA=ON即可，JetPack自带的CUDA工具链直接能编过。

4.4 实测性能与优化空间

我在Orin Nano 8GB版上跑qwen2.5:7b-instruct的Q4量化，实测生成速度大概是5~9 token/s。作为对比，普通聊天场景人类阅读速度大约是每秒4~6个字，所以这个速度已经可以勉强做实时对话，完全能胜任文本分类、摘要、信息抽取这类异步任务。

如果想在8GB版上跑得更舒服，有几个优化手段：

• 禁用桌面环境，切到纯headless模式，省出1~2GB内存给模型。
• 开启zram或swap，模型如果稍微超一点内存，不至于直接崩溃。
• 使用ollama run前先执行ollama stop释放之前加载的模型，避免多个模型同时占显存。
• 14B模型在8GB板上不建议实时跑，量化后勉强，但速度会掉到3~5 token/s，体验不好。16GB版才是跑14B的最低门槛。

Jetson上的坑不少，最典型的是刷完系统后默认运行在低功耗模式，很多人跑模型慢到怀疑人生，结果只是nvpmodel没调对。

5. LoRA微调实战：用LlamaFactory让Qwen学会你的私有数据

5.1 为什么微调而不是只改提示词

等模型跑起来、API能通，下一步大多数人就会遇到同一个问题：通用模型回答得不错，但不懂我们公司/领域的专业知识。这时候有两条路：提示词工程和微调。

提示词工程不是万能的，它的上限是“引导模型已有的知识”。如果模型根本没接触过你们行业专有名词、内部文档、特定对话风格，你写再长的提示词它也只能硬编。微调则是直接把新知识“写进”模型参数里。

全量微调7B模型需要大量显存，普通人根本玩不起。LoRA（低秩适配）则是冻结原始模型参数，只训练一个小规模的增量矩阵，显存需求大幅下降。单张4090甚至3090就能微调7B模型，这也是LoRA能火起来的核心原因。

5.2 LoRA的原理一句话

LoRA的思想可以这样理解：原始模型权重矩阵W是“定死的”，LoRA给它并联了两条小路B和A，训练时只更新这两个小矩阵，最终效果相当于在W旁边加了“一个低秩的微调量”。一方面训练参数量少，显存占用低；另一方面可以随时换不同的LoRA适配不同任务，非常灵活。

5.3 安装LlamaFactory与数据准备

LlamaFactory是目前我测试下来对新手最友好的微调工具，它把Qwen、Llama、DeepSeek这些主流模型全封装进了同一个Web界面，支持LoRA和QLoRA。安装很简单：

git clone https://github.com/hiyouga/LLaMA-Factory.git cd LLaMA-Factory pip install -e .[torch,metrics] CUDA_VISIBLE_DEVICES=0 python src/train_web.py

启动后浏览器进入http://localhost:7860。训练前要把数据整理成Alpaca格式的JSON文件，常见样式如下：

[ { "instruction": "介绍下什么是光伏逆变器", "input": "", "output": "光伏逆变器是太阳能光伏发电系统中负责将直流电转换为交流电的设备……" }, { "instruction": "根据下面内容提取客户投诉的关键词", "input": "客户反馈家用逆变器噪音大，售后响应慢", "output": "['噪音大', '售后响应慢']" } ]

把JSON文件放到LlamaFactory的data目录下，然后在WebUI的数据集下拉框里找到它。注意instruction是问题指令，input是补充上下文（可为空），output是期望回答，三条字段缺一不可。

5.4 关键训练参数说明

在LlamaFactory的WebUI里，模型名称选择qwen2.5-7b-instruct，微调方法选lora，然后重点设置这几个参数：

训练时长方面，单张4060 Ti 16GB微调7B模型，1000条数据大概20~40分钟就能跑完。训练过程中盯着loss看，loss降到0.5~1.0之间就可以停了，不要一味追求loss趋近于0，否则模型会“背题”而不是“学会”，对话反而会变得机械。

5.5 导出合并回灌Ollama

训练完的LoRA权重需要“合并”回基础模型才能直接部署。在LlamaFactory的Export选项卡里，选择导出目录，它会自动把基础模型权重和LoRA增量合并成一个完整的模型目录。然后把它转成GGUF格式：

python convert_hf_to_gguf.py ./merged_model \ --outfile merged-q4_k_m.gguf \ --outtype q4_k_m

转出来的GGUF文件就可以用小模型部署工具直接加载了。用Ollama把它注册成自定义模型：

FROM ./merged-q4_k_m.gguf

ollama create my-finetuned-model -f Modelfile ollama run my-finetuned-model

个人经验是：微调的数据质量比数据量重要得多。几十条高质量、格式统一的示例，效果往往好过几千条语无伦次的垃圾数据。每次微调前先花半天清洗数据，这个时间永远不会白费。

6. 模型部署完只是开始：Dify、VSCode与Codex的接入实战

6.1 Dify本地化搭建

很多人把模型跑起来就停手了，其实模型只是“发动机”，要变成能用的应用，还需要一个编排层。Dify是目前开源社区最主流的LLM应用平台，它可以让你不写代码就搭出知识库问答、Agent工作流、聊天机器人。

Dify官方提供了Docker Compose一键部署方式：

git clone https://github.com/langgenius/dify.git cd dify/docker cp .env.example .env docker compose up -d

首次启动要等一会儿，浏览器访问http://localhost完成初始化设置。整个流程我没遇到过大坑，唯一要强调的是一开始就把.env里的SECRET_KEY改成随机值，不然后续升级容易出问题。

6.2 在Dify中接入本地Ollama与DeepSeek

Dify部署完默认没有任何模型，需要在“设置-模型供应商”里添加。选Ollama，填API地址，有一个关键坑：Dify是在Docker容器里跑的，容器内不能直接访问宿主机，所以不能写localhost:11434，要写http://host.docker.internal:11434/v1，或者直接用宿主机内网IP。

如果你要用DeepSeek官方在线API，在模型供应商里搜索DeepSeek，填入API密钥，模型名称填deepseek-chat或deepseek-reasoner即可。前者适合日常对话，后者适合推理分析。把两条链路都配好，等于你同时拥有了“免费离线底座”和“高能力在线兜底”。

在Dify里创建应用时，可以选择知识库检索模式，上传文档，配置Embedding模型。这里分享一个提升RAG效果的小技巧：如果文档是PDF，不要直接切块喂进去，先用MinerU这类开源文档解析工具把版面、表格、图片转成干净文本再进知识库。实测解析后的检索命中率比直接切PDF高很多。

6.3 把模型接进VSCode：Continue插件配置

每天写代码的人，最实用的场景是把本地模型接进VSCode当AI编程助手。Continue是目前最流行的开源插件，配置方式很直观：装好插件后，在它的配置文件config.json里添加一个模型：

{ "models": [ { "title": "Qwen Coder Local", "provider": "openai", "model": "qwen2.5-coder:7b", "apiBase": "http://localhost:11434/v1", "apiKey": "ollama" } ] }

保存后回到对话面板选这个模型。如果你接的是DeepSeek-R1系列，apiBase还是Ollama的http://localhost:11434/v1，只是model改成deepseek-r1:14b。代码补全和代码解释用qwen2.5-coder:7b体验很好，代码逻辑分析用deepseek-r1:14b更有深度。

6.4 Codex CLI等Agent工具接入本地模型

最近很火的OpenAI Codex CLI也支持自定义模型供应商。它的配置文件是~/.codex/config.toml，大致这样配：

model = "qwen2.5-coder:7b" model_provider = "ollama" [model_providers.ollama] name = "Ollama" base_url = "http://localhost:11434/v1" env_key = "OLLAMA_API_KEY"

不过我实测下来，本地7B级别的模型跑Agent类任务比较吃力，因为Agent需要长上下文理解和工具调用规划，7B模型很容易在中间步骤“犯迷糊”。本地模型跑Codex至少建议32B以上，或者只用它做代码补全、简单重构、代码解释这类轻任务。真正复杂的多文件重构，还是把云端大模型作为补充才靠谱。

这个思路可以扩展到其他Agent工具：只要工具支持OpenAI兼容接口，理论上都可以接本地模型。Dify也支持建Agent应用，把Ollama模型配置好，就能在它的可视化编排里做工具调用。

7. 部署后必踩的坑：五个真实问题与完整排查链路

模型部署完，问题才刚刚开始。以下五个坑是我和身边朋友反复踩过、排查过的典型问题，每个都按“现象-排查-解决”的思路来讲。

7.1 显存溢出：CUDA out of memory

现象：加载模型或对话突然提示CUDA out of memory，进程崩溃。

排查：先用nvidia-smi看显存占用，确认是不是模型权重本身已经超了显存，还是上下文窗口拉得太大。很多人改了num_ctx到65536，显存瞬间爆掉。

解决：按优先级处理。第一步换更小量化，比如从Q8换到Q4_K_M；第二步调低上下文长度，8192对大多数任务足够；第三步用llama.cpp时降低-ngl层数，让部分层跑CPU；第四步检查是否同时加载了多个模型，用ollama ps确认并ollama stop清理。

7.2 TLS证书报错：self_signed_cert_in_chain

现象：用Docker拉镜像、或某个客户端程序访问内网API时，报self_signed_cert_in_chain。

排查：这个报错常见于公司内网使用了自签名证书的Docker Registry或HTTPS网关。它不是模型的问题，而是客户端不信任服务器证书链。用curl -v看看服务端下发的是真实证书还是自签证书，基本就能定位。

解决：把自签名CA证书加到系统信任库，Linux上是放到/usr/local/share/ca-certificates/后执行update-ca-certificates。如果是Docker Registry，可以在/etc/docker/daemon.json里配置insecure-registries，但仅建议内网测试环境使用。如果是Python客户端报错，设置环境变量REQUESTS_CA_BUNDLE指向CA证书文件；Node.js环境则用NODE_EXTRA_CA_CERTS。

7.3 下载模型没速度：Ollama pull卡住

现象：ollama pull卡在下载进度，半天不动。

排查：国内访问Ollama/HuggingFace等海外源不稳定是主因。可以先确认网络能不能打开源站，再考虑换镜像。

解决：Ollama模型目录可以手动从别人那里拷贝，把整个模型目录的blobs文件拷到目标机器再执行ollama list就能识别。HuggingFace下载GGUF时，设置HF_ENDPOINT=https://hf-mirror.com再继续下载，速度稳定很多。这个办法基本能覆盖大多数下载场景。如果还不行，用LM Studio下载也算一条路，但它也要访问网络，本质一样。

7.4 输出质量差：胡编乱造和车轱辘话

现象：模型回答看起来流畅，但事实错误明显，或者一句话反复说，越说越远。

排查：先看量化等级。你要是下了一个Q2_K甚至Q3_K的模型，质量差是正常的，这种量化级别适合显存极度紧张的环境，不适合正经用。再看推理参数，temperature调到0.8以上在长回答里很容易“放飞自我”。

解决：换Q4_K_M量化版是性价比最高的升级。对话场景temperature设0.6~0.7，推理任务设0.2~0.3。上下文窗口不要盲目调到特别大，超过模型训练时的能力范围，注意力会分散，回答质量反而下降。系统提示词写清楚格式约束，比如“每步推理自成一段，最后给结论”，输出质量提升非常明显。

7.5 老系统和老硬件：Windows 7与老显卡

现象：Windows 7上怎么都跑不起来。

排查：现代CUDA版本早就放弃Win7了，Ollama/LM Studio基本不提供Win7支持，硬要跑只能找老版本的llama.cpp CPU构建。

解决：Win7真不建议折腾，系统太老，驱动和运行时生态断代太严重。如果机器没有NVIDIA新卡，优先装一个Ubuntu LTS跑llama.cpp CPU模式，或者干脆用一台新机器。老显卡用户如果只有核显，可以考虑直接用CPU推理，7B模型慢是慢，但能用。千万别在旧系统上浪费时间，我见过太多人折腾了三天最后换了系统十分钟跑通。

结尾

说了这么多，最后聊点实在的。

本地部署这件事，这两年的最大变化是“部署成本”已经从技术壁垒变成了信息壁垒。很多人迟迟不动手，不是因为跑不起来，而是被各种帖子吓到，以为必须有几万块买卡。实际上，一台12GB以上显卡的游戏本，或者一台32GB内存的Mac，就已经是合格的本地模型运行环境了。我个人建议的路径是：先用Ollama把qwen2.5:7b-instruct跑通，体验一下对话、看一下速度；然后拉一个deepseek-r1:14b做推理对比；等熟悉了再谈微调、再谈Dify应用编排，一步一个台阶，不要一上来就全都要。

根据我自己的经验，真正卡住大多数人的反而是“模型跑起来之后怎么办”——所以我才把VSCode接入、Dify编排这几个应用场景单独拿一章出来写。也建议所有做过本地部署的朋友，把自己的Modelfile、训练参数、踩坑记录整理成文档收起来。这类事情记一次，后续不管是重装机器还是帮同事搭环境，都省很多事。

最后分享一个小技巧：很多你以为是“模型变笨了”的问题，其实是上下文开太大、温度调太高，把这两项参数调正常，一半以上的质量吐槽都消失了。调参永远比换模型便宜。