开放模型的价值，怎样才能变成普通人用得起的能力？

先想几个具体的活儿。你要从内部报价里找出单价和交期，但采购文件不能上传外网。或者你在断网的现场查设备手册，答案还得对得上型号。

做内容的人也有自己的账要算。未发布的产品素材，可能需要留在自己的机器上。长期做vlog、短视频或短剧，即使没有保密要求，也会想问：一直按量付费，和自己部署，到底哪个划算？这些都是用来分析需求的假设场景，不是我的亲身经历。

把任务摆出来，问题就好聊了。模型能不能干这个活？整套流程要吃多少内存，手头的机器能不能跑？即使跑起来了，等待和返工又要花多少时间？

这篇就顺着这些问题往下聊。从文字推理、文档和图像理解，到检索、语音，再到生图和生视频。模型怎么选，量化怎么配，硬件该不该买，最后都要回到实际交付。

**先说清资料和实测的范围。**资料核验到2026年10月15日。文中的模型配置、设备规格都有论文或官方文档出处；厂商成绩会注明条件，算例会写明假设。

我没有在自己的设备上完成这些性能、能耗和成本测试。后面的实测章节是一套待执行的方案。模型和设备也是代表性候选，没有把全球最新产品全部列完。

第一章：先确定部署边界，再判断本地运行是否必要

装了本地工具，还得看它实际怎么运行。LM Studio说得很清楚：模型下载好以后，聊天、文档问答和本地服务可以离线用；下载模型仍需要联网。 $25$ $26$ Ollama也有本地和云端模型之分，可以关闭云模型和网页搜索。 $25$ $26$ 所以，光看桌面上多了一个软件图标，还不能确定请求一直留在设备里。 $25$ $26$

我的建议是先写清几件事：资料能发到哪里，什么时候可能断网，最多能等多久，拿什么标准判断答案可用。再去找模型和运行时。 $25$ $26$ $13$ 这只是选型方法。公开文档并没有证明哪类企业一定要本地部署，也没有证明本地必然更安全、更便宜。 $25$ $26$ $13$

拿报价抽取来说，你可能需要供应商、币种、单价、交期，还要能回到原文核对。查内网手册，要留意型号和版本，引用也得准确。

离线巡检更关心断网后能不能完成任务、要等多久。私有代码辅助则要看修改能否测试，以及代码允许流向哪里。这些都是假设任务。你的业务有没有迫切需求，还是得看实际的数据边界和工作条件。

会议录音和扫描件还要再拆一步。转写或解析之后，通常还有检索、生成和校验。测试时得逐段核对，哪些在本地，哪些仍要联网。 $25$ 不能只把生成模型搬回电脑，就说整条流程离线了。 $25$ LM Studio文档说明的是它自己的本地文档处理范围，不能直接套到所有插件和第三方应用上。 $25$

**还有一个很直接的理由：长期用下来，本地可能更省钱。**资料可以上云，网络也没有问题，照样值得算这笔账。

前提是质量、交付时限和工作量都能对齐。在这个前提下，如果本地的完整成本低于长期按量调用或租用算力，选本地就有经济上的理由。不必先找一个隐私或断网需求。不过，这个判断有条件，并不代表本文已经测出了"本地普遍更便宜"。

这笔账得把反复生成、多版本修改、批处理、复核和重试都算进去。单次调用便宜，不代表整个月便宜。

做短视频、vlog或短剧，可以把脚本、素材整理、字幕、图片、镜头和配音分开算。哪些本地做，哪些还需要云端，逐项比较。后文的工作流和核算方法都是构造示例，不是行业平均用量，也不是我的省钱经历。云端不允许用，就和人工流程比；允许用，就拿实际优化过的云方案来比。

先弄清为什么要本地跑，再考虑买硬件。资料要留在本地、断网也得干活、等待不能太久，都可以写成具体的验收要求。后面的技术选择，围着这些要求来。

哪些业务条件会驱动本地执行？

下面这张表是选型建议。有些是数据和联网的硬限制，有些是长期用量带来的成本考虑。对你的业务确实成立，才算迫切需求。"用了内部资料"，也不等于所有云服务都不能用。

业务条件	迫切性来自哪里	必须验证的完整流程
报价、合同或内部手册被明确要求不出指定环境	数据流向是准入条件	解析、检索、推理、日志和插件是否遵守同一边界
巡检、船舶、地下场所等任务时段无法联网	必须在断网时完成工作	权重、词表、索引、语音及文档解析资源是否齐备
摄像、语音与控制流程有严格响应上限	网络等待或波动可能使流程不达标	采集到结果的全链路时间、连续运行与失败回退
长期高频调用、批量生成或多版本迭代	同质量及时限下，本地完整成本可能低于长期按量调用／算力租赁	累计账单、合格产出、设备利用率、复核与完整持有成本
未发布产品的图片编辑与视频草稿被要求留在工作站	原始素材的流向与交付时间共同约束	编码器、生成网络、VAE、节点与上采样是否本地执行
已有可用设备，需要离线或可控版本的个人助手	可用设备与版本管理需求	固定模型修订、数据边界、恢复与维护工时

有了这些条件，才知道该拿谁来比较。云端不能用，可以和人工流程比；云端允许用，就把它当成一套完整方案，用相同标准验收。本地是不是更安全、更省钱，还得另看证据。

任务不同，模型与验收也要分开

先分清"看懂图"和"生成图"。Gemma 4这里对应的是理解任务。Qwen-Image-2.1-Turbo提供图像生成和编辑，Wan、LTX则有本地视频或音视频生成管线。它们要做的实验、要算的资源，不能混在一起。 $31$ $42$ $44$ $45$

下面按七组任务看。业务样例是给后续测试用的假设，验收办法也是建议，没有把它们当成需求调查、客户案例或已经测出的结果。

任务组	业务实验样例	可核对候选或组件	建议验收内容
文字推理、代码与结构化输出	报价抽取、规则判断、测试生成	LFM／Phi／SmolLM等 $33$ $34$ $35$ $39$	正确率、格式有效率、推理与输出预算
图像／文档理解	手册图片、单据、图表问答	Gemma 4 等理解模型 $31$	OCR和问答分开，原文证据与版本
嵌入与检索	私有资料搜索、多模态近邻检索	EmbeddingGemma 2、LFM Embedding $40$ $37$	召回、重排及索引成本，不能只测聊天
语音识别	离线录音转写	Qwen3-ASR $38$	字词错误、实时率、单路延迟、语言
语音生成／交互	离线语音回复	LFM2.5-Audio $36$	首段语音等待、连续性与语言限制
文生图、图像编辑	构造海报、产品背景修改	FLUX、Qwen-Image、Z-Image $41$ $42$ $43$	提示遵循、文字、主体保持与返工
文生视频、图生视频、音视频	构造演示片段与镜头草稿	Wan、LTX、HunyuanVideo $44$ $45$ $46$	总耗时、帧间一致性、运动、音画与失败

语音模型尤其要看语言。这里引用的LFM2.5-Audio-1.5B模型卡只写了English，不能顺手拿它推荐中文会议。Qwen3-ASR有多语种和中文方言材料，但ASR只是语音识别，不等于语音合成或整套对话系统。 $36$ $38$

检索也一样。LFM的单向量嵌入、ColBERT路线，以及EmbeddingGemma 2的多模态向量，都是检索组件。能在本地加载，不代表能拿来生成聊天回答。 $37$ $40$

短视频、vlog与短剧，分别在哪些环节考虑本地？

做内容也可以这样拆。下面这些工作流是我的设计建议，不是行业访谈，更不是劝所有人先买显卡。

转写可以验证Qwen3-ASR。文字和图像理解要找对应模型；生图、生视频则分别核对FLUX、Qwen-Image、Wan、LTX的整套管线。别指望一套聊天模型包办。 $38$ $31$ $41$ $42$ $44$ $45$

从业场景	可以拆出的本地任务	促成本地化的条件	主要验收与边界
口播、知识短视频	素材转写、段落切分建议、脚本改写、字幕与标题候选	每期大量原始录音与多轮改稿，累计调用费用高于本地成本	人名数字、事实、字幕时间轴、剪辑采用率；字幕对齐组件另验
日常／旅行vlog	实拍素材整理、画面检索、旁白草稿、字幕、封面候选	原始素材量大、持续整理且已有合适剪辑设备	不能凭空补地点、事件或亲历；实拍与生成补充素材分开管理
AI短剧、漫剧与动态分镜	剧本拆场、角色／场景表、分镜图、镜头候选及局部重做	多镜头、多版本持续迭代，且开放模型能达到交付质量	角色与服饰一致性、场景连续、镜头可剪辑性；按合格镜头计成本
电商带货、商品短视频	卖点草稿、商品抠图／背景编辑、镜头与封面变体	多SKU、多画幅、多版本的长期生产	商品形状、标识和文案事实保持，不能以美化改变商品属性
品牌广告、门店／文旅内容	授权素材检索、脚本版本、海报与补充镜头	多项目复用、批量交付或未发布素材的边界要求	品牌要素、地点事实、画幅与交付规格；高要求镜头可保留云端
课程、访谈、播客切片	长音视频转写、章节提取、片段候选、字幕和简介	处理量长期稳定，人工整理与按量服务成本需要压缩	原话与上下文是否准确；模型提出片段，人工决定是否采用
影视／短剧后期素材辅助	镜头标签、场记检索、生成占位素材、局部编辑候选	可复用的本地素材库与反复修改需求	不把生成占位当最终合格镜头；编码、修复、上采样另核工具
多语种内容运营	转写、翻译草稿、字幕、配音与口型环节的组合验证	多语言、多版本持续制作，逐环节比较有经济空间	中文／目标语言、音色、时间轴与口型分别验收；ASR不等于TTS或口型生成

也不用非得全部本地化。本地做转写、检索、脚本和大量草稿，关键镜头或忙不过来的峰值任务再交给云端，这也是一种方案。

如果项目不多，用量忽高忽低，或者本地模型达不到角色一致性和交付时限，按量服务可能更合适。要比较的是整套工作流，不是谁能把整条短剧生产线都搬回电脑。

第二章：端侧模型选型，不能只按参数量排队

看到模型名里的"几B"，先别急着算内存。总参数、每个token激活的参数、有效运行负载，至少要分开看。 $3$ $4$ 比如Qwen3-30B-A3B，总参数是30.5B，激活参数是3.3B。Google说明，Gemma 3n E2B在标准执行时加载的参数超过5B；要用上参数跳过、PLE缓存等机制，才能得到更低的有效内存负载。 $3$ $4$ 名字里的数字，还不是完整的内存规格。 $3$ $4$

Dense可以先按全部权重估算驻留负担。MoE就得多问一句：没激活的专家放在哪里？它们仍要存下来，或者从其他存储层级取进来。 $3$ $8$ 把30.5B模型只按3.3B算体积，剩下的专家就漏了。 $3$ $8$ 当然，这也不等于所有运行时都要把全部专家同时塞进显存。存储方式和卸载机制得一起看。 $3$ $8$

