这次我们看一个很实在的问题在 Windows 上通过 Ollama 部署本地大模型后怎么让局域网里其他电脑也能调用这台机器的模型服务。很多人第一次装完 Ollama只有本机能访问127.0.0.1:11434换一台电脑连同一个网络却怎么都连不上。原因不是模型没装好而是 Ollama 默认只监听本机回环地址不会对外提供服务。这篇文章会把 Windows 部署 Ollama、局域网访问配置、API 调用测试、批量任务串起来完整走一遍。看完之后你可以在公司内网或家庭局域网里用一台 Windows 机器作为模型服务端把 qwen、llama3 这类开源本地大模型跑起来然后让其他电脑通过 HTTP 请求访问 11434 端口来调用模型。整个过程不依赖公网数据也不需要出内网适合做团队内网 AI 工具、开发测试环境和私有化部署验证。下面直接进入正文按可执行步骤拆解安装、拉取模型、修改环境变量、放行防火墙、curl 验证、Python 批量调用、性能观察和问题排查。如果你正准备做内网模型服务这篇文章可以直接收藏。1. 核心能力速览先用一张表把 Ollama 的本地部署和局域网访问能力说清楚。能力项说明项目类型本地大模型运行时与 HTTP API 服务官方地址ollama.com支持平台Windows、macOS、Linux、Docker默认服务端口11434默认监听地址127.0.0.1仅本机可访问局域网访问方式设置OLLAMA_HOST0.0.0.0重启服务放行防火墙API 端点/api/generate、/api/chat、/api/tags等模型管理命令ollama pull、ollama list、ollama run、ollama rm批量任务可通过脚本或并发请求调用 API 实现硬件要求取决于模型大小和量化方式无独显时 CPU 也能推理适合场景内网团队协作、私有化部署、开发测试、数据不出内网从这张表能看出Ollama 的核心价值不是“能跑模型”而是“把模型包装成标准化 HTTP 服务”。一旦服务跑起来你就可以用任何语言任何工具去调它这也是局域网访问配置那么重要的原因。2. 适用场景与使用边界2.1 这个方案适合谁Ollama 局域网访问最常见的场景有这几类团队内网需要一台机器统一提供大模型推理能力其他成员通过接口调用不用每台电脑都装显卡和模型。开发测试环境程序员把 Ollama 跑在 Windows 开发机上本地联调接口再通过局域网从另一台电脑做集成测试。私有化部署验证想在公司内网做数据不出局的 AI 工具先用 Windows 加 Ollama 跑通链路后续再迁移到 Linux 或 Docker。家庭局域网多台设备共用一台高性能主机的 GPU 资源手机、笔记本也能访问模型服务。2.2 不适合什么场景对并发要求很高的生产环境。Ollama 本身不是专业的推理服务网关高并发下容易出现排队、超时和显存不足建议加负载均衡和任务队列。需要精细权限管理的公网服务。Ollama 默认没有用户认证如果直接暴露到公网任何人都能调用你的模型接口也会带来安全和成本风险。多用户隔离场景。Ollama 的模型管理和请求日志都是服务端级别的不像专业平台那样有完整的账号体系和资源隔离。2.3 安全与合规边界这里必须提醒三点。第一不要直接把 Ollama 端口暴露到公网。局域网内使用也要限制访问范围如果确实需要公网访问必须在前面加带认证的反向代理例如 Nginx 配合 Basic Auth 或 Token 校验。第二模型本身有开源许可证差异商用前要确认模型授权条款尤其注意一些模型只允许研究使用。第三本地部署虽然数据不出内网但服务端会记录请求日志和推理内容涉及个人信息、隐私数据时需要评估合规要求并保留必要审计记录。3. Windows 环境准备与前置条件3.1 操作系统与基础环境Ollama 官方明确支持 Windows 10、Windows 11 和 Windows Server 2016 以上版本。安装之前建议先确认以下条件检查项建议操作系统Windows 10 / 11尽量更新到最新补丁磁盘空间至少预留 10GB实际取决于模型数量7B 量化模型通常在 5GB 左右内存8GB 起步16GB 以上更稳妥显卡NVIDIA 显卡建议更新驱动无独显可纯 CPU 推理管理员权限安装软件和配置防火墙时需要网络能访问模型下载仓库局域网内机器需要互通需要注意Ollama 在 Windows 上默认使用本机 GPU 进行加速没有 NVIDIA 显卡时会自动退回 CPU 推理。显存占用取决于模型大小、量化精度和上下文长度具体数字需要以实际测试为准这里不写死。3.2 安装 Ollama打开 Ollama 官网下载 Windows 安装包文件名一般是OllamaSetup.exe。双击安装不需要额外配置安装完成后 Ollama 会自动在后台运行任务栏托盘会出现 Ollama 图标。安装完成后打开 PowerShell 或 CMD 验证版本ollama --version如果显示类似ollama version 0.x.x的信息说明安装成功。3.3 拉取一个本地大模型Ollama 支持很多开源模型常用的是qwen2.5和llama3.1。这里以拉取千问为例ollama pull qwen2.5:7b拉取完成后查看本机已有模型ollama list直接运行模型进行交互测试ollama run qwen2.5:7b模型下载速度受网络环境影响较大。如果下载时经常卡住或报错可以多次重试也可以换一个更小的量化模型例如qwen2.5:3b。拉取下来的模型文件默认存放在用户目录的.ollama\models下例如C:\Users\你的用户名\.ollama\models后续管理模型时可以直接查看这个目录。4. 局域网访问配置核心步骤这节是整个部署的关键。完成本节后局域网内其他机器就能通过http://服务器IP:11434访问这台 Windows 机器上的 Ollama 服务了。4.1 第一步修改 OLLAMA_HOST 环境变量Ollama 默认绑定127.0.0.1只监听本机回环地址。想让局域网内其他机器访问就要把监听地址改为0.0.0.0表示监听所有网络接口。操作方法有两种。方法一通过 Windows 系统环境变量永久修改右键“此电脑” - “属性” - “高级系统设置” - “环境变量”在“用户变量”或“系统变量”中新建变量名值OLLAMA_HOST0.0.0.0保存后需要重新启动 Ollama 才能生效。也可以在 PowerShell 中使用setx命令设置setx OLLAMA_HOST 0.0.0.0setx会永久写入用户环境变量但当前已打开的终端不会自动读取需要新开一个终端或者重启 Ollama。方法二临时设置环境变量后手动启动如果只是临时测试不希望对系统做永久修改可以在当前 PowerShell 窗口设置临时环境变量然后手动启动 Ollama$env:OLLAMA_HOST 0.0.0.0 ollama serve这种方式只对当前终端有效关闭窗口后就失效。适合临时调试。4.2 第二步重启 Ollama 服务修改环境变量后必须重启 Ollama 才能让新配置生效。Windows 上最常见的重启方式有两种。方式一右键任务栏托盘的 Ollama 图标选择退出然后从开始菜单重新打开。方式二在 PowerShell 中查看 Ollama 进程并结束再重新启动Get-Process | Where-Object { $_.ProcessName -like *ollama* } | Stop-Process ollama serve重启后Ollama 会以0.0.0.0:11434监听所有网络接口。这时在局域网内任何一台能 ping 通这台机器的主机上访问http://服务器IP:11434会看到如下内容Ollama is running如果看到这行文字说明服务已经对外可访问了。4.3 第三步放行 Windows 防火墙很多人在第一步和第二步做完后局域网还是访问不了问题往往出在 Windows 防火墙。Windows 默认会拦截入站连接即使 Ollama 监听了0.0.0.0外部请求也会被防火墙挡住。方式一控制面板操作打开“控制面板” - “Windows Defender 防火墙”。点击左侧“高级设置”。点击“入站规则”右侧选择“新建规则”。规则类型选择“端口”点击“下一步”。选择“TCP”特定本地端口填写11434。操作选择“允许连接”。配置文件建议全选“域”、“专用”、“公用”。名称填写Ollama LAN Access点击“完成”。方式二管理员命令行快速添加在管理员权限的 PowerShell 或 CMD 中执行netsh advfirewall firewall add rule nameOllama LAN Access dirin actionallow protocolTCP localport11434如果之后想删除这条规则netsh advfirewall firewall delete rule nameOllama LAN Access4.4 第四步内网其他机器验证配置完成后在一台局域网内的其他电脑上执行以下命令curl http://服务器IP:11434同样会得到Ollama is running。再进一步查看这台服务器上已安装的模型列表curl http://服务器IP:11434/api/tags返回结果是 JSON 格式里面包含模型名称、大小和修改时间。到这里局域网访问配置就算完全跑通了。5. Ollama API 调用示例Ollama 提供一组 HTTP API所有能力都可以通过接口调用。这对局域网内的其他机器尤其重要不需要在客户端安装模型只要发 HTTP 请求就能拿到推理结果。5.1 一次性生成/api/generate/api/generate适合单轮文本生成。在客户端机器上执行curl http://192.168.1.100:11434/api/generate -d {\model\: \qwen2.5:7b\, \prompt\: \用一句话介绍本地大模型\, \stream\: false}注意 Windows 的 CMD 和 PowerShell 对引号转义规则不一样为了减少麻烦更推荐写一个 Python 脚本调用。import requests url http://192.168.1.100:11434/api/generate payload { model: qwen2.5:7b, prompt: 用一句话介绍本地大模型, stream: False } response requests.post(url, jsonpayload, timeout120) data response.json() print(data[response])这里有两个关键参数。stream: false表示一次性返回完整结果避免流式输出带来的拼接处理timeout要设置得长一些因为 CPU 推理或首次加载模型时耗时可能超过 60 秒。5.2 对话模式/api/chat要用多轮对话能力可以调用/api/chat通过messages数组维护历史消息import requests url http://192.168.1.100:11434/api/chat payload { model: qwen2.5:7b, messages: [ {role: user, content: 你好请介绍一下你自己} ], stream: False } response requests.post(url, jsonpayload, timeout120) data response.json() print(data[message][content])多轮对话时只需要把上一轮的历史消息按顺序追加到messages里即可。但要注意消息越长上下文越大显存和内存占用也会增加。5.3 获取模型列表/api/tagsimport requests url http://192.168.1.100:11434/api/tags response requests.get(url, timeout30) print(response.json())返回的models数组里包含每个模型的name、size和modified_at。6. 批量任务与失败重试如果需要在局域网内批量处理文本例如批量总结文档、批量生成标题可以用 Python 写一个简单的批量任务脚本。6.1 简单循环批量请求import requests import json SERVER_URL http://192.168.1.100:11434 MODEL qwen2.5:7b text_list [ 总结这篇文章的核心观点, 把这句话翻译成英文, 给这个产品起三个宣传标语 ] for i, text in enumerate(text_list): payload { model: MODEL, prompt: text, stream: False } try: response requests.post( f{SERVER_URL}/api/generate, jsonpayload, timeout120 ) response.raise_for_status() result response.json()[response] print(f任务 {i 1} 完成{result[:50]}...) with open(output.txt, a, encodingutf-8) as f: f.write(f任务 {i 1}: {result}\n) except Exception as e: print(f任务 {i 1} 失败{e})这个脚本会把每条文本单独发给模型并把结果追加到output.txt中。这种简单的串行方式适合任务量不大的场景但要注意每次请求之间模型并不会自动清理上下文如果prompt非常长显存占用会持续累积。6.2 增加失败重试网络波动或服务端繁忙时请求可能超时。更稳妥的写法是加入重试机制import time import requests def generate_with_retry(prompt, max_retries3): url http://192.168.1.100:11434/api/generate payload { model: qwen2.5:7b, prompt: prompt, stream: False } for attempt in range(max_retries): try: response requests.post(url, jsonpayload, timeout180) response.raise_for_status() return response.json()[response] except Exception as e: print(f第 {attempt 1} 次失败{e}) if attempt max_retries - 1: time.sleep(2) return None6.3 并发控制如果任务量很大可以使用线程池限制并发数。但 Ollama 处理并发请求时会排队而且多个并发推理任务会显著增加显存占用。首次测试时建议先用max_workers1或者2确认稳定后再逐步调大。from concurrent.futures import ThreadPoolExecutor, as_completed def process_one(text): return generate_with_retry(text) with ThreadPoolExecutor(max_workers2) as executor: futures [executor.submit(process_one, text) for text in text_list] for future in as_completed(futures): print(future.result())7. 资源占用与性能观察7.1 如何观察显存和内存在 Ollama 服务端执行nvidia-smi可以看到 GPU 显存占用。启动模型推理后显存占用会明显上升。如果本机没有 NVIDIA GPUOllama 会退回到 CPU 推理此时内存占用会更高推理速度也会慢很多。更直观的方式是打开任务管理器在“性能”选项卡中观察 GPU 专用显存和内存变化。不同模型、不同量化等级、不同上下文长度的占用差异很大所以建议每次换模型后都实测一次记录下基线数据。7.2 影响性能的因素因素影响模型大小7B 模型比 3B 模型占用更大推理也更慢量化精度Q4 比 Q8 占用更低但效果可能有细微差异上下文长度num_ctx越大KV Cache 占用越大并发请求并发推理会抢占显存导致排队或 OOM网络延迟局域网内影响较小但跨交换机或无线网络时也要考虑7.3 降低资源占用的方法优先选择量化版本模型例如qwen2.5:7b-q4_K_M。在 API 请求中显式设置较小的num_ctx例如num_ctx: 2048。不要同时启动多个模型用完一个就ollama rm删除不常用的模型。批量任务控制并发数避免一次性打满显存。设置num_ctx的示例payload { model: qwen2.5:7b, prompt: 你好, stream: False, options: { num_ctx: 2048 } }8. 常见问题与排查方法以下是在 Windows 上部署 Ollama 局域网访问时踩过的高频问题整理成清单。问题现象可能原因排查方式解决方案本机能访问 Ollama局域网其他机器无法打开未修改OLLAMA_HOST服务只监听 127.0.0.1服务器执行 netstat -anofindstr 11434 查看监听地址修改环境变量后仍然不通修改后没有重启 Ollama 服务右键托盘退出 Ollama 再重新启动重新启动 Ollama 或ollama serve手动启动局域网访问被拒绝Windows 防火墙拦截了 11434 端口检查防火墙入站规则确认规则已添加添加 TCP 11434 入站允许规则模型拉取卡住或超时网络到模型仓库不稳定多次重试或更换更小模型使用ollama pull重试或换3b等更小模型启动 Ollama 后端口被占用11434 被其他程序占用netstat -anofindstr 11434 查看占用的 PIDollama run显存不足模型超过本机显存或内存观察nvidia-smi和任务管理器换更小模型、启用量化版本、减小num_ctxGPU 不参与推理NVIDIA 驱动过旧或检测失败执行nvidia-smi检查驱动更新到最新 NVIDIA 驱动环境变量OLLAMA_HOST不生效setx设置了但当前终端未重新加载新开 PowerShell 窗口再验证重启 Ollama 或注销重登8.1 验证监听地址在服务器上执行netstat -ano | findstr 11434输出的监听地址如果是0.0.0.0:11434说明服务已经监听所有接口如果是127.0.0.1:11434说明OLLAMA_HOST没有生效回到 4.1 节重新检查。8.2 验证防火墙规则在服务器上查看规则netsh advfirewall firewall show rule nameOllama LAN Access如果没有输出说明规则不存在重新添加即可。8.3 API 调用失败如果局域网内其他机器调用 API 时报ConnectionError或Timeout优先从三个方向排查服务器 IP 是否正确用ping 服务器IP测试。端口是否可达用Test-NetConnection 服务器IP -Port 11434测试。请求体是否符合格式先放一个最简单的/api/tagsGET 请求确认服务可用后再测试生成请求。Test-NetConnection 192.168.1.100 -Port 114349. 最佳实践与合规使用建议9.1 服务端管理建议第一次先跑小参数模型例如qwen2.5:3b确认功能和网络都正常后再切换到大模型。把模型文件、拉取日志、API 输出分目录管理方便排查问题。定期使用ollama list检查模型占用空间删除不再使用的模型。保持 Ollama 更新到新版本官方会修复稳定性问题和新显卡兼容性问题。9.2 局域网安全建议只在内网可信环境使用不要直接将 11434 端口映射到公网。如果有跨部门或多团队使用需求建议在 Ollama 前面加一层网关做访问控制和请求审计。从其他机器调用时使用服务端 IP 而不是主机名避免 DNS 解析问题。开启 Windows 防火墙时只放行必要来源 IP可以进一步提高安全性。9.3 批量任务工程化建议每次批量请求都记录请求时间、模型、输入输出长度和耗时方便定位慢请求。任务失败时要有重试机制重试间隔建议逐步增大避免打爆服务端。批量任务使用独立的输出文件避免多个任务写同一个文件造成内容覆盖。调用接口前先确认模型已经拉取到本机避免第一次请求时触发模型加载导致超时。9.4 合规使用提醒本地部署大模型不等于可以任意使用。商用场景下需要确认模型的开源协议是否允许商用例如某些模型只允许研究用途直接集成到内部工具中可能构成合规风险。另外Ollama 服务端日志会记录请求内容如果处理的是个人隐私数据或业务敏感信息建议明确日志保存策略并控制访问人群。10. 总结与下一步Ollama 局域网访问配置本身并不复杂核心就两步把OLLAMA_HOST改成0.0.0.0再放行防火墙 11434 端口。但很多人的问题恰恰出在这两步的细微之处环境变量改完没有重启服务或者防火墙入站规则没有添加。另外模型拉取慢、显存不足、端口被占用这些痛点在实际部署中出现的频率也很高。这篇文章最值得先验证的部分是 4.4 节的/api/tags请求。只要这个请求能从局域网内另一台机器返回模型列表说明整个服务链路已经通了。之后再把/api/chat和批量任务脚本跑起来就可以把 Ollama 接到自己的内网工具里。下一步可以考虑的扩展方向在局域网服务器上部署 Open WebUI给 Ollama 加一个可视化界面团队成员可以直接通过浏览器对话。将 Ollama 接入 Dify、FastGPT 等开源应用框架做知识库问答或工作流编排。用 Docker 在 Linux 服务器上部署 Ollama配置更灵活也更容易做资源限制。在 Ollama 前面加 Nginx 反向代理实现带认证的访问方式为将来可能的跨网络访问打好基础。建议收藏备用。