← 全部文章

Qwen3.8-27B Dense 本地部署与 API 路由指南:最强开源视觉语言模型的实战方案

Qwen3.8-27B 是 277.8 亿参数的 Dense 视觉语言模型,可在单张 GPU 上运行。本指南覆盖 vLLM 和 SGLang 本地部署、DashScope API 接入、硬件选型,以及通过 OpenAI 兼容网关实现本地优先 + API 兜底的混合路由方案。

· TheRouter

Qwen3.8-27B 是阿里通义千问团队在 2026 年 8 月 14 日发布的 Dense 视觉语言模型,总参数 277.8 亿,接受文本、图片和视频输入,以 Apache 2.0 协议开源,原生上下文窗口 262,144 tokens。这里的关键词是 Dense。和 2.4 万亿参数的 Qwen3.8-Max(稀疏 MoE 架构)不同,这个模型可以装进一张 GPU,让想自建推理服务的团队不再需要多机多卡集群。

我们写这篇指南,因为 Dense 和 MoE 之间的部署决策是实打实的工程选择。能在本地跑 Qwen3.8-27B 处理编程、文档分析或 Agent 任务,就能彻底省掉按 token 计费的 API 开销。本地算力不够的时候(高峰期、突发流量、上下文长度超出显存预算),通过 OpenAI 兼容的路由层回落到托管 API。

Qwen3.8-27B 一览

规格值
参数量27,781,427,952(Dense)
架构64 层 decoder(48 层 Gated DeltaNet + 16 层 full-attention)
模态文本 + 图片 + 视频输入,文本输出
上下文窗口262,144 tokens 原生(YaRN 可扩展至 1M)
许可证Apache 2.0
思考模式支持(思考 + 非思考)
隐藏层 / FFN5,120 / 17,408
注意力24 query heads, 4 KV heads, head dim 256 (GQA)
DashScope 模型 IDqwen3.8-27b
Hugging FaceQwen/Qwen3.8-27B

参考 Hugging Face 模型卡(2026-08-21 检索)、DashScope 模型上架(2026-08-21 检索)、Kingy.ai 规格分析(2026-08-21 检索)。

Dense 对自建部署意味着什么

Qwen3.8 家族目前有两种部署形态。

模型架构总参数每步激活参数全精度最低显存单卡可行?
Qwen3.8-Max稀疏 MoE2.4T~95B多机多卡集群否
Qwen3.8-27BDense27.78B27.78B(全部激活)~56 GB (BF16)是

2.4 万亿参数的 MoE 模型光放权重就需要好几张高端 GPU。哪怕用推理优化过的集群,每月 GPU 租赁费也要上万美元。27B Dense 模型就不一样了,BF16 全精度可以装进一张 80 GB 显存的 GPU,4-bit 量化甚至能跑在 24 GB 的消费级显卡上。

Qwen3.8-27B 的实用价值就在这里。没法或者不想给 Qwen3.8-Max 配集群的团队,可以在本地跑 Dense 模型,同样拿到不错的编程、推理和视觉理解能力。

关于 MoE 和开源权重版本的详细对比,可以看我们的 Qwen3.8 开源 2.4T vs. 闭源 Max 对比。

基准测试表现

以下是通义千问团队公布的结果(所有分数均为官方自测,截至 2026 年 8 月 21 日,独立复现仍在进行中)。

基准Qwen3.8-27BQwen3.6-27B差值
Terminal-Bench 2.173.063.4+9.6
DeepSWE 1.142.213.3+28.9
SWE-bench Pro61.7——
OSWorld-Verified84.363.9+20.4
SWE-MM38.625.7+12.9
GPQA Diamond89.2——
Humanity's Last Exam30.8——

相对 Qwen3.6-27B 的编程和 Agent 能力提升幅度很大。Terminal-Bench、DeepSWE、OSWorld 都有明显跳升,和 DashScope 发布说明中提到的"重点提升编程和办公场景能力"一致。

需要注意的是,上面列出的每一项分数都来自通义千问自己的评测。部分基准使用了内部或修改过的评测方案。社区独立评测尚在早期阶段。

参考 Hugging Face 模型卡(2026-08-21 检索)、Kingy.ai 基准分析(2026-08-21 检索)、Northflank 部署指南(2026-08-21 检索)。

硬件选型

全精度推理(BF16 / FP8)

模型权重本身约 55.6 GB(BF16)。加上合理上下文长度的 KV cache 开销,需要准备的显存如下。

  • 80 GB GPU(A100 / H100 / H200) 可以舒适地跑 BF16 推理,上下文窗口到 128K 没有问题。
  • 48 GB GPU(A6000 / L40S) 搭配 FP8 量化可用,但需要严格控制上下文预算。

量化推理(4-bit / GGUF)

