Palantir 多模态数据平面：Any Data、Any Compute、Any Model

技术教程2026-09-0317 मिनट पढ़ेंPalantirMMDP多模态数据Apache IcebergAgent数据架构Compute Modules

企业 AI 项目很容易形成数据孤岛：表格交给数据仓库，文档交给向量库，图片交给视觉服务，实时流交给消息系统，地理数据又单独建一套处理链。每条路线都能跑 Demo，但一旦要让 Agent 同时理解订单、图像、传感器和文档，系统复杂度会快速上升。

Palantir Architecture Center 用 Multimodal Data Plane（MMDP）描述一套开放的数据与计算架构，核心口号是：

Any data, any compute, any model, anywhere.

这不是说所有数据都必须存到同一个地方，而是强调不同数据、计算和模型之间应该能够在统一治理与语义体系中协作。

MMDP 解决的根本问题

传统平台经常围绕一种存储或计算模式设计：只擅长结构化表格，只擅长批处理，只支持平台内置模型，或者只能复制数据而不能使用原有系统的计算资源。

但企业运营同时包含结构化交易数据、非结构化文档和媒体、传感器与实时流、地理数据、机器学习模型、优化器以及历史系统中的专用程序。

MMDP 的目标，是让这些不同模态进入同一个面向运营的决策体系，而不必先强行变成同一种数据或运行时。

Any Data：开放数据架构

Apache Iceberg 的作用

官方资料把 Apache Iceberg 作为 Foundry 和 AIP 的主要表格式之一。Iceberg 的价值在于它被多个云和数据平台支持，可以帮助企业降低存储和计算绑定。

采用开放表格式后，企业可以更容易地在不同计算引擎之间读取同一份数据，用 SQL、Notebook 或 BI 工具访问，连接既有湖仓和云平台，并减少没有业务价值的数据复制。

虚拟表与不要重复搬数据

数据复制会带来新鲜度不一致、权限重复配置、血缘断裂、多个版本和复制任务失败等问题。

如果平台能以受控方式引用 Databricks、Snowflake、BigQuery 或其他数据系统里的资产，Agent 就可以在更接近真实来源的位置获得上下文，同时减少复制链路。

这并不意味着复制永远错误。高频查询、合规隔离、性能优化和历史快照都可能需要物化。关键是复制应成为有意识的架构选择。

超越表格：文档、媒体、流和地理数据

文档

需要解析文本、页码、表格、标题、版本、来源和访问权限。对 Agent 来说，文档片段还应关联到业务对象，而不是孤立地进入向量索引。

图像和媒体

需要保留文件、格式、分辨率、时间、位置、来源和处理结果。视觉模型输出的标签或描述，应该进入可追踪的元数据或对象关系。

流数据

传感器和事件流带来持续变化。业务对象需要能够订阅状态变化，而不是每次重新扫描整张表。

地理与时间数据

位置、轨迹、区域和时间窗口经常决定业务动作。它们应与订单、设备、人员和风险对象建立关系。

Any Compute：数据不应该被某个运行时绑架

开放计算架构可以容纳多种运行时：Spark 适合大规模批处理，Flink 适合流处理，DataFusion、Polars、DuckDB 适合高效分析，Python、Java、SQL、Go、Rust 适合不同开发任务，容器化自定义程序则可以作为 Compute Module 接入。

为什么要允许 Bring Your Own Compute

企业里有大量不能轻易重写的程序：领域优化器、仿真程序、经过多年验证的算法库、供应商二进制程序，以及已经部署在 HPC 或云平台上的推理服务。

Compute Modules 的思想，是将这些资源包装成受控的可部署单元，再让它们参与数据管道、应用、分析和 Agent 工作流。

Pushdown Compute：在数据所在的位置计算

数据不一定要先搬到 AI 平台再计算。对于大型数据集，把计算下推到 Databricks、Snowflake 或其他云原生运行时，通常更合理：

减少网络传输；
利用已有集群和成本合同；
保留原有治理和性能能力；
避免为一次 Agent 请求复制海量数据。

Agent 不需要读取十亿条交易明细，而应该调用一个按客户、时间窗口和权限计算风险指标的受控函数。

Any Model：模型可替换，但治理不能缺席

Any Model 不是模型越多越好，而是企业可以使用商业模型、开源模型、微调模型、领域模型和自建推理服务。

模型接入之后，仍然需要统一处理模型访问权限、资源预算、输入输出保护、评估与版本记录、失败和降级路径，以及不同模型的结果比较。

模型可选性只有在迁移成本可控时才有价值。否则只是把供应商切换成本从 API 层转移到整个业务应用层。

Anywhere：适应不同环境

企业的部署环境可能包括公有云、多云、私有云、本地数据中心、边缘节点和受监管网络。

设计时要提前画出：

数据驻留位置
模型调用位置
工具执行位置
身份与密钥位置
审计日志位置
升级和回滚路径

如果这张图画不出来，Agent 还不能进入生产设计。

一个多模态异常处理案例

假设要处理工厂设备异常：

实时传感器流提供温度、振动和电流变化；
历史维修记录和设备手册提供文本上下文；
现场照片提供视觉证据；
优化器计算停机与换机成本；
规则判断是否触发安全升级；
Agent 综合对象、指标、文档和图片生成处置建议；
授权用户确认后创建维修工单；
维修结果回写并用于后续评估。

流数据 + 文档 + 图像 + 历史表
              ↓
       Ontology 设备对象
              ↓
     规则 / 模型 / 优化器 / Agent
              ↓
       工单、通知、停机或回写

关键不是用了多模态模型，而是不同模态最终服务于同一个设备对象和同一个动作闭环。

AI FDE 设计清单

原始数据是否需要复制，为什么？
每种数据的更新频率和延迟是多少？
文档、图片和流事件如何关联到业务对象？
哪些计算必须在外部系统或边缘执行？
哪些模型可以替换，替换需要重新评估什么？
不同环境是否拥有相同的权限和审计能力？
Agent 是否只接收经过治理的结果，而非任意底层数据？

常见误区

把多模态等同于一个视觉模型

多模态架构关注的是数据类型、计算方式、语义关联和运营闭环，不只是图片输入。

为了统一而强行统一格式

统一接口和治理不等于所有数据必须转换成同一种格式。保留原始格式、按需处理通常更灵活。

只考虑模型接入，不考虑计算接入

企业的关键能力可能藏在优化器、仿真器和历史代码中。Agent 需要可控地调用这些计算资源。

忽略成本和数据移动

每一次复制、解析、向量化和跨区域传输都会产生成本与新的失败点。把数据移动作为架构决策记录下来。

参考资料

MMDP 的启发，是把多模态从模型输入问题提升为企业数据与计算架构问题：数据可以不同，计算可以不同，模型可以不同，但语义、治理和业务结果必须能够连接起来。