企业官网建设流程全解析

先把结论放前面：Ollama 是目前把本地大模型跑起来最省心的工具，没有之一。最近我把整套流程完整走了一遍，从安装、拉模型，到接入 IDE 插件、网页对话界面和自定义 API 服务，包括中间踩过的下载慢、显存溢出、上下文长度报错这些坑，都会在这篇实战记录里一次性说清楚。适合想在自己电脑上跑大模型、或者想给团队搭一套本地推理服务的同学参考，也适合那些已经装好 Ollama 但不知道怎么接进日常工具的人。

下面这份内容会严格按照真实部署顺序展开：先讲清楚为什么选 Ollama、整体架构长什么样，再一步步安装、配置环境变量、拉模型，然后依次接进 IDE、Web 和 API。每部分都有可以直接复制的命令、配置和代码，以及我在实际使用中踩过坑之后总结出来的排查方法。

1. 项目概述与整体思路

1.1 为什么选 Ollama 做本地部署

聊到本地部署大模型，市面上的方案其实不少，有直接拿 llama.cpp 编译的，有上 vLLM、TensorRT-LLM 这类重型推理框架的，也有折腾 Python + Transformers 自己写服务的。对于个人开发者和十人以内的小团队，我最后的结论很明确：先不要碰那些偏底层的东西，直接用 Ollama 把手上的模型跑起来，等确确实实需要高并发或者定制化调度了，再去看更复杂的框架。

这么选的原因很简单。Ollama 把模型下载、量化管理、推理引擎、REST API、OpenAI 兼容接口全部打包成一个后台服务，装好之后一条命令就能启动，不需要自己编译 C++ 代码，也不用为每个模型单独准备一套 Python 推理脚本。它对显存和内存的调度也比较聪明，默认会加载量化版本，比如 q4 系列模型，单张消费级显卡就能跑 7B 甚至 14B 参数量的模型，这对个人电脑来说非常关键。

另外，Ollama 不是只支持官方模型仓库里那点东西。通过 Modelfile，它可以导入任意 GGUF 格式的模型文件。也就是说，就算模型来自企业内部训练、社区下载、或者云厂商的模型库，只要转成 GGUF，就能用同一套命令和 API 管理。这种统一性，在实际项目里省掉的时间远比想象中多。

还有一个对开发者极其友好的点：Ollama 提供 OpenAI 兼容的/v1/chat/completions接口。这意味着原来基于 OpenAI SDK 写的代码，只需要改一下 base_url，就能无缝切换到本地模型。后面第四节、第六节会具体演示这个用法，这是整个方案能快速接入各种工具的核心原因。

1.2 本地模型和云端 API 怎么选

我在部署之前先做了一个简单决策：到底哪些场景该用本地模型，哪些场景继续用云端 API。如果只是跟风装一下，大概率吃灰；但如果选型选错了，后面维护成本会很高。

我的实际建议是：个人开发、内部工具、隐私敏感场景、离线环境，优先本地；如果业务要面向大量用户，或者对生成质量要求特别高，可以考虑云端 API，或者干脆做混合架构，把敏感请求分流到本地，把复杂任务转发到云端。这个决策不是二选一，Ollama 部署好后完全可以作为云端 API 的本地降级方案，接口一致，切换成本很低。

1.3 整体部署形态

这次实战的整体架构可以概括成“一个服务，三种入口”。

Ollama 安装完成之后，会在默认端口 11434 上启动一个本地服务。IDE 插件通过 OpenAI 兼容地址http://localhost:11434/v1接入；Web 聊天界面（比如 Open WebUI）直接用自己的原生 API 和模型管理能力；业务系统则通过 REST API 或者 OpenAI SDK 打通。三种入口最终都指向同一个模型运行时，底层模型文件也是同一份，不需要重复下载，也不会出现“IDE 里能用，网页里不能用”的割裂感。

理解了这一点，后面所有配置都会变得很好懂。你在 IDE 插件里填的 Base URL，在 Open WebUI 里填的 Ollama 地址，在 Python 代码里填的 base_url，本质上都是指向同一个服务。排错的时候，只要先确认http://localhost:11434通不通，就能快速定位问题在 Ollama 侧还是客户端侧。

2. 环境准备与 Ollama 安装实战

2.1 下载太慢？用国内镜像或离线包解决

