在Mac上构建本地AI API网关：afm的安装、配置与实战指南-编程实验室

1. 项目概述：在Mac上构建一个完全本地的AI API网关

如果你和我一样，是一个对隐私敏感、又热衷于在本地设备上折腾AI的开发者，那么你肯定对“把AI模型完全跑在自己的电脑上”这件事有执念。过去几年，我尝试过Ollama、LM Studio，也自己编译过llama.cpp，虽然都能实现本地运行，但总感觉在苹果生态里差了那么点意思——要么是性能没完全榨干Metal GPU，要么是API兼容性不够好，要么就是安装配置过程太折腾。

直到我遇到了afm（Apple Foundation Model Server），或者说，它的完整项目名maclocal-api。这个由开发者 scouzi1966 用纯Swift编写的工具，彻底改变了我的工作流。它的核心目标极其清晰：在你的Apple Silicon Mac上，提供一个与OpenAI API 100%兼容的本地服务器，后端既可以调用苹果官方的“Apple Foundation Model”，也可以运行任何来自Hugging Face的MLX格式开源大模型。没有Python环境依赖，没有云端调用，不需要API密钥，所有计算都发生在你的Mac的GPU上。

简单来说，它把你的Mac变成了一个功能完备的本地AI服务器。无论是想用苹果自家的3B小模型快速处理一些文本任务，还是想加载一个70B参数的Qwen大模型进行深度推理，抑或是想通过一个统一的API接口来管理你本地部署的Ollama、LM Studio等多个AI后端，afm都能搞定。更让我惊喜的是，它还集成了基于Apple Vision的OCR功能，能直接从图片或PDF里提取文字，并且通过HTTP API暴露出来，这为自动化工作流打开了新的大门。

这个项目特别适合以下几类人：

注重隐私的开发者：不希望任何数据离开本地设备。
全栈工程师或应用开发者：想要快速为你的应用集成AI功能，但又不想依赖OpenAI或Anthropic的API，afm提供了一个完美的、可自托管的替代方案。
AI爱好者和研究者：想在Mac上方便地测试、对比不同开源模型（尤其是MLX社区量化过的模型）的表现。
自动化脚本作者：可以通过简单的cURL命令或Python脚本，调用本地的AI能力处理文档、分析日志、生成内容等。

接下来，我将从一个深度使用者的角度，带你彻底拆解afm，从设计思路、安装部署、核心功能使用，到高级配置和实战避坑，让你能真正把这款强大的工具用起来。

1.1 核心设计思路：为什么是Swift和MLX？

在深入命令行之前，理解afm的底层设计选择至关重要，这能帮你预判它的能力边界和最佳使用场景。

首先，为什么用Swift重写？市面上大多数本地AI工具链（如llama.cpp, Ollama的核心）是基于C++或Python的。虽然它们也能在Mac上运行，但Swift作为苹果的“亲儿子”语言，在macOS上拥有无可比拟的优势：

极致的Metal性能：Swift能直接、高效地调用Metal Performance Shaders框架。afm在运行MLX模型时，能实现几乎零开销的GPU内存管理和计算调度，这是通过Python桥接或通用C++实现难以达到的。实测中，相同模型在afm下的Token生成速度通常有可感知的提升。
原生框架集成：调用“Apple Foundation Model”必须通过苹果私有的CoreML和FoundationModels框架。用Swift调用这些系统级API是最直接、最稳定的方式，避免了跨语言调用可能带来的复杂性和性能损耗。
轻量级部署：编译后的Swift可执行文件是静态链接的，不依赖庞大的Python运行时或复杂的C++库环境。通过Homebrew或直接下载二进制包，安装就是一行命令的事，干净利落。

其次，为什么拥抱MLX格式？MLX是苹果机器学习团队专为Apple Silicon优化的数组框架。mlx-community在Hugging Face上维护了一个庞大的模型仓库，里面包含了主流的Llama、Qwen、Gemma等模型经过量化、转换后的MLX格式版本。

