企业官网建设流程全解析

我一直觉得，把大模型跑在自己电脑上这件事，最大的价值不是“我有别人没有”，而是那种完全掌控的自由：不用纠结账号、不用盯着流量、不用担心中间层改规则。Ollama 这工具我盯了很久，最近终于抽时间把整套流程捋顺了——从下载安装、拉模型，到接入 VS Code、搭 Web 界面、再对外提供 API 接口，全链路都跑通了，踩了不少坑，也总结了一套很稳定的工作流。这篇文章就把我的实际部署过程写出来，从零开始，每一步都带上“为什么这么做”和“我当时怎么栽的跟头”，给想入坑本地大模型的朋友一份可以直接抄的作业。

先给这篇内容的读者画个像：你可能会写点代码，哪怕只会一点 Python 也行；你办公电脑或者自己那台开发机的内存最好在 16GB 以上；你想在本地跑一个真正属于自己的模型，不想把数据往外送，也不想为了一点测试请求反复排队。这篇文章就是为你准备的。整个部署链路我会分成“环境准备与工具选型”“模型下载与配置文件实操”“IDE 接入”“Web 界面搭建”“API 统一封装”这几条主线来展开，全程以 Windows 11 为主要操作环境，顺带补充 Mac 和 Linux 的差异点，确保你在不同平台上都能找到对应的操作路径。

1. 工具选型解析：为什么要用 Ollama 作为本地模型底座

在做本地大模型部署之前，我先把自己踩过的另一条路拿出来对比一下，方便你看清选型背后的逻辑。

1.1 本地推理框架的横向对比

本地跑大模型，现在主流工具无外乎那么几类：llama.cpp 系列、LocalAI、gpt4all、Ollama、llama.rn 这类移动端方案、还有各种 Python 写的推理脚本。听起来很热闹，但如果你认真想过“我要拿大模型干实事”，就会发现大多数工具都是在半成品和工程化之间反复横跳。

我自己早年折腾过一段时间 llama.cpp，那东西定制性确实强，能手动控制量化等级，也能用 Metal 或者 CUDA 做加速。但问题在于它离“开箱即用”差得远——你得自己编 CMake、自己找二进制、还得记得那一堆命令行参数。我这种写业务代码多一点、并不想成天泡在编译日志里的人，很快就失去了耐心。

后来接触过 LocalAI，它的定位是做成“OpenAI API 的本地兼容层”，思路很对，但当时部署复杂度不低，镜像拉取慢、依赖还经常打架，社区模板的质量也参差不齐。gpt4all 的小白友好度不错，但对中文模型的支持、后端切换的灵活度还不够。

真正让我转向 Ollama 的原因有三个：第一，它把所有跟模型推理有关的脏活累活都收进了守护进程里，而且这个守护进程是把 LLM 推理、上下文缓存、请求调度全部统一管理；第二，它所有配置都收敛到一个非常简单的服务层，改写端口、调并发、换模型目录都不需要动系统级文件；第三，它对开发者生态的兼容性很好——主流 IDE 插件和 Web 项目都自带 Ollama 连接选项，认这个标准的工具越来越多。

举一个直观的例子：如果你用其他方案，从“模型文件就绪”到“API 可被外部项目调用”，中间往往还要自己写一层封装服务，处理格式转换、鉴权、流式输出。但在 Ollama 里，这一切被收敛成了类似 ORM 之于数据库那样的抽象层，你只需要装好对应 SDK 或启动服务，模型立刻就能对外交互。

1.2 Ollama 的工作原理与下载安装的准备要点

Ollama 的架构其实不复杂：核心就是一个常驻后台的服务进程。你通过命令行工具向这个服务发指令，它负责读取本地模型文件、按需加载到显存或内存、跑推理、把结果通过 HTTP 或者命令行流式返回。模型文件本身是从 Ollama 的注册中心拉下来的，也可以从 Hugging Face 等渠道自行导入。

安装前先检查两件事：

