GRPS：网易开源的通用深度学习模型推理服务框架

想象一下：你的团队花了三个月训练出了一个效果不错的 ResNet-50 图像分类模型，或者一个基于 Transformer 的推荐模型，产品经理催促着尽快上线——但模型上线从来不是把文件丢到服务器就完事的事儿。你需要处理 HTTP 接口、需要动态批处理来压榨 GPU 吞吐、需要支持 gRPC 以应对高并发、还需要显存隔离、日志监控、Streaming 推流等企业级能力。每一个功能都意味着独立的工程量。

GRPS（Generic Realtime Prediction Service）正是为解决这一痛点而生。它是网易传媒团队开源的通用模型在线推理服务框架，支持 TensorFlow、PyTorch、TensorRT、vLLM、TensorRT-LLM 等主流深度学习框架的模型一键部署，核心目标是将训练好的模型快速送上生产环境，通过 HTTP/gRPC 接口对外提供服务。

一、项目背景与起源

GRPS 由网易传媒（NetEase-Media）团队内部孵化并开源，项目托管于 GitHub，仓库地址为 NetEase-Media/grps。项目采用 Apache-2.0 开源许可证，主要编程语言为 C++（服务端核心）和 Python（工具链与客户端），目前已获得约 168 颗 GitHub Stars。

从项目的发展轨迹来看，GRPS 的迭代重心始终跟随 NVIDIA 硬件生态演进：Dockerfile 模板从最早的 CUDA 10.1 + cuDNN 7.6.5 + TensorFlow 2.3.0 + PyTorch 1.8.1 一路扩展到 CUDA 12.6 + cuDNN 9.6 + TensorRT-LLM 0.16.0 的最新组合，覆盖了从 Volta 到 Hopper 架构的全代际 NVIDIA GPU。这种持续跟进硬件生态的姿态，说明 GRPS 并非一个"练手项目"，而是网易团队在生产环境中长期使用并持续迭代的工程化产品。

项目还配套维护了两个独立扩展仓库：grps-trtllm（支持 TensorRT-LLM 后端）和 grps-vllm（支持 vLLM 后端），以及大量示例工程仓库 grps_examples，体现了作者团队对大模型推理部署这一细分领域的持续投入。

二、核心能力：给模型装上"一键上线"引擎

GRPS 的设计哲学是零代码部署——只要你的模型符合支持的文件格式，就能通过一条命令将其部署为在线服务，无需编写任何服务代码。这种"像启动一个进程一样简单"的上线体验，是 GRPS 区别于 Triton Inference Server 等通用推理平台的核心差异。

GRPS 支持三种主流模型格式的快捷部署：

• TensorFlow：支持 SavedModel 格式，使用 grpst tf_serve /path/to/saved_model 即可启动服务
• PyTorch：支持 TorchScript 格式，使用 grpst torch_serve /path/to/script_model.pt 启动
• TensorRT：支持 Engine 格式，支持多流推理模式，使用 grpst trt_serve /path/to/engine 启动

图1：GRPS 框架架构总览

部署完成后，GRPS 自动监听 HTTP（默认 7080 端口）和 gRPC（默认 7081 端口）两个访问入口，客户端可以是 Python、C++ 或 Java，只需按约定的 JSON 格式发送请求即可获得推理结果。

三、双语言架构：C++ 核心 + Python 工具链

GRPS 采用了精心设计的双语言架构：服务端核心逻辑由纯 C++ 实现，以获得最高的推理性能和最低的延迟；Python 则负责工具链和客户端生态，保持了良好的易用性。

从目录结构可以清晰看到这种分层设计：

• server/cpp_server/：C++ 服务端核心，包含推理后端调度、HTTP/gRPC 服务器、动态批处理、显存管理等模块
• server/py_server/：Python 服务端封装，提供更灵活的自定义扩展接口
• grpst/：GRPS 工具链（grpst CLI），负责服务生命周期管理——部署（deploy）、查看状态（ps）、停止（stop）等操作
• template/cpp_template/ 和 template/py_template/：自定义工程模板，用户可基于模板扩展前后处理逻辑

grpst 是 GRPS 的命令行瑞士军刀，核心功能包括：

• grpst tf_serve：快捷部署 TensorFlow 模型
• grpst torch_serve：快捷部署 PyTorch 模型
• grpst trt_serve：快捷部署 TensorRT 模型
• grpst ps：查看当前运行中的所有服务及其 PID、端口、模型路径
• grpst stop <name>：停止指定服务

grpst 支持大量参数选项，覆盖了设备选择（--device gpu:4）、显存限制（--gpu_mem_limit_mib 4096）、动态批处理（--batching_type dynamic --max_batch_size 16）、日志管理（--log_dir --log_backup_count 7）等几乎所有生产级需求，细节相当成熟。

四、企业级特性：从Demo到生产的跨越

GRPS 并不只是一个"跑通就行"的 Demo 框架，它内置了大量企业级特性，直接对标生产环境的实际需求。

动态批处理（Dynamic Batching）

这是 GRPS 最具竞争力的特性之一。动态批处理允许将多个独立的推理请求自动合并为一个批次处理，充分利用 GPU 的并行计算能力。用户可配置最大批大小（--max_batch_size）和批处理超时时间（--batch_timeout_us），在延迟和吞吐之间取得平衡。

图2：Dynamic Batching 示意图，将多个请求自动合并处理

对于推荐系统、搜索排序等批量请求场景，Dynamic Batching 可以带来数倍的吞吐提升——实测中 TensorRT + Dynamic Batching 组合的吞吐远高于逐请求处理。

内置监控系统

