本地快速私有化部署和运行大语言模型：用 Ollama + WSL 把模型跑起来

1. 为什么 Windows 用户需要 WSL + Ollama 做本地大语言模型私有化部署

如果你手头是一台 Windows 笔记本或者台式机，想跑一个自己的大语言模型，第一反应可能是「装个 Docker 或者直接下个 exe」。但真上手就会发现，很多 LLM 工具链、推理框架、Python 依赖在 Windows 原生环境下会碰到路径、编译、CUDA 版本对不上的问题。我试过在纯 Windows 下折腾，光是一个依赖编译就能耗掉半天。

WSL（Windows Subsystem for Linux）解决的正是这个痛点：它让你在 Windows 里直接跑一个完整的 Linux 内核子系统，文件系统互通、命令行原生、GPU 也能透传。而 Ollama 是目前把「拉模型 + 跑推理 + 开 API」这三件事做得最省心的开源工具之一，一条命令拉模型，一条命令起服务，还自带兼容 OpenAI 风格的接口。

这套组合适合谁？三类人最合适：一是想验证自己业务数据不出内网的开发者；二是想低成本试玩各种开源模型（Llama、Qwen、DeepSeek 等）的技术爱好者；三是需要给团队搭一个内网可访问的推理服务、但又不想买云 GPU 的工程师。核心检索词就三个：Ollama、大语言模型、私有化部署，加上 WSL 这个 Windows 侧的入口。

整篇文章我会按「环境准备 → 装 Ollama → 拉模型 → 起服务 → 调接口 → 排错」的顺序走一遍，每一步都给可复制的命令和配置片段。最后还会讲一下怎么用统一的 Key/API 通道把本地服务和外部调用串起来，方便你在多个模型之间切换。

先说清楚一个前提：本地跑模型吃的是你机器的内存和显存。7B 参数量的模型至少需要 8GB 内存，13B 要 16GB，33B 要 32GB。这个数字是硬门槛，选模型之前先看一眼自己机器的配置，别拉了一个 30GB 的模型结果跑不动。

2. WSL 环境准备与 Ollama 安装：从零到能敲命令

2.1 安装 WSL 并确认版本

Windows 10 版本 2004 及以上、或者 Windows 11，都内置了 WSL 的安装能力。以管理员身份打开 PowerShell，执行：

wsl --install

这条命令会默认装好 WSL2 和一个 Ubuntu 发行版。装完重启一次机器。重启后打开 Ubuntu，第一次会让你设置 Linux 用户名和密码，设好之后就是一个完整的 Linux 终端了。

确认一下版本，必须是 WSL2，WSL1 不支持 GPU 透传：

wsl --list --verbose

输出里 VERSION 那一列应该是 2。如果是 1，执行wsl --set-version Ubuntu 2转换。

2.2 在 WSL 里安装 Ollama

进入 Ubuntu 终端，直接跑官方安装脚本：

curl -fsSL https://ollama.com/install.sh | sh

这个脚本会自动检测架构、下载对应二进制、配置 systemd 服务。装完之后验证一下：

ollama -h

你会看到类似这样的命令列表：

Usage: ollama [flags] ollama [command] Available Commands: serve Start ollama create Create a model from a Modelfile show Show information for a model run Run a model pull Pull a model from a registry push Push a model to a registry list List models cp Copy a model rm Remove a model help Help about any command

看到serve、run、pull、list、rm这几个就说明装好了。这里有个细节：安装脚本默认会把 Ollama 注册成 systemd 服务并自动启动，所以很多时候你不需要手动ollama serve。可以用下面这条确认服务状态：

systemctl status ollama

如果显示 active (running)，那服务已经在后台跑着了，直接跳到拉模型那一步。

2.3 手动启动服务的场景

有些环境（比如容器里、或者 systemd 没启用）需要手动起服务。开一个终端窗口执行：

ollama serve

第一次启动会生成密钥文件，输出类似：

Couldn't find '/home/yourname/.ollama/id_ed25519'. Generating new private key.

这是正常的，它在生成用于签名请求的密钥对。服务默认监听127.0.0.1:11434。注意这个窗口要保持开着，后面的操作在另一个终端窗口做。

如果你希望局域网内其他机器也能访问这个服务，需要设置环境变量再启动：

export OLLAMA_HOST=0.0.0.0:11434 ollama serve

这一步做完，环境就算齐了。接下来是拉模型。

3. 拉取模型与可复制配置片段：Ollama 参数怎么调

3.1 选模型和拉模型

