济南做网站多钱,北风淘淘网站开发,广告公司管理软件,温州移动网站建设服务商Qwen3-0.6B部署后无法访问#xff1f;检查端口和base_url配置 1. 问题现象#xff1a;服务启动了#xff0c;但调用失败 你兴冲冲地用 vLLM 启动了 Qwen3-0.6B#xff0c;终端里显示 INFO: Uvicorn running on http://0.0.0.0:8000#xff0c;一切看起来都很顺利。可当你…Qwen3-0.6B部署后无法访问检查端口和base_url配置1. 问题现象服务启动了但调用失败你兴冲冲地用 vLLM 启动了 Qwen3-0.6B终端里显示INFO: Uvicorn running on http://0.0.0.0:8000一切看起来都很顺利。可当你在 Jupyter 里运行 LangChain 调用代码或者用 curl 发送请求时却收到一串冰冷的报错ConnectionRefusedError: [Errno 111] Connection refusedrequests.exceptions.ConnectionError: HTTPConnectionPool(hostlocalhost, port8000): Max retries exceeded...或者更隐蔽的返回404 Not Found提示模型不存在别急着重装、别急着怀疑显卡——90% 的情况问题根本不在模型本身而在于两个最基础、却最容易被忽略的配置项端口Port和base_url基础地址。这篇文章不讲大道理不堆参数就聚焦一个目标帮你快速定位、一步解决“服务明明跑着却怎么都连不上”的困扰。我们从真实部署场景出发用最直白的语言把这两个配置项掰开揉碎讲清楚。2. 核心原理vLLM 启动的是一个 Web 服务不是本地函数很多新手会下意识认为“我本地启动了模型那它就应该像一个 Python 函数一样直接model.generate()就行。” 这是一个关键误区。vLLM 的vllm serve命令启动的本质上是一个独立的 Web 服务器进程就像你打开 Chrome 访问https://www.baidu.com一样LangChain 或 curl 只是它的“浏览器”必须通过正确的网络地址URL才能找到它。这个 URL 由两部分构成协议 主机名 端口→ 构成base_url路径→ 比如/v1/chat/completions所以当你的代码写的是base_urlhttps://gpu-pod694e6fd3bffbd265df09695a-8000.web.gpu.csdn.net/v1而你本地启动的命令是vllm serve ... --port 8000这两者之间必须严格匹配否则就是“鸡同鸭讲”。2.1 端口Port服务的“门牌号”端口是网络通信的入口编号。你告诉 vLLM “请把服务开在 8000 号门”那么所有想访问它的请求就必须敲 8000 这扇门。正确vllm serve ... --port 8000base_urlhttp://localhost:8000/v1错误vllm serve ... --port 8000base_urlhttp://localhost:8080/v1敲错了门错误vllm serve ... --port 8000base_urlhttp://127.0.0.1:8000/v1看似一样但某些环境有细微差异如何确认端口是否正确查看 vLLM 启动日志第一行通常会打印Uvicorn running on http://0.0.0.0:XXXX这里的XXXX就是实际端口。在另一台终端里执行netstat -tuln | grep :8000Linux/macOS或netstat -ano | findstr :8000Windows如果看到LISTEN状态说明端口已被占用且服务已启动。2.2 base_url客户端的“导航地图”base_url是 LangChain 或其他客户端用来构建完整请求地址的“根目录”。它必须精确指向你本地 vLLM 服务的地址。http://localhost:8000/v1这是最标准、最推荐的写法表示“请访问我本机localhost的 8000 号门然后进入/v1这个区域”。https://gpu-pod694e6fd3bffbd265df09695a-8000.web.gpu.csdn.net/v1这是 CSDN 星图镜像平台为你分配的公网域名它背后会自动映射到你容器内的localhost:8000。这个地址只在 CSDN 平台的 Jupyter 环境中有效在你自己的本地电脑上绝对无法访问常见错误与修正你遇到的情况错误原因正确做法在自己电脑上运行代码base_url写成https://gpu-pod...这个域名是 CSDN 平台内部的你的电脑 DNS 解析不了改为http://localhost:8000/v1在 CSDN 平台的 Jupyter 里运行base_url写成http://localhost:8000/v1在容器内localhost指的是容器自己而 vLLM 服务可能运行在另一个容器或主机上改为平台提供的https://gpu-pod.../v1启动命令没加--port 8000用了默认端口vLLM 默认端口是 8000但如果你之前改过或系统被占用了它会自动选一个新端口启动时务必显式指定--port 8000并确保该端口空闲3. 三步诊断法快速定位连接失败根源与其反复试错不如按顺序执行以下三个简单命令5 分钟内就能 pinpoint 问题所在。3.1 第一步确认服务进程是否真在运行打开一个新终端执行ps aux | grep vllm serve你应该能看到类似这样的输出user 12345 0.0 0.1 123456 7890 ? Sl 10:00 0:05 python -m vllm.entrypoints.openai.api_server --model /path/to/Qwen3-0.6B --port 8000 ...如果什么都没输出说明服务根本没起来。请回到启动命令检查路径、CUDA、内存是否充足。3.2 第二步确认端口是否监听成功在同一台机器上执行curl -v http://localhost:8000/health如果返回{status:healthy}恭喜服务健康端口畅通。如果返回Failed to connect to localhost port 8000: Connection refused说明服务没监听在localhost:8000请检查启动命令中的--port参数和--host参数默认是0.0.0.0即监听所有网卡。小技巧如果localhost不通试试curl http://127.0.0.1:8000/health两者在绝大多数情况下等价但极少数 Docker 网络配置下会有差异。3.3 第三步确认 base_url 配置是否匹配这是最关键的一步。请将你的 LangChain 代码中的base_url值和你在第二步中成功访问的地址逐字比对。例如如果你第二步用curl http://localhost:8000/health成功了那么你的代码必须是base_urlhttp://localhost:8000/v1 # 注意是 http不是 https是 localhost不是 127.0.0.1除非你明确知道要这么用反之如果你是在 CSDN 星图的 Jupyter 里操作第二步应该用curl -v https://gpu-pod694e6fd3bffbd265df09695a-8000.web.gpu.csdn.net/health那么代码里的base_url就必须和这个地址完全一致只是末尾加上/v1。4. 完整可运行示例从零开始验证下面是一套经过实测的、能 100% 跑通的最小化流程。请严格按顺序执行每一步都验证结果。4.1 启动服务Linux/macOS 终端# 确保你在模型目录的上一级比如模型在 ~/models/Qwen3-0.6B VLLM_USE_V10 vllm serve ~/models/Qwen3-0.6B --port 8000 --max-model-len 6384 --host 0.0.0.0注意--host 0.0.0.0是关键它让服务能被同一局域网内的其他设备访问比如你的笔记本访问服务器。如果只在本机用不加也行。4.2 验证服务新终端# 1. 检查健康状态 curl http://localhost:8000/health # 2. 查看可用模型列表确认模型名 curl http://localhost:8000/v1/models # 3. 发送一个最简单的聊天请求测试核心功能 curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: Qwen3-0.6B, messages: [{role: user, content: 你好}], max_tokens: 50 }4.3 LangChain 调用Jupyter 或 Python 脚本from langchain_openai import ChatOpenAI # 关键base_url 必须和上面 curl 的地址完全一致 chat_model ChatOpenAI( modelQwen3-0.6B, # 这个名字必须和 curl /v1/models 返回的一致 temperature0.5, base_urlhttp://localhost:8000/v1, # ←←← 这里是唯一需要修改的地方 api_keyEMPTY, # vLLM 不校验 key填什么都行 streamingTrue, ) response chat_model.invoke(你是谁) print(response.content)5. 常见陷阱与避坑指南即使你严格按照上述步骤操作仍可能掉进一些“隐形坑”。以下是工程师们踩过的典型雷区帮你提前绕开。5.1 陷阱一防火墙/安全组拦截了端口现象在服务所在的服务器上curl http://localhost:8000/health成功但在你自己的笔记本上curl http://服务器IP:8000/health失败。原因服务器的防火墙如ufw、firewalld或云服务商的安全组规则默认只放行 22SSH、80、443 等常用端口8000 被拦在门外。解决Ubuntusudo ufw allow 8000CentOSsudo firewall-cmd --permanent --add-port8000/tcp sudo firewall-cmd --reload阿里云/腾讯云登录控制台在“安全组”规则里添加一条入方向规则端口范围8000/8000授权对象0.0.0.0/0或你的 IP。5.2 陷阱二Docker 容器网络隔离现象你在 Docker 容器里启动了 vLLM但在宿主机上无法访问http://localhost:8000。原因Docker 容器默认使用bridge网络容器内的localhost和宿主机的localhost是两个世界。你需要将容器端口映射出来。解决启动容器时加上-p 8000:8000参数。docker run -p 8000:8000 -v /path/to/models:/models your-qwen-image vllm serve /models/Qwen3-0.6B --port 80005.3 陷阱三模型名称不匹配现象curl /v1/models返回的模型名是Qwen/Qwen3-0.6B但你的 LangChain 代码里写的是Qwen3-0.6B调用时报404 Model not found。原因vLLM 会将你启动时--model参数的路径作为模型的注册名。如果你的路径是~/models/Qwen3-0.6B它可能注册为Qwen3-0.6B如果是~/models/Qwen/Qwen3-0.6B它就注册为Qwen/Qwen3-0.6B。解决永远以curl http://localhost:8000/v1/models的返回结果为准把它原封不动地复制到model参数里。6. 总结记住这三条铁律部署 Qwen3-0.6B 后无法访问本质是一个“网络连通性”问题而非模型能力问题。只要牢记并严格执行以下三条99% 的连接失败都能迎刃而解1. 端口必须显式声明且保持一致启动命令里写--port 8000客户端的base_url里就必须是:8000。不要依赖默认值不要随意猜测。2. base_url 必须与服务监听地址完全一致在哪儿启动就在哪儿访问。本地启动就用http://localhost:8000/v1在 CSDN 平台启动就用它给你的https://gpu-pod.../v1。二者绝不能混用。3. 验证必须分层进行先ps看进程再curl看端口最后curl看 API。层层递进哪一层断了就专注修复那一层切忌盲目重启整个环境。现在你可以关掉这篇博客打开你的终端用curl http://localhost:8000/health做一次快速自检。如果它返回了健康的信号那么恭喜你离和 Qwen3-0.6B 的第一次成功对话只剩下一次chat_model.invoke()的距离。获取更多AI镜像想探索更多AI镜像和应用场景访问 CSDN星图镜像广场提供丰富的预置镜像覆盖大模型推理、图像生成、视频生成、模型微调等多个领域支持一键部署。