1. 为什么要在本地跑 Qwen2：从“注册试用”到“自己掌控”
如果你最近在折腾开源大模型，大概率会反复看到同一个名字：通义千问 Qwen2。它是一套覆盖 0.5B、1.5B、7B、57B-A14B（MoE）、72B 等多个尺寸的开源模型系列，能做的事包括中文问答、代码生成、数学推理、多轮对话、长文本理解，适合谁？适合想在自己机器上跑推理、又不想被在线额度卡脖子的开发者、学生和运维同学。
我自己的场景很典型：一台 16GB 显存的开发机，平时要写脚本、查报错、做代码补全，偶尔还要跑点中文摘要。在线服务用着方便，但一旦断网、限流、或者想把公司内部文档喂进去，就得回到本地。Qwen2 本地部署这件事，核心就两条路：一条是 Ollama，一条是 Docker。前者胜在“一条命令拉模型”，后者胜在“容器化、可复现、能配可视化界面”。
这篇就按“本地部署 + 实测”的节奏走：先把 Ollama 跑通，再用 Docker 起 Open-WebUI，然后对比 Qwen1.5 和 Qwen2 的实际表现，最后给出显存占用、首 token 延迟、多轮对话稳定性的验证动作。你照着做，能在自有机器上复现完整流程。中间涉及模型下载和接口调用，我会把命令、配置、参数都写全，遇到报错也有排查章节。
需要说明的是，本地部署不等于“什么都自己扛”。如果你后面要做长期编码、Agent 调用、或者团队共享，可以考虑用 TaoToken 这类平台做统一入口，把本地模型和云端模型放在同一套调用方式里，省去反复改 Base URL 的麻烦。下面先从最轻的 Ollama 路径开始。
2. Ollama 部署 Qwen2：拉取命令、显存占用与首 token 延迟实测
Ollama 的定位很像“大模型界的 Docker”：它把模型权重、配置、运行参数打包成一个可拉取的包，你不需要手动装 CUDA、配 transformers、写推理脚本，一条ollama run就能对话。对小白来说，这是最低门槛的 Qwen2 本地部署方式。
2.1 安装 Ollama 并确认版本
macOS 和 Windows 直接去 ollama.com 下载安装包，Linux 用脚本：
curl -fsSL https://ollama.com/install.sh | sh ollama --version安装完确认服务在跑：
ollama serve如果提示端口被占用，说明后台服务已经起来了，不用重复启动。我试过在 8GB 内存的轻薄本上跑 1.5B，能跑但慢；16GB 内存 + 8GB 显存的机器跑 7B 比较舒服。
2.2 拉取 Qwen2 不同尺寸并实测资源
先拉 1.5B 做基线，再拉 7B 做主力：
ollama pull qwen2:1.5b ollama pull qwen2:7b ollama listollama list会显示模型名、大小、修改时间。实测下来，qwen2:1.5b 磁盘占用约 1GB 出头，qwen2:7b 约 4.4GB。显存占用方面，7B 在 Q4 量化下推理时大约 5–6GB，留出 1–2GB 余量比较稳。
首 token 延迟我用一个简单办法测：在对话里问“用一句话解释什么是递归”，观察从回车到第一个字出现的时间。7B 在 8GB 显存机器上大约 0.6–1.2 秒，1.5B 在 0.2–0.4 秒。这个数字受 CPU、内存带宽、是否首次加载影响很大，第一次加载会明显慢，第二次走缓存就快很多。
2.3 用 API 方式调用，而不是只在终端聊
终端对话适合试玩，真正要集成得走 HTTP 接口。Ollama 默认监听 11434：
curl http://localhost:11434/api/chat -d '{ "model": "qwen2:7b", "messages": [ {"role": "user", "content": "用 Java 写一个冒泡排序"} ], "stream": false }'返回 JSON 里的message.content就是答案。如果你要接自己的程序，把stream设为true可以逐块拿输出，做打字机效果。注意model字段必须和ollama list里的名字完全一致，写成qwen2不带 tag 有时会拉到默认 tag，容易和预期不符。
2.4 多轮对话稳定性验证
多轮对话最容易暴露上下文管理问题。我连续问了 5 轮：自我介绍、让它记住“我叫阿码”、问它我叫什么、让它用 Python 写快排、再问它我叫什么。Qwen2:7b 在第 3 轮和第 5 轮都能正确回忆名字，说明上下文窗口内记忆稳定。如果你发现它“失忆”，先检查是不是每轮都新建了会话、没把历史 messages 带上。
Ollama 路径的优点是快，缺点是可视化弱、多模型切换靠命令行。想要浏览器界面，就上 Docker + Open-WebUI。
3. Docker 部署 Open-WebUI：可复制的容器配置与模型接入
Docker 这条路适合想要“一次配置、长期使用”的人。核心是把 Open-WebUI 跑起来，让它去连本地的 Ollama，这样你在浏览器里就能切换 Qwen2 不同尺寸，还能管理对话历史。
3.1 启动 Open-WebUI 容器
先确认 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参数含义：-p 3000:8080把容器 8080 映射到本机 3000；--add-host让容器能通过host.docker.internal访问宿主机的 Ollama；-v持久化数据，删容器不丢对话；--restart always开机自启。启动后浏览器打开http://localhost:3000，首次进入先注册一个本地账号。
3.2 让 Open-WebUI 连上 Ollama
进入设置 → 连接（Connections），Ollama 的 Base URL 填：
http://host.docker.internal:11434保存后，模型下拉框里应该能看到qwen2:7b、qwen2:1.5b。如果看不到，先在宿主机执行ollama list确认模型存在，再检查容器网络。
3.3 用 settings 片段固化模型配置
如果你要把这套配置交给同事复现，建议把关键参数写成一个可复制的配置片段。Open-WebUI 支持通过环境变量指定默认模型，重新起容器时可以这样写：
{ "OLLAMA_BASE_URL": "http://host.docker.internal:11434", "DEFAULT_MODELS": "qwen2:7b", "WEBUI_AUTH": "true", "ENABLE_OPENAI_API": "true" }对应到docker run就是加-e OLLAMA_BASE_URL=... -e DEFAULT_MODELS=qwen2:7b。这样每次重建容器，默认模型和连接地址都不会丢。注意DEFAULT_MODELS的值要和ollama list里的名字一致，否则界面会显示空。
3.4 接入外部 API 时的三件套
如果你后面不想只跑本地，而是想把 Qwen2 和云端模型混用，Open-WebUI 也支持 OpenAI 兼容接口。这时要配全三件套：Base URL、API Key、Model ID。以 TaoToken 为例，Base URL 填https://taotoken.net/api，API Key 在控制台创建，Model ID 按文档里的模型名填。三件套缺一个都会报 401 或模型不存在。本地 Ollama 和云端接口可以同时存在，界面上按模型切换即可。
Docker 路径配好后，你就有了一个“本地模型 + 浏览器界面 + 可持久化”的完整环境。接下来做实测对比。
4. 实测 Qwen1.5 vs Qwen2：推理接口调用与效果对比
光跑通不算数，得看效果。我按三个维度测：中文理解、代码生成、数学推理。测试环境是 16GB 内存 + 8GB 显存，模型都用 Q4 量化。
4.1 中文理解与长文本
先问 Qwen1.5:1.8b 和 Qwen2:7b 同一个问题：“用 200 字解释什么是向量数据库，并举例说明适用场景。”Qwen1.5 的回答偏短、例子泛；Qwen2 的回答结构清晰，能提到“相似度检索”“RAG”“推荐系统”等具体场景。这不是参数量的单纯碾压，Qwen2 在中文语料和指令跟随上确实做了优化。
长文本方面，Qwen2-72B-Instruct 支持到 128K tokens，7B 版本上下文也够日常用。我贴了一段约 3000 字的技术文档让它总结，Qwen2:7b 能抓住要点，没有明显跑题。
4.2 代码生成实测
用 API 调用 Qwen2:7b 写冒泡排序：
curl http://localhost:11434/api/generate -d '{ "model": "qwen2:7b", "prompt": "用 Java 写一个冒泡排序，要求有注释和测试 main 方法", "stream": false }'返回的代码结构完整，有swap逻辑、双层循环、边界判断，注释也到位。Qwen1.5:1.8b 同样问题会漏掉部分边界条件。如果你要做代码补全，7B 是起步线，1.5B 更适合做轻量分类或摘要。
4.3 数学推理实测
经典题：“7 年前，妈妈年龄是儿子的 6 倍，儿子今年 12 岁，妈妈今年多少岁？”Qwen2:7b 能列出“7 年前儿子 5 岁，妈妈 30 岁，今年 37 岁”，步骤正确。Qwen1.5:1.8b 有时会算成 35 或 42。这说明 Qwen2 在链式推理上进步明显。
4.4 首 token 延迟与吞吐对比
同一台机器，同样问 50 字左右的问题，Qwen2:7b 首 token 约 0.8 秒，Qwen1.5:1.8b 约 0.3 秒；但 Qwen2 的回答质量高，返工少。吞吐上，7B 大约每秒 20–30 tokens，1.5B 能到 60+。如果你做实时对话，7B 完全够用；做批量离线任务，1.5B 更省资源。
实测结论：Qwen2 相比 Qwen1.5 是代际提升，尤其在中文、代码、数学三块。7B 是性价比甜点，72B 适合有 A100 或 48GB 显存的场景。
5. 常见报错排查：401、local proxy failed、reading choices、OAuth
部署过程中最容易卡在几个固定报错上，我按真实遇到的顺序列出来。
5.1 401 Unauthorized
如果你在 Open-WebUI 里接云端接口，报 401 基本是 API Key 错了或没带。检查三件套：Base URL 是否是https://taotoken.net/api，Key 是否复制完整（前后无空格），Model ID 是否在文档里存在。本地 Ollama 一般不会 401，除非你开了鉴权。
5.2 local proxy failed
这个报错通常出现在容器访问宿主机 Ollama 时。原因是容器里的localhost指向容器自己，不是宿主机。解决：Base URL 用http://host.docker.internal:11434，并且启动容器时加了--add-host=host.docker.internal:host-gateway。Linux 上如果还不行，检查防火墙是否放行 11434。
5.3 reading choices 相关报错
这类报错多出现在用 OpenAI 兼容 SDK 调本地接口时，返回结构不是标准choices数组。Ollama 的/api/chat返回的是message，不是choices。如果你用 OpenAI SDK，要改用/v1/chat/completions路径，Ollama 新版本支持这个兼容层。路径写错就会报 reading choices 为空。
5.4 OAuth 与登录问题
Open-WebUI 首次进入要注册，如果你跳过了注册直接访问，会被重定向到登录页。忘记密码可以在容器里重置，或者删掉open-webui卷重新初始化。注意：删卷会丢对话历史，操作前先备份。
5.5 模型拉取慢或失败
ollama pull卡住，先检查网络，再确认磁盘空间。7B 需要至少 5GB 空闲。如果反复失败，可以换 tag，比如qwen2:7b-instruct或指定量化版本。拉取完成后用ollama list确认，不要凭记忆写模型名。
排查的核心思路：先确认服务在跑，再确认地址对，最后确认模型名和 Key 对。三步走完，90% 的问题能定位。
6. 从本地到云端：用 TaoToken 统一 Qwen2 调用入口
本地部署跑通后，你会遇到一个新问题：机器一关，服务就没了；团队要共享，总不能每人装一遍。这时候可以把 Qwen2 的调用方式统一到云端入口，本地和云端用同一套 Base URL + Key + Model ID，切换成本最低。
具体做法：在 TaoToken 控制台创建 API Key，Base URL 用https://taotoken.net/api，Model ID 按文档填。然后在你的代码里，把原来指向localhost:11434的地方改成这个地址，请求体格式保持 OpenAI 兼容。这样你本地调试用 Ollama，上线用云端，代码几乎不用改。
如果你做长期编码或 Agent，可以看 Coding Plan，它更适合高频调用场景；如果只是想验证模型效果，用模型对话页面直接试；接入细节看接入文档，Key 管理在 API Keys 页面。这几个入口分工明确，按需选就行。
本地部署的价值在于“可控”和“可学习”，云端入口的价值在于“稳定”和“可共享”。两者不冲突，搭配用最省心。你现在就可以先把 Ollama 那条命令跑起来，再决定要不要上 Docker。
