华为云 DLI：用 SQL 看清 AI 应用的调用成本

摘要： AI 应用上线后，团队不仅要关注回答质量，还需要了解不同业务、模型和调用链路的资源消耗。本文以企业知识助手为例，介绍如何结合华为云数据湖探索 DLI 与 OBS，对模型调用记录进行分析，找出高成本环节，并建立可核对的成本统计口径。

一个企业知识助手，可能同时提供文档总结、知识问答和报告生成。随着用户增加，团队希望回答几个具体问题：哪个功能消耗最多？成本上涨来自用户增长，还是单次请求变长？失败重试有没有产生额外开销？

要回答这些问题，可以先建立一份结构化调用记录，再用 SQL 按业务和模型进行汇总。

华为云数据湖探索 DLI 提供 Serverless 数据处理与分析能力，支持标准 SQL、Spark SQL 等方式查询数据，用户无需自行维护分析服务器，也可以对 OBS 中的数据开展分析。(support.huaweicloud.cn)

先统一记录，再讨论成本

以下是一套应用侧的设计示例。

每次模型调用结束后，记录所属应用、模型名称、输入与输出 Token 数、耗时、状态和估算费用。同时保留两个标识：一个标识用户发起的逻辑请求，另一个标识具体调用尝试。

这样，一次用户请求发生两次重试时，就可以同时统计“用户提交了多少任务”和“后台实际调用了多少次模型”。

日志采集、费用估算与字段设计需要由应用实现。DLI 承担后续查询计算，不能自动补齐业务没有记录的信息。

尤其要区分“用量为零”和“用量未知”。如果接口超时，应用没有获得完整用量信息，建议保留为空并记录原因，避免把未知消耗直接当成零。

把调用记录接入 DLI

可以定期将整理后的调用记录写入 OBS，再在 DLI 中建立对应的数据表。DLI 支持 OBS 表，其数据保存在用户的 OBS 桶中；DLI 内部表则将数据保存在服务内部，两者的数据存储位置不同。(support.huaweicloud.cn)

如果采用数据导入方式，官方文档列出了 CSV、Parquet、ORC、JSON 和 Avro 等支持格式。实际接入时，应统一字段类型，特别是时间、金额和可能缺失的用量字段。(support.huaweicloud.cn)

对于这个示例，可以先按天整理数据，建立一张名为 ai_call_logs 的表，再开展日常汇总。

用一条 SQL 找到主要消耗来源

假设表中已经按“调用尝试”去重，estimated_cost 表示应用计算的估算费用，下面可以按应用和模型统计一天的调用情况：

-- 示例字段和表名需要按实际数据结构调整
SELECT
    app_id,
    model_id,
    COUNT(*) AS attempt_count,
    COUNT(estimated_cost) AS cost_known_count,
    SUM(estimated_cost) AS estimated_total_cost,
    AVG(latency_ms) AS avg_latency_ms
FROM ai_call_logs
WHERE dt = '2026-11-11'
GROUP BY app_id, model_id
ORDER BY estimated_total_cost DESC;

这里保留 cost_known_count，是为了让读报表的人知道，有多少条调用具备可计算的费用信息。若总调用次数很多、已知费用记录却很少，就应先补齐数据，再判断成本变化。

这类分组和聚合分析，可以通过 DLI 提供的 SQL 查询能力实现。(support.huaweicloud.cn)

从统计结果回到业务链路

发现某个功能费用偏高后，可以继续按提示词版本、文档长度或重试次数细分。

例如，若报告生成的输入量持续增加，可以检查是否重复拼接历史内容；若重试占比升高，可以核查超时设置与错误分类。优化方案仍需通过实际数据验证，不能仅凭某项指标偏高就直接更换模型。

还可以为每个业务定义“成功任务的平均估算成本”：将该业务的全部调用消耗，包括失败和重试，除以成功完成的任务数。这比只观察单次模型调用，更接近完成一项业务实际付出的代价。

让估算结果能够核对

建议保存费用计算所用的规则版本、生效时间和币种，并定期与服务商账单核对。不同服务的计费项目可能不同，本文示例中的估算字段不代表最终结算金额。

上线前，可以挑选一小批已知调用记录，人工核对去重、重试归属、缺失值和汇总结果。只有统计口径可信，成本变化才有解释价值。

DLI 提供了集中分析调用数据的入口。配合清晰的业务标识和完整记录，团队就能把“费用涨了”进一步拆解为具体原因，为提示词调整、调用流程优化和资源规划提供依据。