27B 模型塞进手机：1.5 bpw 量化与 ANE 后端实战

这篇能做出什么

读完并照着做，你会得到一条完整的端侧大模型流水线：

1. 一份约 27B 参数的开源权重，从 Hugging Face 格式导出成干净的统一格式；

2. 一次混合位宽量化，把平均每权重比特数压到 1.5 bpw 量级（而不是常见的 4 bit），产出一个能在手机内存里放下的权重包；

3. 一个转换到 Core ML 的 .mlpackage，其中大部分矩阵乘法跑在 Apple Neural Engine（ANE）上，而不是 CPU；

4. 一个能装到真机上跑的 App，以及一套可复现的实测方法：prefill / decode 分开测 tok/s、记录真实内存 footprint、观察发热与降频。

先给一个能立刻建立直觉的数字：27B 参数 × 1.5 bit / 8 = 约 5.1 GB。这就是权重本体的大小，还没算 scale、zero、embedding、KV cache 和运行时开销。手机能不能跑，本质上是"这 5 GB 加加减减之后，还剩不剩得下 KV cache 和系统内存"的算术题，不是玄学。

先说明两件事，避免误解：

• 文中"Qwen3.8-27B""iPhone 18"是选题里的代号。具体某个型号的 SoC 名称、ANE 算力、内存带宽、可用内存上限，以厂商官方公布和官方文档当前版本为准。下文所有方法对一个"约 27B 参数的中等规模模型 + 近两代支持 Apple Intelligence 的 iPhone"同样成立，你换成自己手上的模型和机型即可。
• 文中不写具体版本号、镜像 tag、下载地址。凡是涉及版本的地方，一律按官方文档当前版本取。

---

前置条件清单

工具链大致是这几个（用官方渠道装，版本以官方文档当前版本为准）：

```bash

python -m venv .venv && source .venv/bin/activate

pip install --upgrade pip

pip install torch transformers safetensors numpy

pip install coremltools # 版本以 coremltools 官方文档为准

pip install huggingface_hub

```

核对一件事：coremltools 的版本必须支持你目标 iOS 的 deployment target。装完先跑一句 python -c "import coremltools as ct; print(ct.__version__)"，然后去官方文档的 release notes 对一遍支持的 target 列表。

---

步骤一：先把内存预算算清楚，再动手

这一步很多人跳过，然后在转换阶段被 OOM 卡两天。

权重本体：

```

权重字节数 ≈ 参数量 × bpw / 8

27e9 × 1.5 / 8 ≈ 5.06 GB

```

别忘了量化元数据。 分组量化每组要存一个 scale（有时还有 zero）。以 group size = 64、scale 用 fp16 为例：

```

元数据开销 ≈ 16 bit / 64 权重 = 0.25 bit/权重

实际 bpw = 1.5 + 0.25 = 1.75

27e9 × 1.75 / 8 ≈ 5.9 GB

```

这就是为什么"标称 1.5 bpw"和"进程实际占多少"永远对不上。你在报告结果时必须说清楚：1.5 bpw 指的是权重位宽，还是含元数据的等效位宽。

KV cache：

```

KV 字节数 = 2 × 层数 × KV头数 × head_dim × 序列长度 × 每元素字节

```

举例（数字仅示范算法，按你的模型 config 代入）：层数 48、KV 头数 8、head_dim 128、fp16：

• 每 token：2 × 48 × 8 × 128 × 2 = 196,608 字节 ≈ 0.19 MB
• 4K 上下文：约 780 MB

结论：5.9 GB 权重 + 0.8 GB KV + 几百 MB 运行时 ≈ 7 GB 出头。这就是为什么必须给 App 申请提高内存上限的 entitlement（com.apple.developer.kernel.increased-memory-limit），否则系统会在你还没热身完时就把进程杀掉。

顺带算出速度上限：

```

decode tok/s ≈ 有效内存带宽 / 每 token 需要读取的字节数

```