Ollama 的模型库在 https://ollama.com/library，里面按参数量、用途分类。拉模型就一条命令，以 Qwen2.5 的 7B 版本为例：

ollama pull qwen2.5:7b

下载过程会显示每一层的进度条，模型文件存在~/.ollama/models下。拉完之后用ollama list看本地有哪些模型：

ollama list

输出类似：

NAME ID SIZE MODIFIED qwen2.5:7b 845dbda0ea48 4.7 GB 2 minutes ago

3.2 用 Modelfile 定制模型参数

Ollama 支持通过 Modelfile 定制系统提示词、温度、上下文长度等。新建一个文件叫Modelfile：

FROM qwen2.5:7b PARAMETER temperature 0.7 PARAMETER top_p 0.9 PARAMETER num_ctx 8192 SYSTEM """ 你是一个严谨的技术助手，回答问题时先给结论，再给步骤。 """

然后基于这个文件创建一个新模型：

ollama create my-qwen -f Modelfile

之后就可以用ollama run my-qwen跑这个定制版本了。num_ctx这个参数特别值得调，默认上下文窗口比较小，处理长文档时容易截断，调到 8192 或更高会舒服很多，代价是吃更多内存。

3.3 服务端配置片段

如果你想让 Ollama 常驻并对外提供 API，建议写一个 systemd override 来固定环境变量。创建目录和文件：

sudo mkdir -p /etc/systemd/system/ollama.service.d sudo tee /etc/systemd/system/ollama.service.d/override.conf <<'EOF' [Service] Environment="OLLAMA_HOST=0.0.0.0:11434" Environment="OLLAMA_KEEP_ALIVE=24h" Environment="OLLAMA_NUM_PARALLEL=2" EOF

OLLAMA_KEEP_ALIVE=24h让模型常驻内存，避免每次请求都重新加载；OLLAMA_NUM_PARALLEL=2允许两个并发请求。改完重载：

sudo systemctl daemon-reload sudo systemctl restart ollama

3.4 用统一 Key/API 通道对接本地服务

本地服务跑起来之后，如果你有多个模型来源（本地 Ollama、云端模型、其他推理服务），一个个改 Base URL 和 Key 很麻烦。这时候可以用一个统一的 API 通道来收敛配置。TaoToken 提供的就是这种统一入口，官网在 https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= ，API 端点是 https://taotoken.net/api 。

它的思路是：你只维护一份 Base URL 和 Key，模型 ID 作为参数传进去，后端帮你路由到对应的模型。对于本地 Ollama，你可以把它当成一个「模型提供方」注册进去，这样代码里就不用写死http://localhost:11434。

具体操作是先去控制台拿 Key，地址是 https://taotoken.net/console?utm_source=taotoken_aicg_blog_end&utm_content=console&utm_campaign=rewrite ，然后在 API Keys 页面创建密钥： https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=api-keys&utm_campaign=rewrite 。拿到 Key 之后，配置就统一成三个要素：Base URL、Key、Model ID。这三件套在后面的验证步骤里会反复用到。

4. 验证请求与成功结果：一次对话确认部署成功

4.1 命令行直接对话

最直接的验证方式是用ollama run：

ollama run qwen2.5:7b

进入交互界面后输入一句话：

>>> 用一句话解释什么是私有化部署

模型返回内容就说明推理链路通了。输入/bye退出。

4.2 用 curl 调 REST 接口

Ollama 原生接口是/api/generate：

curl http://localhost:11434/api/generate -d '{ "model": "qwen2.5:7b", "prompt": "写一个 Python 快速排序函数", "stream": false }'

返回的 JSON 里response字段就是模型输出。如果返回{"error":"model not found"}，说明模型名写错了，用ollama list核对。

4.3 用 OpenAI 兼容接口调用

Ollama 也提供/v1/chat/completions兼容端点，这意味着你可以直接用 OpenAI SDK：

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": "你好，做个自我介绍"}] ) print(resp.choices[0].message.content)

注意api_key这里随便填一个非空字符串就行，Ollama 本地不校验。

4.4 通过统一通道调用

如果你已经把本地服务注册到统一通道，代码就变成：

from openai import OpenAI client = OpenAI( base_url="https://taotoken.net/api", api_key="你的Key" ) resp = client.chat.completions.create( model="你的模型ID", messages=[{"role": "user", "content": "验证一下通道是否正常"}] ) print(resp.choices[0].message.content)

能正常打印出内容，就说明从本地模型到统一通道的整条链路都通了。想先在网页上试一下模型对话效果，可以打开 https://taotoken.net/model-chat?utm_source=taotoken_aicg_blog_end&utm_content=model-chat&utm_campaign=rewrite ，选好模型直接发消息，不用写代码就能验证。

