你的 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 页面，看看你的算力到底花在了哪儿。