传统注意力模型还要看KV头数。GQA研究的是在MHA和MQA之间怎么选KV头数。论文实验里，它拿到了接近MHA的质量和接近MQA的速度，但这个成绩不能直接套到任意硬件上。 $1$ $2$ Qwen3-4B有36层、32个查询头和8个KV头，可以拿来做常规GQA缓存的研究基线。 $1$ $2$

混合架构得换个算法。Qwen3.5-4B一共有8组"3层Gated DeltaNet加1层Gated Attention"，合计32层。 $5$ $6$ 递归状态和注意力缓存不是同一种东西，不能把所有层都按完整KV历史算。 $5$ $6$ Qwen3.5-0.8B也有混合布局，但系列介绍里提到MoE，不代表这个规格的FFN就是MoE。还是要查具体配置。 $5$ $6$

Apple的2025技术报告也提供了一个例子：约3B的端侧模型，同时用了架构优化、KV共享和2-bit量化感知训练。 $27$ 这说明模型训练和执行可以一起设计。不过，不能由此得出"随便一个模型事后压到2-bit也不掉质量"。Apple这个系统模型也不能当作可自由下载的开放权重候选。 $27$

下面这张表用来比较机制，不是同质量排名，也不保证某台硬件一定能跑。 $2$ $3$ $4$ $5$ $6$ $7$ 换了模型，训练数据、架构和模态可能都变了。这时比较的是整套部署方案，不能说只测出了参数量或某个架构的独立作用。 $2$ $3$ $4$ $5$ $6$ $7$

候选或研究案例	可核对的配置	适合回答的技术问题	使用边界
Qwen3-4B	4.0B、36 层、GQA 32Q/8KV $2$	常规注意力与量化基线	业务质量需实测
Qwen3-30B-A3B	总 30.5B、激活 3.3B $3$	MoE 计算与存储口径	激活参数不代表完整权重
Qwen3.5-0.8B	混合层布局，模型卡强调原型与研发 $5$	小规格与任务微调候选	不承诺通用生产效果
Qwen3.5-4B	24 层 DeltaNet、8 层注意力 $6$	混合状态与长输入预算	需额外核对视觉组件
Gemma 3n E2B	标准执行超过 5B 参数 $4$	有效参数与运行时优化	优化依赖执行实现
MiniCPM-V 4.7	35B-A3B 与 1B 两种规格 $7$	端侧多模态与专家调度	官方性能不代表本机结果

先看任务需要什么能力，再选能做到的规格。"1B只能分类""8B足够编程"听着省事，可上面的配置资料没有证明这种绝对分档。别拿它当选型依据。

从机制基线到近期候选

近期候选里，可以看看Gemma 4。官方把E2B、E4B定位到移动和边缘，也列了更大规格。E2B的有效参数是2.3B，含嵌入的参数口径是5.1B；E4B对应4.5B和8B。不能只按名字里的数字估全部权重。 $31$ 它支持图像、音频等输入，输出文本，也有本地代码。但你的手机能否承受峰值内存、能不能持续跑，仍要验证。 $31$

Qwen3.8要按实际开放的规格看。这次在官方README里核到的是27B、Flash-Next等，没有确认0.8B／2B／4B／9B的小规格。社区蒸馏或合并出来的名字，不能写成官方发布。 $32$ 所以资源有限时，Qwen3.5小规格仍能做基线；27B等新规格要另算硬件预算，不能统一贴上"手机可运行"。 $32$

LFM2.5里也有两条不同路线。2.6B型号的精确总参数是2.69B，混合短卷积与GQA，有GGUF、ONNX、MLX等本地入口。它能处理文本和工具调用，不代表复杂agentic coding就有保证，模型卡里的任务限制还得看。 $34$

24B-A2B则是24.0B总参数、2.45B激活参数，结合短卷积、GQA和MoE，也有官方量化与本地执行材料。名字里的A2B，既不是完整权重，也不是精确的激活量。 $39$

还可以把Phi-4-mini-flash-reasoning和SmolLM3放进基线。前者是3.8B混合推理架构，最高吞吐宣传用的是A100-80GB，不能当成手机成绩。后者有多个本地引擎入口，但重点语言和中文覆盖也有限制。 $33$ $35$ 这里把它们列进来，是因为架构和复现路径值得看，不是说它们就是各自家族全球最新的型号。

近期候选	任务身份	本地证据	必须保留的边界
Gemma 4 E2B／E4B	多模态理解与文本输出 $31$	官方端侧定位与本地代码 $31$	有效参数、全参数分列；目标手机需验证
Qwen3.8-27B	文字任务候选，按具体卡核验 $32$	官方开放仓库 $32$	不伪造同代小型号，不以27B保证手机适配
LFM2.5-2.6B	文本与工具使用候选 $34$	官方多种执行格式入口 $34$	保留模型卡的任务限制
LFM2.5-24B-A2B	推理与混合 MoE $39$	官方本地量化入口 $39$	激活2.45B不代表完整权重
Phi-4-mini-flash-reasoning	混合架构推理案例 $33$	官方CUDA代码 $33$	A100结果不移植到手机
SmolLM3-3B	开放训练与双模式推理基线 $35$	多运行时本地入口 $35$	不保证中文业务质量

Dense、MoE与权重稀疏，先把机制分清

MoE的"稀疏"，说的是每个token只走一部分专家。Mixtral原论文的例子是：每层8个FFN专家，选2个；下一个时刻可以换专家。这样减少了当步参与的专家计算，并没有把专家内部的矩阵权重剪成零。 $61$

权重稀疏是另一回事，指参数张量里有些元素为零。PyTorch教程提醒过：只是把参数置零，不会自动降低延迟或内存开销，还得配上存储格式和计算内核。 $62$ 如果仍按稠密张量存、用稠密矩阵核算，就不能指望按稀疏率等比例省时省内存。 $62$

NVIDIA的2:4又是特定的结构和硬件机制。TensorRT要求沿规定轴检查每四项里的零值。即使满足条件，某些形状下也可能选更快的Dense tactic。 $63$ 所以理论稀疏吞吐、是否符合结构要求、最后用了哪个内核，是三件事。更不能把这些和MoE的top-k激活混算。 $61$ $63$

名称	稀疏发生在哪里	获得收益还需要什么	不能直接推断
MoE 条件稀疏	token 选择的专家子网络 $61$	路由、专家内核、缓存与数据流 $64$ $66$	等于小Dense的内存或延迟
非结构权重稀疏	权重矩阵中的任意零值 $62$	压缩布局与匹配稀疏内核 $62$	置零即可等比例省时省内存
2:4 半结构稀疏	指定维度的固定零值结构 $63$	支持精度、硬件、算子与tactic $63$	整机快两倍或所有MoE自动获益

后面主要比较Dense和路由MoE。硬件参数里如果写了sparsity，会单独看它指什么，免得把模型稀疏和芯片的峰值指标混在一起。

稠密与稀疏，哪个更适合端侧？

全部权重都在GPU里时，MoE每个token只激活部分专家，确实有减少FFN计算的机制。不过，路由、分组、投影和合并也要花资源。Transformers文档里，小批量的batched_mm和按专家分组的grouped_mm就分开实现。后端会影响效率，光读激活参数猜速度不够。 $61$ $64$

显存装不下，情况又变了。如果专家要从主存按需搬进GPU，传输可能卡住后续计算。预取能不能命中、搬运能不能和计算重叠，就很关键。MoE-SpeQ研究了这类场景，但成绩只对应它测的模型和基线，不能证明任意卸载MoE都比全驻留Dense快。 $66$

还有一种做法：专家由CPU执行，其他层交给GPU。llama.cpp的--cpu-moe和--n-cpu-moe会把对应专家权重留在CPU。 $67$ $66$ 这和每一步经PCIe把同一批专家权重搬进GPU，不是同一条执行路径。要分别看CPU的带宽与计算，以及激活、权重各自怎么传。 $67$ $66$

batch变大或prefill变长，也不能简单说MoE一定更慢。多个token可能访问更多专家，每个专家分到的token数也会变。ExFold区分了prefill和decode的专家流量，运行时也有按专家分组的计算。 $65$ $64$ 专家覆盖扩大可能增加流量，但权重复用和矩阵利用率也可能改善。这两面都得测。 $65$ $64$

资源与场景条件	建议先验证的方案	必须核对的判据
紧内存、固定任务、交互式单路	全驻留紧凑Dense作为基线	业务合格率是否已足够、持续延迟
MoE全部权重能驻留、内核支持充分	Dense与MoE同质量对照	路由、缓存、FFN、注意力的总耗时
Dense能驻留、MoE必须动态搬专家	先保留Dense基线，再测卸载MoE	预取命中、传输、首字与逐字等待
大主存＋有限显存	CPU专家混合执行与动态搬运分别测	CPU带宽/计算和跨后端传输不可混记
多人并发、长输入	测量专家并集与每专家token分布	质量门槛下吞吐、排队和尾延迟
手机专门优化MoE	不能预先排除MoE	需移动运行时、实际设备和持续测试

表里给的是验证顺序，不是实测排名。紧凑Dense可以先做基线，但别顺手推出"手机不适合MoE"。专门设计架构和移动实现的MobileMoE，就是需要保留的反例。 $86$

比较之前，先说清"相同"指什么。总参数相同，激活量和质量未必相同；激活量相同，完整存储、注意力和路由也没对齐。

如果比较相同内存预算，就固定设备、任务、上下文和并发，把各自的量化、缓存、卸载配置交代清楚。要单独研究架构影响，再做精度和执行条件尽量一致的受控实验。若比较同等任务合格率，则先用同一业务集验收。

DeepSpeed-MoE用过quality-equivalent Dense作为特定实验对照。 $68$ 但上面这四种比较口径，是本文的实验设计，不是论文规定的通用标准。

算个理想体积，就能看出差别。假设全部权重都是纯4-bit，不含元数据，4.0B Dense是2.0GB，30.5B总参数的MoE则是15.25GB。不能拿后者3.3B的激活量替代完整权重预算。 $2$ $3$ 模型配置来自模型卡，体积是按假设算出来的；这没说明两者同质量或同速度。

图像与视频：模型大小必须连同整条管线解释

生图可以先核对这几个候选。FLUX.2 $klein$ 4B有本地Diffusers路径。Qwen-Image-2.1-Turbo是同架构的加速checkpoint，其中7B说的是视觉生成组件，不一定等于整套运行权重。Z-Image-Turbo则有6B模型和本地推理路径。 $41$ $42$ $43$ 列在一起方便查，不是跨硬件的速度榜。

Qwen Turbo有个容易忽略的细节：八步sigmas保存在checkpoint里，会自动加载。只改num_inference_steps，覆盖不了这套采样计划；use_kv_cache还能复用文本和参考图上下文。 $42$ 所以不能说"所有扩散模型都没有KV Cache"。更准确的说法是：自回归LLM那套完整历史KV公式，不能直接拿来算这些管线的总峰值内存。 $42$ $48$

