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 是这个平衡点上的一次激进尝试,它的实际体验还需要更多长上下文和真实任务的测试来验证。
相关推荐

OpenAI与Shield合作:Astra智能体如何革新IT故障修复
OpenAI与Shield合作推出Astra智能体,可自动登录电脑和遗留系统,实时修复IT故障,比传统模型快35%到40%,仅在需要人类判断时引入人工。

iPhone Duo续航实测:一天一充跑不掉,大屏是耗电元凶
iPhone Duo续航实测:重度使用一天需至少充电一次,6.5小时亮屏约剩30%电量。大屏展开频率是耗电关键,MagSafe电池背夹可救场,长期衰减同样值得关注。

Kimi K3.1 Pro开源发布:2.8万亿参数逼近Opus
Moonshot发布开源MoE模型Kimi K3.1 Pro,2.8万亿总参数、1040亿激活参数,Terminal Bench 4.0仅落后Opus 5.5不到1分,单任务成本约三分之一,API价格减半,开源权重11月4日开放。