decode 阶段每生成一个 token 要把（几乎）全部权重读一遍，所以它本质上是内存带宽问题，不是算力问题。把 5.9 GB 代入，你就能估出一个理论上限；实际能到六到八成。把这个估算写进报告时要标注为"估算"，实测值单独列。

---

步骤二：导出并体检权重

```bash

huggingface-cli download <你的模型仓库名> \

--local-dir ./qwen27b-fp16 \

--local-dir-use-symlinks False

```

下完先体检，别急着转：

```python

check_weights.py

import json, glob

from safetensors import safe_open

cfg = json.load(open("./qwen27b-fp16/config.json"))

print("hidden_size :", cfg.get("hidden_size"))

print("num_hidden_layers:", cfg.get("num_hidden_layers"))

print("num_kv_heads :", cfg.get("num_key_value_heads"))

print("vocab_size :", cfg.get("vocab_size"))

total = 0

dtypes = set()

for f in sorted(glob.glob("./qwen27b-fp16/*.safetensors")):

with safe_open(f, framework="pt") as st:

for k in st.keys():

t = st.get_slice(k)

n = 1

for d in t.get_shape():

n *= d

total += n

dtypes.add(str(t.get_dtype()))

print("参数量: %.2f B" % (total / 1e9))

print("dtype :", dtypes)

```

要点：

• 参数量对不上就是下错了仓库（比如下成了 MoE 版或 fp8 版）。
• dtype 出现 F8_E4M3 之类的，先反量化到 fp16 再继续，否则后面量化器不认。
• 记下 num_key_value_heads，如果你的模型是 GQA，KV cache 公式里要用 KV 头数，不是注意力头数。用错会让内存预算差好几倍。

---

步骤三：做 1.5 bpw 混合位宽量化

关键认知：1.5 bpw 不是一个原生数据类型。 没有芯片原生支持 1.5 bit 的乘法。它只能这么实现：

> 大部分层用 2 bit 分组量化，少量敏感层用 4 bit，再用极少量的 fp16 层兜底，加权平均下来落在 1.5 bpw 附近。

所以你要做的是分层的位宽分配策略，不是一个 --bits 1.5 参数。

哪些层敏感？ 经验规律（不是定理，要在你自己的模型上验证）：

用 imatrix 校准（强烈建议）。 分组量化的误差主要来自离群通道，用一小批真实语料统计每个通道的激活幅度，作为权重来挑分组边界，比均匀量化好上一档：

```python

伪代码：用校准语料统计激活幅度

import torch

from transformers import AutoModelForCausalLM, AutoAI 词典：Token">Tokenizer

tok = AutoTokenizer.from_pretrained("./qwen27b-fp16")

model = AutoModelForCausalLM.from_pretrained(

"./qwen27b-fp16", torch_dtype=torch.float16, device_map="cpu"

)

model.eval()

act_scale = {} # layer_name -> [in_features] 的通道幅度统计

def hook(name):

def fn(mod, inp, out):

x = inp[0].detach().abs().mean(dim=(0, 1))

act_scale[name] = x if name not in act_scale else act_scale[name] * 0.9 + x * 0.1

return fn

for name, mod in model.named_modules():

if name.endswith("mlp.down_proj"):

mod.register_forward_hook(hook(name))

calib = ["这是一段用于统计激活分布的中文校准文本。", "The quick brown fox jumps over the lazy dog."]

with torch.no_grad():

for text in calib:

model(tok(text, return_tensors="pt", truncation=True, max_length=512).input_ids)

```

校准语料用 100–500 条、覆盖你要用的领域（中文问答、代码、英文各来一点）。语料跑偏，量化后的模型就会在你实际用的场景里崩。

量化 + 回写：

