打造 MacBook 本地大模型代理中心:New API 与 LiteLLM 部署记录

随着各大云厂商接连推出极具性价比的大模型 API,手里不知不觉囤了各种厂商(如阿里云、腾讯云、DeepSeek 等)的多个 API Key。为了在本地各种 AI 工具(Chatbox、VSCode、Cursor)中无缝切换和聚合管理这些模型,在本地搭建一个 LLM API 网关(Proxy)成为了刚需。

“New API (可视化管理, golang) + LiteLLM (高阶路由容灾, python)” 是目前最理想的两个本地大模型代理解决方案。本文记录了在 MacBook 上的部署踩坑指北。

架构概览

  • New API:基于 Docker 部署。负责对接国内各家云厂商的私有协议,转换为统一的 OpenAI / Anthropic 标准协议,并提供直观的 Web UI 进行额度和令牌管理。
  • LiteLLM:基于 Python 虚拟环境 + Supervisord 本地部署。套在 New API 壳外,提供极客级别的按需路由(Routing)和故障自动转移(Fallback)。

一、部署 New API:OrbStack 与网络环境破局

在 Mac 上跑 Docker,强烈推荐使用 OrbStack 替代臃肿的官方 Docker Desktop,它不仅启动极速,且内存占用极低。

但由于大陆地区的网络原因,在执行 docker-compose up -d 拉取 New API 镜像时,大概率会遇到 context deadline exceeded 的超时报错。

💡 破局重点:配置加速镜像
不需要复杂的代理规则折腾,最直接有效的方案是在 OrbStack 中配置有效的镜像源。
打开 OrbStack -> Settings -> 左侧选 Docker -> 找到 Daemon 选项卡,填入以下配置并 Apply & Restart

{
"registry-mirrors":[
"https://dockercf.jsdelivr.fyi",
"https://docker.jsdelivr.fyi",
"https://dockertest.jsdelivr.fyi"
]
}

配置完成后,镜像拉取速度还不错,但是可能不稳定,需要多重试几次。国内很多其他的镜像源(如阿里云、腾讯云等)目前都不可用了,只有上面这三个 jsDelivr 的镜像源还勉强能用,深感嘘唏……

附上精简版 docker-compose.yml

services:
new-api:
image: calciumion/new-api:latest
container_name: new-api
restart: always
ports:
- "127.0.0.1:3000:3000"
volumes:
- ./data:/data

ports 部分强烈建议只绑定到 127.0.0.1,以确保服务只在本地可访问,提高安全性。


二、部署 LiteLLM:虚拟环境与 Supervisord 进程守护

LiteLLM 基于 Python 开发。为了极致节省 Mac 系统资源,我没有选择让它也跑在 Docker 里,而是直接在宿主机使用 venv 创建独立虚拟环境,并使用 supervisord 进行后台进程守护与开机自启管理。

1. 创建虚拟环境并安装

# 创建并激活虚拟环境
python3 -m venv ~/.litellm-env
source ~/.litellm-env/bin/activate
# 安装 litellm
pip install 'litellm[proxy]'

2. 💡 配置重点:Supervisord 与虚拟环境的结合

使用 Supervisor 管理虚拟环境中的 Python 应用,最大的踩坑点是路径问题:千万不能依赖系统的环境变量,必须在配置中直指虚拟环境的绝对路径!

通过 Homebrew 安装 Supervisor (brew install supervisor) 后,在配置目录(M芯片通常为 /opt/homebrew/etc/supervisor.d/)下创建 litellm.ini

核心配置写法如下:

[program:litellm]
# 【关键】不要直接写 litellm,必须写 venv 环境下的绝对执行路径!
command=/Users/你的用户名/.litellm-env/bin/litellm --config /Users/你的用户名/LLM/litellm/config.yaml --port 4000

# 指定工作目录
directory=/Users/你的用户名/LLM/litellm
user=你的用户名

# 自动重启与日志
autostart=true
autorestart=true
stopasgroup=true
killasgroup=true
stdout_logfile=/Users/你的用户名/LLM/litellm/stdout.log
stderr_logfile=/Users/你的用户名/LLM/litellm/stderr.log

写好后执行:

supervisorctl update
supervisorctl restart litellm

总结

通过 OrbStack (Docker) + New API 搞定全网模型协议的标准化,再通过 venv + Supervisord + LiteLLM 搞定本地轻量化守护与高阶路由。整套架构完全跑在本地,逐步有了点本地的 token hub 的感觉,既满足了对多模型的无缝切换,又极大地节省了系统资源。

移除 macOS 中被企业策略强制安装的 Chrome 插件扩展的方法

公司配发的 Macbook 安装了一些监控软件,毕竟是办公设备,这点倒是无可厚非。但是,其中的 Forcepoint DLP Endpoint 会向日常使用的主力浏览器 Chrome 中安装一个 WebsenEndpoint 的扩展插件。

这个插件的作用不必多说,但是有一个副作用就是让 Chrome 无法自动填写任何网站用户名密码。每天要输入上百次的密码这种体力活是绝对不能忍受的。于是尝试卸载这个插件。但是这个插件是使用企业策略 (Installed by enterprise policy) 强制安装,无法在Chrome中下载。但是可以通过将与之关联的 Profile 删除实现卸载的作用:

但是过两天,Forcepoint 又会把这个插件装回来? 不过没关系,我们有的是办法。

方法一:通过占用 Chrome 插件文件位置,防止真正插件重新装回

原理是这样的:Chrome 的插件安装在 ~/Library/Application Support/Google/Chrome/Default/Extensions 目录下:

除去 Temp, 每个文件夹对应一个插件。我们希望移除的插件的文件夹名称是 kmofofmjgmakbbmngpgmehldlaaafnjn。由于 macOS 文件夹下,相同名称的文件和文件夹只能存在一个。因此,我们只需要在插件删除以后,在这个目录下新建一个名称为 kmofofmjgmakbbmngpgmehldlaaafnjn 的空文件:

然后,再通过文件系统的 Lock 功能锁定改文件,防止该文件被 Forcpoint 删除:

至此,大功告成,so easy!

方法二:修改 Forcepoint DLP Endpoint 插件安装脚本,禁止强奸 Chrome

法一虽然可以防止Chrome被重新安装插件,但是过几天以后,你会在你的 Profiles 配置下发现,虽然 Chrome 插件安装失败了,但是依然会成功安装这个 Profile:

虽然不会干扰系统的任何功能,但是估计很多强迫症患者看到这个还是挺难受的……从图中我们可以看到,这个插件的路径在 /Library/Application Support/Websense Endpoint/DLP:

其中 setup_chrome_ext.sh 就是强插 Chrome 的脚本:

脚本写得简单粗暴:通过 $PROFILES -I -F "/Library/Application Support/Websense Endpoint/DLP/WebsenseEndpointExtension.config" 向系统强行安装 profile. 要防止其安装插件,把这行代码删除即可。但是,这个文件是属于 admin 用户组的,我们平时使用的账号,即使集合 sudo 也只是 wheel 用户组,是干不过 admin 的,导致我们无法在正常模式下编辑该文件:

因此,我们需要通过 Command (⌘)-R 重启到恢复模式,然后在 /Volumes/mac.os/Library/Application Support/Websense Endpoint/DLP 目录下,将对应代码删除即可。

至此,自己基本满意了?

后记

稍微浏览了一下 /Library/Application Support/Websense Endpoint 文件夹,发现其实这个软件不仅强插 Chrome, 还会强插 FireFox:

艾玛……proxy…吓死宝宝了,已经不想改脚本了。直接在恢复模式下删除文件,然后用方法一的方法,建了一个 Lock 文件锁定这个位置。什么,还有 upgrade.sh? 你怎么不上天呢,也一并删除了……突然想起,自己在无所不能的恢复模式下,要不整个软件一起删除了?想到隔天IT技术小哥可能过来找麻烦,就此打住吧?

基于 Docker 搭建 Mac 本地 HBase 环境

说起玩大数据,相信很多人都会因为 Apache 全家桶软件配置而菊花一紧。Docker 的出现,把很多玩大数据就是配机器、配环境的开发者从泥潭中拯救了出来,虽然还不能完全替代线上环境,但是在开发环境,无疑为开发者节约了大量搭建本地环境的时间。比较遗憾的是,我们团队之前也是没有独立的数据测试环境?,于是把在本地搭建 HBase 环境整理和记录如下。

系统环境:

  • MacBook Pro (Retina, 15-inch, Mid 2015)
  • 2.2 GHz Intel Core i7
  • 16 GB 1600 MHz DDR3
  • macOS 10.13.6

安装 Docker CE for Mac

Docker Community Edition for Mac下载安装。

Mac 上的 Docker 环境经过 docker-machine/virtualbox 几次变化,如今的 Docker CE 已经支持原生 Mac 环境,因此当前阶段 Docker CE for Mac 就是唯一推荐的 Mac Docker 环境,再也不用通过安装 virtualbox 这种借蛋生鸡的方式了,实在是很赞。此外,现在的 Docker CE 集成了 Kubernetes, 因此本地玩 k8s 也不需要额外进行安装配置。如果你计划以后就是玩 k8s, 那么你以前安装的 Kitematic 也可以卸载掉了。Kitematic 除了一个图形化的 container 管理界面,实在没有什么值得留恋的,因此官方停止其开发无疑是个正确的决定。

获取和启动 HBase Docker 镜像

  • 获取容器镜像

更多大数据全家桶 Docker 镜像可以参见 HariSekhon/Dockerfiles

  • 启动容器

参数解释:

  • -d: 后台启动。
  • -h: 容器主机名,必须设置该项并配置 hosts,否则无法连通容器。
  • -p: 网络端口映射,这里只把要使用的端口(zookeeper端口、HBase Master端口、HBase RegionServer端口等)映射了出来,你可以根据自己需要进行端口映射。常用 HBase端口可以参见下表:

但是,harisekhon/hbase 修改了默认端口:

因此,你看到启动参数中的端口参数是那样的。

  • --name: 容器别名。

设置hosts (推荐使用 Gas Mask):

成功启动后,就可以在 http://localhost:16010/master-status 查看 HBase 状态了:

需要注意的一点是:容器销毁后,数据也也会被同时销毁。因此你可以通过 -v YOUR_DIR:/hbase-data 的方式将数据目录映射到宿主机目录,防止数据丢失。

编写测试代码

  • 创建 table

  • 读写 table

Maven 添加依赖:

HelloHBase.java:

扩展阅读