下载慢是本地部署大模型遇到的第一个大坑，也是群里问得最多的问题。这里要先分清楚，下载慢发生在两个层面：一个是 Ollama 安装包本身的下载，另一个是模型文件的下载。

安装包默认托管在 GitHub Releases，国内直连确实不稳定。实用解决办法是搜索一下“ollama 国内镜像”，一般能找到热心维护的镜像直链，也可以从公司内网、团队共享盘拿离线包。如果你有 Linux 服务器，还可以用官方脚本装完再把安装目录整个打包分发到其他机器，这种离线安装方式在团队内部很实用。

模型文件的下载就更关键了。直接执行ollama pull qwen2.5:7b时，Ollama 会从国外模型仓库拉取，速度经常只有几十 KB/s，拉一个 4GB 的量化模型可能要等几个小时。

我最推荐的做法是：先从国内模型社区（比如魔搭社区）下载 GGUF 格式的模型文件，再用 Modelfile 导入 Ollama。这样做速度快，还能顺便确认模型文件完整性。

Modelfile 的内容非常简单，只需要指定基础模型文件来自哪里。例如你下载了 qwen2.5-7b-instruct-q4_k_m.gguf，把它放在某个目录下，然后新建一个 Modelfile：

FROM ./qwen2.5-7b-instruct-q4_k_m.gguf

然后在同一目录执行：

ollama create qwen2.5-7b -f Modelfile

导入完成之后，它和直接 pull 的模型用法完全一样。我在多台机器上实测，这种方式比直接 pull 稳定太多，而且可以按需选择量化版本，不会被迫使用官方默认的量化档位。

2.2 Windows 下安装与把模型挪到 D 盘

Windows 下安装 Ollama 本身不难，去官网下载安装包双击即可。但很多人会遇到一个实际问题：默认情况下，模型文件会下载到C:\Users\你的用户名\.ollama\models，C 盘空间不够，想把模型目录挪到 D 盘。

最稳妥的做法是安装完成之后，先把 Ollama 服务停掉，设置环境变量，再移动模型目录。Windows 下右键“此电脑”进入属性，打开“高级系统设置”，在环境变量里新增一个用户变量：

OLLAMA_MODELS=D:\ollama\models

然后在任务栏右下角找到 Ollama 图标退出，或者直接杀掉进程。接着把原来的模型目录复制到 D 盘。如果 C 盘原本已经有一大堆模型，不要直接剪切，建议先复制，确认新目录能正常识别之后再删除旧目录，避免数据丢失。

复制完成后再启动 Ollama 服务，执行：

ollama list

如果能看到之前的模型列表就说明迁移成功。需要注意，环境变量只影响新写入的模型目录，如果模型已经在旧目录里，光设置变量是不够的，必须移动目录本身，这一点很容易踩坑。

Linux 上思路一样，只是把目录改成/data/ollama/models之类的路径，并在 systemd 服务配置文件里添加Environment="OLLAMA_MODELS=/data/ollama/models"后重启服务。

2.3 关键环境变量速查

除了OLLAMA_MODELS，还有几个环境变量在日常使用中非常有用，建议提前了解一下。

这里重点说一下OLLAMA_KEEP_ALIVE。模型第一次被调用时需要从磁盘加载到显存，如果频繁加载卸载，响应速度会非常慢。默认行为会在请求结束后保持模型加载一段时间，但如果你的电脑内存或显存不够大，模型一直占着资源也不行。个人用途可以设置成5m，就是五分钟后自动释放；服务器场景建议设置成1h或者更长。配合ollama ps命令，可以随时查看当前有哪些模型还留在显存里。

3. 模型获取与运行管理

3.1 显存估算：决定选 7B 还是 32B

决定用哪个模型之前，先看硬件。大模型推理最关键的资源是显存，显存不够时虽然能靠 CPU 和内存硬撑，但速度会慢到让人失去耐心。

估算公式可以简化成：模型权重占用 + 上下文缓存占用 = 最低显存需求。以 7B 模型和常见的 Q4_K_M 量化为例，每个参数大约占 0.55 到 0.65 个字节，权重部分大概在 4 到 5GB 左右；再加上 8K 上下文长度带来的 KV Cache，大约额外需要 1.5 到 2GB。所以跑 7B 量化模型，8GB 显存是一个比较舒服的起点，6GB 也能勉强跑，但上下文得调短。

