Qwen3.5 系列模型端侧部署全维度调研

本调研定位：以**端侧部署（on-device / 浏览器内）**为唯一视角，把 Qwen3.5 全系列从最小的 0.8B 到满血旗舰 397B-A17B 拉通对照，回答一个问题——每一档到底能落在什么设备上。技术口径锚定本站 /web-llm 实际用的 transformers.js + ONNX Runtime Web + WebGPU 链路。

一、是什么

Qwen3.5 是阿里通义千问 2026 年初发布的一代开源大模型系列，全系采用 Gated DeltaNet（GDN）混合注意力架构、原生多模态（文本 / 图像 / 视频）、262K 原生上下文、Apache 2.0 许可。按发布节奏分三批：

小模型系列（2026-03-02）：0.8B / 2B / 4B / 9B，全部 dense
中模型系列（2026-02-24）：27B dense、35B-A3B MoE、122B-A10B MoE、Flash（仅 API）
旗舰（2026-02-16）：397B-A17B MoE

⚠️ 口径校正：本次调研发起时给出的尺寸清单里有 14B / 32B / 72B——这三档属于 Qwen2.5 / Qwen3 上一代的命名，Qwen3.5 并没有 14B / 32B / 72B dense 版本。Qwen3.5 对中段做了重排：用 9B 和 27B 两个 dense 档 + 35B-A3B / 122B-A10B 两个 MoE 档，替代了老一代的 14B / 32B / 72B。下文大表按真实 lineup 列出，并在第五节单独说明这次"代际错位"。

"端侧部署"在本调研里的定义：模型权重与推理完全跑在用户设备上（浏览器标签页 / 手机 / 个人电脑），无后端、无 API Key、无 per-token 费用。技术链路 = transformers.js（HF 的 JS 版 Transformers）→ ONNX Runtime Web → WebGPU。

二、为什么重要

2.1 端侧把"部署门槛"直接清零

在线大模型要服务器、要 API Key、要按 token 付费、要扛并发。端侧方案把这些全部消掉：模型文件下载进浏览器，推理吃用户自己的 GPU。对一个个人站点（如本站 /web-llm）来说，这是唯一可持续的免费 AI 功能形态。

2.2 GDN 架构让"小模型 + 长上下文"第一次在消费级硬件上成立

Qwen3.5 的 Gated DeltaNet 用 3:1 的线性注意力 : 全注意力比例：大部分层是固定大小状态矩阵（如 128×128，与序列长度无关），少数全注意力层作为"精度校验点"。一个 32 层模型若 4 层全注意力 + 28 层 GDN，在 262K tokens 下注意力相关计算量比纯二次方架构降约 8 倍。这正是 0.8B 这种小模型也能扛长上下文、且能塞进浏览器的前提。

2.3 选型错配的代价很高

端侧场景下选错一档，结果是直接跑不起来（显存溢出）或慢到不可用。一张清晰的"尺寸 ↔ 设备"对照表，能避免"拿 9B 去浏览器里硬跑然后卡死"这类典型事故。

三、关键玩家与生态

角色	代表	作用
模型方	阿里通义千问（Qwen Team）	Qwen3.5 全系，Apache 2.0 开源权重
端侧运行时	HF `transformers.js`、`ONNX Runtime Web`	把模型在浏览器 / Node 里跑起来
硬件抽象层	WebGPU（Chrome / Edge / Firefox 桌面端）	给 JS 近原生的 GPU 算力；移动端支持仍零散
模型分发	`onnx-community/Qwen3.5-*-ONNX`（HF Hub）	预转好的 ONNX 量化权重，端侧直接拉
参考实现	HF Space `webml-community/Qwen3.5-WebGPU`	官方/社区的浏览器内运行 demo
竞品（端侧赛道）	Llama 3.x 小档、Phi-3/4-mini、Gemma 小档、SmolLM	同样面向浏览器 / 手机的轻量模型

本站 /web-llm 走的就是 transformers.js + onnx-community/Qwen3.5-{0.8B,2B,4B}-ONNX + WebGPU 这条链路。

