监控 DeepSeek API 的 QPS 和 Token 消耗，最稳妥的方式是结合官方控制台的账单数据与客户端的请求日志统计。

快速处理思路

DeepSeek API 兼容 OpenAI 格式，每次请求的响应体中通常包含 usage 字段，可直接获取本次消耗的 Token 数。QPS（每秒请求数）并非接口直接返回的指标，需要在客户端或网关层通过记录请求时间戳自行统计。若遇到限流，接口会返回 HTTP 429 状态码。

为什么会这样

API 服务商通常只负责计量单次请求的资源消耗（Token），而 QPS 是客户端发起请求的频率指标，取决于你的业务逻辑和并发控制。分开监控的原因在于：Token 消耗直接关联成本，QPS 关联接口稳定性。公开资料中没有看到可靠的量化数据说明具体的限流阈值，这通常取决于账户等级和具体模型，需以实际测试和控制台提示为准。

分步处理

第一步：确认控制台数据可见性
登录 DeepSeek 开放平台控制台，查看“用量统计”或“账单”页面。确认当前 API Key 是否有权限查看历史消耗记录。这是核对总账的唯一权威来源。

第二步：客户端埋点记录
在调用 API 的代码逻辑中，增加日志记录。重点捕获以下信息：

• 请求开始与结束的时间戳（用于计算 QPS）
• 响应体中的 usage.prompt_tokens 和 usage.completion_tokens
• HTTP 状态码（重点关注 429）

示例逻辑（伪代码）：

start_time = now()
response = call_api()
end_time = now()
tokens = response.usage.total_tokens
log(time=start_time, tokens=tokens, status=response.code)

第三步：设置告警阈值
根据业务预算，在日志监控系统中设置阈值。例如：每分钟 Token 消耗超过预期值，或连续出现 429 错误时触发告警。不要依赖单一请求的耗时，要关注单位时间内的累积量。

怎么验证是否生效

1. 日志核对
查询本地日志系统，确认是否能统计出每分钟的请求次数和 Token 总和。

2. 控制台比对
等待控制台数据更新（通常有延迟），将本地统计的当日总 Token 数与控制台账单进行比对。允许存在少量误差，但数量级应一致。

3. 限流测试
在测试环境尝试高频请求，观察是否收到 429 状态码，并确认日志是否正确记录了该错误类型。

常见坑

1. 流式响应统计遗漏
如果使用 Stream 模式，Token 可能分多次返回。确保客户端逻辑是累加所有片段的 usage 数据，而不是只取最后一次。

2. 时区不一致
本地日志时间与控制台账单时间可能存在时区差异，核对数据时务必统一转换为 UTC 或同一时区。

3. 重试机制导致重复计数
若代码中有自动重试逻辑，失败后重试的请求也会消耗 Token。统计成本时应包含重试消耗，但计算业务 QPS 时需区分有效请求与重试请求。

参考来源

• DeepSeek 开放平台，控制台用量统计页面
• OpenAI API 文档，Usage 字段说明（作为兼容格式参考）