作者展示如何在单台本地服务器上通过Ollama运行Qwen 2.5模型，为六个应用提供AI服务并实现零API费用

架构概览与成本对比

这台服务器运行着六个使用AI的应用，所有请求均指向本地端口11434，由Ollama服务统一处理。模型为Qwen 2.5 7B，部署在RTX 3060显卡上。硬件配置包括Ryzen 7 5700G处理器、12GB显存的RTX 3060显卡、64GB DDR4内存和2TB NVMe固态硬盘，系统为Ubuntu 24.04。12GB的显存容量是能够容纳该模型的关键因素。在空闲状态下，整机功耗仅为28瓦。Ollama本质上是一个HTTP服务器，接收请求后将模型加载至GPU生成Token，并以JSON流形式返回。其官方安装脚本会自动检测Nvidia驱动并创建系统用户，从运行脚本到获得首次回复仅耗时3分钟。

"Every line a 200 answered in 2.31, 2.1, and 1.84 seconds."（每一行都是状态码200，响应时间在1.84到2.31秒之间。）

在成本方面，此前使用云端AI服务的月费用高达47美元（包括n8n、Open Web UI等项目的分摊），年支出为564美元。切换到本地部署后，API费用降为零。唯一新增的成本是电力消耗：额外34瓦的功耗在730小时内产生24.8千瓦时电量，按每千瓦时16美分计算，月电费仅为3.97美元。这使得月度支出削减了92%。整个架构极其简洁：六个应用共享一个模型、一个端口，故障排查只需关注一处。

网络配置与Docker连通性修复

Ollama默认绑定在127.0.0.1（仅本地回环），这导致Docker容器内的应用无法访问。默认配置下，Ollama没有认证机制，也不使用TLS加密，仅通过纯JSON通信。在初始测试中，运行在主网络模式下的Home Assistant能成功连接localhost:11434，但其余五个运行在Docker桥接网络上的应用（Open Web UI, n8n, Paperless AI等）均因连接被拒绝而失败。

"Inside the N8N container, local host is its own loopback. Nothing listens on 11434 there."（在N8N容器内，localhost指向其自身的回环地址，那里没有任何服务监听11434端口。）

修复方法是通过systemd覆盖配置，将Ollama监听地址改为0.0.0.0。执行sudo systemctl edit ollama并在服务部分添加一行配置，随后重载并重启Ollama。使用ss | grep 11434验证，端口从仅监听127.0.0.1变为监听所有接口（显示为）。防火墙成为事实上的API密钥，仅允许Docker子网(172.16/12)和家庭局域网(192.168.1/24)访问，路由器不转发任何外部流量。应用连接地址分为三种情况：主网络应用使用localhost；桥接Docker容器使用172.17.0.1（即docker0网关）；外部机器通过主机IP 192.168.1.20访问。切记在Docker内部不要使用localhost*。

模型选择与性能基准测试

作者选择了Qwen 2.5 7B作为核心模型，该版本量化为Q4KM格式，占用磁盘空间4.7GB，拥有76亿参数和32,768的原生上下文窗口。该模型支持工具调用并能返回干净的JSON格式，且能完整装入12GB显存。在速度测试中，Qwen 2.5 7B达到每秒58个Token。为了评估不同模型的表现，作者进行了对比测试：

"On valid JSON, Qwen led with 98%, Gemma 94, Llama 90, and Mistral just 82%."（在JSON格式有效性上，Qwen以98%领先，Gemma为94%，Llama为90%，而Mistral仅为82%。）

测试使用了相同的50份Paperless文档。尽管Mistral速度最快，但Qwen在生成有效JSON方面的准确率最高，这对于自动化工作流至关重要。作者还指出版本命名细节：使用Qwen 2.5标签可匹配最新7B模型，而尝试拉取不存在的14B版本会返回404错误。建议直接从Ollama list复制模型名称，避免手动输入出错。

六大应用的具体集成案例

六个应用在配置上均指向172.17.0.1:11434（Docker桥接地址）或localhost:11434，且无需设置API Key（或填入任意非空字符如"Ollama"）。以下是各应用的具体表现：

1. Open Web UI：设置Base URL为http://172.17.0.1:11434，OpenAI Key留空。首次加载即识别出Qwen 2.5模型，浏览器聊天流式响应正常。
2. n8n：通过Webhook触发AI Agent，使用Ollama Chat Model节点将结果发送至Slack。每日340次工作流运行完全免费。
3. Home Assistant：使用Ollama集成，开启Assist API。从唤醒词到语音回答仅需1.9秒，比云端API的2.6秒更快。配置为localhost:11434。
4. Paperless AI：扫描文档后，OCR文本发送至Qwen进行标签和标题生成。每日处理410个请求，全部本地完成。
5. Care Key：用于书签标签和摘要生成。每日处理860个请求，利用上下文长度优势进行自动标记。
6. Mealie：仅支持OpenAI兼容接口。Base URL指向/v1/chat/completions路径，API Key填入"Ollama"（仅作占位符），模型设为Qwen 2.5。成功本地解析并导入212个食谱。