14B 模型权重部分大概是 9 到 10GB，32B 模型则是 20GB 左右。如果只有 16GB 显存，建议老老实实跑 14B 及以下；如果显卡只有 8GB 显存，想跑 32B 也不是不行，就要接受严重的 CPU offload，推理速度会大幅下降。

我的建议是：先跑 7B 或者 8B 的量化模型把流程跑通，不要一上来就挑战大模型。物理规律摆在那里，显存不够就是不够，靠软件优化只是勉强能用。

3.2 拉取、运行、管理模型

安装完成后，最常用的几个命令如下：

# 拉取模型 ollama pull qwen2.5:7b # 运行模型并进入交互模式 ollama run qwen2.5:7b # 查看已安装模型 ollama list # 查看当前加载到显存/内存中的模型 ollama ps # 停止当前运行中的模型 ollama stop qwen2.5:7b # 删除模型 ollama rm qwen2.5:7b # 查看模型配置详情 ollama show qwen2.5:7b --modelfile

在ollama run的交互界面里，还可以直接调整运行参数，比如输入/set parameter num_ctx 16384，可以把这个对话的上下文窗口暂时调大到 16384。输入/bye退出。这些命令是后续所有操作的基础，建议先熟练起来。

3.3 常用模型推荐

选模型这件事没有绝对标准，但我可以根据实际用途给几个不踩坑的选择。

如果你是理科背景、日常要写代码，我强烈建议优先尝试 qwen2.5-coder 系列，它对代码补全和脚本解释的准确率明显高于通用模型。如果只是跑着玩，直接ollama run qwen2.5:7b就够用了。

3.4 上下文长度怎么调大

很多人在本地部署后遇到一个问题：跟模型聊着聊着，它就完全不记得前面说过什么，或者一次性传入长文档时报错。原因很简单，Ollama 默认的上下文长度往往只有 2048 或 4096，超过的部分会被截断，甚至直接报上下文超长错误。

调整方式有三种。第一种是交互式临时调整，进入ollama run后执行/set parameter num_ctx 16384；第二种是在 API 调用时通过options参数指定；第三种是直接在 Modelfile 里加上参数定义，让模型每次加载时都自动使用更长的上下文。

比如在 Modelfile 里加一行：

FROM ./qwen2.5-7b-instruct-q4_k_m.gguf PARAMETER num_ctx 16384

执行ollama create重新创建模型后，这个模型默认就会按 16384 上下文运行。不过要注意，上下文长度不是越大越好，它需要额外显存，我在 8GB 显存显卡上把 7B 模型从 4K 调到 16K 时，显存占用明显上升，速度也有轻微下降。所以要根据自己的实际场景反复调整，够用就行。

4. 接入 IDE：让本地模型帮你写代码

4.1 OpenAI 兼容接口是 IDE 接入的基石

IDE 里的大模型插件五花八门，但它们接入本地模型这件事，大多依赖同一个事实：Ollama 提供了 OpenAI 兼容接口。

大多数插件只需要你填两个东西：一个 Base URL，一个模型名。Base URL 填http://localhost:11434/v1，模型名填ollama list里看到的名称。这个地址和服务 Keys 无关，本地服务默认没有鉴权，所以 API Key 随便填什么都能通过，很多同学第一次配置时不习惯，总觉得要填个“真正的 Key”，其实在本地场景下没必要。

我用 Continue 插件和 Cline 都试过，只要 Base URL 正确、模型名正确，基本一次就能连上。这个兼容层设计得非常聪明，它让开发工具的接入成本降到最低，不用为每个工具单独适配一套协议。

4.2 Continue 插件接入

Continue 是我在 VS Code 里尝试过的最稳定的本地模型插件。安装完插件后，需要打开 Continue 的配置文件，进入侧边栏设置，找到模型 Provider，添加一个 Ollama Provider。

配置示例如下：

{ "models": [ { "title": "Qwen2.5 7B", "provider": "ollama", "model": "qwen2.5:7b" } ] }

注意一点，这里的model字段必须和ollama list输出的名称完全一致，填错了插件会一直报连接错误。配置完成后，选中代码，让模型解释或者生成注释，请求会直接打到本地服务。实测下来，qwen2.5-coder:7b 在代码解释、单测生成这些相对简单的任务上表现很不错，速度大概每秒能输出几十个 token，对于本地模型来说已经可以接受了。

4.3 Claude Code / CC Switch 和处理协议不一致

