苹果智能

Apple 的 Foundation Models 框架（macOS 26）提供了一个约 30 亿参数的 LLM，可以在设备端运行，免费，无需 API key。但有个问题：它只能使用 Swift。而且不是普通的 Swift——是 Swift 的 async 版本。 你的工具链是 Python 吗？没有绑定。用 Rust？也没支持。脚本语言 Shell？完全没法用。这个世界上最便宜的 LLM（确实免费）被困在两堵墙后：语言和并发模型。 显而易见的解决方案是搭建一个本地 HTTP 服务器，将模型暴露为 REST API，像 Ollama 那样。但这就像是用大炮打蚊子：一个进程在后台运行，占用一个端口，JSON 来回传递，每次问一个简单的问题都要用到 curl。如果只是给一个 commit 分类为 fix 或 feat，你不需要 HTTP，你需要的只是一个简单的 C 函数。 仅有 4 个函数的 dylib 所以我做了 libfoundationmodels：一个动态库，把 Apple 的框架编译为 .dylib，它仅导出 4 个 C 函数： int32_t fm_init(void); int32_t fm_is_available(void); int32_t fm_generate(system, prompt, output, output_len); int32_t fm_classify(system, prompt, choices, output, output_len); --- 嗯，算上 `fm_generate_json` 是 5 个函数，但核心思想未变：四个概念——初始化、检查可用性、生成自由文本，以及在选项中强制分类。全部同步。全部阻塞。输入缓冲区、输出缓冲区、返回代码。经典的 C 风格。 从 Python 调用它是这样的： ```python import ctypes fm = ctypes.CDLL("libfoundationmodels.dylib") fm.fm_init() buf = ctypes.create_string_buffer(256) fm.fm_classify( None, # 没有系统提示 b"fix: handle nil response in OAuth", # 要分类的文本 b"fix\nfeat\nrefactor\ntest\ndocs", # 选项 buf, 256 ) print(buf.value.decode()) # "fix" 就是这样。没有 requests。没有 urllib。没有 JSON。没有运行的服务器。调用一个 C 函数，它会内部唤醒你 Mac 的 Neural Engine，传入文本，并将结果写回缓冲区。典型延迟：200-800ms。 ...

昨天我用 Claude Code 写了一条 commit message。diff 是一行修改：一个注释里的拼写错误。Claude Opus 读取了 diff，思考了两秒钟，生成了 fix: correct typo in auth comment。为此，它用了大约 800 个输入 token 和 30 个输出 token，分别花费 $15 和 $75 每百万 token。总成本：不到一分钱。但是，把这个过程放大到一天 40 次 commits，250 个工作日，一家公司有 200 名开发者使用 coding agents，那么这些看似微不足道的花费会积累成数千美元的开销，付出的只是等同于贴创可贴的智力劳动。 问题并不是 Opus 太贵。问题在于 coding agents 不会区分 $0.001 的任务和 $0.10 的任务。一切都通过同样的大模型执行。生成 commit 信息、分类一个 issue、验证格式 —— 全部使用高成本的模型，就像雇用一位外科医生来贴创可贴。 数据与成本 我们用 Claude Opus 4（上一代，目前大部分生产环境还在用的版本）的价格来算一个账： 任务 输入 Token 数 输出 Token 数 成本 生成 commit 信息（小型 diff） ~800 ~30 $0.014 分类某个 issue ~500 ~50 $0.011 验证 commit 格式 ~300 ~20 $0.006 生成 standup 报告 ~2000 ~200 $0.045 这些任务都不需要一个拥有 2 万亿参数和多步推理能力的大模型。这些仅仅是带有强约束的分类和生成任务。本质上就像是根据颜色对卡片进行分类。 ...