显存数字也要连条件一起读。FLUX模型卡写约13GB VRAM，产品表里4B却是8.4GB。公开页面没有给足统一配置，没法直接归一，就把两种口径都留着，别挑小的当购买保证。 $41$ $47$ Z-Image的消费卡内存声明，和H800的低延迟声明，也不是同一台机器的成绩。 $43$

视频这里看三条路线。Wan2.2-TI2V-5B支持文生／图生视频，官方至少24GB显存的示例，启用了模型卸载、数据类型转换、CPU文本编码器等选项。这不是整套管线全驻留显存的要求。 $44$

HunyuanVideo-1.5是8.3B架构，官方最低14GB GPU memory也带着model offloading前提，分辨率和其他组件仍要查。 $46$

LTX-2当前README推荐LTX-2.5。要下载的包括22B DiT、专门配套的Gemma 4 12B文本编码器，还有视频及音频VAE、上采样组件。 $45$ 这一组文件约66GiB，说的是磁盘体积，不是显存需求。配套编码器也别随手换成其他项目的原版Gemma 4。 $45$

生成候选	本次核对的身份	可以引用的运行条件	不能作出的推断
FLUX.2 $klein$ 4B	图像生成与编辑 $41$	官方本地代码；显存声明有页面差异 $41$ $47$	4B权重体积等于完整管线显存
Qwen-Image-2.1-Turbo	7B视觉组件、加速checkpoint $42$	八步采样计划及CUDA代码 $42$	开放权重自动等于Apache；已验证任意手机
Z-Image-Turbo	6B蒸馏图像生成 $43$	官方16G消费设备声明 $43$	H800延迟就是16G消费卡延迟
Wan2.2-TI2V-5B	文生／图生视频 $44$	至少24GB示例含卸载与CPU文本编码 $44$	所有Wan都适用该条件；全显存驻留
LTX-2.5	音视频生成管线 $45$	独立DiT、定制编码器、VAE与优化项 $45$	66GiB下载量就是运行显存
HunyuanVideo-1.5	8.3B视频生成 $46$	14GB带model offloading前提 $46$	不同分辨率与组件都同一门槛

这里选Wan2.2和HunyuanVideo-1.5，是因为查到了可下载权重、执行脚本和硬件条件，不是认定它们就是家族最新产品。 $44$ $46$ 更新型号如果只有服务入口，没有对应公开权重和代码，就不能放进本地部署清单。

第三章：量化必须说明对象、分组、校准与执行内核

聊量化，先问压缩的是哪一部分。AWQ研究低比特分组权重，会观察激活来找重要通道，但不代表激活也压到了同样位宽。SmoothQuant研究的是W8A8，也就是权重和激活都是8-bit。KV Cache量化压缩的则是历史注意力状态。 $17$ $19$ $22$ 一句"已经INT4"，交代不了这些区别。 $17$ $19$ $22$

再看具体怎么量化。GPTQ是用近似二阶信息做后训练权重量化，原论文用C4里128个、每个2048 token的片段校准。AWQ主要实验的分组大小是128，还会按激活搜索通道缩放。 $18$ $17$ 这些是论文里的配置，不是所有工具永远固定的要求。 $18$ $17$

group size决定多少权重共用缩放等量化参数。GPTQ讨论过，更细的分组会牵涉质量和元数据开销。 $18$ 所以只写位宽，别人还复现不了。至于中文字段抽取或代码修改会掉多少质量，原论文没法替新模型回答，得拿相应数据再测。 $18$

用一套假设编码算一下：每组g个权重，每个b bit，另存16-bit scale和16-bit zero，平均就是b+32/g位。b=4时，g=128得到4.25 bpw；g=32得到5 bpw。 $18$ $20$ 这里只说明元数据怎么影响体积，不是GGUF、GPTQ、AWQ的通用文件公式。实际方案可能没有zero，也可能压缩scale或采用别的布局。 $18$ $20$

python 复制代码

4 + 32 / 128  # 4.25 bpw
4 + 32 / 32   # 5 bpw

GGUF首先是文件格式，里面有元数据和张量。general.file_type描述多数张量的类型，general.architecture描述网络架构。 $16$ $9$ 引擎能读容器，不等于已经实现其中全部网络和数值编码。Safetensors这些容器名，也代替不了量化配置和执行内核说明。 $16$ $9$

这次采集的llama.cpp源码里，Q4_K、Q5_K基础块把缩放等元数据算进去后，分别是4.5、5.5 bits per weight。Q4_K_M、Q5_K_M还会给不同张量分配类型，有些用Q6_K。 $20$ $21$ 所以文件名里的4或5，不是全模型每个参数的严格位宽。配方也会随版本变，不能把旧规则当永久规范。 $20$ $21$

需要记录的参数	为什么影响判断	本文采用的记录方法
权重位宽及具体配方	相同名义位宽可有不同张量分配 $20$ $21$	文件哈希、配方名与实际张量类型
group size、scale、zero	决定量化粒度与元数据负担 $18$	从转换配置记录，不凭文件名猜测
校准集及版本	AWQ、GPTQ 的过程使用校准信息 $17$ $18$	记录来源、数量与是否覆盖任务
激活和计算数据类型	W4A16 与 W8A8 并非同一执行方式 $17$ $19$	与权重精度分列
KV 类型与缓存策略	权重量化不自动压缩缓存 $22$	K/V 精度、上下文、并发分列

文件更小，为什么不一定更快？GPTQ原论文的加速实现强调少搬内存，不是按同比例少做计算；AWQ则涉及融合反量化内核。 $18$ $17$ $23$ 后端怎么读取、解码、计算这些数值，才决定实际收益。文件体积不能直接证明端到端延迟。 $18$ $17$ $23$

想验证量化，先固定模型和设备。拿一个较高精度参照，再选两种机器能承载的量化方案，分别看质量、内存和延迟。这里只给测试办法，不提前押Q4_K_M、AWQ或别的方案获胜。

先核对参照精度，再谈更低位宽

参照精度也不能默认用FP16。EmbeddingGemma 2总参数740M，文本、视觉、音频编码器可以按需加载，但官方要求BF16或FP32。FP16会出现NaN，或悄悄损失质量。 $40$ 所以先查模型支持什么精度，再往低位宽压。 $40$

第四章：内存预算要算权重、缓存与工作区，速度还要看搬运

先算权重，最基础的式子是：参数个数×每参数位数÷八。 $20$ $21$ $22$ 但这只是理想编码的体积。分组参数、混合精度和元数据还没加进去，运行时的缓存、临时空间也没算。所以别把下表直接当成显存需求。 $20$ $21$ $22$

下表都是计算值。GB按十进制10^9字节，GiB按2^30字节算。元数据、KV、工作区、系统和其他程序的占用都不在表内。 $20$ $22$ 买硬件不能只照这个数字。 $20$ $22$

假设参数数量	16-bit 理想权重 GB	8-bit 理想权重 GB	4-bit 理想权重 GB
1B	2	1	0.5
3B	6	3	1.5
4B	8	4	2
8B	16	8	4
14B	28	14	7
32B	64	32	16

缓存也能按形状估算，但要先限定模型：各层结构相同，保留完整历史，K/V维度相同，精度固定。在这些条件下，常规注意力模型的缓存约为：2×层数×token数×KV头数×每头维度×元素字节数×同时缓存的独立序列数。 $22$

这里的2对应K、V两组张量，推法与Hugging Face的KV内存说明一致。实际分配的粒度和元数据，还要另加。 $22$

举个不对应具体模型的假设：32层、8个KV头、每头128维、8192 token、FP16、单序列。代进去是2×32×8192×8×128×2=1,073,741,824字节，也就是1 GiB。 $22$ 其他不变，token数涨到32768，就是4 GiB。再同时保存四个独立、没有前缀共享的同长度序列，就到了16 GiB。 $22$ 这些是算出来的，不是实测。 $22$

python 复制代码

2 * 32 * 8192 * 8 * 128 * 2
# 1,073,741,824 字节，即 1 GiB

遇到MLA、滑动窗口、跨层KV共享、混合递归、量化缓存或共享前缀，先停一下，别直接套公式。 $6$ $27$ $22$ 比如Qwen3.5-4B部分层用DeltaNet，Apple报告里又有KV共享，都不能机械地按"全部层×完整序列"来算。 $6$ $27$ $22$

速度则要把输入处理和逐token解码分开。Roofline论文把算术强度与设备计算、带宽上界联系起来：某些长输入、低批量配置的prefill投影计算受算力限制，decode更容易受内存访问限制。 $23$ 但短prefill也可能受内存限制。batch、缓存长度、算子融合、卸载都会改变瓶颈，不能给两个阶段永久贴上同一种标签。 $23$

这也是为什么CPU、GPU、NPU的理论算力，不能直接换算成生成速度。 $9$ $13$ $12$ 模型形状、数值类型、算子支持、真实访存、跨设备通信，都得看。llama.cpp有CPU/GPU混合执行能力，不等于任意组合都快；ONNX Runtime的EP和ExecuTorch的委派，也还有算子分配和回退问题。 $9$ $13$ $12$

我会把内存预算分开记：全部驻留权重，包括视觉／音频编码器；缓存状态；工作区，包括多模态中间表示；再加运行时开销。独显机器还要分别记主存和显存峰值。编码器如果已经算进权重，就别再加一次。 $22$ $26$ $10$

至于统一留多少百分比，这次资料没有给出跨模型、跨运行时都适用的安全余量。 $22$ $26$ $10$ 能加载成功，也只说明当时分配成功。长输入和并发能不能撑住，是下一步要测的事。 $22$ $26$ $10$

图像与视频的内存不能套用语言模型公式

图像和视频还要看VAE slicing／tiling、整组件卸载、分组卸载，以及逐层存储和计算各用什么精度。Diffusers提醒过，有些VAE不支持相应切分，搬运也可能增加主存占用和耗时。 $48$ 所以各阶段的峰值要分别记，不能换个模型名，就继续沿用语言模型那张预算表。 $48$ $45$

中间特征缓存也得单独看。Diffusers里的PAB、FasterCache、FirstBlockCache、SeaCache会复用部分计算，但支持范围、参数和质量取舍不同。跳步间隔太大可能掉质量，SeaCache也是可能改变输出的近似优化。 $60$ 不能统称"无损加速"，更别把一个模型的参数原样搬给所有视频模型。 $60$

最新代表硬件：容量、带宽、功率与供货分别看

再看硬件。下面列的是代表性平台，没有把全部最新产品列完，也没把发布公告当成当地现货。看容量时先分清：芯片支持上限、具体整机配置、独显显存、统一系统内存，说的不是同一件事。标称带宽也不是引擎保证能跑到的实测带宽。 $69$ $71$ $74$ $77$ $82$ $83$ $84$

手机先分芯片公告和实际整机。Qualcomm活动公告列了Gen6和Extreme Gen6，Samsung验证的是Extreme Gen6配16GB LPDDR6。不能说所有量产手机都是这个配置。没有总线信息，也不能把I/O速率直接换成总GB/s。 $79$ $80$ $97$

iPhone18 Pro系列有A20 Pro的官方上市公告，但这份公告没给RAM、内存带宽和SoC TDP。这里就留空，不拿传闻补数字。 $81$

