A800 + Qwen3.8-27B + vLLM 推理服务部署记录 看到站里有佬发了 5090D + SGLang + WSL 的部署记录，我这边刚好走的是 vLLM 版本，环境是单张 A800 80GB，目标不是公网商业服务，而是给自己几台可信设备用一个 OpenAI-compatible API。 一、环境概况 项 配置 GPU NVIDIA A800 80GB 模型 Qwen/Qwen3.8-27B 引擎 vLLM 0.29.0 精度 BF16，未量化，未 CPU offload 上下文 原生 262,144 tokens 并发 max_num_seqs=1 本地推理端口 127.0.0.1:8000 管理网关 Caddy 127.0.0.1:6008 客户端入口 SSH tunnel 到本机 127.0.0.1:18000/v1 二、vLLM 启动参数 核心启动参数如下： vllm serve /root/autodl-tmp/qwen38/models/Qwen3.8-27B \ --served-model-name Qwen/Qwen3.8-27B \ --host 127.0.0.1 \ --port 8000 \ --dtype bfloat16 \ --tensor-parallel-size 1 \ --max-model-len 262144 \ --max-num-seqs 1 \ --gpu-memory-utilization 0.95 \ --reasoning-parser qwen3 \ --enable-auto-tool-choice \ --tool-call-parser qwen3_coder 这里没有直接把 vLLM 的 8000 端口暴露出去，而是让 vLLM 只监听本机回环地址，外部访问统一走 Caddy 或 SSH 隧道。 三、网关设计 安全边界大概是： vLLM 只监听 127.0.0.1:8000 Caddy 只代理 /v1/ 真实 vLLM API key 只在服务器侧保存 Caddy 在服务器内部给上游请求注入真实 key 客户端只填一个占位 key，例如 device-tunnel 其他电脑通过受限 SSH 用户建立本地隧道 客户端配置： Base URL: http://127.0.0.1:18000/v1 API Key: device-tunnel Model: Qwen/Qwen3.8-27B device-tunnel 不是服务器真实密钥，只是为了满足部分 OpenAI-compatible 客户端“API Key 不能为空”的参数校验。真正的访问控制在 SSH 私钥、受限用户和服务器侧 Caddy 网关。 四、验证项 我自己的验收不是只看进程起来，而是分层确认： 直连 127.0.0.1:8000 无 key 返回 401 管理网关 127.0.0.1:6008/v1/models 返回 200 非 /v1/ 路径返回 404 /v1/models 能看到 Qwen/Qwen3.8-27B 最小对话返回非空内容 reasoning、工具调用、流式 reasoning、JSON Schema 最小调用通过 262,080 token 输入 + 64 输出预算的合成请求返回 CONTEXT_OK 一个最小对话验证示例： curl --fail --silent --show-error http://127.0.0.1:18000/v1/chat/completions \ -H 'Content-Type: application/json' \ -H 'Authorization: Bearer device-tunnel' \ -d '{ "model": "Qwen/Qwen3.8-27B", "messages": [{"role": "user", "content": "只回答：部署成功"}], "temperature": 0.0, "max_tokens": 64, "chat_template_kwargs": {"enable_thinking": false} }' 五、几个坑 1. 不要直接暴露 vLLM 端口 最简单的做法是把 vLLM 绑到 0.0.0.0:8000 ，但这样不太适合作为长期方案。鉴权、日志、路径限制、超时、未来限流这些东西最好放在网关层。 我的做法是： 客户端 -> 本机 127.0.0.1:18000 -> SSH tunnel -> 服务器 127.0.0.1:6008 Caddy -> 服务器 127.0.0.1:8000 vLLM 2. 显存占满不等于 GPU 正在满载 A800 上模型常驻后显存会很高，比如 70GB+ 很正常。但这只说明权重和 KV cache 预算在显存里，不代表 GPU compute 一直满载。 如果要判断是否真的打满，需要看实时采样： nvidia-smi dmon -s pucm -c 5 或者在请求期间持续采样，而不是只看显存占用。 3. 256K 能跑通，不等于所有长文任务都验收 我这里的 256K 验证是容量验证：构造长输入，让输入预算接近原生窗口上限，确认服务能返回。 这能证明“服务能承载这个长度的请求”，但不等于证明： 长文语义效果一定好 多模态满上下文也通过 多客户端并发也稳定 所有 Agent 客户端完整工作流都没问题 4. 客户端参数要和模型模板对齐 有些客户端会传 reasoning_effort=high ，但 Qwen3.8 模板实际支持的档位可能是 low / medium / xhigh 。这类问题不一定是 vLLM 挂了，而是请求参数和 chat template 不匹配。 我这边是在服务端模板里做了一个很小的兼容，把 high 映射成 xhigh ，避免每个客户端单独改。 六、日常使用 隧道起来后，任何支持 OpenAI-compatible 自定义地址的客户端都可以这样填： Base URL: http://127.0.0.1:18000/v1 API Key: device-tunnel Model: Qwen/Qwen3.8-27B Python SDK 示例： from openai import OpenAI client = OpenAI( base_url="http://127.0.0.1:18000/v1", api_key="device-tunnel", timeout=600, ) resp = client.chat.completions.create( model="Qwen/Qwen3.8-27B", messages=[{"role": "user", "content": "只回答：连接正常"}], max_tokens=64, ) print(resp.choices[0].message.content) 七、当前状态 当前这套更像“可信设备自用版”，不是多租户平台。 优点： vLLM 原生 OpenAI-compatible，客户端接入简单 模型端口不直接对外暴露 真实 API key 不下发到客户端 可信设备通过独立 SSH key 和槽位控制 Caddy 统一处理路径限制和上游转发 限制： 没有做计费 没有做多 key 配额 没有做精细限流 并发仍然是 1 公网正式服务化还需要额外网关、监控、限流和权限体系 对我这个场景来说，目标只是让自己的几台设备稳定调用 A800 上的 Qwen3.8-27B，所以先做到“能用、边界清楚、密钥不乱跑”就够了。 1 个帖子 - 1 位参与者 阅读完整话题

  • 情报分类：服务器与云资源
  • 分类依据：内容涉及服务器、云资源或网络线路
  • 信息来源：服务器 / LINUX DO - 最新话题
  • 发布时间：2026/9/22 17:57:55