1. 存储空间：一个 7B 模型的 fp16 版本大约占 14GB 到 15GB（量化版 Q4_K_M 大概 4.4GB 到 5GB），模型动辄好几个，建议给 Ollama 预留 30GB 以上空间。如果系统盘紧张，一定把模型目录改到数据盘，方案我会在后文给出。

2. 内存/显存：Ollama 的调度策略是能塞进 GPU 就优先走 GPU，显存不够就自动往系统内存卸载。但内存最好不低于 16GB，否则加载一个 7B 量化模型也很容易把机器拖到卡死。

下载本身是个体力活，但从官网或者 GitHub release 页面搞定安装包即可。Windows 用户拿到的是 OllamaSetup.exe，一步步点完就能在任务栏看到小羊驼图标。macOS 用户可以用 brew install ollama，Linux 用户一般用官方提供的 curl 安装脚本。正常情况下的官网下载速度不会有太大问题，如果你所在网络环境拉取 GitHub 很慢，可以考虑走国内靠谱的镜像站取安装包。请记住一个铁律：任何来路不明的“一键安装包”都不要碰，直接找官方。

在安装完成后，先不要急着拉模型，打开命令行窗口跑一下：

ollama --version

能正常输出版本号，说明安装没问题。如果你发现命令找不到，大概率是环境变量没生效，重开一个新终端就行——这是新手第一个隐藏坑。

2. 核心配置实操：下载慢、模型存储与私有化部署

工具就绪之后就要解决“模型从哪来”的问题。这个环节是本地部署最容易劝退新人的地方，很多人卡在下载慢、磁盘位置不对、不知道选哪个模型，每一步都有对应解法。

2.1 国内网络环境下的模型拉取加速方案

模型文件动辄几个 GB，如果直接从官方仓库拉取，速度波动会非常明显，我自己最初也遇到过进度条长时间纹丝不动的情况。这里的核心思路不是去折腾网络本身，而是切换镜像源。

Ollama 在模型下载上支持通过环境变量 OLLAMA_HOST 和 OLLAMA_MODELS 等等，但镜像切换最常用的是 registry 环境变量。以当前社区里常见的做法为例，很多用户通过设置镜像源地址（比如使用一些高校或社区维护的 Ollama 代理站）来替换默认的 registry 地址，实测之后速度和稳定性都提升了不少。

Windows 下设置环境变量的方法是：按 Win 键，搜索“编辑系统环境变量”，在“环境变量”里为用户新建变量，变量名和变量值都是上面那组。完成后必须重启终端窗口和 Ollama 服务，修改才会生效。

注意一个细节：设了镜像源之后，你再执行 ollama pull，拉取的地址就已经指向镜像站了，但模型名称的写法和官方仓库是一样的。所以你在任何博客或文档里看到的 qwen2.5:7b、llama3.1:8b 这类名字都可以直接沿用。

顺带提一句：如果你设置的镜像站不稳定，不用一条条反复试，换一个配置项之后重启服务就行。官方源偶尔也会因为用户量太大而变慢，建议在脚本里把拉取命令和重试逻辑写在一起，避免手动盯着。

2.2 把模型安装到 D 盘或其他数据盘

很多人装完 Ollama 后才发现 C 盘空间被模型文件吃满了。原因是默认安装时，模型都会放在用户主目录的 .ollama 文件夹下。想改位置，光把模型文件拷走不管用，必须告诉 Ollama“新的家在哪”。

修改方法如下：

先确保 Ollama 进程没跑。若是 Windows 版，右键任务栏羊驼图标点退出就行。然后在系统环境变量里新建：

OLLAMA_MODELS=D:\ollama_models

保存后重新启动 Ollama，模型就会下载到新目录。如果你之前已经下过模型了，把旧目录里的 .ollama\models 内容整个拷贝到新目录，就不会有重复下载的问题。

