1. 为什么一台 Mac mini 能成为家庭 AI 中枢？——从“玩具”到“生产力引擎”的真实跃迁

你可能已经见过朋友圈里有人把 Mac mini 摆在电视柜旁，接上显示器，再连个机械键盘，配一句“我家的 AI 服务器上线了”。初看像极了极客玩具：不就是台小电脑装几个开源模型吗？但真正用过三个月以上的人，几乎都会删掉那条朋友圈，换一句更实在的：“这玩意儿，真成了家里最忙的设备。”

这不是夸张。我去年底用一台Mac mini M2（16GB 内存 + 512GB SSD）搭建了第一版家庭 AI API 服务，初衷只是想让家里的 iPad、iPhone 和 MacBook 能统一调用本地大模型，不用每次都在手机上开网页、输提示词、等加载。结果它很快演变成全家人的“AI 接口中心”：孩子写作文时用它润色并生成思维导图；太太用 Home Assistant 的自动化脚本调用它分析天气预报文本，自动生成晾衣提醒；我自己则把它接入 Obsidian，实现笔记内容的语义检索与摘要生成。它不再是个“能跑模型的盒子”，而是一个可编程、可编排、可审计、可降级的 AI 基础设施节点。

关键在于，它解决了三个被严重低估的家庭级 AI 痛点：

• 身份与密钥混乱：以前每个 App 都要单独配置 OpenAI API Key，Key 泄露风险高，轮换成本大，家庭成员共用时权限难管控；
• 模型调用路径割裂：Ollama 本地跑的模型、Open WebUI 的 Web 界面、FastAPI 写的轻量服务、甚至 Home Assistant 的http.post请求，各自走不同协议、不同端口、不同鉴权方式，调试像在拼乐高；
• 离线能力不可靠：一旦网络抖动或 OpenAI 限流，整个家庭 AI 流程就断链。而 Mac mini 本地部署的 Ollama 模型，只要机器通电，就能稳定响应——这才是“家庭级”服务该有的韧性。

所以，“统一家庭 AI API”不是技术炫技，而是对“AI 如何真正融入生活动线”的一次务实重构。它不追求吞吐量破万 QPS，但要求：
✅ 任意设备（iOS/Android/macOS/Windows/Linux）都能用标准 OpenAI API 格式调用；
✅ 所有请求必须经过统一网关鉴权、日志记录、速率限制与模型路由；
✅ 支持无缝切换后端：Ollama 本地模型、远程 OpenAI、甚至未来接入的 Llama.cpp 或 vLLM 实例；
✅ 整套栈能在 Mac mini 上静默运行，功耗低于 30W，风扇几乎不转，深夜也能持续服务。

这背后没有魔法，只有三件确定性极高的事：Mac mini 的硬件稳定性、macOS 对 ARM 架构的深度优化、以及 Ollama + Open WebUI + Nginx 这套组合在 Apple Silicon 上的成熟度。接下来，我会带你从零开始，把这台小盒子变成你家真正的 AI 中枢——不是教你怎么“装 Ollama”，而是告诉你：当所有组件都装好了，真正决定成败的，是那层薄薄的 API 网关设计。

2. 统一 API 网关的核心设计逻辑：为什么不能直接暴露 Ollama 的 /api/chat？

很多人搭建完 Ollama，第一反应是：“既然它自带/api/chat接口，那我直接让前端调用不就行了？”——这是最常见、也最危险的起点。我亲眼见过三位朋友因此踩坑：一位因未设限速，孩子用 iPad 不停刷请求，导致 Ollama 进程 OOM 崩溃；另一位把 Ollama 的OLLAMA_HOST=0.0.0.0:11434直接暴露在局域网，第二天发现模型被扫出并上传到某公开论坛；第三位更绝，用curl http://mini.local:11434/api/chat在 Home Assistant 里硬编码调用，结果某次 Ollama 升级后接口字段微调，全屋自动化集体失灵。

问题不在 Ollama 本身，而在它的定位：Ollama 是一个模型运行时（Runtime），不是生产级 API 服务（Service）。它的设计哲学是“极简即正义”，默认关闭鉴权、无速率控制、无请求审计、无错误标准化、无跨模型路由能力。把它当 API 网关用，就像拿一把瑞士军刀去当手术刀——功能都有，但精度、安全、可靠性全不达标。

真正的统一 API 网关，必须承担四重职责：

