llama.cpp 分布式推理介绍(1) 远程计算设备 (RPC Device)

在本系列教程中，我们将一步步揭开 ggml-rpc 的神秘面紗。作为开篇，我们首先来认识整个系统的基石------远程计算设备 (RPC Device)。

1. 问题的提出：我的笔记本电脑算力不足

想象一下这个场景：你是一名机器学习爱好者，正在自己的笔记本电脑上调试一个大型语言模型。突然，你遇到了一个棘手的问题：模型的计算量太大了，你的笔记本电脑跑起来非常缓慢，甚至可能因为内存不足而崩溃。

然而，在你的实验室或云端，有一台配备了顶级 GPU 的高性能服务器正闲置着。如果能直接在你的笔记本上，像使用本地硬件一样，调用那台服务器的 GPU 来进行计算，那该多好啊！

这正是 ggml-rpc 要解决的核心问题。而它实现这一魔法的第一步，就是创建一个"远程计算设备 (RPC Device)"的抽象概念。

2. 核心概念：什么是远程计算设备？

远程计算设备 (RPC Device) 是对一台远程计算服务器的抽象表示。

这个概念听起来有点绕，但我们可以用一个简单的类比来理解它：

它就像在你的设备管理器里，突然出现了一个名为"云端 GPU"的新硬件选项。

虽然这个"云端 GPU"的实体远在天边，但通过"远程计算设备"这个本地的"快捷方式"或"代理"，你的应用程序可以像和本地硬件对话一样与它交互。你可以：

查询它的属性：比如，它有多少可用内存？它的设备名叫什么？
将它纳入统一管理：GGML 框架可以像管理本地 CPU 或 GPU 一样，对这个远程设备进行统一的资源调度和任务分配。

总而言之，这个抽象层将复杂的网络通信细节隐藏了起来，让使用远程资源变得和使用本地资源一样简单、无缝。

3. 如何使用：添加并查询一个远程设备

说了这么多，我们来看看到底如何通过代码来"安装"这个"云端 GPU"。ggml-rpc 提供了一个非常直接的函数来完成这个任务：ggml_backend_rpc_add_device。

假设我们的远程服务器地址是 192.168.1.100，并且 RPC 服务运行在 18080 端口上。

c 复制代码

#include "ggml-rpc.h"
#include <stdio.h>

int main() {
    // 定义远程服务器的地址和端口
    const char * endpoint = "192.168.1.100:18080";

    // 添加远程设备，获取一个设备"句柄" (handle)
    ggml_backend_dev_t rpc_device = ggml_backend_rpc_add_device(endpoint);

    if (rpc_device) {
        printf("成功添加远程设备！\n");
        // ... 接下来我们就可以查询它的信息了
    } else {
        printf("添加远程设备失败。\n");
    }
    return 0;
}

上面的代码非常简单。我们只用了一行 ggml_backend_rpc_add_device(endpoint) 就创建了一个指向远程服务器的设备实例。函数返回的 rpc_device 是一个 ggml_backend_dev_t 类型的句柄，它就是我们在本地的"代理"。

拿到这个句柄后，我们就可以用 GGML 标准的函数来查询它的属性了，完全感觉不到它是一个远程设备。

c 复制代码

// 接上文...
if (rpc_device) {
    printf("成功添加远程设备！\n");

    // 使用标准函数获取设备名称
    printf("设备名称: %s\n", ggml_backend_dev_get_name(rpc_device));

    // 使用标准函数获取设备内存信息
    size_t free_mem, total_mem;
    ggml_backend_dev_get_memory(rpc_device, &free_mem, &total_mem);
    printf("远程设备内存: %.2f / %.2f MB\n",
           (double)free_mem / 1024 / 1024,
           (double)total_mem / 1024 / 1024);
}
// ...

预期输出：

makefile 复制代码

成功添加远程设备！
设备名称: RPC[192.168.1.100:18080]
远程设备内存: 22874.50 / 24576.00 MB

看，我们就像查询本地硬件一样，轻松获取了远程服务器的名称和GPU内存信息！

4. 幕后探秘：内部是如何工作的？

你可能会好奇，当我们调用 ggml_backend_rpc_add_device 和 ggml_backend_dev_get_memory 时，底层究竟发生了什么？是立即建立了网络连接吗？

高层流程

实际上，ggml-rpc 在这里采用了一种"懒加载"或者说"延迟连接"的策略，非常高效。

添加设备 (ggml_backend_rpc_add_device) :
- 调用这个函数时，并不会立即发生任何网络通信。
- 它只是在你的应用程序内存中创建了一个 ggml_backend_device 结构体。
- 这个结构体里存储了远程服务器的地址 (endpoint)，并填充了一系列特殊的"RPC接口函数"（例如 rpc_get_name, rpc_get_memory 等）。这些函数知道如何通过网络与服务器对话。
查询信息 (ggml_backend_dev_get_memory) :
- 当你第一次调用需要与服务器交互的函数时（比如查询内存），真正的网络通信才会发生。
- 客户端会尝试与服务器建立连接。
- 连接成功后，它会发送一个"请告诉我你的内存信息"的请求。
- 服务器收到请求，查询本地硬件（比如 NVIDIA GPU）的内存，并将结果返回给客户端。
- 客户端收到响应后，再将结果呈现给你。