手机／轻薄本资源	内存口径	可引用的功率／性能口径	研究日边界
Snapdragon 8 Elite Gen5	平台最高24GB、LPDDR5x最高5300MHz $78$	不提供统一SoC持续TDP或模型速度	仍可作既有设备基线，不是最新公告代际
Snapdragon Gen6／Extreme Gen6	仅Extreme Gen6：Samsung验证16GB LPDDR6；普通Gen6本次未核该配置 $79$ $80$ $97$	验证I/O速率不等于总带宽或端侧吞吐	已公告；本次不确认具体手机到货
A20 Pro／iPhone18 Pro	RAM容量／带宽未由所引公告披露 $81$	Neural Engine存在不是模型支持保证	官方9月18日上市，不保证当地库存
Core Ultra X9 388H／Series3	处理器支持最高96GB、LPDDR5X9600MT/s $82$	Base25W、Turbo80W，各为处理器定义	不等于任何轻薄本实装96GB
Ryzen AI9 HX470／AI400	处理器支持最高256GB $83$	默认TDP28W、cTDP15--54W	不等于已售笔记本实装256GB
Zenbook A16指定SKU	48GB封装内存、228GB/s $84$	130W为适配器输出，非推理实耗	官方荷兰商店列售配置，非全球库存

有NPU，不等于目标模型全程在NPU上跑。某些算子可能交给CPU或GPU，也可能整套任务都没有走你以为的加速器。峰值TOPS和平台名称证明不了这一点，还是要按第五章的方法查委派日志。 $63$ $82$ $83$ $84$

大统一内存资源	容量与带宽	适合研究的资源方向	可用性边界
Mac mini M6／M5 Pro	最高32／64GB；最高170／307GB/s $70$	紧凑桌面与已有Apple运行路径	官方普通规格9月22日起交付，具体配置另核
Mac Studio M5 Max	40核GPU规格最高128GB；GPU规格对应460或614GB/s $69$	单机驻留容量与桌面推理	容量和带宽须匹配具体配置
Mac Studio M5 Ultra	最高512GB、1.2TB/s $69$	大权重、缓存及多任务容量研究	512GB预计10月下旬，10月15日不可列已交付 $89$
Ryzen AI Halo RAH001／002	128／192GB，256／273GB/s $71$	大主存、集成GPU及混合执行	用户指南列规格，002各地交付未单独证实
DGX Spark	128GB及OEM专供64GB规格、273GB/s $77$	GB10与NVIDIA软件栈的本地开发	64GB被列出不等于已在当地交付

统一内存也不是给模型独占的显存，系统和运行时还要占一部分，得测。功率字段也别混：DGX Spark的240W是电源规格，140W是GB10 CPU+GPU TDP；Mac Studio的480W最大连续功率，同样不是模型平均耗电。 $77$ $69$ $87$ 容量大，有助于驻留更大的模型；能不能比高带宽独显响应更快，还不能由容量推出。 $23$

独立显卡资源	标称显存／带宽	功率字段	选型限制
RTX5060Ti 16GB	16GB、448GB/s $73$ $90$ $91$	TGP180W $90$	8GB版不是同一容量；需要完整主机
国际RTX5090	32GB、1792GB/s $74$ $91$	TGP575W $74$	不可把容量套给中国D v2
中国RTX5090D v2	24GB GDDR7 $88$	以对应SKU完整规格为准	不能沿用国际32GB预算
Radeon AI PRO R9700／S	32GB、640GB/s $72$ $94$	TBP300W $72$ $94$	主动／被动散热及目标软件路径分别核对
RTX PRO5000 Blackwell	48或72GB ECC、1344GB/s $75$	Max Power300W $75$	容量与具体SKU／报价核对
RTX PRO6000 Workstation	96GB ECC、1792GB/s $93$	Max Power600W $93$	不把Workstation功率套给Max-Q版本
RTX PRO5500 Workstation	初步规格84GB、1398GB/s $76$	Up to600W $76$	标为Preliminary，不列确定现货推荐

买独显还得看主存、PCIe布局、机箱、电源和散热，账单不能只剩一张裸卡。多卡跑一个模型，要看运行时怎么划分张量或专家、怎么合并结果。把显存数字相加，不会自动变成统一内存池。反过来，单卡里的专家路由也不能一概叫跨卡网络通信。 $64$ $66$ $74$ $93$

专用边缘设备里，Orin Nano Super开发套件是8GB、102GB/s，功率预算范围7--25W；AGX Thor开发套件是128GB、273GB/s，范围40--130W，两者都有官方历史可用性公告。 $85$ $95$ $96$

接口、部署环境和开发套件身份，要和业务一起看。这些功率字段不能直接当成含载板、风扇、存储、传感器的整机插座功耗，仍需测量。 $85$ $87$ 都是小机器，也不代表处于同一低功耗档；开发套件更不能直接等同于通过认证的工业整机。

硬件怎样与业务场景匹配

下面的搭配是验证建议，还不是测出的最优配置。先写下质量门槛、离线要求、首字和完整任务能等多久，再看并发、温度与能耗限制。模型架构和硬件容量，是用来满足这些条件的。 $64$ $66$ $87$ $23$

场景与硬约束	优先验证的模型方案	硬件层级与观察重点	升级触发条件
手机离线转写、分类、短回复	能达标的紧凑Dense或专用任务模型起步；保留专门优化MoE候选	实际手机的应用可用内存、支持后端、持续温度	当前模型质量不达标或持续延迟超限，再测更强方案
单人知识助手、内部资料问答	分开检索与生成；Dense和MoE按同任务验收	已有PC或较大统一内存；关注上下文和首字等待	证据质量确有改善且完整驻留／可接受卸载才增加容量
私有代码、多步推理	比较推理模式和工具流程，不只比较输出token速度	高带宽GPU或大统一内存候选；检查完整任务时间	更强模型减少返工，或实际任务延迟达到业务价值门槛
批量字段抽取、工单归类	规则／专用小模型／Dense基线，与MoE比较最终合格任务	现有CPU/iGPU或适配NPU；测试批处理和人工复核	质量已够时，优先优化批处理和流程，避免仅为榜单升级
文生图、产品背景编辑	固定生成管线、分辨率、采样与编辑条件	目标管线适配的GPU／统一内存；测去噪和VAE峰值	先消除OOM与严重卸载，再评估高带宽设备是否缩短交付
文生视频、音视频草稿	按完整编码器、生成网络、VAE与上采样验收	高容量GPU／工作站；记录主存、显存、磁盘与时长	更高规格只有降低等待或增加合格素材产出才有价值
现场摄像、语音与控制交互	依据时限选专用模型、Dense或可验证MoE	Jetson等专用边缘平台；接口、功率预算和传感器一起测	满足实时与稳定性之后，再扩大模型或并发
多人内网服务	Dense与MoE在目标并发下同时验收	整机驻留、缓存、排队和专家并集	单用户速度达标但并发尾延迟超限时升级系统

表里有些场景先试Dense，是为了让第一轮验证简单一些，不是断言所有手机或低功耗设备都该选Dense。MobileMoE说明，专门设计的MoE也可以成为移动端候选。 $86$ 同样，128GB统一内存、大显存独卡和40--130W边缘模块，提供的资源并不相同。容量或体积接近，也不能直接互换。 $69$ $71$ $77$ $85$

卡在哪里，先分清。是装不下，还是输入处理慢？是逐token解码慢，还是多人排队？生图、生视频还可能慢在管线解码。找到具体瓶颈，才知道该加RAM、提高显存驻留、改专家缓存，还是换计算设备。峰值算力更高，不是所有问题的通用解法。 $65$ $66$ $23$

性价比和高性能，按合格任务的完整成本取舍

谈性价比，先排除干不成活的方案。质量要够，目标负载下的等待要能接受，峰值内存和持续温度得撑住，数据流向也得允许。哪一项过不了，裸硬件再便宜，也不是同一任务的低成本替代。这里是一套决策办法，不是已经测出的采购结论。

价格也得带日期和地区。2025年美国发布时，RTX5060Ti 16GB版起价429美元，379美元是8GB版；国际RTX5090起价1999美元。 $73$ $92$

2026年中国大陆发布的Mac Studio，M5Max和M5Ultra基配起价分别是19999元、46999元。别把基配价写成128GB或512GB配置报价。 $89$ Mac mini M6、M5Pro的美国发布起价是899、1699美元，也不是中国现价或最高内存配置价。 $70$

这些价格不能跨币种、跨年份，再把裸卡和整机混起来排性价比。Halo、DGX Spark和专业卡，这次没有拿到适用你所在地区、目标配置的可靠现价，就不补数字。

真要采购，先统一地区和含税交付配置。主存、存储、电源、散热、保修，以及必要的软件适配工作，都写进同一份询价表。

这里用一个指标：单位合格任务成本＝（期间分摊购置成本＋电费＋维护工时成本＋人工复核与返工）÷最终合格任务数。

设备用几年、残值多少、利用率多高，要按你的情况填，不能默认每天满载。已有设备要不要继续用，可以分别看新增投入和完整持有成本；别在一种方案里算历史购置价，另一种却不算。

电费得从边界明确的测量来算。MLCommons用的是测试期间整机平均交流功率，在插座测量。TDP配置、电源额定值，不是同一种实测数据。 $87$ 这里只借用这个原则，不说自建测试已经符合MLPerf。600W显卡标称、240W电源、120W平台TDP，都不能各自直接代进公式，当成真实耗电。 $93$ $77$ $71$ $87$

取舍目标	优先验证的策略	何时值得付更多成本
低增量投入	现有设备、足够合格的小模型、允许离线批处理	质量不足或人工复核已超过节省收益
容量与成本平衡	找到刚好跨过完整任务驻留门槛的配置	下一档容量确实避免不可接受的卸载和OOM
高交互性能	目标负载下低首字、低任务延迟与稳定尾延迟	等质量时，减少等待有可量化业务价值
大模型研究容量	大统一内存或高显存方案	允许较慢响应但必须完成更大模型／上下文实验
持续专业部署	实际需要的ECC、散热、I/O与维护条件	这些条件确属业务要求，而非只为更高规格标签

表里是取舍建议。容量大和吞吐高是两个目标；稀疏专家可能少做计算，却多了存储和调度要求。专业卡的ECC、风道也可能是业务需要，但这些规格不能证明所有任务都比消费卡更省钱或更快。 $66$ $75$ $76$ $23$ $93$

两套方案都达标时，可以用新增固定投入，除以每个合格任务的可变成本差，粗算盈亏平衡任务量。先确认差额为正，质量、交付时间和可用性也能对齐。否则这个数没意义。它是带假设的核算办法，不是本文算出的真实回本预测。

长期按量调用与本地部署，怎样算清创作业务的账？

先看账单到底按什么收。文字服务可能分输入、输出、缓存命中和缓存存储。视频有的按视频token，有的按调用秒数；图像API也有按图计费的展示。视频token不能当成文字token，成片时长也不是全部用量。 $98$ $99$ $100$ $101$

火山方舟的视频规则，还区分输入、输出时长、分辨率和帧率，准确用量看API返回。已经结束的限时折扣，这里不拿来当现价。 $98$

