一张 640×480 的图 3.43 秒出结果：Swift-1.5-Qwen3.8-27B 在 24 GB 消费卡上的实测

一、它是什么：dense + SSM 混合的 27B

Swift-1.5-Qwen3.8-27B 在 llama.cpp 里的架构标记是 qwen35，属于「dense + SSM（状态空间）混合」的 27B 级模型，与常见的纯 Transformer 27B 不是同一套推理路径。本地实测用的权重是：

主权重：Swift-1.5-Qwen3.8-27B-Q4_K_M.gguf，17.44 GB
视觉编码器：mmproj-Swift-1.5-Qwen3.8-27B-F16.gguf，0.93 GB
机器：i7-14700F + 单张 RX 7900 XTX 24 GB（UOS 25，私有 Mesa 26.2.5 RADV），llama.cpp Vulkan 构建

一个工程前提：我们的 Strata 引擎跑不了这个文件——它目前只支持 MoE 的两族架构（qwen4exp / qwen35moe），所以 Swift-1.5 走的是 llama.cpp 这条常规路径，也因此它的调优重点落在「预填速度 + 视觉编码放哪」上，而不是分层缓存。

二、速度：换一版 RADV，预填从 677 涨到 921

同一份权重、同一台机器、同一套 llama-bench 参数（-ngl 99 -fa on -b 2048 -ub 512），只换 Vulkan 驱动：

RADV 版本	pp128	pp512	tg64
系统自带 Mesa 24.3	502	677	38.6
私有 Mesa 26.2.5	658（+31%）	921（+36%）	39.4

服务端（llama-server）在 MTP 自投机开启后的解码更实在：固定 360 token 提示、跑 5 次，解码 67.2 ± 1.0 tok/s。草稿数不是越多越好——n-max=3 是 67.9 ± 3.1（波动变大、无实质收益），n-max=4 反而掉到 64.5。甜点是 2。

放在同期实测的其他模型里看：27B Dense（Qwen3.8-27B UD-Q4_K_XL）短提示 68.7、但 60K 上下文只剩 51.1；Swift-1.5 的 67.2 属于同一档位，差别在于它带视觉、且长上下文靠 SSM 结构不需要那么多 KV。

三、视觉：3.43 秒与 15 秒的差别，就是「编码器放哪」

这是这篇最实用的一条。同一张 640×480 图、同样 --image-min-tokens 1024，只改编码器的位置：

mmproj 留在 GPU（默认）：一次视觉往返 3.43 秒。
加 --no-mmproj-offload（编码器在 CPU）：15.0–16.1 秒。
差 4.4 倍。这个参数在别的场景下可能省显存，但在这个模型上是把最慢的环节放到了最慢的地方。

另外保留 --image-min-tokens 1024：上游明确警告低于该值时视觉 grounding 精度会下降（图像 token 太少会让模型「看见轮廓、说不准位置」），所以没为省时间把它调小。

四、显存档位：三档，默认 112K

含视觉编码器 + MTP + q8 KV 的加载后占用（单卡 24,560 MiB）：

上下文	显存占用	余量	建议
102,400（100K）	21.98 GB	约 2.0 GB	宽裕，可放心喂大图
114,688（112K）	22.58 GB	约 1.41 GB	默认档：视觉 + 长文都稳
131,072（128K）	23.19 GB	约 0.79 GB	只建议纯文本，大图有 OOM 风险

五、两个坑，都是「假故障」

「no usable GPU found」不一定是没卡：用私有 Mesa 26.2.5 的 ICD 时，必须预加载系统 libdrm（LD_PRELOAD=libdrm_amdgpu.so.1 libdrm.so.2），否则 Vulkan 初始化失败，llama.cpp 会静默退回 CPU——第一次启动就踩了这个坑，日志里只有一句 warning: no usable GPU found，很容易误判成模型问题。
ub 别乱加到 1024：实测 -ub 512 最优，-ub 1024 会让预填掉约 28%，还多吃 0.6 GB 计算缓冲。

六、什么时候选它

需要说清楚：这个模型我们只测了速度、视觉延迟与显存档位，没有跑客观题（MMLU-Pro / GSM8K / MATH-500 那套）与 15 项工具任务，所以不做能力排名。基于现有数据，它适合三类活：

卷宗拍照、截图、表格辨认：3.43 秒的往返意味着「拍一张问一句」是可用体验，而不是等十几秒。
长文 + 偶尔看图：112K 上下文 + 视觉并存，适合整本材料加几张插图的场景。
既要 27B 的能力、又只有一张 24 GB 卡：17.44 GB 权重全量进显存，不用分层、不用 SSD 换入换出。

机悟的建议：视觉类本地部署，先量「一张图的往返时间」

卷宗、票据、表格这类场景，用户真正感知的是「拍完多久出结果」，不是 tok/s。建议这样验：

固定一张真实图用你业务里的照片（不是测试图），量端到端往返，记三次取中位。
确认编码器在 GPU：看启动参数有没有 --no-mmproj-offload，有就删掉——这一步通常值 4 倍。
按图的大小留显存：大图会吃更多视觉 token，128K 上下文 + 大图是 OOM 高发组合，除非只跑纯文本。
驱动版本写进交付文档：同一张卡换 RADV 版本，预填能差 36%；升级/回滚都要能复现。

数据来源：自有设备实测记录（2026-10-20 定稿的 Swift-1.5 启动器实测注释、llama-bench 输出、llama-server 计时日志，机型 i7-14700F + RX 7900 XTX 24 GB + UOS 25 + Mesa 26.2.5 RADV + llama.cpp Vulkan 构建 fcac190/b900）。速度为固定提示与固定图片下的本机记录，换机器、换驱动、换量化后会变；本模型未做客观题与工具任务评测，文中不涉及能力排名。本文仅陈述自测数据，不评判任何企业与产品，不构成投资建议。

← 返回行业动态

约 40 分钟评估预约演示 · 跑断网本地 AI