Apple的设备端模型在聊天方面表现糟糕，但在结构化输出和工具调用方面表现出色

我花了几周时间对Apple的设备端模型进行压力测试——这是一个约3B参数的模型，运行在任何Apple Silicon Mac的Neural Engine上。为了全面测试，我构建了Think Local，这是一个macOS应用，可以测试模型的每项功能：聊天、图像生成、结构化输出、工具调用和参数比较。

我的结论：作为聊天机器人，这个模型表现糟糕。但作为结构化输出和工具调用引擎，它出人意料地优秀。

这种区别很重要，因为它完全改变了你应该如何使用这个模型。

聊天表现令人失望——但这没关系

Apple的模型上下文窗口只有4,096个token。对比一下：Claude有100万个token，GPT-4o有128K。使用Apple的模型时，你放入200个token的系统提示，150个token的模式定义和三轮对话，就已经用了70%。

自由文本的质量也不令人印象深刻。回答正确但通用，长会话中重复性强，安全防护机制经常出现令人困扰的误报——问它网络安全相关问题，有时会拒绝回答，因为它对"攻击"这个词理解过于字面化。

如果你把它当聊天机器人来评估，它就是一个平庸的模型。但这样评估就像批评螺丝刀不是好锤子一样。

闪光点：约束解码

这里一切都不同了。Foundation Models支持@Generable——一个将Swift结构体转换为模式的宏，模型必须遵守这个模式。这不是"请求JSON然后祈祷"。这是约束解码：在生成过程中，模型字面上无法输出违反模式的token。

@Generable
struct BugReport {
    @Guide(.anyOf(["bug", "feature", "task"]))
    var type: String
    @Guide(.anyOf(["low", "medium", "high", "critical"]))
    var priority: String
    var title: String
    var description: String
}

使用这个模式，你告诉它"分类：应用在旋转设备时崩溃"，它会返回：

{
  "type": "bug",
  "priority": "high",
  "title": "Crash on device rotation",
  "description": "The application crashes when the user rotates..."
}

受限字段（type、priority）始终有效——它不能编造列表之外的值。自由字段（title、description）连贯且简洁。我用几十种不同的输入进行了测试：在200多次执行中，模式错误为零。

在这个模型中，自由生成和约束解码之间的差异是巨大的。这就像让初级开发者随意写作与给他一个有定义字段的表单之间的区别。表单总是获胜。

工具调用：一个知道自己不知道什么的3B模型

这是最让我惊讶的。定义一个工具get_weather(city: String)，问它"马德里天气如何？"，它会生成一个带有正确参数的结构化调用。问它"法国的首都是什么？"，它会直接回答——它知道不需要工具。

一个3B参数的模型，在你的笔记本电脑上运行，无需网络，能区分何时使用工具，何时不用。它不完美——对于模糊的提示有时会困惑——但在明确输入上的准确率很显著。

Apple的工具调用使用相同的约束解码机制：调用是一个@Generable结构体，所以参数始终有效。没有损坏的JSON解析，也没有编造的参数。

Image Playground：没人提到的另一个模型

Apple Intelligence不仅仅是文本。Image Playground是一个独立的框架，在设备上生成三种风格的图像：动画、插图和素描。它也完全在Neural Engine上运行，无需网络。

模式重复：对于它设计的用途，它工作得很好。图标、贴纸、简单构图——结果出人意料地好。图像中的文本、详细的人体解剖学、复杂构图——灾难性的。

Think Local包含一个图像工作室，你可以在其中测试提示并并排比较风格。通过十分钟的提示测试获得的直觉是任何基准测试都无法提供的。

数据

在Apple Silicon Mac上测量，使用Think Local的资源监视器：

电池数据很重要：Neural Engine在推理方面的消耗明显少于CPU。在生成过程中，CPU因为数据封装和UI略有上升，但繁重的工作交给Neural Engine。这使得在后台使用模型进行工具开发成为可能——git钩子、代码检查器、分类器——而不会耗尽笔记本电池。

适用和不适用的场景

使用它来：

• 分类和分流（bug、邮件、工单）→ 使用@Generable的约束解码
• 从自由文本提取结构化数据 → 使用@Guide的模式
• 轻量级工具调用（搜索、计算、查询）→ 类型安全的调用
• 短文本草稿和摘要 → 在4K token限制内
• 生成简单图像（图标、贴纸、插图）→ Image Playground
• 任何可以定义输出格式的任务

不要使用它来：

• 长对话 → 4K窗口在3-4轮就用完了
• 复杂或多步推理 → 模型太小
• 长创意生成 → 回答通用且重复
• 任何需要2023年10月后知识的内容

试试看

Think Local是开源的（MIT许可）。该应用通过可视化UI测试所有这些功能：实时显示消耗上下文的token可视化器、模式编辑器、工具调用实验室，以及比较模式来查看不同参数如何改变回答。

git clone https://github.com/frr149/think-local.git
cd think-local
open Package.swift

要求：macOS 26、Apple Silicon、启用Apple Intelligence。零依赖、零API密钥。

结论

Apple没有构建聊天机器人。它构建了一个具有约束解码和工具调用功能的本地推理引擎，而这个引擎恰好也能聊天。如果你把它当聊天机器人评估，它会输给所有对手。如果你把它当作在你硬件上免费运行、无需网络和API密钥的结构化输出引擎来评估——它没有竞争对手。字面上没有其他人提供这样的服务。

正确的问题不是"Apple能与GPT-4竞争吗？"——它不能。问题是"我能用一个免费运行、本地部署、具有约束解码功能的3B模型构建什么？“答案是：比你想象的要多得多。