Linux 和 macOS 同理，只是要把环境变量写进 shell 的配置文件里，比如在 ~/.bashrc 或 ~/.zshrc 中加 export 那一行。改完路径有一个好处：以后备份数据、重装系统都省心，模型文件能单独管理。我自己甚至把 D 盘这个目录做了定时同步，防止“环境崩了模型全没了”这种惨案。

2.3 模型选择策略与私有化参数配置

刚上手跑什么模型，直接决定你是“五分钟后放弃”还是“顺利跑通”。

先说推荐组合。你的机器如果是 16GB 内存且没有独立显卡，我建议第一发就选 7B 到 8B 的量化模型，最省心的两个名字是 qwen2.5:7b-instruct-q4_K_M 和 llama3.1:8b-instruct-q4_K_M。前者中文效果好，后者英文原生能力强。如果你是 32GB 内存，或者有 8GB 以上显存，可以试 14B 级模型，体验会再上一个台阶。

拉取命令示例：

ollama pull qwen2.5:7b-instruct-q4_K_M

等进度条跑完，先不要急着接 IDE，先在终端里跑一句对话：

ollama run qwen2.5:7b-instruct-q4_K_M

输入“用一句话解释回调函数和 Promise 的区别”。这一步能最快验证模型文件是否损坏、量化版本是否正常、机器的推理速度是否能接受。

关于私有化参数配置，很多人不知道 ollama 还能为每个模型创建 Modelfile，实现类似“系统提示词、上下文长度、温度”的参数固化。比如我想让模型统一以简洁风格回答，可以创建一个 my-assistant 模型：

FROM qwen2.5:7b-instruct-q4_K_M SYSTEM "你是一个严谨的编程助手，回答尽量精简，必要时直接给代码。" PARAMETER temperature 0.3 PARAMETER num_ctx 8192

然后执行：

ollama create my-assistant -f Modelfile

之后再运行 ollama run my-assistant 时，这些参数都会自动生效。这里顺带说明一下 num_ctx 的作用：它表示模型能看到的上下文窗口长度。默认只有 2048 或 4096，就算输入几千字文本，超出的部分也不会被模型“看见”。很多人的模型“前面说完后面就忘”，往往不是模型问题，而是上下文窗口太小。

2.4 多模型管理与各场景适配心得

当你的模型不止一个，管理意识就得跟上来了。Ollama 的常用命令并不多，但组合在一起就是一套完整的管理体系：

# 查看本地已有模型 ollama list # 查看模型在后台是否被加载 ollama ps # 停止某个后台加载的模型（释放显存） ollama stop qwen2.5:7b-instruct-q4_K_M # 删除不要的模型 ollama rm qwen2.5:7b-instruct-q4_K_M

我在实操中发现一个很有用的惯例：专门准备一个模型做代码补全，比如 qwen2.5-coder 系列，再准备一个写通用文档或多轮聊天，最后留一个小模型做 Embedding（微软的或者国产的都可以），这样它们各司其职，工作区划分干净。不同模型并发加载时对显存占用压力很大，建议按需启动而不是全部常驻。

3. IDE 实战接入：VS Code 与 Claude Code 的本地化改造

模型能对话只是第一步，真正把它变成生产力，是把模型接到日常开发环境里。IDE 接入的场景我拆成两半说：一类是 VS Code 这种传统编辑器，通过插件辅助写代码；另一类是 Claude Code 这样的命令行智能体，直接和本地模型对接，让模型自己去读项目、改文件。

3.1 让开箱即用的插件认出本地模型

用 VS Code 接本地模型的配件有不少，Continue 在社区里口碑不错，你直接在扩展商店搜就能装。安装完成后，在设置里会看到对话模型的配置文件，默认写的是 OpenAI 或 Anthropic 的云端信息。

接 Ollama 的原理，一句话就能讲明白：Ollama 的服务是一个本地 HTTP 服务，默认跑在 11434 端口，而且它天然兼容 OpenAI 风格的接口。所以插件界面里填的其实是“自定义 OpenAI 兼容服务”。