2.1 身份抽象层：把“人”和“设备”映射为可管理的 API Key

Ollama 本身不支持 API Key。但家庭场景中，你需要区分：

• 孩子的 iPad 只能调用gemma:2b（轻量、无联网、无代码生成）；
• 太太的 iPhone 可以调用qwen2:7b（支持中文长文本）；
• 你的 MacBook 则拥有llama3:70b的完整访问权（需二次确认）；
• Home Assistant 自动化脚本使用专用 Key，仅允许POST /v1/chat/completions，禁止GET /api/tags。

这需要一套轻量但完整的 Key 管理系统。我最终选择FastAPI + SQLite实现，而非引入 Redis 或 PostgreSQL——因为 Mac mini 是单机部署，SQLite 的 ACID 保证足够，且零依赖、零配置。Key 表结构极简：

提示：Key 生成不依赖密码学安全随机数（如secrets.token_urlsafe()），因为家庭环境无需对抗专业攻击者；但必须避免简单递增 ID 或时间戳，防止 Key 被枚举。我采用uuid.uuid4().hex[:32]，实测足够安全。

2.2 协议转换层：把 OpenAI 格式请求，精准翻译给 Ollama

OpenAI API 的/v1/chat/completions请求体长这样：

{ "model": "gpt-3.5-turbo", "messages": [{"role": "user", "content": "你好"}], "temperature": 0.7, "stream": false }

而 Ollama 的/api/chat接收的是：

{ "model": "gemma:2b", "messages": [{"role": "user", "content": "你好"}], "options": {"temperature": 0.7} }

表面看只是字段名差异，但深层陷阱更多：

• OpenAI 的stream是布尔值，Ollama 的stream是查询参数（?stream=true），且响应格式完全不同；
• OpenAI 的max_tokens对应 Ollama 的options.num_predict；
• OpenAI 的top_p对应 Ollama 的options.top_p；
• OpenAI 的stop数组需转为 Ollama 的options.stop字符串数组；
• OpenAI 的n（返回多条结果）在 Ollama 中不支持，必须由网关层做多次请求+合并。

我的 FastAPI 网关做了严格字段映射，并内置 fallback 逻辑：当用户请求model: "gpt-4"但本地无此模型时，自动降级为qwen2:7b并返回X-Model-Fallback: qwen2:7b响应头，方便前端感知。

2.3 模型路由层：让“模型名”成为可配置的策略，而非硬编码

家庭场景中，模型需求是动态的：

• 白天孩子上网课，优先用phi3:3.8b（快、省电、专注教育）；
• 晚上你写报告，切换到llama3:8b（平衡质量与速度）；
• 周末处理照片描述，才启用llava:13b（多模态，吃内存）。

如果每个请求都硬编码模型名，维护成本爆炸。我在网关中实现了两级路由：

1. 静态路由表：JSON 文件models.json，定义模型别名与实际 Ollama 名的映射：

   { "education": "phi3:3.8b", "writing": "llama3:8b", "vision": "llava:13b" }

2. 动态路由规则：基于请求 Header 或 Query 参数决策。例如：
   • 请求带X-Mode: education→ 强制路由到phi3:3.8b；
   • 请求来自192.168.1.100（孩子 iPad IP）→ 自动追加X-Mode: education；
   • POST /v1/chat/completions?model=writing→ 忽略 body 中的 model 字段，强制用llama3:8b。

这套机制让“换模型”变成改一行 JSON 或加一个 Header，彻底告别代码修改。

2.4 错误标准化层：让所有异常对前端友好、可追溯

Ollama 报错极其原始：HTTP 500 + 一段 Python traceback 文本；网络超时直接返回空响应；模型未加载时返回404 Not Found但无任何提示。而 OpenAI API 的错误是结构化的：

{ "error": { "message": "This model is currently loading.", "type": "model_not_found", "param": null, "code": 404 } }

网关必须做错误归一化。我定义了 7 类家庭常见错误，并映射到标准 OpenAI 错误码：

每条错误日志还自动附加request_id（UUID）、client_ip、model_requested、timestamp，存入 SQLite 日志表。当孩子说“AI 又坏了”，我只需查日志表WHERE client_ip = '192.168.1.100' ORDER BY timestamp DESC LIMIT 1，3 秒定位根因。

3. Mac mini 专属部署实战：绕过 Ollama 官方安装陷阱的 5 个关键动作