按量调用API、按时租GPU、自己买机器，是三本不同的账。API按实际结算规则记。租GPU要看合同计费时长，以及存储、传输和环境费用。自己部署则要看购置或新增投入、分摊、电费、维护、授权和人工。单独拎出一个月订阅费或一次购机款，都代表不了整套任务成本。

做vlog或短剧，可以先给项目记一份流水：原素材多少分钟，调用了多少脚本和转写，生成多少候选图、多少成功镜头，计费秒数或token是多少。最后用了多少镜头时长，人工筛选、返工花多久，总交付又花多久，也记下来。

**没剪进成片的成功候选，费用也不能删。**这里引用的视频规则按成功生成计费，"业务没采用"和"平台调用失败"是两回事。接口失败、审核失败收不收费，还要查对应服务规则。 $98$ $99$

我建议再看两个数。相关全部支出÷最终合格镜头数，叫"单位合格镜头成本"；相关全部支出÷成片实际采用秒数，叫"单位采用秒成本"。

这两个是本文采用的核算指标，比较时要固定镜头质量和交付规格。它们不是API每生成秒报价。最后只用了十秒，不代表之前没用上的镜头没有生成、筛选成本。

长期比较，可以把两边的累计账列出来：本地是初始净投入，加上每月运行、维护和人工；云端是每月实际调用或租赁，再加存储传输、授权和人工。交付数量、质量、时限对得上，才比大小。

看完整持有成本，就做合理分摊。算现金回收，则从初始投入出发。同一台机器，全额购机款和折旧别重复算。

举个纯假设的例子。初始净投入12000元，相同月度交付下，云方案每月有6000元现金支出可以避免，本地每月新增现金运行支出3000元。简单现金回收期就是12000÷(6000−3000)=4个月。

python 复制代码

12000 / (6000 - 3000)  # 4 个月

这里算的都是真能少付或多付的现金。不含折旧，也不含那些并不会减少支付的固定工资。节省人工时间值多少钱，要另算。

数字只是为了讲公式，不是设备报价、模型价格或创作者调研，更没证明某台机器一个月能干完这些活。若每月只省1000元，其他条件不变，就是12个月。差额不为正，就没有这个模型下的正向回收期。资金时间价值和价格变化也没计入，别把它当采购保证。

python 复制代码

12000 / 1000  # 12 个月

账算得过来，还要看机器干不干得完。拿实测的平均候选生成时间、可用运行小时和停机情况，检查月度处理能力能否覆盖交付量。不能默认每天24小时满载，候选就一定都能产出。

多人共用剪辑机，模型加载和切换，素材处理、返工，都要留记录。便宜但赶不上交付，不能当成同等服务能力的替代。

工作条件	值得比较的部署组合	需要看到的证据
长期稳定生产、重复试稿多	本地常用模型与批处理，对比优化后的云端账单	同质量采用率、实际月处理能力、完整成本和维护工时
vlog以实拍为主、生视频用量少	本地转写／检索／字幕与按量生成混用	哪些环节确有足够用量，不按整片长度推算生视频费用
短剧多镜头迭代、部分镜头要求高	本地分镜与合格草稿，关键镜头保留云端候选	跨镜头一致性、重试后成本、可剪辑秒数与截稿时间
项目间歇或交付峰值明显	现有设备＋按量API或临时算力	闲置期持有成本、峰值排队、临时环境与数据传输时间
多人协作且设备长期占满	本地独立资源、租用算力与混合方案同台比较	并发、剪辑资源争用、排队和稳定交付能力

云端那边也别故意算贵。你实际能拿到的资源包、批量价格、缓存能力，以及有效期和限制，都要算进去。别拿最高在线单价，去对比最乐观的本地满载成本。 $98$ $99$ $101$

本地也一样。质量不够、多筛几轮、要付商业授权，这些都得入账。最后可能是本地便宜，也可能是云端便宜，或者只把部分流程留在本地最合适。先比较，再决定买不买。

第五章：推理框架的差别，在模型适配、编译与硬件委派

选框架，先看它接收什么产物、实际怎么执行。llama.cpp基于ggml，提供C/C推理和多个硬件后端，也支持CPU/GPU++混合执行。MLX-LM则面向Apple silicon，提供语言模型生成、微调和量化能力。 $9$ $10$ 它们都能作为Mac桌面实验路线，但MLX-LM支持语言模型，不等于覆盖所有Apple设备或所有神经引擎。 $9$ $10$

MLC LLM要经过权重转换、量化、模型库编译，可以面向桌面、移动和WebGPU。部署时既要核对模型参数，也要核对目标库，光复制原始权重目录不够。 $11$ $15$

WebLLM是浏览器方向，能用worker把重计算和界面分开。但"浏览器本地推理"只说明计算位置，宿主网页有没有发外部请求，仍要查。 $11$ $15$

ExecuTorch在导出和lowering时，把支持的子图交给后端，并把委派信息放进部署产物。不受delegate支持的算子，可以走可移植CPU路径。 $12$ 所以你要验证的是指定模型、导出配置和后端这一组，而不是框架名字。 $12$ 文档里有些平台路线还标着experimental，不能当成全部同样成熟。 $12$

ONNX Runtime会查询Execution Provider的能力，再把节点或子图交给对应实现；provider顺序也影响选择。 $13$ $14$ 配置了GPU或NPU provider，不等于全图都在那里跑。 $13$ $14$

QNN有session.disable_cpu_ep_fallback配置，可以让无法完全交给目标后端的模型报错。它适合用来查执行覆盖率，不代表关掉回退后，任何模型都应该成功。 $13$ $14$

QNN文档还有一处冲突。配置表写着enable_htp_fp16_precision，后面的入门段落却仍说HTP只支持量化模型。 $14$ 遇到这种情况，别挑一句就下结论"NPU只能算整数"。要结合ONNX Runtime、QNN SDK、芯片和模型版本，核对可用精度。 $14$

路线	主要工程入口	需要核对的执行机制	不能据此承诺的事项
llama.cpp	GGUF 与原生推理引擎 $9$ $16$	张量类型、后端、GPU 层卸载	任意模型在任意后端都可用
MLX-LM	Apple silicon 的模型执行 $10$	量化、缓存、prefill 分块	自动使用 ANE 或覆盖所有苹果设备
MLC LLM	转换与模型库编译 $11$	目标平台、量化与编译约束	原始权重无需适配即可部署
ExecuTorch	导出、lowering、后端委派 $12$	子图覆盖、CPU 回退、部署产物	所有后端具有相同成熟度
ONNX Runtime	ONNX 图与 EP $13$ $14$	节点分配、SDK 和 shape 限制	有 EP 名称即全图加速
WebLLM	浏览器端运行与 worker $15$	WebGPU 能力、资源加载与 UI 隔离	宿主网站绝无外部通信

Ollama、LM Studio可以负责交互、模型管理和服务入口，但做评测还得继续查实际模型、运行时和配置。Ollama FAQ能帮助检查GPU驻留、上下文，LM Studio说明了离线范围。 $26$ $25$ 界面用着顺不顺，和底层引擎跑得快不快，分开记。 $26$ $25$

第一轮验证，选一条桌面路线就够了。Apple silicon上，如果模型都有适配，可以比较llama.cpp和MLX-LM；其他桌面设备先验证可用的llama.cpp后端。需要移动端、浏览器或嵌入式，再按原生集成和编译限制扩展。 $9$ $10$ $11$ $12$ $13$ 这不是速度排名，也不用一次装全所有框架。 $9$ $10$ $11$ $12$ $13$

手机、生成工作流与专用边缘平台的现行路线

这些还不是全部现行路线。手机、图像视频生成、专用边缘平台，还有下面这些选择。先分清运行时、编排、管线和工作流各自做什么。 $49$ $50$ $52$ $54$ $55$ $56$ $57$

旧入口还在，不代表新项目应该继续选它。Google把MediaPipe LLM Inference API标为maintenance-only，推荐LiteRT-LM。这次读取的新项目README标记v0.18.0，但Swift、Web API仍是Early Preview。 $51$ $50$ 迁移方向要看，成熟度也别抹平。比起继续罗列旧名字，这类变化更值得更新。

MNN的LLM和Diffusion路线基于同一端侧计算引擎，覆盖手机、PC、IoT的工程选择。README记录了2026-07-22的3.6.1和Hexagon DSP事件，但后端表对QNN FP16成熟度仍有限制。不能概括成手机NPU已经成熟支持任意LLM。 $49$

OpenVINO GenAI在Runtime上提供多类生成式管线，底层列了CPU、GPU、NPU。接下来仍要查支持模型、导出方式和设备矩阵，不能理解成每种图像、视频、语音管线都能在每种设备上用。 $52$ $53$

TensorRT Edge-LLM面向NVIDIA Jetson、DRIVE和DGX Spark。README这次列有0.11.0事件，以及实验性的直接引擎构建路径。它不是普通Android手机NPU的通用运行时。 $54$

图像和视频这边也别只看名字。Diffusers提供模型管线和可组合组件。ComfyUI除了节点工作流，还有API、执行和资源管理，不能只叫界面。stable-diffusion.cpp则是ggml系的C/C++推理实现。 $55$ $56$ $57$ 它有多个模型和后端路径，但支持列表不能任意交叉配对，仍得查具体组合。 $55$ $56$ $57$

Apple图像生态也要和MLX-LM分开。ml-explore有Stable Diffusion示例；MFLUX是独立社区维护的MLX生成实现，不是Apple官方库。用了MLX，也不能直接推断一定走ANE。 $59$ $58$

扩展路线	层级与主要关注对象	必须另查的条件
LiteRT-LM	LiteRT之上的LLM编排层 $50$	API成熟度、模型和设备后端
MNN／MNN-LLM／MNN-Diffusion	引擎及其任务运行方案 $49$	后端与精度的成熟度矩阵
OpenVINO GenAI	生成式管线与优化库 $52$	模型、导出与CPU/GPU/NPU组合 $53$
TensorRT Edge-LLM	NVIDIA边缘C++运行时 $54$	JetPack、DriveOS、CUDA、TensorRT矩阵
Diffusers	生成模型管线与组件 $55$	PyTorch/硬件、算子、精度及管线版本
ComfyUI	节点工作流、执行及资源管理 $56$	具体节点、模型、后端与外部API
stable-diffusion.cpp	C/C++生成推理引擎 $57$	模型格式与后端是否真实适配
MLX图像示例／MFLUX	官方示例与独立社区实现 $59$ $58$	模型支持和实际执行设备，不能混同MLX-LM

第六章：近期端侧进展案例，要拆出每一项优化的贡献

近期案例可以看MiniCPM-V 4.7。OpenBMB官方README记录它在2026-10-12发布，有35B-A3B和1B两种规格。 $7$ 不过，"首个""无损"这些评价属于项目方，本文没有独立复测它的领先性。 $7$

LES做的是跨层预测专家路由，提前预取权重，争取让加载和计算重叠。 $8$ 预测用来调度，真正计算还是按模型原来的token级路由走。必要专家就算没预测中，也得加载、计算。 $8$ 所以它是在减少等待，不能说成跳过本来需要的专家。 $8$