开箱即用的优化：这些社区转换的模型已经针对M系列芯片的GPU和统一内存架构做了深度优化，你无需自己处理复杂的模型转换、量化过程。
统一的加载接口：afm通过swift-huggingface库，可以直接识别和加载这些模型文件，实现了“模型名称即参数”的简易体验。你只需要知道Hugging Face上的模型ID，如mlx-community/Qwen2.5-72B-Instruct-4bit，afm会自动处理下载、缓存和加载。

最后，API网关的设计哲学。afm不仅仅是一个模型服务器，它更是一个智能代理。当你启动网关模式（-g）时，它会自动在本地网络中发现其他AI服务（Ollama、LM Studio、Jan等），并将它们统一聚合到自己的/v1/chat/completions端点下。这意味着你的应用程序只需要连接afm一个地址，就可以在后台灵活切换或负载均衡到多个不同的模型提供商，极大地简化了客户端架构。

2. 从零开始：安装与部署的完整指南

afm提供了多种安装方式，我会逐一分析其适用场景和潜在问题，帮你做出最适合的选择。

2.1 安装方式选型与实操

首选方案：Homebrew这是最推荐的方式，适合绝大多数用户，能自动处理依赖和更新。

# 1. 添加第三方仓库（Tap） brew tap scouzi1966/afm # 2. 安装稳定版 brew install afm # 或安装每日构建的nightly版（包含最新特性，可能不稳定） brew install scouzi1966/afm/afm-next

注意：首次执行brew tap可能会较慢，因为它需要克隆整个homebrew-afm仓库。安装后，可以通过afm --version验证。Homebrew会自动将可执行文件链接到/usr/local/bin（Intel Mac）或/opt/homebrew/bin（Apple Silicon Mac），请确保该路径已在你的PATH环境变量中。

备选方案：pip安装如果你主要使用Python环境，或者无法使用Homebrew（例如在某些受限制的企业环境中），pip安装是一个不错的选择。

pip install macafm # nightly版本 pip install --extra-index-url https://kruks.ai/afm/wheels/simple/ macafm-next

安装后，同样使用afm命令调用。需要注意的是，pip安装的版本可能会与系统其他Python包存在环境隔离问题，如果遇到“command not found”，可以尝试用python -m afm的方式运行，或者检查pip安装的二进制文件路径（通常是~/.local/bin）是否在PATH中。

高级方案：从源码构建如果你想贡献代码、调试问题，或者需要针对特定系统环境进行优化，就需要从源码构建。

git clone --recurse-submodules https://github.com/scouzi1966/maclocal-api.git cd maclocal-api

构建前，请务必确保你的环境满足：

Xcode 26+：这是硬性要求，因为需要其中的Swift 6.2+工具链和macOS 26 SDK。在终端运行xcode-select -p确认路径，并通过xcodebuild -version确认版本。
系统完整性：项目中的Scripts/build-from-scratch.sh脚本会处理所有依赖，包括克隆子模块、打补丁、编译WebUI等。根据网络情况和机器性能，首次构建可能需要10-30分钟。

# 完整构建（包含WebUI界面，需要Node.js环境） ./Scripts/build-from-scratch.sh # 跳过WebUI构建（如果你只需要API服务器） ./Scripts/build-from-scratch.sh --skip-webui # 开发调试模式 ./Scripts/build-from-scratch.sh --debug --skip-webui

构建成功后，可执行文件位于./.build/release/afm（或./.build/debug/afm）。你可以直接运行它，或将其复制到/usr/local/bin下。

2.2 版本管理与回滚技巧

项目维护了清晰的版本线：stable（稳定版）和nightly（每日构建版）。nightly版包含了最新的提交和特性，但稳定性无法保证。你可以像下面这样灵活切换：

# 从stable切换到nightly brew unlink afm brew install scouzi1966/afm/afm-next # 从nightly切换回stable（假设之前安装过stable版） brew unlink afm-next brew link afm