Ollama 官网的curl https://ollama.com/install.sh | sh在 Mac mini 上看似一键安装，实则埋了五个深坑。我花了 17 小时排查，最终形成一套“Mac mini 安全安装法”，确保 Ollama 在 Apple Silicon 上稳定运行、不啃内存、不乱占磁盘。

3.1 动作一：禁用 Rosetta，强制 ARM64 原生运行

Mac mini M1/M2/M3 默认开启 Rosetta 2（x86_64 模拟层），但 Ollama 的 ARM64 二进制早已成熟。Rosetta 会带来两大问题：

• 内存占用翻倍（Rosetta 缓存 + Ollama 自身）；
• GPU 加速失效（Apple Neural Engine 无法通过 Rosetta 调用）。

正确操作：

# 卸载 Rosetta 版 Ollama（如果已装） brew uninstall ollama # 下载官方 ARM64 DMG（非 .pkg！.pkg 会自动启用 Rosetta） curl -L https://github.com/ollama/ollama/releases/download/v0.3.10/ollama-darwin-arm64.zip -o ollama.zip unzip ollama.zip sudo mv ollama /usr/local/bin/ # 验证架构 file /usr/local/bin/ollama # 输出应含 "arm64"，不含 "x86_64"

注意：Ollama 0.3.10 是目前 Apple Silicon 兼容性最佳的版本。0.3.11+ 引入了新日志模块，在 Mac mini 上偶发段错误（Segmentation fault），我实测回退到 0.3.10 后 30 天零崩溃。

3.2 动作二：重定向模型存储路径，避开系统盘瓶颈

Ollama 默认把模型存在~/.ollama/models/，即用户主目录下。问题在于：

• Mac mini 的 512GB SSD 通常分给系统盘（APFS 容器），用户主目录也在其中；
• 一个llama3:70b模型解压后占 42GB，频繁读写会加速 SSD 磨损；
• 更致命的是，当 SSD 剩余空间 <10%，macOS 会强制启用压缩，Ollama 加载模型时卡死。

正确操作：

# 创建独立 APFS 卷（推荐，比软链接更稳） sudo diskutil apfs addVolume disk1 "APFS" OllamaModels -mountpoint /Volumes/OllamaModels # 设置 Ollama 环境变量（永久生效） echo 'export OLLAMA_MODELS="/Volumes/OllamaModels"' >> ~/.zshrc source ~/.zshrc # 验证 ollama list # 应显示空列表（因路径变更） ollama pull llama3:8b # 模型将下载到 /Volumes/OllamaModels

提示：不要用ln -s软链接！Ollama 0.3.x 对符号链接路径处理有 Bug，会导致ollama run时找不到模型。APFS 卷是 Apple 官方推荐的多卷方案，隔离性好、性能无损。

3.3 动作三：定制 Ollama 启动参数，抑制内存泄漏

Ollama 默认启动ollama serve会常驻一个 Go 进程，实测在 Mac mini 上运行 72 小时后 RSS 内存增长 1.2GB（从 380MB 到 1.6GB），最终触发 macOS 的 Jetsam 机制杀进程。

正确操作：
创建/opt/homebrew/etc/ollama.conf（Homebrew 安装路径）：

# Ollama 配置文件 # 启用内存监控，超限时自动重启 [server] keep_alive = "5m" # 5 分钟无请求则休眠 num_ctx = 4096 # 降低上下文长度，省内存 num_gpu = 1 # 强制使用 1 个 GPU 设备（ANE） # 模型加载优化 [models] lazy_load = true # 按需加载，非启动时全载

然后用 LaunchDaemon 替代手动ollama serve：

<!-- /Library/LaunchDaemons/ai.ollama.plist --> <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>Label</key> <string>ai.ollama</string> <key>ProgramArguments</key> <array> <string>/usr/local/bin/ollama</string> <string>serve</string> </array> <key>RunAtLoad</key> <true/> <key>KeepAlive</key> <dict> <key>SuccessfulExit</key> <false/> </dict> <key>StandardOutPath</key> <string>/var/log/ollama.log</string> <key>StandardErrorPath</key> <string>/var/log/ollama.log</string> </dict> </plist>

sudo launchctl load /Library/LaunchDaemons/ai.ollama.plist启用后，Ollama 进程内存稳定在 420±30MB，7×24 小时无波动。

3.4 动作四：为 Open WebUI 配置反向代理，解决 CORS 与 HTTPS 问题

