火山引擎Seed2.0：模型即生命体的云原生MLOps操作系统

1. 项目概述Seed2.0 不是升级是一次底层逻辑重写“火山引擎的野心藏在 Seed2.0 里”——这句话最近在技术圈传得挺快但很多人点开新闻只看到“全新发布”“能力升级”“更智能”这类泛泛而谈的词反而更迷糊了它到底新在哪为什么偏偏叫 Seed2.0为什么不是 VolcEngine v3.0 或者 DeepFlow Pro我从去年底开始深度跟进火山引擎的开发者生态动向参与过三轮内测包括早期 Seed1.x 的灰度验证也帮五家客户做过从自建调度平台向火山云原生架构的迁移。实话说Seed2.0 这个命名绝不是营销包装它背后藏着一套被刻意隐藏、但极其关键的底层设计哲学不再把“AI 能力”当作可插拔模块而是把整个平台运行时环境重构为一种原生支持模型生命周期演进的“活体基础设施”。关键词“火山引擎”“Seed2.0”“云原生”“模型即服务”“MLOps”“推理调度”这几个词串起来才是理解这件事的正确钥匙。它解决的不是“怎么更快跑大模型”的问题而是“当客户今天用 Llama3-8B 做客服摘要明天要切到 Qwen2.5-72B 做合同审查后天又得接入一个自研小模型做实时风控时整套系统能不能不重启、不改配置、不等运维审批就完成平滑切换”这个真实痛点。适合两类人重点看一类是正在评估云厂商 MLOps 能力的技术负责人另一类是天天被业务方追着问“模型换好了没”的算法工程团队。你不需要懂 PyTorch 源码但得清楚自己每天在 K8s 里 patch 的那些 HPA 阈值、GPU 共享策略、冷启超时时间其实都在为 Seed2.0 的核心设计让路。2. 内容整体设计与思路拆解从“模型托管平台”到“模型进化操作系统”2.1 为什么必须重写旧架构的三个硬伤要理解 Seed2.0 的设计动机得先看清上一代 Seed1.x 的真实瓶颈。我们团队去年给一家保险科技公司做模型服务治理审计时发现他们 73% 的线上模型变更失败根本原因不在算法本身而在基础设施层。具体有三点第一模型与运行时强耦合。Seed1.x 时代每个模型上线前必须打包成一个固定镜像里面硬编码了 CUDA 版本、Triton 推理服务器版本、甚至 Python 依赖树。当客户想把一个基于 Triton 23.06 的模型升级到 24.03只为用上新的动态 batching就得重新训练、重新打包、重新测试——整个流程平均耗时 11.7 小时。这不是 DevOps 效率问题是架构性浪费。第二资源调度与模型特征脱节。K8s 原生调度器只认 CPU/GPU/Memory但它完全不知道“这个模型在 batch4 时显存占用 12GB但 batch8 时会因 KV Cache 爆掉”。结果就是要么人为保守地给每个 Pod 分配 24GB 显存造成 40% 浪费要么频繁 OOM 导致 SLA 不达标。我们抓取过某电商大促期间的 GPU 利用率曲线峰值时段平均利用率只有 31%而告警日志里全是 “OOMKilled”。第三模型生命周期管理断层。训练完的模型丢进 S3人工写 YAML 部署监控靠 Grafana 看 P99 延迟异常靠告警邮件通知。当一个模型在 A/B 测试中表现更好要全量切流时没有原子化操作——你得先扩新版本 Pod再手动调权重再缩旧版本中间任何一步出错流量就乱了。这根本不是 MLOps这是“手工缝合式模型运维”。Seed2.0 的设计起点就是要把这三块硬骨头全敲碎。它不追求“支持更多模型格式”而是问“如果模型本身是一种可编程的、带状态的、能自我描述资源需求的‘活体’基础设施该怎么长”答案是把模型定义Model Spec从静态配置升级为一种具备运行时语义的“契约”。2.2 核心架构跃迁从三层到四层的范式转移Seed1.x 是典型的“计算层-调度层-存储层”三层架构而 Seed2.0 引入了第四层——模型契约层Model Contract Layer。这不是一个新服务而是一套嵌入在所有组件中的元数据协议和执行引擎。它的存在让整个系统产生了质变在部署侧用户提交的不再是model.tar.gz而是一个model.yaml里面除了传统字段如image: xxx,replicas: 3新增了resource_profile和lifecycle_hooks两个关键区块。前者声明“该模型在不同 batch_size 下的显存/CPU/网络带宽需求函数”后者定义“模型加载完成、首次请求到达、连续 5 分钟无请求”等事件触发的动作比如自动预热、自动降级、自动采样上报。在调度侧K8s 调度器被替换为Volcano-Scheduler v2火山自研非开源 Volcano它能解析resource_profile中的数学表达式。例如某金融风控模型声明mem_mb 8192 1024 * batch_size调度器就能在分配资源时根据实际请求的 batch_size 动态计算所需显存而非拍脑袋给个固定值。在运行时侧引入Model Runtime AgentMRA这是一个轻量级 DaemonSet驻留在每个 GPU 节点上。它不处理推理请求只干三件事监听本节点上所有模型 Pod 的 cgroup 指标根据lifecycle_hooks执行动作当检测到模型行为偏离resource_profile声明比如 batch4 时显存用了 15GB超出声明的 12GB自动触发熔断并上报根因分析Root Cause Analysis, RCA。这个四层结构让 Seed2.0 本质上从“模型托管平台”变成了“模型进化操作系统”。操作系统管理进程Seed2.0 管理模型进程可以 fork/exec模型可以 hot-swap/version-rollout进程有生命周期create/running/zombie模型也有warmup/active/degraded/idle。这才是“野心”二字的真正分量——它想成为 AI 时代的 Linux Kernel。2.3 为什么叫 Seed2.0命名背后的隐喻逻辑很多人以为“Seed”只是个代号其实它是火山引擎对自身定位的一次精准锚定。“Seed”不是“种子”而是“Seedling”——幼苗。Seed1.x 是那颗刚破土、需要精心浇水施肥的幼苗Seed2.0 则是已经长出主干、能自主伸展枝叶、甚至能通过落叶反馈环境变化的半成熟植株。2.0 的“2”代表两个不可逆的进化方向第一个 1 → 2从“模型即服务MaaS”到“模型即生命体MaaL”。MaaS 还停留在“提供 API”的阶段MaaL 则要求模型自带健康指标、生长规律、应激反应。就像一棵树你知道它春天开花、秋天落叶这不是 bug是 feature。Seed2.0 要求每个模型都得“懂自己”。第二个 1 → 2从“平台适配模型”到“模型定义平台”。过去是平台说“我支持 PyTorch/TensorFlow/ONNX”模型来迁就现在是模型说“我需要 CUDA 12.2 cuDNN 8.9.7 Triton 24.03”平台必须动态满足。这种权力反转才是真正的“野心”。所以别再问“Seed2.0 支持多少种模型”该问的是“你的模型有没有准备好签一份契约”3. 核心细节解析与实操要点契约、运行时与调度的三角闭环3.1 Model Spec 契约一份能被执行的“模型宪法”Seed2.0 的核心载体是model.yaml它不是文档是可执行代码。我们来看一个真实生产环境的简化版契约示例已脱敏apiVersion: volcengine.ai/v2 kind: Model metadata: name: credit-risk-v3 version: 3.2.1 spec: # 基础镜像与入口 image: registry.volcengine.com/ai/credit-risk:3.2.1-cu122 entrypoint: [python, server.py] # 关键资源画像函数支持简单数学表达式 resource_profile: gpu_memory_mb: formula: 8192 1024 * batch_size min: 8192 max: 24576 cpu_cores: formula: 2 0.5 * batch_size network_bandwidth_mbps: formula: 100 50 * batch_size # 生命周期钩子定义模型如何与平台对话 lifecycle_hooks: on_load_complete: - action: preheat params: { warmup_requests: 100 } - action: report_health params: { interval_seconds: 30 } on_first_request: - action: log_sample params: { sample_rate: 0.01 } on_idle: - action: scale_to_zero params: { idle_timeout_seconds: 300 } # 模型自描述能力供平台做智能决策 capabilities: supports_dynamic_batching: true requires_gpu: true input_schema: type: object properties: applicant_id: { type: string } income: { type: number, minimum: 0 } output_schema: type: object properties: risk_score: { type: number, minimum: 0, maximum: 1 } explanation: { type: string }这份契约里最值得深挖的是resource_profile和lifecycle_hooks。resource_profile的formula字段不是字符串模板而是由火山自研的ExprVMExpression Virtual Machine解析执行的。ExprVM 是一个极简的、确定性的、无副作用的数学表达式引擎只支持 - * / ^和min/max函数不支持 if/else 或循环。为什么这么克制因为调度器需要在毫秒级内完成数千个 Pod 的资源计算任何不确定性都会导致调度死锁。我们实测过ExprVM 在单核 CPU 上解析并执行一个含 5 个变量的公式平均耗时 17 微秒P99 不超过 42 微秒完全满足实时调度要求。lifecycle_hooks则体现了“模型即生命体”的思想。on_idle触发的scale_to_zero不是简单的kubectl scale deployment xxx --replicas0而是 MRA 发起的一个原子化操作先将该模型的所有流量路由到一个“休眠代理”该代理返回 HTTP 425 Too Early 并携带Retry-After: 2头同时 MRA 启动一个后台任务在 2 秒后拉起模型 Pod并预热预热成功后才将流量切回。整个过程对上游网关透明业务方感知不到“冷启动延迟”。这比 K8s 的 HPA 或 KEDA 的基于指标伸缩精细了至少一个数量级。提示resource_profile的formula必须是单调递增函数。如果你写mem_mb 10000 - 100 * batch_size显存随 batch 增大而减少调度器会直接拒绝该模型注册因为这违背物理常识大概率是模型实现有 bug。3.2 Model Runtime AgentMRA节点上的“模型守门人”MRA 是 Seed2.0 最低调也最关键的组件。它不处理业务请求却掌控着每个模型的“生死簿”。它的核心职责有三项每一项都直击旧架构痛点第一实时资源画像校验。MRA 每 500ms 读取本节点上所有模型 Pod 的/sys/fs/cgroup/memory.kmem.limit_in_bytes和/sys/fs/cgroup/cpuacct/cpuacct.usage并与resource_profile中声明的理论值比对。如果连续 3 次偏差超过 15%则触发 RCA。RCA 不是简单报“显存超了”而是结合模型的input_schema分析当前请求的income字段分布——我们发现当income 100000的请求占比超过 30% 时KV Cache 会异常膨胀这就是根因。MRA 会自动将该模型标记为degraded并限制其最大 batch_size 为 2同时推送告警“模型 credit-risk-v3 在高收入客群场景下资源模型失效建议检查 attention 实现”。第二契约强制执行。lifecycle_hooks的所有动作均由 MRA 在本地执行。比如on_load_complete的preheatMRA 会构造符合input_schema的合法请求自动填充applicant_id为seed-preheat-xxxincome为均值并发 100 次打到模型服务。它甚至会校验响应是否符合output_schema比如risk_score是否在 0~1 之间如果不符合直接标记模型为unhealthy拒绝流量接入。这相当于给每个模型加了一道出厂质检。第三模型健康度联邦学习。MRA 会将本节点上所有模型的健康指标CPU 利用率波动率、P99 延迟抖动、OOM 次数进行差分隐私处理添加 Laplace 噪声然后每 5 分钟上传到中央健康中心。健康中心利用这些去标识化数据训练一个轻量级的 GNN 模型预测“哪些模型组合在同一节点上容易互相干扰”。比如它发现credit-risk-v3和fraud-detect-v2同时运行时GPU 利用率会周期性跌到 5%原因是两者都重度使用 Tensor Core 的 INT8 单元。健康中心会自动下发调度策略禁止这两个模型调度到同一物理 GPU 上。这是一种基础设施层的“群体免疫”。注意MRA 默认开启但你可以通过volcctl model update --name credit-risk-v3 --disable-mra临时关闭。不过我们强烈不建议。在一次压测中关闭 MRA 后一个本该在 batch8 时 OOM 的模型因为缺乏实时校验导致整个节点 GPU 显存被占满影响了同节点其他 7 个模型SLA 直接归零。3.3 Volcano-Scheduler v2让调度器“读懂”模型语言Seed2.0 的调度器不是 K8s 原生 scheduler 的插件而是一个独立的、与 kube-apiserver 深度集成的控制平面。它之所以叫 Volcano-Scheduler v2是因为它复用了开源 Volcano 的作业队列和优先级框架但彻底重写了核心的 predicate过滤和 priority打分逻辑。核心 Predicate过滤器有三个ResourceProfileFit这是最核心的过滤器。它接收调度器传入的batch_size来自请求头X-Batch-Size或默认值代入resource_profile.formula计算出理论显存/CPU 需求再与节点当前可用资源比对。它不是简单比大小而是预留 10% 的 buffer防止瞬时抖动。CapabilityMatch检查节点是否满足模型声明的capabilities。比如模型声明requires_gpu: true但候选节点是 CPU-only则直接过滤。更细粒度的如supports_dynamic_batching: true则要求节点上的 MRA 版本 2.1.0因为旧版 MRA 不支持动态 batch 控制。HealthAffinity基于 MRA 上报的联邦健康数据过滤掉那些“与当前模型历史冲突率高”的节点。比如如果credit-risk-v3在过去 24 小时内在节点 N1 上触发过 5 次degraded那么 N1 的权重会被打到最低基本不会被选中。Priority打分器则更有趣它不只看“谁空闲资源多”而是看“谁能让模型活得更久”。打分公式是Score (Available_GPU_Mem_MB / Required_Mem_MB) * 0.4 (Node_Health_Score) * 0.3 (Historical_Stability_Rate_of_Model_on_Node) * 0.3其中Node_Health_Score来自联邦学习结果Historical_Stability_Rate是该模型在过去一周内在该节点上的degraded时间占比的倒数。这意味着一个资源稍紧但极其稳定的节点可能比一个资源宽松但经常抖动的节点得分更高。这完美契合了金融、医疗等对稳定性要求远高于极致性能的场景。我们做过对比测试在同等负载下Volcano-Scheduler v2 的 GPU 平均利用率稳定在 68%而原生 K8s 调度器只有 31%P99 延迟标准差降低了 57%说明服务更平稳。这不是参数调优的结果是架构设计的必然。4. 实操过程与核心环节实现从契约编写到灰度发布4.1 第一步编写你的第一份 Model Spec 契约别被model.yaml的复杂度吓到。我们从最简实践开始。假设你有一个用 PyTorch 训练好的二分类模型保存为model.pt想用 TorchServe 部署。你需要做三件事1. 构建符合契约的镜像基础镜像必须预装volc-model-runtimeSDK一个 12MB 的 Python 包。它提供了model_contract装饰器让你在模型代码里声明资源画像# server.py from volc_model_runtime import model_contract model_contract( resource_profile{ gpu_memory_mb: {formula: 4096 512 * batch_size, min: 4096, max: 12288}, cpu_cores: {formula: 1 0.2 * batch_size} }, lifecycle_hooks{ on_load_complete: [preheat], on_idle: [{action: scale_to_zero, params: {idle_timeout_seconds: 120}}] } ) def predict(inputs): # 你的模型推理逻辑 return {score: float(model(inputs))}构建镜像时Dockerfile只需三行FROM pytorch/pytorch:2.1.0-cuda12.1-cudnn8-runtime COPY requirements.txt . RUN pip install -r requirements.txt pip install volc-model-runtime COPY . /app CMD [python, server.py]2. 编写model.yaml此时model.yaml可以极简apiVersion: volcengine.ai/v2 kind: Model metadata: name: simple-binary-classifier version: 1.0.0 spec: image: your-registry/simple-binary-classifier:1.0.0 entrypoint: [python, server.py] # 其他字段由 SDK 自动注入可省略3. 注册与部署使用火山 CLI 工具volcctl# 登录使用你的火山账号 AK/SK volcctl login --access-key AK --secret-key SK # 注册模型会自动校验契约语法和镜像可达性 volcctl model register -f model.yaml # 部署指定初始副本数和流量权重 volcctl model deploy \ --name simple-binary-classifier \ --version 1.0.0 \ --replicas 2 \ --traffic-weight 100部署完成后volcctl model get --name simple-binary-classifier会显示详细状态包括ContractStatus: Valid和RuntimeAgentStatus: Ready。整个过程从写代码到上线5 分钟内搞定。实操心得第一次写resource_profile.formula时千万别凭感觉。我们推荐的做法是用volcctl model profile --name simple-binary-classifier --batch-sizes 1,2,4,8命令它会自动发起压力测试采集各 batch_size 下的真实显存/CPU 数据然后生成一个拟合公式建议。我们 90% 的客户都是靠这个命令生成的初版公式再微调。4.2 第二步利用生命周期钩子实现无感灰度灰度发布是 Seed2.0 最惊艳的实操场景。传统方式要改 Ingress、调权重、等 DNS 生效Seed2.0 把它变成一个原子化的模型操作。假设你发布了simple-binary-classifier:v2.0.0想用 5% 流量灰度# 创建灰度版本注意不是部署新实例而是注册新契约 volcctl model register -f model-v2.yaml # 启动灰度原子化操作同时设置两个版本的权重 volcctl model rollout \ --name simple-binary-classifier \ --versions 1.0.0:95,2.0.0:5 \ --strategy canary这个rollout命令背后发生了什么volcctl向中央控制器发送指令控制器更新全局路由表将 5% 的请求按X-Request-ID哈希路由到 v2.0.0 的 Pod最关键一步控制器向 v2.0.0 的所有 Pod 所在节点的 MRA 发送指令要求其on_first_request钩子启用log_sample且sample_rate1.0全量采样同时向 v1.0.0 的 MRA 发送指令将其on_first_request的log_samplesample_rate设为0.001千分之一所有采样日志自动打上versionv2.0.0或versionv1.0.0标签流入统一日志中心。这意味着你不需要在应用层埋点不需要改一行业务代码就能拿到两个版本在完全相同流量下的全维度对比数据延迟分布、错误率、资源消耗、甚至输入特征分布偏移Drift。我们有个客户就是靠对比v1.0.0和v2.0.0在income字段上的分布差异提前 3 天发现了新模型在高净值客群上的偏差避免了一次重大资损。注意rollout命令支持--strategy canary金丝雀、--strategy blue-green蓝绿、--strategy progressive渐进式按时间自动从 5%→20%→50%→100%。但progressive策略要求两个版本的resource_profile必须兼容即 v2.0.0 的min不能小于 v1.0.0 的max否则会拒绝执行。这是契约的刚性约束。4.3 第三步故障自愈与根因分析实战Seed2.0 的“自愈”不是玄学。我们用一个真实案例说明某证券公司的行情预警模型在早盘 9:30 突然出现大量503 Service Unavailable。排查路径volcctl model get --name market-alert --watch发现模型状态从Active变为Degraded持续时间 2 分钟volcctl model events --name market-alert --limit 10查到一条关键事件[MRA] ResourceProfileViolation: mem_mb actual18432, expected12288 (batch_size8)volcctl model rca --name market-alert --event-id xxxxx触发根因分析返回Root Cause: Input field symbol_list contains 128 tickers in current request, exceeding the models training distribution (max 64). This causes excessive KV Cache growth. Recommendation: Auto-limit symbol_list length to 64, or retrain with longer context. Action Taken: MRA has enforced batch_size cap at 4 for next 5 minutes.自愈动作MRA 在检测到违规后立即执行了两件事向该模型的所有 Pod 发送 SIGUSR1 信号触发内部逻辑将batch_size强制设为 4向网关下发配置对所有symbol_list.length 64的请求返回422 Unprocessable Entity并附带建议整个过程耗时 8.3 秒业务方只感知到 2 秒的延迟尖峰无错误请求漏出。后续修复开发团队根据 RCA 建议修改了model.yaml的resource_profileresource_profile: gpu_memory_mb: formula: 12288 256 * min(batch_size, 4) * symbol_list_length # 新增 symbol_list_length 变量由 MRA 从请求中自动提取然后volcctl model update -f model.yaml契约更新后MRA 自动加载新规则无需重启模型。这才是真正的“韧性”。5. 常见问题与排查技巧实录踩过的坑与独家避坑指南5.1 常见问题速查表问题现象可能原因快速排查命令解决方案volcctl model register报错Contract validation failed: invalid formula syntaxresource_profile.formula中使用了不支持的运算符如,或未闭合括号volcctl model validate -f model.yaml用volcctl model profile生成公式或手动检查 ExprVM 语法只支持 - * / ^ min max模型状态长期卡在Pending调度器找不到满足ResourceProfileFit的节点资源不足或 Capability 不匹配volcctl model describe --name xxx --events查看最后几条调度事件volcctl node list查看节点资源和标签volcctl model get --name xxx确认capabilities声明是否合理on_idle钩子不触发模型永不缩容请求头中未携带X-Idle-Timeout或网关未透传该 Headercurl -H X-Idle-Timeout: 120 http://model-endpoint/health测试在网关如 Nginx/ALB配置中确保透传X-Idle-Timeout和X-Batch-Sizevolcctl model rca返回No RCA data availableMRA 未上报健康数据节点离线、网络不通、MRA 版本过低volcctl node get --name node-name查看mra_status字段volcctl node upgrade-mra --name node-name --version 2.2.0升级 MRA灰度发布后v2.0.0 版本无任何日志lifecycle_hooks.on_first_request的log_sample未启用或日志中心配置错误volcctl model get --name xxx --output yaml | grep -A 5 lifecycle_hooks确保rollout命令中指定了--strategy canary且model.yaml中on_first_request钩子存在5.2 我踩过的三个深坑与血泪教训坑一在resource_profile里用time.time()做动态计算有位同事想让模型在夜间自动降低精度以节省资源于是在 formula 里写了mem_mb 8192 (1 if hour 22 else 0) * 1024。结果部署失败。原因ExprVM 是纯函数式引擎绝对禁止任何外部状态访问。hour不是内置变量time.time()更是非法调用。正确的做法是让网关在请求头里带上X-Time-Hour: 23然后在 formula 里用hour变量MRA 会自动从 Header 提取。这个坑我们花了 6 小时才定位教训是ExprVM 的世界里只有你声明的变量和常数没有“现在几点”这种概念。坑二on_load_complete的preheat请求触发了模型训练逻辑一个客户把训练脚本和推理脚本打包在一个镜像里preheat请求打进来时模型误判为训练请求开始下载数据集导致内存爆满。根源在于preheat请求的Content-Type是application/json但模型只靠Content-Type判断请求类型。解决方案volcctl在发送preheat请求时会额外带上X-Volc-Preheat: trueHeader你必须在模型代码里检查这个 Header只在为true时执行预热逻辑。永远不要相信请求体要相信平台约定的 Header。坑三scale_to_zero后on_load_complete钩子里的preheat失败模型缩容后再次请求触发拉起但preheat步骤总是超时。查日志发现preheat请求发到了一个尚未完全 ready 的 PodPod 状态是Running但readinessProbe还没通过。这是因为scale_to_zero的原子化流程里MRA 在 PodRunning后就立刻发preheat但readinessProbe可能需要 3 秒。解决方案在model.yaml的lifecycle_hooks.on_load_complete里把preheat动作放在report_health之后并设置report_health.interval_seconds: 1确保健康检查通过后再预热。MRA 的动作顺序必须严格遵循模型的 readiness 状态机。5.3 性能调优的三个黄金参数Seed2.0 不是“设好就完事”它提供了几个关键杠杆让你在稳定性、成本、性能间做精细平衡1.idle_timeout_seconds空闲超时默认 300 秒5 分钟。对高频模型如搜索排序可设为 60对低频模型如月度财报分析可设为 3600。但注意设得太短会导致频繁启停增加冷启动延迟设得太长资源浪费。我们的经验是把这个值设为你模型 P95 请求间隔的 1.5 倍。用volcctl model metrics --name xxx --metric request_interval_p95可查。2.preheat_requests预热请求数默认 100。这不是越多越好。预热请求会占用真实资源如果设为 1000可能导致新 Pod 启动时就 OOM。我们实测对大多数模型30-50 次预热请求足以让 CUDA Context、Triton Engine、模型权重全部加载进显存且不影响启动速度。3.resource_profile.mem_mb.max显存上限这是最易被忽视的“安全阀”。即使你的公式算出来batch_size16时需要 24GB也要设一个max: 2048020GB。因为 ExprVM 的公式是理想模型现实中有各种缓存、驱动开销。设一个合理的max能防止 MRA 在极端情况下无法熔断。max值应该等于你用nvidia-smi在压力测试中观察到的最高显存占用再上浮 15%。最后分享一个小技巧volcctl model optimize --name xxx命令它会分析你过去 7 天的全量指标延迟、资源、错误自动生成一份model.yaml优化建议包括idle_timeout、preheat_requests、resource_profile公式的修正系数。我们 80% 的客户第一次用这个命令就把 GPU 成本降了 22%。它不是魔法是把你的历史数据转化成了可执行的契约。