如果你日常用 Mac 做 LLM 开发本地跑 Ollama、llama.cpp 或 LM Studio同时还要接几家云端 API大概率会遇到同一个问题这个月到底花了多少 token、烧了多少请求、费用有没有爆表完全没有一个直观的入口。每次都要打开控制台、翻账单、或者手动翻日志太麻烦。这个项目的思路很直接做一个 Mac 扩展用 panel面板、pill胶囊条或 nub凸块这类轻量 UI 形态常驻在桌面或菜单栏实时显示当前 LLM 的使用量。核心价值不是帮你生成内容而是帮你“看清”本地模型和云端服务的消耗情况。从材料看它面向的是高频调用 LLM 的开发者、AI 应用调试者和关注 API 成本管理的团队。这篇文章会把这套方案拆开讲清楚它适合什么场景、需要准备哪些环境、怎么部署启动、怎么对接本地和云端数据源、怎么判断显示的数据对不对以及最容易踩的几个坑。整个流程按“先判断值不值得用再照步骤跑通最后看资源占用和排查问题”的顺序来。1. 核心能力速览能力项说明项目类型macOS 桌面扩展用于展示 LLM 使用量UI 形态Panel面板/ Pill胶囊条/ Nub凸块轻量常驻主要功能实时展示 token 用量、请求计数、费用估算、本地模型状态数据来源本地 LLM 服务Ollama、LM Studio、llama.cpp 等和云端 APIOpenAI 兼容接口支持平台macOS具体版本需按实际项目说明确认启动方式命令行 / LaunchAgent 常驻 / 编译后运行硬件门槛普通 Mac 即可无特殊 GPU 需求若统计本地推理需本机可运行对应模型是否支持 API支持读取外部数据源自身是否暴露 API 需按项目实际实现确认是否支持批量任务主要面向持续监控与展示批量统计依赖后端数据聚合适合场景本地模型调试、API 成本监控、多模型对比测试这里要强调一个关键点这类“使用量显示”工具的本质是数据采集和可视化它的准确度取决于数据源。如果数据源本身不提供精确的 token 计数界面上显示的只能是一个估算值。后面我们会专门讲怎么验证数据的可靠性。2. 适用场景与使用边界先明确它能解决什么问题。本地开发调试跑 Ollama 或 LM Studio 做 RAG、Agent 测试时实时看每个请求的 token 消耗判断上下文是否超限。云端 API 成本管理同时接多个大模型服务时把每次调用的 usage 字段汇总到桌面避免月底对账才发现超支。模型对比选型用同一个测试集调用不同模型观察 token 消耗的差异辅助成本评估。团队共享展示开发机或测试机上常驻显示方便小团队快速了解当前资源消耗状态。不适合什么场景也要说清楚。不适合做精确计费依据大多数本地模型返回的 token 数是估算值API 提供方账单才具备最终效力。不适合处理敏感数据如果统计的是内部业务数据要确保扩展本身不会把数据上传到第三方。合规原则是数据留在本机只做本地统计和展示。不适合替代日志系统它更适合轻量可视化深入排查还是要靠服务端日志。使用边界方面补三点合规提醒第一如果工具需要读取终端输出、日志文件或 API 密钥要确认本地权限设置是合理的不要为了省事把密钥明文写在配置文件里再到处分享第二涉及企业内部数据时先确认工具的数据流路径是否满足公司安全要求第三不要利用这种统计工具绕过任何平台的速率限制或滥用检测调用量异常时服务方有权利限制访问。3. 环境准备与前置条件因为材料没有给出精确的 macOS 版本和依赖清单这里给出一套通用检查清单。你在部署前逐项确认即可。3.1 系统与基础工具macOS 系统版本建议保持较新的正式版如果有系统级权限需求还要确认是否允许辅助功能或屏幕录制权限。命令行工具安装 Xcode Command Line Tools很多源码编译和 Git 操作都依赖它。xcode-select --installHomebrew用来安装依赖、服务管理以及处理常见运行时。/bin/bash -c $(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)3.2 开发或运行环境这个项目如果走源码编译通常需要以下环境之一具体按项目 README 为准技术栈常见工具用途SwiftUIXcode 或 Swift 工具链原生 Mac 扩展资源占用低Electron / TauriNode.js 或 Rust 工具链跨端 UI开发快PythonPython 3 pip数据采集脚本 简单 UI如果你只是使用编译好的安装包那么只需要确保 macOS 能打开未签名或自签名应用。如果遇到“已损坏”或“无法验证开发者”的提示需要到“系统设置 - 隐私与安全性”中手动允许。3.3 LLM 数据源准备不管扩展 UI 怎么做最终数据都要从一个来源拿。常见数据源有两种。本地推理服务Ollama默认监听127.0.0.1:11434LM Studio本地服务或 OpenAI 兼容端点llama.cpp server自建 HTTP 服务云端 APIOpenAI 兼容接口例如/v1/chat/completionsAnthropic、Google 等各自的 API通常需要 API Key如果你的本地 Ollama 没启动扩展自然会显示“无数据”或“服务不可达”。这不是扩展的 bug而是数据源状态问题。3.4 端口与权限检查Ollama 默认端口是 11434如果这个端口被占后续排查会涉及。先用命令确认一下。lsof -i :11434如果没有任何输出说明端口没有服务在监听。如果输出了其他进程说明端口被占用可能需要停掉冲突进程或修改服务端口。4. 安装部署与启动方式不同的项目分发方式不一样这里给三种常见路径。4.1 方案一直接使用编译好的安装包如果你下载的是.app或安装包按以下步骤操作将应用拖入“应用程序”文件夹。首次打开时如果系统提示未验证到“系统设置 - 隐私与安全性”允许打开。启动应用确认菜单栏或桌面出现对应的 UI 组件。4.2 方案二通过 Homebrew 安装如果项目发布了 Homebrew Cask可以这样安装。实际包名需要替换成项目发布的名称。brew install --cask your-llm-usage-extension4.3 方案三源码编译运行如果项目提供源码流程通常是“克隆代码、安装依赖、构建运行”。git clone https://github.com/your-project/your-llm-usage-extension.git cd your-llm-usage-extension npm install # 如果使用 Node/Electron npm run dev # 或根据 README 执行 build如果是 Swift 项目直接用 Xcode 打开.xcodeproj选择签名方式后 CmdR 运行。如果是 Python 项目创建虚拟环境再安装依赖。python3 -m venv venv source venv/bin/activate pip install -r requirements.txt python main.py4.4 常驻启动显示使用量这种工具常驻是刚需。最稳妥的方式是用 macOS LaunchAgent 做成开机自启。下面是一个通用模板实际路径和可执行文件需要替换。?xml version1.0 encodingUTF-8? !DOCTYPE plist PUBLIC -//Apple//DTD PLIST 1.0//EN http://www.apple.com/DTDs/PropertyList-1.0.dtd plist version1.0 dict keyLabel/key stringcom.example.llmusage/string keyProgramArguments/key array string/usr/local/bin/llm-usage/string string--config/string string/Users/yourname/.config/llm-usage/config.yaml/string /array keyRunAtLoad/key true/ keyKeepAlive/key true/ keyStandardOutPath/key string/tmp/llm-usage.log/string keyStandardErrorPath/key string/tmp/llm-usage.err.log/string /dict /plist将文件保存为~/Library/LaunchAgents/com.example.llmusage.plist然后加载launchctl load ~/Library/LaunchAgents/com.example.llmusage.plist注意如果你只是临时测试不需要一上来就配置开机自启先手动跑通功能更重要。5. 功能测试与效果验证部署完成不代表就真的能用了。建议按以下步骤逐项验证。5.1 验证基础显示启动扩展后先看 UI 是否正常出现。判断成功的标准面板、胶囊或凸块出现在预期位置文字清晰可读没有乱码或持续转圈。如果 UI 没有出现检查后台进程是否在运行。日志文件是否有报错。是否有依赖服务未启动。5.2 验证本地 LLM 数据接入以 Ollama 为例。先确认我们能手动拿到一个包含 token 计数的响应。curl http://127.0.0.1:11434/api/generate \ -d { model: qwen2.5:7b, prompt: 用一句话介绍你自己, stream: false }正常的响应会包含类似以下字段{ model: qwen2.5:7b, prompt_eval_count: 13, eval_count: 32, total_duration: 1750000000 }其中prompt_eval_count是输入 token 数eval_count是输出 token 数。如果扩展接的是 Ollama它拿到的应该就是这类数据。在扩展界面上点击刷新或等待自动刷新周期确认数字是否变化。判断成功的标准界面上显示的 token 数与 curl 返回值一致或至少能对应上。5.3 验证云端 API 数据接入先确认你的 API 响应里有usage字段。以 OpenAI 兼容接口为例import requests API_URL https://api.example.com/v1/chat/completions API_KEY your-api-key payload { model: your-model-name, messages: [{role: user, content: hello}], } response requests.post( API_URL, headers{ Authorization: fBearer {API_KEY}, Content-Type: application/json }, jsonpayload, timeout30 ) print(response.json())响应里通常会有{ model: your-model-name, usage: { prompt_tokens: 8, completion_tokens: 12, total_tokens: 20 } }扩展如果能正确解析这个usage字段界面上应该显示对应的 token 数。如果显示为 0 或没有任何变化多半是字段解析不匹配或网络请求失败。5.4 验证自动刷新让工具保持运行再通过 curl 或代码发起一次新的 API 调用观察 UI 是否在预期时间内更新。判断标准新请求的 token 增量在刷新周期后能反映到界面上。如果长时间不刷新先看日志重点确认是“轮询失败”还是“轮询到了但解析为空”。5.5 验证历史累计很多使用量工具不止显示单次请求还会显示累计数据。这通常需要在本地保存一份历史记录。判断标准重启扩展后历史累计数据没有丢失。如果有丢失说明本地状态没有持久化需要检查数据存储目录是否存在并有读写权限。6. 接口与数据源对接这个项目能不能真正用起来核心在于数据源对接是否顺畅。下面给出一套通用设计思路。6.1 数据源配置配置文件通常采用 YAML 或 JSON。一个典型的配置模板如下sources: ollama: type: local url: http://127.0.0.1:11434 interval: 30 openai_compatible: type: api url: https://api.example.com/v1 api_key_env: LLM_USAGE_API_KEY model: your-model-name interval: 60 ui: style: pill position: menu_bar注意api_key_env这种写法是推荐做法也就是从环境变量读取密钥而不是直接把密钥写进配置文件。如果想写入配置也要保证配置文件权限只有当前用户可读。chmod 600 ~/.config/llm-usage/config.yaml6.2 本地 Ollama 统计Ollama 的/api/generate和/api/chat都会返回 token 计数。扩展可以定期拉取 Ollama 的进程状态或者在每次请求结束后读取响应日志。如果你的扩展本身不能主动拦截请求另一个思路是通过ollama ps命令查看当前加载的模型然后配合日志文件做统计。这个方案虽然没有直接 API 那么精确但能覆盖大多数场景。ollama ps6.3 日志文件监控有些 CLI 工具如 llama.cpp 的 server 模式会在 stdout 输出 token 统计信息。扩展可以通过 tail 日志文件来收集数据。import subprocess import time def tail_log(file_path): proc subprocess.Popen( [tail, -F, file_path], stdoutsubprocess.PIPE, stderrsubprocess.PIPE, textTrue ) for line in proc.stdout: print(line.strip()) # 在这里解析 token 统计字段 if __name__ __main__: tail_log(/tmp/llama-server.log)这种方案更轻量但解析逻辑要跟具体日志格式绑定改版本容易失效。6.4 批量统计与导出如果目标是做每日汇总可以配置一个定时任务把查询到的使用量追加到本地 CSV 文件。下面是一个简单示例import csv import os from datetime import datetime def append_usage(csv_path, source, model, prompt_tokens, completion_tokens): file_exists os.path.isfile(csv_path) with open(csv_path, a, newline, encodingutf-8) as f: writer csv.writer(f) if not file_exists: writer.writerow([time, source, model, prompt_tokens, completion_tokens, total_tokens]) writer.writerow([ datetime.now().isoformat(), source, model, prompt_tokens, completion_tokens, prompt_tokens completion_tokens ])需要明确一点扩展本身如果支持批量导出通常就是写入本地文件如果它没有这个功能也可以通过外部定时任务读取它的状态文件来实现。6.5 费用估算费用估算是一个很实用的功能但要注意不要在没有明确配置的情况下乱猜单价。合理做法是允许用户在配置里填写各模型的单价costs: qwen2.5:7b: input_per_1k: 0.0 output_per_1k: 0.0 your-cloud-model: input_per_1k: 0.0005 output_per_1k: 0.0015然后再根据 token 数计算费用。这样即使扩展界面上没有内置价格也能通过外部脚本完成成本统计。7. 资源占用与性能观察这类常驻工具的占用不能太高否则就失去意义了。部署后需要重点观察以下几个维度。7.1 CPU 占用观察方法打开“活动监视器”按 CPU 排序找到扩展进程。如果 CPU 占用持续超过 10%说明可能存在频繁轮询或渲染资源消耗过大的问题。降低 CPU 占用的常见手段提高轮询间隔例如从 1 秒改成 30 秒或 60 秒。UI 切换到静态内容模式减少动画刷新。在窗口不可见时暂停刷新。7.2 内存占用不同技术栈差别很大。原生 SwiftUI 通常比较省内存Electron 应用则因为内置 Chromium基础内存消耗明显偏高。如果你是在低配 Mac 上使用建议优先选择原生实现。内存持续上涨而不是稳定在一定水位属于异常现象需要进一步排查是否有内存泄漏。7.3 网络请求影响如果扩展在频繁调用云端 API 的/v1/models或/v1/chat/completions要注意两件事API 有速率限制频繁调用可能导致 429 或封禁。每次拉取都会产生网络流量和费用。稳妥的做法是提供一个“手动刷新”按钮自动刷新间隔放宽。如果项目支持还可以只拉取本地状态云端数据通过 webhook 推送或日志解析获取。7.4 与本地推理服务的互相影响如果你在 Mac 上跑 Ollama 或 llama.cpp又开着扩展做统计两者之间是独立的。扩展只是访问 API 或读取日志一般不会挤占推理显存和计算资源。但如果扩展监控间隔太短频繁查询 API 也可能和推理进程抢 CPU。7.5 如何判断工具是否稳定连续运行几个小时然后检查是否出现崩溃或闪退。是否大量积累日志。UI 是否还能正常刷新。系统休眠唤醒后扩展是否自动恢复。如果休眠唤醒后 UI 假死大概率是网络连接或定时器没有恢复正常。优先重启应用的刷新循环或查看日志确认底层请求是否有异常。8. 常见问题与排查方法下面这些问题覆盖了本地部署、数据源连接、权限、API 调用等最常见场景。问题现象可能原因排查方式解决方案扩展启动后 UI 不显示首次启动未获得权限或进程崩溃打开活动监视器确认进程是否存在查看系统日志在系统设置中允许辅助功能 / 屏幕录制权限或重新启动应用显示“服务不可达”本地 Ollama 未启动执行curl http://127.0.0.1:11434/api/tags启动 Ollama或检查服务地址配置端口 11434 被占用有多个 Ollama 实例或其他程序占用了端口执行lsof -i :11434查看占用进程停掉冲突进程或修改服务监听端口API 请求超时网络问题或云端服务繁忙检查网络连通性查看扩展日志中的超时时间延长请求超时时间或切换到备用网络界面上 token 数为 0响应字段解析不匹配手动调用一次 API对比返回字段调整配置中的字段映射API Key 无效或鉴权失败环境变量未正确设置或 Key 已过期检查扩展日志中的 HTTP 状态码重新设置环境变量确认 Key 有效免费额度超限提示云端账户的免费额度已用完登录云端控制台查看用量绑定付费方式或更换计费模式请求被内容安全策略拦截请求提示词命中了服务方的内容审核规则检查 API 返回的 error 信息调整测试提示词确保内容合规菜单栏图标消失macOS 菜单栏空间不足或应用崩溃检查菜单栏是否有多余间隙重启应用或在系统设置中调整菜单栏显示扩展后台运行但数据长时间不刷新自动刷新定时器停止或日志轮询失败查看进程日志确认定时任务是否执行手动点一次刷新按钮若正常则检查定时器逻辑开机自启失败LaunchAgent plist 路径或参数错误执行launchctl list查看任务状态检查 plist 中 ProgramArguments 的路径和参数显存或内存占用异常高UI 实现技术栈偏重或存在资源泄漏在活动监视器中观察内存趋势切换更轻量的 UI 模式或缩小刷新范围重点说一个很多 Mac 用户会踩的坑安装扩展后系统提示“无法打开因为无法验证开发者”。这种情况不一定是应用有问题而是 macOS 对未签名应用的安全限制。处理方式右键点击应用图标选择“打开”然后在弹窗里点击确认或者到“系统设置 - 隐私与安全性”中看到拦截信息后手动允许。另一个常见坑是 API Key 以明文写在配置文件里然后有人把配置分享到技术社区。正确的做法是用环境变量或 macOS Keychain 保存敏感信息。环境变量的加载示例export LLM_USAGE_API_KEYyour-api-key然后在这个会话中启动扩展。如果通过 LaunchAgent 自启环境变量可能不会自动加载需要调launchctl setenv或把密钥放到权限受限的配置文件中。9. 最佳实践与使用建议9.1 第一次使用先小规模验证不要一上来就配置十几个模型和 API。第一次部署先只用 Ollama 一个本地数据源确认 UI 显示、token 计数、刷新逻辑都没有问题后再逐步接入云端 API 和费用估算。9.2 配置文件和日志分目录管理推荐这样组织文件结构~/.config/llm-usage/ config.yaml api_key.env state.db logs/ app.log api.log输入素材、输出结果、日志分开方便排查和备份。9.3 API Key 保管原则优先使用环境变量或系统钥匙串。如果需要写入配置文件文件权限设置为仅当前用户可读写。不要把带真实 Key 的配置直接粘贴到社区。定期检查云端控制台的 API 使用记录确认没有异常调用。9.4 监控也要有边界使用量统计是手段不是目的。不要为了“实时的极致体验”把轮询间隔调成 1 秒这既浪费资源也可能触发云端 API 的频率限制。按使用场景设置 30 秒到 5 分钟的刷新间隔就足够。9.5 合规与授权提醒如果这个扩展要读取终端输出、日志文件或网络请求数据使用场景限定在本人设备、本人账号、已授权服务和开源合法数据范围内。涉及企业内部数据时确认数据不会发送到未授权的第三方。在商用或对外发布截图前也要检查界面中是否出现了敏感 Key、账号信息或内部模型名。10. 总结与下一步这个项目最值得尝试的点是把 LLM 使用量从“日志里翻”变成“桌面上看”。它不需要高端硬件、不依赖特定 GPU、也不要求懂大模型原理只要你日常在跟 LLM 打交道就有使用价值。最先应该验证的功能不是 UI 好不好看而是数据能不能对上。建议你部署后先用 curl 或 Python 跑一两次请求对比扩展界面的 token 数和服务端返回的usage字段。这一关过了后面所有统计、费用估算、批量导出才有意义。最容易踩的坑是权限和数据源连接。macOS 的权限拦截、Ollama 端口被占用、API Key 没加载成功这三个问题会吃掉你一多半排查时间。部署前先按文章里的检查清单过一遍能省掉很多麻烦。后续可以继续扩展的方向包括把统计结果导出成周报、接入更多本地推理后端、做费用预估和告警、和团队共享看板。等基础数据链路跑通了这些都可以基于同一套本地统计能力往上加。建议直接收藏备用。下次需要查看 LLM 使用量时照着这篇文章把环境、配置、验证流程跑一遍很快就能上线。