一个非常重要的实操细节：afm在2026年3月31日左右进行了一次重大更新，将底层的swift-huggingface依赖更新到了最新版。新版本将模型缓存目录从~/Documents/Huggingface移到了~/.cache/huggingface。这样做主要是为了避免~/Documents目录被iCloud同步，导致模型文件被意外上传和下载，浪费流量和空间。

这意味着：如果你在此日期之前使用过afm并下载了模型，升级后需要重新下载模型。旧的模型文件仍占据着~/Documents/Huggingface的空间，你可以手动删除它们来释放磁盘：

rm -rf ~/Documents/Huggingface

新的模型将会下载到~/.cache/huggingface中。你可以通过环境变量MACAFM_MLX_MODEL_CACHE来指定自定义的缓存路径，这对于管理多个磁盘或希望将模型放在SSD上的用户非常有用。

2.3 环境检查与故障排查

在第一次运行afm前，请完成以下检查，可以避免90%的启动失败问题：

macOS版本确认：必须为macOS 26 (Tahoe) 或更高版本。在“关于本机”中查看。这是运行Apple Foundation Model的强制要求。
Apple Intelligence开关：前往“系统设置” -> “Apple Intelligence与Siri”，确保“Apple Intelligence”已启用。这个开关不打开，系统级的Foundation Models框架将不可用。
硬件确认：必须是Apple Silicon芯片（M1, M2, M3, M4系列）。可以在终端用sysctl -n machdep.cpu.brand_string命令查看。
端口占用检查：afm默认使用9999端口。如果该端口被其他程序（如另一个afm实例、其他开发服务器）占用，会导致启动失败。
```
lsof -i :9999 # 如果输出有内容，说明端口被占用。可以杀掉对应进程，或让afm使用其他端口： afm -p 8080
```

如果启动时遇到类似“Foundation Models framework is not available”的错误，请严格按照上述1-3步检查，并重启终端应用甚至电脑。有时系统服务更新需要重启才能完全生效。

3. 核心功能深度解析与实战

安装妥当后，我们进入最激动人心的部分：实际使用。afm的功能可以概括为三大核心板块：Apple Foundation Model服务、MLX开源模型运行、以及API网关与OCR等工具。

3.1 基石：运行Apple Foundation Model

这是afm最基础也是集成度最高的功能。启动它，就等于在你的本地9999端口（或你指定的端口）开启了一个专属于苹果官方3B模型的OpenAI兼容API。

# 最基本启动，仅API服务器 afm # 启动API服务器并打开WebUI聊天界面（推荐初次使用） afm -w # 指定端口和主机，并开启详细日志 afm -p 8080 -H 0.0.0.0 -v

启动后，打开浏览器访问http://localhost:9999（如果用了-w参数会自动打开），你会看到一个简洁的聊天界面。在后台，一个Vapor框架驱动的Swift HTTP服务器已经开始运行。

这个本地API与OpenAI的兼容性非常高。你可以直接使用官方的openaiPython库，只需将base_url指向本地。

