企业官网建设流程全解析

大多数人接触本地模型，都是从“下载一个 Ollama、跑起一个对话窗口”开始的。跑通了之后，很多人会立刻做一件事：把这个本地推理服务，接进平时天天用的云端工具里，比如 VS Code 里的 AI 插件、团队的知识库、企业微信机器人，或者一个跑在服务器上的智能体。结果往往不太顺畅——要么工具不认这个地址，要么对方只支持 OpenAI 格式，要么填好了 API Key 依然报 401，要么模型名称对不上。这时候你会发现，本地模型和云端工具的协同，根本不是“有没有模型”的问题，而是“中间那层接口和工程链路”有没有被组织好。

围绕这个场景，社区里有不少开源项目值得梳理。这篇文章会重点讲四个项目：Ollama、LiteLLM、Open WebUI、Dify。它们不是同一个赛道上的竞品，更像是一条协同链上的四个拼图。先理解它们各自解决哪一层问题，再按自己的实际需求选型，才不会今天装一个工具明天卸一个工具。

1. 先搞清楚一条链：本地模型和云端工具是怎么“协同”的

1.1 “本地”不是“离线”，而是一个计算节点

很多人把“本地模型”理解成“完全离线、和云端无关”，这个印象其实会限制思路。真正在实际项目里跑的时候，本地模型承担的角色更像是“一个位于自己机器或内网里的计算节点”。云端工具仍然是入口，仍然负责账号、流程、权限、消息分发、数据存储和对外 API，只是把最核心的推理动作交给了本地模型。

这样一拆分，好处就明显了：敏感数据不用出内网，推理成本可控，离线也能跑的兜底能力更强。代价则是，云端工具不会天然知道你的本地模型存在哪里，也不会主动兼容某个独特服务地址。它只会按照自己预设的接口标准，比如 OpenAI 兼容协议，去尝试调用一个 base_url。谁能把本地模型包装成这个标准结构，谁就能被主流工具认领。

1.2 四个开源项目正好覆盖四个层级

我倾向于把这套协同架构拆成四层：

这四个项目并不要求全上。个人开发可以先只要第一层，团队使用可能需要加上第二层和第三层，一旦要接入真实业务系统，第四层基本逃不掉。

1.3 为什么不是“一个工具解决所有问题”

如果只是为了在命令行里和模型聊几句，单独用 Ollama 就够了。但云端工具五花八门，有的支持 OpenAI 协议，有的只认自己的供应商列表，有的要求填写多个参数，有的还要求带鉴权信息。把模型暴露到内网或局域网时，你还得考虑多用户、并发、权限、日志。

这些都不是单个推理引擎擅长的事情。工程上更稳的路径是各层职责分离：推理归推理，路由归路由，界面归界面，业务编排归编排。四个开源项目合在一起，恰好是一条可复用的参考链路。

2. Ollama：第一个拼图，让“模型运行层”具备统一的本地服务能力

2.1 为什么它常常是第一公里

过去在本地跑一个开源模型，你得自己处理权重下载、推理框架、显存管理、模型格式转换，光是环境问题就能劝退一大半人。Ollama 把其中大量重复劳动封装掉了。一条命令拉模型，一条命令起服务，社区模型库又足够丰富，这使它成了“本地模型 + 云端工具”场景里最常见的起点。

它不只是简单的命令行工具。Ollama 提供了本地 HTTP 服务，而且带一个 OpenAI 兼容的接口目录。正因如此，很多开发工具在支持本地模型时，第一选择就是填http://127.0.0.1:11434。日常见到的 CodeGeeX、Trae、Claude Code 这类开发工具，都有办法通过配置 base_url 指向 Ollama。

2.2 落到实操：先把最小链路跑通

一个最基础但能验证问题的流程，大概是这样：

# 启动服务端 ollama serve # 拉取一个本地模型，比如通义千问系列的小参数版本 ollama pull qwen2.5:7b # 先对话确认模型正常 ollama run qwen2.5:7b

如果模型能正常对话，再验证 HTTP 服务：

# 看本地服务是否列出了模型 curl http://127.0.0.1:11434/v1/models

对于工具侧连接，通常你只需要把 base_url 填成http://127.0.0.1:11434/v1。不过要注意，不同工具对“要不要带/v1”的处理方式不一样。有些工具会自己拼/chat/completions，有些会把认证信息放到 Header 里，有些则要求提供一个假的 API Key 才能通过校验。这里的差异，是很多人第一个踩坑点。

2.3 真正决定稳定性的不是模型跑起来，而是服务参数

单次跑通只能说明链路没有断，真正决定长期能不能用，是几个容易被忽略的参数。