```python

import torch, json, os

BITS_PLAN = {

"lm_head": 4, "model.embed_tokens": 4,

}

DEFAULT_BITS = 2

GROUP_SIZE = 64

def quantize_group(w, bits, group_size):

"""按通道维做分组，返回 int 码 + fp16 scale（示例实现，生产用成熟库）"""

qmax = (1 << bits) - 1

out_shape = w.shape

w2 = w.reshape(-1, group_size)

mn, mx = w2.min(dim=1, keepdim=True).values, w2.max(dim=1, keepdim=True).values

scale = ((mx - mn) / qmax).clamp_min(1e-8)

q = ((w2 - mn) / scale).round().clamp(0, qmax).to(torch.uint8)

return q.reshape(out_shape), scale.squeeze(1).half(), mn.squeeze(1).half()

```

实际工程里建议直接用成熟的量化库（GPTQ / AWQ 一类的分组量化实现），别手搓——手搓版最大的问题是和推理后端的分组布局对不上，转 Core ML 时会失败。量化器输出的分组布局必须和 Core ML 侧的 palettize 参数一致（同样 group size、同样按输出通道分组）。

写盘时同时输出一份清单，方便复现：

```python

manifest = {

"default_bits": DEFAULT_BITS,

"override": BITS_PLAN,

"group_size": GROUP_SIZE,

"calib_samples": len(calib),

"note": "bpw 为权重位宽，元数据开销另计",

}

json.dump(manifest, open("./quant/manifest.json", "w"), indent=2)

```

---

步骤四：量化后必须验收，别直接进转换

三个检查，缺一不可：

1. 困惑度回归。 拿同一份 held-out 文本，比 fp16 和 1.5 bpw 的困惑度。相对涨幅控制在个位数百分比是健康区间；翻倍就是位宽分配错了，回去把 lm_head、首尾层提到 4 bit。

2. 抽样生成。 至少跑 20 条，覆盖：中文长句、英文、代码补全、数学推理、多轮对话。重点看两个坏味道：

• 重复循环：同一句反复输出 → 通常是 lm_head 或最后几层被压坏了；
• 语言错乱：中文里混英文碎片 → 通常是 embedding 量化太狠。

3. 张量对齐检查。 打印量化前后每个张量的 shape 和 dtype，逐层 diff。分组量化最常见的翻车是 reshape 顺序搞错，shape 对了但数值全乱，这种错误在困惑度上会直接体现为天文数字。

```bash

建议把验收脚本做成一条命令，改一次量化参数就跑一次

python verify.py --ref ./qwen27b-fp16 --quant ./quant --ppl-samples 200 --gen-samples 20

```

---

步骤五：转 Core ML，指明要用 ANE

```python

import numpy as np, torch, coremltools as ct

SEQ_LEN = 1 # decode 阶段先固定成 1，prefill 另做一个包

STATE_SHAPE = None # 按你的模型层数/KV头数算

class DecoderWrapper(torch.nn.Module):

def __init__(self, m):

super().__init__()

self.m = m

def forward(self, input_ids, k_cache, v_cache):

out = self.m(input_ids, past_key_values=(k_cache, v_cache), use_cache=True)

return out.logits, out.past_key_values[0][0], out.past_key_values[0][1]

traced = torch.jit.trace(

DecoderWrapper(model).eval(),

(torch.zeros((1, SEQ_LEN), dtype=torch.int32),

torch.zeros(k_shape, dtype=torch.float16),

torch.zeros(v_shape, dtype=torch.float16)),

)

mlmodel = ct.convert(

traced,

inputs=[

ct.TensorType(name="input_ids", shape=(1, SEQ_LEN), dtype=np.int32),

ct.TensorType(name="k_cache", shape=k_shape, dtype=np.float16),

ct.TensorType(name="v_cache", shape=v_shape, dtype=np.float16),

],

outputs=[ct.TensorType(name="logits"),

ct.TensorType(name="k_out"), ct.TensorType(name="v_out")],

minimum_deployment_target=ct.target.iOS18, # 以 coremltools 官方文档支持的 target 为准

compute_units=ct.ComputeUnit.CPU_AND_NE, # 关键：明确点名 NE

)

mlmodel.save("qwen27b_decode.mlpackage")

```

compute_units 的取值直接决定你的模型跑在哪：

