本地大模型部署全流程：从 Ollama 到 vLLM 实战指南

“本地大模型部署”这几个字，最近在我身边出现的频率高得吓人。做开发的同事问能不能把 DeepSeek、Qwen 装到自己笔记本上写代码用，做内容的同学问本地起的模型能不能做知识库问答，还有刚入行的朋友一开口就是“我是不是得配一台好几个W的工作站”。大多数人的第一反应都是先看硬件参数，结果越看越慌，最后干脆放弃。我决定把这一整套流程掰开揉碎写出来：从判断机器能不能跑、选什么工具和模型、到真正把模型跑起来并接到 VS Code、Claude Code 这类日常工具里，再到用 Docker + vLLM 做像样一点的推理服务，每个环节都讲清楚“为什么这么做”而不是只丢命令。这篇文章适合所有想在本地折腾大模型的开发者，哪怕你只有一台普通笔记本，只要跟着流程走，两小时内一定能看到模型在本地给你回话。

1. 部署前必须先算账：显存、内存和模型大小到底什么关系

很多教程一上来就让你装 Ollama、拉模型，结果拉到一半发现自己电脑根本带不动，白等半天。本地部署大模型这件事，第一道门槛从来不是工具，而是你对“模型跑起来要吃多少资源”这件事有没有概念。

1.1 一张公式看懂显存需求

先给一个最简单的估算公式，Transformer 结构的模型在推理时，光是把权重放进显存就有一个下限：

text复制权重显存 ≈ 参数量(B) × 每个权重占的字节数

• 用 FP16 半精度跑，每个参数占 2 字节，7B 模型光权重就是 14GB。
• 用 INT8 量化，每个参数占 1 字节，7B 模型约 7GB。
• 用 INT4 量化，每个参数约为 0.5 字节，7B 模型约 3.5GB 到 4GB。

但这只是“权重”部分。实际推理时还要算上 KV Cache、临时激活值、推理框架自身的开销。KV Cache 和上下文长度直接相关，你给模型塞的上下文越长，吃的显存越多。所以一个很常见的现象是：模型明明加载成功了，一聊长对话或者一上传大文档就报显存不足，原因就在这。

以目前最主流的 GGUF 量化格式为例，Ollama 仓库里 Q4_K_M 量化版本的模型体积大致如下，这个数字已经包含了大部分实际开销的参考：

注意，表格里的配置建议不是绝对的。一个非常现实的情况是：如果你只有 8GB 显存，跑 7B 的 Q4 量化模型是可行的，但如果你想同时跑两个模型、或者开一个很大的上下文窗口，立刻就会挤爆显存。先对着这张表，冷静看看自己的机器属于哪一档，再决定要拉哪个模型，这是省时间的关键。

1.2 没有独显也不代表完全没戏

没有 NVIDIA 显卡能不能本地部署？能，但你要接受一个现实：速度会比较慢。以 llama.cpp 这类纯 CPU 推理引擎为例，模型全靠 CPU 算，生成速度主要取决于内存带宽。普通双通道 DDR4/DDR5 内存的话，跑 7B 量化模型大概能做到每秒 1 到 3 个 token，这个速度用来应付简单的问答、文本润色是够的，用来写代码辅助就会觉得响应太慢。

Mac 用户情况会好不少，因为 Apple Silicon 是统一内存架构，CPU 和 GPU 共用一块内存。M 系列芯片的机器跑本地模型其实非常有优势，比如 16GB 统一内存的 MacBook Air 跑 7B 量化模型能到每秒十几个 token，体验比同价位的无独显 Windows 笔记本强太多。所以别一看“没有 N 卡”就觉得自己被排除在外，先看你的内存和系统。

另外还有纯内存容量的问题。跑模型之前，确保你的剩余 RAM 至少要比模型文件大出 2GB 以上，否则模型还没开始说话，系统就可能因为内存不足把进程杀掉。我见过太多人拿着 8GB 内存的机器硬拉 14B 模型，结果终端里模型加载到一半整个系统卡死，最后只能强制重启。

1.3 部署链路的选择：先知道有哪几条路