# 监听所有网卡，便于同一局域网内其他机器访问 OLLAMA_HOST=0.0.0.0:11434 ollama serve # 限制同时加载的模型数量，避免显存被占满 OLLAMA_MAX_LOADED_MODELS=1 # 限制单个模型并发请求数，降低 OOM 概率 OLLAMA_NUM_PARALLEL=1

在常见实践里，默认配置适合单机学习和验证。如果准备把服务暴露给团队其他人用，就要提前想清楚：同一台机器同时服务两三个模型，容易超出显存和内存；多个请求同时进来，只要上下文一长，内存增长会非常快。通常建议一开始把并发拉低，先跑稳定，再根据真实压力慢慢调。

2.4 边界：它解决“运行”，不解决“路由与编排”

Ollama 有一个原生/v1接口，这已经能让不少工具连上了。但它的定位依然是“模型运行层”。多租户权限、不同团队按密钥计量、模型故障时自动切换云端备份、统一日志和调用审计，这些功能它并不擅长。你可以在小规模和个人场景里直接拿它当后端，但一旦要维护的模型多了、接入的工具也多了，就需要上面说的“标准接口层”。

从工程经验看，判断要不要引入更上层的项目，经验标准可以很简单：当你要给多个工具分别配置同一个本地模型地址，并且要反复改地址、换模型、处理不同工具的鉴权差异时，说明该加一层网关或代理了。

3. LiteLLM：把“协议差异”压缩成同一个 API 入口

3.1 为什么非要有统一接口层

做开发工具的人都有一个体感：各家云端工具对模型提供方的要求越来越像，但始终没有完全统一。你在这个工具里填的是 OpenAI 格式，下一个工具却只认自己的供应商列表；这个工具允许填自定义模型，那个工具甚至把模型名写死在代码里。

如果没有统一接口层，每接一个新工具，都要给它单独配置 base_url、模型名、鉴权方式。本地模型一旦换版本，又得挨个工具改一遍，维护成本会滚雪球。LiteLLM 这类项目解决的正是这个问题：它把多种后端模型统一包装成同一个 OpenAI 风格接口，对外暴露一个稳定地址，工具只需要配一次。

3.2 一次最小配置

简单理解，LiteLLM 可以是一个跑在本地或服务器上的 Python 服务，通过一份配置文件完成模型映射。

model_list: - model_name: local-qwen litellm_params: model: ollama/qwen2.5:7b api_base: http://127.0.0.1:11434 - model_name: cloud-fallback litellm_params: model: openai/gpt-4o-mini api_key: sk-xxxx

启动代理服务：

litellm --config config.yaml --port 4000

之后，任何工具都只需要访问http://127.0.0.1:4000，模型名填写local-qwen。工具根本不用知道你用的是 Ollama 还是远程云模型，也不需要知道你换没换模型版本，你只需要在配置文件里改映射关系。

这种“工具侧零改动”的价值，在长期维护里会越来越明显。你可以在本地模型不可用时把请求转发到云端模型，也可以把多个版本模型同时上线做对比，而不是在工具里反复试路径。

3.3 真正有用的不是“少写一行代码”，而是“模型变更不打扰工具”

我个人觉得，LiteLLM 这类代理层对“本地模型协同云端工具”这件事的真正价值，不是省了几分钟配置，而是让本地模型从“裸服务”变成了“可管理服务”。它能做密钥管理，能记录调用日志，能在模型 A 失败时自动尝试模型 B，还能统一设置超时和重试策略。

这很重要。因为本地模型跑在内网机器上，经常会因为显存不够、服务被杀、模型加载失败而不可用。如果没有代理层，工具会直接报错；有了代理层，你可以配置降级策略，先切换到云端模型，再通知你排查本地服务。这种体验差异，在实际生产环境里几乎是决定性的。

3.4 边界：代理层不是万能的

需要说清楚，LiteLLM 不是一个推理框架，不会帮你把模型加载到显存，也不会提升模型本身的生成质量。它解决的是“调用标准不统一”和“地址管理混乱”。

配置越复杂，出错的概率也越高。model_name如果写得和工具侧不一致，照样 404；api_base忘了指向真实的 Ollama 地址，代理层会一直转发失败；容器环境里访问宿主机，还得写host.docker.internal而不是127.0.0.1。这些细节会在后面统一排查里再展开。

4. Open WebUI：把本地模型变成可以“用起来”的交互台

4.1 不只是聊天网页

很多人以为 Open WebUI 只是一个长得像 ChatGPT 的网页。它确实提供一个聊天界面，但如果只把它当成聊天工具，就浪费了它真正的价值。