Open WebUI 是优秀的 Web 前端，但它直接访问http://localhost:3000会遇到两个 Mac 生态特有问题：

• Safari/iOS 浏览器对localhost的 CORS 策略更严格，常报Blocked by CORS policy；
• iOS 设备无法通过http://mini.local:3000访问（因 HTTP 不被信任，尤其 iOS 17+）。

正确操作：用 Nginx 做反向代理，并启用自签名 HTTPS（Mac mini 作为内网 CA）：

# /opt/homebrew/etc/nginx/servers/ai.conf server { listen 443 ssl http2; server_name ai.local; ssl_certificate /etc/ssl/certs/ai.local.crt; ssl_certificate_key /etc/ssl/private/ai.local.key; location / { proxy_pass http://127.0.0.1:3000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; # 关键：透传 WebSocket proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; } # API 网关入口（复用同一域名） location /v1/ { proxy_pass http://127.0.0.1:8000/v1/; } }

生成证书命令（Mac 自带security命令）：

# 创建根 CA security create-certificate-authority "Home AI CA" --valid-years 10 # 为 ai.local 签发证书 openssl req -x509 -newkey rsa:4096 -keyout /etc/ssl/private/ai.local.key -out /etc/ssl/certs/ai.local.crt -days 3650 -nodes -subj "/CN=ai.local" # 将根 CA 导入系统钥匙串（macOS） sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain /etc/ssl/certs/Home\ AI\ CA.crt

完成后，在 iPhone 设置 → 已下载描述文件 → 安装，即可信任ai.local。从此全家设备输入https://ai.local即可安全访问 WebUI 和 API。

3.5 动作五：预热模型缓存，规避首次推理延迟

Ollama 首次ollama run llama3:8b时，需将 GGUF 模型文件 mmap 到内存，耗时 8~12 秒（Mac mini M2）。用户感知就是“点发送后卡住很久”。这不是模型慢，是内存映射冷启动。

正确操作：写一个预热脚本warmup_models.sh：

#!/bin/zsh # 预热常用模型，加载到内存但不运行推理 for model in "phi3:3.8b" "qwen2:7b" "llama3:8b"; do echo "Preloading $model..." # 发送空请求触发加载 curl -s "http://localhost:11434/api/chat" \ -H "Content-Type: application/json" \ -d "{\"model\":\"$model\",\"messages\":[{\"role\":\"user\",\"content\":\".\"}],\"options\":{\"num_predict\":1}}" \ >/dev/null 2>&1 done echo "Warmup done."

加入 LaunchDaemon，开机 2 分钟后自动执行：

<!-- /Library/LaunchDaemons/ai.warmup.plist --> <key>StartInterval</key> <integer>120</integer> <!-- 2分钟后执行 -->

实测效果：首次调用延迟从 10.2 秒降至 0.8 秒，用户完全无感知。

4. 家庭级 API 网关的健壮性设计：如何让服务在断电、升级、模型崩坏时仍“活着”

Mac mini 的优势是静音低功耗，劣势是——它终究是一台消费级电脑，不是工业服务器。它会断电（雷击）、会升级系统（macOS 更新强制重启）、会模型崩溃（ollama serve段错误）、会磁盘满（日志撑爆）。一个“能用”的网关和一个“可靠”的网关，差距就在这些边缘场景的处理上。

4.1 断电恢复：让服务在重启后 30 秒内自动就绪

Mac mini 断电后，Ollama、Nginx、FastAPI 全部停止。若依赖手动brew services start，全家 AI 就瘫痪。必须做到：开机即服务，无需人工干预。

我的方案是三层自愈：

1. LaunchDaemon 保活：前文已配置ai.ollama.plist和ai.nginx.plist，确保 Ollama 和 Nginx 开机自启；
2. FastAPI 进程守护：不用uvicorn直接跑，改用supervisord（Homebrew 安装）：

   ; /opt/homebrew/etc/supervisord.d/ai-api.ini [program:ai-api] command=/opt/homebrew/bin/uvicorn main:app --host 127.0.0.1 --port 8000 --workers 2 directory=/opt/ai-api user=yourusername autostart=true autorestart=true startretries=3 redirect_stderr=true stdout_logfile=/var/log/ai-api.log

3. 启动依赖编排：Nginx 必须等 Ollama 启动后再加载配置（否则 upstream 连接拒绝）。在ai.nginx.plist中添加：

   <key>LaunchOnlyOnce</key> <true/> <key>StartInterval</key> <integer>30</integer> <!-- 等 Ollama 先跑 30 秒 -->

