Apple Silicon

如果你只看标题，TurboFieldfare 很容易被误读成又一个“神奇压缩模型”的项目：26B 参数，2GB 内存，任意 M 系列 Mac 都能跑。 我一开始也有点怀疑。因为做过本地推理的人都知道，内存不会凭空消失。模型权重、KV cache、运行时缓冲区、系统占用，哪一项都不是靠一句“优化”就能省掉的。真正值得研究的地方不是“它怎么把 14GB 变成 2GB”，而是它愿意用什么代价换掉这部分内存。 答案很工程化：TurboFieldfare 没有把完整模型塞进内存，而是把 Gemma 4 26B-A4B 的共享权重和 KV cache 留在内存里，把路由专家权重放在 SSD 上，每生成一个 token 时只读取当前会用到的专家。项目 README 明确说，它面向 Apple Silicon，用 Swift 和 Metal 写了一个模型专用 runtime，不是 MLX 或 llama.cpp 的薄封装。HN 上这条 Show HN 也拿到了很高讨论度，说明大家真正关心的是同一个问题：本地大模型推理，能不能从“必须买大内存机器”变成“接受慢一点，但普通机器也能跑”？ 项目地址在这里：drumih/turbo-fieldfare，HN 讨论记录可见 HN Algolia 条目 49098510。我建议先把它当成一个外存推理实验看，而不是马上当成生产推理引擎看。 它省的不是模型大小，而是常驻内存 TurboFieldfare 选择的模型是 Gemma 4 26B-A4B 的 4-bit 指令版本，权重来源是 Hugging Face 上的 mlx-community/gemma-4-26b-a4b-it-4bit。按项目文档，它的文本部分安装后大约 14.3GB，但运行时常驻内存主要是 1.35GB 的共享权重、FP16 KV cache 和一些工作缓冲区。 关键在 A4B 这个 MoE 结构。Mixture-of-Experts 模型并不是每次都激活所有专家。TurboFieldfare 的系统设计文档写得很细：每层有 128 个 routed experts，router 每个 token 选择 8 个；同时还有 dense shared expert 分支。于是它把“专家权重”从常驻内存里拆出来，按层存成文件，推理时用显式 pread 把当前 token 需要的专家读进缓存槽。 ...

如果你只有一台 Mac 电脑，想从单张图片生成 3D 模型——直到今天，这基本上是个伪需求。市面上最好的开源图片转 3D 技术，几乎全部围绕 NVIDIA CUDA 构建，买不到合适的硬件就等于玩不了。 这个局面正在被打破。 TRELLIS.2 是微软 2025 年发表在 CVPR 的论文提出的图片转 3D 方法，在 GitHub 上有 1.2 万星，官方仓库清一色 CUDA 代码。近日有个开发者把它完整移植到了 Apple Silicon，M4 Pro 上 3.5 分钟就能生成一个 40 万顶点的网格模型，全程跑在苹果自研芯片上，不需要半块 NVIDIA 显卡。 移植的核心思路：替换掉 CUDA 依赖 TRELLIS.2 依赖好几个 CUDA 专用的库，官方版本开箱即用但根本不支持 Metal。这不是简单的编译选项问题，而是代码里大量硬编码了 .cuda() 调用和 CUDA 核函数。 移植的思路很直接：找到每一个 CUDA 依赖，用 PyTorch 原生功能或纯 Python 实现替换。 主要替换关系如下： 原始（CUDA） 移植版本 用途 flex_gemm backends/conv_none.py 子流形稀疏 3D 卷积，通过 gather-scatter 实现 o_voxel._C hashmap backends/mesh_extract.py 从双体素网格提取网格面 flash_attn PyTorch SDPA 稀疏变换器的注意力机制 cumesh Stub（跳过） 网格孔填充与简化 nvdiffrast Stub（跳过） 可微分光栅化（仅影响纹理导出） 稀疏 3D 卷积的替换是个技术亮点。原始 flex_gemm 做的是子流形稀疏卷积——3D 生成任务中只有物体表面有数据，不需要对整个空间做卷积。移植版本用 Python 构建空间哈希表，对每个活跃体素收集邻域特征，通过矩阵乘法应用权重，再把结果 scatter 回去。neighbor maps 做了缓存避免重复计算。 ...