最近不少做 AI 应用的同学都在交流同一个感受大模型 API 越来越便宜但自己部署模型时的“算力开销”却越来越让人看不懂。尤其是当 CoreWeave、Nebius 这类名字频繁出现在融资、上市、扩产、调价新闻里时很多人第一反应是——它们是做什么的为什么一说英伟达“干儿子”就意味着 GPU 资源又紧了这篇文章不打算写成金融分析而是站在开发者视角把算力、GPU 云、token、模型部署这些概念串起来然后再落到工程侧如果你真的需要自己去租算力、调 GPU、控成本应该怎么看门道。1. 先把“算力”这个词说清楚很多人第一次接触“算力”是从一张显卡参数表开始的。比如“XX 显卡 100 TOPS INT8”又或者“某芯片 FP16 算力达到 XX TFLOPS”。但这些数字放到真实业务里到底能支撑多少并发、能训练多大的模型往往没有一个直接答案。1.1 算力不是一个简单数字从底层看算力是计算设备在单位时间内能完成的数学运算次数。CPU 的算力用每秒浮点运算次数衡量GPU 则更强调并行吞吐。NVIDIA 的 GPU 规格里常见两个指标TFLOPS每秒万亿次浮点运算通常分 FP32、FP16、INT8 等精度TOPS每秒万亿次整数运算多用于 INT8 量化场景。实际推理任务里FP16 或 INT8 更有参考价值因为绝大多数模型推理权重都做了精度降级不会真的用 FP64 去跑。但是单看这两个数字还不够。显存带宽、显存容量、卡间互联、机内拓扑、散热功耗都会决定“算力能不能被喂饱”。就像一辆车发动机功率再高变速箱和轮胎不匹配跑起来依然难受。1.2 算力、token、数据、模型、场景的关系这部分是很多新手的模糊区。为了便于理解可以把一次大模型应用拆成五层概念通俗解释典型单位数据模型学习和推理时喂入的原始文本、图片、表格GB、TB模型通过大量数据训练出来的权重参数集合7B、70B 参数算力运行模型训练和推理所需的计算资源TFLOPS、PFLOPStoken模型处理文本时的最小语义单元个、千 token场景离线批量处理、在线对话、Agent 任务等真实需求并发路数、QPStoken 和算力并不是同一个东西。token 是模型文本处理粒度算力是底层资源消耗。同一个模型处理 1000 个 token在不同 GPU 上的耗时不同不同模型处理同样 token 数需要的显存和算力也不同。API 之所以按 token 计费是因为对平台方来说token 能近似反映推理计算量和带宽占用。1.3 从大模型训练到算力租赁模型参数量越大训练需要的 GPU 卡越多。以常见开源模型为例7B 参数模型的完整预训练可能需要几百张高性能 GPU 连续运行数周即便只是做领域微调也需要几十张 GPU。问题在于大多数公司不可能自建一个上万卡的数据中心。于是出现了“算力租赁”模式训练团队按小时租用整台 GPU 服务器推理团队直接调用云厂商的大模型 API小团队按容器粒度申请单卡或半卡资源。CoreWeave、Nebius 这类厂商本质上就是“把英伟达 GPU 资源打包成云服务”的玩家。它们不解决模型算法问题但解决“你很难买到卡、更难把上万张卡运维好”的问题。2. 英伟达的“干儿子”们是怎么来的项目主题里的 CoreWeave 和 Nebius是这两年最受关注的英伟达生态云厂商。它们并不是传统意义上的大云厂商但成长速度很快。2.1 为什么英伟达愿意“出手”传统云厂商是英伟达的大客户同时也是潜在竞争者。像 AWS、Azure、Google Cloud 既卖云服务也和 AMD、自研芯片团队、创业公司保持合作不会把所有筹码押在英伟达一家身上。英伟达的算盘很清晰扶持一批“只专注于英伟达 GPU 云”的新厂商让它们在市场上形成更多可被英伟达控制的算力出口。这些厂商不像大云厂商那样有自己的芯片战略也没有动力去扶持 AMD、Intel 或自研产品。它们更依赖英伟达的 GPU 供应也更容易接受英伟达的生态绑定。这也是“干爹”说法的来源。英伟达既是供应商又是投资人还可能是这些云平台的早期客户。GPU 供应的优先级、账期、合作报价都会直接影响“干儿子”的生存质量。2.2 CoreWeave、Nebius 分别是什么定位CoreWeave 起步较早最早的业务也和加密相关后来转向 GPU 云计算。它的名字经常出现在大模型企业客户列表里商业模式更接近“大规模 GPU 基础设施服务商”核心卖点是“能比较快拿到大量 NVIDIA GPU并按小时计费出租”。Nebius 则属于另一类 AI 原生云厂商。它的国际化背景比较复杂简单理解就是一家面向 AI 训练和推理场景、重新搭建了整套云平台的技术公司。Nebius 更强调端到端平台能力不只是裸金属 GPU 出租还希望把模型训练、数据管道、推理服务这些环节整合到一起。两类厂商共同的特点是以英伟达 GPU 为底座以“租卡”、“租集群”为核心收入尽量避免与传统通用云计算业务正面纠缠。2.3 “干爹出手”对算力市场意味着什么英伟达对生态伙伴的扶持并不是简单的财务投资。更深层的影响是供货倾斜在 GPU 产能紧张时能拿到更多芯片配额的厂商才有资格承诺“有货即用”云厂商获得 GPU 后又将这些卡高价转租给训练团队最终传导到下游就是模型开发者发现“租卡要排队”或“同类实例涨价”。所以当 CoreWeave、Nebius 扩产或调价的消息出现时行业第一反应并不是关心公司股价而是关心“算力租赁价格是不是又要动了”。3. 算力涨价背后到底是什么在涨从“买一张显卡”到“租一张显卡”中间隔着一整套数据中心工程。涨价从来不只是 GPU 芯片本身在涨而是多个环节叠加的结果。3.1 芯片供给与产能周期GPU 并不是标准电子元器件。高性能 AI 芯片需要台积电等代工厂的先进制程产能同时要搭配 HBM 高带宽显存。HBM 供应链高度集中产能扩张周期长不是显卡厂商想增加就能立刻增加的。当大模型公司集中采购时GPU 就会变成稀缺资源。供不应求阶段云厂商获得的“卡成本”上涨最终体现在实例价格上。3.2 机房、电力、散热、网络不是免费GPU 服务器的功耗远高于普通 CPU 服务器。一个机柜里塞上 8 张 H 系列 GPU功耗轻松超过普通机柜上限。这意味着数据中心需要更高密度的供电方案液冷或更强风冷系统需要额外成本万兆、400G 网络成本也被摊进机器租金机房选址、PUE 指标、电力审批都会影响供给。所以云厂商在谈“算力成本”时谈的往往是一个机柜的综合成本而不是市场显卡价格加一点利润。3.3 不同“算力租法”价格差异极大同样是使用英伟达 GPU不同租用方式的价格逻辑完全不同租用方式适合场景成本特点公有云按需实例短期测试、少量推理单价高、弹性好、随时释放包月/包年实例长期稳定的微调与推理单价低但需要承诺周期裸金属整机租赁训练大模型总量大通常按整机计费容器级资源轻量推理任务灵活适合并发波动场景很多团队以为“租赁价格只跟着市场 H100 行情走”实际却会发现同一家平台月初和月末的报价都可能不同。4. 拿到一台 GPU 服务器后先看什么不论你租的是 CoreWeave、Nebius 这类海外平台还是国内云厂商的 GPU 实例登录服务器后的第一步几乎都是统一的看清楚到底分到了什么卡、驱动是否正常、能不能发挥性能。下面这套命令在 Ubuntu/CentOS 系统的 GPU 服务器上都适用也是“算力服务器命令总结”里最常被提到的一组。4.1 用 nvidia-smi 查看基础状态登录服务器后最基础的操作是执行nvidia-smi这条命令会显示GPU 型号显存总容量与当前已用容量GPU 利用率显存温度与功耗当前正在运行的进程驱动版本与 CUDA 版本。如果执行后提示command not found通常说明驱动未装好或 NVIDIA 驱动没有进入 PATH。可以先检查驱动模块lsmod | grep nvidia如果没有任何输出大概率是驱动未加载。4.2 查看 CPU、内存与系统负载GPU 跑不动有时并不是 GPU 的问题而是 CPU 数据加载跟不上。建议先看系统整体状态free -h df -h top nprocfree -h看内存是否够用df -h看数据盘剩余空间模型权重经常占用几十 GBtop看 CPU 和负载nproc看 CPU 核数决定数据预处理的并行能力。4.3 用 Python 小脚本定时记录 GPU 状态训练模型时经常遇到“程序跑到一半 GPU 利用率掉到 0%”的问题。如果只靠手动敲nvidia-smi很难发现规律。更推荐让脚本定时记录状态把数据落盘再观察时间线变化。下面的 Python 脚本思路可以放在训练脚本启动后并行执行# 文件路径: monitor_gpu.py import subprocess import time from datetime import datetime LOG_FILE gpu_monitor.log def get_gpu_snapshot(): # 使用 nvidia-smi 获取简洁的 GPU 状态行 cmd [ nvidia-smi, --query-gpuindex,utilization.gpu,memory.used,memory.total,temperature.gpu,power.draw, --formatcsv,noheader,nounits ] result subprocess.run(cmd, stdoutsubprocess.PIPE, textTrue) return result.stdout.strip() def main(): print(f开始记录 GPU 状态日志写入: {LOG_FILE}) while True: timestamp datetime.now().strftime(%Y-%m-%d %H:%M:%S) snapshot get_gpu_snapshot() line f{timestamp} | {snapshot} with open(LOG_FILE, a, encodingutf-8) as f: f.write(line \n) # 每 10 秒记录一次 time.sleep(10) if __name__ __main__: main()这个脚本并不复杂核心作用是持续采集 GPU 利用率、显存使用、温度和功耗。如果后面发现脚本训练时 GPU 利用率一直很低就能根据日志反推大概什么时间开始异常。需要注意在训练容器内如果权限受限nvidia-smi可能无法看到宿主机全部 GPU。此时应参考容器内可见的 GPU 编号而不是宿主机编号。5. 算力成本压力下开发者能做什么对普通开发者和中小团队来说我们没有能力影响英伟达的芯片配额也无法左右 CoreWeave、Nebius 这类平台的定价但可以通过工程手段降低对算力的依赖。5.1 先分清“必须自己部署”和“可以走 API”大模型部署存在一个常见误区什么都要自己租卡部署。这里给一个非常实际的建议如果业务是通用问答、文本摘要、代码生成直接调用大模型 API 通常更便宜如果有数据隐私要求、需要深度定制权重、数据量极大再考虑私有化部署如果需求是快速验证产品原型优先用 API不要过早陷入 GPU 运维。API 按 token 计费表面看单价不低但省掉了机器闲置、运维人员、模型调度、弹性扩容这些成本。把机器利用率算进去API 未必更贵。5.2 估算 token 时不要只看中文字数很多同学在评估 API 成本时把 1 个中文字符当成 1 个 token结果账单比自己预期贵不少。大模型的分词器tokenizer并不是按字符切分。中文在常见模型里一个汉字大约对应 1 到 2 个 token一段包含标点、数字、英文混合的文本token 数量波动会更大。更稳妥的做法是按“输入 token 输出 token”分别估算给输出预留足够余量。如果你使用的是 OpenAI 兼容接口可以借助模型库或 SDK 自带的分词方法来统计。下面是一个思路示例# 文件路径: estimate_tokens.py # 这里以 OpenAI 兼容接口为例目标是估算一段 messages 的 token 数量 import json def estimate_prompt_tokens(messages, model_prefixgpt): # 不同模型 tokenizer 不同这里保留一个可扩展的入口 # 如果没有引入官方分词库可以先用粗略规则估算 total_chars 0 for message in messages: content message.get(content) or total_chars len(content) total_chars 20 # 消息结构本身的开销 # 粗略估算英文约 4 字符/token中文约 1.5 字符/token # 这里按最保守的 2 字符/token 示例 estimated_tokens int(total_chars / 2) return max(estimated_tokens, 1) if __name__ __main__: demo_messages [ {role: system, content: 你是一个乐于助人的助手}, {role: user, content: 请帮我写一段 Python 计算斐波那契数列的代码} ] print(预估 token:, estimate_prompt_tokens(demo_messages))这段代码的重点不是给出一个精确的 token 计算公式而是提醒大家在项目里一定要预留 token 估算模块并把历史请求的 token 用量记录到一个单独的表或日志中之后才能做成本趋势分析。5.3 自己部署时尽量复用和分时如果确实需要自己部署开源模型成本控制可以从几个方向入手用相同效果下参数量更小的模型使用 INT8/INT4 量化降低显存占用将多路请求做动态批处理尽量把一个 batch 塞满闲时任务放低价时段运行。对不常访问的模型服务做冷启动策略避免“一直占着 GPU 不跑业务”。算力租用最常见的浪费不是租贵了而是租了机器后 GPU 利用率长期在 10% 以下。6. 常见问题与认知误区只看新闻里的“算力涨价”很容易形成几个错误判断。这里列几个常见问题供大家对照自查。问题常见误区正确理解token 等于字数吗1 token 1 汉字 1 英文字符token 由模型分词器决定不能简单按字符换算GPU 显存占满就代表算力用满显存占用高说明 GPU 一直在算显存是空间利用率才算算力可能显存占满但利用率接近 0%API 和租 GPU 哪个一定便宜自己部署一定省钱只有业务规模足够大且利用率稳定时自部署才有明显优势英伟达“干儿子”涨价 所有算力都涨所有 GPU 都同步紧张不同卡型、不同地域、不同租期差异很大租算力必须一次租一整台自己没有大规模需求就不能租很多平台提供单卡或容器级资源入门成本不算高再补充一个容易踩坑的工程细节GPU 利用率高并不等于“它在干正事”。有些程序因为有 bug 陷入死循环GPU 也会显示 100% 利用率。排查时要结合显存、功耗、训练日志综合判断不要只看nvidia-smi里一个百分比。7. 梳理几条务实建议前文零零散散讲了一些方法论最后集中整理几条对开发者和技术团队更有实际操作价值的建议。第一不要因为“算力涨价”消息就急着锁长周期资源。GPU 租赁市场存在明显的周期波动。如果业务波动大先用按需实例核算真实用量再决定是否切包月。第二做成本预测时一定要把“模型迭代次数”算进去。不要只按推理 token 量估计成本模型微调时的一次实验可能在几小时内消耗数百元的算力费用。我见过不少团队推理成本控制得很好却在调参实验上超支严重。第三自己的训练任务要有断点续训能力。GPU 实例被回收或故障后如果任务无法从最近 checkpoint 恢复前面所有算力成本都会直接浪费。这是工程上比“租到便宜卡”更重要的事。第四对 CoreWeave、Nebius 这类厂商保持关注但不建议把核心业务绑定在某一家算力平台的独家资源上。可以提前准备多套部署脚本让同一模型能在不同 GPU 云平台或国内云平台上运行。这样即使其中一家调价你也有切换空间。算力市场的波动在短期内很难消失。与其焦虑自己“上不了车”不如先把一个模型推理服务的成本模型吃透把 GPU 利用率、token 估算、故障恢复这些基础工程做扎实。毕竟无论哪家算力平台起落最终比拼的还是谁能用更低成本把模型能力稳定交付给用户。 算力、GPU云与模型部署：开发者成本控制指南
最近不少做 AI 应用的同学都在交流同一个感受大模型 API 越来越便宜但自己部署模型时的“算力开销”却越来越让人看不懂。尤其是当 CoreWeave、Nebius 这类名字频繁出现在融资、上市、扩产、调价新闻里时很多人第一反应是——它们是做什么的为什么一说英伟达“干儿子”就意味着 GPU 资源又紧了这篇文章不打算写成金融分析而是站在开发者视角把算力、GPU 云、token、模型部署这些概念串起来然后再落到工程侧如果你真的需要自己去租算力、调 GPU、控成本应该怎么看门道。1. 先把“算力”这个词说清楚很多人第一次接触“算力”是从一张显卡参数表开始的。比如“XX 显卡 100 TOPS INT8”又或者“某芯片 FP16 算力达到 XX TFLOPS”。但这些数字放到真实业务里到底能支撑多少并发、能训练多大的模型往往没有一个直接答案。1.1 算力不是一个简单数字从底层看算力是计算设备在单位时间内能完成的数学运算次数。CPU 的算力用每秒浮点运算次数衡量GPU 则更强调并行吞吐。NVIDIA 的 GPU 规格里常见两个指标TFLOPS每秒万亿次浮点运算通常分 FP32、FP16、INT8 等精度TOPS每秒万亿次整数运算多用于 INT8 量化场景。实际推理任务里FP16 或 INT8 更有参考价值因为绝大多数模型推理权重都做了精度降级不会真的用 FP64 去跑。但是单看这两个数字还不够。显存带宽、显存容量、卡间互联、机内拓扑、散热功耗都会决定“算力能不能被喂饱”。就像一辆车发动机功率再高变速箱和轮胎不匹配跑起来依然难受。1.2 算力、token、数据、模型、场景的关系这部分是很多新手的模糊区。为了便于理解可以把一次大模型应用拆成五层概念通俗解释典型单位数据模型学习和推理时喂入的原始文本、图片、表格GB、TB模型通过大量数据训练出来的权重参数集合7B、70B 参数算力运行模型训练和推理所需的计算资源TFLOPS、PFLOPStoken模型处理文本时的最小语义单元个、千 token场景离线批量处理、在线对话、Agent 任务等真实需求并发路数、QPStoken 和算力并不是同一个东西。token 是模型文本处理粒度算力是底层资源消耗。同一个模型处理 1000 个 token在不同 GPU 上的耗时不同不同模型处理同样 token 数需要的显存和算力也不同。API 之所以按 token 计费是因为对平台方来说token 能近似反映推理计算量和带宽占用。1.3 从大模型训练到算力租赁模型参数量越大训练需要的 GPU 卡越多。以常见开源模型为例7B 参数模型的完整预训练可能需要几百张高性能 GPU 连续运行数周即便只是做领域微调也需要几十张 GPU。问题在于大多数公司不可能自建一个上万卡的数据中心。于是出现了“算力租赁”模式训练团队按小时租用整台 GPU 服务器推理团队直接调用云厂商的大模型 API小团队按容器粒度申请单卡或半卡资源。CoreWeave、Nebius 这类厂商本质上就是“把英伟达 GPU 资源打包成云服务”的玩家。它们不解决模型算法问题但解决“你很难买到卡、更难把上万张卡运维好”的问题。2. 英伟达的“干儿子”们是怎么来的项目主题里的 CoreWeave 和 Nebius是这两年最受关注的英伟达生态云厂商。它们并不是传统意义上的大云厂商但成长速度很快。2.1 为什么英伟达愿意“出手”传统云厂商是英伟达的大客户同时也是潜在竞争者。像 AWS、Azure、Google Cloud 既卖云服务也和 AMD、自研芯片团队、创业公司保持合作不会把所有筹码押在英伟达一家身上。英伟达的算盘很清晰扶持一批“只专注于英伟达 GPU 云”的新厂商让它们在市场上形成更多可被英伟达控制的算力出口。这些厂商不像大云厂商那样有自己的芯片战略也没有动力去扶持 AMD、Intel 或自研产品。它们更依赖英伟达的 GPU 供应也更容易接受英伟达的生态绑定。这也是“干爹”说法的来源。英伟达既是供应商又是投资人还可能是这些云平台的早期客户。GPU 供应的优先级、账期、合作报价都会直接影响“干儿子”的生存质量。2.2 CoreWeave、Nebius 分别是什么定位CoreWeave 起步较早最早的业务也和加密相关后来转向 GPU 云计算。它的名字经常出现在大模型企业客户列表里商业模式更接近“大规模 GPU 基础设施服务商”核心卖点是“能比较快拿到大量 NVIDIA GPU并按小时计费出租”。Nebius 则属于另一类 AI 原生云厂商。它的国际化背景比较复杂简单理解就是一家面向 AI 训练和推理场景、重新搭建了整套云平台的技术公司。Nebius 更强调端到端平台能力不只是裸金属 GPU 出租还希望把模型训练、数据管道、推理服务这些环节整合到一起。两类厂商共同的特点是以英伟达 GPU 为底座以“租卡”、“租集群”为核心收入尽量避免与传统通用云计算业务正面纠缠。2.3 “干爹出手”对算力市场意味着什么英伟达对生态伙伴的扶持并不是简单的财务投资。更深层的影响是供货倾斜在 GPU 产能紧张时能拿到更多芯片配额的厂商才有资格承诺“有货即用”云厂商获得 GPU 后又将这些卡高价转租给训练团队最终传导到下游就是模型开发者发现“租卡要排队”或“同类实例涨价”。所以当 CoreWeave、Nebius 扩产或调价的消息出现时行业第一反应并不是关心公司股价而是关心“算力租赁价格是不是又要动了”。3. 算力涨价背后到底是什么在涨从“买一张显卡”到“租一张显卡”中间隔着一整套数据中心工程。涨价从来不只是 GPU 芯片本身在涨而是多个环节叠加的结果。3.1 芯片供给与产能周期GPU 并不是标准电子元器件。高性能 AI 芯片需要台积电等代工厂的先进制程产能同时要搭配 HBM 高带宽显存。HBM 供应链高度集中产能扩张周期长不是显卡厂商想增加就能立刻增加的。当大模型公司集中采购时GPU 就会变成稀缺资源。供不应求阶段云厂商获得的“卡成本”上涨最终体现在实例价格上。3.2 机房、电力、散热、网络不是免费GPU 服务器的功耗远高于普通 CPU 服务器。一个机柜里塞上 8 张 H 系列 GPU功耗轻松超过普通机柜上限。这意味着数据中心需要更高密度的供电方案液冷或更强风冷系统需要额外成本万兆、400G 网络成本也被摊进机器租金机房选址、PUE 指标、电力审批都会影响供给。所以云厂商在谈“算力成本”时谈的往往是一个机柜的综合成本而不是市场显卡价格加一点利润。3.3 不同“算力租法”价格差异极大同样是使用英伟达 GPU不同租用方式的价格逻辑完全不同租用方式适合场景成本特点公有云按需实例短期测试、少量推理单价高、弹性好、随时释放包月/包年实例长期稳定的微调与推理单价低但需要承诺周期裸金属整机租赁训练大模型总量大通常按整机计费容器级资源轻量推理任务灵活适合并发波动场景很多团队以为“租赁价格只跟着市场 H100 行情走”实际却会发现同一家平台月初和月末的报价都可能不同。4. 拿到一台 GPU 服务器后先看什么不论你租的是 CoreWeave、Nebius 这类海外平台还是国内云厂商的 GPU 实例登录服务器后的第一步几乎都是统一的看清楚到底分到了什么卡、驱动是否正常、能不能发挥性能。下面这套命令在 Ubuntu/CentOS 系统的 GPU 服务器上都适用也是“算力服务器命令总结”里最常被提到的一组。4.1 用 nvidia-smi 查看基础状态登录服务器后最基础的操作是执行nvidia-smi这条命令会显示GPU 型号显存总容量与当前已用容量GPU 利用率显存温度与功耗当前正在运行的进程驱动版本与 CUDA 版本。如果执行后提示command not found通常说明驱动未装好或 NVIDIA 驱动没有进入 PATH。可以先检查驱动模块lsmod | grep nvidia如果没有任何输出大概率是驱动未加载。4.2 查看 CPU、内存与系统负载GPU 跑不动有时并不是 GPU 的问题而是 CPU 数据加载跟不上。建议先看系统整体状态free -h df -h top nprocfree -h看内存是否够用df -h看数据盘剩余空间模型权重经常占用几十 GBtop看 CPU 和负载nproc看 CPU 核数决定数据预处理的并行能力。4.3 用 Python 小脚本定时记录 GPU 状态训练模型时经常遇到“程序跑到一半 GPU 利用率掉到 0%”的问题。如果只靠手动敲nvidia-smi很难发现规律。更推荐让脚本定时记录状态把数据落盘再观察时间线变化。下面的 Python 脚本思路可以放在训练脚本启动后并行执行# 文件路径: monitor_gpu.py import subprocess import time from datetime import datetime LOG_FILE gpu_monitor.log def get_gpu_snapshot(): # 使用 nvidia-smi 获取简洁的 GPU 状态行 cmd [ nvidia-smi, --query-gpuindex,utilization.gpu,memory.used,memory.total,temperature.gpu,power.draw, --formatcsv,noheader,nounits ] result subprocess.run(cmd, stdoutsubprocess.PIPE, textTrue) return result.stdout.strip() def main(): print(f开始记录 GPU 状态日志写入: {LOG_FILE}) while True: timestamp datetime.now().strftime(%Y-%m-%d %H:%M:%S) snapshot get_gpu_snapshot() line f{timestamp} | {snapshot} with open(LOG_FILE, a, encodingutf-8) as f: f.write(line \n) # 每 10 秒记录一次 time.sleep(10) if __name__ __main__: main()这个脚本并不复杂核心作用是持续采集 GPU 利用率、显存使用、温度和功耗。如果后面发现脚本训练时 GPU 利用率一直很低就能根据日志反推大概什么时间开始异常。需要注意在训练容器内如果权限受限nvidia-smi可能无法看到宿主机全部 GPU。此时应参考容器内可见的 GPU 编号而不是宿主机编号。5. 算力成本压力下开发者能做什么对普通开发者和中小团队来说我们没有能力影响英伟达的芯片配额也无法左右 CoreWeave、Nebius 这类平台的定价但可以通过工程手段降低对算力的依赖。5.1 先分清“必须自己部署”和“可以走 API”大模型部署存在一个常见误区什么都要自己租卡部署。这里给一个非常实际的建议如果业务是通用问答、文本摘要、代码生成直接调用大模型 API 通常更便宜如果有数据隐私要求、需要深度定制权重、数据量极大再考虑私有化部署如果需求是快速验证产品原型优先用 API不要过早陷入 GPU 运维。API 按 token 计费表面看单价不低但省掉了机器闲置、运维人员、模型调度、弹性扩容这些成本。把机器利用率算进去API 未必更贵。5.2 估算 token 时不要只看中文字数很多同学在评估 API 成本时把 1 个中文字符当成 1 个 token结果账单比自己预期贵不少。大模型的分词器tokenizer并不是按字符切分。中文在常见模型里一个汉字大约对应 1 到 2 个 token一段包含标点、数字、英文混合的文本token 数量波动会更大。更稳妥的做法是按“输入 token 输出 token”分别估算给输出预留足够余量。如果你使用的是 OpenAI 兼容接口可以借助模型库或 SDK 自带的分词方法来统计。下面是一个思路示例# 文件路径: estimate_tokens.py # 这里以 OpenAI 兼容接口为例目标是估算一段 messages 的 token 数量 import json def estimate_prompt_tokens(messages, model_prefixgpt): # 不同模型 tokenizer 不同这里保留一个可扩展的入口 # 如果没有引入官方分词库可以先用粗略规则估算 total_chars 0 for message in messages: content message.get(content) or total_chars len(content) total_chars 20 # 消息结构本身的开销 # 粗略估算英文约 4 字符/token中文约 1.5 字符/token # 这里按最保守的 2 字符/token 示例 estimated_tokens int(total_chars / 2) return max(estimated_tokens, 1) if __name__ __main__: demo_messages [ {role: system, content: 你是一个乐于助人的助手}, {role: user, content: 请帮我写一段 Python 计算斐波那契数列的代码} ] print(预估 token:, estimate_prompt_tokens(demo_messages))这段代码的重点不是给出一个精确的 token 计算公式而是提醒大家在项目里一定要预留 token 估算模块并把历史请求的 token 用量记录到一个单独的表或日志中之后才能做成本趋势分析。5.3 自己部署时尽量复用和分时如果确实需要自己部署开源模型成本控制可以从几个方向入手用相同效果下参数量更小的模型使用 INT8/INT4 量化降低显存占用将多路请求做动态批处理尽量把一个 batch 塞满闲时任务放低价时段运行。对不常访问的模型服务做冷启动策略避免“一直占着 GPU 不跑业务”。算力租用最常见的浪费不是租贵了而是租了机器后 GPU 利用率长期在 10% 以下。6. 常见问题与认知误区只看新闻里的“算力涨价”很容易形成几个错误判断。这里列几个常见问题供大家对照自查。问题常见误区正确理解token 等于字数吗1 token 1 汉字 1 英文字符token 由模型分词器决定不能简单按字符换算GPU 显存占满就代表算力用满显存占用高说明 GPU 一直在算显存是空间利用率才算算力可能显存占满但利用率接近 0%API 和租 GPU 哪个一定便宜自己部署一定省钱只有业务规模足够大且利用率稳定时自部署才有明显优势英伟达“干儿子”涨价 所有算力都涨所有 GPU 都同步紧张不同卡型、不同地域、不同租期差异很大租算力必须一次租一整台自己没有大规模需求就不能租很多平台提供单卡或容器级资源入门成本不算高再补充一个容易踩坑的工程细节GPU 利用率高并不等于“它在干正事”。有些程序因为有 bug 陷入死循环GPU 也会显示 100% 利用率。排查时要结合显存、功耗、训练日志综合判断不要只看nvidia-smi里一个百分比。7. 梳理几条务实建议前文零零散散讲了一些方法论最后集中整理几条对开发者和技术团队更有实际操作价值的建议。第一不要因为“算力涨价”消息就急着锁长周期资源。GPU 租赁市场存在明显的周期波动。如果业务波动大先用按需实例核算真实用量再决定是否切包月。第二做成本预测时一定要把“模型迭代次数”算进去。不要只按推理 token 量估计成本模型微调时的一次实验可能在几小时内消耗数百元的算力费用。我见过不少团队推理成本控制得很好却在调参实验上超支严重。第三自己的训练任务要有断点续训能力。GPU 实例被回收或故障后如果任务无法从最近 checkpoint 恢复前面所有算力成本都会直接浪费。这是工程上比“租到便宜卡”更重要的事。第四对 CoreWeave、Nebius 这类厂商保持关注但不建议把核心业务绑定在某一家算力平台的独家资源上。可以提前准备多套部署脚本让同一模型能在不同 GPU 云平台或国内云平台上运行。这样即使其中一家调价你也有切换空间。算力市场的波动在短期内很难消失。与其焦虑自己“上不了车”不如先把一个模型推理服务的成本模型吃透把 GPU 利用率、token 估算、故障恢复这些基础工程做扎实。毕竟无论哪家算力平台起落最终比拼的还是谁能用更低成本把模型能力稳定交付给用户。