Claude Code、还有配合它使用的 CC Switch，是目前比较热的 IDE 编程工具组合。但直接接 Ollama 有个坑：Claude Code 原生要求 Anthropic 的 API 协议，而 Ollama 原生提供的是 OpenAI 兼容协议，两者格式并不完全一致。

我在实际使用中碰到“Login failed. Check API token”这类报错，排查到最后发现不是 Ollama 的问题，而是 Claude Code 仍然在用它默认的认证流程，它以为你要连某个云端服务。正确做法有两条：要么选择天生支持 OpenAI 兼容协议的 Cline、Continue 这类工具，要么额外加一层协议转换服务，比如用 LiteLLM proxy 暴露一个 Anthropic 兼容端点，再把请求转发给 Ollama。

LiteLLM 的配置大概长这样：

model_list: - model_name: ollama/qwen2.5:7b litellm_params: model: ollama/qwen2.5:7b api_base: http://localhost:11434

LiteLLM 启动后，会在本地提供一个代理端口，然后把 Claude Code 的 base URL 指向这个代理。这种方式能做，但多了一个中间层，排查问题时会多一环，所以我的建议是：如果你不是非得用 Claude Code 不可，直接用 Continue 或 Cline 省心得多；如果一定要用 Claude Code，那就要先把协议转换层跑通，别让 Ollama 背锅。

4.4 IDE 接入的实际体验与坑

IDE 接入跑通之后，最大的感受是：本地模型确实能干活，但要把它当助手，不能把它当程序员。

代码补全类任务，如果用 qwen2.5-coder，补全质量还算有模有样。但对话式生成任务，比如让它重构一段复杂代码，它经常会给你一个“看起来合理但跑不通”的方案，需要自己动手改。另外，本地模型一旦把上下文窗口拉长，推理速度会明显下降，在 IDE 里一个请求等十几秒的情况很正常。

还有个容易忽略的坑是资源占用。IDE 本身吃内存，Ollama 加载了 7B 模型之后又吃一份显存和内存，如果电脑只有 16GB 内存，开几个大项目再跑模型，系统会明显卡顿。我后来把模型推理放到另一台 Linux 机器上，IDE 通过网络访问 Ollama，才彻底解决了这个问题。读者如果手头有多台机器，建议把模型服务独立出去，体验会好很多。

5. 接入 Web 页面：Open WebUI 与自建聊天页

5.1 Open WebUI 一键起一个聊天界面

如果不想每次都敲命令行和模型对话，最直接的办法是装一个 Open WebUI。它本身是一个网页应用，提供类似 ChatGPT 的聊天界面，还自带用户管理、历史记录、模型切换这些功能。

最推荐用 Docker 运行，一条命令就能启动：

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

启动后，Open WebUI 默认会尝试连接它自己环境里的 Ollama，也就是host.docker.internal:11434。如果你已经在本机把 Ollama 跑起来了，需要在 Open WebUI 的“外部连接”设置里把 Ollama 地址改成http://host.docker.internal:11434，或者在启动容器时设置环境变量OLLAMA_BASE_URL。

第一次打开页面会让你注册管理员账号，之后所有对话都会经过后台模型服务。整体体验很接近在线版 ChatGPT，但数据完全在自己手里。

如果不想用 Docker，也可以在本机用 pip 安装，但个人还是建议 Docker，升级、备份都方便。

5.2 局域网共享和安全

把 Ollama 只绑在 localhost 上时，只有本机能访问。如果想让团队其他人或者同一局域网内的设备也用，需要修改 OLLAMA_HOST 环境变量为：

OLLAMA_HOST=0.0.0.0:11434

重启 Ollama 服务后，局域网内其他机器就可以通过http://服务器IP:11434访问。但这一步有个安全风险，Ollama 默认没有鉴权，谁拿到地址就能调用你的模型，轻则把显存占满，重则被刷出高额电费。

所以我在实际部署中给团队用的方案是：Ollama 只监听内网，前面加一层 Nginx 反向代理做 Basic Auth，或者直接用带登录功能的 Open WebUI 暴露给用户。Open WebUI 本身支持多用户登录和管理员审核，比裸 OLLAMA 安全很多。

5.3 不装 UI 框架，用纯 HTML 调 Ollama

有时候只是想临时写个测试页面，不想装 Open WebUI 这种大组件，也可以用纯 HTML 加 JavaScript 直接调用 Ollama 接口。下面是一个最小栗子：