搞清楚硬件能跑到什么程度之后，再选部署工具就不会乱。目前主流工具大致分三类：

• Ollama：自带模型仓库，一条命令拉模型、一条命令跑服务，体验最像“装 App”，适合绝大多数人和绝大多数场景。
• LM Studio：图形化界面做得好，适合不想碰命令行的人，内置搜索和下载功能，也可以开一个 OpenAI 兼容 API 让别人调用。
• vLLM / SGLang 这类推理框架：面向高并发、生产级服务，配置门槛高，但对显存利用率和吞吐量的优化到位，适合团队内部服务、批量任务。

很多人把这三类工具对立起来，其实没必要。它们解决的问题是不同的，前期先老老实实从 Ollama 开始，等你觉得“响应速度不够”“并发一多就排队”，再考虑上 vLLM。这也是我后面会用专门一节讲 vLLM 的原因。

2. 从零跑通第一个本地模型：Ollama 安装与完整实操

Ollama 为什么能成为本地部署的事实标准？因为它把最麻烦的三件事一次性解决了：模型文件分发、底层推理引擎、OpenAI 兼容 API。你不需要自己下载 Hugging Face 上的权重，不需要编译 llama.cpp，也不需要写服务端代码，装一个 Ollama 就全齐了。这一步的目标只有一个：在你自己的电脑上，看到大模型真正开始对话。

2.1 安装 Ollama 的三种方式

Ollama 支持 Windows、macOS 和 Linux。Windows 和 macOS 用户直接到 ollama.com 下载安装包即可，安装完打开命令行敲 ollama --version 能输出版本号就说明成功了。Linux 服务器用户一般用官方安装脚本：

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

脚本会自动帮你处理 systemd 服务，装完之后 Ollama 已经在后台运行，默认监听本机的 11434 端口。装完先确认一下服务状态，别急着拉模型：

bash复制sudo systemctl status ollama

看到 active (running) 就说明服务起来了。Windows 上 Ollama 安装完成后，托盘区会出现一个羊驼图标，点击菜单里有 View Logs 和 Quit，这些入口后面排查问题会用到。

2.2 拉取并运行你的第一个模型

先用一个最不容易出错的模型验证整套链路。我个人建议不要一上来就拉 14B 以上的大模型，先用 7B 级别把流程跑通，再按需换更大的。以 Qwen2.5 为例：

bash复制ollama run qwen2.5:7b

第一次执行会先显示 pulling 进度条，把大约 4.7GB 的模型文件下载到本地，下载完成后自动进入对话界面。看到类似 >>> Send a message 的提示符，你就可以直接输入问题测试了，比如问它“用 Python 写一个快速排序”。

如果只想下载不进入交互，用：

bash复制ollama pull qwen2.5:7b

想看看本机已经有哪几个模型：

bash复制ollama list

想看看当前内存里加载了哪个模型、占了多少资源：

bash复制ollama ps

在对话界面输入 /bye 退出，输入 /help 可以查看所有可用指令。

2.3 服务地址和模型存放位置，这两件事要心里有数

Ollama 拉下来的模型默认存放在用户目录下。Linux 和 macOS 是 ~/.ollama/models，Windows 是 C:\Users\你的用户名\.ollama\models。这个目录会非常大，如果你 C 盘空间紧张，一定要提前把模型目录改到其他盘。方法很简单：在系统环境变量里新增一个 OLLAMA_MODELS，值指向你想要存放的位置，然后重启 Ollama 服务。

服务本身默认通过 HTTP 协议监听 11434 端口。你在浏览器里访问 http://localhost:11434，能看到 Ollama is running 的字样。这个端口非常关键，后面所有工具接入本地模型，本质上都是往这个端口发请求。

提示：修改任何环境变量之后，一定要重启 Ollama 服务，否则怎么都不生效。Windows 在托盘退出后重新打开即可，Linux 执行 sudo systemctl restart ollama。

3. 模型选型与量化：DeepSeek、Qwen、GLM 到底该选谁

