谁说 Python 搞不定 AI 模型微服务？！Towhee 来了！_towhee 本地模型

作者 | 郭人通

“从用 Python 定义流水线，到生成 Docker 镜像，再到启动服务并调用执行，一共不到 30 行代码！？”

想要模型落地，有一连串大坑躲都躲不开：

• 模型转不了 ONNX，TensorRT。

• 模型推理搞的飞快之后，发现预处理、后处理才是瓶颈。

• 除了需要搜寻各种英伟达的算法库，还需要学习各种高性能计算和 CUDA 编程技术，对着图片解码、视频解码、tensor transform、分词之类的操作一顿猛搞。

• 发现英伟达老爷的东西“又高又硬”，根本装不起来。

• 不仅要写一堆脚本程序，努力的把一整条处理流水线串起来，更要设计好服务的调用接口。

• 串完发现流水线各级速度不匹配，想着把慢的阶段起多实例并行，又扯上了负载均衡和流水线优化。

• 流水线上的算法实例起多了，物理资源又不够了。

• 一切内容终于准备就绪了，竟然又要去学写 Dockerfile ......

为了解决上面一连串的问题，我们发起了一个开源项目 Towhee（github.com/towhee-io/towhee），任何用户都能够从 Python 代码一键构建面向生产的高性能推理流水线。这个项目提供了一套优雅的函数式 Python 编程接口，以及一组覆盖日常工作所需要的工具集，只需要几行代码，就能够自动的解决上述问题：将推理流水线内出现的代码（模型、算法、数据处理过程等）转换成对应的高性能实现，组织端到端的推理服务代码，一键生成 Docker 镜像。

下面举一个小例子演示如何使用 Towhee：用 CLIP 做图片 embedding 特征提取。从定义流水线到生成 Docker 镜像，再到启动服务并调用执行，一共不到 30 行代码。

首先，用 Python 定义一个“流水线”：

流水线接受图片作为输入，输出图片对应的 embedding 向量。这个流水线包含两个算子 image_decode.cv2_rgb 和 image_text_embedding.clip_image，分别负责图片的解码以及 CLIP 的图片特征提取。

例子里对流水线进行了配置，通过 pipeline_config 的 format_priority 参数给到 Towhee 一个提示，告诉 Towhee 优先把模型转到 TensorRT 的格式去做推理，如果失败就尝试走 ONNX。

image_decode.cv2_rgb 的算子配置是 num_instance=4，让 Towhee 在流水线中起4个图片解码的实例提高并发。image_text_embedding.clip_image 的算子配置是 dev_id=0，让 Towhee 在 GPU0 上跑 CLIP 的推理。如果指定了使用 GPU 进行模型推理，Towhee 会自动的选择 GPU 版本的模型前后处理过程，并在同一块 GPU 设备上执行前处理、模型推理、后处理。更多流水线配置能力详见官方文档（https://docs.towhee.io/）。

接下来，我们通过 Towhee 把这个流水线制作成 Docker 镜像，这里选用 Nvidia Triton 作为高性能推理服务框架：

命令执行完毕，我们将得到一个名为 clip_image_embedding:v1  的镜像，使用下面的命令启动服务实例：

在完成了模型服务启动之后，我们在本地编写一个简单的测试程序，通过调用刚才启动的服务，对当前目录下 jpg 图片做 embedding 特征提取：

如果你想进一步做一个基于 CLIP 的 “文本-图像跨模态” 召回服务，我们还可以再添加一个用 “CLIP 提取文本 embedding 特征” 的流水线，并进一步丰富服务的调用代码，完整程序不会超过 100 行 Python 代码。（这里因为和上面的示例代码比较接近，就不展开赘述了，感兴趣的同学可以自行尝试，遇到问题欢迎到 Slack 或微信反馈，链接见文章末尾）