我的做法是，在 Continue 配置里选择 Ollama 作为 provider，然后在 model 列表里填上你想用的模型名，比如刚才那个 qwen2.5:7b-instruct-q4_K_M，baseUrl 写成：

http://localhost:11434

这样配置好在编辑器侧栏里就能看到模型状态。此时你完全不需要重启 VS Code，插件会去请求 Ollama 的接口并推送模型列表。

这里有一个新手极易犯的错：插件要求填 model 名，结果填成了“qwen2.5”带冒号版本号的标签，但实际本地不存在这个标签，直接报 404。正确做法是先在终端里 ollama list 确认准确名称，再把它复制到插件里。

3.2 通过支持 OpenAI 兼容协议的工具接入本地模型

除了 Continue，现在很流行的 Claude Code 也能通过配置切到本地模型。这个思路其实和上面一样，因为 Claude Code 本身支持配置 OpenAI 兼容端点。

我的做法是这样：先配置环境变量让 Claude Code 在请求时指向本地 Ollama 服务：

export ANTHROPIC_BASE_URL="http://localhost:11434/v1" export ANTHROPIC_AUTH_TOKEN="ollama"

这么做的原因是：Ollama 的接口在 /v1 路径下提供了 OpenAI 兼容 API，而 Claude Code 走的是 Anthropic 风格的协议。经过这层 base_url 的映射，它也能直接跟 Ollama 对话。实际体验下来，它在本地模型上读取项目文件、生成 diff、修改代码块这些基础任务都能跑起来，虽然和云端顶尖模型的综合推理能力还有差距，但胜在数据不出门、也不消耗服务配额。

接完后记得在模型选择里指定为本地模型名。Claude Code 的配置方式有命令行参数 --model 也有环境变量，选一种顺手的即可。

基于我个人的测试，“Claude Code + cc-switch + Ollama”这种组合在一些只需要自动补全、描述性代码修改、简单脚本生成的开发任务中，能稳定工作。尤其是不想用云端付费服务、又需要批量处理小需求的人，很合适。

特别提醒：IDE 接本地模型时,跑代码类任务建议选带 coder 的版本，跑通用聊天用 instruct 版本，不要总指望同一个模型在所有场景都扛得住。尤其是补全场景，上下文窗口大不大直接决定结果质量。

3.3 接入常见报错的快速判定逻辑

如果你在 IDE 里连了半天没反应，可以先在浏览器里访问一下：

http://localhost:11434

如果显示的是 “Ollama is running”，说明服务正常。接下来再确认模型是否存在，执行：

ollama list

如果这两步都没问题，那绝大多数情况下就是插件里的 baseUrl 或 API Key 字段填错了。本地服务通常不校验 key，随便填一个占位符即可。千万不要顺手把云端的 key 也复制进来，没意义。

4. Web 项目接入：Open WebUI 与前端页面的一站式方案

把本地模型接到 Web 界面，是很多人最终极的目标：不需要懂命令行，打开浏览器就能用上自己电脑上的大模型。这里我会给你两条路：一条是用现成的开源 Web 项目 Open WebUI，另一条是自己写前端页面通过接口调用。

4.1 借助 Open WebUI 把模型页面端到端跑通

你要是想拥有一个类似 ChatGPT 那样的页面体验，Open WebUI 是资产最丰厚的选项。它自带用户体系、对话管理、模型切换、文档上传等能力，还可以通过 Docker 一键部署。

如果你的机器有 Docker，直接用：

docker run -d --name open-webui -p 3000:8080 -v open-webui:/app/backend/data --add-host=host.docker.internal:host-gateway ghcr.io/open-webui/open-webui:main

如果你不想用 Docker，官方也提供了 pip 安装的方法，但会稍微折腾一点。我建议 Docker 优先，隔离省心，卸载还干净。

启动后浏览器打开：

http://localhost:3000