把第一个模型跑通以后，你一定会遇到下一个灵魂拷问：网上都在聊 DeepSeek、Qwen、GLM、Llama，我到底该下哪个？这个问题没有标准答案，但有一个非常实用的分析框架：先看用途，再看参数量，最后看量化。

3.1 参数量、蒸馏版和量化版的核心区别

关于参数量，有一件事特别容易被新人误解：很多人以为本地部署的 deepseek-r1:7b 就是 DeepSeek 官方那个满血版模型。实话说，差远了。官方线上的 DeepSeek 模型是 671B 的 MoE 模型，本地能装下的 7B、14B、32B 版本，本质上是用大模型蒸馏出来的小模型，能力断档很严重。所以一句话总结：你在本地跑的永远是小模型的“投影”，别指望完全复刻线上大模型的质量，正常预期是“日常能用，但复杂任务会露怯”。

量化这个概念，简单理解为一种“用可接受的质量损失换体积和速度”的压缩手段。Q8、Q6、Q5、Q4、Q3 这些数字代表每个权重用多少 bit 来表达，数字越小文件越小、速度越快、质量也越低。目前社区默认的平衡点是 Q4_K_M，绝大多数模型你看到的大小就是这个量化级别。如果你显存够用，想追求更好质量，可以选 Q6_K 或 Q8_0，但提升幅度对于日常使用来说不算特别大。

3.2 按你的用途抄作业式选型

我自己长期使用之后给出的选型参考如下：

这里我强烈建议一个做法：机器配置允许的话，同时装一个 qwen2.5-coder 系列和一个 deepseek-r1 系列，前者日常写代码用，后者遇到复杂问题需要模型“先思考再回答”时用。不同任务换不同的模型，比你硬找一个“全能王”要实际得多。

3.3 从 ModelScope 下载 GGUF 再手动导入 Ollama

在 Ollama 官方仓库拉模型已经够方便，但如果你是国内网络条件，官方源有时候会特别慢，下载到一半断掉更是家常便饭。这时候我通常直接去 ModelScope 魔搭社区这类可正常访问的平台下载 GGUF 文件，然后手动导入 Ollama。

先通过 pip 安装 ModelScope 的命令行工具：

bash复制pip install modelscope

然后下载你想要的 GGUF 文件，比如：

bash复制modelscope download --model Qwen/Qwen2.5-7B-Instruct-GGUF qwen2.5-7b-instruct-q4_k_m.gguf --local_dir ./qwen_gguf

下载完成后，创建一个文本文件作为 Ollama 的 Modelfile，内容指定 GGUF 文件的路径：

dockerfile复制FROM ./qwen_gguf/qwen2.5-7b-instruct-q4_k_m.gguf

然后在同一目录下执行：

bash复制ollama create qwen2.5-7b-local -f Modelfile

ollama create 的作用是把这个 GGUF 文件构造成 Ollama 认识的本地模型条目。有一点要提醒：从第三方源下载的 GGUF 不一定自带完整的 prompt 模板信息，如果导入后对话风格不对劲、或者模型不知道自己的身份，你需要在 Modelfile 里补 TEMPLATE 字段。稳妥起见，新手阶段尽量优先从 Ollama 官方仓库拉取模型，因为官方已经把这些元信息都配好了；手动导入这条路主要是为了解决下载速度问题。

4. 把本地模型接进 VS Code 和 Claude Code：开发工作流才算完整

模型跑起来只是第一步，真正让“本地部署大模型”产生价值的时刻，是它能跟你每天打开的开发工具无缝协作。这一章解决的是接入问题，而且你会发现，Ollama 其实已经把最难的那部分接口工作替你做好了。

4.1 认识 OpenAI 兼容 API 这个“通用插座”

现在几乎所有本地推理工具都提供 OpenAI 兼容接口。什么叫兼容？意思是你在代码里不需要区分背后是 ChatGPT 还是本地模型，只要请求的地址、请求体格式跟 OpenAI 官方接口长得一样，就能直接通信。

Ollama 的 OpenAI 兼容接口地址是：

text复制http://localhost:11434/v1

API Key 随便填一个字符串，比如 ollama，因为本地服务不做鉴权校验，填了只是为了满足客户端 SDK 的格式要求。用 Python 的 openai 库调一下试试：