官方消融用的是iPad Pro 11英寸M4、16 GB。任务包括公开多模态、代码、数学数据，以及内部文本对话评测。 $8$

SSD专家加载基线是2.97 token/s。加调度和加载优化后到9.81，再加逐层混合精度量化到14.92，最后加DSpark投机采样到17.39。 $8$ 这些都是官方这组条件下的解码数据，不是我测的。 $8$

这组数据能说明，权重布局、加载调度、数值表示和解码策略可以一起改变端侧体验。但17.39这个最终结果，不能全算在LES预取一项上，也不能和另一台iPhone的内存、速度拼成一组成绩。 $8$ 表里没有给足完整存储、能耗和长期热状态数据，这些就先留着，不猜。 $8$

再看Gemma的有效参数优化和Apple的端侧训练压缩，至少能确认：缩小参数量之外，还有别的优化办法。 $4$ $8$ $27$ 但几个项目没用同一数据、同一设备直接比较，排不出哪条路线最强。 $4$ $8$ $27$

看到新进展，可以顺着数据流问：权重怎么存，专家怎么预取，计算和缓存怎么做，最后怎么解码？具体改了哪一段，拿什么作基线，还有哪些优化同时开着？消融条件交代清楚，才知道单项贡献有多少。

这些进展怎样改变选型，而不是替我们完成选型

Gemma调整有效负载，MiniCPM优化专家调度，MobileMoE则专门设计移动MoE。这些是不同机制的例子。 $4$ $8$ $86$ 端侧优化还可以发生在模型设计、数值表示、专家加载、编译内核和解码策略等环节，不能用一张跨设备速度表就分高下。 $4$ $8$ $86$

新发布对你有没有用，还是看现有硬件上的实际任务。如果它让原来干不成的活变得可用，连续运行时等待少了，或者返工少了，就值得继续验证。模型更新、框架更新和业务收益，仍得分别拿证据说话。这里没有拿仓库更新时间当发布日期，也没有从官方演示推算你的收益。

第七章：把功能实测改成可复现的技术实验

llama-bench能测prompt processing、text generation和组合任务，也支持重复测量。但文档写明，不包含分词和采样时间。 $24$ $29$ 所以引擎微基准和完整业务耗时都要留。一个tokens/s数字，算不出每小时能处理多少份报价。 $24$ $29$

MLPerf Mobile把模型质量、受控负载和测量方式放进基准，也讨论了移动设备热降频。 $30$ 这里借用这些原则，把连续运行和冷启动分开记，不代表这套自建实验符合MLPerf，更不能把早期移动任务的阈值直接当生成式模型标准。 $30$

下面这套实验还没执行，样本数和档位都是我的建议，不是文献结果。 $17$ $20$ $22$ $24$

实验A固定模型、引擎、设备、上下文和输出限制，只换两到三种已支持的量化配置，看质量、内存、延迟怎么变。 $17$ $20$ $22$ $24$ 实验B则固定配置，改变真实输入长度和缓存深度，再看prefill、decode和资源峰值。 $17$ $20$ $22$ $24$

实验C换模型方案。比如在同一设备、同一资源上限下，比较常规GQA和混合架构。 $2$ $6$ $12$ 训练、模板和模型能力都可能不同，所以它回答的是哪套方案适合任务，测不出GQA或DeltaNet单独带来了多少因果收益。 $2$ $6$ $12$ 配置先查模型卡，实际兼容性也得在运行前确认。 $2$ $6$ $12$

基础业务可以从报价和手册两组开始，之后再加内容创作。

报价组先人工构造30份资料，提前定好金额、单位、币种、交期和原文位置。测字段准确率，单列关键字段错误，也记人工修改用了多久。手册组用公开或授权资料出20道题，放入直接查找、跨段落、版本冲突和资料里没有答案的情况。

30份、20题都只是起始设计，别拿这点样本就说有行业代表性。

每个条件先预热，再保留至少五次完整运行记录；冷启动单独记。llama-bench有重复测试设置，可以参考。 $24$ 这里五次只做初筛，不用来估计稳定的p95。要研究尾延迟，就另设更大的请求集，公开全部样本。这是本文的方法选择，不是文献验证过的统计阈值。

跨模型还要记真实输入token数。同一段文字，换个分词器，长度未必一样。tokenizer、聊天模板也要核对，模板错配或重复特殊token会影响质量。 $28$

为了让别人复现，配置别只写"某模型＋某显卡"。模型仓库和修订、权重哈希、tokenizer、聊天模板、量化与KV类型，都要留。上下文、输出限制、采样参数也一样。引擎提交、编译开关、后端、设备、线程、GPU卸载和热状态，则说明了它到底在哪儿、怎么跑。 $28$ $24$ $9$ $12$ $13$ 这份清单来自模板、基准和后端文档，不是说每个工具都提供一模一样的接口。 $28$ $24$ $9$ $12$ $13$

结果分开看会清楚些：一张配置表，一张引擎性能表，再放业务质量和复核记录。本文还没有执行这些实验，所以本机结果里不填厂商数字，也不提前写赢家。等真实数据和证据齐了，才有自己的实测结论。

图像与视频实验，增加完整管线与结果验收

文字推理要多记思考模式、推理token、工具调用，还有完成整个任务的时间。图像实验先固定画幅、分辨率、采样计划、文本编码器、编辑参考和seed；到了视频，再把帧数、时长、帧率、VAE路径、音频、上采样选项固定下来。 $33$ $42$ $44$ $45$ $48$ 这是按模型卡控制项设计的测试办法，目前还没有测量结果。

验收也得跟着任务走。文字先看是否正确、能否核查。图片看提示有没有做到、文字对不对、主体有没有变。视频还要看帧间一致性、运动和音画关系。

别拿语言模型的tokens/s给图片、视频方案排名，也别只挑一张最好看的图，代替多样本合格率。这些是本文的测试建议，不是行业统一标准。

把架构比较、硬件比较与业务方案比较拆开

架构、硬件、业务方案，最好分开比较。比Dense和MoE时，除了质量，还要写总参数、激活参数、权重与缓存、峰值内存和执行路径。激活量相同，不代表其他条件都相同。 $61$ $64$ $68$

比硬件则尽量固定适配的模型、数值配置和输入，看驻留、传输、首字、解码。换了后端，内核和数值路径哪里不同，也要交代。 $63$ $66$ $67$

业务方案用固定样本和质量门槛验收。先测单人短交互，再覆盖长输入、目标并发、连续运行和失败重试。图像、视频的分辨率、帧数、采样、编码器、VAE等，按前面的协议记录。这仍是待执行的方案，没有现成成绩。

每次都留下原始输入输出。模型和引擎修订、量化与稀疏机制、真正执行的设备，之后都可能用来查差异。主存、显存、缓存、线程、并发、温度、功耗测量边界和环境，也要随运行记录保存。 $87$ $23$

能效看的是完成合格任务花了多少时间、多少能量。只报峰值TOPS/W，或者只量闲置电流，都回答不了这个问题。 $87$ $23$

拿到数据后，再看质量、延迟、能耗、购置和维护。若一套方案在这些方面都被另一套已测方案压过，就可以先排除；剩下的按你的优先级选。这是本文用的多目标决策办法。没有同条件测量和实际报价，就先不排Dense/MoE、GPU或统一内存设备的绝对性价比榜。

增加vlog、短视频与短剧的同任务对照

创作组也还没执行。素材先用公开或已经授权的，固定交付规格和人工验收标准，同时留云端账单、本地日志。结果和报价、手册组分开，不凑一种跨行业准确率。

实验组	固定输入与交付	本地／云端共同记录	通过条件示例
口播／vlog素材整理	同一段录音或实拍，输出转写、片段候选、字幕草稿	字词和人名错误、时间轴误差、采用率、人工修正时间	没有虚构地点或事件，字幕与实际内容一致
访谈／课程切片	同一长素材，按预设主题产出片段与标题	上下文完整、误引、片段采用率和整理工时	片段未改变原意，能回到源时间点核对
带货／封面编辑	同一商品参考、文案、画幅与版本数量	商品保持、文字、合格图比例、生成与筛选成本	产品关键属性和已确认卖点保持正确
短剧／漫剧镜头	同一角色设定、分镜与镜头规格，逐镜头验收	角色服饰、背景连续、动作、采用秒数与返工	预设连续性和交付标准达标，而非只选最漂亮一帧
连续生产成本	固定一组上述任务及实际交付周期	成功但未采用的候选、计费单位、全部人工与总历时	相同质量和时限下，合格产出完整成本可比

可以同时比三组：本地全流程候选、获准使用的云方案，以及本地出草稿、云端处理关键环节。模型不支持的活，别硬塞给它。

中文配音、字幕对齐、口型或视频修复，如果组件还没验证，就写明尚未覆盖。英文音频模型和普通ASR，不能代替这些能力。 $36$ $38$

记录时，把技术失败、内容不合格和编辑主动弃用分开。平台按成功生成收费，那么内容不合格但响应成功的候选，也在项目账单里。错误请求、审核失败，另按服务规则记。 $98$ $99$

把质量、采用率、单位合格产出成本、维护和复核工时、交付时间放在一起，才知道本地化值不值。

第八章：避坑应围绕可定位的失败机制，而不是虚构经历

先留意名字里的"精度"和"规模"。Q4_K_M会混用张量类型，MoE要分总量和激活量，Gemma还有有效参数口径。它们都得看实际实现，不能把文件大小当运行显存。 $21$ $3$ $4$ $22$ 检查时保存权重文件、运行峰值和缓存设置，别只抄一个模型名。 $21$ $3$ $4$ $22$

再查模型到底跑在哪儿。ONNX Runtime的EP、ExecuTorch的delegate都允许子图分配到不同路径，QNN也有关闭CPU fallback的验证配置。 $13$ $12$ $14$ 看委派和profiling信息，再比较回退前后的表现。任务完成了，不等于NPU全程加速了。 $13$ $12$ $14$

回答变差，也别马上怪模型小。Hugging Face文档明确提醒，特殊token用错或重复，会损害表现。 $28$ 先检查tokenizer、chat template、提示序列，再讨论量化和参数规模。否则跨工具的质量对比，起点都没对齐。 $28$

有些内存问题，要到加载以后才出现。常规KV缓存如果保留完整历史，输入越长，占用就越大；固定大小或滚动缓存，则另看窗口限制和质量取舍。 $22$ $10$

Ollama并发会放大上下文相关内存，MLX-LM的prefill分块大小，也是在峰值内存和输入处理速度之间取舍。 $26$ $10$ 所以实际输入、缓存、并发和预处理峰值都要记，空载截图证明不了任务能跑稳。 $22$ $26$ $10$

跑一轮快，也不等于一直快。移动设备的温度、运行条件会影响测量，微基准又不包含完整工作流。 $30$ $24$ 排查时把冷加载、输入处理、解码、文档处理和人工验收分开，再留连续运行曲线。这里没有证据给出所有设备通用的固定降频幅度。 $30$ $24$

