680GB统一内存：我们为什么要建一个"疯狂"的本地推理集群

680GB统一内存：我们为什么要建一个"疯狂"的本地推理集群 最近有朋友问我，你们SFD实验室为什么要搞那么多Mac Studio，直接用Claude API不香吗？ 我想了想，决定写这篇文章认真聊聊——不是炫耀硬件，而是聊聊我们在AI推理这件事上踩了哪些坑，最后为什么做出这个选择。 从API账单开始的反思 2024年底，我们的Claude API账单突破了单月$3000。那时候我有点麻木了，觉得这就是做AI产品的成本。直到有一天，一个批量处理任务——给BACAKU的500篇文章生成翻译和摘要——让我坐在那里等了4个小时，中途还碰到了rate limit，任务失败重来。 钱是一方面，更让我难受的是那种"不可控"的感觉。你永远不知道今天API响应是快是慢，你永远不知道下次rate limit在哪里，你永远不知道某天某个模型会不会突然改了behavior影响你的pipeline。 这才开始认真想：我们到底需要什么样的推理能力？ 大模型推理的几个基本原理 先说点干货，不然就是纯记流水账了。 为什么本地推理难？ 大语言模型的核心瓶颈是 内存带宽 ，不是算力。一个参数量70B的模型，FP16精度下需要140GB内存，推理时每生成一个token，都要把所有参数"读"一遍。现代GPU的显存通常是24-80GB，根本装不下。 这就是为什么大家谈到"消费级跑大模型"时，M系列芯片的"统一内存"架构是个关键优势——它把CPU和GPU的内存合并，M3 Ultra的96GB全部可用于模型权重，带宽接近800GB/s。 量化：用精度换空间 实际使用中，我们不需要跑FP16。量化技术（Q4/Q8）可以把模型压缩到1/4到1/2大小，精度损失极小。DeepSeek R1 671B的Q4版本大约需要400GB内存——这正好是两台M3 Ultra 96GB Mac Studio + 我们的M4 Ultra MacBook加起来能覆盖的范围。 llama.cpp的RPC分布式推理 这是我们整个方案的技术核心。llama.cpp在2024年加入了 --rpc 功能，允许把模型的不同层分布到多台机器上推理，通过高速网络（我们用雷电5内网）传输中间激活值。理论上，只要网络够快，N台机器的显存可以合并使用。 我们的集群怎么搭的 目前在线的配置： MacBook Pro M4 Ultra 24GB（主控，跑OpenClaw） Mac Studio M3 Ultra 96GB × 2（推理节点，走雷电5互联） 等后续M5 Ultra × 2 + Mac Mini到位后，统一内存总量将达到680GB。 雷电5的实测带宽在40-50GB/s左右，而我们用的Q4量化模型，每个token的激活值传输量很小，延迟基本可以忽略。实测Qwen2.5:32B在这个集群上的推理速度大概是30-40 tokens/秒，比单机快了将近3倍。 真实使用感受 说实话，部署过程比我预想的麻烦很多。 llama.cpp的RPC模式文档极少，很多参数需要自己摸索。MS01和MS02之间的雷电连接有时会断开，需要写watchdog脚本自动重连。Ollama的API兼容层有些模型加载行为不一致，我们在BACAKU的pipeline里踩了好几次坑。 但是，当这一切跑通之后——批量处理500篇文章，不限速，不限频，成本只有电费——那种感觉是真的爽。 更重要的是，Qwen2.5:32B在中文理解和生成上出乎意料地好。处理BACAKU的日语/中文混合内容时，比GPT-3.5-turbo的效果还要稳定。 什么时候应该考虑本地推理？ 不是所有人都需要这么搞。根据我们的经验： 适合本地推理的场景 ： 批量处理任务（每月>10万次调用） 对延迟敏感的实时应用 数据隐私要求高的业务 需要长时间微调实验的团队 还是用API更合适的场景 ： 日调用量低于1000次 团队没有运维能力 需要前沿模型能力（Claude 3.7/GPT-4o等） 我们现在的策略是混合使用：复杂推理和内容生产用Claude API，批量处理和内部工具走本地集群。 一个容易被忽视的细节 用本地模型做生产级应用，最大的挑战不是跑起来，而是 稳定性和监控 。 我们写了一个简单的健康检查脚本，每5分钟curl一次Ollama API，模型响应慢于10秒就自动发Telegram告警。这个脚本帮我们提前发现了好几次内存泄漏和网络抖动。 做AI应用的朋友，不管是用API还是本地模型，监控这件事千万别省。 如果你也在做类似的事情，欢迎交流。我们这个集群的配置和踩坑记录后续会陆续写出来。