• ALL：系统自己挑，可能挑到 GPU，测出来的延迟解释不了；
• CPU_AND_NE：做 ANE 实测就用这个，把 GPU 排除掉，结果才可归因；
• CPU_ONLY：做基线对比用。

权重压到 2 bit 附近，用 palettize：

```python

from coremltools.optimize.coreml import (

palettize_weights, OpLinearQuantizerConfig, OptimizationConfig

)

op_cfg = OptimizationConfig(global_config=OpLinearQuantizerConfig(

mode="palettize", nbits=2, granularity="per_grouped_channel", group_size=64,

))

mlmodel_q = palettize_weights(mlmodel, op_cfg)

mlmodel_q.save("qwen27b_decode_2bit.mlpackage")

```

想做 4 bit 兜底层，就分开调用 palettize_weights，用 op_name_configs 只对指定层设 nbits=4。group_size 必须和你步骤三里的量化分组对上。

---

步骤六：ANE 后端的三个硬性约束

这是整条流水线里最容易卡住的地方。

约束一：形状固定，不能有动态维度。

ANE 要求编译期确定形状。所以标准做法是拆成两个模型：

• prefill 包：固定 seq_len = 512（或 256/1024，按内存挑），一次吞掉提示词；
• decode 包：固定 seq_len = 1，逐 token 生成。

提示词长度不是 512 的倍数时，左边补 pad，并保证 attention mask 把 pad 屏蔽掉。

约束二：KV cache 用 state 或者显式输入输出。

不要让图里带"会变的全局变量"。要么用 Core ML 的 states（有状态模型），要么像上面那样把 k_cache/v_cache 显式做成输入输出，在 Swift 侧自己搬运。后者更啰嗦但完全可控，调试期推荐后者。

约束三：一旦有 op 掉到 CPU，整个包的性能会被拖垮。

转换完必须验证算子落点：

```python

列出每一层的执行位置，重点看有没有大量 cpu 项

spec = mlmodel_q.get_spec()

for layer in spec.neuralNetwork.layers[:20]:

print(layer.name, layer.WhichOneof("layer"))

```

更可靠的办法是在真机上用 Xcode 打开 .mlpackage，看 Core ML 性能报告里各个 op 的 device 归属。常见掉 CPU 的原因：

• 用了 ANE 不支持的激活函数（某些变体、某些近似实现）；
• 出现了 int64 索引运算；
• 动态 reshape / 转置模式；
• 序列长度不是 16 的倍数（很多 ANE 实现对维度有对齐偏好）。

遇到掉 CPU，优先改图结构，不要试图靠调参数绕过。

---

步骤七：装到真机并解掉内存限制

新建 SwiftUI App，把两个 .mlpackage 拖进工程，勾选 target。然后加 entitlement：

```xml

<!-- YourApp.entitlements -->

<key>com.apple.developer.kernel.increased-memory-limit</key>

<true/>

```

不放心就先申请，被拒时收到的原因通常是"该能力面向特定类型的 App"，那就只能靠减小 KV cache 和缩短上下文来适配。

Swift 侧最小推理骨架：

```swift

import CoreML

final class Runner {

let prefill: MLModel

let decode: MLModel

init() throws {

let cfg = MLModelConfiguration()

cfg.computeUnits = .cpuAndNeuralEngine // 和转换时保持一致

prefill = try MLModel(contentsOf: Self.url("qwen27b_prefill"), configuration: cfg)

decode = try MLModel(contentsOf: Self.url("qwen27b_decode"), configuration: cfg)

}

static func url(_ name: String) -> URL {

let u = Bundle.main.url(forResource: name, withExtension: "mlmodelc")!

return u

}

/// 用 os_signpost 打点，Instruments 里能直接看到 prefill / decode 分段耗时

func generate(prompt: [Int32], maxTokens: Int) throws {

let t0 = CFAbsoluteTimeGetCurrent()

// ... prefill 打包 + 预测 ...

let tPrefill = CFAbsoluteTimeGetCurrent() - t0

var n = 0

let t1 = CFAbsoluteTimeGetCurrent()

while n < maxTokens {

// ... 单 token decode + 搬运 KV cache ...

n += 1

}

let tDecode = CFAbsoluteTimeGetCurrent() - t1

print(String(format: "prefill %.0f ms | decode %.2f tok/s",

tPrefill * 1000, Double(n) / tDecode))

}

}

```

