在 M6 Mac 上把 ollama 换成 uzu，推理速度提升了 2 倍

一句话总结：纯文本编码场景，Apple Silicon 上 uzu 完胜 ollama——decode 快 2.3×、内存省 30%、默认 thinking 档位最优、自带 DFlash 投机解码。唯二硬伤：仅 macOS、无 vision。团队全 Mac 做 coding agent 的，建议直接全切。

缘起：为什么要折腾这事？

半年前我把主力推理从 llama.cpp 迁到 ollama，图个 ollama run 一条龙、模型库丰富、还有 vision。qwen3.8:27b-mlx-64k 跑在 M6 32GB 上，体验勉强能用：

• decode 25 tok/s，写个函数等半天
• prefill 100+ tok/s，塞 30k 上下文得等几秒
• 内存 23 GB，开个 Chrome + IDE 就要 swap
• 默认 think: medium，推理冗长得像废话文学，得手动改 xhigh
• 无投机解码，纯靠大模型硬生生吐 token

直到看到 uzu（Mirai Labs 出品） 的一句 slogan：

“Zero latency, full data privacy, no inference costs.”

再加上它自带 DFlash 投机解码、Mirai 量化（非对称 int4 + Hadamard 旋转）、原生 Metal 内核，号称专为 Apple Silicon 打磨。我不信邪，周末两天把它跑通、跑 bench、跑质量、写迁移脚本、写这篇文章。

uzu 是什么？（先科普一下）

uzu 不是一个模型，而是一个 推理引擎 + 模型生态：

关键区别：ollama 是“模型运行器 + 仓库”，uzu 是“推理引擎 + 量化体系 + 专属模型仓库”。你不能把 ollama 里的模型丢给 uzu 跑——格式完全不同。

我的对手：ollama 里的 qwen3.8:27b-mlx-64k

1
2
3
4
5
6

$ ollama show qwen3.8:27b-mlx-64k
architecture: qwen3_5
parameters: 27.8B
quantization: nvfp4          # NVIDIA FP4，移植到 MLX 跑
context length: 262144
capabilities: completion, vision, tools, thinking(levels: false/low/medium/xhigh)

• nvfp4：原本给 H100 用的 FP4，MLX 移植后精度尚可，但 Metal 上没专用内核，靠通用 fp16 累加模拟
• vision：多模态是加分项，但我 90% 场景是纯文本写代码
• thinking 默认 medium：这是最大的坑——medium 既慢又啰嗦，xhigh 才是最优档（后面数据说话）

我的新主力：uzu 的 Qwen3.8-27B-M

1
2
3
4
5
6

# HF 仓库：trymirai/Qwen3.8-27B-M (library_name: uzu)
quantization: Mirai-M (int4 asym + Hadamard, group=64)
size: 15.6 GB
context: 262144
speculator: DFlash (draft dim=512, hidden=17408, block=16, layers=[5,19,33,47])
capabilities: tools, reasoning(xhigh/medium/low/disabled)

• Mirai-M 量化：同 4-bit 下比 GGUF Q4_K_M / AWQ / nvfp4 都强，论文里 KL 散度-尺寸帕累托最优
• DFlash 投机：小 draft 跑在同一 Metal 队列，命中即跳过大模型前向，免费提速 15–20%
• 无 vision：纯文本 checkpoint，vision 需求留 ollama
• 原生 encoding：qwen3.8 rendering 继承 qwen3.6，天生支持 tools + 4 档 reasoning

迁移只需 3 分钟（已封装脚本）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

# 1. 装依赖
pip install -U "huggingface_hub[cli]"

# 2. 拉 uzu 专属格式权重（15 GB，约 2–5 分钟）
hf download trymirai/Qwen3.8-27B-M --local-dir <模型目录>

# 3. 必补 encoding.json（否则 pi 报 "no supported encoding"）
echo '{"type":"hanashi","name":"qwen3.8"}' > <模型目录>/encoding.json

# 4. 装 pi 扩展
pi install npm:@trymirai/uzu-pi-extension