<!doctype html> <html> <body> <textarea id="input">用一句话介绍你自己</textarea> <button onclick="send()">发送</button> <pre id="output"></pre> <script> async function send() { const resp = await fetch("http://localhost:11434/api/generate", { method: "POST", headers: { "Content-Type": "application/json" }, body: JSON.stringify({ model: "qwen2.5:7b", prompt: document.getElementById("input").value, stream: false }) }); const data = await resp.json(); document.getElementById("output").textContent = data.response; } </script> </body> </html>

这里调用的是 Ollama 原生/api/generate接口，返回的 JSON 里包含response字段，就是模型生成的文本。如果这个页面不是从 Ollama 同源端口打开的，可能会遇到跨域拦截。Ollama 提供了OLLAMA_ORIGINS环境变量，可以设置允许的来源，比如：

OLLAMA_ORIGINS=http://127.0.0.1:5500,http://localhost:5500

设置完重启 Ollama 再试，跨域报错就能解决。

5.4 用 FastAPI 包一层再给前端调用

虽然 HTML 直接调 Ollama 方便，但生产环境不建议这么做。更合理的做法是后端包一层代理，后端负责连接 Ollama、处理权限、记录日志，前端只跟自己的后端通信。

下面是一个用 FastAPI 做的简单示例：

from fastapi import FastAPI from fastapi.middleware.cors import CORSMiddleware from pydantic import BaseModel import ollama app = FastAPI() app.add_middleware( CORSMiddleware, allow_origins=["*"], allow_methods=["*"], allow_headers=["*"], ) class ChatRequest(BaseModel): prompt: str @app.post("/chat") async def chat(req: ChatRequest): resp = ollama.chat( model="qwen2.5:7b", messages=[{"role": "user", "content": req.prompt}], options={"num_ctx": 8192}, ) return {"reply": resp.message.content}

启动后，前端把请求发到/chat，后端再转发给 Ollama。这样做的好处很明显：Ollama 的 IP、端口不会直接暴露到前端，将来要加用户鉴权、限流、日志审计都方便，也可以随时把 Ollama 换成云端 API，前端代码不用动。

6. 接入 API：开放给其他系统调用

6.1 Ollama 原生 API 常用端点

Ollama 的 HTTP 服务其实就是在 11434 端口提供了一整套 REST API。搞清楚这些端点，后面做系统集成会非常顺手。

举个最常用的例子，用 curl 调用/api/chat：

curl http://localhost:11434/api/chat \ -d '{ "model": "qwen2.5:7b", "messages": [ {"role": "user", "content": "你好"} ], "stream": false }'

如果不设置stream: false，Ollama 会默认使用流式输出，返回一堆以换行分隔的 JSON 片段。对于服务端程序，建议根据需要选择是否开启流式；对聊天类业务，开启流式能让用户体验好很多。

6.2 OpenAI SDK 的调用方式

Ollama 提供 OpenAI 兼容端点/v1/chat/completions，所以直接使用 OpenAI 官方 SDK 就能访问本地模型，只是需要把 base_url 改一下。

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": "写一段快速排序的 Python 代码"} ], ) print(resp.choices[0].message.content)

这里的关键点有两个：base_url必须带/v1，模型名必须和ollama list一致。如果你的业务原来调用的是 DeepSeek 这类云端 API，只要把base_url从云端地址换成本地地址，模型名换成已安装的模型，代码几乎不用改。我在一个内部自动化脚本里就是这么干的，平时用 DeepSeek API，离线时切到本地 Ollama，两边接口通用，省心很多。

6.3 处理 400 上下文超限错误

接入 API 之后最常见的一个报错是类似这样的 400 错误：

this model's maximum context length is 1048576 tokens ...

这个报错从字面上看像是模型上下文特别大，实际含义是要么请求里指定的上下文长度超过了模型支持上限，要么模型后端按一个很大的上下文窗口进行了预设，而实际硬件资源根本带不动。

我的处理思路是：先确认本地模型的实际上下文能力。比如 qwen2.5 系列在 Ollama 里通常可以支持到 32K 甚至更大，但默认上下文被设成 2048 或 4096。当你通过 API 传入了很长的 prompt，或者模型自己把上下文扩展参数写得很高，然后被服务端拒绝，就会出现这种 400 错误。

解决方案是显式设置num_ctx，把它控制在合理范围内。比如调用时加上：

