你的 GPU 算力,到底被谁、用在了哪儿?GPUStack 用量统计上线,一张图说清楚

你的 GPU 算力,到底被谁、用在了哪儿?GPUStack 用量统计上线,一张图说清楚 买了一堆 GPU跑了一堆模型月底老板问一句这些卡到底用得值不值你能答上来吗如果答不上来这篇文章你得看完。GPUStack 全新的用量统计Usage功能正式上线了——Token 消耗、GPU/CPU 实例运行时长、存储容量占用三类资源的消耗一目了然。谁在用、用了多少、花在了哪个模型上再也不用靠猜。一、为什么你需要它在多人、多模型共享一套 GPU 集群的场景里最痛的从来不是算力不够而是“算力去哪了”想做成本核算却拿不到按用户拆分的明细平台管理员想知道哪个模型最烧钱只能翻日志业务方申请扩容但谁也说不清现有资源的真实利用率。GPUStack 用量统计就是来回答这些问题的。它把采集 → 归集 → 可视化全链路打通让每一份算力消耗都有据可查。二、五个标签页覆盖全部消耗场景打开左侧导航栏的柱状图图标进入 Usage 页面你会看到五个标签页标签页看什么Summary 总览一屏看尽 Token、算力、存储三类资源TokensLLM Token 消耗可按 模型 / 用户 / API Key 拆分GPU InstancesGPU/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总 TokenAPI 请求数最近活跃时间这样你一眼就能看出哪个模型是流量大户哪个模型申请了却几乎没人用该下线还是该扩容数据替你做决策。顺手验证缓存优化效果表里的Input Tokens Cached单独标注了被提示词缓存命中的那部分输入。做了 prompt 缓存优化后看这个数字的占比就能直接量化到底省了多少输入 Token——优化有没有效一目了然。另外即使模型已被删除它的历史消耗仍会保留在表中标记为Deleted照样计入总量——历史账目不丢。六、场景四GPU 算力使用情况再也不是糊涂账GPU Instances 标签页把实例运行这件事拆得明明白白关键在于它区分了两个容易混淆的指标指标含义Instance Hours实例小时实例的运行墙钟时长无论它装了几块卡GPU HoursGPU 小时加速卡运行时长 运行时长 × 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 页面看看你的算力到底花在了哪儿。