用途：在 CoreWeave GPU 云上降低 GPU 支出，把工作负载的内存、吞吐、可用性和延迟需求匹配到满足要求的最小容量。属于社区贡献内容，与 CoreWeave, Inc. 无隶属或赞助关系。
主要能力：提供按显存规模推荐 GPU 的思路（7B 以下推理用 L40，13B 以内用 A100 80GB PCIe，70B 用 4 卡张量并行 A100，更大用 8 卡 H100 SXM5）；用 Knative 的 autoscaling.knative.dev/minScale: "0" 与 scaleDownDelay: "5m" 对开发/测试环境缩容到零；用 AWQ 或 GPTQ 量化把大模型放进更小的 GPU（如 4-bit 70B 可落到单张 A100-80GB，示例命令 vllm serve meta-llama/Llama-3.1-70B-Instruct-AWQ --quantization awq）；并给出变更记录与回滚要求。资料还列出了一份近似价格参考（如 A100 40GB 约 $1.50/GPU/小时、A100 80GB 约 $2.21、H100 80GB PCIe 约 $4.76、H100 SXM5 8 卡约 $6.15/GPU、L40 约 $1.10），仅作规划输入，不是计费依据。
使用方式：先做前置条件——只读访问利用率、命名空间配额与计费分摊数据，指定服务负责人与目标 SLO，并取得可能降低生产容量变更的批准。基线需采集七天 GPU 利用率、排队时间、请求延迟、错误率与按命名空间的分摊成本，避免只看单点峰值。随后提出一个可回滚变更（非生产工作负载调整规格、设置保守的缩容延迟、或跑量化金丝雀），在约定观察窗内对比 SLO 与预算，仅在质量、延迟和错误率不越线时推广。示例做法是在 staging 用 kubectl patch 设定 GPU 限额并 rollout status 观察。
适用场景与限制：适合需要控制 GPU 成本、做选型决策或在非生产环境试验缩容/量化的团队。限制包括：价格是近似值而非账单来源；无完整标签或计费导出时必须停止优化；降配后延迟上升、量化金丝雀质量下降、缩容到零出现冷启动失败时应分别回滚到原资源请求、原模型或原最小副本数；涉及生产容量的变更必须先获批并保留回滚路径。本工具为技能说明，并非 CoreWeave 官方产品。