注意：tok/s 一定要把 prefill 和 decode 分开报。混在一起报的那个数字，在提示词长度不同的两次测试之间毫无可比性。

---

步骤八：实测——tok/s、内存、发热

测什么、怎么测，比测出多少更重要。

1. tok/s

• 预热：先跑 3 次，丢弃，让模型加载和 ANE 编译完成；
• 正式跑 5 次，每次输出 128 token，报中位数；
• 分三档报：短提示（~32 token）、中提示（~512 token）、长提示（~2048 token）；
• 记录输出 token 数而不是字数。

2. 内存

不要用"感觉"，用两个来源交叉验证：

• Xcode → Debug Navigator → Memory，看进程 footprint 的峰值；
• 代码里读 task_vm_info 的 phys_footprint，采样间隔 200 ms 写日志。

峰值出现在 prefill 阶段而不是 decode，因为 prefill 的激活值大得多。这个峰值决定你的 App 会不会被系统杀掉。

3. 发热与降频

三个可观测信号：

• 时间序列：连续跑 10 分钟，每 30 秒记录一次 tok/s。曲线先平后掉就说明撞到降频了，记录掉到稳态用了多少秒、稳态是峰值的百分之几；
• Instruments 的 Energy Log：看能耗档位变化；
• 系统热状态：App 内可以观察 ProcessInfo.processInfo.thermalState，从 .nominal 走到 .serious 的时刻就是散热边界。

机身温度用外部手段（红外测温、温度贴）比读传感器更接近体感，但不写具体温度值，写"相对变化"更稳妥。

4. 记录模板（照抄这个表格填你自己的数）

报告纪律：模型名、量化配置（bits / group size / 是否含元数据）、设备型号与系统版本、提示词长度、采样方式，五样齐全，数字才有意义。少任何一样，别人都复现不了。

---

常见坑与排错

排错顺序建议固定成：先看算子落点 → 再看内存峰值 → 最后才调量化位宽。反过来调，你会在错误的方向上改十几轮。

---

下一步建议

1. 把 1.5 bpw 做成搜索问题。 现在你是手工分配位宽。写一个小脚本：对每个层类型枚举"2 bit / 4 bit"，用困惑度和实测 tok/s 做二维打分，跑一轮自动搜索，通常能在同样 bpw 下多拿回一截质量。

2. 做投机解码（speculative decoding）。 端侧完全可以挂一个 0.5B 量级的小模型当草稿模型，大模型批量验证。decode 是带宽瓶颈，一次验证多个 token 等于免费提速，这是端侧性价比最高的优化之一。

3. 量化 KV cache。 长上下文场景下 KV 会超过权重的一半。KV 压到 8 bit 甚至 4 bit，能直接把可用上下文翻倍，代价是长文一致性下降——值得单独测一轮。

4. 做分层卸载。 把冷层放闪存、热层常驻内存，用 mmap 按需加载。这条路能做"模型比内存大"的场景，但闪存随机读延迟会显著影响 tok/s，要有心理准备。

5. 建一个回归看板。 每次改量化配置或转换参数，自动跑固定提示集，把 tok/s、峰值内存、困惑度、重复率四个数打到一张表上。端侧调优的坑在于改动之间互相干扰，没有回归看板，你会在"这次好像快了点"的错觉里反复横跳。

最后提醒一句：先跑通"能出字"，再谈"跑得快"。 这条链路上任何一步的参数错误，都会伪装成"性能问题"出现在最后一步。分段验证、逐段留日志，比一次性调到最优要快得多。