你的 GPU 算力，到底被谁、用在了哪儿？GPUStack 用量统计上线，一张图说清楚
买了一堆 GPU，跑了一堆模型，月底老板问一句"这些卡到底用得值不值"，你能答上来吗？
如果答不上来，这篇文章你得看完。
GPUStack 全新的 用量统计（Usage） 功能正式上线了——Token 消耗、GPU/CPU 实例运行时长、存储容量占用，三类资源的消耗一目了然。谁在用、用了多少、花在了哪个模型上，再也不用靠猜。
一、为什么你需要它？
在多人、多模型共享一套 GPU 集群的场景里，最痛的从来不是"算力不够"，而是 "算力去哪了"：
- 想做成本核算，却拿不到按用户拆分的明细；
- 平台管理员想知道哪个模型最烧钱，只能翻日志；
- 业务方申请扩容，但谁也说不清现有资源的真实利用率。
GPUStack 用量统计就是来回答这些问题的。它把 采集 → 归集 → 可视化 全链路打通，让每一份算力消耗都有据可查。
二、五个标签页，覆盖全部消耗场景
打开左侧导航栏的 柱状图图标，进入 Usage 页面，你会看到五个标签页：
| 标签页 | 看什么 |
|---|---|
| Summary 总览 | 一屏看尽 Token、算力、存储三类资源 |
| Tokens | LLM Token 消耗，可按 模型 / 用户 / API Key 拆分 |
| GPU Instances | GPU/CPU 实例运行时长，可按 实例类型 / 实例 / 用户 拆分 |
| Storage | 存储容量占用，可按 存储卷 / 用户 拆分 |
| Resource Events | 资源生命周期审计日志，解释每个数字"从哪来" |
它到底在统计什么？
| 资源 | 计量时机 | 统计粒度 |
|---|---|---|
| Token | 推理请求经过网关被服务时 | 按天 |
| GPU/CPU 实例 | 实例处于"运行（计费）"阶段时；停止或删除后不再累计 | 按小时 |
| 存储 | 从创建到删除全程计量，无论是否被挂载使用 | 按小时 |
三、场景一：按用户查看，谁用了多少一清二楚
这是多人共享集群时最关心的能力。GPUStack 内置 Admin 和 User 两种角色：
- 管理员（Admin）：可以查看 所有用户 的用量，并通过 「按用户筛选」 控件下钻到任意成员；
- 普通用户（User）：能看到 自己 的用量，看不到别人的明细。
也就是说，平台管理员可以轻松回答："这个月某个用户消耗了多少 Token？谁占了最多的 GPU 小时？"——做成本核算、做配额规划，数据全都现成。
💡 每个标签页的明细表都支持 按用户分组（仅管理员可见），每个用户的账单清晰可见。
而对 普通用户 来说，打开 Usage 页面看到的就是一份 自己的专属账单：我这个月用了多少 Token、跑了多少 GPU 小时、占了多少存储，一清二楚——既能心里有数，也方便对照配额、避免超用。看不到别人的数据，权限边界自然分明，用起来也更安心。
四、场景二：按 API Key 拆分，看清哪个应用在烧钱
"按用户"是面向人的视角，"按 API Key"则是面向应用的视角——而这往往才是真正的消耗主体。
实践中，每个接入的应用、每条业务管线通常会用 独立的 API Key。Tokens 标签页支持 按 API Key 分组，于是你能直接看出：
- 是哪个 应用 / 集成方 在持续消耗 Token；
- 某条业务线的成本是不是突然飙升；
- 哪个 Key 几乎不用，可以回收。
把"人"和"应用"两个维度结合起来，成本归因就立体了。
五、场景三：不同种类的模型，消耗一目了然
集群里同时跑着大语言模型、向量模型、各种尺寸的开源模型？没问题。
Tokens 标签页 顶部直接给出核心指标：输入 / 输出 / 总 Token 数、API 请求数、使用的模型数。下方明细表可以按 模型 分组，逐个列出：
- 输入 Token（含 命中缓存的输入 Token，单独标注）
- 输出 Token
- 总 Token
- API 请求数
- 最近活跃时间
这样你一眼就能看出：哪个模型是"流量大户"，哪个模型申请了却几乎没人用，该下线还是该扩容，数据替你做决策。
📌 顺手验证缓存优化效果：表里的 Input Tokens Cached 单独标注了被提示词缓存命中的那部分输入。做了 prompt 缓存优化后，看这个数字的占比，就能直接量化到底省了多少输入 Token——优化有没有效，一目了然。
另外：即使模型已被删除，它的历史消耗仍会保留在表中（标记为 Deleted），照样计入总量——历史账目不丢。
六、场景四：GPU 算力使用情况，再也不是糊涂账
GPU Instances 标签页 把"实例运行"这件事拆得明明白白，关键在于它区分了两个容易混淆的指标：
| 指标 | 含义 |
|---|---|
| Instance Hours（实例小时） | 实例的运行墙钟时长，无论它装了几块卡 |
| GPU Hours（GPU 小时） | 加速卡运行时长 = 运行时长 × GPU 卡数 |
举个例子：一台 2 卡实例运行 1 小时 = 2 GPU 小时，但只算 1 个实例小时。
这一拆分让你能真正算清"卡的利用率"，而不是被实例数量误导。趋势图还能按 实例类型 / 实例 / 用户 分组，扩容前先看清现状。
⚙️ CPU 实例没有加速卡，只计入 Instance Hours，不计入 GPU Hours。
七、场景五：存储占用，连"闲置"也躲不掉
Storage 标签页 关注存储容量随时间的占用，核心指标是 GB-Days 和 GB-Hours（容量 × 持有时长），可按 存储卷 / 用户 拆分。
关键在于：存储 从创建到删除全程计量，与是否挂载无关。这意味着账目没有盲区——哪怕一个卷没挂载、没人读写，只要它还在，占用就如实计入 GB-Days，绝不会因为"没在用"就从账面上消失。
于是那些"建了就忘"的闲置卷无所遁形：按 GB-Days 占用排个序，占着大容量的卷一目了然，再对照它到底还有没有被实例使用，该清理的就清理。
八、场景六：揪出"僵尸资源"，省下白花的钱
集群跑久了，总会留下一堆没人记得的资源：早就没人调用的模型、忘了停的实例——它们不产出价值，却仍在占资源。
对于模型、GPU/CPU 实例这类 用的时候才计量 的资源，每个明细表都有一列 Last Active（最近活跃），记录它最后一次产生用量的时间。一旦停用就不再计量，Last Active 便定格在那一刻；那些 长期不活跃 的模型、停了忘删的实例立刻现形，清理起来有的放矢。
九、场景七：看趋势、做容量规划，扩容不再拍脑袋
总览和标签页都有 趋势图，配合可调的 粒度（小时 / 天 / 周 / 月），你能看到消耗随时间的变化曲线，而不只是一个静态总数。
- 用量是平稳还是在加速增长？
- 增长拐点出现在什么时候、和哪次业务上线对得上？
- 按当前趋势，现有算力还能撑多久？
把趋势看清楚，扩容决策就从"拍脑袋"变成"看曲线"。趋势图还能 按分组拆分，结构性变化一眼可见。
十、场景八：每个数字都有出处，Resource Events 还原资源的一生
前面每个标签页给的是 结论（花了多少 GPU 小时、多少 GB-Days），而 Resource Events 标签页 给的是这些数字的 来源——每个实例、每个存储卷的生命周期，被一条条事件如实记下。
按时间倒序，它就是一部资源编年史。一个实例的一生清清楚楚，彩色标签一眼分清：
🟢 Created 创建 → 🔵 Started 进入计量 → 🟠 Stopped 停止计量 → 🔴 Deleted 删除
于是：
- 对账溯源：某实例的 Instance Hours 为什么是这个数？看它 Started 到 Stopped 的区间就知道运行了多久，数字对得上账。
- 可筛查：按 日期 / 资源类型 / 事件类型 / 名称 一筛，"上周删了哪些卷""哪个实例被反复启停"立刻清楚。
- 解释不活跃：场景六里 Last Active 发现某实例不动了，来这儿一查——原来它哪天 Stopped、哪天被 Deleted，一目了然。
十一、让数据落地：一键导出，直接对账
看清楚还不够，数据得能拿出去用。
Tokens / GPU Instances / Storage 三个标签页都带 导出（下载图标）：先预览当前筛选后的明细，再下载下来。月度账单、财务对账、内部报表——拿到数据就能做，不用再让工程师手写脚本捞数。
十二、这些贴心细节，决定了它能不能用得放心
统一时区
所有标签页的时间——趋势分桶、最近活跃、事件时间——都按同一个 归集时区 显示，保证每个标签页的日历边界对齐。通过 GPUSTACK_USAGE_ROLLUP_TIMEZONE 环境变量配置，默认跟随服务器本地时区。
灵活的通用控件
日期范围（默认近 30 天）、按用户/模型/API Key 筛选、刷新、切换指标、分组、调整粒度，开箱即用。
数据保留与归档
Token、算力、存储的归集数据默认保留约 13 个月，之后由后台任务归档。保留窗口和归档计划均可通过 GPUSTACK_*_RETENTION_MONTHS、GPUSTACK_*_ARCHIVE_CRON 环境变量配置。
写在最后
算力很贵，但"看不清的算力"更贵。
GPUStack 用量统计让你的每一份 Token、每一个 GPU 小时、每一 GB 存储都变得 可量化、可追溯、可分摊。无论你是做成本核算的财务、规划容量的管理员，还是想证明 ROI 的业务负责人，它都能给你一个有数据支撑的答案。
现在就升级到最新版 GPUStack，打开 Usage 页面，看看你的算力到底花在了哪儿。
浙公网安备 33010602011771号