fastDeploy
notAI-tech/fastDeploy加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
微信扫码咨询客服
POMOAI — 让开源 AI 即刻运行
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
做过深度学习项目的朋友大概都经历过这个尴尬时刻：模型在 Jupyter Notebook 里跑得好好的，F1 值 0.95，Accuracy 惊艳全场——然后，当你试图把它变成一个真正的在线服务时，一切就开始变得复杂了。
TF-Serving？Triton Inference Server？TorchServe？每一种方案都需要你改造模型代码，需要定义签名，需要编译，需要理解一堆运维概念。更别提当你有一整个预处理→推理→后处理的推理流水线时，不同环节可能用 PyTorch、TensorFlow、甚至第三方 API 混搭——这种"链式推理管道"在传统模型服务框架里几乎无解。
fastDeploy 解决的正是这个问题：它不需要你改一行推理代码，直接把你的 Python 函数变成可扩展的微服务。
深度学习推理服务有几个独特的挑战，与传统 Web 服务截然不同：
1. 批处理至关重要。 单个推理请求往往只有 50ms~几秒，如果每次只处理一个请求，GPU 利用率会非常低。真实场景中，用户请求会在短时间内密集到来（如搜索框输入、语音上传），把这些请求合并成批发送给模型推理，能将 GPU 利用率提升数倍。
2. 推理代码通常很"脏"。 真实的预测代码往往混着模型加载、数据预处理、后处理、业务逻辑，不一定符合标准 TF/PyTorch Serving 的接口规范。用传统框架需要"削足适履"地改造代码。
3. 多模型链式调用很常见。 典型场景如：语音→ASR→NLU→知识库→LLM→TTS，或者图像→检测→分类→OCR，每一步都是独立的 Python 模块。串联这些模块需要精巧的工程设计。
fastDeploy 的作者（Praneeth，GitHub @notAI-tech）从生产实践中提炼出这些需求，于 2020 年 4 月创建了该项目，目标就是：让任意 Python 推理管道，以最少的代码改动，上线成为可扩展的微服务。
fastDeploy 的核心概念是 Recipe（配方）——一个标准的文件夹结构，约定俗成地存放你的推理逻辑：
recipe_folder/
├── example.py # 示例输入输出，用于自动生成 API 文档
├── predictor.py # 你的推理函数（这是唯一必须写的！）
├── requirements.txt # 可选，pip 依赖
└── extras.sh # 可选，构建前执行的 Shell 命令
关键是 predictor.py 里只需要定义一个符合规范的函数：
def predictor(inputs, batch_size=1):
# inputs 是一个列表（可能是一批输入）
# batch_size 是框架建议的最优批大小
# 你的任务：返回与 inputs 等长的 outputs 列表
return [my_model.predict(x) for x in inputs]
这个函数不需要装饰器、不需要继承任何基类、不需要定义签名。 fastDeploy 通过 SQLite 队列连接预测循环和 REST API，天然支持预测端和 API 端独立扩缩容。
fastDeploy 的核心竞争力之一。开启预测循环后，框架会自动收集一段时间窗口内的请求，将其合并为一批发给 predictor() 函数处理。批处理窗口大小可以通过 optimal_batch_size 参数配置，也可以让框架自动测定最优值。
官方文档明确建议：对于推理时间 >50ms 的模型，批处理能显著提升吞吐量；而对于极轻量的模型（毫秒级推理）或 I/O 密集型任务（查询数据库、外部 API），批处理反而可能添乱。
通过多个 predictor_N.py 文件，可以串联多个推理环节：
fastdeploy --loop --recipe recipes/echo_chained --config "predictor_name=predictor_1.py"
fastdeploy --loop --recipe recipes/echo_chained --config "predictor_name=predictor_2.py"
fastdeploy --rest --recipe recipes/echo_chained
每个环节可以在不同的虚拟环境中运行，互不干扰——这解决了生产环境中不同模型依赖冲突的常见痛点。
技术栈：
架构模式： 经典的"生产者-消费者"（Producer-Consumer）架构：
两者通过 SQLite 队列解耦，可以独立部署、独立扩缩容——这是 fastDeploy 区别于大多数模型服务框架的独特设计。
AI 框架兼容： PyTorch、TensorFlow、ONNX、任意自定义模型均可。框架本身不绑定任何 AI 框架，只要能接收 Python 对象输入即可集成。
pip install --upgrade fastdeploy fdclient
# fdclient 是可选的 Python 客户端
fastdeploy --rest --recipe recipes/echo
# 默认监听 0.0.0.0:8080，可通过 --config 调整 workers、timeout 等参数
Python 客户端（fdclient）是最推荐的调用方式：
from fdclient import FDClient
client = FDClient('http://localhost:8080')
result = client.infer([obj_1, obj_2, obj_3])
也支持纯 curl：
curl -X POST http://localhost:8080/infer -d '{"inputs": [...]}'
fastdeploy --build --recipe recipes/echo
# 自动生成 Dockerfile，基于 python:3.8-slim
docker run -it -p8080:8080 fastdeploy_echo
注意： fastDeploy 本身无 Web UI 控制台，不提供浏览器界面。所有交互通过 REST API 或 Python 客户端进行。
Pickle 安全性：默认使用 Pickle 序列化传输数据。Pickle 在内部服务场景（请求来源可信）下完全安全且高效，但若直接暴露给外部用户且不经过验证，风险极高。文档中明确警告了这一点，并提供了 allow_pickle=false 选项。
不适合的场景：
文档质量：README 和配方文档较简洁，对复杂场景（如 TLS 认证、多实例部署）缺少详细指引，属于"一看就懂、一做就懵"类型文档。
Stars 与影响力：项目目前约 105 Stars，2020 年创建后持续维护（最近更新 2026-02），但社区规模较小，在模型服务领域知名度不如 TorchServe、Triton 等主流方案。
fastDeploy 代表了一类"轻量级模型服务"工具的思路：不做大而全的模型管理平台，而是专注于"让 Python 推理代码最快速地上线"这一个目标。相比 TF-Serving/Triton 的重型方案，fastDeploy 的上手门槛低得多——任何写过 Python 预测函数的开发者，10 分钟内就能让模型跑起来。
随着 LLMOps 和 AI Agent 的发展，这类工具的价值正在被重新认识：当 AI 应用越来越多地依赖本地推理（避免 API 成本和延迟）时，能够快速将自定义模型嵌入应用的轻量框架会越来越受欢迎。
# 1. 安装
pip install fastdeploy fdclient
# 2. 创建 recipe
mkdir my_recipe && cd my_recipe
# 编写 predictor.py，定义 predict(inputs, batch_size) 函数
# 3. 启动服务
fastdeploy --rest --recipe ./my_recipe
# 4. 调用
python -c "from fdclient import FDClient; print(FDClient('http://localhost:8080').infer(['hello']))"