Feast Feature Serving 与模型推理架构四种生产级推理模式的实现与选型指南【免费下载链接】feastThe Open Source Feature Store for AI/ML项目地址: https://gitcode.com/GitHub_Trending/fe/feast导读本文以 Feast 官方架构文档 Feature Serving and Model Inference 为主线系统拆解生产环境机器学习系统中四种模型推理Model Inference的落地模式在线特征 在线推理、预计算预测值的离线推理、带缓存预测的在线推理以及无特征直出推理。文章不仅完整保留原文档的代码示例与权衡分析还结合当前仓库 Python SDK 的get_online_features、write_to_online_store、push、materialize等核心 API 实现与 Python 特征服务器 的 HTTP 端点给出可直接复制运行的工程方案帮助你依据延迟、数据新鲜度与计算成本约束为业务正确选择推理架构。架构前提说明本文展示的 ML 基础设施图描述了一种由客户端应用驱动的编排模式client-driven orchestration。这并不是唯一可行的做法不同的编排模式会带来不同的权衡取舍详见原文档 model-inference.md。一、四种模型推理服务模式总览生产机器学习系统通常可以从以下四种方式中选择一种来对外提供模型预测结果即模型推理的输出原文档对此给出了权威归纳在线模型推理 在线特征Online model inference with online features无在线特征的离线模式推理Offline mode inference without online features在线模型推理 在线特征 缓存预测Online model inference with online features and cached predictions无特征的在线模型推理Online model inference without features需要特别说明的是在线特征可以来自批处理batch、流式streaming或请求时request数据源。这四种模式在延迟、数据新鲜度、实现复杂度与基础设施投入上有显著差异没有绝对优劣只有与业务约束的匹配程度。二、模式一在线模型推理 在线特征2.1 模式定位与适用场景这是数据驱动型 ML 应用最常用的做法由特征存储Feature Store对外提供在线特征由模型服务器如 KServe对外提供模型预测。它特别适合那些必须在请求时刻取用实时数据才能完成推理的场景——例如点击率预估、实时风控、个性化推荐等特征值必须反映用户当下的最新行为。2.2 核心调用链get_online_features原文档给出了本模式的最小实现骨架features store.get_online_features( feature_refs[ user_data:click_through_rate, user_data:number_of_clicks, user_data:average_page_duration, ], entity_rows[{user_id: 1}], ) model_predictions model_server.predict(features)从仓库源码看这一骨架对应 SDK 的 FeatureStore.get_online_features 方法其内部关键行为包括支持两种特征声明方式既可以传feature_view:feature形式的字符串引用列表也可以直接传FeatureService对象官方推荐用 Feature Service 按模型版本聚合特征见 feature-retrieval.mdentity_rows 无需时间戳与离线检索不同在线检索每个实体键只取一条最新值因此entity_rows不需要event_timestamp原文档与 feature-retrieval.md 均明确此点registry 缓存影响首访延迟方法首次运行会下载完整 registry若使用 GCS/S3 等远程 registry首次请求可能耗时数秒之后按 TTL 缓存可通过refresh_registry()在 TTL 到期前主动刷新以避免同步下载阻塞在线请求支持full_feature_names置为True时返回的特征名会带上 Feature View 前缀如daily_transactions→customer_fv__daily_transactions便于多视图合并时消除列名歧义底层实现该方法通过 provider 分发最终调用各在线存储实现的get_online_features可参考 infra/online_stores/online_store.py 与 infra/provider.py 中的接口定义若配置了 MLflow 自动记录config.mlflow.auto_log还会自动记录特征检索耗时、实体数量与检索类型等观测数据。2.3 生产化路径特征服务器与多语言客户端在线推理场景中推荐通过部署好的Python 特征服务器以 HTTP JSON 方式取特征这样任何能发 HTTP 请求的语言Java、Go、Node.js 等都能接入。启动命令为feast serve默认端口 6566# 生产配置按 CPU 核数自动计算 worker 数并设置 registry 刷新间隔 feast serve --workers -1 --worker-connections 1000 --registry_ttl_sec 60对应的 HTTP 请求示例curl -X POST http://localhost:6566/get-online-features \ -d { features: [ user_data:click_through_rate, user_data:number_of_clicks, user_data:average_page_duration ], entities: { user_id: [1] } }仓库中 feature_server.py 的get_online_features端点实现会统计特征数、特征视图数与实体数等指标并支持按full_feature_names等参数透传。特征服务器的完整性能调优参数--workers、--worker-connections、--max-requests、--registry_ttl_sec、--keep-alive-timeout等见 Python feature server。2.4 请求数据源request data的补充原文档指出在线特征可来自请求数据源。在 Feast 中这类推理请求时刻才产生的特征可通过 Request Source 定义配合 On-Demand Feature View 在特征服务器读取路径上完成实时变换。从源码结构看feature_server.py 的读取路径包含 ODFV 变换计时transformation_duration_seconds指标需要 ODFV 显式开启track_metricsTrue印证了读取时变换是受支持的在线链路能力。三、模式二无在线特征的离线推理预计算预测3.1 模式定位与适用场景这是实现门槛最低、最直接的做法把模型预测结果本身当作一个普通特征用标准的 Feast SDK 从特征存储中取用。预测值通常由某个批处理任务预先算好——例如一个对一批用户本地跑模型推理、输出 CSV 的脚本——再通过物化materialization写入在线存储从而实现在线服务。3.2 核心代码与原理解析model_predictions store.get_online_features( feature_refs[ user_data:model_predictions, ], entity_rows[{user_id: 1}], )注意此模式完全不涉及模型服务器。预测值是预计算后物化到在线存储的读取路径退化为一次在线存储查询。预计算产物写入在线存储有两种方式批处理 物化批处理脚本产出 CSV/DataFrame 后使用feast materialize或feast materialize-incremental把离线数据灌入在线存储。仓库中 FeatureStore.materialize 支持start_date/end_date时间区间、feature_views白名单以及disable_event_timestamp源数据无事件时间戳时用当前时间代替等参数materialize_incremental 则从上次物化结束点增量补齐两者均可通过run_asyncTrue异步执行直接写入批处理脚本也可以直接调用store.write_to_online_store(feature_view_nameuser_data, df...)把预测 DataFrame 写入在线存储该方法在 feature_store.py 中实现会先校验 DataFrame 非空、特征列非全空再经由 provider 的ingest_df落库。3.3 权衡与局限原文档明确指出该模式的两大短板数据陈旧stale data预测值在批处理时刻生成两次批处理之间数据不更新实体覆盖有限只能服务批处理计算时刻已存在的用户/实体新实体在下一轮批处理前无法获得预测。这些局限在某些业务场景如以天为粒度更新的评分、人群分层下是可以接受的但它天然不适用于强实时需求。另外预计算预测值同样可以作为普通特征参与get_historical_features离线检索便于模型版本间的对照验证。四、模式三在线推理 在线特征 缓存预测4.1 模式定位这是工程上最复杂的一种模式通过缓存预测结果来优化推理延迟——预测在数据生产者写入特征时即被计算并缓存客户端读特征时直接拿到预测值从而把模型推理从请求关键路径上移除。它特别适合以下场景特征来自多个数据源模型计算开销大、推理耗时长延迟是硬性约束SLA 严苛。4.2 客户端读取带缓存兜底# Client Reads features store.get_online_features( feature_refs[ user_data:click_through_rate, user_data:number_of_clicks, user_data:average_page_duration, user_data:model_predictions, ], entity_rows[{user_id: 1}], ) if features.to_dict().get(user_data:model_predictions) is None: model_predictions model_server.predict(features) store.write_to_online_store(feature_view_nameuser_data, dfpd.DataFrame(model_predictions))这段代码体现了cache-aside旁路缓存语义优先读缓存预测值缓存未命中model_predictions为None时才现场推理并把结果写回在线存储。仓库中 write_to_online_store 的实现细节值得注意它支持transform_on_writeTrue写入前变换与allow_registry_cache允许使用缓存 registry且对空 DataFrame、全空特征列会给出告警并提前返回避免无效写入。4.3 数据生产者写入主动刷新缓存由于底层数据变化会导致预测随之变化原文档要求数据生产者每次写入时另行调用write_to_online_store刷新缓存# Client Writes from the Data Producer user_data request.POST.get(user_data) model_predictions model_server.predict(user_data) # assume this includes user_data in the Data Frame store.write_to_online_store(feature_view_nameuser_data, dfpd.DataFrame(model_predictions))4.4 权衡与适用边界优点每个数据生产者多一次写入开销换来的是最低的推理延迟——在线请求路径上只有一次在线存储读取代价写入路径变重、缓存一致性需要自行维护每次数据变更都要触发预测重算与写回工程复杂度最高生产建议在特征服务器部署形态下/write-to-online-store端点已内置见 python-feature-server.md 的权限表配合POST /push推送数据源可以实现更解耦的写路径。若使用 Push Source还可通过store.push(push_source_name..., df..., toPushMode.ONLINE)实时注入新特征详见 push.md。五、模式四无特征的在线模型推理该模式不需要 Feast 参与模型服务器直接输出预测不依赖任何特征。它在以下两类模型中非常常见大语言模型LLM直接基于 Prompt 生成内容无需结构化特征其他不需要特征即可推理的模型。5.1 一个重要的例外RAG 需要特征原文档特别提醒使用检索增强生成RAG的生成式模型仍然需要特征——文档嵌入document embeddings被当作特征来处理而这正是 Feast 的能力范围对应在线模型推理 在线特征模式。仓库对此有完整支撑向量数据库集成列表Pgvector、Elasticsearch、Milvus、Qdrant、ScyllaDB、SQLite、Faiss 等见 alpha-vector-database.md其中 Milvus、SQLite、ScyllaDB 已实现 v2 的retrieve_online_documents_v2支持在向量相似度检索的同时返回普通特征便于向 Prompt 注入更丰富的上下文特征服务器提供POST /search向量检索端点/retrieve-online-documents已废弃并可通过 feature_store.yaml 配置本地embedding_model默认sentence_transformersall-MiniLM-L6-v2无需外部 API Key实现服务端文本向量化仓库还提供了可直接运行的 RAG 示例例如 examples/rag/feature_repo/example_repo.py 与 examples/rag-retriever含rag_feast.ipynb可作为文档嵌入作为特征的端到端参照。六、客户端编排模式Client Orchestration原文档指出上述代码示例隐含了一个设计抉择客户端如何编排取特征与跑推理这两个调用。Feast-centric以特征存储为中心如本文示例所示客户端先调 Feast 取特征再把特征作为模型输入发起推理。由于特征是模型的输入调用顺序显而易见实现简单直接也是原文档示例采用的方式Inference-centric以推理服务为中心客户端只调用一个统一的推理端点由推理服务内部负责先取特征、再推理的完整编排。调用方与特征存储解耦但推理服务需要自行集成特征拉取逻辑并承担由此带来的依赖与运维复杂度。选择哪种编排取决于团队边界若特征逻辑归特征平台团队维护Feast-centric 更利于收敛职责若希望业务方只面对一个模型 APIInference-centric 更友好。两种模式可以共存于同一系统例如在线链路用 Inference-centric离线回填用 Feast-centric。七、四种模式选型对照与总结模式是否使用 Feast是否使用模型服务器特征新鲜度推理延迟实现复杂度典型场景① 在线推理 在线特征是是高实时/近实时高请求路径含推理中实时风控、CTR 预估、个性化推荐② 离线推理预计算预测是预测值作特征否低批处理间隔最低一次存储读低日粒度评分、人群分层、批量打标③ 在线推理 在线特征 缓存预测是是写入路径高最低读缓存最高多源特征、高计算成本模型、低延迟 SLA④ 无特征在线推理否是—取决于模型低LLM 生成、无需特征的端到端模型选型建议可总结为三条主线数据新鲜度敏感度特征随请求时刻变化且必须实时 → 模式①或③可接受批处理粒度 → 模式②延迟与成本约束模型贵且延迟敏感 → 优先模式③缓存预测或模式②预计算模型轻量且特征实时 → 模式①特征存在性模型不需要特征如纯 LLM 生成→ 模式④但 RAG 场景记得把文档嵌入作为特征交给 Feast 管理参见 alpha-vector-database.md。无论选择哪种模式核心 API 与工程构件都是相通的get_online_featuresfeature_store.py、write_to_online_storefeature_store.py、materialize/materialize_incrementalfeature_store.py以及feast serve特征服务器python-feature-server.md。你可以从模式②起步快速见效再逐步演进到模式①或③将推理延迟与数据新鲜度调整到业务可接受的平衡点。【免费下载链接】feastThe Open Source Feature Store for AI/ML项目地址: https://gitcode.com/GitHub_Trending/fe/feast创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