四、技术 / 实施细节：端侧部署对照大表

核心产出。 显存数字为 Q4 量化下的权重占用（端侧实际几乎都用量化），均为公开资料的近似值；"端侧落点"指能跑起来且交互速度可接受的设备级别。

型号	架构 / 激活	总参	Q4 权重显存	端侧落点	浏览器内（transformers.js + WebGPU）
Qwen3.5-0.8B	Dense	0.8B	< 2 GB	手机 / 集显 / 甚至纯 CPU	✅ 流畅（本站 `/web-llm` 首选档）
Qwen3.5-2B	Dense	2B	< 2 GB	高端手机 / 集显 / 轻薄本	✅ 可行
Qwen3.5-4B	Dense	4B	≈ 2.5 GB	笔记本独显 / 4–6GB GPU / 低显存 Mac	✅ 可行（量化后 < 2GB 区间，交互速度尚可）
Qwen3.5-9B	Dense	9B	≈ 5.1 GB（全精度约需 12GB）	8GB+ 独显笔记本 / 桌面	⚠️ 勉强 —— 超出"< 2GB 流畅区"，需较好 GPU，是浏览器内的事实上限
Qwen3.5-27B	Dense	27B	≈ 15 GB	16–24GB 桌面独显	❌ 不现实
Qwen3.5-35B-A3B	MoE / 激活 3B	35B	≈ 19–25 GB	24GB+ 桌面 / 工作站	❌（但因仅激活 3B，同硬件下出词比 27B dense 快）
Qwen3.5-122B-A10B	MoE / 激活 10B	122B	FP8 ≈ 2×H100 80GB	多卡工作站 / 服务器	❌
Qwen3.5-397B-A17B	MoE / 激活 17B	397B	INT4 权重 ≈ 199GB，运行时 230–240GB	数据中心，≥ 4×H100 80GB	❌（满血旗舰，纯云端）
Qwen3.5-Flash	MoE / 仅 API	未公开	——	仅云端 API	❌（无开放权重，不可端侧）

4.1 这张表的分界线

端侧"舒适区"= 0.8B / 2B / 4B：Q4 后权重 < 2GB，WebGPU 上交互速度可用，移动端也有戏。
9B = 端侧上限且勉强：Q4 ≈ 5GB，已超出浏览器"< 2GB 流畅"经验阈值；只在 8GB+ 独显机器上、且用户愿意等下载和加载时才合理。
27B 及以上 = 离开端侧：从桌面独显（27B/35B-A3B）到多卡（122B）到数据中心（397B），与"浏览器 / 手机"无关。
"满血旗舰"与"端侧"基本互斥：397B-A17B 是能力天花板，但它的部署天花板也最高——这是本调研最关键的一句话。

4.2 容易被忽略的显存项：KV 缓存

上面只算了权重。262K 满上下文时 KV 缓存还要额外 4–8GB；好在端侧交互场景一般工作在 4K–32K 上下文，额外开销只有 0.5–2GB。端侧做容量规划时，按"Q4 权重 + 1~2GB"估总占用比较稳。

4.3 端侧落地清单（以本站 `/web-llm` 为参考）

用 onnx-community/Qwen3.5-{0.8B|2B|4B}-ONNX 预量化权重，不要自己在浏览器里转。
transformers.js 动态导入浏览器构建（Next.js 下需绕开 node 版解析，见本站 web-llm/transformers-browser.js）。
首次加载会下载数百 MB ~ 1GB+ 权重，必须给进度条 + 缓存（transformers.js 默认走浏览器 Cache Storage，二次秒开）。
检测 navigator.gpu，无 WebGPU 时明确降级提示；移动端默认按"可能不支持"处理。
默认档位选 0.8B——成功率最高；2B/4B 作为"显存够再上"的可选项。

4.4 成本预估：先分清"谁出钱"

成本要拆成两个视角看，混在一起就会得出"端侧免费"这种误导结论：

站长侧：把功能挂上线、维持运行，开发者要持续掏多少钱。
终端侧：模型实际跑在某台机器上，这台机器本身要花多少钱买。

