想给团队做个内部问答工具，模型选的是 7B 量化版。我的第一反应是买卡——一张二手 3090 的行情摆在那儿，一台能用的机器连显卡带主机小一万。老板听到"一万"两个字就皱了眉，这事最后拖了两周。
转折点是我算了一笔小时账。
先把两种花法摆平
买卡是一次性支出 + 持续的电和维护。租云主机是按小时计费 + 什么都不用管。真正该比的不是"一万 vs 几百"，而是"这台机器我打算用多久"。
假设 GPU 实例按 8 块/小时（这个量级在几家云厂商的入门卡上都能拿到），一万块的卡对应约 1250 个小时的连续运行——听起来远超任何人的使用时长。但这个算法有个前提：你真的会一直开机。
实际情况是，模型服务只有工作日白天有人用，晚上和周末基本空转。按每天 8 小时算，一张卡一年只跑约 2000 小时里有效利用的 730 个小时不到，剩下的时间在烧电费、吃折旧、还要占一个机柜位。这时候租机的每小时单价虽然是支出，但你只为真正在用的时间付费。
我的情况是：内部工具一天有效调用大概三四个小时，分布在白天。这种负载租机几乎必胜——一个月付掉的钱不到买卡利息的十分之一。
但有三个前提必须想清楚
第一，你的数据能不能出内网。 这一条直接否决了很多"上云做 AI"的方案。代码、文档、用户数据要送进云上的模型服务，如果合规上不允许数据出内网，那讨论价格就没意义了。也有折中办法：敏感数据在内网做脱敏和向量化，只把必要的上下文送出去。
第二，模型权重和业务数据要来回搬。 几十 GB 的模型文件第一次下载、每次更新都要走公网，入站流量通常免费，但出站流量在多数云厂商是收费的，而且单价不低。用对象存储 + 内网 endpoint 拉取能省很多，这个细节在部署前就要确认，不然账单出来会很难看。
第三，别忘了"忘记关机"。 这是我见过最贵的错误形态。一台 GPU 实例没人关，跑一个周末，三天的钱就没了。解决办法很土但有效：给实例加自动停机策略，设一个兜底定时任务；或者用完立刻释放（按秒计费的实例尤其适合这种用法）。
选实例时别只看 GPU 型号
新手容易犯的错是直奔 GPU 型号去比。实际选型要看三件事的乘积，而不是单项：
- 显存够不够装下模型。7B 的 FP16 权重约 14GB，Q4 量化后约 4-5GB，加上 KV cache 和运行时开销，实际要留 2 倍余量。显存不够的典型症状是加载时报 CUDA OOM，而不是跑一段时间才崩。
- 带宽够不够喂饱推理。模型加载完之后的瓶颈往往从算力转移到内存带宽上——每生成一个 token 都要把权重过一遍。带宽不够的表现是"能跑但很慢"，GPU 利用率却在低位空转。
- CPU 和磁盘别成为短板。文本分词、文档解析、向量检索都在 CPU 上做；模型权重加载和缓存写盘吃磁盘 IO。我第一次选机就只盯着 GPU，结果发现 tokenizer 的 CPU 核数不够，预处理直接把吞吐压到预期的三分之一。
什么时候租机是亏的
反面情况同样明确：
- 7×24 全天候高负载。如果服务真的全天有人用、且利用率稳定在高位，那长期包一台或自己买卡的单位成本更低，租机的"按需付费"优势就没了。
- 需要长期驻留的重量级模型。70B 以上模型加载一次要几分钟到十几分钟，冷启动期间不响应请求。要么接受这个延迟，要么为它单独准备常驻实例——那就回到"长期持有"的成本模型了。
- 推理量足够大到能摊薄工程成本。自建推理服务要装 CUDA、装框架、盯显存、处理版本兼容。这些隐性工时算进去之后，"省下的机器钱"可能只是把成本从财务挪到了研发身上。
一条我最后用的判断规则
看"峰值利用率"而不是"总时长"。 峰值利用率低（大多数内部工具都是），租机几乎总是对的；峰值利用率高且持续时间长，才轮到买卡或包年包月。
这个判断我在后来的几次选型里一直用，包括给一个文档处理流水线换机器、给一个需要常驻的向量检索服务调配置，结论都没有反过来。
需要补充一句：上面所有的"小时价""显卡行情"都是量级示意，不是报价。真实数字请以各家官方页面为准——这类价格变动比服务器配置变动还快，写死在文章里过几个月就是误导。