Cua 的团队此前以 macOS 虚拟化栈 Lume 起步。苹果自家的 Virtualization.framework 让 macOS 客户机通过虚拟 GPU 使用宿主的 Apple GPU，但在默认配置下，这个虚拟设备上报了一套非常保守的 Metal 能力档。应用程序正是根据这些应答来选择计算内核和渲染路径，于是 llama.cpp 在虚拟机里走了更慢的 GPU 代码路径。

虚拟机里的 GPU 被「降级」了

问题出在能力查询的应答上。在 Cua 基于 macOS Tahoe 的标准虚拟机里，这块虚拟显卡上报的近似能力是「Apple 5 时代家族」、最大线程组内存仅 32 KB，并且不支持 SIMD 组矩阵运算。现代 Metal 软件会依据这些应答挑选内核，即便设备其实能跑更新的内核，llama.cpp 也只会选择更慢的实现。

苹果官方文档通过「GPU 家族与特性表」来描述 GPU 能力，并建议应用在运行时查询设备。换言之，应用程序只是照着平台告诉它的边界来工作。这与常见的 GPU 直通不同：在 x86 Linux 上可以通过 VFIO 把物理 PCI 设备直接分配给虚拟机，而苹果这套是半虚拟化架构，宿主机仍掌控硬件，客户机使用的是虚拟化感知的设备。

进程级补丁做了什么

Cua 团队写了一个很小的 Metal 能力补丁，作为兼容层插在某个客户机进程与 Metal API 之间。它只拦截并改写该进程读到的少数几项能力应答：把支持的家族档提升到 Apple family 9（编号 1009），并把最大线程组内存从 32 KB 提到 64 KB。就这两项改动，足以让被测的 llama.cpp 版本改用更新的 SIMD 组归约、SIMD 组矩阵与 bfloat16 路径。

关键在于，这个补丁只作用于被注入的那个工作进程及其子进程，工作负载仍然跑在苹果现有的虚拟 GPU 通道上，由宿主的 Apple GPU 执行；它不涉及物理 GPU 直连、原始 PCI 或 VFIO 直通，也不改动内核。其余能力档保持默认不变，配置缺失或格式错误时会自动回落到标准路径。

实测：提速 7 到 16 倍

测试在一台 Apple M1 Ultra（48 核 GPU）、宿主 macOS 26.6.1 上进行，客户机为当前公开的 Tahoe Cua 镜像（macOS 26.5.2、8 个虚拟 CPU、16 GiB 内存），运行 Lume 0.5.1，统一使用官方 llama.cpp b10167 版本。

使用 TinyLlama 1.1B 对话模型（Q4_K_M）时，提示处理从标准虚拟机的每秒 431.86 个词元提升到解锁后的 4786.70 个词元，达到裸机的 98.25%；生成速度从每秒 12.63 个词元提升到 206.60 个词元，相当于裸机的 72.06%。两项提升分别为 11.08 倍与 16.36 倍。

换成 Google 今年发布的 Gemma 4 12B（QAT Q4_0，约 6.98 GB）后，提示处理从每秒 71.66 个词元提升到 515.76 个词元，达到裸机的 99.59%；生成从每秒 3.41 个词元提升到 49.67 个词元，相当于裸机的 94.82%，提升分别为 7.20 倍与 14.54 倍。

再用 Meta 官方的 Muse Glimmer 30B（Q4_K-M，约 16.76 GB，客户机内存提到 64 GiB）测试，提示处理从每秒 25.83 个词元提升到 194.97 个词元，生成从每秒 2.38 个词元提升到 21.08 个词元，提升分别为 7.55 倍与 8.87 倍。作为对照，MLX-LM 0.31.3 在标准中就已经很快，补丁前后几乎持平（提示 1.005 倍、生成 0.993 倍），这也帮助团队定义了发布时所覆盖的能力档范围。

局限与适用边界

这项技术仍是实验性的，且对版本敏感：它依赖客户机 Metal 实现中私有的、随 macOS 版本可能变化的行为，因此每一个宿主与客户机组合都需要单独验证。补丁只影响被注入的工作负载，加固或受平台保护的程序可能拒绝库注入；它覆盖的能力档也仅限于已测试的范围，物理 GPU 能力发现不在其内。