端侧部署的真相是——它没有消灭算力成本，只是把成本从"站长的服务器账单"转移成了"终端用户的设备购置费"。下面两张表分开算。

A. 终端硬件购置成本（端侧真正的成本所在）

要在本地跑某一档模型，设备得有对应的内存 / 显存。这台设备的购置价，就是该档位"看不见的端侧成本"：

档位	跑得动的最低设备	设备购置价（人民币）
0.8B / 2B	近几年的手机、8GB 内存轻薄本	¥1,500–5,000（多数人已持有 → 增量 ≈ ¥0）
4B	8GB 勉强、16GB 舒服的笔记本	¥4,000–7,000
9B	8GB+ 显存独显本，或 24–32GB 统一内存 Mac	¥8,000–18,000
27B / 35B-A3B	24GB 显存桌面（RTX 4090 / 5090），或 64GB+ 统一内存 Mac	单卡 ¥18,000–27,000；整机 ¥30,000–50,000
122B-A10B	多卡工作站（≥ 2× 数据中心级 GPU）	¥30 万–80 万
397B-A17B	数据中心服务器，4–8× H100	¥200 万–300 万（8×H100 服务器约 $250K–400K）

关于"72B 要百万级服务器"：方向对，但 Qwen3.5 没有 72B 这一档。真正落在百万级的是满血旗舰 397B-A17B（8×H100 服务器 ¥200–300 万）；122B-A10B 属于数十万级工作站。老一代 72B dense 大致就是这个"大模型 = 服务器级硬件"的直觉区间。

这张表也解释了端侧"舒适区"为什么卡在 0.8–4B：这几档对应的设备是"人人本来就有的手机和笔记本"，增量硬件成本 ≈ 0；9B 起要求用户专门有台好机器；27B 往上，硬件成本对个人就是劝退级。

B. 站长侧成本：端侧 / 云端 API / 自托管三条路径

路径	一次性成本	持续成本（站长侧）	适用模型档	主要风险
端侧（浏览器内）	0（用现成 ONNX 权重）	≈ $0	0.8B / 2B / 4B	首包下载体验、WebGPU 覆盖
云端 API（按量付费）	0	按 token 付费，可被刷	任意档，含 397B	账单失控、需 API Key 管理
自托管 GPU	买卡 / 起租	$200 – $15,000+/月常驻	27B 及以上	利用率低 = 纯烧钱

路径一 · 端侧 —— 对站长是真·零成本

推理算力与电费由用户设备承担，站长一分不出。
唯一可能的成本是模型权重分发带宽；但 transformers.js 直接从 Hugging Face / hf-mirror 拉权重（见本站 web-llm 的 env.remoteHost），这部分带宽都不经过本站服务器。
加上浏览器 Cache Storage 缓存，每个用户只下载一次。→ 站长侧持续成本 ≈ $0，且天然防刷（每个人花的是自己的算力）。

路径二 · 云端 API —— 便宜，但有"被刷"敞口

以本站 /web-llm 量级估算（设每次对话 ≈ 输入 500 + 输出 500 tokens）：

调用的模型	单价（输入 / 输出，每百万 token）	每次对话	1000 次/天 ≈ 每月
Qwen3.5-9B	$0.04 / $0.15	≈ $0.0001	≈ $3
Qwen3.5 Flash	$0.065 / $0.26	≈ $0.00016	≈ $5
Qwen3.5 Plus（≈ 旗舰 397B 级）	$0.30 / $1.80	≈ $0.001	≈ $30

数字看着不大，但公开的免费 AI 功能直连付费 API ≈ 给全网开了一张站点信用卡：一旦被脚本刷量，月账单可能从 $30 跳到三四位数。要么加鉴权 / 限流 / 验证码，要么设额度封顶——都增加复杂度。

路径三 · 自托管 GPU —— 对个人站点基本不成立

