本地跑大模型这件事最近已经不算什么新鲜技术了但真正动手折腾过的人都知道网上教程看着花哨真到自己上手时卡在下载、端口、模型名这些小问题上能折腾一下午。我这段时间把 Ollama 从服务器到个人电脑完整部署了好几遍又陆续接进了 IDE、Web 前端和 API 接口过程中踩了不少坑也总结出了一套能直接照着做的路径。这篇就来完整记录从安装到接入三种常用场景的实战过程把下载加速、模型路径、局域网访问、上下文长度这些高频问题一次性讲透。这个内容适合谁看如果你是刚接触本地大模型想在个人电脑上跑一个 Qwen 或 Llama 系列模型或者你已经装了 Ollama但不知道怎么把它接到 VS Code、JetBrains 这类 IDE 里再或者你想把本地模型封装成接口给 Web 前端调用这篇都能给你省下大量查资料的时间。1. 为什么偏偏是 Ollama安装方案与前置环境准备开始安装前先别急着敲命令搞清楚 Ollama 在整套本地大模型部署里到底扮演什么角色能帮你少走很多弯路。1.1 先搞清楚 Ollama 帮你解决了什么问题如果裸跑大模型你通常需要自己处理三件事模型文件的下载和格式转换、模型在 CPU/GPU 上的推理调度、以及对外提供接口的 Web 服务。这三件事单独做都不难但合在一起就非常琐碎。Ollama 的本质就是把这三层打包成一个服务你只需要下载一个安装包然后通过命令拉模型它就会自动把模型文件加载到显存或内存中并在本机的 11434 端口启动一个控制服务。这个“服务”的思路非常关键。很多人以为 Ollama 跟普通软件一样双击打开一个聊天窗口就完事了。实际上它默认隐藏了聊天界面暴露出来的是一个 HTTP API。这种设计的最大好处是方便集成IDE 插件可以访问它Web 项目可以访问它远程电脑也能访问它。刚开始你可能只为了聊天窗口装它但部署完成后要尽早建立“Ollama 本地模型服务”的心智模型后面接入 IDE 和 Web 项目时思路就会非常清晰。官方支持的操作系统是 Windows、macOS 和主流 Linux。Windows 和 macOS 直接下载安装包即可Linux 官方给了一行安装脚本。安装完成之后打开终端输入ollama -v能正常显示版本号就说明核心服务已经跑起来了。这一步通常五秒钟就能完成真正的难点往往在模型下载环节。1.2 下载太慢的破局思路安装包与模型分开处理“Ollama 下载太慢”可以拆成两个完全不同的阶段一是下载安装包二是拉取模型文件。很多人在第一阶段就开始烦躁其实安装包通常只有几百兆到一两个 G最直接的办法是用支持断点续传的多线程下载工具去下载官方直链。我试过几次在浏览器里下载动不动就卡住换成多线程工具后速度能稳定很多下载完再双击安装就行安装流程没有任何区别。第二阶段也就是运行ollama pull qwen2.5:7b拉取模型时如果网络状况不好会在进度条上卡很久甚至出现下载到一半 SHA256 校验失败的情况。我的处理方案是不在 Ollama 内部死磕网络而是借助国内模型仓库把模型文件先下载到本地再用 Ollama 的本地导入功能加载。像魔搭社区这类国内模型站通常都提供 GGUF 格式的模型文件下载速度要理想得多下载完成后的导入过程不依赖外网真正做到了把模型下载和 Ollama 安装彻底解耦。导入的具体做法是写一个Modelfile文件里面通过FROM指定本地 GGUF 文件路径然后用ollama create命令创建成本地模型。比如我从模型站下载了 Qwen2.5 7B Instruct 的 4bit 量化 GGUF 文件放在D:\models\qwen2.5-7b-instruct-q4_k_m.gguf就可以建一个内容如下的ModelfileFROM D:\models\qwen2.5-7b-instruct-q4_k_m.gguf然后在同目录执行ollama create qwen2.5-7b-local -f Modelfile运行完成后ollama list里就会多出一个叫qwen2.5-7b-local的模型。这种方案的优点很突出模型站上的文件命名清晰下载过程可断点续传而且导入成功的是经过校验的本地文件后续推理不再需要联网。如果你只是想快速试玩也可以继续用ollama pull但一旦遇到反复卡住的问题不要反复重试果断转到“下载 GGUF 再导入”的方案这才是真正省时间的做法。1.3 模型默认安装到 C 盘怎么办修改 OLLAMA_MODELS 路径Windows 用户最容易踩的坑是模型路径。Ollama 默认把模型文件放在C:\Users\你的用户名\.ollama\models而一个 7B 量级模型通常要占 4 到 8 个 G多下几个模型 C 盘很快就满了。到那时候再迁移就麻烦因为模型文件几百个 G 的话移动起来很耗时建议从一开始就规划好路径。修改方式是通过环境变量把模型目录指到其他盘。在 Windows 上先创建一个专门用于存放模型的目录比如D:\ollama_models然后进入系统设置搜索“编辑系统环境变量”在用户变量区域新建一个变量变量名OLLAMA_MODELS 变量值D:\ollama_models创建完成后需要彻底退出 Ollama。注意不是关掉聊天窗口而是右键系统托盘里的 Ollama 图标选择退出然后重新从开始菜单启动。启动后随便拉一个模型再去D:\ollama_models里看就能看到按模型名组织的目录结构了。修改环境变量后不生效的问题90% 是因为没有彻底重启进程这个细节值得单独记下来。除了路径最好顺手把另外两个常用变量也配了。OLLAMA_HOST设为0.0.0.0可以让局域网内其他设备访问OLLAMA_CONTEXT_LENGTH用来控制默认上下文长度。这些变量不用一次配齐可以按需添加但建议在刚开始时就了解它们的位置后面排障会方便很多。2. 模型下载与命令行操作从零跑通第一个本地模型Ollama 装好之后最爽快的时刻就是第一次在本地跑起模型。但选择哪个模型、怎么调整上下文、怎么定制人设这些细节直接影响后续接入 IDE 和 Web 时的体验。2.1 先选一个不后悔的模型再记住这几个高频命令模型选择这件事没有标准答案但有几个经验性的参考维度。首要维度是你的硬件条件尤其是可用显存或内存的大小。以 Qwen2.5 系列为例我做了一个粗略的参考表适合大多数人的初步选型硬件条件推荐模型参考说明8G 显存qwen2.5:3b日常代码补全、轻量问答够用12G-16G 显存qwen2.5:7b综合能力强最常被选用的档位24G 显存qwen2.5:14b逻辑推理明显更强对内存压力也更大纯 CPU 且内存 16Gqwen2.5:3b建议选小模型速度更可接受选模型时可以留意 tag不要只敲ollama run qwen2.5因为不指定版本时默认拉取的可能是基础版显存和内存的消耗相对大。通常建议指定量化版本比如qwen2.5:7b或带q4_K_M字样的标签文件体积更小推理速度更快。对于大多数民用显卡4bit 量化在效果和资源占用之间最平衡7B 模型的 4bit 量化文件大约 4 到 5 个 G可以作为一个心理预期。命令行操作的最高频命令其实就是五个ollama pull qwen2.5:7b # 下载模型 ollama list # 查看本地已有模型 ollama run qwen2.5:7b # 进入交互式对话界面 ollama show qwen2.5:7b # 查看模型参数与上下文长度 ollama rm qwen2.5:7b # 删除模型第一次运行时 Ollama 如果本地还没有该模型会先执行拉取再进入对话所以可以直接用ollama run完成“先下载再运行”的全部流程。我的建议是首次用一个比较小的模型跑通全流程比如 1.5B 或 3B 级别确认基本链路没问题后再去下载更大的模型。这样做的好处是出问题时容易定位不至于一上来就面对下载慢、显存爆等各种问题的叠加状态。2.2 Modelfile 能干什么给模型设置人设和核心参数很多教程讲到这里就结束了默认大家只会用官方原版对话。但如果你要接 IDE 或做特定场景的 Web 应用直接改系统提示词和推理参数会非常频繁。Ollama 的Modelfile就是用来固化这些设置的。用个简单的例子我想把本地模型变成一个“只输出简洁代码不做多余解释”的编程助手可以新建一个Modelfile内容如下FROM qwen2.5:7b PARAMETER temperature 0.2 PARAMETER top_p 0.8 PARAMETER num_ctx 8192 SYSTEM 你是一名资深程序员。回答问题时优先给出可直接运行的代码不要长篇解释。代码中涉及原理性内容时用一句话说明即可。 然后执行ollama create code-assistant -f Modelfile这样我就创建了一个独立的模型叫code-assistant。它的优势非常明显团队里其他人使用同一个模型时不需要每个人都去设 system promptIDE 插件在调用时只需指定模型名得到的就是固化好行为的输出。num_ctx这个参数值得多说几句。它表示模型处理上下文的最大 token 数量Ollama 的默认值往往偏小如果你发现模型“记忆力”很差前几轮对话就忘极大概率是上下文长度不够。把它调大成 8192 或 16384 能明显改善多轮对话体验但代价是占用更多显存或内存因为保存对话状态需要额外的 KV Cache 空间。具体调到多少建议从 8192 开始试内存还有富余再加不要盲目往上顶。2.3 局域网访问让手机和其它电脑一起用同一个模型默认情况下 Ollama 服务只绑定在127.0.0.1意思是只有本机能访问。如果你有两台电脑一台配置高专门跑模型另一台日常办公想让办公电脑通过局域网访问高配机器上的模型就需要解除地址绑定限制。正确做法是设置OLLAMA_HOST环境变量为0.0.0.0让服务监听所有网络接口。Windows 上的设置位置跟前面改模型路径一样在环境变量设置里新建变量名OLLAMA_HOST 变量值0.0.0.0重启 Ollama 后用局域网内另一台电脑访问http://高配电脑的IP:11434比如http://192.168.1.100:11434应该能看到一段响应内容说明服务已经可以对外提供访问了。这里特别提醒0.0.0.0表示允许所有网卡地址上的访问如果你的电脑同时连着不信任的公网或公共 WiFi这会有曝露风险因为 Ollama 本身默认没有鉴权机制。普通家用路由器环境下风险可控但严谨起见建议只在受信任的内网环境中开启或者配合后续讲到的反向代理增加访问控制。3. 接入 IDE把本地模型变成你的编程助手IDE 接入本地大模型是本地部署最有价值的应用场景之一。代码里不让出本地用 API 服务又怕费用失控这时候本地模型就是非常实际的方案。3.1 IDE 插件为什么都盯着 11434 端口现在很多 IDE 编程助手插件都支持自定义模型服务地址它们内部遵循的标准通常是 OpenAI 的 API 格式。Ollama 本身虽有自己的接口格式但同时提供了一个兼容 OpenAI 的/v1接口。这意味着你在任何支持自定义 Base URL 的插件里都可以把端点指向http://127.0.0.1:11434/v1插件就会像调用 OpenAI API 一样调用本地模型。理解这层关系后配置工作就简化成了三个填空Base URL 填http://127.0.0.1:11434/v1API Key 随便填一个非空字符串占位模型名必须填你的本地模型名比如qwen2.5:7b。但这里有个很容易踩的坑很多教程直接说模型名填什么都可以于是用户就填了外部在线平台上的模型名如deepseek-v4-pro结果本地 Ollama 返回一个英文报错提示model not found。这类报错的原因很统一本地 Ollama 的模型列表是独立的本地没有这个模型就是没有不会自动帮你代理到云端的同名服务。配置前先在终端执行一次ollama list把列出来的模型名原封不动填进插件才能保证连接成功。3.2 Continue 插件从安装到联调全流程Continue 是我目前在 VS Code 里用得最多的开源插件安装后支持同时配置多套模型服务非常适合本地模型与云端模型对比使用。安装方式很简单在 VS Code 扩展市场搜索 Continue 并安装它会在侧边栏出现一个对话窗口。接着点击侧边栏底部的模型配置按钮找到配置文件config.json或通过图形界面修改核心配置部分大致是这样的{ models: [ { title: Local Qwen, provider: openai, model: qwen2.5:7b, apiBase: http://127.0.0.1:11434/v1, apiKey: ollama } ] }配置里有一个细节值得注意provider 字段通常要写成openai因为其他在线平台提供的也是 OpenAI 兼容接口。apiKey 字段不需要真实有效本地服务不校验但插件客户端往往要求非空所以占位即可。改完配置后在 Continue 对话窗口发一条测试消息如果模型正常回复右下角通常也会显示模型名qwen2.5:7b和耗时。3.3 JetBrains 和 Cursor 场景的通用配置法JetBrains 全家桶IDEA、PyCharm、WebStorm里接入思路跟 VS Code 完全一致差别只在插件的入口位置。以支持 OpenAI 兼容接口的 CodeGPT 类插件为例安装后在设置里找到工具列表新建一个服务配置URL 仍填http://127.0.0.1:11434/v1模型名填本地模型名密钥随便填占位符保存后把默认模型切换成这个本地服务即可。网上还经常有人问“IDE 跳转到一个叫 Qoder 或 Junie 的客户端有什么用”其实这些基本都是 JetBrains 官方或第三方推出的 AI 编程入口核心逻辑依然是把用户输入的 prompt 发给某个模型服务。如果你用的是这类自带模型列表的入口可以去设置里找自定义模型端点入口如果能填 Base URL 就按同样的方式处理如果入口固定绑定在线服务且没有开放自定义端点那就无法用本地模型替代只能选支持自定义端点的工具。Cursor 的情况也类似它不同版本对外开放的程度有差异。能自定义模型端点时记得先在模型列表里输入本地模型名ollama/qwen2.5:7b的格式具体前缀写法视版本而定。配置完以后我通常会做一个“最小验证”不在 IDE 界面上发消息而是先单独运行一次 Python 脚本或 curl 测试调用本地接口确认接口通并且模型名正确再回 IDE 调整配置。这样做的好处是能把“本地服务问题”和“IDE 配置问题”隔离出来排查速度会快很多。4. 从命令行到网页把模型接入 Web 的两种场景聊完 IDE接下来是 Web。这里的“Web”其实包含两种完全不同的需求一种是我想要一个漂亮的网页聊天界面类似本地的 ChatGPT另一种是我自己的 Web 项目想让模型生成内容。两种场景的实现方式是截然不同的。4.1 不写一行代码用 Open WebUI 快速搭建网页端如果你只是希望在浏览器里有一个聊天界面完全没有必要自己写前端。Open WebUI 是一个成熟的开源网页应用专门对接本地模型服务。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 的服务地址填上。这里有个经验值Docker 内部访问宿主机时不能填127.0.0.1因为容器里的127.0.0.1是容器自己。Windows 和 macOS 的 Docker Desktop 可以用host.docker.internalLinux 则必须在启动命令上加--add-hosthost.docker.internal:host-gateway才能解析这个域名上面这条命令已经包含了这一行。如果你不想用 Docker也能用 Python 直接启动 Open WebUI但依赖项较多没有 Docker 干净我会优先推荐容器方案。启动之后把 Ollama 的连接地址填成http://host.docker.internal:11434Open WebUI 就会自动读取本地模型列表之后的下拉选择、会话管理、文件上传都是现成的。4.2 在自己写的 Web 项目里对接 Ollama 的正确姿势如果你的需求是把自己网站里的某块功能接上模型那就不能指望现成的网页界面了需要你的后端服务去调用 Ollama 的接口。这里最容易犯的错误是前端代码直接去请求http://127.0.0.1:11434/api/chat。浏览器端直接请求本地模型服务会带来两个麻烦。首先是 CORS 跨域策略前端的域名跟 11434 端口不一致浏览器默认会拦截请求其次是把 Ollama 的地址和端口直接暴露给了所有访问者安全上不合适。正确的做法是让后端作为中转代理你的业务后端收到前端请求之后再由后端去访问 Ollama。这样一来前端只需要跟你自己的后端通信Ollama 只对你信任的后端服务可见。用 Node.js 的 Express 写一个中转接口的示意大概看起来是这样的import express from express; import fetch from node-fetch; const app express(); app.use(express.json()); app.post(/api/model/chat, async (req, res) { const { prompt } req.body; const response await fetch(http://127.0.0.1:11434/api/chat, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ model: qwen2.5:7b, messages: [{ role: user, content: prompt }], stream: false }) }); const data await response.json(); res.json({ reply: data.message.content }); }); app.listen(3001);这里强制设置stream: false是为了让后端逻辑简单一些拿到完整回复后再一次性返回给前端。如果要做打字机效果可以把stream设为true但响应处理就要改成流式解析代码复杂度会增加不少。我的建议是第一版先用非流式把业务跑通等核心链路稳定了再升级成流式体验。5. 对外开放模型能力API 接入与协议避坑指南API 接入是把模型能力变成可复用服务的关键一步。Ollama 的接口设计大部分场景足够用但它同时提供两套接口风格理解清楚它们的差异能省很多排查时间。5.1 看清两套接口原生 API 与 OpenAI 兼容接口的差异Ollama 自己有一套原生接口核心端点是/api/chat和/api/generate。前者走的是 messages 对话格式适合多轮聊天后者走的是 prompt 补全格式适合一次性生成。原生接口的特点是参数更贴近底层推理配置但缺点是第三方生态兼容性差很多现成的 SDK 和插件不认识这个格式。为了让生态更顺滑Ollama 在 11434 端口上同时提供了一个 OpenAI 兼容接口根路径是/v1端点包括/v1/models、/v1/chat/completions、/v1/embeddings。官方文档描述这套接口时使用 OpenAI 的格式请求体长这样{ model: qwen2.5:7b, messages: [ { role: user, content: 你好 } ] }响应结构也跟 OpenAI 一致最终内容在choices[0].message.content里。正是因为这种格式兼容IDE 插件才能无感接入。日常调试建议优先用 OpenAI 兼容接口因为网上绝大多数的调用示例都能直接搬来用只有当你需要控制 Ollama 独有的底层参数时再去看原生/api/chat的文档。5.2 先用 curl 打通再用 Python 接入业务系统不管最终从哪种语言调用我会建议先打开终端用 curl 做一次最小请求确认服务本身没问题。下面这条命令可以直接在终端测试curl http://127.0.0.1:11434/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen2.5:7b, messages: [ {role: user, content: 用一句话介绍你自己} ], stream: false }如果返回一大段 JSON并且在choices[0].message.content里能看到模型回复说明接口链路完全正常可以继续做业务集成。我通常还会顺手查看一下模型列表接口确认本地模型名和大小curl http://127.0.0.1:11434/v1/models业务代码里最常见的做法是使用 OpenAI 官方的 Python SDK然后把 base_url 和 api_key 改成 Ollama 的地址。下面的代码是一个可以直接运行的最小示例from openai import OpenAI client OpenAI( base_urlhttp://127.0.0.1:11434/v1, api_keyollama ) response client.chat.completions.create( modelqwen2.5:7b, messages[ {role: system, content: 你是一个简洁的助手。}, {role: user, content: 什么是 KV Cache用两句话解释。} ], streamFalse ) print(response.choices[0].message.content)这段代码的价值在于它可以直接复用 OpenAI 生态里的所有客户端经验和代码换回 OpenAI 官方接口时只需要改 base_url、api_key 和 model 名。对于已经在用 Azure OpenAI 或各类国内云模型平台的人来说迁移成本非常低。Python SDK 安装命令是pip install openai5.3 模型名、上下文长度和鉴权三个最容易报错的地方API 接入后最常见的报错几乎都集中在三处第一处是模型名写错报错信息会直接告诉你model xxx not found。这不是网络问题也不是服务问题就是本地模型列表里没有这个名字。用ollama list查完再填可以解决绝大多数这类问题。第二处是上下文长度过长。当你发送的输入内容超过模型支持的限制时会看到包含maximum context length的 400 报错例如模型上限 1048576 tokens 这类提示。这种报错在对接外部大上下文模型时更常见本地 Ollama 上则更多表现为“上下文太小导致记不住前面的内容”。处理方向相反超长输入时需要主动截断历史消息只保留最近的若干轮本地记忆不够时则要调大num_ctx。默认值通常只有几 K做代码仓库级问答时是不够的可以通过PARAMETER num_ctx 16384或环境变量OLLAMA_CONTEXT_LENGTH调整。第三处是鉴权相关比如 IDE 插件或者客户端偶尔弹窗提示login failed或check api token。这个报错特征非常明显它跟本地 Ollama 基本无关实际上是你使用的客户端在尝试登录某个在线服务。本地 Ollama 不校验 key因此本地模型接入时理论上不会出现 token 问题。如果看到 token 报错请先回头确认客户端里选择的模型服务是不是真的指向了本地地址有时候插件会静默切回默认在线服务让人误以为配置成功了。6. 实战排障记录从下载卡住到推理白屏的踩坑笔记最后这部分是我最想分享的所有参数配置最终都要落到实操里而实操必然会遇到各种不属于任何教程的怪问题。下面按主题整理了我亲测有效的排查思路和参数清单。6.1 遇到问题先看日志别让黑盒状态消耗你的时间第一次部署时遇到问题大部分人的习惯是先上网搜一圈结果搜了半天可能还没定位到根因。我的习惯是出现问题后第一时间去看日志Ollama 的日志路径很固定Windows 下在%LOCALAPPDATA%\Ollama\server.logmacOS 和 Linux 下通常在~/.ollama/ollama.log如果 Linux 上以 systemd 服务运行可以直接用journalctl -u ollama -f日志里会明确写出加载模型失败的原因、显存不足的提示、网络请求超时的时间点等信息。比如有时候你发现ollama run之后模型迟迟不回复桌面进程看起来像卡死了实际上日志早就告诉你“尝试加载模型时显存不足开始卸载其他模型腾空间”。这种时候你以为程序出 bug 了其实它只是在缓慢等待资源释放。如果日志级别不够细还可以在启动前设置环境变量OLLAMA_DEBUG1能看到更详细的请求和加载过程。把日志打开以后再复现一次问题就能看到完整调用链定位速度会大幅提升。6.2 高频问题处理清单下载、端口、GPU 三大方向的速查结合自己多次部署和网友的常见提问下面这几个场景出现的频率最高我把处理思路整理成了速查表现象常见原因处理方式pull 模型时一直卡在进度条网络传输不稳定CtrlC 中断后重试如果反复卡住考虑从模型站下载 GGUF 后通过 Modelfile 导入服务能启动但局域网其他电脑访问不了未设置监听所有网卡设置OLLAMA_HOST0.0.0.0并彻底重启 Ollama端口 11434 被占用其他程序占用端口修改OLLAMA_HOST为127.0.0.1:11435等新端口模型已用 GPU 跑但速度仍然慢上下文设置过大或模型量化级别过高降低num_ctx选择更小量化文件运行大模型时系统变得卡顿CPU 推理时内存压力过高换更小的模型或关闭其他占用内存的软件端口占用这块多说一句排查工具在 Windows 上可以用netstat -ano | findstr 11434如果发现进程占用了 11434 端口你就得决定是杀掉占用进程还是让 Ollama 换端口。我的经验是尽量不要跟系统进程抢端口直接给 Ollama 换一个高位端口更干脆。GPU 使用情况可以通过任务管理器查看也可以在命令行用nvidia-smi看显存占用。如果模型确实加载到了 GPU显存占用会有明显跳升。看不到显存占用时先看看是不是显卡太老导致 Ollama 放弃 GPU 加速退回了 CPU也有可能是驱动没更新建议先把显卡驱动更新到最新版再试一次。6.3 每次部署前我都会检查的参数与环境变量清单经过多次折腾后我整理出了一套固定检查顺序每次新机器上部署 Ollama 时都按这个顺序走一遍基本没有翻过车。第一确认安装包来源。从官方渠道下载安装包下载慢就用多线程工具安装完成后立刻验证版本号。第二确认模型存储路径。如果不想让 C 盘被占满第一时间把OLLAMA_MODELS环境变量指向其他磁盘。第三确认服务监听范围。如果需要局域网访问就设置OLLAMA_HOST0.0.0.0。第四用一个小模型跑通ollama list和对话测试。第五接入第三方工具前先看一眼模型列表确保模型名能对得上。涉及高性能场景时还有一组环境变量可以按需调整我经常用的几个如下OLLAMA_HOST0.0.0.0 OLLAMA_MODELSD:\ollama_models OLLAMA_CONTEXT_LENGTH16384 OLLAMA_KEEP_ALIVE24h OLLAMA_NUM_PARALLEL2OLLAMA_KEEP_ALIVE24h的意思是模型加载到内存后保持 24 小时不被自动卸载对频繁请求的应用很重要否则长时间不请求后模型被卸载下次请求又要重新加载延迟会明显增加。OLLAMA_NUM_PARALLEL表示同时处理的请求数显存有富余时可以设成 2能明显提升并发场景下的吞吐能力。这些参数属于优化项日常使用不用一上来就全配好但知道它们的含义能让后续调优时有的放矢。我个人在实际操作中的体会是Ollama 这套东西最大的特点是学习曲线不陡但坑位密集很多问题看起来五花八门归根结底就三个点网络下载、模型命名、环境变量。把这三点抓牢基本能覆盖掉 80% 的故障场景。如果你刚好也要给自己的电脑或服务器搭一套本地模型服务不妨就按这个顺序从安装开始一步步试先跑通最小的交互链路再慢慢往 IDE、Web 和 API 方向扩展。每一个场景之间都是独立的单独打通一个就能立刻带来实际帮助。