Hugging Face 上有第三方制作的 GGUF 量化文件。在 4-bit 量化下,硬件要求如下。

  • 24 GB GPU(RTX 4090 / RTX 5090) 可以装进 4-bit 模型,但实际可用上下文约 8K-16K tokens。
  • 32-48 GB 统一内存(Apple M 系列芯片) 通过 Ollama 或 llama.cpp 运行,有更多上下文空间。

容易踩的坑是,24 GB 只够放权重。KV cache 随上下文长度线性增长。在 24 GB 显卡上跑 4-bit 量化再开 262K 上下文,内存会直接爆掉。实用建议是为量化推理准备 32-48 GB 显存或内存。

生产环境推荐

# 单张 H100 80GB 或 A100 80GB
# BF16 或 FP8 推理,32K-128K 上下文
# 预期输出速度 40-80 tokens/秒(取决于 batch size)

参考 Kingy.ai 硬件分析(2026-08-21 检索)、Northflank GPU 需求(2026-08-21 检索)。

用 vLLM 本地部署

vLLM 提供高吞吐推理,自带 OpenAI 兼容 API。

pip install vllm

vllm serve Qwen/Qwen3.8-27B \
  --host 0.0.0.0 \
  --port 8000 \
  --max-model-len 32768 \
  --dtype bfloat16

服务跑起来之后,用 OpenAI SDK 就能调用。

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:8000/v1",
    api_key="not-needed",
)

response = client.chat.completions.create(
    model="Qwen/Qwen3.8-27B",
    messages=[
        {"role": "user", "content": "用三句话解释 Dense 和 MoE 架构的区别。"}
    ],
)
print(response.choices[0].message.content)

在 H100 上用 FP8 量化节省显存的写法如下。

vllm serve Qwen/Qwen3.8-27B \
  --host 0.0.0.0 \
  --port 8000 \
  --max-model-len 65536 \
  --dtype float16 \
  --quantization fp8

用 SGLang 本地部署

SGLang 是另一个高性能选择,原生支持 Qwen3.8-27B。

pip install sglang[all]

python -m sglang.launch_server \
  --model-path Qwen/Qwen3.8-27B \
  --host 0.0.0.0 \
  --port 8000 \
  --context-length 32768

SGLang 同样暴露 OpenAI 兼容的 /v1/chat/completions 端点,上面 vLLM 部分的客户端代码不用改。

参考 SGLang Qwen3.8-27B cookbook(2026-08-21 检索)。

用 Ollama 在消费级硬件上部署

工作站或笔记本上,Ollama 是最省事的方案。

ollama run qwen3.8:27b

会自动拉取量化过的 GGUF 文件,在 Apple Silicon(建议 32 GB 以上内存)或 24 GB 以上显存的 NVIDIA GPU 上运行。OpenAI 兼容 API 在 http://localhost:11434/v1。

DashScope 托管 API

不想自建推理服务的话,Qwen3.8-27B 在 DashScope(阿里云百炼平台) 上可用,模型 ID 是 qwen3.8-27b。

定价(北京区域)

截至 2026 年 8 月 21 日,DashScope 定价页面尚未单独列出 qwen3.8-27b 的价格,预计与其他 27B 级别模型同档。具体费率请查看 DashScope 模型调用计费。

第三方 API 服务商

Qwen3.8-27B 也可以通过第三方推理服务商调用。

服务商输入价(每百万 tokens)输出价(每百万 tokens)来源
OpenRouter$0.40$3.00openrouter.ai(2026-08-21 检索)
SiliconFlow~$0.30-0.45~$3.20siliconflow.com/pricing(2026-08-21 检索)

已经在通过 OpenAI 兼容路由层使用 SiliconFlow 或 DashScope 的团队,加上 Qwen3.8-27B 只是一个配置项的变更,请求自动路由过去。

OpenAI 兼容指供应商提供一个 chat-completions 接口,其请求与响应结构与 OpenAI API 契约足够接近——只需替换三个值(API key、base URL、模型名),原来的 OpenAI SDK 调用即可直接工作。最小实践面是POST /v1/chat/completions 带 messages、model, 并返回 OpenAI 形式的流式响应。

DashScope API 快速上手

from openai import OpenAI

client = OpenAI(
    base_url="https://dashscope.aliyuncs.com/compatible-mode/v1",
    api_key="sk-your-dashscope-key",
)

response = client.chat.completions.create(
    model="qwen3.8-27b",
    messages=[
        {"role": "user", "content": "Dense 模型相比 MoE 在本地部署上有哪些优势?"}
    ],
)
print(response.choices[0].message.content)

视觉输入

Qwen3.8-27B 是原生视觉语言模型,可以在消息内容中传入图片。

response = client.chat.completions.create(
    model="qwen3.8-27b",
    messages=[
        {
            "role": "user",
            "content": [
                {"type": "text", "text": "描述这张架构图中的内容。"},
                {"type": "image_url", "image_url": {"url": "https://example.com/diagram.png"}},
            ],
        }
    ],
)

混合路由方案:本地优先,API 兜底