"The only new cost is power... That cuts my monthly cost by 92%."（唯一的新增成本是电力……这使得我的月度支出削减了92%。）

所有应用均通过journalctl -u ollama实时查看日志，确认请求状态。这种架构不仅消除了云端API费用，还通过本地化处理提升了响应速度，特别是对于Home Assistant等对延迟敏感的应用。

Open Web UI 等应用的本地请求与上下文窗口陷阱

作者服务器上的多个应用，包括 Open Web UI、Karabiner 和 Mealie，其请求量分别为 205、120 和 47。这些应用的 所有请求均保留在本机，未发送至外部云端 API。

然而，默认配置存在严重隐患。Ollama 的 上下文窗口默认为 4,096 tokens，而作者处理 Paperless 文档的平均提示词长度高达 9,800 tokens，远超默认限制。当输入超出窗口时，系统不会报错或警告，而是静默丢弃提示词顶部的内容。这导致 Paperless 的标签提取准确率从 4K 上下文下的 61% 暴跌。唯一的线索是 Ollama 日志中的一条警告：truncating input prompt limit 4,096 prompt 9,812 keep four。将上下文提升至 16K 后，标签准确率恢复至 94%。

"Correct tags went from 61% at 4K context to 94% at 16K."

全局上下文配置与显存开销分析

为解决上述问题，作者在 systemd service 文件中添加了第二行配置，将 上下文长度变量设置为 16,384，并绑定 Ollama host 为 0.0.0.0。这一设置对所有应用和调用生效，但需注意 每个请求的 num_ctx 参数优先级更高，因此仍需检查应用设置或通过模型文件固化配置。例如，基于 Qwen 2.57B 创建名为 "Qwen 16K" 的模型变体，添加 num_ctx = 16,384。该操作 不增加磁盘占用，因为共享同一权重文件。

上下文扩展并非没有代价。显存使用量随窗口增大而显著上升：

在作者的 12GB VRAM 显卡上，16K 上下文占用 55%（即 6.6 GB），剩余 5.4 GB 用于并行请求。测试显示，Qwen 2.57B 在 16K 上下文下占用 6.6 GB，且 GPU 利用率达到 100%，无数据溢出至 CPU。此外，默认情况下 Ollama 会在 5分钟空闲后卸载模型，冷启动耗时 6.8秒，而热加载仅需 0.4秒。因此作者将 keep alive 设置为 24小时，以牺牲少量显存换取响应速度。

并发性能、功耗与故障排查经验

在高负载下，Ollama 队列可容纳多达 512个请求，分配给 GPU 上的两个并行槽位。实测数据显示：

峰值时 GPU 利用率达 91%。功耗方面，待机为 28W，加载模型后升至 39W，生成时达 165W。24小时平均额外功耗为 34W，月耗电约 24.8 kWh（成本约 $4）。

作者分享了三个耗时三小时的错误：1) 模型标签拼写错误导致 N8N 报 404；2) 直接编辑 unit 文件被更新覆盖导致应用失效；3) 信任默认上下文导致 Paperless 标签错误持续一周。排查口诀为：连接拒绝查 0.0.0.0，模型未找到拉取正确标签，忽略长输入则提高 num_ctx。日志查看命令为 journalctl on the Ollama unit。

成本对比与本地部署的局限性

从经济角度分析，12个月云端 API 费用为 $564。本地部署初始成本为一块二手 RTX 3060（240W，假设购入价 $150-200 区间，文中未明确硬件单价仅提及功耗与电费对比逻辑）加上首年电费 $48，总计约 $288（注：原文表述为 "used RTX 3060 at 240 W, plus 48 in power, so 288 in year one"，暗示硬件+电费总和或特定计算方式）。第二年本地成本降至仅 $48（纯电费），而云端仍为 $564。显卡在 6个月内回本。

尽管本地化解决了 95% 的日常需求（如税务表格、银行 PDF、语音命令等隐私数据），但在 长多步推理（如大型代码重构）和 超过 16K tokens 的文档处理上，7B 模型仍会漂移。对于这些场景，作者仍需手动使用云端模型。

"Local handles the boring 95% and that was the expensive 95%."

最终部署步骤包括：安装 Ollama，拉取 Qwen 2.57B，设置 host 为 0.0.0.0，上下文设为 16,384，并通过防火墙限制 LAN 和 Docker（172.17.0.1:11434）访问。整个设置仅需 20分钟，实现真正的零账单 AI 服务。

结论

本地部署 Ollama 配合 Qwen 2.5 7B 模型，成功实现了六大应用零 API 账单运行。该架构通过牺牲少量电力成本（月增约4美元），将月度支出削减92%，并在Home Assistant等场景下实现比云端更快的响应速度。核心优势在于隐私保护、成本可控及对95%日常自动化任务（如文档标签、食谱解析）的高效处理。然而，其局限性在于7B模型在处理长多步推理及超16K上下文文档时易出现逻辑漂移，仍需依赖云端补充。此外，该方案高度依赖12GB显存硬件及精细的系统配置（如防火墙规则与上下文参数调整），适合具备一定技术能力且追求极致性价比的本地化部署用户。