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 running3.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-webui4.2 问题二：模型响应慢或超时
优化建议：
- 使用量化版本（GGUF-Q4）降低显存占用
- 在
vLLM启动参数中启用连续批处理（continuous batching） - 若使用 CPU 推理，建议开启 llama.cpp 并绑定线程数
示例优化参数：
--max-model-len 4096 \ --gpu-memory-utilization 0.9 \ --tensor-parallel-size 14.3 问题三：如何关闭 Jupyter 自动启动？
若不需要 Jupyter 服务，可在docker-compose.yml中注释或删除相关 service：
# jupyter: # image: ... # ports: # - "8888:8888" # command: ["jupyter-lab", ...]然后重新构建：
docker-compose up -d --force-recreate5. 总结
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 助手”。
获取更多AI镜像
想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。