Cua 已将相关源码以与 Lume、Cua 相同的宽松许可证开放，并附带构建脚本、能力探测与原始基准日志，供他人复现。对于需要在苹果芯片虚拟机里跑本地推理的开发者，这层补丁提供了一个值得关注的起点——前提是接受它的实验属性，并为每个系统组合自行核验。

来源：Cua 官方博客（GitHub 项目 trycua/cua），作者 Francesco Bonacci 与 Johnny Franks

很多人以为跑本地大模型一定得配一张昂贵的独立显卡。这个说法有一半是对的——确实有不少任务离不开显卡。但模型世界里还藏着一大批体积小、却能把事情做漂亮的小模型。只要手边有一台近五年内生产的旧电脑或笔记本，内存不低于 8GB，就能跑起来，速度大约在每秒 10 个词元上下。这个速度听起来不起眼，可在不少实际场景里，原始速度根本不是关键。

第一行命令：用 Ollama 起一个本地服务

对于大多数想自己托管 AI 的人来说，Ollama 几乎成了默认选择。它内置模型库，提供一套兼容 OpenAI 的接口，能在本地直接拉起一个服务进程。基于开放权重模型搭建真正能执行任务的 AI、而非单纯对话，它再合适不过。

最大的好处是省心。硬件探测、量化版本选择这类琐碎活儿，Ollama 都替用户打理了。唯一要盯紧的是量化设置：选错格式的后果很严重，仅仅两比特的差别，就能让整机性能天差地别。选定模型后，执行 ollama pull 模型名 拉取，再 ollama run 模型名 就能对话。

要榨干性能：试试 llama.cpp

llama.cpp 是一套专门跑 GGUF 格式模型的推理引擎。它没有界面开销，把能用的 CPU 优化都用到了极致，适合那种「每一分性能都要抠」的场景，代价是上手更费劲。

它高度依赖命令行（不过也有网页界面可用），模型文件得自己管理，量化格式也得自己搞明白。起步方式是下载发布版或自行编译，再从 Hugging Face 取一份 GGUF 模型，用 llama-cli 或 llama-server 跑起来。有一项设置至关重要：把上下文长度封顶，别用默认值。KV 缓存吃掉内存的速度快得惊人，设太高整机立刻卡死。

给老旧硬件的礼物：Gemma 4 边缘模型

Gemma 4 家族里最小的两员——E2B 与 E4B——于 2026 年春天专为「边缘」硬件发布。名字里的「E」代表有效参数量，用更少的显存堆出更深的层次。举例来说，E4B 在 4 比特量化下大约只占 5GB 内存。

它们擅长摘要、起草、抽取结构化数据、翻译这类基础活儿，也能做一点推理，只是比不上更大的思考型模型。通过 Ollama 使用时，按内存选型号：有 8GB 就上 E4B，更少就退到 E2B。上下文也别拉太高，一样会挤占内存。

慢笔记本的绝配：给相册自动写说明

这篇文章里最受青睐的本地 AI 项目之一，是个给截图自动生成描述的小程序。这套配置跑在显卡上，但完全没有理由不能挪到 CPU 上，尤其是不要求实时的时候。批量给一整个文件夹的照片生成说明文字或替代文本，正是慢笔记本的理想任务——模型每秒吐三个词元，即便在无人值守时运行，慢一点也无妨。

可选方案有好几个：Moondream2（或 Moondream3，约 16 亿参数）专为边缘设计，4 比特量化下轻松塞进 3GB；SmolVLM 2B 是开放权重模型，擅长批处理；Gemma 4 E4B 每个版本都带视觉能力。要是想翻找过去十年的照片并让它们变得可搜索，这招极其实用。建议先用十几张差异很大的图试试水，再决定要不要丢进上万张的图库。

把文档搜索变聪明：私有语义检索

