虽然Claude3.5持续高热度，但是端侧AI或者说本地模型始终是众多程序员的梦想，而且并不满足于就是跑一个7B、8B的模型，毕竟同样的模型，参数规模越大，效果越好，人总是贪心的。
很简单的道理，之前也多次介绍过，模型越大，需要的内存越大（考虑到CPU非常差的推理性能，这里的内存其实只是GPU或者NPU内存，大体上一种是独立显卡的显存，例如英伟达4090的24GB，H100的80GB，另一种是一体化内存，例如苹果Silicon笔记本的最高128GB，Mac Studio的最高192GB）。
所以，除去服务器或者大型工作站使用H100之类的专用卡之外，市售模型推理最好的设备其实一直是苹果的笔记本或者台式机（mac mini，mac studio，iMac或者Mac Pro就先忽略吧）。一台128GB的M3 Max笔记本甚至可以推INT8版本的LlaMa3-70B，对于一台192GB内存的Mac Studio，110B的模型不在话下。虽然Intel或者AMD的下一代AI芯片支持的最大内存可以达到96GB，高通的X Elite最高也可以支持64GB，但是市售普遍的产品32GB就已经是高配了，考虑到Windows启动后就占据了至少10GB内存，所以能够留给模型的内存也就差不多16GB，跑一个13B的模型大概也就是能接受的上限了。
模型的性能问题，根本上是内存容量和内存带宽的问题，即使传说中微软为OpenAI准备了几十万张H100，但是单卡的内存容量也就是80GB，一个GPT模型需要装载到几十张卡上。
这些也逐渐成为普遍知道的信息。
但是，互联技术不是只能用在这种超大计算集群上，任何机器都可以通过互联成为一个集群的，但是有两个重要点：一是连接速度，二是推理的程序框架对集群的支持。
前者，大型训练集群几乎都标配了800G(bps)光模块，英伟达还搞出了胖树架构的IB网络。但是如果到我们一般的工作或者家庭使用环境，1G(bps)就算是不错的了（还得是网线连接），10G(bps)即万兆网络都算是很高的配置了。不过这个影响的就是推理速度，端侧部署，推理速度实在不是很重要。
而第二点，就是直接影响到能不能推理的问题了：有没有一套程序可以在多台机器间互相通信，把模型拆成若干份，分配到不同的机器里推理。看起来就是，假设有三台机器，每台的内存（显存或者一体化内存）都是16GB，都只能跑一个7B或者8B的INT-4量化版本模型，但是如果按照上面说的程序存在，把3*16GB看作一个48GB内存，那么是不是就可以跑一个22B甚至27B的模型？
上面两点，在ChatGPT问世之后，一直在我的脑子里存留着。第一个问题其实比较容易解决，至少在我当初为了跑大dataset时准备的m1的mac mini上有比万兆网口更快的thunderbolt4（雷电4）口，带宽是40G(bps)，讲道理，是可以跟这轮AI军备竞赛之前绝大多数数据中心内互联带宽比一比的。
最大的问题是第二个，即支持分布式的推理程序。好消息是，llama.cpp最近推出了支持分布式部署的rpc方案，同时，mistral发布的22B的codestral，gemma-2的27B都是“尺寸”合适的实验目标，所以，今天下午我“动手”了。
首先是三台20年的基于M1的Mac mini（当初购入成本6000rmb多一点，纯粹是为了跑一些分布式的数据计算方案，例如dask，ray等），没想到放到今天，还能有这样的用途。
这个版本的Mac mini，每台背后都有两个雷电4接口，雷电口和传统的网口有个很大区别是无法使用路由器或者交换机，有人使用过雷电hub，但是性能非常差，所以，计算机只能通过一对一的方式以雷电口连接。
要多台机器连接就是两种方式，一种是设定一个“主”机，每台“子”机都跟“主”机一对一连接，那么一个集群可以容纳的机器数量就等于“主”机的雷电口+1，我的Mac mini有两个雷电口，所以按照这种方式可以组成三台机器的集群。
另一种方式，就是通过所谓菊链的方式，即A接到B，B接到C，这种方式理论上可以接很多机器，但是要求每台机器至少有两个雷电口（Windows笔记本普遍不具备，哈哈），同时，中间任何一台宕机，整个网络就GG。
实际过程中，我采用的是第一种方式，但是为了展示菊链的方式，我画了一个四台机器的示意图。
组网完成后，我们仅通过ping，就能看到速度的明显对比，这是在局域网里的。
这是通过雷电口组成的网络的。
第二步，就是编译rpc版本的llama.cpp。
在项目的github站点的examples/rpc下有较为详细的部署教程。（https://github.com/ggerganov/llama.cpp/tree/master/examples/rpc）
rpc是支持不同的后端的，也就是完全可以在同一个集群中混用英伟达的gpu和苹果的mac，甚至，因为llama.cpp也可以支持安卓部署（调整下编译配置，应该也可以跑在ios上），也存在可以使用手机组网的可能性（只能是无线网络或者type-c口的hub了）。
下面是编译代码：
git clone https://github.com/ggerganov/llama.cppcd llama.cppmkdir build-rpccd build-rpccmake .. -DGGML_METAL=ON -DGGML_RPC=ONcmake --build . --config Release
llama.cpp在每台机器上都要编译一次，GGML_RPC就是支持rpc的编译标志。
编译成功后，在每台机器上都运行build-rpc/bin/rpc-server，启动rpc服务。
上面清晰的展示了GPU信息，是否使用metal开发框架，以及可分配的内存（我这里设定了12GB，留4GB给系统）。
然后就是在其中一台机器上，跑推理，首先要把模型权重文件下载到对应目录。
我分别试了gemma-2的9B和27B（内存不够失败）模型，和mistral的codestral-22B模型。
运行的示例代码如下：
$ bin/llama-cli -m ../models/tinyllama-1b/ggml-model-f16.gguf -p "Hello, my name is" --repeat-penalty 1.0 -n 64 --rpc 192.168.88.10:50052,192.168.88.11:50052 -ngl 99
下面是我测试的结果，首先是gemma-2 9B模型的INT-4量化版本。
模型权重文件大小6.4G，被分配到了三台机器上，其中一台使用了超过3G内存。
每台机器有加载了800多MB的KV缓存和300MB的计算缓存（最大的一台机器使用了超过5GB内存）。27B的模型是9B模型的3倍，每台机器的内存占用也可以简单乘以3，所以我尝试了很多次，27B模型都无法加载成功，因为内存使用最大的机器需要接近15GB内存，溢出了。
然后是模型推理性能。平均下来，每秒钟约6.5个tokens。9B的INT-4量化版本是可以跑在单机上的，实测下来每秒约7.5-8个tokens。这种不到20%的性能损失其实已经属于非常好的表现了，毕竟同样一个推理过程，单机跑的瓶颈都是内存带宽，而集群则还要加上网络延迟。后面有机会，我会测试一下高并发下的性能，这时候集群的优势应该可以得到进一步体现。
跑mistral的codestral-22B，差异则比较明显了。
首先，模型权重文件12GB，每台机器平均占用超过4GB，两个缓存再占用2.3+3.2=5.5GB，总和差不多10GB，刚好可以跑。
实际推理过程中，虽然可以返回token，但是也一直在报内存不够的错误。至于推理速度，1.6tokens每秒。我相信这个速度可以被优化提升，但是，难能可贵的是，在16GB内存的单机上，我们是无法跑22B模型的。即使windows的AIPC高配的32GB，考虑到单机大概需要18GB，windows占用10GB，即使可以运行也是非常吃力了。
所以，集群是巨大的突破。更何况，如果使用的机器不是16GB一体化内存的M1 Mac mini，而是M2 Ultra的Mac Studio（192GB内存），那么四台不超过五台机器就可以跑一个量化版本的LLaMA3-400B（如果meta继续开源的话）了。
同时，也需要注意的是测试的Mac Mini是M1芯片，内存带宽只有66GB/s，而M2 Ultra的Mac Studio内存带宽是800GB/s，推理速度绝对是完全两个量级的。
另外，苹果自己的MLX框架也推出了distributed的分布式部署方案，还有叫做exolabs的初创团队也披露了基于苹果设备的分布式推理方案（可以同时使用mac，ipad，iphone，甚至watch），他们的开发者正在跟我联系安排早早期的测试工作。我当然对于基于苹果生态构造集群的方案更感兴趣。
