拓冰网站定制 
后端人工智能模型推理服务集群管理可观测性【免费下载链接】gpustackA GPU cluster manager for high-performance AI model serving (vLLM, SGLang) and on-demand SSH-accessible GPU instances.项目地址https://gitcode.com/gh_mirrors/gp/gpustack点击查看免费下载GPUStack 的Usage用量页面是面向集群运维与成本归因的统一资源计量入口它按时间维度汇总 LLM Token 消耗、GPU/CPU 实例运行时长与持久化存储容量并支持按用户、模型、API Key、实例类型等维度下钻。读完本文你将掌握 Usage 页面五个标签页的完整用法、全部指标口径、统一时区与数据保留策略并理解背后基于metered_usage、resource_events与独立采集器的计量实现原理可直接用于集群用量追踪、成本核算与容量规划。进入 Usage 页面在 GPUStack Web 界面左侧导航栏点击Usage柱状图图标即可进入。页面整体操作路径如下从左侧导航进入Usage页面选择标签页 ——Summary、Tokens、GPU Instances、Storage或Resource Events设置date range日期范围及其它筛选条件界定报表窗口。页面默认展示最近 30 天的数据你可以随时通过日期范围控件调整统计窗口。五个标签页各管什么标签页内容Summary用量总览一屏同时呈现 Token、计算、存储三类资源的概览TokensLLM Token 消耗可按模型 / 用户 / API Key 拆分GPU InstancesGPU/CPU 实例运行时长可按实例类型 / 实例 / 用户拆分Storage存储容量占用可按存储 / 用户拆分Resource Events支撑计算与存储数字的生命周期审计日志什么会被计量计量范围与粒度资源计量区间桶粒度Tokens推理请求经网关gateway被服务期间每日DailyGPU/CPU 实例实例处于 runningmetered阶段Stopped或已删除的实例不再累积每小时Hourly存储从创建到删除全程计量无论是否被挂载每小时Hourly从源码看这一设计对应两套独立的数据通道Token 用量走 metrics_collector.py 维护的model_usages每日汇总而实例与存储的按时计量统一落在 metered_usage.py 的metered_usage每小时聚合表 —— 该文件注释明确写道Tokens are NOT here两类来源在 Summary 层做并集。日汇总的 Token 数据因此没有小时粒度这是 Tokens 标签页只提供 Day/Week/Month 而 GPU Instances 与 Storage 提供 Hour/Day/Week/Month 的根本原因。可见性Admin 与 User 的权限差异GPUStack 内置两种角色 ——Admin与User详见 User ManagementAdmin可查看所有用户的用量并通过Filter by user按用户筛选控件收窄视图User只能查看自己的用量按用户拆分的明细不可用。在接口层这一规则由self/all两种 scope 实现普通用户请求all会被静默降级为self且self视图下按用户分组、按用户筛选都会被拒绝见 usage.py 中的_resolve_effective_scope与_check_permission。此外平台管理员在跨组织 All 视图下还可以额外按Organization组织分组与筛选以及使用用户组User Group筛选组会被展开为其直接用户成员。公共控件除Resource Events使用自己的筛选器外其余每个标签页共享以下控件Date range日期范围——报表窗口默认最近 30 天Filter by user按用户筛选——限定到特定用户仅 AdminTokens 标签页额外提供Filter by model按模型筛选与Filter by API key按 API Key 筛选Refresh刷新——按当前筛选条件重新拉取数据Metric指标——趋势图与 KPI 排序所依据的数值例如 GPU Hours 与 Instance Hours 二选一Group by分组依据——将趋势图按分组拆成多条序列例如按实例类型Granularity粒度——趋势桶的大小。GPU Instances 与 Storage 支持Hour / Day / Week / MonthTokens 仅支持Day / Week / MonthToken 是每日汇总没有小时桶Export导出下载图标Tokens / GPU Instances / Storage 可用——先预览当前筛选下的明细拆分再下载。指标定义指标含义Input Tokens提示词PromptTokenInput Cached Tokens是其中命中提示词缓存的部分Output Tokens生成的补全CompletionTokenTotal TokensInput OutputInstance Hours实例墙钟运行时长Σ(运行时间)与实例占用的显卡数量无关GPU Hours加速卡运行时长Σ(运行时间 × 显卡数量)。一台 2 卡实例运行 1 小时 2 GPU Hours但只有 1 Instance HourGB-Days存储的按时长占用容量(GB) × 持有天数GB-Hours与 GB-Days 同义按小时表达Active Instances / Active Storages / Active Users窗口内仍存活未Deleted的资源Last Active该资源产生用量的最近一个时间桶注意已删除资源仍保留其历史用量 —— 已删除的模型、实例或存储仍会出现在表格中标记为Deleted并计入合计但不再计入Active。这一点在metered_usage与model_usages的建模上体现得很彻底所有 id 列均为无外键设计删除主体不会把归属信息清空显示名以*_name快照随行保存见 metered_usage.py 与 usage.py 中的_identity_deleted。Summary一屏总览三类资源Summary 标签页纵向堆叠Tokens、Compute计算、Storage存储三个区块每个区块都包含一行核心统计数字、一个按类型拆分的环形图以及所选时间范围内的趋势图无需切换标签页即可快速掌握三类资源的整体情况。TokensLLM Token 消耗明细该标签页展示 LLM 推理产生的 Token 消耗。顶部 KPI 依次为Input / Output / Total Tokens、API RequestsAPI 请求数、Models Used使用的模型数。底部明细表支持三种分组视角Models模型——按模型展示Input Tokens / Input Cached Tokens / Output Tokens / Total Tokens、API Requests、Last ActiveUsers用户——按用户展示仅 AdminAPI Keys——按 API Key 展示。从实现上看Token 计量由网关侧的 usage 统计插件上报、服务器端聚合metrics_collector以 10 秒为周期将网关指标刷入model_usages每日汇总表与model_usage_details逐请求审计表metrics_collector.py。当网关上报不完整流中断、completedfalse且 token 字段为空时服务器会基于请求字节数与输出 chunk 数做估算补全估算系数由GPUSTACK_USAGE_ESTIMATED_BYTES_PER_INPUT_TOKEN默认 4CJK 密集场景可下调至 2与GPUSTACK_USAGE_ESTIMATED_TOKENS_PER_OUTPUT_CHUNK默认 1控制。GPU InstancesGPU/CPU 实例运行时长该标签页展示 GPU 与 CPU 实例的运行时长。KPI 为GPU Hours、Instance Hours、Active Instances、Active Users。图表指标可在GPU Hours与Instance Hours之间切换趋势图可按instance type实例类型、instance实例或user用户分组。明细表支持的分组视角Instance Types实例类型——按实例类型展示GPU Hours、Instance Hours、Active Instances、Last ActiveInstances实例——按单个实例展示Users用户——按用户展示仅 Admin。注意CPU 实例没有加速卡因此只计入Instance Hours不计入GPU Hours。Storage存储容量占用该标签页展示存储容量占用。KPI 为GB-Days、GB-Hours、Active Storages、Active Users。图表指标可在GB-Days与GB-Hours之间切换并按storage存储或user用户分组。明细表支持的分组视角Storage存储——按卷展示Type、Capacity、GB-Days、GB-Hours、Last ActiveUsers用户——按用户展示仅 Admin。注意存储从创建到删除全程计量、与是否挂载无关因此存在但闲置的存储仍会持续累积 GB-Days/GB-Hours。Resource Events用量背后的生命周期审计日志该标签页是计算与存储数字背后的生命周期审计日志 —— 每个与计量相关的一次状态迁移对应一行记录用于解释某个数字为何呈现为当前的样子。可用筛选条件日期范围、资源类型GPU Instance / Storage、事件类型以及资源名称的模糊搜索。从源码看事件类型包括驱动采集器状态机的生命周期事件 ——created、deleted、phase_to_metered进入计量阶段、phase_left_metered离开计量阶段—— 以及仅审计、不影响汇总的updated、attached、detached见 resource_events.py。两个采集器正是以事件日志而非独立检查点表为状态来源实例进入/离开计量阶段时开窗/关窗存储卷创建/删除时开窗/关窗见 resource_usage_collector.py 与 storage_usage_collector.py。统一时区让所有标签页对齐同一个日历Usage 页面上的所有日期与时间 —— 趋势桶、Last Active、资源事件时间 —— 都基于同一个可配置的rollup timezone汇总时区展示因此每个标签页都对齐在相同的日历边界上。它由服务端环境变量GPUSTACK_TIMEZONE控制兼容旧的GPUSTACK_USAGE_ROLLUP_TIMEZONE作为已弃用别名仍然生效默认取服务器的操作系统本地时区。详见 Environment Variables 中对时区作用范围与夏令时DST影响的说明。时区解析逻辑位于 rollup_tz.py依次尝试GPUSTACK_TIMEZONEIANA 名称如Asia/Shanghai→ OS 本地时区TZ//etc/localtime→ UTC 兜底并在调用时实时读取以便测试可覆盖。该时区同时作用于三处model_usages的每日 Token 汇总桶、GPU/存储的时间桶以及展示侧的 Last Active 与资源事件时间。文档对 DST 有两条明确提醒在 DST 切换附近事件的显示钟表时间可能落在与其所属桶不同的日历日DST 切换后重跑同一历史查询可能把旧行重新分桶偏移一小时导致结果随时间漂移非 DST 时区UTC、Asia/Shanghai等精确且不受影响。数据保留与归档Token、计算与存储的汇总数据约保留13 个月之后由后台任务迁移至归档表。保留窗口与归档计划均可通过GPUSTACK_*_RETENTION_MONTHS与GPUSTACK_*_ARCHIVE_CRON系列环境变量配置。完整的归档相关变量如下均作用于 Server见 Environment Variables环境变量默认值说明GPUSTACK_USAGE_DETAILS_RETENTION_MONTHS13model_usage_details逐请求审计表的保留窗口GPUSTACK_USAGE_DETAILS_ARCHIVE_CRON0 3 * * *逐请求审计归档任务的 CronUTCGPUSTACK_USAGE_DETAILS_ARCHIVE_BATCH_SIZE1000归档每次迁移的行数GPUSTACK_METERED_USAGE_RETENTION_MONTHS13metered_usage小时资源汇总的保留窗口GPUSTACK_METERED_USAGE_ARCHIVE_CRON0 4 * * *小时汇总归档任务的 CronUTCGPUSTACK_METERED_USAGE_ARCHIVE_BATCH_SIZE5000归档每次迁移的行数GPUSTACK_USAGE_EVENTS_RETENTION_MONTHS13resource_events生命周期审计日志的保留窗口GPUSTACK_USAGE_EVENTS_ARCHIVE_CRON30 3 * * *资源事件归档任务的 CronUTCGPUSTACK_USAGE_EVENTS_ARCHIVE_BATCH_SIZE5000归档每次迁移的行数归档机制为“热/冷”分层仪表盘只读热表审计场景直接读归档表归档表与热表保持完全相同的列结构迁移采用批量INSERT ... SELECT见 metered_usage.py 的MeteredUsageArchive。各归档任务仅在 leader 节点运行且服务器启动时会先执行一次归档不依赖 Cron 到达。深入原理统一计量框架如何工作理解了页面操作后值得看一下这套数字在底层是如何被精确、幂等地累积出来的。统一的metered_usage表。每个基于时间的资源GPU 实例、CPU 实例、持久卷以及未来新增类型都以(meter_key, resource_id, bucket_start, sku, sku_count)为自然键、每小时一行地累积到同一张表其中bucket_start是 UTC 小时桶quantity以该计量的规范整数单位存储更粗的日/周/月粒度在查询时通过date_trunc派生。注册一种新的时间型资源只需定义一个MeterDef并编写一个采集器无需改表结构见 metered_usage.py。两个计量器Meter。当前注册了两个instance.uptime秒由 GPU/CPU 实例发出与storage.capacityMiB·秒由持久卷发出。实例行以整机墙钟秒数计量、sku_count单独成列GPU 为加速卡数量切片卡为小数CPU 为基础规格单元数因此instance_hours SUM(quantity) / 3600 (meterinstance.uptime) gpu_hours SUM(quantity × sku_count) / 3600 (meterinstance.uptime, GPU only) gb_days SUM(quantity) / 1024 / 86400 (meterstorage.capacity)查询侧换算公式就写在 metered_usage.py 的文件头注释中。sku对实例而言是运行中实例类型的快照引用sha1:40hex可直接 join 回实例类型目录存储则是volume--kind--type形式。事件驱动的开窗/关窗 周期 tick。采集器从resource_events事件流获知生命周期迁移进入计量阶段时在内存中打开窗口并快照当时的计费形态离开计量阶段或删除时结算窗口同时每 300 秒GPUSTACK_RESOURCE_USAGE_TICK_SECONDS/GPUSTACK_STORAGE_USAGE_TICK_SECONDS默认 300下限 60跑一次 tick为长时间无状态迁移的实例/卷刷新“本小时至今”的时长。幂等与防重。每一行汇总记录都带settled_until高水位游标结算只累加游标之后的时间段因此事件重放、tick 重叠、服务重启、同小时内 stop→start 都不会重复计数。服务器重启后还会从事件日志重建内存中的开放窗口并从持久化的高水位续算见 resource_usage_collector.py 的_seed_settled_through。桶封存seal。一个完整度过的小时桶在“小时结束 宽限期”后被封存为不可变 —— 封存条件为now bucket_end grace宽限期由GPUSTACK_METERED_USAGE_SEAL_GRACE_SECONDS默认 900 秒控制须大于 tick 间隔以吸收迟到事件与时钟偏差见 metered_usage.py 的seal_due。封存后的桶可被信任为最终结果对已封存桶的迟到分段会被丢弃并告警。切片与分区卡的精确计费。软切片卡按 VRAM 百分比折算sku_count如 25% 切片计 0.25 卡硬件分区则按分区memoryMib与整卡 VRAM 的比值折算在分区份额尚无法确定时窗口不会被结算 —— 回退为整卡会最多多收 8 倍因此采集器宁可持有窗口等待份额解析见 resource_usage_collector.py 的_resolve_profile_share。实例类型查询失败时会在每个 tick 重试避免实例在剩余生命周期内静默掉出用量报表。接口层的验证保障。与报表配套的 API 层/usage路由提供了粒度、排序字段、分组维度的严格校验并支持page-1免分页拉取整条序列用于趋势图与导出无分页的拆分结果受GPUSTACK_USAGE_BREAKDOWN_MAX_NO_PAGINATION_ROWS默认 50000上限保护超限返回 HTTP 400 而非静默截断见 usage.py 与 usage.py。相关行为在 tests/routers/test_usage.py 与 tests/routes/test_resource_usage_api.py 中有大量测试覆盖包括时区桶、删除标记、组织分组、用户组筛选等边界场景。小结GPUStack 的 Usage 页面把 Token、算力与存储三类资源的计量统一到了同一套日历、同一组归因维度之下Admin 可全量下钻、普通用户只见自身统一时区保证跨标签页口径一致13 个月的保留期配合可配置的归档计划控制数据体积。底层则以metered_usage单一聚合表 事件驱动采集器 高水位游标 桶封存机制实现了精确、幂等、可审计的持续计量。无论是做模型用量监控、按用户/组织的成本分摊还是排查某个数字的成因Usage 页面及其背后的计量框架都能给出可追溯的答案。赞分享后端人工智能模型推理服务集群管理可观测性【免费下载链接】gpustackA GPU cluster manager for high-performance AI model serving (vLLM, SGLang) and on-demand SSH-accessible GPU instances.项目地址https://gitcode.com/gh_mirrors/gp/gpustack点击查看免费下载相关推荐AI NovelGenerator从零生成连贯长篇故事的完整指南AI NovelGenerator从零生成连贯长篇故事的完整指南 AI NovelGenerator 是一款基于大语言模型的小说生成工具专门解决 AI 写作人工智能大模型AI 应用AI 写作RAG桌面应用openai-agents-python 用量统计Usage完整指南从 Token 追踪、成本核算到检查点隔离openai agents python 用量统计Usage完整指南从 Token 追踪、成本核算到检查点隔离 本指南围绕 openai agents p人工智能AI AgentAgent 框架多智能体工具调用MCP Clientsruflo cost-analyst Agent 实战指南Token 用量追踪、USD 成本归因与多级预算治理ruflo cost analyst Agent 实战指南Token 用量追踪、USD 成本归因与多级预算治理 ruflo cost tracker 是 ru人工智能AI Agent多智能体Agent 编排Agent 记忆工具调用代码智能体MCP 服务AI 评测上一篇提升PT体验PT-depiler备份服务器功能详解与数据同步技巧下一篇如何快速搭建ESP32语音控制平台5分钟部署开源智能语音交互系统终极指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 GPUStack 资源用量追踪（Usage）实战指南：从 Token 计量到存储成本归因
后端人工智能模型推理服务集群管理可观测性【免费下载链接】gpustackA GPU cluster manager for high-performance AI model serving (vLLM, SGLang) and on-demand SSH-accessible GPU instances.项目地址https://gitcode.com/gh_mirrors/gp/gpustack点击查看免费下载GPUStack 的Usage用量页面是面向集群运维与成本归因的统一资源计量入口它按时间维度汇总 LLM Token 消耗、GPU/CPU 实例运行时长与持久化存储容量并支持按用户、模型、API Key、实例类型等维度下钻。读完本文你将掌握 Usage 页面五个标签页的完整用法、全部指标口径、统一时区与数据保留策略并理解背后基于metered_usage、resource_events与独立采集器的计量实现原理可直接用于集群用量追踪、成本核算与容量规划。进入 Usage 页面在 GPUStack Web 界面左侧导航栏点击Usage柱状图图标即可进入。页面整体操作路径如下从左侧导航进入Usage页面选择标签页 ——Summary、Tokens、GPU Instances、Storage或Resource Events设置date range日期范围及其它筛选条件界定报表窗口。页面默认展示最近 30 天的数据你可以随时通过日期范围控件调整统计窗口。五个标签页各管什么标签页内容Summary用量总览一屏同时呈现 Token、计算、存储三类资源的概览TokensLLM Token 消耗可按模型 / 用户 / API Key 拆分GPU InstancesGPU/CPU 实例运行时长可按实例类型 / 实例 / 用户拆分Storage存储容量占用可按存储 / 用户拆分Resource Events支撑计算与存储数字的生命周期审计日志什么会被计量计量范围与粒度资源计量区间桶粒度Tokens推理请求经网关gateway被服务期间每日DailyGPU/CPU 实例实例处于 runningmetered阶段Stopped或已删除的实例不再累积每小时Hourly存储从创建到删除全程计量无论是否被挂载每小时Hourly从源码看这一设计对应两套独立的数据通道Token 用量走 metrics_collector.py 维护的model_usages每日汇总而实例与存储的按时计量统一落在 metered_usage.py 的metered_usage每小时聚合表 —— 该文件注释明确写道Tokens are NOT here两类来源在 Summary 层做并集。日汇总的 Token 数据因此没有小时粒度这是 Tokens 标签页只提供 Day/Week/Month 而 GPU Instances 与 Storage 提供 Hour/Day/Week/Month 的根本原因。可见性Admin 与 User 的权限差异GPUStack 内置两种角色 ——Admin与User详见 User ManagementAdmin可查看所有用户的用量并通过Filter by user按用户筛选控件收窄视图User只能查看自己的用量按用户拆分的明细不可用。在接口层这一规则由self/all两种 scope 实现普通用户请求all会被静默降级为self且self视图下按用户分组、按用户筛选都会被拒绝见 usage.py 中的_resolve_effective_scope与_check_permission。此外平台管理员在跨组织 All 视图下还可以额外按Organization组织分组与筛选以及使用用户组User Group筛选组会被展开为其直接用户成员。公共控件除Resource Events使用自己的筛选器外其余每个标签页共享以下控件Date range日期范围——报表窗口默认最近 30 天Filter by user按用户筛选——限定到特定用户仅 AdminTokens 标签页额外提供Filter by model按模型筛选与Filter by API key按 API Key 筛选Refresh刷新——按当前筛选条件重新拉取数据Metric指标——趋势图与 KPI 排序所依据的数值例如 GPU Hours 与 Instance Hours 二选一Group by分组依据——将趋势图按分组拆成多条序列例如按实例类型Granularity粒度——趋势桶的大小。GPU Instances 与 Storage 支持Hour / Day / Week / MonthTokens 仅支持Day / Week / MonthToken 是每日汇总没有小时桶Export导出下载图标Tokens / GPU Instances / Storage 可用——先预览当前筛选下的明细拆分再下载。指标定义指标含义Input Tokens提示词PromptTokenInput Cached Tokens是其中命中提示词缓存的部分Output Tokens生成的补全CompletionTokenTotal TokensInput OutputInstance Hours实例墙钟运行时长Σ(运行时间)与实例占用的显卡数量无关GPU Hours加速卡运行时长Σ(运行时间 × 显卡数量)。一台 2 卡实例运行 1 小时 2 GPU Hours但只有 1 Instance HourGB-Days存储的按时长占用容量(GB) × 持有天数GB-Hours与 GB-Days 同义按小时表达Active Instances / Active Storages / Active Users窗口内仍存活未Deleted的资源Last Active该资源产生用量的最近一个时间桶注意已删除资源仍保留其历史用量 —— 已删除的模型、实例或存储仍会出现在表格中标记为Deleted并计入合计但不再计入Active。这一点在metered_usage与model_usages的建模上体现得很彻底所有 id 列均为无外键设计删除主体不会把归属信息清空显示名以*_name快照随行保存见 metered_usage.py 与 usage.py 中的_identity_deleted。Summary一屏总览三类资源Summary 标签页纵向堆叠Tokens、Compute计算、Storage存储三个区块每个区块都包含一行核心统计数字、一个按类型拆分的环形图以及所选时间范围内的趋势图无需切换标签页即可快速掌握三类资源的整体情况。TokensLLM Token 消耗明细该标签页展示 LLM 推理产生的 Token 消耗。顶部 KPI 依次为Input / Output / Total Tokens、API RequestsAPI 请求数、Models Used使用的模型数。底部明细表支持三种分组视角Models模型——按模型展示Input Tokens / Input Cached Tokens / Output Tokens / Total Tokens、API Requests、Last ActiveUsers用户——按用户展示仅 AdminAPI Keys——按 API Key 展示。从实现上看Token 计量由网关侧的 usage 统计插件上报、服务器端聚合metrics_collector以 10 秒为周期将网关指标刷入model_usages每日汇总表与model_usage_details逐请求审计表metrics_collector.py。当网关上报不完整流中断、completedfalse且 token 字段为空时服务器会基于请求字节数与输出 chunk 数做估算补全估算系数由GPUSTACK_USAGE_ESTIMATED_BYTES_PER_INPUT_TOKEN默认 4CJK 密集场景可下调至 2与GPUSTACK_USAGE_ESTIMATED_TOKENS_PER_OUTPUT_CHUNK默认 1控制。GPU InstancesGPU/CPU 实例运行时长该标签页展示 GPU 与 CPU 实例的运行时长。KPI 为GPU Hours、Instance Hours、Active Instances、Active Users。图表指标可在GPU Hours与Instance Hours之间切换趋势图可按instance type实例类型、instance实例或user用户分组。明细表支持的分组视角Instance Types实例类型——按实例类型展示GPU Hours、Instance Hours、Active Instances、Last ActiveInstances实例——按单个实例展示Users用户——按用户展示仅 Admin。注意CPU 实例没有加速卡因此只计入Instance Hours不计入GPU Hours。Storage存储容量占用该标签页展示存储容量占用。KPI 为GB-Days、GB-Hours、Active Storages、Active Users。图表指标可在GB-Days与GB-Hours之间切换并按storage存储或user用户分组。明细表支持的分组视角Storage存储——按卷展示Type、Capacity、GB-Days、GB-Hours、Last ActiveUsers用户——按用户展示仅 Admin。注意存储从创建到删除全程计量、与是否挂载无关因此存在但闲置的存储仍会持续累积 GB-Days/GB-Hours。Resource Events用量背后的生命周期审计日志该标签页是计算与存储数字背后的生命周期审计日志 —— 每个与计量相关的一次状态迁移对应一行记录用于解释某个数字为何呈现为当前的样子。可用筛选条件日期范围、资源类型GPU Instance / Storage、事件类型以及资源名称的模糊搜索。从源码看事件类型包括驱动采集器状态机的生命周期事件 ——created、deleted、phase_to_metered进入计量阶段、phase_left_metered离开计量阶段—— 以及仅审计、不影响汇总的updated、attached、detached见 resource_events.py。两个采集器正是以事件日志而非独立检查点表为状态来源实例进入/离开计量阶段时开窗/关窗存储卷创建/删除时开窗/关窗见 resource_usage_collector.py 与 storage_usage_collector.py。统一时区让所有标签页对齐同一个日历Usage 页面上的所有日期与时间 —— 趋势桶、Last Active、资源事件时间 —— 都基于同一个可配置的rollup timezone汇总时区展示因此每个标签页都对齐在相同的日历边界上。它由服务端环境变量GPUSTACK_TIMEZONE控制兼容旧的GPUSTACK_USAGE_ROLLUP_TIMEZONE作为已弃用别名仍然生效默认取服务器的操作系统本地时区。详见 Environment Variables 中对时区作用范围与夏令时DST影响的说明。时区解析逻辑位于 rollup_tz.py依次尝试GPUSTACK_TIMEZONEIANA 名称如Asia/Shanghai→ OS 本地时区TZ//etc/localtime→ UTC 兜底并在调用时实时读取以便测试可覆盖。该时区同时作用于三处model_usages的每日 Token 汇总桶、GPU/存储的时间桶以及展示侧的 Last Active 与资源事件时间。文档对 DST 有两条明确提醒在 DST 切换附近事件的显示钟表时间可能落在与其所属桶不同的日历日DST 切换后重跑同一历史查询可能把旧行重新分桶偏移一小时导致结果随时间漂移非 DST 时区UTC、Asia/Shanghai等精确且不受影响。数据保留与归档Token、计算与存储的汇总数据约保留13 个月之后由后台任务迁移至归档表。保留窗口与归档计划均可通过GPUSTACK_*_RETENTION_MONTHS与GPUSTACK_*_ARCHIVE_CRON系列环境变量配置。完整的归档相关变量如下均作用于 Server见 Environment Variables环境变量默认值说明GPUSTACK_USAGE_DETAILS_RETENTION_MONTHS13model_usage_details逐请求审计表的保留窗口GPUSTACK_USAGE_DETAILS_ARCHIVE_CRON0 3 * * *逐请求审计归档任务的 CronUTCGPUSTACK_USAGE_DETAILS_ARCHIVE_BATCH_SIZE1000归档每次迁移的行数GPUSTACK_METERED_USAGE_RETENTION_MONTHS13metered_usage小时资源汇总的保留窗口GPUSTACK_METERED_USAGE_ARCHIVE_CRON0 4 * * *小时汇总归档任务的 CronUTCGPUSTACK_METERED_USAGE_ARCHIVE_BATCH_SIZE5000归档每次迁移的行数GPUSTACK_USAGE_EVENTS_RETENTION_MONTHS13resource_events生命周期审计日志的保留窗口GPUSTACK_USAGE_EVENTS_ARCHIVE_CRON30 3 * * *资源事件归档任务的 CronUTCGPUSTACK_USAGE_EVENTS_ARCHIVE_BATCH_SIZE5000归档每次迁移的行数归档机制为“热/冷”分层仪表盘只读热表审计场景直接读归档表归档表与热表保持完全相同的列结构迁移采用批量INSERT ... SELECT见 metered_usage.py 的MeteredUsageArchive。各归档任务仅在 leader 节点运行且服务器启动时会先执行一次归档不依赖 Cron 到达。深入原理统一计量框架如何工作理解了页面操作后值得看一下这套数字在底层是如何被精确、幂等地累积出来的。统一的metered_usage表。每个基于时间的资源GPU 实例、CPU 实例、持久卷以及未来新增类型都以(meter_key, resource_id, bucket_start, sku, sku_count)为自然键、每小时一行地累积到同一张表其中bucket_start是 UTC 小时桶quantity以该计量的规范整数单位存储更粗的日/周/月粒度在查询时通过date_trunc派生。注册一种新的时间型资源只需定义一个MeterDef并编写一个采集器无需改表结构见 metered_usage.py。两个计量器Meter。当前注册了两个instance.uptime秒由 GPU/CPU 实例发出与storage.capacityMiB·秒由持久卷发出。实例行以整机墙钟秒数计量、sku_count单独成列GPU 为加速卡数量切片卡为小数CPU 为基础规格单元数因此instance_hours SUM(quantity) / 3600 (meterinstance.uptime) gpu_hours SUM(quantity × sku_count) / 3600 (meterinstance.uptime, GPU only) gb_days SUM(quantity) / 1024 / 86400 (meterstorage.capacity)查询侧换算公式就写在 metered_usage.py 的文件头注释中。sku对实例而言是运行中实例类型的快照引用sha1:40hex可直接 join 回实例类型目录存储则是volume--kind--type形式。事件驱动的开窗/关窗 周期 tick。采集器从resource_events事件流获知生命周期迁移进入计量阶段时在内存中打开窗口并快照当时的计费形态离开计量阶段或删除时结算窗口同时每 300 秒GPUSTACK_RESOURCE_USAGE_TICK_SECONDS/GPUSTACK_STORAGE_USAGE_TICK_SECONDS默认 300下限 60跑一次 tick为长时间无状态迁移的实例/卷刷新“本小时至今”的时长。幂等与防重。每一行汇总记录都带settled_until高水位游标结算只累加游标之后的时间段因此事件重放、tick 重叠、服务重启、同小时内 stop→start 都不会重复计数。服务器重启后还会从事件日志重建内存中的开放窗口并从持久化的高水位续算见 resource_usage_collector.py 的_seed_settled_through。桶封存seal。一个完整度过的小时桶在“小时结束 宽限期”后被封存为不可变 —— 封存条件为now bucket_end grace宽限期由GPUSTACK_METERED_USAGE_SEAL_GRACE_SECONDS默认 900 秒控制须大于 tick 间隔以吸收迟到事件与时钟偏差见 metered_usage.py 的seal_due。封存后的桶可被信任为最终结果对已封存桶的迟到分段会被丢弃并告警。切片与分区卡的精确计费。软切片卡按 VRAM 百分比折算sku_count如 25% 切片计 0.25 卡硬件分区则按分区memoryMib与整卡 VRAM 的比值折算在分区份额尚无法确定时窗口不会被结算 —— 回退为整卡会最多多收 8 倍因此采集器宁可持有窗口等待份额解析见 resource_usage_collector.py 的_resolve_profile_share。实例类型查询失败时会在每个 tick 重试避免实例在剩余生命周期内静默掉出用量报表。接口层的验证保障。与报表配套的 API 层/usage路由提供了粒度、排序字段、分组维度的严格校验并支持page-1免分页拉取整条序列用于趋势图与导出无分页的拆分结果受GPUSTACK_USAGE_BREAKDOWN_MAX_NO_PAGINATION_ROWS默认 50000上限保护超限返回 HTTP 400 而非静默截断见 usage.py 与 usage.py。相关行为在 tests/routers/test_usage.py 与 tests/routes/test_resource_usage_api.py 中有大量测试覆盖包括时区桶、删除标记、组织分组、用户组筛选等边界场景。小结GPUStack 的 Usage 页面把 Token、算力与存储三类资源的计量统一到了同一套日历、同一组归因维度之下Admin 可全量下钻、普通用户只见自身统一时区保证跨标签页口径一致13 个月的保留期配合可配置的归档计划控制数据体积。底层则以metered_usage单一聚合表 事件驱动采集器 高水位游标 桶封存机制实现了精确、幂等、可审计的持续计量。无论是做模型用量监控、按用户/组织的成本分摊还是排查某个数字的成因Usage 页面及其背后的计量框架都能给出可追溯的答案。赞分享后端人工智能模型推理服务集群管理可观测性【免费下载链接】gpustackA GPU cluster manager for high-performance AI model serving (vLLM, SGLang) and on-demand SSH-accessible GPU instances.项目地址https://gitcode.com/gh_mirrors/gp/gpustack点击查看免费下载相关推荐AI NovelGenerator从零生成连贯长篇故事的完整指南AI NovelGenerator从零生成连贯长篇故事的完整指南 AI NovelGenerator 是一款基于大语言模型的小说生成工具专门解决 AI 写作人工智能大模型AI 应用AI 写作RAG桌面应用openai-agents-python 用量统计Usage完整指南从 Token 追踪、成本核算到检查点隔离openai agents python 用量统计Usage完整指南从 Token 追踪、成本核算到检查点隔离 本指南围绕 openai agents p人工智能AI AgentAgent 框架多智能体工具调用MCP Clientsruflo cost-analyst Agent 实战指南Token 用量追踪、USD 成本归因与多级预算治理ruflo cost analyst Agent 实战指南Token 用量追踪、USD 成本归因与多级预算治理 ruflo cost tracker 是 ru人工智能AI Agent多智能体Agent 编排Agent 记忆工具调用代码智能体MCP 服务AI 评测上一篇提升PT体验PT-depiler备份服务器功能详解与数据同步技巧下一篇如何快速搭建ESP32语音控制平台5分钟部署开源智能语音交互系统终极指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考