Qwen3.8-27B 最划算的部署模式是把本地推理和托管 API 结合起来。思路很直接。

  1. 主路径 把请求路由到本地的 vLLM 或 SGLang 实例。
  2. 兜底路径 本地算力打满的时候(队列过深、GPU 利用率拉满、上下文长度超出显存预算),自动回落到 DashScope 或 SiliconFlow。
  3. 特殊路径 需要 MoE 旗舰能力的场景(超长上下文分析、复杂多步推理),直接路由到 DashScope 上的 qwen3.8-max。

这个方案能跑通,因为 Qwen3.8-27B 和托管 API 走的都是 OpenAI 兼容的 chat completions 协议。OpenAI 兼容路由网关可以在本地和云端之间切换,应用代码不用改。

TheRouter 把 OpenAI 兼容请求路由到已配置的服务商。如果把本地端点和 DashScope 都配成服务商,路由层自动处理故障转移。

自建还是用 API?

场景建议
持续的高吞吐推理(每小时数千请求)自建,均摊 GPU 成本比按 token 计费便宜
隐私敏感的工作负载(医疗、法律、财务文档)自建,数据不出你的基础设施
突发流量或不可预测的负载API,按 token 付费,弹性伸缩
需要 1M+ token 上下文API(Qwen3.8-Max),本地 27B 用 YaRN 扩展到 1M 仍属实验性质
编程 Agent 配合中等上下文(8K-32K)自建,这正好是 27B Dense 在单卡上的甜区
多模态文档分析取决于量和延迟要求

常见部署问题

长上下文下内存溢出

262K 原生上下文不等于你的 GPU 跑得动 262K tokens。KV cache 占用的显存随序列长度线性增长。在 24 GB 显卡上跑 4-bit 权重,实际上下文约 8K-16K。128K 以上的上下文请准备 80 GB 显存。

首 token 延迟偏高

Dense 27B 模型的首 token 延迟比 Qwen3.7-Flash 这类小模型高。如果需要 200ms 以内的首 token 响应,考虑在 H100 上用 FP8 推理或者直接用托管 API。

GGUF 质量与官方权重

Hugging Face 上只有 BF16 和 FP8 检查点是通义千问官方产物。所有 GGUF 文件都是第三方转换的。激进的量化级别(2-bit、3-bit)质量下降明显。我们建议 4-bit(Q4_K_M 或 Q4_K_S)作为生产使用的实际下限。

上线检查清单

  • GPU 规格匹配 生产环境 BF16/FP8 用 80 GB,量化用 24-48 GB
  • 上下文预算设定 --max-model-len 按实际显存设置,别填 262K 上限
  • 健康检查配好 vLLM 和 SGLang 都有 /health 端点
  • 兜底服务商配好 DashScope 或 SiliconFlow 作为本地宕机时的备选
  • 限流措施到位 防止流量高峰把 GPU 队列打爆
  • 监控就绪 跟踪 GPU 利用率、队列深度和 p99 延迟

Qwen3.8-27B 与同类开源模型对比

模型参数量Dense/MoE视觉输入上下文许可证SWE-bench Pro
Qwen3.8-27B27.78BDense是262KApache 2.061.7
Qwen3.6-27B~27BDense是131KApache 2.0—
DeepSeek-V4-Flash284B 总 / 13B 激活MoE否1MModel License—
GLM-5.3开源权重Dense否1M——

在 27B 级别的 Dense 模型中,Qwen3.8-27B 目前没有直接对手能同时做到视觉输入、强编程基准和 Apache 2.0 许可。

总结

Qwen3.8-27B 是我们见过的最适合本地部署多模态、编程和 Agent 工作负载的开源 Dense 模型。它跑在单张 GPU 上,说 OpenAI 兼容协议,可以和托管 API 组合成高性价比的混合架构。

如果你在评估编程 Agent、文档分析或隐私敏感推理的自建模型方案,Qwen3.8-27B 是现在该测的那个检查点。先用 DashScope API 验证业务场景,算明白经济账之后再转本地推理。


本文引用的来源

  1. Hugging Face / Qwen3.8-27B 模型卡(2026-08-21 检索)
  2. DashScope 模型上架与更新(2026-08-21 检索)
  3. DashScope 模型调用计费(2026-08-21 检索)
  4. Kingy.ai, Qwen3.8-27B Specs, Benchmarks and Verdict(2026-08-21 检索)
  5. Kingy.ai, Qwen3.8-27B Local Hardware Guide(2026-08-21 检索)
  6. Northflank, Qwen3.8-27B Performance, Benchmarks, GPU Requirements(2026-08-21 检索)
  7. SGLang, Qwen3.8-27B Deployment Cookbook(2026-08-21 检索)
  8. OpenRouter, Qwen3.8-27B Pricing(2026-08-21 检索)
  9. SiliconFlow, Pricing(2026-08-21 检索)
帮助与联系