实测：Mac mini 从断电到https://ai.local可访问，平均耗时 28.4 秒（含 SSD 初始化、Ollama 加载、Nginx 启动、FastAPI 绑定端口）。

4.2 系统升级防护：绕过 macOS 更新对服务的“温柔谋杀”

macOS 更新后，LaunchDaemon 权限会被重置，/Library/LaunchDaemons/下的 plist 文件常被禁用。更糟的是，更新后/usr/local/bin可能被重置，Ollama 二进制丢失。

正确防护：

• 将所有服务文件（plist、conf、script）备份到 iCloud Drive 同步目录；
• 创建post-update-hook.sh，监听/var/log/install.log中的Software Update关键字，触发自动恢复：

  # 监控更新日志（后台常驻） tail -f /var/log/install.log | while read line; do if echo "$line" | grep -q "Software Update"; then echo "$(date): macOS update detected, restoring services..." cp ~/iCloud\ Drive/ai-config/* /Library/LaunchDaemons/ sudo launchctl load /Library/LaunchDaemons/ai.* brew install ollama # 重装二进制 sudo launchctl kickstart -k system/ai.ollama fi done

• 将此脚本设为 LaunchAgent，随用户登录启动。

注意：不要用launchctl enable，macOS 13+ 对 LaunchDaemon 的 enable/disable 支持不稳定。kickstart是唯一可靠的强制启动命令。

4.3 模型崩溃兜底：当ollama serve段错误时，自动降级到备用模型池

Ollama 的SIGSEGV（段错误）无法完全避免，尤其在加载llava:13b等大模型时。此时若网关直接返回 500，用户体验极差。

我的兜底策略是“双模型池”：

• 主池：ollama list返回的所有模型，正常路由；
• 备用池：预装一个永不崩溃的极小模型tinyllama:1.1b（仅 380MB），专为兜底设计。

FastAPI 网关中实现：

# main.py from fastapi import HTTPException import subprocess def call_ollama(model: str, payload: dict): try: # 正常调用 return requests.post(f"http://localhost:11434/api/chat", json=payload) except Exception as e: # 主模型失败，切到备用池 logger.warning(f"Model {model} failed: {e}, falling back to tinyllama") payload["model"] = "tinyllama:1.1b" return requests.post(f"http://localhost:11434/api/chat", json=payload) @app.post("/v1/chat/completions") async def chat_completions(request: Request): # ... 解析请求 ... response = call_ollama(model, payload) if response.status_code != 200: raise HTTPException(status_code=response.status_code, detail="Fallback model also failed") return response.json()

tinyllama:1.1b在 Mac mini M2 上推理速度达 120 tokens/sec，虽质量不如llama3:8b，但足以应付“今天天气如何”“设置闹钟”等基础指令，保证服务不中断。

4.4 磁盘满预警：当模型分区剩余 <5GB 时，自动清理旧日志与缓存

/Volumes/OllamaModels分区满时，Ollama 会静默失败，无任何提示。必须主动监控。

正确方案：

• 每小时执行disk_usage_check.sh：

  #!/bin/zsh USAGE=$(df -P /Volumes/OllamaModels | awk 'NR==2 {print $5}' | sed 's/%//') if [ $USAGE -gt 95 ]; then echo "$(date): OllamaModels usage ${USAGE}%, cleaning..." # 清理 Ollama 缓存（安全） ollama rm $(ollama list | awk 'NR>1 {print $1}') 2>/dev/null || true # 清理网关日志（保留最近 7 天） find /var/log/ai-api.log* -mtime +7 -delete fi

• 通过launchctl设置每小时定时任务。

提示：ollama rm不会删除模型文件（只删 registry），但会释放 Ollama 内部缓存。真正删除模型用ollama rm <model>，需谨慎。

4.5 用户体验熔断：当 API 延迟 >3s 时，前端自动降级为“思考中…”动画

技术上再稳，用户感知延迟仍是痛点。我给前端（Open WebUI）加了一层熔断：

• 所有请求带X-Request-Timeout: 3000Header；
• 网关收到后，启动asyncio.wait_for(..., timeout=3)；
• 超时则立即返回：

  { "choices": [{ "delta": {"content": "正在思考中…"}, "finish_reason": "length" }] }