要常驻一张卡：最便宜的 on-demand H100 约 $2–2.5/小时，按 730 小时/月算 ≈ $1,500–1,800/月；即便退到消费级 RTX 4090（约 $0.29/小时）常驻也要 ≈ $210/月。而"满血旗舰"397B-A17B 要 4–8 张 H100，光租金就 $7,000–15,000/月起——这也解释了为什么 397B 只能走 API（$0.30/$1.80）去碰，没有个人项目会自托管它。

小结：端侧把站长侧边际成本压到 0，但没有消灭成本——它要求终端用户自带够格的设备。0.8–4B 是端侧甜区，正因为它要的设备（手机 / 普通笔记本）是大众已持有的，增量硬件成本 ≈ 0；一旦往 9B、27B 上走，"看不见的终端成本"就开始陡升。这也是本站 /web-llm 选端侧、且默认档锁 0.8B 的根本原因。

五、争议与风险

5.1 代际错位：用户清单里的 14B / 32B / 72B 不存在于 Qwen3.5

这是本次调研最该澄清的一点。14B（Qwen2.5/Qwen3）、32B（Qwen2.5/Qwen3）、72B（Qwen2.5）都是上一代的尺寸。Qwen3.5 主动重排了中段：

老一代直觉	Qwen3.5 实际对应
7–8B	9B dense
14B	（取消，由 9B / 27B 两端覆盖）
32B	27B dense
72B dense	35B-A3B / 122B-A10B MoE（用 MoE 替代大 dense）

5.2 端侧的真实痛点

首包体积：哪怕 0.8B，量化权重也有数百 MB，第一次访问是"白屏等下载"，对跳出率不友好。
WebGPU 覆盖：桌面 Chrome/Edge/Firefox 可用，移动端支离破碎——而移动端恰恰是端侧最大的潜在场景。
冷加载慢：权重进显存 + 编译 shader，首次推理前有可观等待，需要 UI 明确管理预期。
能力天花板：端侧能跑的 0.8–4B，智能水平（Intelligence Index 约 9 / 16 / 27）只够轻量问答、改写、结构化抽取；复杂推理、长链 Agent 仍要 9B+ 乃至云端。
"满血"诱惑：397B-A17B 参数好看，但它和"端侧"完全是两个世界；把旗舰能力写进端侧需求是常见的需求错配。

5.3 反方观点

"端侧不如直接调 API"：对追求质量的场景成立——4B 的能力确实远不如云端旗舰。端侧的价值在隐私、零成本、离线、零后端，不在能力上限。
"WebGPU 还太早"：移动端覆盖差是事实；但桌面端已足够支撑"轻量 AI 功能"这一层，作为渐进增强（progressive enhancement）是站得住的。

六、个人结论

一句话定性：Qwen3.5 把"小模型能力"和"长上下文 + 多模态"拉到了端侧可用线，但**"满血旗舰"与"端侧部署"在物理上互斥**——这张大表的真正用途是帮人别选错档。
成本视角：端侧的成本从站长账单转移到终端用户的设备购置费（详见 4.4）——0.8–4B 是甜区，因为它要的设备是大众已有的手机 / 笔记本，增量 ≈ ¥0；9B 起终端硬件成本陡升，397B 旗舰对应的是 ¥200 万级服务器。站长侧端侧确实 ≈ 零成本且天然防刷，这是它压过云端 API 的关键。
是否跟进：跟进，且范围明确——端侧只认 0.8B / 2B / 4B，9B 列为"实验性上限"，27B 及以上只作云端选项，不进端侧讨论。
下一步行动：
1. 本站 /web-llm 维持 0.8B 默认 + 2B/4B 可选，与本表结论一致，无需改档。
2. 给 /web-llm 增加设备能力探测：无 WebGPU / 移动端时直接提示"建议桌面 Chrome"，而不是让用户白等。
3. 观望 9B 的浏览器实测：等出现稳定的 onnx-community/Qwen3.5-9B-ONNX 浏览器 demo 再评估是否加入可选档。
4. 旗舰线（122B / 397B）只做知识储备，不投入端侧工程。
适用场景：端侧 AI 选型、/web-llm 迭代、向他人解释"为什么浏览器里只能跑小模型"。