python复制from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:11434/v1",
    api_key="ollama"
)

resp = client.chat.completions.create(
    model="qwen2.5:7b",
    messages=[
        {"role": "user", "content": "用一句话解释什么是 HTTP"}
    ]
)

print(resp.choices[0].message.content)

只要这段代码能跑通，说明本地模型已经完全变成了一套“可编程的服务”。后面不管你是写脚本批量处理文本，还是给内部工具加 AI 能力，都是在这个接口上做文章。

4.2 VS Code 里接入本地模型的插件配置

VS Code 生态里能连本地模型的 AI 插件非常多，我自己主要用 Cline 和 Continue。Cline 的优势是会展示完整操作链路，比较适合辅助修改代码；Continue 更像是一个聊天式的辅助，适合边写边问。不管哪个插件，配置逻辑都是一样的：在模型提供商设置里选择 OpenAI Compatible，填三个关键字段：

• Base URL：http://127.0.0.1:11434/v1
• API Key：随便填 ollama
• Model ID：填你在 Ollama 里实际存在的模型名，比如 qwen2.5-coder:14b

给一个实际建议：在 VS Code 里接本地模型时，不要用 7B 级别以下的通用模型，代码任务对模型能力要求高，小模型很容易生成有明显语法错误或者逻辑不通的代码。我实测下来，qwen2.5-coder:14b 是个性价比很高的起点，如果显存不够，qwen2.5-coder:7b 也比通用 7B 强不少。如果你选 Cline 这类带 Agent 能力的插件，注意把自动接受改代码的开关关掉，本地小模型写出来的代码还是要人工过目一遍，别让 AI 没轻没重地直接覆盖你的源代码。

4.3 Claude Code 接入本地模型：协议转换的思路

Claude Code 这个词最近热度很高，它是 Anthropic 官方的终端编程助手。它原生只跟 Anthropic 的接口通信，要把 Ollama 这种只讲 OpenAI 方言的本地模型接进去，中间必须加一个协议转换层。这一步我不是很建议新手直接上手，但既然问了，我把思路讲清楚。

Claude Code 读取环境变量里的 ANTHROPIC_BASE_URL 来确认请求该发到哪。默认指向 Anthropic 官方，我们把它改成本地某个兼容服务地址，比如 http://localhost:8000，同时设一个假的鉴权 token：

bash复制export ANTHROPIC_BASE_URL=http://localhost:8000
export ANTHROPIC_AUTH_TOKEN=ollama
claude

问题来了：Ollama 本身不会说 Anthropic 的“方言”，所以 localhost:8000 这个位置需要一个能接收 Anthropic 格式请求、再转成 OpenAI 格式发给 Ollama 的转换服务。目前社区里有 claude-code-router 这样的开源项目专门做这件事，它通过一个配置文件把不同模型名映射到不同后端。使用时一般是在它的配置里加一个 Ollama 服务商，然后把默认路由指到你在 Ollama 里建的模型名。

这类工具迭代极快，配置文件格式经常变，最靠谱的做法是：先装一个这类转换工具，然后严格按它仓库 README 里的步骤操作。你需要理解的底层逻辑只有一句话：Claude Code 关心的是 Anthropic 格式的接口，本地模型关心的是 OpenAI 格式的接口，中间那个转换层负责做翻译，仅此而已。

4.4 桌面版 AnythingLLM：把本地模型变成个人知识库

如果你不只是想写代码，还想让本地模型“读”你手头的文档，然后针对文档内容回答问题，那你可以试试 AnythingLLM 这种桌面应用。它本身不带模型，但支持连接 Ollama，你只需要在设置里把 Ollama 地址填成 http://localhost:11434，再选一个模型名就能用。

接入之后，你可以建一个 workspace，把你常用的 PDF、Word、Markdown 文档扔进去，AnythingLLM 会做文本切分和向量化。之后你问的问题如果和文档内容相关，它会先从文档里检索最相关的片段，再连同问题一起交给本地模型生成回答。这个“检索增强生成”的流程，就是目前搭建个人知识库最主流的方式，全程本地运行，你的文档内容不会流出自己的电脑。

