DeepSeek-R1-Distill-Qwen-1.5B部署疑问：jupyter服务切换指南-编程阁

DeepSeek-R1-Distill-Qwen-1.5B部署疑问：Jupyter服务切换指南

1. 背景与问题提出

在本地部署轻量级大模型的实践中，DeepSeek-R1-Distill-Qwen-1.5B因其“小钢炮”特性迅速成为开发者和边缘计算场景下的热门选择。该模型通过蒸馏技术，在仅1.5B参数规模下实现了接近7B级别模型的推理能力，尤其在数学和代码任务中表现突出（MATH 80+，HumanEval 50+），同时支持函数调用、Agent插件等高级功能。

然而，在使用vLLM + Open-WebUI构建本地对话应用时，部分用户反馈：启动服务后默认进入的是 Jupyter Notebook 环境，而非预期的 Open-WebUI 对话界面。本文将围绕这一常见部署疑问，详细解析服务架构原理，并提供从 Jupyter 到 WebUI 的正确访问方式及端口切换指南。

2. 技术方案选型与系统架构

2.1 为什么选择 vLLM + Open-WebUI 组合？

为了充分发挥 DeepSeek-R1-Distill-Qwen-1.5B 的性能优势并实现友好的交互体验，推荐采用以下技术栈组合：

组件	作用	优势
vLLM	模型推理后端	高吞吐、低延迟，支持 PagedAttention，适合小模型高速推理
Open-WebUI	前端对话界面	支持多模态交互、历史会话管理、函数调用可视化
Docker Compose	服务编排	一键启动多个容器，简化部署流程

该架构允许用户通过浏览器直接与模型交互，无需编写代码即可完成提问、调试 Agent 插件等操作。

2.2 默认启动为何跳转至 Jupyter？

许多镜像（如 CSDN 星图镜像）为方便调试，默认集成了 JupyterLab 环境。其启动逻辑如下：

services: jupyter: image: deepseek-r1-distill-qwen-1.5b ports: - "8888:8888" command: ["jupyter-lab", "--ip=0.0.0.0", "--no-browser", "--allow-root"] vllm: image: deepseek-r1-distill-qwen-1.5b ports: - "8000:8000" command: ["python", "-m", "vllm.entrypoints.openai.api_server", ...] open-webui: image: ghcr.io/open-webui/open-webui:main ports: - "7860:7860" depends_on: - vllm

因此，当用户访问http://<ip>:8888时，实际进入的是 Jupyter 服务；而 Open-WebUI 运行在7860端口，需手动切换 URL 才能访问。

3. 实现步骤详解

3.1 启动模型与服务

假设已拉取包含 vLLM、Open-WebUI 和 Jupyter 的一体化镜像，执行启动命令：

docker-compose up -d

等待约 2–5 分钟，直到所有服务状态为running：

docker-compose ps

输出应类似：

NAME COMMAND SERVICE STATUS jupyter-container "jupyter-lab ..." jupyter running vllm-server "python -m vllm..." vllm running webui-container "/app/backend/entry..." open-webui running

3.2 访问 Open-WebUI 而非 Jupyter

❌ 错误做法：直接访问 8888 端口

若浏览器输入：

http://localhost:8888

将进入 JupyterLab 界面，显示为开发调试环境，无法进行自然对话。

✅ 正确做法：切换至 7860 端口

请修改 URL 为：

http://localhost:7860

此时将加载 Open-WebUI 页面，出现登录/注册界面。

核心提示：Jupyter（8888）是开发入口，Open-WebUI（7860）是用户体验入口。两者共存但职责分离。

3.3 登录账号与初始化设置

根据提供的演示信息：

账号：kakajiang@kakajiang.com
密码：kakajiang

首次登录后建议立即修改密码以保障安全。进入主界面后，确认模型连接状态正常（通常自动识别http://vllm:8000/v1作为 API 地址）。

3.4 验证模型能力：一次完整对话测试

在 Open-WebUI 中输入以下问题：

请解方程：x^2 - 5x + 6 = 0，并用 JSON 格式返回结果。

预期输出示例：

{ "roots": [2, 3], "discriminant": 1, "steps": [ "判别式 Δ = b² - 4ac = 25 - 24 = 1", "根公式 x = (5 ± √1) / 2", "得 x₁ = 3, x₂ = 2" ] }

此测试验证了模型的数学推理、结构化输出（JSON）和思维链保留能力。

4. 常见问题与优化建议

4.1 问题一：7860 端口无法访问

可能原因：

容器未完全启动
防火墙或云服务器安全组未开放 7860 端口
Docker 网络配置错误

解决方案：

# 查看 open-webui 容器日志 docker logs webui-container # 检查端口绑定情况 docker port webui-container # 手动重启服务 docker-compose restart open-webui

4.2 问题二：模型响应慢或超时

优化建议：

使用量化版本（GGUF-Q4）降低显存占用
在vLLM启动参数中启用连续批处理（continuous batching）
若使用 CPU 推理，建议开启 llama.cpp 并绑定线程数

示例优化参数：

--max-model-len 4096 \ --gpu-memory-utilization 0.9 \ --tensor-parallel-size 1

4.3 问题三：如何关闭 Jupyter 自动启动？

若不需要 Jupyter 服务，可在docker-compose.yml中注释或删除相关 service：

# jupyter: # image: ... # ports: # - "8888:8888" # command: ["jupyter-lab", ...]

然后重新构建：

docker-compose up -d --force-recreate

5. 总结

本文针对DeepSeek-R1-Distill-Qwen-1.5B在vLLM + Open-WebUI部署过程中常见的“误入 Jupyter”问题进行了系统性解析。关键结论如下：

服务分离设计：Jupyter（8888）用于开发调试，Open-WebUI（7860）用于对话交互，二者运行于不同端口。
正确访问路径：应通过http://<ip>:7860进入对话界面，而非默认的 8888 端口。
一键部署优势：得益于 Apache 2.0 协议和主流框架集成（vLLM/Ollama），该模型可实现“6GB 显存跑满速、手机树莓派可用”的极简部署目标。
工程实践建议：生产环境中建议禁用 Jupyter 服务，减少攻击面，提升安全性。

对于仅有 4GB 显存设备的用户，推荐使用 GGUF-Q4 量化版本配合 llama.cpp 或 Jan 推理引擎，仍可实现每秒百 token 以上的生成速度，真正实现“零门槛本地 AI 助手”。