七、信息来源

一手 / 官方

技术细节 / 二手交叉验证

成本 / 价格

注：显存数字来自上述二手硬件指南的公开口径，为 Q4 量化近似值，会随推理框架、上下文长度、量化方案浮动；端侧规划请以实测为准。

本调研定位：以**端侧部署（on-device / 浏览器内）**为唯一视角，把 Qwen3.5 全系列从最小的 0.8B 到满血旗舰 397B-A17B 拉通对照，回答一个问题——每一档到底能落在什么设备上。技术口径锚定本站 /web-llm 实际用的 transformers.js + ONNX Runtime Web + WebGPU 链路。

一、是什么

小模型系列（2026-03-02）：0.8B / 2B / 4B / 9B，全部 dense
中模型系列（2026-02-24）：27B dense、35B-A3B MoE、122B-A10B MoE、Flash（仅 API）
旗舰（2026-02-16）：397B-A17B MoE

⚠️ 口径校正：本次调研发起时给出的尺寸清单里有 14B / 32B / 72B——这三档属于 Qwen2.5 / Qwen3 上一代的命名，Qwen3.5 并没有 14B / 32B / 72B dense 版本。Qwen3.5 对中段做了重排：用 9B 和 27B 两个 dense 档 + 35B-A3B / 122B-A10B 两个 MoE 档，替代了老一代的 14B / 32B / 72B。下文大表按真实 lineup 列出，并在第五节单独说明这次"代际错位"。

二、为什么重要

2.1 端侧把"部署门槛"直接清零

2.2 GDN 架构让"小模型 + 长上下文"第一次在消费级硬件上成立

2.3 选型错配的代价很高

三、关键玩家与生态

角色	代表	作用
模型方	阿里通义千问（Qwen Team）	Qwen3.5 全系，Apache 2.0 开源权重
端侧运行时	HF `transformers.js`、`ONNX Runtime Web`	把模型在浏览器 / Node 里跑起来
硬件抽象层	WebGPU（Chrome / Edge / Firefox 桌面端）	给 JS 近原生的 GPU 算力；移动端支持仍零散
模型分发	`onnx-community/Qwen3.5-*-ONNX`（HF Hub）	预转好的 ONNX 量化权重，端侧直接拉
参考实现	HF Space `webml-community/Qwen3.5-WebGPU`	官方/社区的浏览器内运行 demo
竞品（端侧赛道）	Llama 3.x 小档、Phi-3/4-mini、Gemma 小档、SmolLM	同样面向浏览器 / 手机的轻量模型

本站 /web-llm 走的就是 transformers.js + onnx-community/Qwen3.5-{0.8B,2B,4B}-ONNX + WebGPU 这条链路。

四、技术 / 实施细节：端侧部署对照大表

型号	架构 / 激活	总参	Q4 权重显存	端侧落点	浏览器内（transformers.js + WebGPU）
Qwen3.5-0.8B	Dense	0.8B	< 2 GB	手机 / 集显 / 甚至纯 CPU	✅ 流畅（本站 `/web-llm` 首选档）
Qwen3.5-2B	Dense	2B	< 2 GB	高端手机 / 集显 / 轻薄本	✅ 可行
Qwen3.5-4B	Dense	4B	≈ 2.5 GB	笔记本独显 / 4–6GB GPU / 低显存 Mac	✅ 可行（量化后 < 2GB 区间，交互速度尚可）
Qwen3.5-9B	Dense	9B	≈ 5.1 GB（全精度约需 12GB）	8GB+ 独显笔记本 / 桌面	⚠️ 勉强 —— 超出"< 2GB 流畅区"，需较好 GPU，是浏览器内的事实上限
Qwen3.5-27B	Dense	27B	≈ 15 GB	16–24GB 桌面独显	❌ 不现实
Qwen3.5-35B-A3B	MoE / 激活 3B	35B	≈ 19–25 GB	24GB+ 桌面 / 工作站	❌（但因仅激活 3B，同硬件下出词比 27B dense 快）
Qwen3.5-122B-A10B	MoE / 激活 10B	122B	FP8 ≈ 2×H100 80GB	多卡工作站 / 服务器	❌
Qwen3.5-397B-A17B	MoE / 激活 17B	397B	INT4 权重 ≈ 199GB，运行时 230–240GB	数据中心，≥ 4×H100 80GB	❌（满血旗舰，纯云端）
Qwen3.5-Flash	MoE / 仅 API	未公开	——	仅云端 API	❌（无开放权重，不可端侧）