本地执行的范围也得重新查。LM Studio的离线说明、Ollama的云开关，各自有适用范围。再接网页、插件、OCR或外部检索服务，数据流就要重新核对。 $25$ $26$ $15$ 可以做断网流程测试，检查连接目的地，但不能因为模型在本地，就说整个系统已经通过安全审计。 $25$ $26$ $15$

这些都是文档和执行机制指向的检查项。要写成自己遇到的故障，还需要输入输出、日志和复测记录。资料里有某种风险，不代表就能补出使用时长、客户投诉或省钱经历。

再检查三种跨任务误读

生图、生视频的完整组件和卸载条件，别在转述时省掉。Wan2.2的24GB示例启用了卸载和CPU文本编码器，HunyuanVideo的14GB也带model offloading前提。LTX下载文件的磁盘体积，更不是显存数字。 $44$ $46$ $45$ 少了这些条件，别人就没法按你写的门槛复现。

能下载，也要查具体许可证。Qwen-Image-2.1-Turbo用Qwen Research License，不能改写成Apache授权。MLX的社区图像实现，也不能称作Apple官方软件。 $42$ $58$ $59$ 谁维护、按什么授权，分别核对。

硬件还有时间和地区。核验当天，512GB Mac Studio的预计供货时间还没到，RTX PRO5500也仍标着初步规格。 $89$ $76$ 采购时重新确认配置和供货。国际RTX5090是32GB，中国RTX5090D v2是24GB，显存数字别串了。 $74$ $88$

真出问题，可以先看输入和模板。它们没问题，再看数值配置、算子委派。接着查权重驻留、缓存和传输，最后看连续运行、业务验收。

有了这些记录，才好判断要换模型、换框架、改流程，还是加硬件。这是排查建议，不是每个故障都得照走的固定步骤。

别把"无限生成"当成零成本，也别只统计成片

本地不按每次API收费，运行、维护、授权和人工筛选也不会因此消失。云端则别混淆调用失败和成功但没采用。这里引用的视频服务按成功生成计费，没采用的候选仍要算账。 $98$ $99$

买不买设备，看第四章的完整成本。实验则看第七章的采用率和交付时间。一次生成成功，说明不了整套创作流程是否划算。

结尾：让一项业务先变得可用

不妨先挑一个能核对答案、能认出失败的活儿。报价、手册、产品素材都可以。把数据边界、输出标准、能等多久和现有设备写清楚，再找一组确实适配的模型与框架。旧流程先留着，拿来作比较。

能在同一业务门槛下稳定干活、方便维护、少些人工返工，再继续投入。内存紧，先试紧凑模型；能力不够，再比较更强的Dense和MoE。等确认驻留、带宽或持续性能真的卡住了，再考虑升级硬件。这只是验证顺序，谁更合适，还得由任务数据和整机测量决定。

模型可以下载、检查、适配，只是开始。真正用起来，还得把模型适配、数值配置和执行验证做完，最后拿业务验收。

值不值得用，记下完成了多少合格任务、总共付出了多少成本。这比看参数、峰值算力，或者一次漂亮的演示，更能帮助你作决定。

出处与研究边界

资料来自2026年10月15日保存的论文、官方模型卡、仓库、技术文档和规格页。清单只列代表性候选，没有穷举全部最新产品。厂商性能仍归厂商，不是我复现的；最低内存带卸载等条件，会一起写出来。上市公告、一般交付和当地现货，也分开处理。

功能实测还在方案阶段。文中的业务样例、样本数、成本定义和选型顺序，是本文提出的方法，不是客户访谈、行业统计或实际使用收益。采购前再核对目标地区、配置、价格和交付。

引用编号已经统一。随稿保留证据登记、原始快照路径和章节整合映射，想核对某个说法，可以顺着出处往回查。

Bibliography｜参考文献

以下来源统一访问于2026-10-15。n.d.表示本次没有从页面核定发表年份；具体发布时间仅在正文和原始材料可以确认时陈述。编号与整合证据登记一致。

$1$ arxiv.org (n.d.). "GQA: Training Generalized Multi-Query Transformer Models from Multi-Head Checkpoints". Primary source. arxiv.org/abs/2305.13... (Retrieved: 2026-10-15).

$2$ huggingface.co (n.d.). "Qwen3-4B model card". Primary source. huggingface.co/Qwen/Qwen3-... (Retrieved: 2026-10-15).

$3$ huggingface.co (n.d.). "Qwen3-30B-A3B model card". Primary source. huggingface.co/Qwen/Qwen3-... (Retrieved: 2026-10-15).

$4$ ai.google.dev (n.d.). "Gemma 3n model overview". Primary source. ai.google.dev/gemma/docs/... (Retrieved: 2026-10-15).

$5$ huggingface.co (n.d.). "Qwen3.5-0.8B model card". Primary source. huggingface.co/Qwen/Qwen3.... (Retrieved: 2026-10-15).

$6$ huggingface.co (n.d.). "Qwen3.5-4B model card". Primary source. huggingface.co/Qwen/Qwen3.... (Retrieved: 2026-10-15).

$7$ github.com (n.d.). "OpenBMB MiniCPM-V Chinese README". Primary source. github.com/OpenBMB/Min... (Retrieved: 2026-10-15).

$8$ github.com (n.d.). "LES: 前瞻专家调度". Primary source. github.com/OpenBMB/lla... (Retrieved: 2026-10-15).

$9$ github.com (n.d.). "llama.cpp README". Primary source. github.com/ggml-org/ll... (Retrieved: 2026-10-15).

$10$ github.com (n.d.). "MLX LM README". Primary source. github.com/ml-explore/... (Retrieved: 2026-10-15).

$11$ llm.mlc.ai (n.d.). "Introduction to MLC LLM". Primary source. llm.mlc.ai/docs/get_st... (Retrieved: 2026-10-15).

$12$ docs.pytorch.org (n.d.). "ExecuTorch Backends". Primary source. docs.pytorch.org/executorch/... (Retrieved: 2026-10-15).

$13$ onnxruntime.ai (n.d.). "ONNX Runtime Execution Providers". Primary source. onnxruntime.ai/docs/execut... (Retrieved: 2026-10-15).

$14$ onnxruntime.ai (n.d.). "ONNX Runtime QNN Execution Provider". Primary source. onnxruntime.ai/docs/execut... (Retrieved: 2026-10-15).

$15$ webllm.mlc.ai (n.d.). "Welcome to WebLLM". Primary source. webllm.mlc.ai/docs/ (Retrieved: 2026-10-15).

$16$ github.com (n.d.). "GGUF specification". Primary source. github.com/ggml-org/gg... (Retrieved: 2026-10-15).

$17$ arxiv.org (n.d.). "AWQ: Activation-aware Weight Quantization for LLM Compression and Acceleration". Primary source. arxiv.org/html/2306.0... (Retrieved: 2026-10-15).

$18$ arxiv.org (n.d.). "GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers". Primary source. arxiv.org/html/2210.1... (Retrieved: 2026-10-15).

$19$ arxiv.org (n.d.). "SmoothQuant: Accurate and Efficient Post-Training Quantization for Large Language Models". Primary source. arxiv.org/abs/2211.10... (Retrieved: 2026-10-15).

$20$ raw.githubusercontent.com (n.d.). "llama.cpp ggml-common.h quantization block definitions". Primary source. raw.githubusercontent.com/ggml-org/ll... (Retrieved: 2026-10-15).

$21$ raw.githubusercontent.com (n.d.). "llama.cpp llama-quant.cpp tensor type selection". Primary source. raw.githubusercontent.com/ggml-org/ll... (Retrieved: 2026-10-15).

$22$ huggingface.co (n.d.). "Unlocking Longer Generation with Key-Value Cache Quantization". Primary source. huggingface.co/blog/kv-cac... (Retrieved: 2026-10-15).

$23$ arxiv.org (n.d.). "LLM Inference Unveiled: Survey and Roofline Model Insights". Primary source. arxiv.org/html/2402.1... (Retrieved: 2026-10-15).

$24$ raw.githubusercontent.com (n.d.). "llama-bench official README". Primary source. raw.githubusercontent.com/ggml-org/ll... (Retrieved: 2026-10-15).

$25$ lmstudio.ai (n.d.). "LM Studio Offline Operation". Primary source. lmstudio.ai/docs/app/of... (Retrieved: 2026-10-15).

$26$ docs.ollama.com (n.d.). "Ollama FAQ". Primary source. docs.ollama.com/faq (Retrieved: 2026-10-15).

$27$ arxiv.org (n.d.). "Apple Intelligence Foundation Language Models: Tech Report 2025". Primary source. arxiv.org/abs/2507.13... (Retrieved: 2026-10-15).

$28$ huggingface.co (n.d.). "Templates for Chat Models". Primary source. huggingface.co/docs/transf... (Retrieved: 2026-10-15).

$29$ github.com (n.d.). "llama-bench README". Primary source. github.com/ggml-org/ll... (Retrieved: 2026-10-15).

$30$ arxiv.org (n.d.). "MLPerf Mobile Inference Benchmark". Primary source. arxiv.org/abs/2012.02... (Retrieved: 2026-10-15).

$31$ huggingface.co (n.d.). "Gemma4 E2B official model card". Primary source. huggingface.co/google/gemm... (Retrieved: 2026-10-15).

$32$ github.com (n.d.). "Qwen3.8 official repository README". Primary source. github.com/QwenLM/Qwen... (Retrieved: 2026-10-15).

$33$ huggingface.co (n.d.). "Phi-4-mini-flash-reasoning official model card". Primary source. huggingface.co/microsoft/P... (Retrieved: 2026-10-15).

$34$ huggingface.co (n.d.). "LFM2.5-2.6B official model card". Primary source. huggingface.co/LiquidAI/LF... (Retrieved: 2026-10-15).

$35$ huggingface.co (n.d.). "SmolLM3-3B official model card". Primary source. huggingface.co/HuggingFace... (Retrieved: 2026-10-15).

$36$ huggingface.co (n.d.). "LFM2.5-Audio-1.5B official model card". Primary source. huggingface.co/LiquidAI/LF... (Retrieved: 2026-10-15).

$37$ huggingface.co (n.d.). "LFM2.5-Embedding-350M official model card". Primary source. huggingface.co/LiquidAI/LF... (Retrieved: 2026-10-15).

$38$ huggingface.co (n.d.). "Qwen3-ASR-0.6B official model card". Primary source. huggingface.co/Qwen/Qwen3-... (Retrieved: 2026-10-15).

$39$ huggingface.co (n.d.). "LFM2.5-24B-A2B official model card raw". Primary source. huggingface.co/LiquidAI/LF... (Retrieved: 2026-10-15).

$40$ huggingface.co (n.d.). "EmbeddingGemma2 official model card". Primary source. huggingface.co/google/embe... (Retrieved: 2026-10-15).

$41$ huggingface.co (n.d.). "FLUX.2-klein-4B official model card". Primary source. huggingface.co/black-fores... (Retrieved: 2026-10-15).

