Qwen3.8-27B 跑进 iPhone 18 神经引擎:15–70 tok/s 的端侧大模型突破

Qwen3.8-27B 以 1.5 bpw 量化跑进 iPhone 18 神经引擎,实测 15–70 tok/s,标志着端侧大模型工程门槛下移。
文章分析了 27B 参数级 Qwen3.8 模型在 iPhone 18 神经引擎上运行、实测 15–70 tok/s 的案例。核心变量是 1.5 bpw 极低比特量化,它把约 54GB 的 FP16 权重压到 5GB 上下,使手机部署成为可能。选择神经引擎而非 GPU 是为换取更优能效比与持续推理时的低发热,代价是算子支持与内存布局需要深度适配,这也是速度区间跨度巨大的原因。作者指出端侧 27B 的价值在于隐私隔离与离线可用,但精度损失、长上下文 KV cache 内存压力和发热降频仍是硬约束,并强调速度数据需结合上下文长度与 prompt 规模才有意义。
Qwen3.8-27B 跑进 iPhone 18 神经引擎:15–70 tok/s 的端侧大模型突破
端侧大模型的边界正在被一次次推高。最近在技术社区引发讨论的一个案例显示,27B 参数级别的 Qwen3.8 模型已经可以在 iPhone 18 的神经网络引擎上运行,实测速度区间为每秒 15 到 70 个 token(tok/s),而模型权重被压缩到了约 1.5 bpw(bits per weight)。这个组合意味着什么,值得拆开来看。
1.5 bpw:端侧大模型的关键变量
27B 模型若以 FP16 存储,权重体积接近 54GB,显然远超手机可用内存。1.5 bpw 的量化把每个权重压缩到约 1.5 比特,理论上权重体积可降到 5GB 上下,这才让「装进手机」从不可能变成需要精细工程调优的挑战。
1.5 bpw 属于极低比特量化区间。相比常见的 4-bit 量化,它对精度更敏感,通常需要配合混合精度策略——把敏感层保留在更高比特,其余层压到低位。讨论中呈现的速度区间 15–70 tok/s 跨度相当大,说明实际表现高度依赖量化配置、上下文长度以及神经引擎的调度方式,而不是一个稳定的单一数字。
bpw(bits per weight) 是衡量量化粒度的常用指标,表示平均每个模型权重占用的比特数。这一指标比“4-bit 量化”这类说法更精确,因为实际量化往往是混合精度的:敏感层(如 embedding、归一化层、输出头)可能保留 4 或 8 比特,而大部分 Transformer 层被压到 2 比特甚至更低,加权平均后得到 1.5 bpw 这样的整体数值。
需要区分的是,bpw 只描述权重的存储与计算格式,不等于压缩率——还需考虑量化元数据(scale、zero-point)、分组粒度(group size)带来的额外开销,因此实际文件体积往往略高于“参数量 × bpw / 8”的理论值。1.5 bpw 已接近信息论意义上的极低区间,通常需要借助 GPTQ、AWQ 或更激进的向量量化等方法,并配合校准数据集来抑制精度崩塌。
为什么是神经引擎而不是 GPU
把推理放在 iPhone 的 Neural Engine 上,而不是 GPU 或 CPU,是这个案例最有信息量的部分。神经引擎的优势在于能效比:在持续推理场景下,它比 GPU 更省电、发热更低,适合长时间对话类应用。代价是编程模型更受限,算子支持和内存布局都需要针对硬件做适配。
这也解释了速度区间的波动。神经引擎对算子融合、权重量化格式、KV cache 管理都有特定要求,任何一环没对齐,吞吐就会明显下滑。15 tok/s 大致是「能用的交互体验」下限,70 tok/s 则接近「接近本地小模型流畅度」的上限,两者之间的差距基本由工程实现决定。
Neural Engine(神经引擎) 是苹果 SoC 中独立于 CPU 和 GPU 的专用推理加速单元,从 A11 起引入,此后逐步扩大算力与可编程性。它的设计目标是高能效的矩阵与卷积运算,架构上偏向定点/低比特计算和片上内存复用,因此在持续负载下的每瓦性能通常优于 GPU。
但它并非通用计算单元:早期只能通过 Core ML 间接调用,可表达的算子集合有限;较新的平台才逐步开放更底层的访问。这意味着要把一个 27B 模型跑上去,需要把注意力、归一化、激活等算子映射到神经引擎支持的指令集,必要时做算子融合或改写内存布局,KV cache 也要放在访问延迟可控的位置。工程适配的深度,直接决定了实际能达到 15 还是 70 tok/s。
端侧 27B 模型的实际意义
27B 级别模型跑到手机上,意义不在于替代云端,而在于提供一条隐私隔离、离线可用的推理路径。对输入敏感数据的场景——个人文档问答、本地知识库检索、离线翻译——端侧推理能避免数据出设备。
但需要冷静看待:1.5 bpw 的精度损失、长上下文下的内存压力、以及持续推理时的发热与降频,都是仍然存在的约束。速度数据本身没有说明上下文长度和 prompt 规模,脱离这些条件谈 tok/s 容易产生误导。
KV cache 是大模型推理中除权重之外最主要的显存/内存消耗来源。自回归生成时,每一层都要缓存历史 token 的 Key 和 Value 向量以避免重复计算,其大小与层数、注意力头维度、序列长度和批大小成正比。对 27B 级模型而言,即使权重被压到 5GB 上下,长上下文下的 KV cache 仍可能占用数 GB,成为手机内存的真正瓶颈。
这也是端侧部署常配套使用 KV cache 量化(如压到 4 或 8 比特)、分组查询注意力(GQA)以及滑动窗口或稀疏注意力等机制的原因。原文提到“长上下文下的内存压力”,其技术根源正在于此:上下文越长,KV cache 增长越快,还可能触发内存换页或直接 OOM,进而影响 tok/s 的稳定性。
端侧推理的工程门槛正在下降
这个案例更值得关注的信号是:低比特量化和硬件专用推理栈的组合,正在把「大模型上手机」从研究演示推向可复现的工程实践。当 27B 模型能以可接受的交互速度跑在消费级手机上,应用层的设计空间会被重新打开——本地优先的 AI 应用不再是噱头,而是具备性能基础的架构选择。
真正的分水岭不在于峰值 tok/s,而在于精度、内存、功耗三者能否同时落在可用区间。1.5 bpw 是这个平衡点上的一次激进尝试,它的实际体验还需要更多长上下文和真实任务的测试来验证。
相关推荐

一句提示词引发的全球PHP安全风暴:AI是救星还是隐患?
一句AI提示词竟引发全球PHP安全危机,维基百科、互联网档案馆受波及。本文梳理事件脉络,解析OpenAI与亚马逊的争议,探讨AI时代漏洞发现门槛降低带来的安全悖论与开发者应对策略。

当AI被拿走:依赖捷径如何削弱你的解题韧性
一项涉及1,222人的研究发现:使用AI答题后,一旦AI被移除,人们放弃解题的比例高于从未使用AI的对照组。文章分析AI依赖对学习韧性和元认知的影响,并探讨AI学习工具的设计启示。

Carta联手NewView:让创业公司员工提前套现股权
Carta 与 NewView Capital 合作推出新计划,简化创业公司 tender offer 流程,帮助员工提前出售股权套现。本文分析该合作的核心机制、员工股权流动性痛点及对创业公司股权激励的影响。