第一次访问会要求注册一个管理员账号，这个账号数据存在本地 Docker 卷里。注册完成后进入设置页，把 Ollama API 地址填成：

http://host.docker.internal:11434

注意这里不能填 localhost，因为 Docker 容器内部访问宿主机要用 host.docker.internal。填完点击连接，正常情况下页面会自动抓取你已经 pull 过的模型列表，浏览器界面就算跑通了。

4.2 如何处理 Web 场景下的跨域与鉴权问题

如果你不用现成项目，而是自己在 Next.js 或者 Vue 项目里调用 Ollama，会遇到两个绕不开的问题：浏览器跨域和接口调用安全。

Ollama 默认没有开启跨域限制，但浏览器从某个自定义端口发请求给 11434 时，可能会被 CORS 策略拦下。处理方案有两种：一是启动 Ollama 时设置 OLLAMA_ORIGINS 把前端地址加进去：

OLLAMA_ORIGINS=http://localhost:3000

这在 Windows 环境变量里配置同样有效；二是自己写一层极薄的 Node/Java 后端代理，把前端请求转发到 Ollama，这样浏览器永远只跟你自己的后端通信，既不跨域，也能在 Node 层做鉴权。

我个人的建议是：如果不是纯本机演示，而是想让局域网内其他人用，一定要在前面加一层反向代理做权限控制，不要把 Ollama 裸奔到内网。另外，如果 Web 页面里打算让用户上传 PDF 或者长文，先在 Node 层把文件切成适配大小的文本块再发给 Ollama，不然长文档很容易把上下文窗口撑爆，导致报内部错误。如果你在用 ASP.NET MVC 这类后端技术，把 Ollama 封装成后台调用接口一样可行——原理就是向 11434 发 HTTP 请求拿到结果再返回给前端，没本质区别。

4.3 Web 端模型会话的参数调优建议

在 Web 页面上调模型，跟在终端里跑模型还不太一样。终端里你只对着一轮对话，Web 端用户会连续发多条，上下文累积很快。所以我建议在页面侧做“会话隔离”——每个会话独立维护历史消息，而不是无脑把所有聊天都塞给同一个请求。

Open WebUI 其实已经帮你做好了这些。如果你自研，会话隔离的最简单实现就是把 messages 数组放在内存里，每次请求把全量数组发给模型，再在 OpenAI 兼容请求里带上 stream: true。前端接流式输出时注意逐行解析，不要把一整段 JSON 全部等到结束再渲染。

5. API 统一封装：三种主流调用方式的实操演示

本地模型最终能被多少项目使用，取决于你对它的调用方式熟不熟。下面把 Ollama 的标准 API、OpenAI 兼容 API、以及脚本化自动调用三种方式各展示一遍。

5.1 开启对外服务与多端口配置

Ollama 默认只绑定 127.0.0.1 的 11434 端口，只能本机访问。如果要让局域网其他设备访问，需要配置：

OLLAMA_HOST=0.0.0.0

Windows 下同样在环境变量里改，之后重启服务。此时如果你的电脑局域网 IP 是 192.168.1.8，同一 WiFi 下其他设备就能通过：

http://192.168.1.8:11434

访问你的模型了。

不过我要认真敲一下黑板：直接在公网开放 11434 端口非常危险。Ollama 本身没有内建的 API Key 鉴权机制，一旦暴露到公网，任何人都能调用你的模型、消耗你的 CPU/GPU 资源，甚至可能通过模型接口探测内网环境，这是我强烈不建议的。如果需要远程访问，请务必使用运行反向代理 + 认证中间件的方式，不要把裸端口暴露到公网。

5.2 使用原生 /api/generate 接口处理生成任务

Ollama 的原生接口以 /api 开头，最常用的是 /api/generate，适合单轮问答或者流式输出。

我用 Python requests 快速调用的示例：