4.1 这张表的分界线

端侧"舒适区"= 0.8B / 2B / 4B：Q4 后权重 < 2GB，WebGPU 上交互速度可用，移动端也有戏。
9B = 端侧上限且勉强：Q4 ≈ 5GB，已超出浏览器"< 2GB 流畅"经验阈值；只在 8GB+ 独显机器上、且用户愿意等下载和加载时才合理。
27B 及以上 = 离开端侧：从桌面独显（27B/35B-A3B）到多卡（122B）到数据中心（397B），与"浏览器 / 手机"无关。
"满血旗舰"与"端侧"基本互斥：397B-A17B 是能力天花板，但它的部署天花板也最高——这是本调研最关键的一句话。

4.2 容易被忽略的显存项：KV 缓存

4.3 端侧落地清单（以本站 `/web-llm` 为参考）

用 onnx-community/Qwen3.5-{0.8B|2B|4B}-ONNX 预量化权重，不要自己在浏览器里转。
transformers.js 动态导入浏览器构建（Next.js 下需绕开 node 版解析，见本站 web-llm/transformers-browser.js）。
首次加载会下载数百 MB ~ 1GB+ 权重，必须给进度条 + 缓存（transformers.js 默认走浏览器 Cache Storage，二次秒开）。
检测 navigator.gpu，无 WebGPU 时明确降级提示；移动端默认按"可能不支持"处理。
默认档位选 0.8B——成功率最高；2B/4B 作为"显存够再上"的可选项。

4.4 成本预估：先分清"谁出钱"

成本要拆成两个视角看，混在一起就会得出"端侧免费"这种误导结论：

站长侧：把功能挂上线、维持运行，开发者要持续掏多少钱。
终端侧：模型实际跑在某台机器上，这台机器本身要花多少钱买。

端侧部署的真相是——它没有消灭算力成本，只是把成本从"站长的服务器账单"转移成了"终端用户的设备购置费"。下面两张表分开算。

A. 终端硬件购置成本（端侧真正的成本所在）

要在本地跑某一档模型，设备得有对应的内存 / 显存。这台设备的购置价，就是该档位"看不见的端侧成本"：

档位	跑得动的最低设备	设备购置价（人民币）
0.8B / 2B	近几年的手机、8GB 内存轻薄本	¥1,500–5,000（多数人已持有 → 增量 ≈ ¥0）
4B	8GB 勉强、16GB 舒服的笔记本	¥4,000–7,000
9B	8GB+ 显存独显本，或 24–32GB 统一内存 Mac	¥8,000–18,000
27B / 35B-A3B	24GB 显存桌面（RTX 4090 / 5090），或 64GB+ 统一内存 Mac	单卡 ¥18,000–27,000；整机 ¥30,000–50,000
122B-A10B	多卡工作站（≥ 2× 数据中心级 GPU）	¥30 万–80 万
397B-A17B	数据中心服务器，4–8× H100	¥200 万–300 万（8×H100 服务器约 $250K–400K）

关于"72B 要百万级服务器"：方向对，但 Qwen3.5 没有 72B 这一档。真正落在百万级的是满血旗舰 397B-A17B（8×H100 服务器 ¥200–300 万）；122B-A10B 属于数十万级工作站。老一代 72B dense 大致就是这个"大模型 = 服务器级硬件"的直觉区间。

这张表也解释了端侧"舒适区"为什么卡在 0.8–4B：这几档对应的设备是"人人本来就有的手机和笔记本"，增量硬件成本 ≈ 0；9B 起要求用户专门有台好机器；27B 往上，硬件成本对个人就是劝退级。