5. 进阶上强度：用 Docker + vLLM 搭一个接近生产环境的推理服务

把 Ollama 玩熟了以后，你迟早会遇到几个瓶颈：一是同时请求一多，响应速度直线下降；二是没有细粒度控制显存、上下文长度、并发数的能力；三是团队里多人想用，总不能让别人也去装 Ollama。这些场景就该轮到 vLLM 上场了。

5.1 为什么要从 Ollama 换到 vLLM

vLLM 的核心优势是它实现了 PagedAttention 这个显存管理技术。打个比方，Ollama 这类基于 llama.cpp 的推理方式，给每个请求预分配一整块连续显存，请求少没事，请求一多，碎片化浪费就特别严重；vLLM 像操作系统管理内存那样以页为单位管理 KV Cache，可以大幅提升显存利用率，从而支持更高并发和更大吞吐。

代价是什么？配置复杂。vLLM 不自带模型下载仓库，你需要用 Hugging Face 或 ModelScope 上的模型，而且它对显卡型号、驱动、CUDA 版本都有要求。所以我的建议很清楚：单机自己用，没必要换 vLLM；但如果你想让模型服务被多个应用调用，或者你的机器显存足够大还希望吞吐能力尽量压榨出来，就值得投入。

5.2 用 Docker Compose 把 vLLM 服务拉起来

vLLM 官方提供了 OpenAI 兼容的镜像，名字叫 vllm/vllm-openai。假设我已经通过 ModelScope 把 Qwen2.5-7B-Instruct 的完整权重下载到了本机 ./models 目录，可以写这样一个 docker-compose.yml：

yaml复制services:
  vllm:
    image: vllm/vllm-openai:latest
    command:
      - --model
      - /models/Qwen/Qwen2.5-7B-Instruct
      - --served-model-name
      - local-qwen
      - --port
      - "8000"
      - --gpu-memory-utilization
      - "0.85"
    volumes:
      - ./models:/models
    ports:
      - "8000:8000"
    environment:
      - HF_HOME=/models
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]

先解释几个关键参数。--gpu-memory-utilization 0.85 的意思是让 vLLM 最多使用 85% 的显存，留出余量给显卡驱动和别的进程，直接填 0.95 也不是不行，但很容易在叠加了其他应用时报显存不足。--served-model-name local-qwen 是把模型对外叫成一个你自定义的名字，这样客户端请求时不需要关心模型内部路径。

启动命令：

bash复制docker compose up -d

启动过程中要留意日志，vLLM 会先加载权重并做预热。启动完成后，用 curl 验证一下：

bash复制curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "local-qwen",
    "messages": [{"role": "user", "content": "你好，请简单介绍一下你自己"}]
  }'

如果返回了带 choices 的 JSON，说明服务已经正常运行。

5.3 vLLM 和 Ollama 的关键差异对照

理解两者的差异才能在不同场景里做正确选择。我整理了一份对照，方便你对号入座：

这里说一个容易踩的坑：如果你的 Linux 服务器上有多个 Python 环境，千万别跳过容器直接 pip install vllm，除非你确认 CUDA 版本匹配。vLLM 对 CUDA 的版本要求很严格，不匹配会出现“No kernel image available”这类让人抓狂的报错。用官方 Docker 镜像能绕开绝大部分依赖地狱。

6. 局域网访问：让手机和同事电脑都能调用你的本地模型

本地模型默认只监听了本机地址，也就是说只有你这台电脑自己能用。但很多时候你想做的是：在另一台电脑的浏览器里打开一个界面随时问模型，或者同事想试用你部署的模型。这时候就涉及局域网共享配置。

6.1 让 Ollama 监听所有网卡

Ollama 默认绑定的地址是 127.0.0.1:11434，也就是只能本机访问。想开放给局域网，需要改环境变量。以 Linux 上比较常见的 systemd 服务方式为例，编辑 Ollama 服务配置：

bash复制sudo systemctl edit ollama

在这个编辑文件里加：