from openai import OpenAI client = OpenAI(base_url="http://localhost:9999/v1", api_key="not-needed") response = client.chat.completions.create( model="foundation", # 模型名称固定为"foundation" messages=[{"role": "user", "content": "写一首关于春天的五言诗"}], stream=True # 支持流式输出 ) for chunk in response: if chunk.choices[0].delta.content: print(chunk.choices[0].delta.content, end="")

关键参数解析：

-t, --temperature：控制生成文本的随机性（0.0-1.0）。越低输出越确定和保守，越高则越有创造性。对于代码生成或事实问答，建议0.1-0.3；对于创意写作，可以调到0.7-0.9。
-r, --randomness：更底层的采样控制。greedy是贪婪搜索，每次选概率最高的词，结果完全确定；random:top-p=0.9是核采样，从概率累积超过0.9的候选词中随机选，在创造性和连贯性间取得平衡；random:top-k=40是Top-K采样。
-a, --adapter：LoRA适配器支持。这是afm一个强大的进阶功能。你可以使用Apple官方提供的 Adapter Training Toolkit 对基础模型进行微调，生成一个.fmadapter文件。通过此参数加载后，模型就会具备你微调后的特定能力（比如用某种风格写作、精通某个垂直领域知识）。

3.2 灵魂：运行任意MLX开源模型

如果说Foundation Model是开胃菜，那么MLX模型支持就是afm的主菜。它让你能在Mac上运行几乎任何主流的大语言模型。

基础使用：

# 1. 运行一个指令模型并进行单次对话（模型会自动从Hugging Face下载） afm mlx -m mlx-community/Qwen2.5-0.5B-Instruct-4bit -s "用Python写一个快速排序函数" # 2. 启动一个MLX模型并开启WebUI（方便交互测试） afm mlx -m mlx-community/gemma-3-4b-it-8bit -w # 3. 以API服务器模式运行MLX模型，供其他程序调用 afm mlx -m mlx-community/Llama-3.2-1B-Instruct-4bit -p 8888

第一次指定某个模型时，afm会从Hugging Face下载它。缓存目录默认为~/.cache/huggingface。下载进度会在终端显示。你可以通过MACAFM_MLX_MODEL_CACHE环境变量改变缓存位置。

模型选择策略：mlx-community仓库里有成百上千个模型，如何选择？我的经验是：

追求速度与轻量：选择参数量小、量化位宽低的模型，如Qwen2.5-0.5B-Instruct-4bit、Llama-3.2-1B-Instruct-4bit。它们能在几秒内完成响应，适合简单的分类、总结、翻译任务。
平衡能力与资源：Gemma-3-4b-it-8bit、Qwen3-0.6B-4bit是不错的折中选择，在8GB内存的Mac上也能流畅运行，能力远超基础小模型。
追求最强能力：如果你的Mac拥有32GB或更大内存（尤其是M3 Max/M4 Max），可以挑战Qwen3.5-35B-A3B-4bit、DeepSeek-V3-32B-4bit这类大模型。它们需要更多的GPU内存，生成速度会慢一些，但理解和生成能力接近第一梯队商用模型。

交互式模型选择器：如果你不想记模型ID，afm提供了一个非常贴心的功能：

MACAFM_MLX_MODEL_CACHE=/your/model/path afm mlx -w

加上-w参数后，WebUI的模型选择下拉框里，不仅会列出所有已下载的模型，如果你设置了MACAFM_MLX_MODEL_CACHE环境变量，还会扫描该路径下的所有模型文件，让你可以轻松切换。这对于管理多个模型的用户来说极其方便。

3.3 进阶：API网关、OCR与工具调用

afm的野心不止于服务单个模型，它想成为你本地AI生态的统一入口。

API网关模式：这是我认为afm设计最精妙的地方之一。通过一个-g参数，它就能变身智能代理。

afm -w -g

启动后，afm会自动在本地网络进行服务发现，寻找正在运行的Ollama（默认端口11434）、LM Studio（默认端口1234）、Jan（默认端口1337）等服务的API端点。一旦发现，它会将这些后端模型“虚拟化”为afm自己的模型列表。

这意味着，你的客户端应用只需要连接http://localhost:9999/v1，发送请求时在model字段指定对应的后端模型名（如ollama/llama3.2），afm就会自动将请求转发到正确的后端，并将响应返回。你可以在一个WebUI里同时与苹果官方模型、本地MLX模型、Ollama模型对话，管理复杂度大大降低。

Vision OCR功能：这是一个独立但极其实用的功能。它封装了macOS系统级的Apple Vision OCR引擎，通过HTTP API暴露出来，识别精度高，且支持多语言。

# 命令行直接识别本地图片 afm vision ~/Desktop/invoice.png # 识别PDF文档（会自动分页） afm vision ~/Documents/contract.pdf --max-pages 5

更强大的是它的HTTP API端点/v1/vision/ocr。它支持多种输入方式：

本地文件路径：{"file": "/path/to/image.png"}
Base64编码数据：{"data": "base64string..."}
Data URL：{"url": "data:image/png;base64,..."}
OpenAI兼容格式：直接接收OpenAI多模态API格式的请求，自动提取其中的图片内容进行识别。

这对于构建自动化流水线非常有用。比如，你可以写一个脚本，监控某个文件夹，一旦有新的扫描件图片放入，就调用这个OCR API提取文字，然后送入afm的聊天接口进行摘要或信息提取。

工具调用（Function Calling）： afm的Foundation Model后端支持OpenAI格式的工具调用。你可以在请求中定义tools数组，描述可供模型调用的函数。当模型认为需要调用工具时，会在响应中返回一个tool_calls结构，你的程序可以据此执行相应函数，并将结果以tool角色的消息再次发送给模型，形成多轮交互。这使得构建具备复杂推理和行动能力的AI Agent成为可能。

4. 生态集成与高级应用场景

一个工具的价值，很大程度上取决于它能否融入你现有的工作流。afm在这方面做得相当出色。

4.1 与OpenCode深度集成：打造本地AI编程助手

OpenCode 是一个终端内的AI编程助手。将它与afm结合，你就能获得一个完全在本地运行、无数据泄露风险的“Copilot”。

配置步骤：

启动afm并加载一个代码模型。Qwen3-Coder-Next系列或DeepSeek-Coder的MLX版本是很好的选择，它们在代码生成和理解上表现优异。

afm mlx -m mlx-community/Qwen3-Coder-Next-4bit -t 0.1 --max-tokens 8192 # 温度调低（0.1）让代码生成更确定，增大max-tokens以处理长代码片段

配置OpenCode。在~/.config/opencode/opencode.json中，添加afm作为后端提供商。

{ "$schema": "https://opencode.ai/config.json", "provider": { "ollama": { "npm": "@ai-sdk/openai-compatible", "name": "macafm (local)", "options": { "baseURL": "http://localhost:9999/v1" }, "models": { "mlx-community/Qwen3-Coder-Next-4bit": { "name": "mlx-community/Qwen3-Coder-Next-4bit" } } } } }

在终端启动OpenCode，输入/connect命令，在提供商列表最底部找到macafm (local)并选择。当要求输入API密钥时，随意输入一个字符（如x）即可，因为afm目前尚未实现鉴权。

完成以上步骤后，你就可以在终端里，用自然语言让本地的AI帮你写代码、解释代码、重构代码，所有数据都在本地循环，安全感十足。

4.2 构建自动化AI工作流

结合afm的API和OCR能力，我们可以设计出强大的本地自动化脚本。

场景示例：自动处理会议纪要图片假设你经常收到会议白板的拍照图片，需要提取文字并生成结构化摘要。

import os import requests from pathlib import Path AFM_BASE_URL = "http://localhost:9999/v1" OCR_API = f"{AFM_BASE_URL}/vision/ocr" CHAT_API = f"{AFM_BASE_URL}/chat/completions" def process_meeting_minutes(image_path): # 1. OCR提取文字 with open(image_path, 'rb') as f: img_data = f.read() import base64 b64_data = base64.b64encode(img_data).decode('utf-8') ocr_payload = { "data": b64_data, "recognition_level": "accurate", "languages": ["zh-Hans", "en-US"] # 中英文混合识别 } ocr_response = requests.post(OCR_API, json=ocr_payload).json() extracted_text = ocr_response.get('combined_text', '') if not extracted_text: print("OCR failed or no text found.") return # 2. 调用本地模型进行摘要和结构化 chat_payload = { "model": "foundation", # 或你喜欢的MLX模型 "messages": [ { "role": "system", "content": "你是一个专业的会议秘书。请将OCR提取的杂乱文本，整理成结构清晰的会议纪要，包含：会议主题、时间、参会人、讨论要点、决议事项、待办任务。" }, { "role": "user", "content": extracted_text[:3000] # 避免文本过长 } ], "temperature": 0.2 } summary_response = requests.post(CHAT_API, json=chat_payload).json() structured_minutes = summary_response['choices'][0]['message']['content'] # 3. 保存结果 output_path = Path(image_path).with_suffix('.md') with open(output_path, 'w', encoding='utf-8') as f: f.write(f"# 会议纪要（源自：{image_path}）\n\n") f.write(structured_minutes) print(f"会议纪要已生成：{output_path}") # 监控文件夹，处理新图片 watch_folder = Path("~/Desktop/MeetingPhotos").expanduser() for img_file in watch_folder.glob("*.jpg"): process_meeting_minutes(str(img_file))

这个脚本展示了afm作为本地AI“微服务”的潜力。你可以将其扩展，结合cron定时任务或文件夹动作，实现完全自动化的内容处理流水线。

4.3 性能调优与监控

当你在Mac上运行大型MLX模型时，资源管理很重要。

内存与Swap监控：运行大模型（如35B参数）时，即使有4-bit量化，也可能占用超过20GB的内存。打开“活动监视器”，观察“内存压力”和“Swap使用情况”。如果Swap使用持续增长，说明物理内存不足，性能会下降。这时需要考虑换用更小的模型，或者关闭其他占用内存的大型应用。

afm启动参数优化：

--prewarm：默认为y。它会在服务器启动时预先加载模型到GPU内存。虽然会让启动慢几秒，但能显著加快第一个请求的响应速度。如果你不常使用，可以设为n来加快启动。
-t和-r：如前所述，合理设置温度和采样策略对生成速度和质量有直接影响。对于需要快速、准确回复的对话机器人，使用-t 0.1 -r greedy；对于创意生成，使用-t 0.8 -r random:top-p=0.9。

使用htop或sudo powermetrics观察CPU/GPU使用率，可以了解模型推理时芯片的负载情况。理想情况下，GPU（Apple Silicon的GPU核心）利用率应该很高，而CPU利用率相对较低，这说明计算很好地卸载到了GPU上。

5. 常见问题与排查实录

即便afm设计得再优雅，在实际使用中依然会遇到各种问题。这里我总结了一份从社区和自己踩坑中积累的“避坑指南”。

5.1 模型下载失败或速度极慢

这是新手最常遇到的问题，尤其是从国内网络访问Hugging Face时。

现象：执行afm mlx -m some-model后，卡在下载进度条，或报网络错误。
原因：swift-huggingface库默认使用Hugging Face官方镜像，国内访问可能不稳定。
解决方案：
1. 使用环境变量指定镜像（推荐）：在运行afm前，设置HF_ENDPOINT环境变量指向国内镜像站。
```
# 使用阿里云镜像（目前对MLX社区模型支持较好） export HF_ENDPOINT="https://hf-mirror.com" afm mlx -m mlx-community/Qwen2.5-1.5B-Instruct-4bit -s "hello"
```
  你可以将export HF_ENDPOINT="https://hf-mirror.com"这行添加到你的shell配置文件（如~/.zshrc）中，使其永久生效。
2. 手动下载：如果镜像站也没有你需要的模型，或者下载依然很慢，可以尝试用其他下载工具（如huggingface-cli或浏览器）先下载模型文件，然后放置到afm的缓存目录中。你需要知道模型文件的精确命名和目录结构，这比较繁琐，仅作备选。

5.2 启动WebUI后无法连接或空白页

现象：使用-w参数启动后，浏览器打开了，但页面显示“无法连接”或一片空白。
排查步骤：
1. 检查端口：首先确认afm服务器是否真的在运行。在终端查看是否有错误输出。另开一个终端，运行curl http://localhost:9999/health，应该返回{"status":"ok"}。
2. 检查WebUI资源：afm的WebUI是内嵌的静态资源。如果构建时--skip-webui或者构建失败，WebUI文件会缺失。尝试用afm不带-w参数启动，然后用浏览器直接访问http://localhost:9999，如果能看到简单的API信息页面，说明API服务器正常，是WebUI前端资源问题。此时需要重新执行完整的构建脚本./Scripts/build-from-scratch.sh（不跳过WebUI）。
3. 防火墙或安全软件：极少情况下，macOS的防火墙或第三方安全软件会阻止本地回环地址的特定端口。可以尝试换一个高端口（如-p 30000）测试。

5.3 “模型加载失败”或“非法指令”错误

现象：运行MLX模型时，提示加载失败，或直接崩溃报“Illegal instruction”。
原因：这通常是因为模型文件与当前afm版本或底层的MLX框架不兼容。MLX框架仍在快速迭代，社区转换的模型可能使用了较新或较旧的格式。
解决方案：
1. 清理模型缓存：删除有问题的模型缓存文件，让afm重新下载。缓存路径在~/.cache/huggingface或你自定义的MACAFM_MLX_MODEL_CACHE目录下。找到对应的模型文件夹删除即可。
2. 尝试不同量化版本的模型：同一个模型可能有4bit、8bit等不同量化版本。如果Qwen2.5-7B-Instruct-4bit失败，可以试试Qwen2.5-7B-Instruct-8bit。
3. 更新afm：确保你使用的是最新稳定版或nightly版。开发者会持续更新以兼容最新的MLX模型格式。
```
brew upgrade afm # 或 brew upgrade scouzi1966/afm/afm-next
```

5.4 API请求超时或无响应

现象：客户端（如Python脚本）向afm发送请求后，长时间等待无响应，最终超时。
排查：
1. 查看afm日志：启动afm时加上-v（verbose）参数，查看服务器端是否收到了请求，以及模型推理的进度。
2. 检查请求格式：确保你的请求体是合法的JSON，并且model字段的值正确。对于Foundation Model，必须是"foundation"；对于MLX模型，必须是完整的Hugging Face模型ID，如"mlx-community/Qwen2.5-1.5B-Instruct-4bit"；对于网关模式下的Ollama模型，可能是"ollama/llama3.2"。
3. 模型首次推理慢：模型第一次响应某个长度的提示时，需要时间进行“预热”和计算。后续相同长度的提示会快很多。这是正常现象，尤其是大模型。耐心等待第一次响应。
4. 系统资源不足：如果同时运行了多个大型模型或应用，系统内存不足，可能导致交换（swap）频繁，从而使响应极其缓慢。关闭不必要的应用，或换用更小的模型。

5.5 如何贡献代码或反馈问题

afm是一个活跃的开源项目。如果你发现了bug，或者有功能建议，最好的方式是到GitHub仓库提交Issue。

提交Issue前：请先搜索已有的Issue，看是否有人已经提出过类似问题。
提供详细信息：包括你的macOS版本、afm版本（afm --version）、复现问题的完整命令、以及详细的错误日志（用-v参数运行）。
关于Pull Request：项目欢迎贡献。如果你是Swift开发者，可以Fork仓库进行修改。项目README中提到，即使你不是Swift开发者，也可以通过“Vibe coding”的方式参与——这大概指的是利用AI编程助手（如Claude）来理解代码和提交修改。你可以Fork仓库后，用OpenCode连接afm，让它帮你理解代码逻辑并提出修改建议。

afm的出现，让我在Mac上进行AI开发和实验的体验提升了一个维度。它把复杂的模型部署、API封装、多后端聚合等问题，简化成了几条简单的命令。更重要的是，它坚持了本地化、隐私优先的原则，让开发者能在享受强大AI能力的同时，牢牢掌控自己的数据。从简单的文本对话到复杂的多模态工作流自动化，afm提供了一个坚实、高效且优雅的基础设施。如果你手头有一台Apple Silicon的Mac，我强烈建议你花上半小时，按照本文的指南把它跑起来，亲自感受一下“本地AI原生”的魅力。