Open WebUI 可以同时连接 Ollama 和 OpenAI 兼容接口，所以它非常适合当本地模型的统一操作台。它支持多用户、会话隔离、文档上传和知识库检索，还自带一套 API 接入方式。这意味着，团队内部可以有这样一个入口：开发人员用同一个服务跑本地模型，产品和测试在网页上直接验证效果，运营在后台管理知识库，而外部工具也可以通过它的接口调用本地模型能力。

4.2 实操：用容器方式跑起来

如果你已经装好了 Ollama，下一步可以这样起 Open WebUI：

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

第一次访问时注册管理员账号，然后在后台的模型连接设置里，把 Ollama 地址填成http://host.docker.internal:11434。如果 Open WebUI 和 Ollama 跑在同一台宿主机上，用这个地址通常比直接填127.0.0.1更稳，因为容器里的127.0.0.1指向容器自己，而不是宿主机。

这一步完成之后，网页里就能看到 Ollama 拉下来的模型列表。上传文档、新建会话、切换模型，都是在这个界面里完成的。

4.3 “人”这一侧的革命：从命令行到团队共用

如果只是自己用，命令行里跑 Ollama 就够了。但一旦涉及团队协作，Open WebUI 的价值就出来了。它把“本地模型”从个人电脑的终端窗口，变成了一个团队内部都能访问的服务。管理员可以统一配置模型，普通用户不需要理解 API 和 base_url，只需要打开网页、选择模型、开始对话。

另一个常用方式是把它接给其他工具。Open WebUI 后面也可以接 LiteLLM 作为统一模型提供方，这样团队界面走 Open WebUI，业务 API 走 LiteLLM，底层模型由 Ollama 承载。三层各管各的，出现问题也容易隔离。

5. Dify：把本地模型真正放进业务流，而不只是聊天

5.1 为什么最终往往需要一个“编排层”

到了这一步，你可能已经能在网页里和本地模型聊天了，但真实业务通常不是“聊几句”这么简单。比如你负责一个客服系统、一个内部问答机器人，或者一个带工具调用的智能体，这就需要把模型接入到具体的业务流程里：给定用户输入、查知识库、调用外部 API、拼接上下文、输出结构化结果、记录日志。

Dify 就是这一层的典型开源平台。它把模型接入、Prompt 编排、知识库、工作流、日志和 API 发布都放进了同一个界面。相比手动写代码，它更适合让团队在“应用层”快速迭代。

5.2 接入方式

在 Dify 后台的“设置 → 模型供应商”里，可以直接添加 Ollama，也可以选 OpenAI API Compatible 类型的供应商。关键还是地址问题。

由于 Dify 通常跑在 Docker 容器里，它访问宿主机上的 Ollama 时，同样需要注意网络命名空间的区别。常见写法是：

http://host.docker.internal:11434

如果 Ollama 部署在另一台服务器上，这里应该填那台服务器的实际 IP，例如：

http://192.168.1.10:11434

填完之后先做连通性测试，没问题再选模型。

5.3 最小实践：从聊天到带知识库的智能体应用

一个实操路径比较典型：在 Dify 里新建“聊天助手”应用，把模型选为本地模型，再创建一个知识库并上传团队内部文档，然后接一个外部工具，比如企业微信机器人或钉钉机器人，通过 Dify 的 API 把聊天能力暴露出去。

结构上大致是：

企业微信/钉钉机器人 ↓ Dify 应用 API ↓ Dify 工作流（召回知识库 → 组装 Prompt → 调用模型） ↓ Ollama 本地模型

这里所有敏感文档都在内网完成召回，只有模型推理发生在本地节点。对于数据敏感的内部知识场景，这个架构很有吸引力。

5.4 边界：模型能推理，不代表业务能成功

需要提醒的是，Dify 这类编排平台会放大底层模型的能力，也会放大底层模型的缺点。如果本地模型本身指令遵循能力不够稳定，把它放进一个复杂的多轮 Agent 流程里，就会出现“工作流设计得好好的，但模型就是不会按格式输出”的情况。

因此我的建议是：先拿小模型在 Dify 里做简单任务，验证基础质量，再逐步增加工具调用和知识库数量。不要一上来就把几十个工具全挂上，本地模型未必 hold 得住。

6. 实操中最容易遇到的连接问题和一条可复用的排查链路

6.1 为什么“连接不上”经常被误判

做本地模型接入时，最常见的报错无非是 Connection refused、404、401、超时、模型不存在。这些报错看起来是在不同环节出现的，但原因往往集中在几个点上。

第一个是地址问题。容器里的工具访问宿主机，用127.0.0.1大概率失败，应该用host.docker.internal或实际局域网 IP。

第二个是路径问题。有的工具要求 base_url 写到/v1，有的要求写到根地址，还有的自己会补上/chat/completions。填错一个/v1，结果就是 404。

