同事站在我工位后面看我敲终端忍不住问你这是跟机器聊天我说不是是让本机的模型帮我写段代码。他更疑惑了本地模型那不都该在网页里用吗这个误解其实挺普遍。Ollama 本地大模型部署早就不只是“在自己电脑上开个聊天窗口”这件事了。它的核心价值在于你下载一个开源大模型到本地它能以标准 API 的方式暴露出来IDE 插件可以接、Web 工具可以接、公司业务系统也可以接。也就是说Ollama 解决的是一整条“本地模型使用链路”的问题而不是一个聊天问题。这篇文章我就把从安装下载、模型选择到接入 VS Code 里的 Claude Code、搭建 Open WebUI、再通过 OpenAI 兼容接口输出 API 的完整过程按我实际操作的顺序记录下来方便你照着走一遍。1. 先把底层逻辑理清Ollama 是一个模型运行时不是一个聊天软件很多人第一次接触 Ollama是在终端里敲了ollama run qwen2.5:7b看到命令行直接进入对话。这个印象太深了导致他们以为 Ollama 就是个“聊天玩具”。真不是。聊天只是它最表面的功能它真正做的事情是把“下载模型、运行推理、暴露接口”这三件事包成一个统一层。1.1 用 Docker 来类比 Ollama 的三大职责我习惯把 Ollama 理解成“大模型界的 Docker”。不是说容器化而是它在使用心智上和 Docker 高度相似。ollama pull对应docker pull负责拉取模型ollama run对应docker run负责启动一个模型实例ollama list查看本地有哪些模型ollama ps查看当前正在跑的模型几乎一一对应。这三件事对应三个核心能力模型管理pull、push、rm、create能处理模型版本和量化格式差异不需要你手动去管理文件目录。推理运行时执行run时它会根据当前机器的硬件自动选择推理后端。NVIDIA 显卡走 CUDAAMD 走 ROCmApple Silicon 走 Metal没有独立显卡就退到 CPU。这个自动选择省掉了无数环境配置的麻烦。服务化默认监听127.0.0.1:11434同时提供原生 HTTP API 和 OpenAI 兼容端点让任何会发 HTTP 请求的程序都能调用本地模型。没有 Ollama 之前用 llama.cpp 跑 GGUF 模型你需要自己下载权重、处理命令行参数、写调用脚本每个模型可能踩一遍不同的编译坑。Ollama 把这些全部封装了这也是它生态能快速起来的根本原因——它把“用本地模型”的门槛从“编译源码”降到了“装一个软件”。1.2 本地部署的真正价值在哪里本地大模型和云端 API 不是替代关系而是互补关系。我之所以倾向在本机跑一套主要看中四点第一是隐私。代码片段、内部文档、客户数据这些丢给云端 API 总归有顾虑。本地部署后所有推理都在自己机器上完成数据不出内网。第二是离线可用。出差、断网、内网隔离环境本地模型是唯一能提供智能能力的方式。第三是可控性。云端 API 有版本下线、限流、封禁的问题本地模型没有这些外部约束。第四是长期成本。如果生成量很大一张消费级显卡跑本地模型的边际成本远低于按 token 计费的云端 API。当然也要接受它的极限本地跑的开源模型在复杂推理、代码生成质量、长文本理解上和顶级闭源模型还是有差距。尤其是 7B 级别的本地模型日常聊天和简单代码补全够用但要让它像一个资深工程师那样处理大型遗留代码仓库不太现实。所以我的态度是能用本地解决的先用本地搞不定的再考虑云端 API。1.3 安装 Ollama 之前建议先确认的三件事我知道很多人会直接冲到官网下载安装包但我建议先花两分钟确认三件事避免装完再折腾系统环境Windows、macOS、Linux 的安装方式不同而且还要决定是直接用原生安装包还是用 Docker 方式部署。这两种方案后面有各自要注意的地方。硬件配置有没有独立显卡显存多大Apple Silicon 统一内存是多大这直接决定你最多能跑多大的模型。磁盘空间一个 7B 模型量化后约 4-5GB14B 约 9GB32B 约 20GB。如果 C 盘空间紧张一定要提前把模型存储路径改到其他盘。这三件事不确定好后面很容易出现“模型拉下来了系统盘满了”或者“拉了个大模型卡成幻灯片”的局面。2. 安装与初始化从下载安装包到跑通第一个模型安装本身不复杂但有几个细节处理不好会浪费不少时间。我把三个平台的安装方式、必配的环境变量、硬件门槛和下载卡死问题一次性说清楚。2.1 各平台安装方式与版本选择Windows 最简单直接下载 Ollama 的 exe 安装包双击安装即可。装完它会在后台启动一个ollama serve服务之后你在终端里敲ollama命令就能用。如果你用 WinGet也可以一条命令搞定winget install Ollama.Ollama。我推荐用 WinGet 的原因是可以顺便自动处理 PATH 环境变量。macOS 推荐用 Homebrewbrew install ollama。如果不用 Homebrew去官网下载 pkg 包也可以。两者选其一别在同一个环境里混着装。Linux 用官方安装脚本最省事注意脚本执行完成后ollama二进制通常装在/usr/local/bin如果当前用户没有写权限可能需要手动确认安装是否成功。Linux 下还有一个选择是直接用 Docker 跑docker run -d -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama。但要注意如果想让容器里的 Ollama 用到 NVIDIA GPU光跑这个命令不够必须先装好 NVIDIA Container Toolkit否则模型全程跑 CPU速度会很感人。2.2 这五个环境变量建议第一次就配好安装完成只是第一步真正影响日常体验的是环境变量。我在不同机器上配过很多次 Ollama有五个变量几乎每次都要动建议你刚开始就配好省得以后迁移路径再踩坑。环境变量默认值作用我的推荐OLLAMA_MODELS~/.ollama/models模型文件存放路径改到大容量磁盘比如D:\ollama\modelsOLLAMA_HOST127.0.0.1:11434服务监听地址单机用默认局域网访问改0.0.0.0:11434OLLAMA_NUM_PARALLEL1一个模型同时处理的请求数显存够用可设2否则保持 1OLLAMA_KEEP_ALIVE5m模型在内存中的驻留时间内存紧张设0任务密集设10mOLLAMA_MAX_LOADED_MODELS3同时最多加载几个模型显存小设1Windows 设置环境变量在“系统属性 - 环境变量”里操作设置完必须重启终端否则不生效。macOS 和 Linux 在~/.zshrc或~/.bashrc里加export然后source。OLLAMA_MODELS尤其重要Windows 用户默认会把模型存在 C 盘用户目录拉几个大模型C 盘很快就爆了。2.3 显存门槛你的机器到底能跑多大模型本地大模型对显存的需求是实打实的。我整理了一个基于 Q4 量化等级的参考表你可以对照自己的硬件水平挑选合适规模的模型。模型参数量量化后大小建议显存/内存流畅运行的硬件示例3B约 2GB4GB无独显靠 CPU 也能勉强跑7B约 4.5GB6GBRTX 3060 12GB、16GB 内存的 Mac8B约 5GB6-8GBRTX 3060 12GB、M 系列 16GB14B约 9GB12GBRTX 3080/4070 12GB32B约 20GB24GBRTX 4090、M 系列 32GB70B约 43GB48GB多卡或 Mac 64GB 起步要注意这个表只是“能装进显存”的底线。实际运行的时候系统本身也要占一点显存而且如果你同时开浏览器、IDE内存和显存压力都会叠加。另外 Ollama 有一个分层卸载机制显存不够时模型的一部分层会放在 CPU/内存里计算导致速度明显下降。所以选模型的原则是宁可小一档不要卡爆。2.4 模型下载卡住时的解决办法下载模型卡住是新手遇到最多的一个问题典型表现是ollama pull qwen2.5:14b之后进度条长时间不动或者几 MB 之后就停滞。这里先要分清是“文件确实大”还是“网络卡了”14B 模型约 9GB肉眼看着它下载本来就要一段时间。如果进度条长时间完全不动最直接的办法是CtrlC中断重试Ollama 支持断点续传重新执行pull会从断点继续。如果反复卡在同一个进度说明默认下载链路在你的网络环境下不太稳定。我实际用过最顺手的替代方案从 ModelScope 魔搭社区下载原始的 GGUF 文件然后通过ollama create导入到本地。ModelScope 上通常能直接搜到Qwen2.5-7B-Instruct-GGUF这类文件下载速度比直接 pull 快非常多。下载完成后写一个 ModelfileFROM ./qwen2.5-7b-instruct-q4_k_m.gguf TEMPLATE {{- if .System }}|im_start|system {{ .System }}|im_end| {{- end }}|im_start|user {{ .Prompt }}|im_end| |im_start|assistant PARAMETER stop |im_start| PARAMETER stop |im_end|然后执行ollama create qwen2.5-local -f Modelfile。这里的 TEMPLATE 最好参考该模型在官方仓库的对话模板不同模型的格式不一样用错了会出现回复乱套的情况。如果只为应急也可以直接FROM一行指向 GGUF 文件但对话体验会打折扣。3. 模型选型不同任务对应不同的本地模型很多人的选择困难症发生在拉模型这一步。其实不用纠结“哪个模型最强”而要看你拿它做什么。我按使用场景把 Ollama 上值得试的模型分成四类直接照方抓药就行。3.1 中文对话场景首选的模型中文场景我首选 Qwen 系列。qwen2.5:7b和qwen2.5:14b这两个版本在中文理解、文本润色、内容总结上表现稳定Ollama 生态里的兼容性也最好。显存够的话直接上 14B质量比 7B 高一截尤其是长文本和复杂指令的场景。如果只是轻度问答、跑在无 GPU 的老机器上qwen2.5:3b也能顶一下。如果你更熟悉 ChatGLM 系列glm4:9b也是中文场景的选择之一但在 Ollama 里的模型生态和模板更新速度没有 Qwen 勤快所以我默认还是推荐 Qwen。3.2 代码与编程辅助场景的模型代码场景要看你是“补全短片段”还是“理解整个项目”。补全场景推荐qwen2.5-coder:7b起步14B 更稳32B 则是这个系列里的旗舰理解和生成能力明显更好。deepseek-coder:6.7b是老牌选手特定场景下还不错但新项目不太建议再入手因为新版 DeepSeek 模型都走推理路线了。如果你要接 Claude Code 这类 Agent我建议选qwen2.5-coder:14b或 32B。7B 也能跑但连续多轮修改、调用工具时容易掉链子。不要把代码 Agent 的预期建立在 7B 模型上它做点自动补全还行独立改需求就是另一回事了。3.3 推理深度与工具调用场景的模型需要“再想一想再回答”的场景比如数学题、逻辑分析、复杂指令拆解推荐 DeepSeek-R1 的蒸馏版本比如deepseek-r1:7b、deepseek-r1:14b、deepseek-r1:32b。这个系列在回答前会先生成思考过程效果确实好代价是响应时间变长。把它接进 IDE 做补全不太合适更适合做问答和推理类 API。Agent 和工具调用场景也就是要让模型自主决定调用哪个函数、返回什么样的 JSONqwen2.5系列和llama3.1:8b都支持 function calling。如果你正好在用 Nous Hermes 那套生态也可以直接拉它官方的 GGUF。必须提醒一句本地小模型的工具调用能力属于“能用但别硬压上限”真正部署到生产环境前一定要用你实际场景里的工具定义多测几轮。3.4 量化标签 q4、K_M 这些后缀到底代表什么Ollama 模型名后面跟着的标签比如qwen2.5:7b和qwen2.5:7b-q8_0区别就在量化方式。简单说模型权重是浮点数文件越大精度越高但显存占用也越大。q4_K_M是日常最均衡的选择也是很多模型默认标签体积适中质量损失在可接受范围。q8_0更接近原版效果体积大不少显存足够才考虑。q2_K是最强压缩体积最小但回答质量下降明显不推荐。用ollama show 模型名可以看模型的详细信息包括参数量、量化等级、上下文长度。选模型时先看量化再看参数量最后才比较“谁更强”顺序别搞反。4. 接入 IDEClaude Code 直连本地模型的完整打通过程本地模型跑起来以后最有价值的应用场景就是接入 IDE。现在 Claude Code 很火我猜不少人搜“Claude Code 接入本地大模型”就是想省 API 费用。这条路完全走得通但中间有一道协议转换的门槛我先讲清楚再来配置。4.1 为什么 Claude Code 不能直接填一个 Ollama 地址Claude Code 是 Anthropic 官方出的终端编程助手它走的是 Anthropic Messages API 协议也就是/v1/messages。而 Ollama 对外提供的是原生/api/*接口和 OpenAI 兼容的/v1/chat/completions接口。这两种协议在请求体结构、消息格式、流式返回格式上都不一样所以你不能直接把ANTHROPIC_BASE_URL指向http://localhost:11434指向了也连不通。想要打通核心思路是加一个中间层把 Anthropic 协议翻译成 Ollama 能理解的 OpenAI 风格协议。这块我建议用 LiteLLM Proxy它本身是一个成熟的模型网关一条命令就能启动还支持参数过滤。4.2 用 LiteLLM 做协议转换层的配置方法先安装 LiteLLMpip install litellm[proxy]然后启动一个代理把请求转发给本地 Ollamalitellm --model ollama_chat/qwen2.5-coder:14b --port 4000 --drop_params这里的ollama_chat/前缀表示用 Ollama 的 chat 接口--drop_params很关键它会把 Anthropic 传来的一些 Ollama 不支持的采样参数直接丢弃避免请求 400。接着给 Claude Code 配置环境变量export ANTHROPIC_BASE_URLhttp://localhost:4000 export ANTHROPIC_AUTH_TOKENsk-local-test export ANTHROPIC_MODELqwen2.5-coder:14b然后在项目目录里执行claude正常情况下就能看到 Claude Code 用你本地模型进行对话和文件修改了。第一次跑通的时候那种“云端专属功能居然能在本地 14B 模型上跑起来”的感受还挺奇妙的。不过我也要泼盆冷水本地模型在复杂代码任务上的表现和官方 Claude 模型有明显差距这属于模型能力天花板的问题不是配置能解决的。4.3 cc-switch 与配置切换管理折腾过 Claude Code 的人都知道它的配置本质上就是一组环境变量。你既想要官方 API 的强模型又想偶尔切到本地模型省钱总不能每次手动改环境变量。GitHub 上有个开源工具 cc-switch就是干这个的。cc-switch 提供了一个简单的管理界面你可以在里面保存多套“供应商配置”。比如一套叫“Claude 官方”填官方 API 地址和 Token另一套叫“本地 Ollama”填http://localhost:4000和一个本地假 Token。需要切换的时候点一下即可不用再碰环境变量。这个工具不改变 Claude Code 本身的逻辑它只是把配置切换这件事从“命令行手工操作”变成“图形化一键操作”。4.4 不想折腾协议转换时VS Code 的续写插件怎么接如果你只是想在 VS Code 里有个对话框和自动补全不一定要上 Claude CodeContinue 和 Cline 这些插件更省事。以 Continue 为例它的配置里直接内置了 Ollama 支持不需要协议转换层。在配置里加一个 providerproviders: - name: local-ollama provider: ollama model: qwen2.5-coder:14b保存后侧边栏聊天框和代码补全就会走本地模型。Cline 则稍微通用一点它支持 OpenAI-compatible provider把 base URL 填成http://localhost:11434/v1API Key 随便填一个非空字符串模型名填你本地拉取的模型名也能连上。这部分没有一个标准答案我的习惯是日常补全和闲聊用 Continue重要项目的深度重构交给 Claude Code 走云端本地模型负责隐私要求高或离线时的辅助工作。工具是死的搭配是活的。5. Web 化把本地模型变成团队可访问的服务终端工具毕竟只有自己能玩。当你希望让团队或者局域网内的多台设备都能访问到本地模型时就需要一个 Web 界面。5.1 Docker 部署 Open WebUI 与容器网络真相Open WebUI 是目前用得最多的开源 Web 方案功能包括多用户登录、对话管理、模型切换、文档上传 RAG甚至还能接工具调用。推荐用 Docker 部署docker run -d \ -p 3000:8080 \ --add-hosthost.docker.internal:host-gateway \ -v open-webui:/app/backend/data \ --name open-webui \ --restart always \ ghcr.io/open-webui/open-webui:main启动后浏览器访问http://localhost:3000首次打开按页面提示注册一个管理员账号然后在后台把 Ollama 地址填成http://host.docker.internal:11434就能看到你本地的模型列表了。这里有一个特别常见的坑容器里的localhost不是宿主机的localhost。你在容器内写http://localhost:11434它访问的是容器自己而不是你宿主机上的 Ollama。Linux 上必须加--add-hosthost.docker.internal:host-gateway才能用host.docker.internal指向宿主机。如果你是 macOS 或 Windows那条参数加了也没坏处但 Docker Desktop 自带了对host.docker.internal的支持。5.2 不用 Docker 的轻量启动方式如果机器上没有 Docker也不想为这事专门装一个Open WebUI 也支持直接 pip 安装pip install open-webui open-webui serve启动后同一个访问地址配置逻辑和 Docker 版基本一致。这种方式的优点是少了一层容器网络配置简单缺点是环境隔离差升级和清理没有 Docker 干净。我的建议生产环境用 Docker个人临时体验或者无 Docker 的内网服务器用 pip 方式都能接受。5.3 比聊天更重的 Dify 接入方式适合谁Open WebUI 解决的是“聊天和轻量 RAG”但如果你的需求是编排复杂的工作流、做知识库问答之外的 Agent 应用那 Open WebUI 就不够了。这时候可以去看 Dify。Dify 是一个 LLMOps 平台定位更重支持可视化编排、数据集管理、插件市场、多模型供应商管理。在 Dify 后台的“设置 - 模型供应商”里选择 Ollama填上http://host.docker.internal:11434或实际可达的 Ollama 地址再填模型名就能把本地模型作为 Dify 的模型后盾。适合的场景是你在做一个内部知识助手希望把用户上传的文档切片、召回、再交给本地模型生成答案Dify 会省掉一大块自研工作。不过 Dify 本身有学习成本如果只是几个人聊天问答Open WebUI 已经绰绰有余了。6. API 输出把本地模型变成业务系统的一个内部服务接完 IDE 和 Web UI 之后最有价值的一步是把它做成 API。这样一来任何内部系统都能调用它而不只局限于聊天工具。6.1 Ollama 原生接口generate 与 chat 的区别Ollama 原生接口有两个核心端点/api/generate和/api/chat。generate是简单的文本补全适合“给一段 prompt 返回一段文字”的场景chat是带消息结构的多轮对话适合需要维护会话历史的场景。实际开发中我几乎只用chat它结构更标准以后切换模型供应商时也更好迁移。curl http://localhost:11434/api/chat \ -H Content-Type: application/json \ -d { model: qwen2.5:7b, messages: [ {role: user, content: 用一句话介绍 Ollama} ], stream: false }6.2 OpenAI 兼容端点一行代码替换你的 SDK base_urlOllama 很聪明地提供了一个 OpenAI 兼容端点http://localhost:11434/v1。这意味着你现有的 OpenAI SDK 不需要改任何业务逻辑只需要把base_url换成本地地址API Key 随便填一个非空字符串就能把请求发到本地模型。from openai import OpenAI client OpenAI( base_urlhttp://localhost:11434/v1, api_keyollama ) response client.chat.completions.create( modelqwen2.5:7b, messages[{role: user, content: 你好}] ) print(response.choices[0].message.content)这个兼容层带来的生态价值特别大。很多开源项目、内部工具、低代码平台都内置了 OpenAI 客户端只要允许你改 base URL就能直接接入本地模型。这也是我为什么强调“Ollama 解决的是链路问题”的原因。6.3 并发、上下文与模型驻留的三项调优把模型接进正式业务后光会调接口不够还要懂得调服务的资源参数。并发请求上OLLAMA_NUM_PARALLEL默认是 1也就是同一时间一个模型只处理一个请求多余的会排队。要是你的 API 同时被多个系统调用可以调成 2但前提是显存有余量否则并发了反而拖慢整体响应。模型驻留方面OLLAMA_KEEP_ALIVE默认5m模型 5 分钟没人调用就从内存释放。如果是 7x24 小时都被调用的服务建议直接设成较长的时间避免模型频繁加载卸载省掉加载时间如果你只是偶尔用一下设成0可以即时释放内存避免模型一直占着显存。上下文长度是最容易忽视的一环。本地模型的 context 窗口从几千到几十万不等但实际能用多少取决于模型本身和显存大小。业务方调用时如果一次性塞太多历史消息和文件内容就会顶到模型的 context 上限Ollama 直接返回 400 类错误。这种报错信息里通常会带maximum context length is xxx tokens遇到之后不要慌先看请求里塞了多少内容能截断就截断实在要长文本就换一个支持更长上下文的模型。6.4 局域网暴露模型时的安全基线把OLLAMA_HOST改成0.0.0.0:11434后局域网内任意设备都能直接访问你的模型接口这等于把你的算力裸奔在网络上。如果不加任何鉴权内部任何一个人都可以无限调用你的模型。如果这个服务意外暴露到了更大的网络范围还可能被刷量消耗算力。最低限度的安全措施只在可信的内网环境开启不要直接映射到公网用 Nginx 做反向代理加一层 Basic Auth 或 Token 鉴权如果通过 Open WebUI 开放必须开启它的用户登录功能不要用匿名访问。另外我见过有人折腾半天报login failed或 token 校验错误最后发现是 IDE 插件在用自己的第三方平台 token 认证跟 Ollama 接口本身没关系。遇到这类问题先分清楚是“哪个环节在报错”不要一上来就怀疑本地模型配置。7. 排错实录我从下载到接入阶段踩过的坑最后这部分我把实际使用中遇到的几个典型问题和完整排查思路写出来。这些坑不一定每个人都会踩但排查的方法是可以复用的。7.1 装完 Ollama 命令找不到先检查 PATH 而不是重装现象很直接安装完成后终端里敲ollama提示“不是内部或外部命令”。新手第一反应往往是“是不是没装成功”然后卸载重装装完还是不行。排查顺序应该是先找到 Ollama 的安装目录确认ollama.exe或ollama文件真的存在。如果存在再检查 PATH 环境变量里有没有这个路径。Windows 安装包通常会自动写入 PATH但有个非常容易忽略的点已经打开的终端窗口不会自动刷新环境变量你需要重新开一个终端窗口。Linux 下则要检查当前用户是否有执行权限有的安装脚本执行完/usr/local/bin/ollama只有 root 权限普通用户执行会报 Permission denied。7.2 拉取模型卡在 0%根因往往不是网速ollama pull下载卡住的情况我在 2.4 节已经说了一个解法。这里补充一个详细的排查思路先看进度条是否完全静止还是缓慢增长。如果静止不动优先中断重试利用断点续传多试一两次。如果每次都在同一位置卡住基本可以判断默认下载链路有问题。替代方案就是前面说的从 ModelScope 下载 GGUF再写 Modelfile 导入。这个方案我远程帮朋友处理过很多次成功率几乎是 100%只是需要多花几分钟手动写模板。导入过程中如果ollama create报模板相关错误检查 GGUF 文件的对话模板和你填写的 TEMPLATE 是否匹配如果只是简单测试不追求完美最小可以只写一行FROM但对话格式就不会太规范。7.3 接 Claude Code 后响应异常的排查链路Claude Code 接上本地模型后最常见的现象是能启动但对话经常中断或者模型回答格式不对甚至报“不理解工具调用”。出现这种问题我习惯按“自底向上”的顺序排查。第一步确认 Ollama 本身正常直接ollama run问一句简单的话看回复流畅度。第二步绕过 Claude Code直接用 curl 调用 LiteLLM 代理的/v1/messages接口看返回内容是否正常。如果 curl 直接报 400大概率是参数不兼容确认代理启动时有没有加--drop_params。第三步用一个简单的工具调用 prompt 测试模型本身的 function calling 能力。如果模型输出里没有结构化的工具调用信息那问题不在 Claude Code而是模型能力不够换更大的模型。这条排查链路的要点是每一层独立验证不要带着上层的猜测去改下层的配置。我见过别人花了两小时调 Claude Code 的配置最后发现是本地模型压根不支持工具调用格式。工具选错配置再对也没用。7.4 上下文超限报错 400 背后的真实原因模型返回 400提示maximum context length这个报错我在接 API 时遇到过很多次。它的真实原因是你一次请求里包含的系统提示、对话历史、参考文档加在一起超过了模型设定的 context 窗口上限。本地模型和云端 API 一样都有 token 计算逻辑不是简单看字数。解决思路有三个优先级第一主动减少请求体——把无关历史清掉把参考文档分段传入不要一股脑塞进去。第二换长上下文模型——比如把 7B 默认 8K 上下文的模型换成支持 32K 或 128K 的模型。第三如果是自己控制请求可以在 Ollama 调用时显式设置num_ctx参数让模型加载时使用更大的上下文窗口前提是显存撑得住。这个方法能缓解问题但不要盲目把 context 拉满上下文越长推理速度和显存占用都会同步上涨。7.5 模型不跑 GPU 导致的推理变慢用什么命令确认很多人的显卡配置不差但推理速度很慢像是 CPU 在跑。这时候先执行ollama ps看输出表格里的 PROCESSOR 列。如果显示100% GPU说明模型完整跑在显卡上如果显示50% CPU / 50% GPU说明显存不够部分层被卸载到内存里了如果全是CPU说明根本没调用到显卡。排查顺序先确认显卡驱动和 CUDA 环境是否正常Windows 上可以直接用nvidia-smi看显卡是否被系统识别。如果驱动正常但 Ollama 还是用 CPU检查是不是用 Docker 部署且没装 NVIDIA Container Toolkit。还有一个隐藏条件OLLAMA_MAX_LOADED_MODELS设得太大模型都在抢显存新模型加载时只能被迫用 CPU 兜底把它调成1能强制优先保证一个模型完整驻留 GPU。写到这我自己回顾了一下整个链路安装配置、模型选型、IDE 接入、Web 化、API 输出、排错思路每块都踩过不少坑但也正是这些坑让我把 Ollama 的运行机制理解得更深。最后补充一句个人习惯我会用ollama list定期看本地有什么模型不常用的直接删磁盘和显存都清爽很多。如果你正计划在团队里普及本地模型建议先从一个小团队试点跑通一两个真实场景再慢慢把更多业务接进来。这套东西会越用越顺。