自托管语音 AI 的难点不只在部署模型，还在于运营数据的归属。推理服务虽然运行在自己的 Amazon SageMaker AI 环境中，但容量规划、成本核算所需的账单、调用量和单卡 GPU 指标，往往封闭在供应商容器内。Deepgram 针对 SageMaker AI 提供的 Enhanced Metrics，目标正是把这些数据直接落到用户自己的 Amazon CloudWatch 账户。
为什么这比一张供应商控制台更重要
语音识别、语音合成等工作负载通常有明显的流量波峰：客服高峰、批量转写任务、直播转录都可能在短时间内推高 GPU 使用率。仅看到实例是否存活，无法回答几个关键运营问题：
- 某个端点实际处理了多少语音用量，增长来自哪个业务时段。
- GPU 是因请求积压而饱和，还是模型进程未有效利用已购买的算力。
- 某次成本异常是实例规模扩大、运行时长增加，还是特定使用量变化导致。
- 应该扩容端点、调整自动伸缩阈值，还是拆分不同优先级的工作负载。
将计费、使用量和每 GPU 指标写入同一个 CloudWatch 账户后，平台团队可以把它们与 SageMaker endpoint 指标、ALB 请求量、队列深度、业务订单量放在同一套仪表板和告警体系中。重要的是数据控制权：告警、保留周期、跨账户查询和财务导出都由云账户的现有治理规则管理。
三类指标如何形成运营闭环
从摘要披露的信息看，Enhanced Metrics 覆盖计费、使用量和单 GPU 指标。这三类数据解决的问题不同，组合起来才有决策价值。
使用量指标适合描述服务需求。它可以用于识别高峰时段、按环境或端点分摊消耗，并与上游请求量交叉验证。若请求数增加而语音用量没有同步变化，可能意味着短音频占比提高，或者请求统计口径需要重新确认。
每 GPU 指标适合诊断计算资源。集群平均值容易掩盖单卡热点：一个 GPU 接近饱和、其余 GPU 空闲时，问题可能是并发分配、批处理策略或模型进程布局，而不一定是机器数量不足。
计费指标则把技术信号接到财务约束上。将成本变化与使用量、GPU 利用率放在同一时间轴，可以避免把“花得更多”简单归因为“业务变多”。例如，使用量平稳但成本上升，应优先检查实例运行时间、部署副本和资源闲置情况。
可以这样实践：用 CloudWatch Dashboard 对齐需求、算力和成本
具体 metric namespace、metric name 与维度应以 Deepgram 在 SageMaker AI 部署后实际写入 CloudWatch 的定义为准。下面的示例假设指标位于 Deepgram/SageMaker 命名空间，分别名为 UsageSeconds、BilledAmount 和 GpuUtilization；部署前请在 CloudWatch Metrics 页面或通过 CLI 替换为实际名称、单位和维度。
将下面内容保存为 deepgram-observability-dashboard.json。示例按 EndpointName 聚合用量与费用，并按 GpuId 展示单卡利用率：
{
"widgets": [
{
"type": "metric",
"x": 0,
"y": 0,
"width": 12,
"height": 6,
"properties": {
"title": "Deepgram usage and billed amount",
"view": "timeSeries",
"region": "us-east-1",
"stat": "Sum",
"period": 300,
"metrics": [
[ "Deepgram/SageMaker", "UsageSeconds", "EndpointName", "speech-prod", { "label": "Usage seconds", "yAxis": "left" } ],
[ ".", "BilledAmount", ".", ".", { "label": "Billed amount", "yAxis": "right" } ]
],
"yAxis": {
"left": { "label": "Seconds" },
"right": { "label": "Cost" }
}
}
},
{
"type": "metric",
"x": 12,
"y": 0,
"width": 12,
"height": 6,
"properties": {
"title": "GPU utilization by device",
"view": "timeSeries",
"region": "us-east-1",
"stat": "Average",
"period": 60,
"metrics": [
[ "Deepgram/SageMaker", "GpuUtilization", "EndpointName", "speech-prod", "GpuId", "0", { "label": "GPU 0" } ],
[ "...", "1", { "label": "GPU 1" } ]
],
"yAxis": {
"left": { "min": 0, "max": 100, "label": "Percent" }
}
}
}
]
}
创建或更新 Dashboard：
aws cloudwatch put-dashboard \
--dashboard-name deepgram-sagemaker-observability \
--dashboard-body file://deepgram-observability-dashboard.json \
--region us-east-1
再用 CLI 检查指标实际携带的维度，避免在 Dashboard 中猜测维度名：
aws cloudwatch list-metrics \
--namespace Deepgram/SageMaker \
--region us-east-1
生产环境还应将 speech-prod 换成真实 SageMaker endpoint 标识，并为开发、预发布和生产环境使用可筛选的维度或标签。若费用指标并非实时累计值，也需要确认其发布延迟与统计方式，避免把短周期波动误解为最终账单。
告警不要只盯 GPU 百分比
一个常见误区是为 GPU 利用率设置单一阈值，然后把它当作扩缩容依据。高利用率可能意味着健康的高吞吐，也可能意味着队列已开始堆积；低利用率可能是流量低，也可能是模型进程、分片或批处理没有正确使用 GPU。
可以把 GPU 指标与使用量变化组合成分层告警：持续高 GPU 利用率时通知服务负责人；高利用率同时伴随请求延迟或队列深度上升时，再触发扩容或事件响应。成本告警则更适合按日、按月预算或相对于历史基线设置，而不是对每一分钟的费用变化报警。
下面是一个可改造的 CloudWatch Alarm 示例。它假设 GpuUtilization 为百分比，连续 15 分钟平均值高于 85 时进入告警状态；SNS Topic ARN 和指标维度必须替换为实际值。
aws cloudwatch put-metric-alarm \
--alarm-name deepgram-speech-prod-gpu-high \
--alarm-description "Investigate sustained Deepgram GPU saturation" \
--namespace Deepgram/SageMaker \
--metric-name GpuUtilization \
--dimensions Name=EndpointName,Value=speech-prod \
--statistic Average \
--period 300 \
--evaluation-periods 3 \
--datapoints-to-alarm 3 \
--threshold 85 \
--comparison-operator GreaterThanThreshold \
--treat-missing-data notBreaching \
--alarm-actions arn:aws:sns:us-east-1:123456789012:platform-alerts \
--region us-east-1
接入前的检查清单
Enhanced Metrics 的价值不在于增加更多图表，而在于让容量、性能和成本讨论使用同一份可审计数据。接入时可以检查以下事项：
- 确认所有指标的命名空间、单位、发布频率、延迟和维度语义。
- 将 endpoint、环境、区域或租户维度与内部成本分摊口径对齐。
- 在上线前验证无流量、峰值流量、扩容和容器重启时的指标行为。
- 为 Dashboard 与告警设置 IAM 最小权限，并明确谁可以查看可能涉及使用信息的指标。
- 保留一段历史数据后，再根据使用量、单 GPU 利用率和成本的关联关系调整扩缩容策略。
当这些指标进入自己的 CloudWatch 账户，语音 AI 就不再是基础设施监控中的黑箱。团队可以用熟悉的 AWS 工具，把实际消耗和实际算力状态纳入日常运维与成本治理。