技术深度解析
Ollama的GPU失明并非疏忽——而是其单主机架构的直接后果。这款主要用Go编写、底层采用C++推理后端（llama.cpp）的工具，通过平台特定的API查询本地可用GPU：NVIDIA用CUDA，AMD用ROCm，Apple Silicon用Metal。这种枚举在启动时进行，且硬编码为本地PCIe总线。没有任何机制——没有网络套接字、没有服务发现协议、没有远程过程调用——来检测或与其他机器上的GPU通信。
核心问题在于Ollama的资源抽象层。当用户运行`ollama run llama3`时，工具的调度器会将模型分配给找到的任何本地GPU。如果没有GPU，则回退到CPU推理。调度器对网络拓扑一无所知。这与vLLM或TensorFlow Serving等分布式推理框架有着本质区别，后者可以将模型作为网络服务暴露，并允许远程客户端向配备GPU的服务器发送请求。
要理解问题的规模，不妨考虑一个典型的家庭实验室设置：用户有一台搭载RTX 4090（24GB显存）的台式机和一台搭载RTX 3060（12GB显存）的笔记本。像Llama 3 70B这样的模型，在4-bit量化下需要大约140GB显存。单台机器都无法运行，但合起来有36GB——仍然不够。然而，对于Mixtral 8x7B（4-bit量化下约45GB）这样的模型，36GB的合计显存就很接近了，再加上激进量化或模型分片，或许可行。Ollama无法原生做到这一点。用户必须手动拆分模型、搭建网络桥接、在每台机器上运行独立的Ollama实例，然后使用负载均衡器——这个过程耗时数小时且极易出错。
| 方法 | 原生GPU发现 | 延迟开销 | 设置复杂度 | 可扩展性 |
|---|---|---|---|---|
| Ollama（当前） | 仅限本地 | 无（本地） | 低 | 无 |
| Ollama + 手动分片 | 无 | 中（网络） | 高 | 低 |
| vLLM（分布式） | 是（通过Ray） | 低（已优化） | 中 | 高 |
| llama.cpp RPC | 是（通过--rpc） | 中 | 中 | 中 |
| LocalAI（使用gRPC） | 部分 | 中 | 中 | 中 |
数据要点： Ollama的简洁性是以零可扩展性为代价的。所有支持远程GPU发现的替代方案都会引入一定的延迟和复杂性，但解锁了多节点推理——随着模型规模增长到超出单GPU容量，这一权衡变得不可避免。
一个值得注意的开源项目`llama.cpp`的RPC后端正在弥补这一差距，它允许客户端将层卸载到运行轻量级RPC工作进程的远程服务器上。GitHub仓库`ggerganov/llama.cpp`（超过70,000颗星）包含一个`--rpc`标志，让用户可以指定远程GPU端点。然而，这需要手动配置IP地址和端口——没有自动发现。另一个项目`exo`（GitHub: `exo-explore/exo`，约15,000颗星）旨在将网络中的消费级GPU汇集起来用于推理，但它仍处于实验阶段，缺乏Ollama的精致度。
根本性的工程挑战在于构建一个既轻量又安全的资源发现协议。基于广播的简单发现（如mDNS）可以在本地网络上工作，但在跨子网或VPN时则失效。集中式注册表则引入了单点故障。Ollama需要实现类似Kubernetes节点发现的功能，但要小得多，且对消费者友好。
关键玩家与案例研究
分布式推理领域较为分散，多个参与者对远程GPU问题采取了不同方法。
Ollama（GitHub: `ollama/ollama`，约120,000颗星）仍然是最用户友好的本地LLM工具，但其单节点限制正成为其致命弱点。项目维护者已在GitHub问题中承认了该问题，但尚未出现具体的分布式支持路线图。社区的挫败感显而易见：问题跟踪器中充斥着数十个功能请求和变通指南。
vLLM，由UC Berkeley开发，采取了相反的方法。它从底层设计就面向分布式推理，使用Ray来协调跨节点的GPU工作进程。vLLM可以在数十个GPU上以近乎线性的扩展性服务Llama 3 405B等模型。然而，其设置要复杂得多——需要Python、Ray集群和仔细的网络配置。它无法像Ollama那样即插即用。
LocalAI（GitHub: `mudler/LocalAI`，约30,000颗星）提供与OpenAI格式兼容的REST API，并支持多个后端，包括llama.cpp和Transformers。它通过gRPC对远程工作进程提供了实验性支持，但该功能文档不全且不稳定。
llama.cpp本身，作为Ollama的骨干，拥有最直接的解决方案：RPC后端。用户可以在配备GPU的远程机器上运行`rpc-server`，然后让本地的llama.cpp客户端连接到它。