Swift-1.5-Qwen3.8-27B
关于 Swift-1.5-Qwen3.8-27B 的完整介绍(点开看;上面就是结论表)
UkisAI 对 Qwen3.8-27B 的推理效率衍生:少 58.5% thinking token 同时综合分比基座高 0.35%(GPQA-D 88.59 vs 88.28;AIME 2026 96.0 vs 98.67),官方称多任务端到端 1.95× 提速;由 Swift 1.0(35 万+下载)把 RL + OPD 后训练加大而来,偏 coding/agentic(LiveCodeBench v6 81.71 vs 基座 76.76、Terminal-Bench 2.1 72.13 vs 69.21,均为官方口径)。架构常数与基座逐字一致(config.json 一手核对:64 层 / full_attention_interval 4 → 16 层全注意力 / 4 KV 头 / head_dim 256 / 262144 ctx / MTP 1 层),KV 口径与基座完全一致:每 4K 0.25G。权重 27.78B(BF16 safetensors,HF API 一手核对),带视觉塔多模态,官方 GGUF 仓库 24 档全量 + F16 mmproj(llama.cpp 需配 mmproj 才能看图)。许可 Swift Open License v1.0:年收入 <100 万美元个人/组织商用免费,超过需企业授权;基座部分仍是 Qwen Apache-2.0。给读者的实测警示(本站六工位实测 V100-32G Q4_K_M,2026-11-09:decode 16.79 t/s;No.05 七项横评):常见题型不掉分(gsm8k 92% 与基座打平),但 minerva_math 只有 2.71% 低于随机线——「少思考」在需要完整推理链的难题上变成了「不想了」,数学推理任务别选它。他测(2026-11-09 B-066 补,llm-bench.io 社区 20 runs / 3 GPUs,IQ3_XXS-mtp 量化变体,llama.cpp 客户端口径,C 级单源聚合):RX 7800 XT 16G 单卡 **52.8 tok/s**(9 runs,131K ctx,PP 343.5,TTFT 1675ms)/ 2×RTX 5060 16G **39.7**(PP 472.6)/ RX 6700 XT 12G **28.6**(32K ctx)——MTP 投机开着但接受率未报,不进投机对比;llama.cpp 客户端口径与 vLLM 服务端条目不可横比。本站六工位 V100-32G 16.79 t/s(verified)是 V100 代差(900GB/s),非模型问题。
实测速度:什么卡、什么量化、多少 token
| 显卡 | 卡数 | 量化 | 上下文 | 框架 / 版本 | decode tok/s | prefill tok/s | 单流/并发 | 投机 | 口径 | 来源 |
|---|---|---|---|---|---|---|---|---|---|---|
| NVIDIA Tesla V100 32G(数据卡) | 1 卡 | Q4_K_M | 0K | llama.cpp llama-server(六工位统一评测,OpenAI 兼容 chat 接口) · llama.cpp b10635-fc35562ba;-np 4 -ngl 99 -fa on -ctk q8_0 -ctv q8_0 -c 32768 -b 2048 -ub 1024 -tb 1024 | 16.79 | 124.25 | 单流 | 无 | 本站实测 | P:\显卡模型网站\tools\bench\evals_suite\swift-1-5-qwen38-27b-q4km\raw.json 本站(Step,六工位统一评测) · 2026-11-09 |
| AMD Radeon RX 7800 XT 16GB(社区 9 runs,llama.cpp 各 budget 档) | 1 卡 | IQ3_XXS(GSQ+RCO,mtp 版本,14.0–17.2GB) | 128K | llama.cpp · 社区各版(k4 v4 / k8 v4 各 budget 档 + q8 kv 档) | 52.8 | 343.5 | 单流 | 开(接受率 未报) | 口径不全·不进对比 缺 2 项 | llm-bench.io:Swift-1.5-Qwen3.8-27B-GSQ-RCO-IQ3_XXS-mtp(20 runs / 3 GPUs 社区聚合) llm-bench.io 社区(run 提交者 10-04/10-05/10-18) · 2026-10-18 |
| NVIDIA RTX 5060 Ti 16G | 2 卡(互联未报) | IQ3_XXS(GSQ+RCO,mtp 版本,13.2–16.4GB) | 128K | llama.cpp · 社区版(09-25/09-28 双 run) | 39.7 | 472.6 | 单流 | 开(接受率 未报) | 口径不全·不进对比 缺 3 项 | llm-bench.io:Swift-1.5-Qwen3.8-27B-GSQ-RCO-IQ3_XXS-mtp(2×5060 MULTI-GPU run) llm-bench.io 社区(09-28 run 提交者) · 2026-09-28 |
| AMD RX 6700 XT 12G | 1 卡 | IQ3_XXS(GSQ+RCO,mtp 版本) | 32K | llama.cpp · 社区版 | 28.6 | 196.9 | 单流 | 开(接受率 未报) | 口径不全·不进对比 缺 2 项 | llm-bench.io:Swift-1.5-Qwen3.8-27B-GSQ-RCO-IQ3_XXS-mtp(6700 XT run) llm-bench.io 社区(09-29 run 提交者) · 2026-09-29 |
每行是一次真实测量的完整口径:哪张卡、几张卡、什么量化、多大上下文、哪个框架哪个版本、单流还是并发、开没开投机—— 缺一项就会标出来,缺项的行不参与对比与偏差计算。本站实测行没有外链,但日志路径就是原始数据所在。 想看同一张卡跑别的模型,从这个表的显卡名点进那张卡的页面。
速查:什么卡、跑多少 token
推算值按 IQ3_M、8K 上下文、单流;真实测量看下面的实测速度表。没有实测的模型这里只有推算,本站不把推算写成实测。
架构常数(已核实)
来源:ukisai/Swift-1.5-Qwen3.8-27b / config.json(抓取于 2026-11-09)。KV 公式:2 × 层数 × KV头数 × 头维 × 精度字节 × token(滑窗层按 — 封顶)。
上下文档位(按 IQ3_M)
| 上下文 | KV | 总需显存 | 16G 水位内 |
|---|---|---|---|
| 4K | 0.25 G | 13.2 G | 够 |
| 8K | 0.5 G | 13.5 G | 够 |
| 32K | 2 G | 15 G | 超 |
| 128K | 8 G | 21 G | 超 |
* 含 1G 框架开销;可用水位按 Windows 口径 88% = 14.1G。
各显存档位能开多大
| 显存 | 推荐量化 | 8K 总需 | 最多可开 |
|---|---|---|---|
| 4G | 装不下 | — | — |
| 6G | 装不下 | — | — |
| 8G | 装不下 | — | — |
| 10G | 装不下 | — | — |
| 11G | 装不下 | — | — |
| 12G | 装不下 | — | — |
| 16G | IQ3_M(估算) | 13.5G | 18432(约 18K) |
| 20G | IQ4_XS(估算) | 16.3G | 29696(约 29K) |
| 22G | Q4_K_M(估算) | 18.2G | 28160(约 28K) |
| 24G | Q5_K_M(估算) | 21G | 10240(约 10K) |
| 32G | Q6_K(估算) | 24.3G | 71680(约 70K) |
| 48G | Q8_0(估算) | 31G | 190976(约 187K) |
| 64G | Q8_0(估算) | 31G | 262144(约 256K) |
| 96G | Q8_0(估算) | 31G | 262144(约 256K) |
| 128G | Q8_0(估算) | 31G | 262144(约 256K) |
| 256G | Q8_0(估算) | 31G | 262144(约 256K) |
| 512G | Q8_0(估算) | 31G | 262144(约 256K) |
「最多可开」已扣掉权重与 1G 开销;标注为「模型原生上限」时表示显存还有余但模型只支持这么长。净可用还要再减聊天模板与系统提示词的 250 token(估算值,未逐项核实)。量化档后带「(估算)」= 官方仓库没核到这档、按公式算的权重体积(方向保守偏高);不带 = 核过官方仓库真实文件体积。
估算速度(IQ3_M · 8K)
推算 本站暂无这一模型的实测记录。
| 显卡 | 状态 | 估算 tok/s |
|---|---|---|
| NVIDIA RTX 5090 32G | 流畅 | 90–127 |
| NVIDIA RTX 5090 D 32G | 流畅 | 90–127 |
| NVIDIA CMP 170HX 64G(矿卡魔改) | 流畅 | 75–106 |
| NVIDIA RTX PRO 5000 Blackwell 48G(工作站) | 流畅 | 67–96 |
| AMD Instinct MI100 32G(老数据中心卡) | 流畅 | 62–87 |
| AMD Instinct MI50 32G(数据卡) | 流畅 | 51–73 |
| AMD Radeon VII 16G | 能跑但紧 | 51–73 |
| NVIDIA RTX 4090 24G | 流畅 | 51–72 |
| NVIDIA RTX 3090 Ti 24G | 流畅 | 51–72 |
同一套公式也用于显卡页,两页数字必然一致。带宽按 60–85% 效率折算(offload 场景更低),并对单流解码设经验上限,因此这里的数字比纯带宽公式保守。 总需显存 = 13.5G,对比各卡可用水位。
实测数据区
上传实测数据
推理框架命令
llama.cpp
# 1) 取 GGUF 权重(本站核实过的仓库名)
huggingface-cli download ukisai/Swift-1.5-Qwen3.8-27b config.json
# GGUF 量化版通常在第三方转换仓库,搜「ukisai/Swift-1.5-Qwen3.8-27b GGUF」
# 2) 起服务(Linux/macOS 用 ./llama-server,Windows 用 llama-server.exe)
llama-server -m SWIFT-1-5-QWEN38-27B-Q4_K_M.gguf -ngl 99 -c 8192 --port 8080Ollama
# 本站没核实到 Ollama 仓库里有 Swift-1.5-Qwen3.8-27B 的可用标签,所以不给命令
# 自己去查一眼:https://ollama.com/search?q=Swift-1.5-Qwen3.8-27B宁可不给命令,也不给一条跑不通的命令——照抄未核实的标签是新手最常见的卡死原因。
vLLM
vLLM 直接吃 Hugging Face 仓库名,这条最可靠:
vllm serve ukisai/Swift-1.5-Qwen3.8-27b --max-model-len 8192 --gpu-memory-utilization 0.90LM Studio
模型页搜「ukisai/Swift-1.5-Qwen3.8-27b」→ 选 IQ3_M 或 Q4_K_M → Load →
Chat Context Length 设 8192 → GPU Offload 拉到最大仓库名 ukisai/Swift-1.5-Qwen3.8-27b 是本站核实过的(架构常数就取自它)。Ollama 标签与 GGUF 文件名会随发布方变动,本站不保证一定存在,拉取失败请搜同名前缀。
优化要点
- Q4_K_M 权重 16.7G(估算)、Q6_K 22.8G(估算)、Q8_0 29.5G(估算):带「估算」的是公式值(官方仓库没核到这档),不带的核过真实文件;先在容量表里确认 8K 上下文还剩多少,再决定档位
- 上下文从 8K 提到 32K,KV 增加约 1.5G(本模型 64 层 / 4 KV头 / 头维 256)
- 模型原生上下文上限是 256K,把 -c 设得更高属于超纲使用,质量不保证
- 想要更长上下文:-ctk q8_0 -ctv q8_0 让 KV 减半,几乎不掉质量
- 稠密模型每个 token 都要读全部权重,所以速度上限就是带宽 ÷ 权重大小
- 本站对单流解码设了经验上限 200–200 tok/s(依带宽分档),超出上限的数字是公式失真而不是你的卡快