4. gRPC 与 Protocol Buffers：核心概念与流式通信模式

在低延迟模型服务场景中，RESTful API 的 JSON 序列化开销和 HTTP/1.1 的队头阻塞逐渐成为瓶颈。gRPC 基于 HTTP/2 和 Protocol Buffers（protobuf），提供强类型、高压缩比、双向流式通信能力，是部署高性能推理服务的首选 RPC 框架。本章深入解析 gRPC 的核心概念、Proto 文件定义方法，并对比四种通信模式。

4.1 gRPC 核心概念

gRPC 采用客户端-服务器模型，通过 protobuf 定义服务接口和消息结构，利用 HTTP/2 的多路复用、流控和头部压缩特性实现低延迟通信。其核心组件包括：

• Service Definition：在 .proto 文件中声明 RPC 方法及其请求/响应消息类型。
• Protocol Buffers：语言中立、平台无关的序列化协议，编码后体积比 JSON 小 3-10 倍，解析速度更快。
• HTTP/2 Transport：支持多路复用、服务器推送和二进制分帧，消除 HTTP/1.1 的队头阻塞。
• Stub / Skeleton：客户端存根和服务端骨架由 protoc 编译器自动生成，屏蔽网络细节。
• Channel：客户端到服务器的持久连接抽象，管理连接池和负载均衡。

4.2 Proto 文件定义与消息结构

Proto 文件是 gRPC 的契约中心，定义服务接口和消息格式。以下是一个面向模型推理服务的完整示例：

syntax = "proto3";

package inference.v1;

// 模型推理服务定义
service ModelInference {
  // 单次推理（Unary）
  rpc Predict(PredictRequest) returns (PredictResponse);

  // 服务端流式推理（Server Streaming）
  rpc StreamPredict(PredictRequest) returns (stream TokenChunk);

  // 客户端流式推理（Client Streaming）
  rpc BatchPredict(stream FeatureVector) returns (BatchResult);

  // 双向流式推理（Bidirectional Streaming）
  rpc ChatStream(stream UserMessage) returns (stream AssistantMessage);
}

// 请求消息
message PredictRequest {
  string model_id = 1;
  repeated float input_tensor = 2 [packed = true];
  map<string, string> params = 3;
  uint32 max_tokens = 4;
}

// 响应消息
message PredictResponse {
  repeated float output_tensor = 1 [packed = true];
  float latency_ms = 2;
  string model_version = 3;
}

// 流式 Token 块
message TokenChunk {
  uint32 index = 1;
  string token = 2;
  bool is_final = 3;
}

// 特征向量
message FeatureVector {
  string id = 1;
  repeated float features = 2 [packed = true];
}

// 批量结果
message BatchResult {
  repeated PredictResponse results = 1;
  uint32 total_processed = 2;
}

// 用户消息
message UserMessage {
  string session_id = 1;
  string content = 2;
}

// 助手消息
message AssistantMessage {
  string session_id = 1;
  string content = 2;
  bool finish_reason = 3;
}

4.3 四种通信模式对比

gRPC 支持四种 RPC 模式，分别适用于不同的模型服务场景。下表从通信方向、适用场景和延迟特征三个维度进行对比：

4.4 流式模式在模型服务中的实践要点

在低延迟模型服务中，流式模式的选择直接影响用户体验和系统吞吐。以下是各模式的关键实践要点：

• Server Streaming 首 Token 优化：模型推理引擎应支持“预填充+解码”分离，预填充阶段完成后立即返回第一个 Token，后续解码结果持续推送。gRPC 的流式响应无需等待完整结果，可显著降低用户感知延迟。
• Client Streaming 背压控制：当客户端批量发送特征向量时，应使用 gRPC 的流控机制（基于 HTTP/2 的流控窗口）防止服务端过载。建议在客户端实现自适应发送速率，根据服务端 FlowControl 信号调整批次大小。
• Bidirectional Streaming 会话管理：在对话式 AI 场景中，每个 gRPC 流对应一个会话。服务端需维护会话状态（如上下文窗口），并在流关闭时清理资源。建议使用 session_id 字段关联同一会话的多个流。
• 错误处理与重试：流式 RPC 的中断恢复比 Unary 更复杂。对于 Server Streaming，客户端应记录已接收的 Token 索引，在重连时从断点处请求；对于 Bidirectional Streaming，建议实现心跳机制检测流健康状态。

4.5 从 Proto 到代码：生成与集成

定义好 .proto 文件后，使用 protoc 编译器生成客户端和服务端代码。以下是一个典型的生成命令：

# 生成 Python gRPC 代码
python -m grpc_tools.protoc \
  -I./protos \
  --python_out=./generated \
  --grpc_python_out=./generated \
  ./protos/inference.proto

# 生成 Go gRPC 代码
protoc \
  --go_out=./generated \
  --go-grpc_out=./generated \
  -I./protos \
  ./protos/inference.proto

生成后的代码结构包含：

• 消息类：对应 proto 中的每个 message，提供序列化/反序列化方法。
• 服务基类：服务端需继承的抽象类，实现每个 RPC 方法。
• 客户端 Stub：客户端调用的代理类，封装网络通信细节。