$42$ huggingface.co (n.d.). "Qwen-Image-2.1-Turbo official model card". Primary source. huggingface.co/Qwen/Qwen-I... (Retrieved: 2026-10-15).

$43$ github.com (n.d.). "Z-Image official repository". Primary source. github.com/Tongyi-MAI/... (Retrieved: 2026-10-15).

$44$ github.com (n.d.). "Wan2.2 official repository". Primary source. github.com/Wan-Video/W... (Retrieved: 2026-10-15).

$45$ github.com (n.d.). "LTX-2 official repository: LTX-2.5". Primary source. github.com/Lightricks/... (Retrieved: 2026-10-15).

$46$ github.com (n.d.). "HunyuanVideo-1.5 official repository". Primary source. github.com/Tencent-Hun... (Retrieved: 2026-10-15).

$47$ bfl.ai (n.d.). "FLUX.2 klein official product specification table". Primary source. bfl.ai/models/flux... (Retrieved: 2026-10-15).

$48$ huggingface.co (n.d.). "Diffusers official documentation: Reduce memory usage". Primary source. huggingface.co/docs/diffus... (Retrieved: 2026-10-15).

$49$ github.com (n.d.). "MNN README". Primary source. github.com/alibaba/MNN (Retrieved: 2026-10-15).

$50$ github.com (n.d.). "LiteRT-LM README". Primary source. github.com/google-ai-e... (Retrieved: 2026-10-15).

$51$ developers.google.com (n.d.). "MediaPipe LLM Inference guide". Primary source. developers.google.com/edge/mediap... (Retrieved: 2026-10-15).

$52$ github.com (n.d.). "OpenVINO GenAI README". Primary source. github.com/openvinotoo... (Retrieved: 2026-10-15).

$53$ openvinotoolkit.github.io (n.d.). "OpenVINO GenAI Supported Models". Primary source. openvinotoolkit.github.io/openvino.ge... (Retrieved: 2026-10-15).

$54$ github.com (n.d.). "TensorRT Edge-LLM README". Primary source. github.com/NVIDIA/Tens... (Retrieved: 2026-10-15).

$55$ huggingface.co (n.d.). "Hugging Face Diffusers documentation". Primary source. huggingface.co/docs/diffus... (Retrieved: 2026-10-15).

$56$ github.com (n.d.). "ComfyUI README". Primary source. github.com/Comfy-Org/C... (Retrieved: 2026-10-15).

$57$ github.com (n.d.). "stable-diffusion.cpp README". Primary source. github.com/leejet/stab... (Retrieved: 2026-10-15).

$58$ github.com (n.d.). "MFLUX README". Primary source. github.com/mflux-commu... (Retrieved: 2026-10-15).

$59$ github.com (n.d.). "MLX Examples Stable Diffusion". Primary source. github.com/ml-explore/... (Retrieved: 2026-10-15).

$60$ huggingface.co (n.d.). "Diffusers Caching". Primary source. huggingface.co/docs/diffus... (Retrieved: 2026-10-15).

$61$ arxiv.org (n.d.). "Mixtral of Experts". Primary source. arxiv.org/abs/2401.04... (Retrieved: 2026-10-15).

$62$ docs.pytorch.org (n.d.). "PyTorch: Accelerating BERT with semi-structured (2:4) sparsity". Primary source. docs.pytorch.org/tutorials/a... (Retrieved: 2026-10-15).

$63$ docs.nvidia.com (n.d.). "NVIDIA TensorRT: Data Formats and Tensors --- Sparsity". Primary source. docs.nvidia.com/deeplearnin... (Retrieved: 2026-10-15).

$64$ huggingface.co (n.d.). "Hugging Face: Mixture of Experts (MoEs) in Transformers". Primary source. huggingface.co/blog/moe-tr... (Retrieved: 2026-10-15).

$65$ arxiv.org (n.d.). "ExFold: Unified Expert Folding for Training-Free MoE Prefill-Decode Acceleration". Primary source. arxiv.org/abs/2608.24... (Retrieved: 2026-10-15).

$66$ arxiv.org (n.d.). "MoE-SpeQ: Speculative Quantized Decoding with Proactive Expert Prefetching and Offloading for Mixture-of-Experts". Primary source. arxiv.org/abs/2511.14... (Retrieved: 2026-10-15).

$67$ github.com (n.d.). "llama.cpp server official README". Primary source. github.com/ggml-org/ll... (Retrieved: 2026-10-15).

$68$ arxiv.org (n.d.). "DeepSpeed-MoE: Advancing Mixture-of-Experts Inference and Training to Power Next-Generation AI Scale". Primary source. arxiv.org/abs/2201.05... (Retrieved: 2026-10-15).

$69$ support.apple.com (n.d.). "Mac Studio (M5 Max or M5 Ultra) technical specifications". Primary source. support.apple.com/en-gb/12810... (Retrieved: 2026-10-15).

$70$ www.apple.com (n.d.). "Apple introduces Mac mini with M6 and M5 Pro". Primary source. www.apple.com/newsroom/20... (Retrieved: 2026-10-15).

$71$ developer.amd.com (n.d.). "AMD Ryzen AI Halo User Guide". Primary source. developer.amd.com/playbooks/u... (Retrieved: 2026-10-15).

$72$ www.amd.com (n.d.). "AMD Radeon AI PRO R9700 official specification". Primary source. www.amd.com/en/products... (Retrieved: 2026-10-15).

$73$ investor.nvidia.com (n.d.). "NVIDIA Blackwell GeForce RTX arrives for every gamer". Primary source. investor.nvidia.com/news/press-... (Retrieved: 2026-10-15).

$74$ www.nvidia.com (n.d.). "NVIDIA GeForce RTX5090 official specification". Primary source. www.nvidia.com/en-us/gefor... (Retrieved: 2026-10-15).

$75$ www.nvidia.com (n.d.). "NVIDIA RTX PRO5000 Blackwell specification". Primary source. www.nvidia.com/en-us/produ... (Retrieved: 2026-10-15).

$76$ www.nvidia.com (n.d.). "NVIDIA RTX PRO5500 Blackwell Workstation GPU". Primary source. www.nvidia.com/en-us/produ... (Retrieved: 2026-10-15).

$77$ www.nvidia.com (n.d.). "NVIDIA DGX Spark official product specifications". Primary source. www.nvidia.com/en-us/produ... (Retrieved: 2026-10-15).

$78$ www.qualcomm.com (n.d.). "Snapdragon 8 Elite Gen 5 Product Brief Rev B". Primary source. www.qualcomm.com/content/dam... (Retrieved: 2026-10-15).

$79$ www.qualcomm.com (n.d.). "Snapdragon Leads the Agentic AI Age with Two of the World's Fastest Mobile SoCs". Primary source. www.qualcomm.com/news/releas... (Retrieved: 2026-10-15).

$80$ semiconductor.samsung.com (n.d.). "Samsung LPDDR6: Industry-First Validation on Qualcomm Technologies New Snapdragon Platform". Primary source. semiconductor.samsung.com/news-events... (Retrieved: 2026-10-15).

$81$ www.apple.com (n.d.). "Apple debuts iPhone 18 Pro and iPhone 18 Pro Max". Primary source. www.apple.com/newsroom/20... (Retrieved: 2026-10-15).

$82$ www.intel.com (n.d.). "Intel Core Ultra X9 Processor 388H Specifications". Primary source. www.intel.com/content/www... (Retrieved: 2026-10-15).

$83$ www.amd.com (n.d.). "AMD Ryzen AI 9 HX 470 Specifications". Primary source. www.amd.com/en/products... (Retrieved: 2026-10-15).

$84$ estore.asus.com (n.d.). "ASUS Zenbook A16 UX3607 Official Store Specifications". Primary source. estore.asus.com/nl/90nb17w1... (Retrieved: 2026-10-15).

$85$ www.nvidia.com (n.d.). "NVIDIA Jetson Developer Kit Quick Specifications". Primary source. www.nvidia.com/en-eu/auton... (Retrieved: 2026-10-15).

$86$ arxiv.org (n.d.). "MobileMoE: Scaling On-Device Mixture of Experts". Primary source. arxiv.org/abs/2605.27... (Retrieved: 2026-10-15).

$87$ mlcommons.org (n.d.). "MLPerf Inference Datacenter: power measurements". Primary source. mlcommons.org/benchmarks/... (Retrieved: 2026-10-15).

$88$ www.nvidia.cn (n.d.). "NVIDIA GeForce RTX 5090 D v2 China specifications". Primary source. www.nvidia.cn/geforce/gra... (Retrieved: 2026-10-15).

$89$ www.apple.com.cn (n.d.). "Apple中国：M5 Max和M5 Ultra Mac Studio发布公告". Primary source. www.apple.com.cn/newsroom/20... (Retrieved: 2026-10-15).

$90$ www.nvidia.com (n.d.). "NVIDIA GeForce RTX 5060 family specifications". Primary source. www.nvidia.com/en-us/gefor... (Retrieved: 2026-10-15).

$91$ www.nvidia.com (n.d.). "NVIDIA GeForce RTX 50 series comparison". Primary source. www.nvidia.com/en-us/gefor... (Retrieved: 2026-10-15).

$92$ nvidianews.nvidia.com (n.d.). "NVIDIA Blackwell GeForce RTX 50 series launch announcement". Primary source. nvidianews.nvidia.com/news/nvidia... (Retrieved: 2026-10-15).

$93$ www.nvidia.com (n.d.). "NVIDIA RTX PRO 6000 Blackwell Workstation specifications". Primary source. www.nvidia.com/en-us/produ... (Retrieved: 2026-10-15).

$94$ www.amd.com (n.d.). "AMD Radeon AI PRO R9700S specifications". Primary source. www.amd.com/en/products... (Retrieved: 2026-10-15).

$95$ blogs.nvidia.com (n.d.). "NVIDIA Jetson Orin Nano Super launch". Primary source. blogs.nvidia.com/blog/jetson... (Retrieved: 2026-10-15).

$96$ nvidianews.nvidia.com (n.d.). "NVIDIA Jetson Thor general availability announcement". Primary source. nvidianews.nvidia.com/news/nvidia... (Retrieved: 2026-10-15).

$97$ www.qualcomm.com (n.d.). "Snapdragon Summit 2026: official product announcements". Primary source. www.qualcomm.com/company/eve... (Retrieved: 2026-10-15).

$98$ docs.volcengine.com (n.d.). "火山方舟模型价格：视频token与成功生成计费". Primary source. docs.volcengine.com/docs/ark/mo... (Retrieved: 2026-10-15).

$99$ docs.volcengine.com (n.d.). "即梦AI视频生成计费说明". Primary source. docs.volcengine.com/docs/Jimeng... (Retrieved: 2026-10-15).

$100$ bfl.ai (n.d.). "Black Forest Labs: API pricing and self-hosted licensing". Primary source. bfl.ai/pricing/ (Retrieved: 2026-10-15).

$101$ docs.volcengine.com (n.d.). "火山方舟模型服务计费：输入输出与缓存". Primary source. docs.volcengine.com/docs/82379/... (Retrieved: 2026-10-15).