B. 站长侧成本：端侧 / 云端 API / 自托管三条路径

路径	一次性成本	持续成本（站长侧）	适用模型档	主要风险
端侧（浏览器内）	0（用现成 ONNX 权重）	≈ $0	0.8B / 2B / 4B	首包下载体验、WebGPU 覆盖
云端 API（按量付费）	0	按 token 付费，可被刷	任意档，含 397B	账单失控、需 API Key 管理
自托管 GPU	买卡 / 起租	$200 – $15,000+/月常驻	27B 及以上	利用率低 = 纯烧钱

路径一 · 端侧 —— 对站长是真·零成本

推理算力与电费由用户设备承担，站长一分不出。
唯一可能的成本是模型权重分发带宽；但 transformers.js 直接从 Hugging Face / hf-mirror 拉权重（见本站 web-llm 的 env.remoteHost），这部分带宽都不经过本站服务器。
加上浏览器 Cache Storage 缓存，每个用户只下载一次。→ 站长侧持续成本 ≈ $0，且天然防刷（每个人花的是自己的算力）。

路径二 · 云端 API —— 便宜，但有"被刷"敞口

以本站 /web-llm 量级估算（设每次对话 ≈ 输入 500 + 输出 500 tokens）：

调用的模型	单价（输入 / 输出，每百万 token）	每次对话	1000 次/天 ≈ 每月
Qwen3.5-9B	$0.04 / $0.15	≈ $0.0001	≈ $3
Qwen3.5 Flash	$0.065 / $0.26	≈ $0.00016	≈ $5
Qwen3.5 Plus（≈ 旗舰 397B 级）	$0.30 / $1.80	≈ $0.001	≈ $30

路径三 · 自托管 GPU —— 对个人站点基本不成立

小结：端侧把站长侧边际成本压到 0，但没有消灭成本——它要求终端用户自带够格的设备。0.8–4B 是端侧甜区，正因为它要的设备（手机 / 普通笔记本）是大众已持有的，增量硬件成本 ≈ 0；一旦往 9B、27B 上走，"看不见的终端成本"就开始陡升。这也是本站 /web-llm 选端侧、且默认档锁 0.8B 的根本原因。

五、争议与风险

5.1 代际错位：用户清单里的 14B / 32B / 72B 不存在于 Qwen3.5

这是本次调研最该澄清的一点。14B（Qwen2.5/Qwen3）、32B（Qwen2.5/Qwen3）、72B（Qwen2.5）都是上一代的尺寸。Qwen3.5 主动重排了中段：

老一代直觉	Qwen3.5 实际对应
7–8B	9B dense
14B	（取消，由 9B / 27B 两端覆盖）
32B	27B dense
72B dense	35B-A3B / 122B-A10B MoE（用 MoE 替代大 dense）

5.2 端侧的真实痛点

首包体积：哪怕 0.8B，量化权重也有数百 MB，第一次访问是"白屏等下载"，对跳出率不友好。
WebGPU 覆盖：桌面 Chrome/Edge/Firefox 可用，移动端支离破碎——而移动端恰恰是端侧最大的潜在场景。
冷加载慢：权重进显存 + 编译 shader，首次推理前有可观等待，需要 UI 明确管理预期。
能力天花板：端侧能跑的 0.8–4B，智能水平（Intelligence Index 约 9 / 16 / 27）只够轻量问答、改写、结构化抽取；复杂推理、长链 Agent 仍要 9B+ 乃至云端。
"满血"诱惑：397B-A17B 参数好看，但它和"端侧"完全是两个世界；把旗舰能力写进端侧需求是常见的需求错配。

5.3 反方观点

"端侧不如直接调 API"：对追求质量的场景成立——4B 的能力确实远不如云端旗舰。端侧的价值在隐私、零成本、离线、零后端，不在能力上限。
"WebGPU 还太早"：移动端覆盖差是事实；但桌面端已足够支撑"轻量 AI 功能"这一层，作为渐进增强（progressive enhancement）是站得住的。