resp = client.chat.completions.create( model="qwen2.5:7b", messages=[{"role": "user", "content": "..."}], extra_body={"options": {"num_ctx": 8192}}, )

在/api/chat方式下，则是这样：

{ "model": "qwen2.5:7b", "messages": [], "options": { "num_ctx": 8192 } }

把一个本来需要 64K 上下文的请求压到 8K，可能影响长文本理解，但至少不会报错。更合理的做法是把长文本切块后再处理，而不是无限加大上下文窗口。

6.4 生产化：鉴权、并发和端口保护

Ollama 本身定位偏向开发工具，直接用在生产环境会缺一些东西，最典型的就是鉴权。默认情况下任何人能访问 11434 端口，就能无限调用模型，这绝对是不可接受的。

我建议至少做两件事。第一，不要直接暴露 11434 公网端口，让服务只监听内网；第二，用 Nginx 反向代理并在这一层做 Basic Auth 或 API Key 校验。一个最简单的 Nginx 配置：

server { listen 11435; location / { proxy_pass http://127.0.0.1:11434; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }

然后再给该 location 加上auth_basic相关配置，或者接入现有的网关系统。对于并发控制，可以调节OLLAMA_NUM_PARALLEL环境变量，限制同时进入模型的请求数。如果团队里有多个人同时用，建议在网关层做排队和限流，否则一旦多个请求同时撞上来，显存瞬间被打满，所有请求都会变慢甚至超时。

7. 常见问题与排查技巧实录

7.1 安装和启动阶段的典型问题

启动 Ollama 后最常见的现象是端口起不来。可以先用curl http://localhost:11434/api/version测一下，如果完全不通，再检查端口是否被占用。

Windows 下查看端口占用用：

netstat -ano | findstr 11434

如果端口被占用，先找到占用进程的 PID，再用任务管理器结束它，或者修改 OLLAMA_HOST 换个端口。另一个常见问题是杀毒软件或者安全软件提示 Ollama 要访问网络，有些安全策略会直接拦截，导致局域网访问失败。解决方法是把 Ollama 的安装目录加入白名单，或者至少在防火墙里放行 11434 端口。

7.2 IDE 接入时的报错排查

IDE 接入阶段，最常见的报错是“Login failed. Check API token”或者“Connection refused”。

出现这类问题的第一步不是怀疑插件，而是先用 curl 验证 Ollama 服务本身：

curl http://localhost:11434/v1/models

如果这条命令正常返回模型列表，说明服务没问题，问题出在插件的配置上。检查三处：Base URL 是否写成了http://localhost:11434/v1，模型名是否和ollama list完全一致，以及插件是否还在使用默认的云端供应商。

还有一个容易让人迷惑的情况：有些插件会把你填入的“模型名”自动拼上一个云端模型前缀，导致 Ollama 看到的是一个不认识的模型名，反复提示找不到模型。遇到这种情况，最好用一个最简单的模型名，比如qwen2.5:7b，不要带不必要的路径。

7.3 Web 和 API 阶段的典型问题

Web 页面最容易遇到跨域问题。如果你用纯 HTML 在 5500 端口直接访问 Ollama，控制台会报 CORS 相关的错误。解决办法是正确设置OLLAMA_ORIGINS，或者在中间层加一个后端代理。注意OLLAMA_ORIGINS支持精确源和通配符，最好把端口写明确，不要直接用*，否则安全性会下降一个档次。

API 阶段比较常见的错误是 400 上下文超限、400 未知模型、以及ollama pull时下载中断。下载中断的解法是反复回到 2.1 那节，优先用 GGUF 离线导入。400 未知模型则多半是模型名拼写错误，或者还没有执行ollama pull。只要按照“先 curl 测服务，再查模型列表，最后看请求参数”这个顺序排查，九成问题都能解决。

7.4 问题速查表

最后说句实在话，Ollama 这套东西把本地大模型的门槛降得非常低，但真正想在日常开发里用稳定，还需要自己补上鉴权、并发、资源调度这些基本功。我在实际部署中最大的感受是，先把模型跑起来远不是终点，后续怎么把它接进已有工作流、怎么保证多人使用时不出问题，才是真正需要花时间的地方。如果你在接入 IDE 或 Web 时卡住，别急着怀疑模型不行，先按“服务是否正常、模型名是否一致、配置是否指向 127.0.0.1”这三步走一遍，大多数问题都能迎刃而解。希望这篇实战记录能帮你少踩几个坑。