除了对大量工程细节的极致封装，Towhee 在性能方面也有不俗的表现。在我自己的机器上（64核CPU，3080单卡），使用 HuggingFace 的 CLIP 预训练模型和配套工具库实现了同样功能的流水线，并和 Towhee 的流水线进行了性能对比：

HuggingFace 与 Towhee 的流水线性能对比

经过多次实验，HuggingFace 流水线的平均 QPS 67，Towhee 流水线的平均 QPS 328。Towhee 的流水线有接近 5 倍的提速。也就是说，通过使用 Towhee，仅用一块卡就可以达到之前五块卡的服务能力，两个字，省钱！

接下来，继续分享一些 Towhee 中的重要组件和实用工具：Towhee Operator Hub、DataCollection 编程接口、高性能推理服务，以及项目的 Roadmap。

Towhee Operator Hub
 

Towhee 的 Hub 不叫 Model Hub，而是叫 Operator Hub。主要原因在于，Towhee 是面向端到端的流水线构建，不仅仅是聚焦神经网络模型，还更加关注算法模块功能的丰富度、高性能推理、标准的任务接口。

算法模块的丰富度：Towhee 中的算法模块，包括神经网络模型，也包括各种五花八门的数据处理方法，如音视频编解码、图片裁切、文本分词、向量降维、数据库操作等。

Towhee 关注的算法来源主要有四类：

• 应用场景所需的通用算法或数据处理方法；

• 各类顶会以及arXiv上受到广泛关注的前沿模型；

• Paper with Code 关键领域的 benchmark 上榜模型；

• 业务领域常用的算法库、模型库集成。

目前，Towhee 已经覆盖计算机视觉、自然语言处理、音频、生物医药、多模态五大领域的十多项任务，120多种模型结构，700多个预训练模型。查看 Towhee 支持的 Operator 列表（https://github.com/towhee-io/towhee）。

高性能推理：Towhee Hub 上的算法模块除了提供预训练模型以及Fine-tuning 能力，会更加聚焦流水线落地后的推理性能。Towhee 会为常用算法或前沿模型提供对应的高性能实现，根据 Python 侧流水线的定义，在推理服务的构建期进行自动化替换。这些加速支持包括：

• 模型转 ONNX、TensorRT；

• 前后处理的多线程、GPU 加速；

• 常见的数据处理过程加速，如图片、音频、视频解码加速等。

标准的任务接口：Towhee 会按照任务类型对算子进行模块化组织。任务类型确定了标准的调用接口，并通过算子提供这些接口的不同实现。

在 Towhee Hub 中 Operator 的组织方式类似 PapersWithCode，相同任务的 Operator 会组织在一个分类下，结构目录清晰、方便阅读和使用。目前，Towhee 社区也在尝试逐步覆盖 Papers with Code 上的重点任务，支持用户对 SOTA 模型的快速试用，避免用户在 “读懂论文-看懂论文作者的初版实现-面向工程落地的代码重构-PoC-性能优化” 这个链条上的重复造轮子。Towhee 会对已支持的模型添加 Papers with Code 链接。如果在 Papers with Code 模型页面的 'Code' 部分看到 towhee-io/towhee，就说明在 Towhee 可以对该模型进行试用。例如跨模态视频召回的 CLIP4Clip 模型。

Towhee Hub 上的每一个 Operator repo，既是一个模型的代码仓库，也是一个直接可调用的模块。如前面的例子中用到的 image_text_embedding.clip_image 算子，对应 Hub 上 image-text-embedding/clip_image 这个 repo。这个仓库的用户名和仓库名分别与流水线调用中的包名 image_text_embedding、算子名 clip_image 对应。Towhee 规定了一套 Operator 代码仓库的接口协议。只要代码仓库的组织方式遵守这套协议规范，就可以通过 Towhee 提供的工具，将仓库代码自动化打包，并可以通过 "用户名.仓库名" 的方式对算法模块直接加载调用。

