
Qwen3.8-27B 文本+视频即将登陆 CPU:SGLang 的 torchcodec PR 带来了哪些变化
- z-ai新Z.ai: GLM 5.32026-08-1860智能75代码
- obsidian新Qwen3.8 27B Uncensored (Aggressive)2026-08-1552智能68代码
- qwen新Qwen: Qwen3.8 27B (free)2026-08-1341 tok/s
- deepseek新DeepSeek: DeepSeek V4 Pro 08132026-08-1253智能69代码
- grok新SpaceXAI: Grok 4.62026-08-1261智能77代码
- meta新Meta: Muse Spark 1.22026-08-0557智能72代码
- qwenQwen: Qwen3.8 Max2026-08-0358智能72代码
- deepseekDeepSeek: DeepSeek V4 Flash 07312026-07-3152智能69代码
- minimaxMiniMax: MiniMax-H32026-07-31minimax/minimax-h3
- qwenQwen: Qwen3.7 Flash2026-07-27$0.03 / $0.13 每百万 tokens · 237 tok/s
- orcaOrcaDub: OrcaDub 1.02026-07-27orca/dub
- anthropicAnthropic: Claude Opus 52026-07-2463智能78代码
- googleGoogle: Gemini 3.6 Flash2026-07-2152智能69代码
- googleGoogle: Gemini 3.5 Flash-Lite2026-07-2137智能49代码
- metaMeta: Muse Spark 1.12026-07-1653智能71代码
- kimiMoonshotAI: Kimi K32026-07-1560智能76代码
- openaiOpenAI: GPT-5.6 Luna2026-07-0952智能71代码
- openaiOpenAI: GPT-5.6 Terra2026-07-0957智能77代码
- openaiOpenAI: GPT-5.6 Sol2026-07-0961智能77代码
- grokxAI: Grok 4.52026-07-0856智能72代码
SGLang 目前有一份草稿 PR,标题为“[CPU] 支持 Qwen3.8 文本+视频:添加 torchcodec、ffmpeg 并移除 pin_memory。”撇开这些底层工程细节,它读起来就像一张路线图:Qwen3.8-27B——阿里巴巴的 Apache-2.0 协议、270 亿参数的视觉语言模型,五天前刚刚开源——正在被接入,使其文本+视频模式能在没有 GPU 的机器上运行。这是第一个具体的信号,表明多模态 27B 模型正在团队实际部署的某个推理运行时中获得一条真正的 CPU 推理服务路径;这对所有一直等着无需购买 48GB 显卡就能在本地运行视频理解的人来说,意义重大。
那个 PR 里没有任何内容已经合并——它还是个草稿,CI 是红的,版本锁定也还在变动中。但这正是它值得仔细阅读的原因。它背后的模型是真实的并且已经发布,GPU 上的服务生态已经跟上,而这个 PR 展示了无 GPU 路径未来的走向。以下是这个变更实际做了什么、为什么 27B 模型的 CPU 视频推理比听起来要重要得多、关于 Qwen3.8-27B 已确认了什么,以及你今天可以在哪里调用它。
一段话中的模型
Qwen3.8-27B 是 Qwen 3.8 系列中开放权重的 27B 模型:一个稠密的约 278 亿参数视觉语言模型(64 层,隐藏维度 5,120),配备专用视觉塔,于 2026 年 8 月 14 日晚(北京时间)在 Apache 2.0 许可下发布到 Hugging Face 和 ModelScope。它接受文本、图像和视频输入并返回文本——原生支持,而非通过外挂适配器——原生上下文窗口为 262,144 个 token,可通过 YaRN 扩展到约一百万个。该许可属于宽松型:允许商业使用、微调和再分发,不设收入门槛,也无需额外签署商业协议,这与旗舰检查点的条款不同。
与宣传中的主要规格相比,有两个架构细节对部署者更重要。第一个是混合注意力:大多数层使用 Gated DeltaNet 线性注意力,只有四分之一保留完整的 KV 缓存,因此长上下文内存仅为传统 64 层密集模型所需的一小部分——正是这一技巧使得 262K 窗口在单个消费级 GPU 中成为现实。第二个是多词元预测(MTP),它随检查点附带自己的推测解码头,并且当服务栈使用它时,可衡量地加快解码速度。
它也是该系列中支持视频的一款。旗舰开源检查点 Qwen3.8-2.4T-A95B 的可下载版本实际上仅支持文本,而托管的 Qwen3.8-Max API 在这些权重之上添加了视觉能力。27B 是你可以实际下载并运行、开箱即用地支持文本、图像和视频的权重——这就是为什么其视频模式的 CPU 路径值得关注。
SGLang PR 实际更改了什么
这个拉取请求(sgl-project/sglang #35492)范围集中、清晰易读。它自己的描述是:“这个PR旨在通过添加torchcodec、ffmpeg并移除pin_memory来支持Qwen3.8文本+视频。”实际上,这包含三步改动。
• torchcodec — PyTorch 的基于 ffmpeg 的视频解码库 — 已被加入该技术栈,因此 Qwen3.8 文本+视频的视频帧可以在主机 CPU 上进行解码和预处理。该 PR 将 torchcodec 0.12.0 固定为与 torch 2.12 搭配,并注明 ffmpeg 必须保持低于版本 9。
• pin_memory 被移除——从多模态路径中。pin_memory 是一种 GPU 传输优化,它固定主机缓冲区以实现到设备的快速异步复制;在仅 CPU 路径上舍弃它,就表明目标硬件在数据路径中没有独立加速器。
• 复现命令启动实际模型 — Qwen/Qwen3.8-27B — 通过 sglang.launch_server 在 CPU 上运行,并启用文本+视频输入路径。
在基于它构建任何东西之前,先看看这些状态标签:这个 PR 还是草稿,两个 CI 运行均失败,而且截至今天仍在等待 SGLang 代码所有者的审查。它代表的是一个方向,而不是一次发布。重要的背景是,SGLang 已经在 GPU 上提供 Qwen3.8-27B 服务——该指南涵盖了 H200、RTX PRO 6000、RTX 5090 和 DGX Spark,并配有专门的 lmsysorg/sglang:qwen38-27b 镜像——所以 CPU 上的文本+视频路径才是真正的新内容。
![A screenshot of the draft SGLang pull request #35492 titled '[CPU] Support Qwen3.8 text+video: adding torchcodec, ffmpeg and removing pin_memory', showing the description quoting torchcodec 0.12.0 against torch 2.12 and ffmpeg below 9, a reproduce command launching Qwen/Qwen3.8-27B with --device cpu, and the note that an approving review is required before the pull request can merge.](https://cms.orcarouter.ai/api/media/file/2-375.png)
为什么CPU文本+视频比听起来更重要
Alibaba从一开始就将27B定位为边缘AI——MediaTek在权重发布当天就将其适配到Dimensity移动芯片和C-X1汽车座舱中。本地部署的故事进一步强化了这一点:Q4_K_M量化后约为17.1GB,可以装进24GB的消费级GPU或配有32GB统一内存的Apple Silicon Mac。但这个故事唯一无法做到的是,在没有GPU的机器上处理视频。这正是本PR要填补的空白。
一种CPU文本+视频路径使得视频理解可以部署在纯CPU设备上——虚拟机、小型服务器、本地机架单元、边缘网关——在这些场景中,工作负载是异步的,吞吐量比延迟更重要。视频字幕生成、内容审核、文档与图表解析、对录制的视频进行离线检索:这些正是无需GPU的批处理任务,然而如今任何具备视频输入能力的VLM仍然默认依赖GPU。
诚实的权衡是,Qwen3.8-27B 是一个270亿参数的模型,任何CPU路径都无法让270亿参数跑得快。在配备AVX级服务器且上下文包含视频帧的情况下,预计每秒只能生成个位数token——适合批处理和隔夜作业,不适合基于视频的交互式聊天。CPU路径的意义在于这个选项本身的存在:无GPU部署可以运行同一模型的视频模式,而不必降级到更小的视觉模型,或把每一帧都发送到云端GPU。
Qwen3.8-27B 如今在哪里运行
生态系统迅速跟上了模型的步伐。在自托管方面,你有 llama.cpp 和 LM Studio,提供低至约 10.7GB 的 2-bit 量化 GGUF 包;Ollama 只需一行命令即可运行;vLLM 和 SGLang 则用于正式的服务部署。目前这些大多支持文本或图像;CPU 上的视频处理路径仍在构建中。
如果您不想自己运行27B模型,托管路由已经存在:OrcaRouter提供qwen/qwen3.8-27b支持文本、图像和视频输入,262,144个token的上下文窗口,以及文本输出,输入每百万token收费0.33美元,输出每百万token收费2.40美元。它与平台上所有其他模型一样,位于同一个兼容OpenAI的端点之后——一个API密钥,无需第二份合同——并且平台的自动故障转移和路由DSL适用于该密钥下的200多个模型。一个发布仅五天、CPU路径尚未经过验证的模型,正是应该使用路由而非硬编码的典型场景:您可以在路由后面于真实工作负载上试用Qwen3.8-27B,而不必将整个调用路径押注在单一服务栈上,并且可以在自托管和托管版本之间切换而无需更改代码。

这些数字——由供应商报告,值得核实。
以下每个标题数字都来自阿里巴巴自身,出自模型卡和发布材料。该模型刚发布五天,独立复现才刚刚开始出现,因此请视其为方向明确的宣称,而非定论。对于一个27B模型,编码和智能体得分是最引人注目的亮点:
• SWE-bench Pro — 61.7(阿里巴巴报告;其自身的表格显示 Claude Opus 4.6 Max 为 53.4)
• Terminal-Bench 2.1 — 73.0(智能体终端编程)
• OSWorld-Verified — 84.3(计算机使用智能体任务)
AndroidWorld — 81.9
• DeepSWE 1.1 — 42.2,约为之前开源 27B 模型的 13.3 的三倍。
在视觉方面——也是本文真正关注的重点——阿里巴巴报告称,VideoMME视频理解得分87.0,MathVision无工具视觉推理得分90.0。Artificial Analysis的初步评测将该模型在智能指数上评为52分,在代理指数上评为51分,在特定推理设置下可以与规模大得多的闭源模型一较高下;不过,针对一个问世仅五天的模型,这些仍是早期分数。

有一个注意事项对任何在本地或CPU上运行模型的人来说都尤为重要,那就是推理调控旋钮。Qwen3.8-27B 默认开启思考模式,并配有逐请求的 reasoning_effort 设置(low / medium / xhigh)。默认的 xhigh 会严重过度思考:如今广为人知的 17GB GGUF 首次运行大约花费了 21 分钟和 22,000 个推理 token,才绘制出一张简单的图像。尤其是在 CPU 上,请谨慎设置 reasoning_effort——交互流畅与完全不可用之间的差别,仅在于这一个参数。
看什么
三个方面会告诉你CPU路径是否成为现实:
• PR #35492 是否会被合并。目前它还是草稿,CI 为红色。只有当合并后的绿色版本进入发布版时,CPU 文本+视频路径对我们其他人来说才可运行。
• 独立基准测试。 SWE-bench Pro的61.7分和VideoMME的87.0分均为供应商报告的数据。接下来几周,LMArena和Artificial Analysis的测试运行将显示,在阿里巴巴自身的测试环境之外,这些数据还能保留多少。
• 托管版1M上下文版本能否实现。原生262K已经相当大了;百万token的多模态模式才是混合注意力缓存节省真正体现价值的地方。
就目前而言,选择很简单。如果你有硬件,17GB 的 Q4 GGUF 加上 SGLang 或 llama.cpp 今天就能运行该模型;CPU 上的文本+视频 PR 则展示了无 GPU 路线的方向。如果没有硬件,可以通过 OrcaRouter 调用 Qwen3.8-27B,只需一个 API 密钥,价格为每百万输入 token 0.33 美元、每百万输出 token 2.40 美元。无论哪种方式,支持视频的开源 27B 模型都是 Qwen 3.8 这一代中最值得关注的模型——而且它才发布五天。
