大模型推理成本看板的搭建方法

围绕 vLLM 的 /metrics 与 DCGM Exporter 的 GPU 指标，说明如何采集模型与部署版本，用 Prometheus 和 Grafana 建立面板，并按服务映射部署成本记录。

搭建大模型推理成本看板，应先采集 vLLM OpenAI-compatible API server 的 /metrics 端点和 DCGM Exporter 默认 :9400 的 GPU /metrics 端点，再把请求、Token、缓存与 GPU 指标按时间保存，并映射到服务费用。在算力租赁场景中，还要把计费数量、单价、其他账单行和调整记录放进同一核对表，否则资源利用率不能直接回答“这个服务花了多少”。

搭建前先固定三类记录

先给每次部署固定服务名、模型名、部署版本、GPU 资源标识和账单周期。模型与版本应作为部署元数据记录，不要从面板数值反推。

用量记录：Prometheus 查询窗口的起止时间、counter 增量和 histogram 查询结果。
资源记录：由部署配置补充 GPU 资源标识、对应实例及数据缺口。
费用记录：账单行名称、计费数量、单价、金额和调整行。

不要把供应商金额写死在模板中。公开定价页、报价单或账单没有给出的数值，应继续向实际供应商确认，不能自行推算。

接通 Prometheus 采集链

按 Prometheus 的入门配置，采集目标应列在 scrape_configs 下，并使用 job_name 与 static_configs.targets 标识。可按下面的结构配置：

global:
  scrape_interval: 15s

scrape_configs:
  - job_name: 'YOUR_VALUE'
    static_configs:
      - targets: [ 'YOUR_VALUE' ]

这里的 15s 是入门配置采用的抓取间隔，job 可以覆盖它，并不代表账单周期。把 YOUR_VALUE 替换为实际可达地址；本机核验 DCGM Exporter 时可使用 localhost:9400，部署在远程主机时则应填写对应地址。

Prometheus 可按文档中的命令启动：

./prometheus --config.file=prometheus.yml

数据库默认保存在 ./data。启动后，应确认配置中的采集地址与实际提供的 /metrics 端点一致，再检查查询中是否出现对应 series。

排列推理与 GPU 核心面板

Grafana 对 dashboard 的定义是由多个 panel 组成的视图，因此可把资源状态、请求压力、时延、Token 和费用分别排成独立面板。

按 vLLM 的 Production Metrics 文档，建议至少保留以下指标：

请求与缓存：vllm:num_requests_running、vllm:num_requests_waiting 和 vllm:kv_cache_usage_perc。
时延与排队：vllm:time_to_first_token_seconds、vllm:e2e_request_latency_seconds 和 vllm:request_queue_time_seconds。
工作量与结果：vllm:prompt_tokens、vllm:generation_tokens、vllm:num_preemptions、vllm:prefix_cache_hits 和 vllm:request_success。

gauge 用于观察当前状态，counter 则应在相同账单窗口内取增量。需要计算 classic histogram 分位数时，按 Prometheus 查询函数文档，聚合过程必须把 le 保留在 by 子句中。官方给出的 P90 查询示例是：

histogram_quantile(0.9, sum by (job, le) (rate(http_request_duration_seconds_bucket[10m])))

这是通用示例，不是 vLLM 指标名；实际面板应选择自身暴露的 histogram bucket series。

把算力租赁账单映射到服务费用

到实际供应商当前的定价页、报价单或账单中，逐项读取账单周期、时区、资源标识、计费行名称、计费数量和单价。基础资源按“数量乘单价”计算，账单中单独列出的其他金额也应加入；不要预设某个项目一定免费。共享 GPU 或共享实例还必须提前写明分摊规则。

可使用以下计算模板：

INFERENCE_COST
= SUM(YOUR_BILLED_QUANTITY * YOUR_UNIT_PRICE)
+ SUM(YOUR_OTHER_BILL_AMOUNT)

SERVICE_COST
= YOUR_DIRECT_COST
+ YOUR_SHARED_COST * YOUR_ALLOCATION_RATIO

COST_PER_SUCCESS
= SERVICE_COST / YOUR_SUCCESSFUL_REQUEST_INCREMENT

COST_PER_GENERATION_TOKEN
= SERVICE_COST / YOUR_GENERATION_TOKEN_INCREMENT

成功请求增量和生成 Token 增量，应取 vllm:request_success 与 vllm:generation_tokens 在同一账单窗口内的 counter 增量。共享费用没有明确规则时，不要随意填写分摊比例，否则同一份用量会产生不同的服务成本。

验证结果与排查常见错误

先使用 DCGM Exporter 文档给出的命令检查 GPU 指标端点：

curl localhost:9400/metrics

随后检查 vLLM 的 /metrics 页面是否包含目录中的指标名称，Prometheus 是否已采集这些 series，最后确认 Grafana 面板能够按服务、模型和部署版本筛选。

常见错误包括：把 Prometheus 的抓取间隔当作账单粒度；把 gauge 当作 counter 累计；计算 histogram 分位数时遗漏 le；用量窗口与账单周期或时区不一致；以及共享费用没有记录分摊依据。最后用 INFERENCE_COST 与账单逐项核对，不要只用 GPU 利用率推算费用。

本文步骤依据正文链接的官方文档整理，使用前应按当前版本核对。