GRPS 自带一套完整的指标监控系统，通过 Web 页面（http://host:7080/）可视化展示以下核心指标：

• QPS（Queries Per Second）：实时吞吐量
• Latency：延迟分布，包括 P50/P90/P99 分位数
• GPU/CPU 使用率：硬件资源实时占用

图3：GRPS 监控面板——吞吐量与延迟趋势图

图4：延迟累积分布函数（CDF），可直观看到 P99 延迟分位点

这套监控系统的优势在于零配置开箱即用，无需对接 Prometheus/Grafana 等外部监控系统，非常适合中小规模部署场景。

多模型与多卡支持

GRPS 支持在同一进程中部署多个模型，模型之间可以组合成级联服务（一个模型的输出作为下一个模型的输入），也可以独立对外提供。这种设计非常适合多模型 A/B 测试或组合推荐场景。

在硬件层面，GRPS 支持通过配置选择特定 GPU 设备部署模型，并支持多 GPU 的显存和利用率监控，满足多卡推理场景需求。

Streaming 推流支持

GRPS 支持模型持续推理并逐帧返回结果，适用于大语言模型（LLM）的 Token 生成、视频处理、自然语言生成等需要流式输出的场景。Streaming 模式下，服务端持续推送推理中间结果，客户端无需等待完整结果即可开始消费，大幅降低首 Token 延迟。

五、部署方式：Docker 镜像矩阵

GRPS 提供了极其丰富的预编译 Docker 镜像，覆盖了从旧到新的几乎所有主流 CUDA + 深度学习框架组合，形成了完整的"镜像矩阵"。所有镜像托管于阿里云容器镜像服务（registry.cn-hangzhou.aliyuncs.com/opengrps/），国内开发者 pull 速度极快。典型的启动命令仅需两行：

# 一键拉取镜像
docker pull registry.cn-hangzhou.aliyuncs.com/opengrps/grps_gpu:grps1.1.0_cuda12.6_cudnn9.6_trtllm0.16.0_py3.12

# 启动容器，映射服务端口
docker run -it --rm --runtime=nvidia --name grps_dev \
  -p 7080:7080 -p 7081:7081 \
  registry.cn-hangzhou.aliyuncs.com/opengrps/grps_gpu:grps1.1.0_cuda12.6_cudnn9.6_trtllm0.16.0_py3.12 bash

镜像覆盖范围包括：CUDA 10.112.6，cuDNN 7.6.59.6，TensorRT 7.2.38.6.3，PyTorch 1.8.12.5.1，vLLM 0.4.30.5.5，TensorRT-LLM 0.10.00.16.0，Python 3.7~3.12，组合超过 14 种预配置镜像，满足各类硬件环境。

六、大模型推理支持：LLM 时代的新战场

GRPS 对大语言模型（LLM）推理的支持通过两个独立扩展仓库实现：

grps-trtllm：集成 NVIDIA TensorRT-LLM，通过自定义后端插件方式接入 GRPS，支持主流 LLM 架构（Llama、GPT 等）的 TensorRT 加速推理。目前已兼容 OpenAI 协议，客户端可直接使用 OpenAI SDK 调用。

grps-vllm：集成 vLLM 高吞吐量推理引擎，支持 PagedAttention、Continuous Batching 等优化技术，同样通过自定义后端插件方式接入 GRPS，未来规划兼容 OpenAI 协议。

这两个扩展仓库的存在，说明 GRPS 的插件化后端设计是真正经得起生产验证的——通过统一的插件接口接入新的推理引擎，无需修改核心代码。

七、局限性与上手门槛

GRPS 并非没有短板。首先，它对 GPU 的强依赖决定了它不太适合纯 CPU 环境下的模型推理需求——虽然技术上可以在 CPU 模式下运行，但 TensorRT 加速的核心价值将完全丧失。

其次，尽管 GRPS 提供了"零代码快捷部署"的极简上手路径，但如果需要深度定制前后处理逻辑（比如特殊的输入预处理、数据格式转换），用户仍然需要阅读自定义工程文档、理解 GRPS 的插件机制，这对没有 C++/Python 工程经验的开发者来说存在一定门槛。

第三，GRPS 目前没有官方的 Kubernetes 部署 Manifest，对于已经深度使用 K8s 的团队来说，需要自行编写 Deployment/Service YAML。此外，GRPS 的监控方案在内小规模场景下足够用，但对于需要长期历史数据存储、告警规则配置的场景，建议对接到 Prometheus + Grafana 体系。

八、行业意义与展望

在 2024-2025 年大模型爆发之前，深度学习模型部署一直是工业界的痛点——学术界刷榜的模型往往缺乏可靠的工程化路径。TRITON Inference Server 虽然功能强大，但其复杂的配置和较高的学习曲线让很多中小团队望而却步。GRPS 的出现，提供了一条介于"手写 Flask 服务"和"部署完整 Triton Server"之间的中间路线：够用、好用、不over-engineering。

随着 vLLM 和 TensorRT-LLM 的加入，GRPS 已经从最初的传统 CV 模型部署工具，演进为可以支撑 LLM 生产推理的完整解决方案。在国内开源社区，网易传媒团队这种持续维护、跟进硬件生态的投入态度尤为难得——很多企业开源项目在初期热度之后就陷入停更，而 GRPS 从最早的 CUDA 10.1 一路维护到 CUDA 12.6，持续跟进了将近三年。

对于 AI 开发者而言，如果你需要快速将 PyTorch/TensorFlow 模型部署为生产级 HTTP/gRPC 服务，GRPS 是一个值得优先考虑的选择——特别是当你已经有 Docker 环境、只需要一条命令就能让模型跑起来时，它的效率优势是无可替代的。