我们可以用一个时序图来更清晰地展示这个过程：

sequenceDiagram participant 应用程序 participant ggml-rpc客户端 participant ggml-rpc服务端应用程序->>ggml-rpc客户端: 调用 ggml_backend_rpc_add_device("ip:port") activate ggml-rpc客户端 Note right of ggml-rpc客户端: 仅在本地创建设备结构体，
不进行网络通信。 ggml-rpc客户端-->>应用程序: 返回设备句柄 (ggml_backend_dev_t) deactivate ggml-rpc客户端应用程序->>ggml-rpc客户端: 调用 ggml_backend_dev_get_memory(句柄) activate ggml-rpc客户端 ggml-rpc客户端->>ggml-rpc服务端: 建立网络连接 (首次通信) activate ggml-rpc服务端 ggml-rpc客户端->>ggml-rpc服务端: 发送 GET_DEVICE_MEMORY 请求 ggml-rpc服务端-->>ggml-rpc客户端: 响应：返回内存信息 deactivate ggml-rpc服务端 ggml-rpc客户端-->>应用程序: 返回获取到的内存信息 deactivate ggml-rpc客户端

深入代码

让我们看一小段源码来印证这个过程。

这是 ggml_backend_rpc_add_device 函数的核心实现 (位于 ggml-rpc.cpp):

cpp 复制代码

ggml_backend_dev_t ggml_backend_rpc_add_device(const char * endpoint) {
    // ... (一些用于防止重复添加的锁和检查)

    // 1. 创建一个上下文，存储 endpoint 信息
    ggml_backend_rpc_device_context * ctx = new ggml_backend_rpc_device_context {
        /* .endpoint = */ endpoint,
        /* .name     = */ "RPC[" + std::string(endpoint) + "]",
    };

    // 2. 创建设备结构体，并关联 RPC 的接口函数 (ggml_backend_rpc_device_i)
    ggml_backend_dev_t dev = new ggml_backend_device {
        /* .iface   = */ ggml_backend_rpc_device_i,
        /* .reg     = */ ggml_backend_rpc_reg(),
        /* .context = */ ctx,
    };

    // ... (将设备存入 map 中)

    return dev;
}

正如我们所分析的，这段代码只做了两件事：创建上下文（存地址）和创建设备结构体（关联接口），完全没有网络操作。

那么，网络操作发生在哪里呢？我们再看看 ggml_backend_rpc_device_get_memory 的实现：

cpp 复制代码

static void ggml_backend_rpc_device_get_memory(ggml_backend_dev_t dev, size_t * free, size_t * total) {
    ggml_backend_rpc_device_context * ctx = (ggml_backend_rpc_device_context *)dev->context;

    // 这个函数会真正触发网络通信
    ggml_backend_rpc_get_device_memory(ctx->endpoint.c_str(), free, total);
}

// ggml_backend_rpc_get_device_memory 内部会调用
static void get_device_memory(const std::shared_ptr<socket_t> & sock, size_t * free, size_t * total) {
    rpc_msg_get_device_memory_rsp response;
    // 发送 RPC_CMD_GET_DEVICE_MEMORY 命令并等待响应
    bool status = send_rpc_cmd(sock, RPC_CMD_GET_DEVICE_MEMORY, nullptr, 0, &response, sizeof(response));
    // ...
    *free = response.free_mem;
    *total = response.total_mem;
}

在这里，ggml_backend_rpc_get_device_memory 函数内部通过 send_rpc_cmd 向服务器发送了一个 RPC_CMD_GET_DEVICE_MEMORY 命令，这才是真正的数据交换。具体的通信细节，我们将在后续的 RPC 通信协议章节中深入探讨。

5. 总结与展望

在本章中，我们学习了 ggml-rpc 的核心入门概念------远程计算设备 (RPC Device)。

我们理解了它是一个对远程服务器的本地抽象或代理，目的是让远程计算资源的使用像本地硬件一样简单。
我们学会了使用 ggml_backend_rpc_add_device 函数来创建一个远程设备实例，并用标准函数查询其属性。
我们还探究了其内部的"延迟连接"机制，了解到设备句柄的创建和实际的网络通信是分开的。

这个"远程设备"只是 GGML 庞大而灵活的后端系统的一部分。GGML 如何发现和管理包括 CPU、本地 GPU 以及我们今天介绍的 RPC 设备在内的所有硬件呢？这就是我们下一章要探讨的主题。