import requests import json url = "http://localhost:11434/api/generate" payload = { "model": "qwen2.5:7b-instruct-q4_K_M", "prompt": "用Python写一个读取CSV文件并返回平均值的函数", "stream": False, "options": { "temperature": 0.2, "num_ctx": 8192 } } resp = requests.post(url, json=payload, timeout=120) resp.encoding = "utf-8" data = resp.json() print(data["response"])

实际生产里，我倾向于把 stream 设为 True，再配合 SSE 解析去逐字展示结果。你不要小看这个选择：对长文本生成任务，如果 stream=False，用户可能要白等十几秒甚至几十秒才看到内容，体验极差。如果 stream=True，每次 resp.iter_lines() 里解析出 data 字段并实时拼装，整个交互就会顺畅很多。

5.3 使用 OpenAI 兼容 API 适配不同开发语言

如果你希望现有项目不用改太多代码就能对接本地模型，直接调 Ollama 的 OpenAI 兼容端点更省事。

先看 curl 的完整示例：

curl http://localhost:11434/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "qwen2.5:7b-instruct-q4_K_M", "messages": [ {"role": "system", "content": "你是一名资深Java工程师"}, {"role": "user", "content": "解释一下Spring Boot自动配置的原理"} ], "stream": false }'

Python 端可以用 SDK：