• 前端收到此响应，不报错，只显示流畅的“打字机”动画，同时后台继续请求，结果到达后自动追加。

这招极大缓解了用户焦虑——他们看到的是“AI 在认真思考”，而不是“转圈圈+报错弹窗”。

5. 从“能用”到“好用”：家庭 AI API 的 7 个真实增效技巧

部署完成只是起点。真正让家人愿意天天用、离不开，靠的是那些藏在文档角落、却极大提升体验的细节。这些不是“必须”，但每一个都让我家的 AI 使用频率提升了 3 倍以上。

5.1 技巧一：为每个家庭成员生成专属 API Key，并绑定设备指纹

与其给所有人同一个 Key，不如每人一个。但 Key 管理麻烦？我的解法是：Key = 设备指纹 + 用户名哈希。

在网关初始化时，运行：

# 为孩子 iPad 生成 Key echo "child-ipad-$(ioreg -rd1 -c IOPlatformExpertDevice | grep UUID | sed 's/.*"\(.*\)".*/\1/' | sha256sum | cut -c1-32)" | tr '[:lower:]' '[:upper:]' # 输出：CHILD-Ipad-8A3F9C2E1D...（32位）

ioreg获取的 UUID 是设备唯一标识（Mac/iPad/iPhone 均支持），哈希后转大写，既保证唯一性，又便于记忆。孩子 iPad 的 Key 就是CHILD-Ipad-8A3F9C2E...，太太 iPhone 的是MOM-iPhone-5B2D7F1A...。Key 名即身份，无需额外维护映射表。

5.2 技巧二：用 Shortcuts 自动注入 API Key，消灭手动复制粘贴

iOS Shortcuts 是家庭 AI 最佳入口。但每次调用都要粘贴 Key？太反人性。我的方案：

• 在 Shortcuts 中创建“AI 问答”自动化；
• 第一步：Get Contents of URL→https://ai.local/v1/chat/completions；
• 第二步：Set Variable→API_KEY=CHILD-Ipad-8A3F9C2E...（硬编码在 Shortcut 内）；
• 第三步：Make HTTP Request，Header 中Authorization: Bearer $API_KEY。

Key 存在 Shortcut 里，比存在 Notes 里更安全（Shortcuts 数据受 iCloud Keychain 加密），且调用时全自动注入。

5.3 技巧三：在 Home Assistant 中封装为input_text+input_select，让老人也能用

我妈不会用 Terminal，但会按遥控器。我把网关封装成 HA 的input_text（输入框）和input_select（模型选择）：

# configuration.yaml input_text: ai_prompt: name: "AI 提示词" initial: "" input_select: ai_model: name: "选择模型" options: - "phi3:3.8b（孩子）" - "qwen2:7b（日常）" - "llama3:8b（写作）" initial: "qwen2:7b" automation: - alias: "发送 AI 请求" trigger: platform: event event_type: automation_triggered event_data: entity_id: input_text.ai_prompt action: service: rest_command.ai_chat data: prompt: "{{ states('input_text.ai_prompt') }}" model: "{{ states('input_select.ai_model') | replace('（孩子）','') | replace('（日常）','') | replace('（写作）','') }}"

她只需在电视界面输入文字，点“发送”，结果自动播报——这才是家庭 AI 的终极形态。

5.4 技巧四：用ollama serve --host 0.0.0.0:11434时，必须加防火墙白名单

很多人为了从 iPad 访问，执行ollama serve --host 0.0.0.0:11434，却忘了 macOS 防火墙默认阻止外部连接。结果 iPad 一直连不上，反复重试。

正确操作：

# 允许 11434 端口入站（仅限局域网） sudo /usr/libexec/ApplicationFirewall/socketfilterfw --add /usr/local/bin/ollama sudo /usr/libexec/ApplicationFirewall/socketfilterfw --unblockapp /usr/local/bin/ollama # 但更安全的做法：只允许特定 IP sudo /usr/libexec/ApplicationFirewall/socketfilterfw --add /usr/local/bin/ollama --allow-incoming --ip 192.168.1.0/24

5.5 技巧五：ollama run时加-v参数，实时查看 token 生成速度

调试模型性能时，ollama run llama3:8b黑屏无反馈。加-v：

ollama run llama3:8b -v # 输出： # >>> Loading model... # >>> Generating... # >>> [1/128] token: "Hello" (0.82 t/s) # >>> [2/128] token: " world" (1.15 t/s)

t/s