任务接口标准化有一个非常大的优势是可以灵活切换模型，而不用担心引入额外的工程量。这对于快速 PoC 以及流水线升级都很重要。在原型阶段，可以根据业务逻辑确定需要哪些类型的任务，由于相同任务下的不同算子具有一致的调用接口，因此可以乐高积木式的自由组合，进行快速的效果尝试。在生产环境如果需要对流水线的某个 Operator 升级，也只需要在流水线的定义中替换相应的 Operator，通过 Towhee 重新构建 docker image 即可。

目前 Towhee 社区也在收集用户的算子需求，在每个版本中进行汇总并更新实现。有这方面需求的同学可以加项目的Slack/微信群进行讨论或提 github issue。相关链接在文章末尾。

DataCollection 编程接口
 

Operator 是乐高积木，DataCollection 接口则是强力胶，用来连接积木。通过 DataCollecton 接口，Towhee 用户可以轻松构建推理流水线。DataCollection 在逻辑上的定义是一个带 Schema 的非结构化数据表格，每一行对应一个数据实体（Entity），每一列对应一种数据属性。一个流水线对应着一组数据属性操作，每个 Operator 接受一到多个数据属性作为输入，并产生新的数据属性作为输出。

DataCollection 主要有三个作用：

• 在原型阶段，用于构建可直接本地执行的流水线；

• 用于定义面向生产部署的 DAG；

• 作为 driver program 连通业务逻辑与流水线服务。

在文章一开始 CLIP 的例子中，已经简单演示了后两个用法。这里对流水线的本地快速原型构建做一个简单的介绍。CLIP 这个例子的本地可执行版本写出来是这样：

代码中方括号的部分指定了 schema 的相关信息。这个例子中 3 个 Operator 够成了一个收尾相连的链，当然，还可以通过 DataCollection 定义一些比 operator-chain 更复杂的 DAG：

这个例子中，我们先通过 YOLO v5 检测图片中出现的 objects，然后在原图中将这些 objects 裁切出来，并使用 CLIP 分别对这些 objects 的图片进行 embedding feature 的提取。这个 DAG 画出来是这个样子：

CLIP 示例对应的 DAG

高性能推理服务
 

Towhee 项目的目标不是打造一款全新的推理引擎，而是聚焦于让现有的高性能推理引擎更加落地。目前，Towhee 的推理服务适配了 Nvidia Triton 推理框架，主要特性包括：

• 推理流水线 DAG。相比常见的推理引擎只支持 “单纯的神经网络模型推理”，或 “前处理-模型推理-后处理 三阶段流水线”，DAG 型的流水线可以覆盖更丰富的数据处理组合逻辑。

• 异构的推理后端。DAG 中的每一个算子节点可以在不同的后端引擎上执行，既包括神经网络推理引擎，如 Pytorch(TorchScript)，ONNXRuntime, TensorRT；也包括通用的数据处理过程，如 Python 函数，DALI，或自定义Python/C++后端；还包括数据库/索引连接器，如 Milvus，FAISS。

• 极致的推理性能。推理服务可在 NVIDIA GPU，x86/ARM CPU 上高效运行，支持多 GPU，支持多模型实例，支持实时、流式、批处理、动态批处理请求，支持流水线自动并行。

• Docker 与 Kubernetes 部署。推理流水线都以 Docker 镜像的方式进行封装，对外提供 grpc 与 http 接口，隐藏大量内部复杂性。可通过 Kubernetes 轻松部署推理微服务。

在支持上述特性的同时，Towhee 为用户完成了大量自动化工作，包括逻辑图到物理图的映射，物理图到异构执行后端的映射，以及运行期调度。

DAG 的映射与自动优化