六、个人结论

一句话定性：Qwen3.5 把"小模型能力"和"长上下文 + 多模态"拉到了端侧可用线，但**"满血旗舰"与"端侧部署"在物理上互斥**——这张大表的真正用途是帮人别选错档。
成本视角：端侧的成本从站长账单转移到终端用户的设备购置费（详见 4.4）——0.8–4B 是甜区，因为它要的设备是大众已有的手机 / 笔记本，增量 ≈ ¥0；9B 起终端硬件成本陡升，397B 旗舰对应的是 ¥200 万级服务器。站长侧端侧确实 ≈ 零成本且天然防刷，这是它压过云端 API 的关键。
是否跟进：跟进，且范围明确——端侧只认 0.8B / 2B / 4B，9B 列为"实验性上限"，27B 及以上只作云端选项，不进端侧讨论。
下一步行动：
1. 本站 /web-llm 维持 0.8B 默认 + 2B/4B 可选，与本表结论一致，无需改档。
2. 给 /web-llm 增加设备能力探测：无 WebGPU / 移动端时直接提示"建议桌面 Chrome"，而不是让用户白等。
3. 观望 9B 的浏览器实测：等出现稳定的 onnx-community/Qwen3.5-9B-ONNX 浏览器 demo 再评估是否加入可选档。
4. 旗舰线（122B / 397B）只做知识储备，不投入端侧工程。
适用场景：端侧 AI 选型、/web-llm 迭代、向他人解释"为什么浏览器里只能跑小模型"。

七、信息来源

一手 / 官方

技术细节 / 二手交叉验证

成本 / 价格

注：显存数字来自上述二手硬件指南的公开口径，为 Q4 量化近似值，会随推理框架、上下文长度、量化方案浮动；端侧规划请以实测为准。

一、是什么

二、为什么重要

2.1 端侧把"部署门槛"直接清零

2.2 GDN 架构让"小模型 + 长上下文"第一次在消费级硬件上成立

2.3 选型错配的代价很高

三、关键玩家与生态

四、技术 / 实施细节：端侧部署对照大表

4.1 这张表的分界线

4.2 容易被忽略的显存项：KV 缓存

4.3 端侧落地清单（以本站 /web-llm 为参考）

4.4 成本预估：先分清"谁出钱"

A. 终端硬件购置成本（端侧真正的成本所在）

B. 站长侧成本：端侧 / 云端 API / 自托管 三条路径

五、争议与风险

5.1 代际错位：用户清单里的 14B / 32B / 72B 不存在于 Qwen3.5

5.2 端侧的真实痛点

5.3 反方观点

六、个人结论

七、信息来源

一手 / 官方

技术细节 / 二手交叉验证

成本 / 价格

讨论

一、是什么

二、为什么重要

2.1 端侧把"部署门槛"直接清零

2.2 GDN 架构让"小模型 + 长上下文"第一次在消费级硬件上成立

2.3 选型错配的代价很高

三、关键玩家与生态

四、技术 / 实施细节：端侧部署对照大表

4.1 这张表的分界线

4.2 容易被忽略的显存项：KV 缓存

4.3 端侧落地清单（以本站 /web-llm 为参考）

4.4 成本预估：先分清"谁出钱"

A. 终端硬件购置成本（端侧真正的成本所在）

B. 站长侧成本：端侧 / 云端 API / 自托管 三条路径

五、争议与风险

5.1 代际错位：用户清单里的 14B / 32B / 72B 不存在于 Qwen3.5

5.2 端侧的真实痛点

5.3 反方观点

六、个人结论

七、信息来源

一手 / 官方

技术细节 / 二手交叉验证

成本 / 价格

讨论

4.3 端侧落地清单（以本站 `/web-llm` 为参考）

B. 站长侧成本：端侧 / 云端 API / 自托管三条路径

4.3 端侧落地清单（以本站 `/web-llm` 为参考）

B. 站长侧成本：端侧 / 云端 API / 自托管三条路径