toml复制[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"

保存后重启服务：

bash复制sudo systemctl restart ollama

Windows 用户则是在系统环境变量里新增 OLLAMA_HOST 并设置成 0.0.0.0:11434，然后重启 Ollama。注意，0.0.0.0 代表“监听本机所有网络接口”，而不是某个具体 IP。

改完之后，先查一下你电脑在局域网里的 IP 地址，Linux 可以用 ip addr，Windows 可以用 ipconfig。找到类似 192.168.x.x 这样的一段，然后在同一局域网内的另一台设备上访问：

text复制http://192.168.x.x:11434

能看到 Ollama is running 就说明局域网访问已经通了。

6.2 解决防火墙和跨域拦截

局域网测试不通，百分之八十是防火墙没放行 11434 端口。Windows 首次启动 Ollama 时通常会弹防火墙授权窗，如果当时点了取消，后面就要手动去“高级安全 Windows Defender 防火墙”里添加入站规则，允许 TCP 11434 端口。

你还要知道一个比较隐蔽的变量：OLLAMA_ORIGINS。当你不是直接用 API 工具，而是用浏览器打开一个网页前端去连 Ollama 时，浏览器会有跨域限制。Ollama 默认只允许少数来源访问，碰到跨域报错，可以在环境变量里设置：

bash复制export OLLAMA_ORIGINS="*"

我建议加这个环境变量时想清楚，既然是局域网内部使用，直接放开问题不大；但如果你的 Ollama 暴露到了不可信网络，又没有任何鉴权，那别人就能通过 11434 端口随便调用你的模型，还会消耗你的显存算力。所以在开放网络里跑 Ollama 一定要谨慎，要么用防火墙限制来源 IP，要么在链路前面加一层带 API Key 的网关。

6.3 给模型配一个像样的网页端

命令行对话终究不够直观，局域网里的同学也没法上手。我一般会给 Ollama 配一个 Open WebUI，它是一个现成的网页界面，支持聊天、文件上传、多模型切换。用 Docker 一条命令就能启动：

bash复制docker run -d \
  -p 3000:8080 \
  --add-host=host.docker.internal:host-gateway \
  -e OLLAMA_BASE_URL=http://host.docker.internal:11434 \
  -v open-webui:/app/backend/data \
  --name open-webui \
  --restart always \
  ghcr.io/open-webui/open-webui:main

启动后，浏览器打开 http://localhost:3000，注册一个本地账号，就能在网页里选择 Ollama 模型开始聊天。这个界面看起来和市面上的 AI 聊天产品很像，用来给同事演示“我本地部署了一个大模型”最合适不过。Open WebUI 自身的前端代码跑在容器里，模型请求通过 host.docker.internal 这个特殊域名转发到宿主机上的 Ollama，这是 Docker 容器访问宿主机服务的标准做法。

这里特别提一句：ghcr.io 这个镜像仓库在国内网络下速度可能不理想，如果拉不动，你可以搜一下国内是否有可访问的镜像加速源，或者在网络环境良好的时段执行。不要因为拉取镜像失败就觉得是自己环境有问题，这个现象很普遍。

7. 实战中出现的那些幺蛾子：报错、卡顿和性能瓶颈排查

最后这部分我想写写真正跑起来之后才感受得到的问题。网上教程很少提这些，因为它们是在 IDE 里不会出现的、只有在真实折腾时才遇到的“经验税”。我把踩过的坑按类整理出来，你以后再碰到就不至于一头雾水。

7.1 模型加载到一半被杀掉：先分清是显存不足还是内存不足

这个现象很典型：输入 ollama run deepseek-r1:32b，然后终端里进度条走了一会儿，界面没有任何报错，进程就消失了。这种情况基本可以确定是 OOM，也就是进程被系统或者驱动杀掉了。但你要先分清是哪一种 OOM：

• 如果是显存不足，界面上通常会有一段彩色告警或者 CUDA out of memory 的报错。
• 如果是内存不足，Linux 上 dmesg 日志里能看到 Out of memory: Killed process 字样，Windows 上会表现为整个系统无响应或者模型进程直接消失。

排查思路很简单：先用 ollama ps 看当前有没有别的模型占着显存，如果有，跑到对话界面里用 /bye 退出，或者用 ollama stop <模型名> 强制卸载。然后在启动参数或 API 请求里减少 num_ctx 这个上下文长度参数。Ollama 默认的上下文窗口通常足够日常问答，但如果你在写代码或者处理长文档，模型就会悄悄把上下文撑大。明确设置一个合理的上下文长度，比如 4096 或 8192，能显著减少 KV Cache 带来的显存占用。

7.2 模型下载中断和速度慢

Ollama 官方模型仓库在海外的服务器，国内网络环境下载速度不稳定是很正常的。我见过不少人把 4GB 的模型下了三次，次次在 99% 的时候断掉，心态直接崩了。这里分享几个实际有效的办法。

第一，Ollama 的 pull 是分块下载的，失败之后重新执行 ollama pull <模型名>，它会在已有进度基础上继续，不要因为失败就删除本地模型目录从头再来。第二，前面第 3.3 节提到的 ModelScope 手动下载 GGUF 再导入，也是绕开慢速网络的一个途径，适合模型文件特别大的场景。第三，如果你公司内部或者学校有可用的模型文件分发服务，直接把别人的模型目录拷贝过来放到 OLLAMA_MODELS 对应的位置通常也能被识别，但注意版本要匹配，我自己不太推荐这种方式，除非你非常清楚 Ollama 的目录组织规则。

7.3 代码补全和 IDE 插件提示“连接失败”

接到 VS Code 插件后，最常见的问题就是连接失败。排查顺序一直是这三个检查点：Ollama 服务是否在运行；配置的 Base URL 是否拼写正确；Model ID 是否跟 ollama list 输出完全一致。

有一个很多人忽略的细节：本地 IDE 插件的 Base URL 一般写 127.0.0.1，但如果插件跑在某个容器里或者远程开发环境里，它访问的就不是你本机的 11434 端口了。Remote-SSH 连到服务器开发时，插件实际运行在服务器上，你需要把 Base URL 改成服务器能访问到的 Ollama 地址，而不是写 localhost。这个坑我踩过不止一次，排查了半天代码，最后发现是访问地址指向错了位置。

7.4 模型输出速度慢到无法忍受时，按这个顺序优化

如果模型明明已经跑起来，但生成速度只有每秒两三个 token，先别急着换工具，按下面的顺序逐个排查：

1. 看模型是不是跑在 CPU 上。执行 ollama ps，查看进程列里显示的是 GPU 处理还是全部 CPU 处理。如果显示 CPU，说明你的 Ollama 没有自动启用显卡加速，检查驱动、CUDA 环境，Windows 用户确认显卡驱动是否更新。
2. 看是不是量化等级太高。Q8_0 比 Q4_K_M 慢是必然的，速度优先就换 Q4_K_M。
3. 看模型是不是太大了。14B 在 8GB 显存上会有一部分层跑到 CPU，整体速度自然拉胯。硬件不够就是不够，老老实实换 7B。
4. 看上下文是否被撑爆。长对话后模型会越来越慢，这是因为 KV Cache 的增长拖慢了计算，缩小 num_ctx 会有效。

我看到很多人明明只有 8GB 显存，却非要用 14B 模型，然后在群里吐槽“本地模型根本没法用”。这种结论多少有点冤枉本地部署这条路线。本地模型的价值从来不是顶替线上大模型，而是在断网环境、隐私敏感、高频低延迟三种场景下提供“够用且可控”的能力。8GB 显存跑好一个 7B 量化模型，代码补全加上文档问答，体验已经很友好了。

每个新模型拉下来，我都会花几分钟把同样一组问题问一遍：让模型写一段有复杂逻辑的代码、总结一篇长文章、做一道数学题，然后横向对比哪个模型的输出更符合我的需求。这套“自己的评测集”比看别人的榜单有用得多，毕竟模型最终是拿来做你手头的事，而不是跑别人定义的分数。机器配置决定你能跑多大的模型，使用场景决定你该跑哪个模型，这两件事想清楚了，本地大模型部署就再没有什么玄学。