上图给出了 CLIP 这个例子从流水线定义到生成推理流水线服务的过程。从上到下，整个自动化构建与执行过程共分三个阶段，分别是逻辑图（编译期），物理图（编译期），以及执行后端（运行期）。逻辑图是通过对 DataCollection 进行 Trace 所获得的关于图定义的完整元信息。物理图会对逻辑图中各个算子节点进行物理实现的绑定，如 image_decode 节点在物理层会以 Python model 的方式执行 OpenCV 程序，CLIP 对应的图片前处理过程在物理层会绑定 DALI 实现，CLIP 模型在物理层会绑定 TensorRT 实现。同时，这些算子节点会在物理层完成 ensemble 的相关配置、实例个数配置、以及物理资源的分配。在运行期，会根据物理图上各个节点的物理绑定，适配执行后端，以及物理内存与计算资源，并根据图上各个算子节点的依赖关系，驱动流水线的自动化执行。

Roadmap
 

Towhee 项目的 Roadmap 可以在官网（https://towhee.io/）查看。目前，Towhee 项目还在快速迭代与重度研发的阶段。项目 Roadmap 上的关键内容有：

前沿算法模型

模型方面，近期会聚焦 CVPR 2022 新出炉的前沿成果，如 CV 大神何恺明的 MAE，香港大学、UC Berkeley、腾讯合作的 MCQ 等。同时，会集成 AutoEncoder ，提供向量降维能力。对于中文跨模态搜索、多模态召回、代码等数据上的任务类型也会有模型更新。

进展详情请关注项目的 Model ChangeLog。

计算机视觉：

• MAE：Masked Autoencoders Are Scalable Vision Learners CVPR2022 (backbone)

• SVT：Self-supervised Video Transformer (action recognition)

• TransRAC：Encoding Multi-scale Temporal Correlation with Transformers for Repetitive Action Counting (repetitive action counting)

• CoFormer：Collaborative Transformers for Grounded Situation Recognition (action recognition/grounded action counting)

• MCQ：Bridging Video-text Retrieval with Multiple Choice Question (text video retrieval)

• STRM：Spatio-temporal Relation Modeling for Few-shot Action Recognition (action recognition)

多模态：

• CoOp：Conditional Prompt Learning for Vision-Language Models (visual language task)

• CVNet：Correlation Verification for Image Retrieval (image retrieval)

代码文件：

• CodeBERT：A Pre-Trained Model for Programming and Natural Languages

• CodeGen：A Conversational Paradigm for Program Synthesis

Embedding 向量降维：

• Autoencoder

编程接口与工具

• 更加统一的 DataCollection 批处理接口与流处理接口。

• 支持自定义的算子。Towhee 目前给出了比较丰富的标准算子模块，但在常见的业务流程中，通常会引入业务逻辑，自定义算子可以很好的满足这部分需求。Towhee 的自定义算子将会包含两种形态，一种是通过 python 的 lambda 表达式生成，另一种是通过继承 Operator 基类生成。

• 算子的打包与安装工具升级。支持基于 pip 的打包与安装，并提供基于 AWS S3 的模型参数下载服务，优化本地模型参数缓存。

推理服务优化

• 支持视频与音频的推理流水线。长视频或长音频的处理往往会耗费大量物理资源，针对这类场景，Towhee 将不再一次性展开帧数据，而是提供流式的帧数据处理，以降低内存/显存需求。

• 在推理服务构建中完整支持 Schema。

• 基于 numba 的 python 算子自动优化 （实验阶段）。Towhee 通过自定义算子支持业务相关的逻辑，我们鼓励用户使用 python 来快速构建这些逻辑，同时，Towhee 会在底层对这些 python 代码进行尽可能的优化：基于 numba，使用LLVM编译技术解释字节码，优化 IR 并翻译到目标代码进行执行。

本地执行优化

• 支持基于 Apache Arrow 的列存数据，提高本地内存利用率，支持连续内存上的向量化执行。

• Transformer 模型结构的执行性能优化（实验阶段）。

Towhee 项目的相关链接
 

• Github：

  https://github.com/towhee-io/towhee

• 项目主页：

  https://towhee.io/tasks/operator

• Slack：

  https://slack.towhee.io/

阅读原文：https://www.wpsshop.cn/w/2023面试高手/article/detail/423670