5. 本篇常见错误排查：401、local proxy failed、reading choices 怎么解

5.1 401 Unauthorized

这个报错基本都出在 Key 上。三种可能：Key 没填、Key 填错、Key 对应的权限不对。检查顺序是：先确认api_key字段不是空字符串；再确认 Key 没有多余空格；最后去控制台看这个 Key 是否被禁用或过期。如果是走统一通道，注意 Base URL 必须是https://taotoken.net/api，不要带多余的路径后缀。

5.2 local proxy failed / connection refused

这个报错说明客户端连不上服务端。分两种情况：

第一种，本地 Ollama 没起来。执行systemctl status ollama或curl http://localhost:11434确认。如果服务没跑，ollama serve起一下。

第二种，WSL 的网络和 Windows 主机隔离。WSL2 默认是 NAT 网络，Windows 侧访问 WSL 里的服务需要用 WSL 的 IP，而不是 localhost。查 IP：

ip addr show eth0 | grep inet

拿到类似172.x.x.x的地址，用这个地址替换 localhost。或者更省事的办法是在 Windows 侧配置端口转发：

netsh interface portproxy add v4tov4 listenport=11434 listenaddress=0.0.0.0 connectport=11434 connectaddress=172.x.x.x

5.3 reading choices 报错 / 返回结构解析失败

这个通常出现在用 OpenAI SDK 调非标准端点时。报错信息类似KeyError: 'choices'或reading 'choices'。原因是返回的 JSON 结构里没有choices字段，说明请求根本没走到 chat completions 端点，或者服务返回了错误信息但被当成正常响应解析了。

排查方法：先用 curl 直接打一次，看原始返回：

curl https://taotoken.net/api/v1/chat/completions \ -H "Authorization: Bearer 你的Key" \ -H "Content-Type: application/json" \ -d '{"model":"你的模型ID","messages":[{"role":"user","content":"test"}]}'

如果返回的是{"error":...}，那就是模型 ID 或 Key 的问题；如果返回正常结构，那就是 SDK 的 base_url 配置少了/v1或者多了路径。

5.4 OAuth / 认证相关报错

有些工具（比如 Claude Code、Codex 这类 CLI）走的是 OAuth 流程，配置方式和普通 API Key 不一样。如果你在配置这类工具时遇到认证失败，需要确认三件套是否齐全：Base URL、Key、Model ID。以 Claude Code 为例，它需要设置ANTHROPIC_BASE_URL和ANTHROPIC_API_KEY两个环境变量，模型 ID 通过启动参数指定。缺任何一个都会报认证错误。具体的接入文档在 https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_content=doc&utm_campaign=rewrite ，里面有各工具的完整配置示例。

5.5 模型加载慢或 OOM

如果ollama run卡在 loading 很久，或者直接进程被杀，基本是内存不够。用free -h看可用内存，用nvidia-smi看显存。7B 模型量化后大约 4-5GB，加上上下文开销，8GB 内存是底线。内存不够就换更小的模型，比如 3B 或者 1.5B 的版本。

6. 长期编码与 Agent 场景：把本地模型接进工作流

本地模型跑通之后，最有价值的用法是把它接进日常编码和 Agent 工作流。比如你在用 Cline、Continue 这类 VS Code 插件，它们都支持自定义 OpenAI 兼容端点，把 Base URL 指向http://localhost:11434/v1，模型填qwen2.5:7b，就能用本地模型做代码补全和对话，数据完全不出本机。

如果你需要更强的模型能力，又不想每次都手动切换配置，可以用 Coding Plan 来管理多个模型来源。地址是 https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_content=coding-plan&utm_campaign=rewrite ，它把本地模型和云端模型的调用统一到一套配置里，切换模型只改一个 Model ID 参数。

对于 Agent 类应用（比如需要多轮工具调用的场景），本地 7B 模型在复杂推理上会吃力，建议用本地模型做简单任务、云端模型做复杂任务，通过统一通道按需路由。这样既保证了敏感数据的本地处理，又能在需要时调用更强的模型。

最后给一个实用技巧：把常用的 Ollama 命令做成 alias 写进~/.bashrc，比如：

alias ol='ollama list' alias orun='ollama run qwen2.5:7b' alias oserve='OLLAMA_HOST=0.0.0.0:11434 ollama serve'

这样每次开终端就能快速操作，省去记长命令的麻烦。本地部署这件事，跑起来只是第一步，把它变成日常工具才算真正落地。