BaseRT 跑了一遍 Qwen3.5-2B——期待落空，但也算个念想
本来以为是发现黑马的故事，结果变成了「你的硬件还不够好」的续集。
一、缘起
上一次用MacBook Neo测完 MLX 之后，我在文章里写了这么一句：「MLX 在 macOS 上确实最快」。
然后 BaseRT 就出现了。
铺天盖地的宣传文案：比 llama.cpp 快 6.4 倍，比 MLX 快 3.9 倍。配上 M5 Pro 上那些夸张的跑分数据——Prefill 两万五千 tokens/s，Decode 五百多 tokens/s。
说实话，我心动了。
如果你也在本地跑大模型，你应该能理解这种心情——每一次新的推理引擎发布，都忍不住想：这次会不会更快？我的 MacBook Neo 有没有可能再榨出一些性能？虽然MacBook Neo跟M5 Pro完全是两个世界的产物，但是好歹也是苹果的嫡系儿孙。
所以当我在 GitHub 上看到 BaseRT 的时候，第一反应不是怀疑，而是期待。
二、安装
BaseRT 的安装确实简单，一条命令：
curl -fsSL https://basecompute.co/install.sh | sh
装完就能用，自带模型下载、benchmark、聊天、API 服务——全部在一个 CLI 里。
basert pull <model> # 下载模型
basert bench <model> # 跑分
basert chat <model> # 聊天
basert serve <model> # 启动 API
这一点比 MLX 省心不少。MLX 要配 Python 环境、装 mlx-vlm、处理各种依赖问题，BaseRT 拿到手就能跑。我也搞不懂为什么原厂的MLX会比BaseRT安装要复杂的多？
对了，BaseRT 也支持 OpenAI 兼容的 API 服务，跑起来之后任何 OpenAI 客户端都能直接连，不需要改代码。
三、跑分
测试条件跟上次保持一致，方便直接对比：
| 项目 | 值 |
|---|---|
| 设备 | MacBook Neo (A18 Pro, 8GB) |
| 系统 | macOS 26.5 |
| 模型 | Qwen3.5-2B Q4 |
| BaseRT | v0.1.7 |
3.1 BaseRT 跑分
先把模型拉下来。1.2GB 的文件，网络慢，折腾了好一阵才下完。
跑 basert bench：
| 测试项 | 结果 |
|---|---|
| Prefill (pp512) | 448.94 t/s |
| Decode (tg128) | 43.66 t/s |
3.2 四个引擎横向对比
把这次的数据和上次的测试放到一起：
| 工具 | Decode | Prefill | 安装难度 |
|---|---|---|---|
| MLX 🏆 | 44 t/s | 未测 | ★★☆ |
| BaseRT | 43.7 t/s | 449 t/s | ★☆☆ |
| Ollama | 33 t/s | — | ★☆☆ |
| llama.cpp | 33.4 t/s | — | ★★★ |
MLX 44 t/s，BaseRT 43.7 t/s。差距 0.3%，其实就是实验误差。
四、BaseRT vs MLX——谁更快？
4.1 数据说话
同样 MacBook Neo，同样 Qwen3.5-2B Q4，同一个 Wi-Fi。
BaseRT 跑出来的 Decode 速度是 43.66 t/s。MLX 是 44 t/s。
两者基本上是一样的，连误差范围都差不多。
其实测完第一轮我就知道结果了。BaseRT 没有像宣传的那样「碾压」MLX，至少在我的 MacBook Neo 上没有。
4.2 为什么会这样？
BaseRT 官方的 6.4x 和 3.9x 是在 M5 Pro 上跑出来的。M5 有专用的 Tensor Core，BaseRT 的手写 Metal 4 内核能充分利用这个硬件。而我的 MacBook Neo 是 A18 Pro——
- 没有 M5 的专用 Tensor Core
- GPU 核心数比 M 系列少
- 内存带宽也低一截
在这个硬件上，MLX 和 BaseRT 都跑到了带宽瓶颈附近，谁也没办法再快多少。
这其实跟上次测 llama.cpp 和 Ollama 的结论很像：瓶颈在硬件，不在软件。
| 配置 | BaseRT | MLX | 领先方 |
|---|---|---|---|
| M5 Pro (官方) | 530 t/s | 398 t/s | BaseRT 🏆 |
| A18 Pro (本文) | 43.7 t/s | 44 t/s | MLX（误差内打平） |
| A18 Pro + Ollama | — | 33 t/s | — |
我能找到的最诚实的说法是：BaseRT 的意义在 M4/M5 以上的芯片上才能体现出来。 对于 A18 Pro 甚至更老的 M1/M2，它和 MLX 拉不开差距。
五、BaseRT 值得一试吗？
抛开跑分，聊聊实际体验：
好的地方：
- 安装极简，一条命令搞定，不需要折腾 Python 环境
- 自带 benchmark，跑分很方便
- OpenAI 兼容 API，启动即用
- CLI 设计得很清爽，pull/bench/chat/serve 都在一个命令里
不够好的地方：
- 模型生态还在早期，支持的模型没有 MLX 和 llama.cpp 多
- 核心推理引擎不是完全开源
- 对老芯片的优化不明，至少 A18 Pro 上没看到明显优势
- GGUF 格式不能直接用，需要转换，转换还经常失败
我最想吐槽的是 GGUF 转换。我之前测试llama时本地有好几个下好的 Qwen3.5-2B GGUF 文件，想着直接转成 .base 格式就能跑。结果试了四个版本——
| 版本 | 转换结果 | 对话结果 |
|---|---|---|
| 原版 Q4_K_M | ❌ 0 张量映射 | — |
| diodel 版 | ✅ 320 张量映射 | ❌ 乱码 |
| fixed 版 | ❌ 0 张量映射 | — |
| unsloth 版 | ❌ 0 张量映射 | — |
唯一成功映射的一个，跑出来满屏乱码。
gemma-4-E2B 也是一样，541 个张量全映射了，但对话全是 "<pad> dimensions কম্পিউ..." 这样的碎字符。
后来查了一下才知道，--allow-quant-from-quant 会把 GGUF 的 K-quant 数据强行塞进 BaseRT 的量化格式，张量名能对上，但权重数据是错的。官方文档也写了——量化转量化会累积误差。
六、后记
这次测试从期待到失落，情绪起伏还挺大的。
看到 BaseRT 宣传文案的时候，我真的以为找到了一个比 MLX 更快的引擎。结果在同一台机器上跑下来，两个工具的数据几乎一模一样。说实话，心里有点失落。
但冷静下来想想，这其实不是 BaseRT 的问题，是我这台 MacBook Neo 的问题。A18 Pro 的硬件天花板就摆在那里，不管哪个引擎来跑，都要受内存带宽和 GPU 核心数的限制。BaseRT 的优化在 M5 上能发挥出来，但在我这台机器上，硬件本身成了瓶颈。
而且换个角度看，BaseRT 有一件事做得特别好——它给了一个念想：换一台 M4 或 M5 的机器，性能还能翻倍。 MLX 在 M5 上跑不到 530 t/s，但 BaseRT 能。
所以我最后的建议是：
- 如果你用的是 M4/M5 芯片的 Mac，BaseRT 值得一试，可能真的有惊喜
- 如果你用的是 老芯片（M1/M2/A 系列），MLX 和 BaseRT 选哪个都行，速度差不多
- 如果你追求最简单上手的体验，BaseRT 的零配置 CLI 确实比 MLX 省心
至少现在我知道了，在 Apple Silicon 上跑大模型这件事，天花板比我想象的高——只是需要换一把更好的梯子。
环境配置：
设备: MacBook Neo (A18 Pro, 8GB) + macOS 26.5
模型: Qwen3.5-2B Q4 (BaseRT 原生 .base 格式)
BaseRT: v0.1.7
对比数据来源 - MLX: mlx 0.32.0 + mlx-lm 0.31.3
对比数据来源 - Ollama: v0.31.1 + Metal + Flash Attention
对比数据来源 - llama.c.cmaster 自编译 + Metal GPU