RedisAI 是 Redis 的官方模块之一，它把 TensorFlow、PyTorch、ONNX Runtime 等主流推理后端直接嵌入 Redis 进程。模型加载完成后，客户端不需要再调用独立的模型服务，只需向 Redis 发送 AI.MODELRUN 命令，就能让模型在 Redis 所在机器上完成前向计算。这样设计省去了应用层到模型服务之间的一次乃至多次网络跳转，也避免了输入数据在缓存层与模型服务层之间重复序列化。对于已经大规模使用 Redis 的业务来说，模型推理可以变成一种类似缓存命中的内存级操作。
RedisAI 管理的核心对象包括模型、张量和脚本。模型对应后端加载的计算图，张量对应推理输入输出，脚本对应 TorchScript 等可执行逻辑。这些对象都存储在 Redis 的键空间中，和普通字符串、哈希一样可以设置过期时间、被多个客户端读取。因此模型只需加载一次，之后所有连接到同一 Redis 实例的进程都能复用这份推理能力，这与传统微服务架构中每个调用方都维护独立客户端连接或独立模型实例有很大不同。
一、RedisAI 的定位与后端支持
RedisAI 的设计目标不是替代模型训练平台，而是把训练好的模型尽量高效地搬到线上执行环境。模块本身通过 C 语言 API 调用各推理引擎，支持 TensorFlow、PyTorch、ONNX Runtime 以及纯 TorchScript 等不同后端。开发者在部署时明确指定 BACKEND 和 DEVICE 参数，例如 ONNX CPU 或 TORCH GPU，RedisAI 就会把对应计算图加载到指定设备。
不同后端支持的模型格式不同：TensorFlow 通常使用冻结图或 SavedModel 导出的 protobuf，PyTorch 需要先 trace 或 script 为 TorchScript，ONNX Runtime 则接受标准 ONNX 格式。这种多后端支持让模型上线不必强依赖单一框架，也能根据推理延迟、模型大小和设备环境选择更合适的后端。需要注意的是，不同后端在模型输入输出节点的命名、张量形状表示上存在差异，部署前最好先用框架自带工具确认节点信息。
加载 RedisAI 模块可以通过源码编译生成 redisai.so，也可以在启动 Redis 时用 loadmodule 指令加载。如果使用 Docker，则直接选择带 RedisAI 的镜像。模块加载后，Redis 会在现有命令之上注册 AI.MODELSET、AI.TENSORSET、AI.MODELRUN 等命令。因为没有独立推理服务常驻，整个部署链路缩短为 Redis 客户端、Redis 进程、推理后端三层，排障时也更容易定位问题。
下面这段配置展示了从模块文件加载 RedisAI 的典型方式：
# redis.conf 中加载 RedisAI 模块 loadmodule /usr/lib/redis/modules/redisai.so # 或直接通过命令行指定模块 redis-server --loadmodule /usr/lib/redis/modules/redisai.so
二、核心命令与模型部署流程
模型部署的核心命令是 AI.MODELSET。它以键名为模型名，参数中包含后端、设备、输入节点、输出节点和模型二进制数据。模型二进制数据通常较大，直接在命令行中拼接参数不方便，实际部署时可以用 redis-cli -x 从标准输入读取文件内容，再传给 AI.MODELSET。下面的命令片段展示了一个 ONNX 模型的加载过程：
# 从文件加载 ONNX 模型到 RedisAI redis-cli -x AI.MODELSET fraud_model ONNX CPU INPUTS transaction_features OUTPUTS fraud_score < model.onnx # 查看模型信息 redis-cli AI.MODELGET fraud_model META
加载完成后，推理输入输出以张量形式存在。AI.TENSORSET 用于创建张量，需要指定 Redis 键、数据类型、形状以及具体值。如果输入数据来自 CSV 或二进制文件，也可以使用 redis-cli -x 配合 BLOB 参数导入。数据类型支持 FLOAT、DOUBLE、INT32、INT64、UINT8 等，形状可以是一维、二维或更高维，与深度学习框架中的张量概念基本一致。
AI.MODELRUN 负责触发一次推理，它把输入张量键对应到模型的输入节点，把输出结果写入另一个张量键。推理结束后，用 AI.TENSORGET 读取输出张量的值。下面这组命令演示了创建一个输入张量、执行模型并获取结果：
# 创建输入张量：形状为 1x4，值为 0.1, 0.2, 0.3, 0.4 redis-cli AI.TENSORSET input_tensor FLOAT 1 4 VALUES 0.1 0.2 0.3 0.4 # 执行推理，结果写入 output_tensor redis-cli AI.MODELRUN fraud_model INPUTS input_tensor OUTPUTS output_tensor # 读取输出张量 redis-cli AI.TENSORGET output_tensor VALUES
这套命令的优势在于命令本身极短，客户端不需要理解模型细节。只要知道输入输出节点名和张量形状，就可以像操作普通 Redis 键一样发起推理。AI.MODELRUN 支持同步阻塞模式，也支持通过 AI.MODELRUN_ASYNC 写入队列异步执行。如果推理耗时较长，异步模式可以避免 Redis 单线程命令处理被阻塞，但通常更适合批量任务而不是单条低延迟请求。
三、Python 客户端集成与优化实践
生产环境中更常见的做法是在业务代码里通过 Redis 客户端执行模型推理。使用 Python 时可以直接用 redis-py 的 execute_command 方法调用 RedisAI 命令，不必依赖额外的专用库。下面示例展示了加载模型、创建张量、运行推理和读取结果的完整流程：
import redis
r = redis.Redis(host='127.0.0.1', port=6379, decode_responses=False)
# 读取模型二进制并加载到 RedisAI
with open('model.onnx', 'rb') as f:
model_blob = f.read()
r.execute_command('AI.MODELSET', 'fraud_model', 'ONNX', 'CPU',
'INPUTS', 'transaction_features',
'OUTPUTS', 'fraud_score',
'BLOB', model_blob)
# 准备输入张量：形状 1x4
r.execute_command('AI.TENSORSET', 'input_tensor', 'FLOAT', 1, 4,
'VALUES', 0.1, 0.2, 0.3, 0.4)
# 执行推理
r.execute_command('AI.MODELRUN', 'fraud_model',
'INPUTS', 'input_tensor',
'OUTPUTS', 'output_tensor')
# 获取输出
result = r.execute_command('AI.TENSORGET', 'output_tensor', 'VALUES')
print(result)
这段代码没有额外引入模型服务 SDK，所有交互都复用现有 Redis 连接。对已经大量使用 Redis 的推荐系统或风控系统来说，这种方式几乎不增加客户端复杂度。输入张量可以由特征工程阶段直接写入 Redis，模型输出也能被后续规则引擎或缓存逻辑立即消费，整条链路的数据流非常短。
优化 RedisAI 推理效果时，第一原则是模型尽量常驻内存。模型加载一次后在 Redis 进程内缓存，避免每次请求都从磁盘读取。第二原则是合理选择输入输出张量精度，例如 FLOAT 已经满足大多数场景，DOUBLE 会增加计算和内存开销。第三原则是尽可能减少客户端与 Redis 之间的无效拷贝，使用连接池而非频繁新建连接。如果单次请求包含多条样本，把张量形状写为 batch_size x feature_dim，一次 AI.MODELRUN 就能完成批量推理，吞吐量明显高于逐条调用。
另一个常见优化点是 GPU 后端的选择。RedisAI 在支持 CUDA 的环境下可以用 TORCH GPU 或 ONNX GPU 执行推理，但需要评估 CPU 到 GPU 之间的数据传输成本。对于小模型，GPU 调度和拷贝时间可能超过计算本身，CPU 反而更稳定。对于大模型或卷积神经网络，GPU 则能显著降低单次推理延迟。建议在真实业务数据上压测 CPU 和 GPU 两种配置，再决定是否启用 GPU 设备。
四、适用场景与部署注意事项
RedisAI 最适合那些已经严重依赖 Redis 内存数据、同时要求低延迟推理的场景。典型例子包括实时风控中的评分模型、推荐系统中的召回或排序模型、对话系统中的意图识别模型，以及物联网流式数据中的异常检测模型。在这些场景里，特征数据往往已经存放在 Redis 中，推理放在 Redis 内部可以避免把原始数据搬出再搬回，既降低延迟也减少网络带宽占用。
不过 RedisAI 并不适合所有推理场景。如果模型体积非常大，例如百 MB 甚至 GB 级的大语言模型，Redis 进程的内存占用会显著增加，而且单个 Redis 实例的吞吐受限于单线程命令处理。虽然 RedisAI 支持异步执行，但命令调度、键空间管理和连接处理仍然在 Redis 主线程中完成。遇到这类大模型或高并发场景，可以考虑多分片 RedisAI 部署，或者保留独立推理服务并用 Redis 做结果缓存，而不是把所有计算都塞进 Redis。
部署时还需要注意版本兼容和持久化行为。RedisAI 的版本需要与 Redis 版本匹配，不同模块版本对后端引擎的版本依赖也不同。模型加载后存储在 Redis 键空间，如果配置了 RDB 或 AOF 持久化，模型二进制数据可能被一并保存，重启时会恢复。但这也会让持久化文件变大、恢复时间变长。对于线上核心实例，建议把模型加载命令放在部署脚本中，而不是依赖持久化恢复，以便升级模型时能快速重新加载。