# 5. 环境变量写入 <home>/.zshrc
echo 'export LOCAL_PATH=<模型目录>' >> <home>/.zshrc

# 6. 跑前停 ollama（防 Metal 隊列打架）
ollama stop qwen3.8:27b-mlx-64k

# 7. 爽了
pi --model "uzu/Qwen3.8-27B-M"

避坑：uzu 只认自家格式（config.json 是 uzu 自己的 schema，不是 HF 原始 config）。别想把 mlx-community/Qwen3.8-27B-4bit 或 GGUF 直接扔进 LOCAL_PATH——不行。

实测数据：吊打 ollama 的证据

硬件环境

• Mac mini M6 / 32 GB / macOS 27
• pi 1.2.0 / uzu 0.6.13 / ollama 0.40.11
• 同 prompt、同 32k ctx、贪婪采样、室温 22℃

速度对比（单位：tok/s）

反直觉发现：XHigh 不但不拖速度，反而是最快档——思考更短更收敛（reasoning 296 vs 408 字符，输出 145 vs 287 token）。关闭 thinking 最惨：推理全写进正文，410 token 啰嗦输出。

推理质量：11 道陷阱题，全通过

两边 11/11 全对，无可测差异。这难度对 27B 已饱和；想拉开质量差距需上 AIME/Codeforces 长链推理或大海捞针，留待后续。

pi 里的真实工具链体验（3 轮全过）

1
2
3
4
5
6
7
8
9
10
11

# 1. 读文件取值
$ pi -p -m "uzu/Qwen3.8-27B-M" "read <任意文本文件> 回 MAGIC_WORD"
pineapple-42 ✅

# 2. 读代码+改 docstring+跑验证
$ pi -p -m "uzu/Qwen3.8-27B-M" "读 fib.py 加 docstring 并 python3 fib.py 验证输出前 10 项"
OK（fib.py 真被改了）✅

# 3. 多工具连用
$ pi -p -m "uzu/Qwen3.8-27B-M" "列出当前目录所有 .py 文件并统计行数"
正确调用 bash/read ✅

• 冷启动 7–15 s（首次加载权重）
• 后续每轮 4–6 s
• 工具调用零差评，supportsToolCalls=true 实锤

坑与规避（必读，省你半天）

什么场景留 ollama？

迁移清单（落地到 dotfiles）

1
2
3
4
5
6
7
8
9

# <一键脚本>（新机一键）
#!/usr/bin/env bash
set -euo pipefail
pip install -Uq "huggingface_hub[cli]"
hf download trymirai/Qwen3.8-27B-M --local-dir <模型目录>
echo '{"type":"hanashi","name":"qwen3.8"}' > <模型目录>/encoding.json
pi install npm:@trymirai/uzu-pi-extension
grep -q 'LOCAL_PATH.*Qwen3.8-27B-M' <home>/.zshrc || echo 'export LOCAL_PATH=<模型目录>' >> <home>/.zshrc
ollama stop qwen3.8:27b-mlx-64k 2>/dev/null || true

1
2

# 常用别名
alias uzu='ollama stop qwen3.8:27b-mlx-64k 2>/dev/null; LOCAL_PATH=<模型目录> pi --model "uzu/Qwen3.8-27B-M"'

后续想玩的

1. 长上下文实测：64k/128k/256k 实际内存爬坡、KV 复用、needle-in-haystack 准确率
2. 量化损失对比：Mirai-M vs nvfp4 vs 原始 bf16，在 AIME 2024 / LiveCodeBench 上的 pass@1
3. DFlash 超参调优：block_size/target_layer_ids 对 decode 吞吐的边际收益
4. 多模型并发：32 GB 能否同时跑 27B + 9B（猜测：27B 16GB + 9B 6GB ≈ 22GB，留 10GB 系统，可行）
5. 自动化转换管线：HF 原始权重 → uzu config + safetensors（uzu-cli convert 还未开源，得盯着 repo）

写在最后

别信营销，跑数据说话。 如果你也是 Apple Silicon + 全职写代码 + 不需要 vision，把 ollama 停了，换 uzu，别犹豫。