from openai import OpenAI client = OpenAI( base_url="http://localhost:11434/v1", api_key="ollama" # 本地服务其实不校验，但为了兼容SDK，必须给个非空值 ) resp = client.chat.completions.create( model="qwen2.5:7b-instruct-q4_K_M", messages=[ {"role": "user", "content": "用中文讲清楚闭包是什么，并给一个JS例子"} ], stream=False ) print(resp.choices[0].message.content)

这里 core 的点在于 base_url 必须指向 /v1，否则 OpenAI SDK 会尝试拼出云服务域名然后直接失败。api_key 字段在本地场景随意填，但一定要有这个参数，因为 SDK 好不容做了强制校验逻辑。

Node.js 侧也类似，只是把包换成 openai 的 npm 包，逻辑完全一致。这样你会发现，本地模型的代码接入成本并不比云端高，很多时候只是改改 base_url 而已。

5.4 API 服务化最佳实践与超时机制

一旦有多个项目同时在调用本地模型，你就不能在每一个项目里单独维护一套调用逻辑了。更好的做法是自己封装一层“模型网关”，把模型选择、上下文轮转、多实例负载分担都收敛到同一个服务里。

我用 Python FastAPI 做过一个轻量封装，结构很清晰：

from fastapi import FastAPI, HTTPException from pydantic import BaseModel from openai import OpenAI app = FastAPI() client = OpenAI(base_url="http://localhost:11434/v1", api_key="ollama") class ChatRequest(BaseModel): model: str = "qwen2.5:7b-instruct-q4_K_M" message: str temperature: float = 0.3 @app.post("/chat") def chat(req: ChatRequest): try: resp = client.chat.completions.create( model=req.model, messages=[{"role": "user", "content": req.message}], temperature=req.temperature, timeout=120 ) return {"reply": resp.choices[0].message.content} except Exception as e: raise HTTPException(status_code=500, detail=f"Model call failed: {e}")

这样一个内部服务就可以供公司其他同事或者自己的其他应用调用了。接入 API 时的超时机制非常关键：本地模型在 CPU 上推理速度远慢于云端，如果应用层把超时设成 5 秒、10 秒，生成稍长一点的回答就会直接请求失败。可以把请求超时调到 120 秒，并配合 SSE 流式返回，让前端不是干等。

6. 进阶玩法与注意事项：调并发、调显存、避大坑

走完了从安装到 API 封装的主流程，剩下的是让这套系统长期稳定运行的关键心法，也是我实际踩坑最多的区域。

6.1 并发参数与端口默认值调整

如果你在企业内部把本地模型接到了多人协作的工具上，Ollama 默认的并发处理能力会变成瓶颈。默认情况下 Ollama 一次只处理一个请求，后续请求只能排队等待，而排队期间用户完全感受不到进度，体感就跟崩了似的。

两个最实用的环境变量：

OLLAMA_NUM_PARALLEL=2 OLLAMA_MAX_LOADED_MODELS=2

第一个变量表示每个模型允许并行处理 2 个请求。第二个变量表示同时最多加载 2 个模型。具体数字取决于你内存多少、显存多大，只能实测，不能盲抄。8GB 显存跑 7B 量化模型时，并发开到 1 是稳妥的，显存更大的机器再往上增加。

每次改完环境变量都要重启 Ollama 服务，你可以先用:

ollama ps

观察模型加载情况，再压测一下。我见过有人把 OLLAMA_NUM_PARALLEL 调到 8，结果显存溢出后进程直接崩溃，所以“越高越好”的思路在这里不成立。

6.2 内存与显存不足时的兜底机制

如果你的电脑没有独立显卡，所有推理都会走 CPU，那么速度基本就固定在每秒几个 token 到十几个 token 之间。内存不足时，模型加载阶段就会出现“一闪而过”的报错，或者响应直接超时。

我的建议比较现实：普通办公学习直接跑 7B 量化模型就好，别贪大。如果非要跑更大模型，可以用 llama.cpp 类的不完全加载方案配合 mmap 处理，但 Ollama 不支持这么底层的操作，所以更省心的做法是换机器/加到 32GB 内存，或者干脆接受小模型的现状。

还有一个小技巧：在模型空闲的时候，它并不会马上从内存中退出去，而是驻留一段时间，方便后续请求秒回。如果你想让模型立刻释放资源，可以用：

ollama stop <模型名>

6.3 桌面端到 Web 端的跨域调试案例

说到这里，可能有人已经遇到了这种情况：从 Web 页面发起请求时直接被浏览器拦截。常见的报错是 “blocked by CORS policy” 或 “fail api scope is not declared in the privacy agreement”。

如果遇到这类问题，先检查三件事：

1. 前面说的 OLLAMA_ORIGINS 是否把页面源地址加进去了。比如页面跑在 http://localhost:3000，那么环境变量里就写 http://localhost:3000；端口变了也要同步改。

2. 浏览器是不是从 https 页面访问 http 接口。如果页面在线上是 https，而 Ollama 服务是 http，混合内容可能直接拦掉。这种情况只能在服务端反向代理一层 https，或者在前端开发环境里用 http 源页面测试。

3. Chrome 之类的浏览器缓存。改了环境变量和页面代码还是报错，强制刷新或者无痕模式也许就好。

6.4 大模型文件管理与日常运维速查

日常运维的坑，我一次性把所有常踩的集合成了一张速查表，方便你们直接定位。

6.5 彻底理清本地模型接入外部生态的边界

最后想谈一些偏思考的内容。本地模型跟云端模型之间从来没有“你死我活”的替代关系，更多是分工互补。我自己现在的模式是：日常聊天、写代码补全、生成各种格式的模板文本，尽量先走本地模型，速度虽然慢，但胜在隐私和可控；需要更强的理解力或者复杂代码重构，再借助云端服务，把问题封装好一次性发给云端。

本地大模型能实现的生产力上限，往往不由工具决定，而由你的封装能力和场景想象力决定。把 Ollama 当成一个和 MySQL、Redis 平级的基础设施去设计你的调用层，后面的路会越走越宽。

在实操中我还有一个小癖好：每次给外部项目接本地模型时，先在脚本里同时打印出输入 token 数、生成 token 数和耗时。这样你就能直观掌握模型在每类任务上的表现，时间久了就知道什么任务适合本地跑，什么任务建议换云端，这种判断是任何参数教程都给不了你的。

希望这篇实战内容能帮你把本地大模型真正用起来。踩坑不可怕，可怕的是对着几KB的模型文件和一个报错窗口无从下手。从下载到接入 IDE、Web、API，这套链路我已经验证过可靠，剩下的就看你怎么组合它们了。