第三个是模型名不一致。Ollama 里的模型名可能带:7b这种 tag，工具侧样本配置只写了qwen2.5，两边对不上，就会提示模型不存在。

第四个是鉴权问题。很多工具默认要求 Header 里带Authorization: Bearer xxx。你的本地服务可能不校验这个字段，但工具侧如果不带上，或者代理层要求校验而你没配置，就会报 401。

6.2 一套可复用的五步排查链路

遇到连接问题，不要直接怀疑工具不好用。我一般会按这个顺序定位：

第一步：确认本地推理服务本身正常

curl http://127.0.0.1:11434/v1/models

先确认服务在本地能访问，模型列表能返回。如果这一步都失败，问题大概率在 Ollama 本身。

第二步：确认服务监听范围和网络可达

如果本地能访问，但其他机器、容器或云端工具访问不到，就要检查是否监听了0.0.0.0、防火墙有没有放行端口、容器内部能否解析宿主机地址。可以在另一台机器上执行：

curl http://<宿主机IP>:11434/v1/models

第三步：确认代理/网关日志

如果接了 LiteLLM，看它有没有收到请求、日志里有没有转发失败。代理层通常会在日志里给出后端返回的原始错误，这是最快定位的一步。

第四步：确认工具侧请求细节

base_url、模型名、API Key、超时时间，一项一项核对。关键是用浏览器的开发者工具或代理抓包，看工具实际发出去的请求是什么样子。

第五步：确认资源限制和参数边界

如果请求发出去但长时间没返回，可能是模型正在加载，也可能是上下文太长、显存不够，或者并发数被占满。这时候再去调 OLLAMA_NUM_PARALLEL、上下文长度、超时时间这些参数。

6.3 长期运行还要注意的三件事

配置问题解决了，后面还有维护问题。最容易忽略的有三点：

第一，磁盘空间。本地模型动辄几个 GB，再叠加日志、Docker 镜像、知识库文件，磁盘很快会被吃掉。建议定期清理不用的模型版本。

第二，升级风险。Ollama、Open WebUI、Dify 这些项目迭代都很快，升级可能会导致模型列表丢失、数据结构变化或配置项不兼容。如果是长期服务，先看 Release Notes，再考虑升级。

第三，内存增长。长时间运行后，多个长对话会累积上下文，内存和显存占用会持续增长。建议定期重启服务，或者通过监控平台观察资源曲线，而不是等到服务挂掉再处理。

7. 适合谁、不适合谁、怎么选？给一张决策表

7.1 按需求选方案

如果只是一个人在自己电脑上开发，想把 CodeGeeX、Trae、Claude Code 这类工具接上本地模型，通常做到 Ollama 这一层就够了，最多再加一个 LiteLLM 做统一入口。

如果是一个几个人到几十个人的团队，需要共享本地模型能力，同时不想给每个人都讲一遍命令行，最好加 Open WebUI。

如果需要接知识库、做智能体、对外提供 API，比如企业机器人、内部客服，Dify 基本是绕不开的一层。

7.2 不适合的情况也要说清楚

这套组合并非万能。如果机器没有独立 GPU，或者只有一颗很老的 CPU，跑一个大模型会非常吃力，体验远不如直接调用云端 API。如果需求是高并发、低延迟、99.9% 可用性，单机本地模型也确实不是最优选项，至少需要多机集群、负载均衡和运维体系。

还有一种情况是，如果组织对日志审计、权限分级、数据备份有严格合规要求，开源项目默认配置通常是不够的，需要额外补一堆工程能力。这时候不能因为“本地模型安全”就假设整套系统安全，所有访问日志、模型版本、知识库变更记录都要纳入管理。

7.3 一个更底层的选型判断

顺着这几个项目往下想，你会发现一个趋势：本地模型正在从“实验玩具”变成“基础设施里的可替换计算单元”。四个开源项目之所以各有各的存在价值，是因为它们分别处理了模型运行、接口标准化、人机交互和应用编排。真正难的不是把模型下到本地，而是围绕模型搭一条稳定的服务链路。

如果你现在还在纠结选哪个，我更建议先回到实际需求：是先和现有工具打通，还是先给团队一个入口，还是要让模型进业务？选一个小范围验证，跑通之后再考虑逐步扩展。先跑通，再优化，永远比一开始就搭一个庞大的平台更稳。

本地模型的价值，不在“不联网”这个表面卖点，而在于它把 AI 能力重新拉回了你能够控制的边界里。能否和云端工具协同好，取决于你在这条边界上有没有搭对接口、留好退路。这四个开源项目，是搭好这条边界比较实用的起点。