打造 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 的感觉,既满足了对多模型的无缝切换,又极大地节省了系统资源。

值得关注的 Agent Skills

落笔之前,顺手翻了一下之前关于LLM领域的技术动向记录,发现一个有意思的事情:Anthropic 这家公司除了经常在用户使用协议和声名上经常搞很抽象的事,在工程和模型上面不得不说真的是个落地和推进都很强的团队,颇有点当年Google几篇论文教育行业的味道。

去年十月,Anthropic 发布了一个叫做 Agent Skills 的项目,目标是让大模型能够更好地适应和执行复杂任务。这个项目的核心思想是通过定义一套“技能”(Skills),让模型能够像人类一样,逐步学习和掌握各种任务的执行方法:Equipping agents for the real world with Agent Skills。我其实没有立即跟进,因为当时看到大家的讨论都觉得这个项目和颇有点从MCP又回到function calling的感觉,不仅没什么新意,反而有种背叛初心的意味。

几个月以后,重新审视了这个项目,发现它其实有一些值得我们深入探讨。Agent Skills提到的几个核心优势:

  • 可组合性:技能可以像积木一样组合,形成更复杂的行为。
  • 可重用性:技能可以在不同任务中复用,提高开发效率。
  • 专用性:为领域任务进行能力剪裁适配。

而这几个优势其实本质上都是基于LLM的function calling能力,但Anthropic通过“技能”这个概念,赋予了这些能力更高的抽象层次和组织结构,使得开发者能够更方便地管理和调用这些功能模块。而这种工程上的构建思路其实是非常值得借鉴的:

  • 当前的 Agent 其实都免不了在 workflow 与 task decomposition 上面下功夫,而agent本身也可以看所是一个复杂的function calling。
  • 这个世界本身就是一个无限嵌套循环的function calling过程,不断折叠的过程。
  • 这种无限循环嵌套的过程需要进行更高层次的抽象和组织,才能更好地管理和调用这些功能模块。
  • 而这个层次的抽象和组织,其实跟OpenAI定义的人工智能能力标准和方向不谋而合。

使用文件系统进行技能的构建很多人觉得“挺落后的”。而我认为这本身本身无可厚非。一方面技能本身是一个工程实践的产物,如果使用场景本身就是跟沙箱等环境相关联,那么使用文件系统进行技能的构建其实是非常合适的。另一方面,回归的本质,对于操作系统来说,万物皆文件,这本身也是更高层次抽象的成熟手段。

当前的技能更多的是介于子workflow与原子function calling之间的一个产物。因此,它当前面向的用户更多是开发者和Pro级用户,而非普通终端用户。因此,任何从普通终端用户视角对它的评判都可能会有失偏颇。但是它迈出了非常有意义的工程实践第一步:如果这种模式被证明是可以梯度降低使用门槛的,那么我们可以顺着这条路一直构建和梯度降低,最终让普通终端用户也能享受到这种能力。这个梯度过程,将会是工程实践与模型迭代不断双向奔赴的过程,而这是有可能点燃无限希望的过程。一年以后,我们回头再看。

大模型这四年

从大模型元年2022年开始,当前关注度和影响力依然势头不减的大模型已经走到了第四个年尾。回头翻了一下快三年前写的使用ChatGPT的一点感受和思考
,当时提到的几点感受和思考,放在今天看来又有了一些新的感受和收获。

关于一个更好的wikipedia,但是时效性较差,也没法输入新的知识这个观点,今天看来已经不太成立了。大模型的知识库和知识图谱的结合,已经让大模型可以具备更好的时效性和可扩展性。比如结合检索增强生成(RAG)技术,可以让大模型在回答问题时,实时检索最新的信息,从而提供更准确和及时的回答。而随着基模能力的增强,尤其是推理能力、MoE 的引入,RAG在很多场景也越来越变得不那么必要了。短短三年,大模型技术从单纯的知识问答,已经发展到了可以进行复杂推理和决策支持的阶段。

关于它能帮你代笔写东西,但不是创作这个观点依然有争议。从身边的内容创作者样本来看,很多人已经开始将大模型作为创作的辅助工具,帮助他们生成初稿、提供灵感和优化语言表达。大模型在创作过程中扮演了一个重要的角色,尤其是在需要大量文本生成的场景下,比如写作、编程、设计等。然而,大模型生成的内容仍然需要人类的审校和润色,以确保其质量和准确性。因此,大模型更多地被视为一种增强创作能力的工具,而不是完全替代人类创作者。但这两年也也分明越来越明确的听到内容创作者的两个心声:恐惧和拥抱。恐惧的是大模型可能会取代一部分内容创作者的工作,尤其是那些重复性较高、技术含量较低的工作。而拥抱则是看到大模型带来的效率提升和创作灵感,愿意积极利用大模型来提升自己的创作能力和竞争力。

特别有意思的是,在前两天——52%比48%:互联网上AI生成的内容数量首超人类. 关于这点其实三年前自己也有过非常准确的判断:

及格内容生成的成本极低,互联网高质量内容将会以快的速度被稀释。而最有可能形成垃圾内容成山的领域就是导购、营销、水军等一软文为生存手段的领域。

但是,真的没想到这么快就达到了这个临界点。而这个临界点几乎宣布了一些行业的终结,比如传统的SEO写手、低质量内容创作者,甚至是传统的不思进取的搜索引擎。未来的内容创作将更多地依赖“独一无二”。关于这一点,看看百度和小红书的搜索流量和势头就会有深切的体感。虽然百度在搜索中也引入了AI生成内容,但是用户对AI生成内容的信任度和满意度仍然存在较大差距。相比之下,小红书等平台更注重用户生成内容(UGC)的真实性和多样性,吸引了大量用户进行分享和交流。因此,未来的内容创作将更多地依赖于独特的视角、真实的体验和个性化的表达,而不是单纯依赖于AI生成的内容。

关于“嵌入派”与“降临派”。嵌入派的观点认为大模型AI即工具,应该被嵌入到各种应用和服务中,以提升用户体验和工作效率。而降临派则认为大模型AI将会带来颠覆性的变革,甚至可能改变人类社会的运作方式。从目前的发展趋势来看,嵌入派与降临派分别代表了两种典型的工程构建方式:自下而上与自上而下。而比较奇妙的点在于,这两个构建方式都在同时进行,并且在不同的尺度上不断融合发展。比如,Anthropic提出的 MCP 以及 Claude Skills,都是典型的基于大模型嵌入派思路的延生;而Claude Code又为开发者提供强大的vibe coding能力,推进降临派的发展。DeepSeek R1、 OCR 这样的技术,则更多地体现了降临派的思路,通过模型架构和设计的创新,推进大模型能力的跃迁。

如果你是当前大模型技术的从业者或者爱好者,建议你仔细回顾和研究一下 LangChain 的技术架构变更。如果一定要在现在给出一个明确的建议,那就是:在可控的系统架构上去嵌入大模型能力,然后不断地沉淀为系统的确定性模块或子系统,进而扩大嵌入的尺度,持续迭代,无限进步。从这个思路触发,这就跟一门编程语言最终要实现如何自举的设计哲学几乎完全一致。毕竟,别忘了,LLM 的中心正是 Language.