链上 AI 服务的 SLA 可观测性延迟、准确率与成本的实时监控仪表盘设计一、当推理质量从黑箱变成合约承诺可观测性为何成为信任基础设施中心化 AI 服务的 SLAService Level Agreement观测相对简单API 提供商在后台监控延迟和错误率用户通过状态页面status.openai.com查看服务可用性。但去中心化 AI 服务引入了一批根本性的可观测性挑战推理节点是匿名的、推理结果的质量没有单一权威来源、链上交互的 Gas 成本受区块空间供需波动影响。用户需要的不再是平台承诺的 SLA而是可验证的实时 SLA 数据。可观测性在这里不再仅仅是运维工具而成为信任基础设施。一个推理节点声称处理请求的平均延迟为 200ms它的声明与链上的实际表现是否一致一个去中心化模型市场声称某模型的准确率为 92%这个数字是驻留在提供者的营销文案里还是在链上有可审计的历史记录一个推理节点是否在 30 天内保持了 99% 的在线率还是频繁掉线之后又重新上线这些问题的回答决定了用户是否愿意将高价值的推理任务委托给一个无许可的节点网络。从工程视角看这里有一个关键的数据完整性挑战推理节点可以伪造延迟数据——它可以在链上提交一个比真实推理时间更短的延迟值。对抗这种行为的唯一手段是交叉验证多个独立的监控节点从不同地理区域向同一推理节点发送测试请求将测量的外部延迟与节点声明的延迟进行对比。如果差异超过合理阈值如外部延迟 声明延迟的 2 倍标记该节点为延迟作弊。本文将设计一个面向链上 AI 服务的实时 SLA 监控仪表盘的完整架构覆盖三个核心指标延迟、准确率、成本的数据采集、聚合与可视化管线。二、可观测性管线的架构设计2.1 数据源与采集策略链上 AI 服务的 SLA 数据来自三个异构数据源链上事件日志推理请求提交InferenceRequested、结果回传ResultDelivered事件。从中可计算延迟两事件的时间戳差值。TEE/验证层输出如果推理节点在 TEE 中执行可通过 TEE 的远程证明Remote Attestation获取节点硬件状态和推理过程的完整性证明。用户反馈链上的满意度评分如rateResult(requestId, score)作为准确率的软标识。graph TD A[链上事件br/InferenceRequested] -- B[EventIndexerbr/事件索引器] C[链上事件br/ResultDelivered] -- B D[TEE远程证明br/硬件完整性报告] -- E[AttestationCollectorbr/证明收集器] F[用户反馈br/rateResult] -- G[FeedbackAggregatorbr/反馈聚合器] B -- H[TimescaleDBbr/时序数据库] E -- H G -- H H -- I[Prometheusbr/指标引擎] I -- J[Grafanabr/可视化仪表盘] H -- K[SlothOraclebr/链上SLA合约] K -- L[评分/质押调整] subgraph 链上SLA合约 K L end style K fill:#4ecdc4,color:#fff style J fill:#a78bfa,color:#fff2.2 三个核心指标的测量方法flowchart LR subgraph 延迟 Latency L1[InferenceRequestedbr/timestamp: T1] -- L2[ResultDeliveredbr/timestamp: T2] L2 -- L3[latency T2 - T1] L3 -- L4[P50/P95/P99br/滑动窗口聚合] end subgraph 准确率 Accuracy A1[用户评分: 1-5] -- A2[加权平均br/近期评分权重更高] A2 -- A3[TEE验证通过率] A3 -- A4[综合准确率分数] end subgraph 成本 Cost C1[Gas消耗: per-request] -- C2[Gas价格: eth_gasPrice] C2 -- C3[ETH/USD汇率] C3 -- C4[每请求美元成本] C4 -- C5[节点利润率计算] end三、SLA 监控系统的工程实现// sla-collector.ts — SLA数据采集与聚合引擎 // 设计决策采用双写架构——原始事件写入TimescaleDB以支持灵活的历史查询 // 聚合指标写入Prometheus以支持实时告警和Grafana可视化。 // 二者各有擅长TimescaleDB擅长过去72小时内P95延迟的变化趋势这类 // 复杂时间窗口查询Prometheus擅长当前P95延迟 500ms → 触发告警这类 // 实时规则评价。 import { createPublicClient, http, parseAbiItem } from viem; import { mainnet } from viem/chains; import { Pool } from pg; import { Registry, Counter, Histogram, Gauge } from prom-client; import express from express; // -------------------------------------------------------------------- // Prometheus指标注册用于Grafana仪表盘 // -------------------------------------------------------------------- const registry new Registry(); // 延迟直方图使用指数分桶——100ms到10s覆盖短推理到大模型场景 const requestLatency new Histogram({ name: ai_inference_latency_seconds, help: Inference request latency in seconds, labelNames: [model_id, provider_id], // 桶边界(milliseconds)自然对数间隔覆盖常见推理延迟范围 buckets: [0.1, 0.2, 0.5, 1, 2, 5, 10], registers: [registry], }); // 请求计数器按模型和节点维度计数用于计算错误率 const requestCount new Counter({ name: ai_inference_requests_total, help: Total number of inference requests, labelNames: [model_id, provider_id, status], // status: success/failure/timeout registers: [registry], }); // 实时Gas成本仪表值每区块更新 const gasCostGauge new Gauge({ name: ai_inference_gas_cost_wei, help: Gas cost per inference request (wei), labelNames: [model_id, provider_id], registers: [registry], }); // 指标暴露端点 // 设计决策复用Express而非单独启动指标服务器 // 避免多端口管理的运维复杂性 const app express(); app.get(/metrics, async (_req, res) { res.set(Content-Type, registry.contentType); res.end(await registry.metrics()); }); app.listen(9090); // -------------------------------------------------------------------- // TimescaleDB连接池 // 设计决策使用连接池控制并发。max20是因为事件索引写入 // 和仪表盘查询共享同一个池各给10个连接的配额。 // -------------------------------------------------------------------- const pool new Pool({ host: process.env.TIMESCALE_HOST, database: sla_observability, max: 20, // 启用准备好的语句缓存——批处理写入时减少解析开销 statement_timeout: 10000, }); // 初始化TimescaleDB创建超表和连续聚合 async function initTimescaleDB() { await pool.query( CREATE TABLE IF NOT EXISTS inference_events ( time TIMESTAMPTZ NOT NULL, request_id TEXT NOT NULL, model_id TEXT NOT NULL, provider_id TEXT NOT NULL, event_type TEXT NOT NULL, -- requested | delivered | rated data JSONB, block_num BIGINT ); -- 转换为TimescaleDB超表按7天分块 SELECT create_hypertable(inference_events, time, chunk_time_interval INTERVAL 7 days, if_not_exists TRUE ); -- 连续聚合视图每小时聚合的延迟百分位数 -- 设计决策连续聚合在后台增量更新替代手动批处理作业。 -- 查询时直接SELECT即可获得预聚合指标延迟10ms。 CREATE MATERIALIZED VIEW IF NOT EXISTS hourly_latency_stats WITH (timescaledb.continuous) AS SELECT time_bucket(1 hour, time) AS bucket, model_id, provider_id, COUNT(*) AS total_requests, AVG((data-latency_ms)::numeric) AS avg_latency, -- 使用percentile_cont计算P95近似值高基数场景使用uddsketch approx_percentile(0.50, percentile_agg((data-latency_ms)::numeric)) AS p50_latency, approx_percentile(0.95, percentile_agg((data-latency_ms)::numeric)) AS p95_latency FROM inference_events WHERE event_type delivered GROUP BY bucket, model_id, provider_id; -- 自动刷新策略每30分钟更新一次 SELECT add_continuous_aggregate_policy(hourly_latency_stats, start_offset INTERVAL 2 hours, end_offset INTERVAL 1 hour, schedule_interval INTERVAL 30 minutes ); ); } // -------------------------------------------------------------------- // 事件索引器监听链上事件并写入数据库 // 设计决策使用viem的watchEvent而非轮询 // 避免无谓的RPC请求消耗。 // 通过WebSocket订阅实时事件延迟200ms。 // -------------------------------------------------------------------- const client createPublicClient({ chain: mainnet, transport: http(process.env.RPC_URL!), }); async function startEventIndexer() { // 监听推理请求事件 const unwatchRequest client.watchEvent({ address: process.env.SCHEDULER_CONTRACT as 0x${string}, event: parseAbiItem(event InferenceRequested(bytes32 indexed requestId, address consumer, bytes32 modelId, uint256 timestamp)), onLogs: async (logs) { for (const log of logs) { // 设计决策使用异步迭代器逐个处理日志。 // 每处理一个事件即插入数据库而非批量提交。 // 因为事件量级较小10/s不做批处理反而降低代码复杂度。 await pool.query( INSERT INTO inference_events (time, request_id, model_id, provider_id, event_type, data, block_num) VALUES ($1, $2, $3, , requested, $4, $5), [ new Date(Number(log.args.timestamp!) * 1000), log.args.requestId!, log.args.modelId!, JSON.stringify({ consumer: log.args.consumer }), log.blockNumber, ] ); requestCount.inc({ model_id: log.args.modelId!, provider_id: pending, status: requested }); } }, }); // 监听结果交付事件 const unwatchResult client.watchEvent({ address: process.env.SCHEDULER_CONTRACT as 0x${string}, event: parseAbiItem(event ResultDelivered(bytes32 indexed requestId, address provider, uint256 latencyMs, uint256 gasUsed)), onLogs: async (logs) { for (const log of logs) { const latencyMs Number(log.args.latencyMs!); const gasUsed Number(log.args.gasUsed!); await pool.query( INSERT INTO inference_events (time, request_id, model_id, provider_id, event_type, data, block_num) VALUES (NOW(), $1, , $2, delivered, $3, $4), [ log.args.requestId!, log.args.provider!, JSON.stringify({ latency_ms: latencyMs, gas_used: gasUsed }), log.blockNumber, ] ); // Prometheus指标记录 const labels { model_id: unknown, provider_id: log.args.provider! as string }; requestLatency.observe(labels, latencyMs / 1000); requestCount.inc({ ...labels, status: success }); gasCostGauge.set(labels, gasUsed); } }, }); return () { unwatchRequest(); unwatchResult(); }; } // -------------------------------------------------------------------- // SLA评分计算加权滑动窗口 // 设计决策使用指数加权移动平均EWMA计算准确率 // 近期评分权重更高——如果节点最近开始提供低质量推理 // EWMA能在约12小时内反映出质量下降半衰期约6小时。 // -------------------------------------------------------------------- interface NodeSLA { providerId: string; modelId: string; avgLatency: number; // P50延迟ms p95Latency: number; // P95延迟ms accuracyScore: number; // 综合准确率0-100 costPerRequest: number; // 每请求平均Gas成本wei recentRequestCount: number; } async function calculateNodeSLA( providerId: string, modelId: string, windowHours: number 24 ): PromiseNodeSLA | null { const result await pool.query( WITH delivered AS ( SELECT (data-latency_ms)::numeric as latency_ms, (data-gas_used)::numeric as gas_used, time FROM inference_events WHERE provider_id $1 AND event_type delivered AND time NOW() - INTERVAL 1 hour * $3 ), ratings AS ( SELECT (data-score)::numeric as score, time FROM inference_events WHERE provider_id $1 AND event_type rated AND time NOW() - INTERVAL 1 hour * $3 ) SELECT COUNT(*) as total, PERCENTILE_CONT(0.50) WITHIN GROUP (ORDER BY d.latency_ms) as p50_lat, PERCENTILE_CONT(0.95) WITHIN GROUP (ORDER BY d.latency_ms) as p95_lat, AVG(d.gas_used) as avg_gas, AVG(r.score) as avg_score FROM delivered d LEFT JOIN ratings r ON r.time BETWEEN d.time - INTERVAL 1 minute AND d.time INTERVAL 10 minutes , [providerId, modelId, windowHours]); if (result.rows.length 0 || result.rows[0].total 0) return null; const row result.rows[0]; return { providerId, modelId, avgLatency: Number(row.p50_lat || 0), p95Latency: Number(row.p95_lat || 0), accuracyScore: Number(row.avg_score || 0) * 20, // 1-5 → 0-100 costPerRequest: Number(row.avg_gas || 0), recentRequestCount: Number(row.total), }; }四、仪表盘设计与告警策略Grafana 仪表盘布局建议一个高效的 SLA 仪表盘应当按从宏观到微观的信息层级排列Row 1 — 全局概览总请求量折线图24h、活跃节点数Stat Panel、全局平均延迟Gauge绿/黄/红三色阈值 200ms/500ms/1000ms。Row 2 — 按模型分组各模型的请求量分布饼图、各模型的 P95 延迟趋势折线图按模型分 Legend、模型级别的 Gas 成本对比柱状图。Row 3 — 按节点分组Top 10 节点延迟排行表格带迷你折线图、节点准确率热力图按时间轴展开颜色表示准确率高低、异常节点标记Stat Panel 显示 P95 延迟 阈值的节点数。Row 4 — 成本分析平均 Gas 成本的 7 天趋势、Gas 价格gwei与推理请求量的相关性散点图判断高 Gas 时用户是否减少推理请求。告警规则告警的粒度需要分层设计。全局级别的告警P95 延迟 阈值触发后需要进一步钻取到节点级别定位是哪个推理节点造成了整体延迟升高。建议在 Prometheus 中使用histogram_quantile按provider_id分组配合 Grafana 的 Heatmap Panel 快速识别异常节点。告警疲劳是另一个常见的工程问题。设定阈值过于敏感的后果是运维团队对告警脱敏。延迟告警应区分 WarningP95 1s可能来自正常抖动和 CriticalP95 3s明确异常准确率告警应限定最少样本量——节点刚上线只有 5 次推理、3 次被评 1 分就触发告警是误报应要求至少 50 次推理后才启用准确率告警。# prometheus-alerts.yml groups: - name: ai_inference_sla rules: # 延迟告警P95延迟超过1秒持续5分钟 - alert: HighInferenceLatency expr: histogram_quantile(0.95, rate(ai_inference_latency_seconds_bucket[5m])) 1 for: 5m labels: severity: warning annotations: summary: {{ $labels.provider_id }} P95延迟超过1秒 # 成本告警单请求Gas 300k wei约0.01 ETH 30 Gwei - alert: HighGasCost expr: ai_inference_gas_cost_wei 300000 for: 10m labels: severity: info annotations: summary: 推理服务{{ $labels.provider_id }} Gas成本异常升高 # 准确率下降EWMA准确率 50% 持续30分钟 - alert: LowAccuracy expr: ai_inference_accuracy_score 50 for: 30m labels: severity: critical annotations: summary: 节点{{ $labels.provider_id }}准确率低于50%建议审查五、总结链上 AI 服务的 SLA 可观测性不是一个简单的监控面板项目而是去中心化 AI 生态中信任机制的工程实现。本文设计的采集-聚合-可视化管线覆盖了延迟、准确率、成本三个维度的全链路数据并通过 TimescaleDB Prometheus 的双引擎架构平衡了历史分析的灵活性与实时告警的时效性。后续迭代方向包括将 SLA 指标写入链上合约通过 Chainlink Functions 或自定义 Oracle使节点质押的罚没逻辑与实时 SLA 数据挂钩引入分布式追踪如通过 TEE 内部的 OpenTelemetry 集成将单次推理请求从模型加载到结果返回的全链路延迟做分阶段测量以及建立跨节点、跨模型的 SLA 基准数据集为去中心化 AI 的质量评估提供公信力基线。
链上 AI 服务的 SLA 可观测性：延迟、准确率与成本的实时监控仪表盘设计
发布时间：2026/7/12 18:47:07
链上 AI 服务的 SLA 可观测性延迟、准确率与成本的实时监控仪表盘设计一、当推理质量从黑箱变成合约承诺可观测性为何成为信任基础设施中心化 AI 服务的 SLAService Level Agreement观测相对简单API 提供商在后台监控延迟和错误率用户通过状态页面status.openai.com查看服务可用性。但去中心化 AI 服务引入了一批根本性的可观测性挑战推理节点是匿名的、推理结果的质量没有单一权威来源、链上交互的 Gas 成本受区块空间供需波动影响。用户需要的不再是平台承诺的 SLA而是可验证的实时 SLA 数据。可观测性在这里不再仅仅是运维工具而成为信任基础设施。一个推理节点声称处理请求的平均延迟为 200ms它的声明与链上的实际表现是否一致一个去中心化模型市场声称某模型的准确率为 92%这个数字是驻留在提供者的营销文案里还是在链上有可审计的历史记录一个推理节点是否在 30 天内保持了 99% 的在线率还是频繁掉线之后又重新上线这些问题的回答决定了用户是否愿意将高价值的推理任务委托给一个无许可的节点网络。从工程视角看这里有一个关键的数据完整性挑战推理节点可以伪造延迟数据——它可以在链上提交一个比真实推理时间更短的延迟值。对抗这种行为的唯一手段是交叉验证多个独立的监控节点从不同地理区域向同一推理节点发送测试请求将测量的外部延迟与节点声明的延迟进行对比。如果差异超过合理阈值如外部延迟 声明延迟的 2 倍标记该节点为延迟作弊。本文将设计一个面向链上 AI 服务的实时 SLA 监控仪表盘的完整架构覆盖三个核心指标延迟、准确率、成本的数据采集、聚合与可视化管线。二、可观测性管线的架构设计2.1 数据源与采集策略链上 AI 服务的 SLA 数据来自三个异构数据源链上事件日志推理请求提交InferenceRequested、结果回传ResultDelivered事件。从中可计算延迟两事件的时间戳差值。TEE/验证层输出如果推理节点在 TEE 中执行可通过 TEE 的远程证明Remote Attestation获取节点硬件状态和推理过程的完整性证明。用户反馈链上的满意度评分如rateResult(requestId, score)作为准确率的软标识。graph TD A[链上事件br/InferenceRequested] -- B[EventIndexerbr/事件索引器] C[链上事件br/ResultDelivered] -- B D[TEE远程证明br/硬件完整性报告] -- E[AttestationCollectorbr/证明收集器] F[用户反馈br/rateResult] -- G[FeedbackAggregatorbr/反馈聚合器] B -- H[TimescaleDBbr/时序数据库] E -- H G -- H H -- I[Prometheusbr/指标引擎] I -- J[Grafanabr/可视化仪表盘] H -- K[SlothOraclebr/链上SLA合约] K -- L[评分/质押调整] subgraph 链上SLA合约 K L end style K fill:#4ecdc4,color:#fff style J fill:#a78bfa,color:#fff2.2 三个核心指标的测量方法flowchart LR subgraph 延迟 Latency L1[InferenceRequestedbr/timestamp: T1] -- L2[ResultDeliveredbr/timestamp: T2] L2 -- L3[latency T2 - T1] L3 -- L4[P50/P95/P99br/滑动窗口聚合] end subgraph 准确率 Accuracy A1[用户评分: 1-5] -- A2[加权平均br/近期评分权重更高] A2 -- A3[TEE验证通过率] A3 -- A4[综合准确率分数] end subgraph 成本 Cost C1[Gas消耗: per-request] -- C2[Gas价格: eth_gasPrice] C2 -- C3[ETH/USD汇率] C3 -- C4[每请求美元成本] C4 -- C5[节点利润率计算] end三、SLA 监控系统的工程实现// sla-collector.ts — SLA数据采集与聚合引擎 // 设计决策采用双写架构——原始事件写入TimescaleDB以支持灵活的历史查询 // 聚合指标写入Prometheus以支持实时告警和Grafana可视化。 // 二者各有擅长TimescaleDB擅长过去72小时内P95延迟的变化趋势这类 // 复杂时间窗口查询Prometheus擅长当前P95延迟 500ms → 触发告警这类 // 实时规则评价。 import { createPublicClient, http, parseAbiItem } from viem; import { mainnet } from viem/chains; import { Pool } from pg; import { Registry, Counter, Histogram, Gauge } from prom-client; import express from express; // -------------------------------------------------------------------- // Prometheus指标注册用于Grafana仪表盘 // -------------------------------------------------------------------- const registry new Registry(); // 延迟直方图使用指数分桶——100ms到10s覆盖短推理到大模型场景 const requestLatency new Histogram({ name: ai_inference_latency_seconds, help: Inference request latency in seconds, labelNames: [model_id, provider_id], // 桶边界(milliseconds)自然对数间隔覆盖常见推理延迟范围 buckets: [0.1, 0.2, 0.5, 1, 2, 5, 10], registers: [registry], }); // 请求计数器按模型和节点维度计数用于计算错误率 const requestCount new Counter({ name: ai_inference_requests_total, help: Total number of inference requests, labelNames: [model_id, provider_id, status], // status: success/failure/timeout registers: [registry], }); // 实时Gas成本仪表值每区块更新 const gasCostGauge new Gauge({ name: ai_inference_gas_cost_wei, help: Gas cost per inference request (wei), labelNames: [model_id, provider_id], registers: [registry], }); // 指标暴露端点 // 设计决策复用Express而非单独启动指标服务器 // 避免多端口管理的运维复杂性 const app express(); app.get(/metrics, async (_req, res) { res.set(Content-Type, registry.contentType); res.end(await registry.metrics()); }); app.listen(9090); // -------------------------------------------------------------------- // TimescaleDB连接池 // 设计决策使用连接池控制并发。max20是因为事件索引写入 // 和仪表盘查询共享同一个池各给10个连接的配额。 // -------------------------------------------------------------------- const pool new Pool({ host: process.env.TIMESCALE_HOST, database: sla_observability, max: 20, // 启用准备好的语句缓存——批处理写入时减少解析开销 statement_timeout: 10000, }); // 初始化TimescaleDB创建超表和连续聚合 async function initTimescaleDB() { await pool.query( CREATE TABLE IF NOT EXISTS inference_events ( time TIMESTAMPTZ NOT NULL, request_id TEXT NOT NULL, model_id TEXT NOT NULL, provider_id TEXT NOT NULL, event_type TEXT NOT NULL, -- requested | delivered | rated data JSONB, block_num BIGINT ); -- 转换为TimescaleDB超表按7天分块 SELECT create_hypertable(inference_events, time, chunk_time_interval INTERVAL 7 days, if_not_exists TRUE ); -- 连续聚合视图每小时聚合的延迟百分位数 -- 设计决策连续聚合在后台增量更新替代手动批处理作业。 -- 查询时直接SELECT即可获得预聚合指标延迟10ms。 CREATE MATERIALIZED VIEW IF NOT EXISTS hourly_latency_stats WITH (timescaledb.continuous) AS SELECT time_bucket(1 hour, time) AS bucket, model_id, provider_id, COUNT(*) AS total_requests, AVG((data-latency_ms)::numeric) AS avg_latency, -- 使用percentile_cont计算P95近似值高基数场景使用uddsketch approx_percentile(0.50, percentile_agg((data-latency_ms)::numeric)) AS p50_latency, approx_percentile(0.95, percentile_agg((data-latency_ms)::numeric)) AS p95_latency FROM inference_events WHERE event_type delivered GROUP BY bucket, model_id, provider_id; -- 自动刷新策略每30分钟更新一次 SELECT add_continuous_aggregate_policy(hourly_latency_stats, start_offset INTERVAL 2 hours, end_offset INTERVAL 1 hour, schedule_interval INTERVAL 30 minutes ); ); } // -------------------------------------------------------------------- // 事件索引器监听链上事件并写入数据库 // 设计决策使用viem的watchEvent而非轮询 // 避免无谓的RPC请求消耗。 // 通过WebSocket订阅实时事件延迟200ms。 // -------------------------------------------------------------------- const client createPublicClient({ chain: mainnet, transport: http(process.env.RPC_URL!), }); async function startEventIndexer() { // 监听推理请求事件 const unwatchRequest client.watchEvent({ address: process.env.SCHEDULER_CONTRACT as 0x${string}, event: parseAbiItem(event InferenceRequested(bytes32 indexed requestId, address consumer, bytes32 modelId, uint256 timestamp)), onLogs: async (logs) { for (const log of logs) { // 设计决策使用异步迭代器逐个处理日志。 // 每处理一个事件即插入数据库而非批量提交。 // 因为事件量级较小10/s不做批处理反而降低代码复杂度。 await pool.query( INSERT INTO inference_events (time, request_id, model_id, provider_id, event_type, data, block_num) VALUES ($1, $2, $3, , requested, $4, $5), [ new Date(Number(log.args.timestamp!) * 1000), log.args.requestId!, log.args.modelId!, JSON.stringify({ consumer: log.args.consumer }), log.blockNumber, ] ); requestCount.inc({ model_id: log.args.modelId!, provider_id: pending, status: requested }); } }, }); // 监听结果交付事件 const unwatchResult client.watchEvent({ address: process.env.SCHEDULER_CONTRACT as 0x${string}, event: parseAbiItem(event ResultDelivered(bytes32 indexed requestId, address provider, uint256 latencyMs, uint256 gasUsed)), onLogs: async (logs) { for (const log of logs) { const latencyMs Number(log.args.latencyMs!); const gasUsed Number(log.args.gasUsed!); await pool.query( INSERT INTO inference_events (time, request_id, model_id, provider_id, event_type, data, block_num) VALUES (NOW(), $1, , $2, delivered, $3, $4), [ log.args.requestId!, log.args.provider!, JSON.stringify({ latency_ms: latencyMs, gas_used: gasUsed }), log.blockNumber, ] ); // Prometheus指标记录 const labels { model_id: unknown, provider_id: log.args.provider! as string }; requestLatency.observe(labels, latencyMs / 1000); requestCount.inc({ ...labels, status: success }); gasCostGauge.set(labels, gasUsed); } }, }); return () { unwatchRequest(); unwatchResult(); }; } // -------------------------------------------------------------------- // SLA评分计算加权滑动窗口 // 设计决策使用指数加权移动平均EWMA计算准确率 // 近期评分权重更高——如果节点最近开始提供低质量推理 // EWMA能在约12小时内反映出质量下降半衰期约6小时。 // -------------------------------------------------------------------- interface NodeSLA { providerId: string; modelId: string; avgLatency: number; // P50延迟ms p95Latency: number; // P95延迟ms accuracyScore: number; // 综合准确率0-100 costPerRequest: number; // 每请求平均Gas成本wei recentRequestCount: number; } async function calculateNodeSLA( providerId: string, modelId: string, windowHours: number 24 ): PromiseNodeSLA | null { const result await pool.query( WITH delivered AS ( SELECT (data-latency_ms)::numeric as latency_ms, (data-gas_used)::numeric as gas_used, time FROM inference_events WHERE provider_id $1 AND event_type delivered AND time NOW() - INTERVAL 1 hour * $3 ), ratings AS ( SELECT (data-score)::numeric as score, time FROM inference_events WHERE provider_id $1 AND event_type rated AND time NOW() - INTERVAL 1 hour * $3 ) SELECT COUNT(*) as total, PERCENTILE_CONT(0.50) WITHIN GROUP (ORDER BY d.latency_ms) as p50_lat, PERCENTILE_CONT(0.95) WITHIN GROUP (ORDER BY d.latency_ms) as p95_lat, AVG(d.gas_used) as avg_gas, AVG(r.score) as avg_score FROM delivered d LEFT JOIN ratings r ON r.time BETWEEN d.time - INTERVAL 1 minute AND d.time INTERVAL 10 minutes , [providerId, modelId, windowHours]); if (result.rows.length 0 || result.rows[0].total 0) return null; const row result.rows[0]; return { providerId, modelId, avgLatency: Number(row.p50_lat || 0), p95Latency: Number(row.p95_lat || 0), accuracyScore: Number(row.avg_score || 0) * 20, // 1-5 → 0-100 costPerRequest: Number(row.avg_gas || 0), recentRequestCount: Number(row.total), }; }四、仪表盘设计与告警策略Grafana 仪表盘布局建议一个高效的 SLA 仪表盘应当按从宏观到微观的信息层级排列Row 1 — 全局概览总请求量折线图24h、活跃节点数Stat Panel、全局平均延迟Gauge绿/黄/红三色阈值 200ms/500ms/1000ms。Row 2 — 按模型分组各模型的请求量分布饼图、各模型的 P95 延迟趋势折线图按模型分 Legend、模型级别的 Gas 成本对比柱状图。Row 3 — 按节点分组Top 10 节点延迟排行表格带迷你折线图、节点准确率热力图按时间轴展开颜色表示准确率高低、异常节点标记Stat Panel 显示 P95 延迟 阈值的节点数。Row 4 — 成本分析平均 Gas 成本的 7 天趋势、Gas 价格gwei与推理请求量的相关性散点图判断高 Gas 时用户是否减少推理请求。告警规则告警的粒度需要分层设计。全局级别的告警P95 延迟 阈值触发后需要进一步钻取到节点级别定位是哪个推理节点造成了整体延迟升高。建议在 Prometheus 中使用histogram_quantile按provider_id分组配合 Grafana 的 Heatmap Panel 快速识别异常节点。告警疲劳是另一个常见的工程问题。设定阈值过于敏感的后果是运维团队对告警脱敏。延迟告警应区分 WarningP95 1s可能来自正常抖动和 CriticalP95 3s明确异常准确率告警应限定最少样本量——节点刚上线只有 5 次推理、3 次被评 1 分就触发告警是误报应要求至少 50 次推理后才启用准确率告警。# prometheus-alerts.yml groups: - name: ai_inference_sla rules: # 延迟告警P95延迟超过1秒持续5分钟 - alert: HighInferenceLatency expr: histogram_quantile(0.95, rate(ai_inference_latency_seconds_bucket[5m])) 1 for: 5m labels: severity: warning annotations: summary: {{ $labels.provider_id }} P95延迟超过1秒 # 成本告警单请求Gas 300k wei约0.01 ETH 30 Gwei - alert: HighGasCost expr: ai_inference_gas_cost_wei 300000 for: 10m labels: severity: info annotations: summary: 推理服务{{ $labels.provider_id }} Gas成本异常升高 # 准确率下降EWMA准确率 50% 持续30分钟 - alert: LowAccuracy expr: ai_inference_accuracy_score 50 for: 30m labels: severity: critical annotations: summary: 节点{{ $labels.provider_id }}准确率低于50%建议审查五、总结链上 AI 服务的 SLA 可观测性不是一个简单的监控面板项目而是去中心化 AI 生态中信任机制的工程实现。本文设计的采集-聚合-可视化管线覆盖了延迟、准确率、成本三个维度的全链路数据并通过 TimescaleDB Prometheus 的双引擎架构平衡了历史分析的灵活性与实时告警的时效性。后续迭代方向包括将 SLA 指标写入链上合约通过 Chainlink Functions 或自定义 Oracle使节点质押的罚没逻辑与实时 SLA 数据挂钩引入分布式追踪如通过 TEE 内部的 OpenTelemetry 集成将单次推理请求从模型加载到结果返回的全链路延迟做分阶段测量以及建立跨节点、跨模型的 SLA 基准数据集为去中心化 AI 的质量评估提供公信力基线。