电脑自带搜索基本是「傻瓜式」的，只认敲进去的字面关键词。换上 AI，就能做语义搜索——用更自然的描述去找东西，不必字字对应。推荐先从 EmbeddingGemma 入手：它只有 3.08 亿参数，量化后内存占用不到 200MB，甚至能把输出向量从 768 维截到 128 维而几乎不损质量。把它接在 Ollama 服务后，配合 AnythingLLM 或 Open WebUI 就能用。只是要记住，在 CPU 上扫一遍庞大的文档库，动辄要等上几个小时。

怎么选：快用 llama.cpp，图省心用 Ollama

想要最快的搭建，选 llama.cpp；对其他人，作者强烈推荐 Ollama，那份省心简直是游戏规则的改变者。若一时没有特定模型目标，先从 Gemma 4 的边缘型号起步最稳妥——它们能做的事多到惊人，而且哪怕是一台「土豆机」也带得动。

来源：How-To Geek（作者 Nick Lewis，2026 年 8 月 11 日）

XDA 撰稿人分享了自己的排查过程：元凶往往不是模型，而是设置面板里两个几乎没人动过的滑块——重复惩罚（repeat penalty）与出现惩罚（presence penalty）。二者功能相近却各司其职，网上大量教程把它们混为一谈，反而误导了调参方向。

一、默认值为什么不适合日常使用

本地模型的默认参数多为跑分评测调校，并非为日常对话设计。日常很少人每次都精心挑选示例、配上完整思维链指令。

LM Studio、Ollama、llama.cpp 基于同一核心引擎，但默认参数各自不同。

量化会把问题继续放大。多数人为了塞进显存跑 Q4 或 Q5 而非 FP16，精度一降最先冒头的就是重复和循环，小模型尤其明显。另外 Qwen 倾向过度解释，Gemma 长对话易啰嗦。

二、两个滑块分别管什么

重复惩罚是词元级别的控制，来自 2019 年的 CTRL 论文，作用是惩罚已出现过的具体词元。中性值 1.0，高于 1.0 开始抑制复用。甜区很窄，调到 1.05 或 1.1 通常就能清掉词语层面的循环；一旦推到 1.2，模型可能连「的」这类常用词都开始躲，输出反而古怪。命名上需留意：llama.cpp 称 repeat_penalty，OpenAI 接口最接近 frequency_penalty，Hugging Face 则名 repetition_penalty。

出现惩罚同样作用在词元层，算法却不同。重复惩罚随复用次数加重，出现惩罚是「出现过就扣一次固定分」，出现十次和一次扣得一样多，中性值 0，常见区间 -2.0 到 2.0。它把模型推离刚用过的那批词，换了词往往就换了话题——「同一个观点绕四遍」正源于此，并非模型真在做语义理解，只是好用的词元被耗尽后的副产品。

三、三组实测对照

这位撰稿人用同一条提示词跑了三轮，模型、温度、min-p、系统提示词全部固定，只改这两个参数：「用三种方式解释什么是 REST API：面向新手、懂 HTTP 的人、正在动手实现的人」。

1. 两项都保持中性：回答表面正常，但 Qwen 犯了老毛病，每个小节都要先把「REST API 是一套规则」重述一遍才进入正题。
2. 两项都拉满（重复 1.3、出现 1.8）：开头尚可，接近结尾时不再生成完整句子，退化成一串地理名词堆砌，只能手动中止。这就是过度矫正——惩罚把合理的高概率词元也饿死了。
3. 取中间值（重复 1.1、出现 0.6）：输出干净的三段式解释，三类读者各自拿到了不同角度。

注意事项

这两个滑块奖励微调、惩罚猛拉。上述数值是在 LM Studio 里跑 Qwen 9B 得出的，只能当起点。温度也会参与其中：处于 0 或 0.1 时模型本就趋于确定，惩罚几乎没有发挥空间，0.6 到 0.8 之间才留有余地。

按任务微调同样重要：写代码时重复惩罚应贴近中性，因为代码本就要重复语法；推理类模型需要更低的出现惩罚；Q3、Q4 这类低精度量化整体宜用更轻的惩罚。模型的 Hugging Face 页面若给了推荐配置，从那里开始最省事。

来源：XDA Developers