最近 AI 基础设施圈有两个名字反复出现CoreWeave、Nebius另一个绕不开的是英伟达。很多人把这两家公司比作“英伟达的干儿子”这个说法不算严谨但确实说中了一点它们不是英伟达的官方部门却在 GPU 供货、云基础设施投资和客户获取上都和英伟达深度绑定。标题里的“算力涨价、干爹出手”真正要讨论的不是八卦而是大模型训练和推理背后的 GPU 资源价格、供给和选型策略正在发生变化。如果你只在本地跑过 ComfyUI 或小模型可能暂时感受不到这波算力行情的冲击。但只要你用过云 GPU、计划租卡做微调、或正在给业务接大模型 API就必须关注 CoreWeave、Nebius 这类平台的一举一动。原因很简单它们决定了你能以什么价格、在多长时间内拿到 A 卡、H 卡以及下一代 GPU也决定了你后期做推理服务时是按卡收费还是按 token 收费。因此这篇文章不讲股价涨跌讲三件更实际的事这波算力涨价到底涨在哪客户应该用哪些指标判断一个算力平台适不适合自己拿到 GPU 实例或 Kubernetes 集群后如何快速验证性能、接入 API、跑批量任务。文章会先给出一张算力平台速览表再拆解“算力、Token、API”这些容易混淆的概念接着给出一套从环境准备、部署验证到资源监控的通用流程。涉及代码和命令我都会给可直接复制的模板但要注意不同云厂商的控制台、资源名和权限策略不一样模板里的路径、镜像、参数需要按实际情况替换。1. 算力版图速览CoreWeave、Nebius、英伟达分别扮演什么角色先看一张速览表快速理解这三方在 AI 算力供给里的位置。表格内容来自公开产品形态不代表某个平台的全部功能也不构成下单建议。主体主要角色提供的能力典型使用者与英伟达的关系CoreWeaveGPU 云服务商GPU 裸金属、Kubernetes 集群、大规模训练与渲染基础设施需要快捷租用大批量 NVIDIA GPU 的团队被看作英伟达 GPU 产能的重要出口合作关系非常深NebiusAI 云服务商GPU 云主机、Kubernetes 服务、托管推理环境做模型训练、微调、推理部署的算法团队同样围绕英伟达 GPU 生态提供偏向工程化工具链的云服务英伟达芯片与软件栈供应商GPU 硬件、CUDA、驱动、容器运行时、模型优化工具所有需要 GPU 算力的用户产业链上游通过供货和生态绑定影响下游算力价格传统云厂商综合云平台除 GPU 外还有 CDN、对象存储、数据库等全栈服务需要把 AI 能力放进完整业务系统的企业也在提供 NVIDIA 实例同时推广自研芯片做替代不要把 CoreWeave 和 Nebius 理解成“又一个虚拟机厂商”。它们和其他云平台的核心差异在于目标用户更集中服务更偏向 AI 训练和推理大量流程围绕多卡并行、高速网络、GPU 容器调度来设计。普通人如果只是开一台机器跑nvidia-smi传统云厂商就够用但如果你准备部署大模型推理服务或者经常要做 8 卡甚至更大规模的训练这类平台的用户体验会更顺。从资本关系看“干儿子”这个词有夸张成分。更准确的说法是英伟达希望把有限的 GPU 产能分配到愿意长期建设 AI 基础设施的伙伴手里合作伙伴则通过长期合约锁定芯片供应。这种生态绑定的好处是客户能更快拿到最新卡代价是价格弹性变小大客户的话语权更强。对普通开发者来说不需要为这个关系投入情绪重点看平台的可用性、价格透明度和接口能力。2. 算力涨价的底层逻辑GPU、Token、API 到底是什么关系2.1 GPU 算力不是“处理速度”这么简单很多技术文章把算力说成“每秒能处理多少 token”这是为了方便快速比较但很容易造成误导。算力的核心指标包括 GPU 芯片型号、HBM 显存容量、显存带宽、FP16/BF16/INT8 算力、卡间互联带宽以及集群网络结构。以一个大模型推理任务为例影响用户体验的是首 token 延迟、每秒输出 token 数、最大并发数而这三个指标不仅取决于 GPU 算得快不快还取决于核函数有没有优化到位、显存带宽够不够、KV Cache 有没有预热。所以比较两个算力平台时最忌讳只盯着显卡型号看。同一个 H 级 GPU在不同制造商的机房、不同网络拓扑、不同 CUDA 版本、不同推理引擎下面吞吐可能差异很大。比较 K8s 节点是否开启了 RDMA、网络是否跨 AZ、存储是否 NAS、镜像拉取是否走内网这些都比单纯看卡名重要。2.2 Token 是推理计量单位不是“消耗预算”的全部ChatGPT 类产品习惯按 token 计费很多开发者因此认为 token 单价就是模型成本的全部。但 token 单价可以被人为压低真实成本却还要看底下的 GPU 是否被充分利用。一个模型服务如果并发低、排队高、处理速度慢即便 token 报价很低用户侧的每秒处理能力也可能远低于预期。反过来如果服务端做了很好的 prompt caching、continuous batching、动态 batch那么同一块 GPU 上承载的 token 吞吐会高很多。做技术选型时建议把算力、Token、API 三件事拆开算力是你购买的基础设施Token 是模型对文本切分的计量方式API 是调用模型能力的协议层。先确认需要什么量级的算力再看这个平台在相同模型下给出的每秒 token 吞吐最后看 API 是否 OpenAI 兼容、是否支持批量上传、是否适合内网部署。只有这三者都满足比价才有意义。2.3 为什么这轮“算力涨价”会被反复讨论从行业观察来看涨价不是单纯某一家公司抬价而是结构性的供需错配。头部模型公司会提前锁定大量 GPU留给临时租用的余量本来就不多。加上数据中心电费、机柜功率密度、网络带宽、散热这些成本都在上升云厂商只能把压力传导给客户。与此同时新一代 GPU 虽然单卡性能提升但并没有立刻带来供给总量的跳跃式增长因此价格波动会更明显。对普通开发者的直接影响是按小时租卡的现货价格波动大按周或按月租赁的长期合约又可能锁定太死。应对方法不是祈祷降价而是把预算拆成三层测试用少量 Spot/按量卡生产级小流量用短周期预留大训练任务再考虑长租。这样既能控制短期风险也不会因为长期合同错过后续价格回调。3. 选算力平台前的量化指标与环境准备3.1 先列清单再做预算模型无论你打算用 CoreWeave、Nebius还是国内外的通用云平台建议先形成一个固定的环境检查模板。这样既能避免被销售话术带偏也能在多个平台之间做同口径对比。下面是基础清单机型与卡型显存容量、显存带宽、卡间互联、是否支持 NVLink/IB。软件环境CUDA、驱动、PyTorch、Python 版本、容器运行时。集群能力是否提供 Kubernetes、是否能按节点池扩容、是否有节点自动回收。存储方案对象存储、文件存储、临时盘容量、数据出流量费用。调度与配额一次最多能调多少卡是否有长期卡位或竞价实例。网络访问是否提供外网入口出方向流量费多少。安全合规数据存储区域、访问密钥、私有网络隔离能力。计费组成GPU 小时价、存储费、网络费、管理节点费、镜像拉取费。可以先用一个简单的 Python 脚本估算月成本再决定是否提交工单。下面代码是通用模板卡价格需要按所在云厂商的控制台价格填写def estimate_gpu_monthly_cost(card_per_hour, gpu_num, daily_hours, weekly_days, months1): weekly_hours daily_hours * weekly_days monthly_hours weekly_hours * 4.33 total_gpu_hours monthly_hours * gpu_num * months return card_per_hour * total_gpu_hours # 示例假设单卡 1 美元/小时租 8 卡每天跑 16 小时每周 5 天 cost estimate_gpu_monthly_cost(card_per_hour1.0, gpu_num8, daily_hours16, weekly_days5) print(f无折扣情况下预估账单: {cost:.2f} 美元/月)这个模型没有把显存利用率、失败重试、数据下载、后端存储算进去但已经能帮助你在预算阶段排除明显不合理的平台。最终决定前最好先用单卡跑一轮真实推理基准再看生产成本。3.2 用“真实吞吐”替代“纸面算力”纸面算力可以看规格表真实吞吐只能通过压测拿到。建议准备两个测试小 batch 延迟测试和大 batch 吞吐测试。小 batch 延迟测试用于判断线上交互是否流畅大 batch 吞吐测试用于估算离线任务成本。不要在同一个机器上测试时把其他团队的任务混进去。多租户共享 GPU 节点的平台在忙时数字很难看应该在拿到独立资源后再测。比较合理的做法是固定模型、固定输入输出长度、固定并发只改变 GPU 型号和推理引擎测量每秒输出 token 数。同一个平台不同时间测出的结果也可能不一样因此要保留测试日志方便复盘。4. 拿到 GPU 实例后的部署验证流程4.1 登录后的第一组命令不管你在哪个云平台开通实例建议先执行下面这套命令确认硬件、驱动和存储都正常# 查看 GPU 型号、显存以及驱动 nvidia-smi # 查看 CUDA 工具链版本 nvcc --version # 查看系统信息 lscpu free -h df -h如果nvidia-smi能正常打印 GPU 信息说明驱动和容器运行时基本就绪。接下来跑一个简单的 PyTorch 或 CUDA 样例确认 PyTorch 能正常调用 GPUimport torch print(torch.__version__) print(torch.cuda.is_available()) print(torch.cuda.get_device_name(0))这一步能排除 90% 的“明明有卡但程序跑在 CPU 上”的问题。如果输出显示cuda.is_available()为 False优先检查 PyTorch 版本是不是 CPU 版本再检查 CUDA 驱动和容器的LD_LIBRARY_PATH。4.2 用 Kubernetes 测试 GPU 调度很多算力平台提供了兼容 Kubernetes 的控制面。如果你拿到的是 KubeConfig而不是一台裸机可以用下面这个通用 Pod 验证 GPU 是否能被正常调度export KUBECONFIG/path/to/your/platform-kubeconfig kubectl create namespace gpu-test然后写入一个测试 PodapiVersion: v1 kind: Pod metadata: name: gpu-smoke namespace: gpu-test spec: restartPolicy: Never containers: - name: cuda image: nvidia/cuda:12.4.1-base-ubuntu22.04 command: [sh, -c, nvidia-smi sleep 30] resources: limits: nvidia.com/gpu: 1再执行kubectl apply -f gpu-smoke.yaml kubectl logs -n gpu-test gpu-smoke kubectl delete -f gpu-smoke.yaml这里要注意不是所有平台的 GPU 资源名都叫nvidia.com/gpu。如果平台使用自定义设备插件资源名可能是平台自己的标识需要查看控制台文档后再修改。看到 Pod 日志里有 NVIDIA GPU 信息说明调度、驱动和设备插件都通了可以开始部署真实模型。4.3 显存占用和性能观察的基本方式运行推理服务时可以用以下命令持续观察显存和利用率# 每 1 秒刷新一次 watch -n 1 nvidia-smi # 输出 CSV 格式方便保存 nvidia-smi --query-gpuindex,memory.used,utilization.gpu,temperature.gpu,power.draw \ --formatcsv -l 5这里的显存占用不是固定数字它会随模型参数量、上下文长度、batch size 和 KV Cache 策略变化。不要只看启动时显存还要在连续请求时观察显存有没有缓慢增长如果持续增长而不回落大概率存在显存泄漏需要检查推理服务和缓存清理逻辑。5. 功能测试与效果验证让模型服务真正跑起来5.1 部署一个兼容 OpenAI 格式的推理服务下面以 vLLM 容器为例展示从镜像启动到 API 返回的完整链路。命令里的模型名是示例实际使用时要换成允许下载的模型也需要保证当前 GPU 显存足够。docker run --gpus all -p 8000:8000 \ -e HF_TOKENyour_hf_token \ vllm/vllm-openai:latest \ --model Qwen/Qwen2.5-7B-Instruct \ --gpu-memory-utilization 0.9 \ --max-model-len 8192 \ --enforce-eagerHF_TOKEN用于从 Hugging Face 拉取有权限的模型--gpu-memory-utilization 0.9表示推理框架最多使用 90% 显存给驱动和其他进程留一点余量--max-model-len 8192是上下文窗口长度限制要根据显存微调。如果平台不支持 Docker可以改用 Kubernetes Deployment 和 Service原理一致。启动日志里出现Starting vLLM API server后另开一个终端访问接口。5.2 用 curl 完成一次 Chat 请求curl -s http://127.0.0.1:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: Qwen/Qwen2.5-7B-Instruct, messages: [ {role: user, content: 用一句话介绍 GPU 算力调度} ], max_tokens: 256, temperature: 0.3 }判断成功的标准是返回 JSON 里包含choices[0].message.content并且nvidia-smi中显存利用率出现明显变化。常见失败原因有端口没暴露、模型没下载完、显存不足以加载模型、请求参数里模型名写错。排错时先看服务端日志再看资源占用。5.3 验证输出质量和稳定性接口通了不代表效果没问题。建议用固定问题集测试以下指标短问题是否能在合理延迟内返回第一段内容。长文本是否出现截断是否触发超时。高并发下是否频繁返回 429 或 503。连续请求后显存是否被持续占用。同一条 prompt 多次请求结果是否稳定。如果准备用于生产建议再做一次回归测试把输入文件、输出结果、显存曲线、日志都保存下来。这样后续升级推理引擎或更换 GPU 实例时可以对同一组数据进行前后对比而不是凭感觉认为新版变快或变慢。6. 接口 API 与批量任务从单次调用到批量处理6.1 用 OpenAI SDK 调用自部署服务大部分推理框架会暴露 OpenAI 兼容接口所以客户端可以直接用 Python SDK 或 requests 调用。以 Python 为例from openai import OpenAI client OpenAI( base_urlhttp://127.0.0.1:8000/v1, api_keyEMPTY ) response client.chat.completions.create( modelQwen/Qwen2.5-7B-Instruct, messages[ {role: user, content: 帮我总结这段文本} ], max_tokens512, temperature0.2 ) print(response.choices[0].message.content)这种调用方式好处是业务代码不需要依赖具体云平台 SDK。以后如果从本地 vLLM 切到平台托管推理只要平台支持 OpenAI 兼容接口只需要改base_url和api_key。6.2 批量任务设计控制并发、记录进度、失败重试批量处理不要直接写“无限 for 循环 requests”。更安全的做法是读入一个 JSONL 文件每条记录包含独立的任务 ID 和请求内容然后使用有限线程池去请求。示例结构如下{custom_id: case-001, body: {messages: [{role: user, content: 任务一}]}} {custom_id: case-002, body: {messages: [{role: user, content: 任务二}]}}然后写一个处理函数把结果写回到一个结果 JSONL并为每条任务记录status。遇到超时或限流时不要立刻重试先等待一段时间再退回如果连续失败多次就把任务 ID 单独保存到失败列表方便复盘。下面是一个简化版并发模板import json import time from concurrent.futures import ThreadPoolExecutor, as_completed MAX_WORKERS 4 def process_one(line): obj json.loads(line) body obj[body] # 这里调用自己的请求方法 # result request_chat(body) # 示例中先用 sleep 代替 time.sleep(1) return {custom_id: obj[custom_id], status: success} with open(input.jsonl, r, encodingutf-8) as fp: lines fp.readlines() results [] with ThreadPoolExecutor(max_workersMAX_WORKERS) as executor: future_map {executor.submit(process_one, line): line for line in lines} for future in as_completed(future_map): try: result future.result() results.append(result) except Exception as exc: original future_map[future] results.append({error: str(exc), line: original}) with open(output.jsonl, w, encodingutf-8) as fp: for item in results: fp.write(json.dumps(item, ensure_asciiFalse) \n)实际批量任务里最值得注意的不是并发数开多大而是请求失败后的恢复策略。每个任务都应该能独立重试不能因为某个请求卡住就把整个进程阻塞。建议把记录 ID 和请求内容做幂等设计重试时不会产生重复结果。6.3 平台 API 与本地 API 的取舍如果 CoreWeave、Nebius 这类平台提供托管的模型服务你可以直接调用平台 API省去自己维护推理服务的成本。如果平台只提供 GPU 容器你就要自己部署 vLLM、TGI 或 TensorRT-LLM。选择标准也很简单业务是否波峰明显有没有极强的模型定制需求是否需要数据不出内网需要数据不出内网优先自部署推理服务。想快速上线且模型不需要深度定制平台托管 API 的运维成本更低。批量任务量大建议走对象存储 事件触发而不是全部塞在请求里。需要更低延迟尽可能把服务部署在离模型数据更近的区域。7. 资源占用与性能观察算力平台的实测方法7.1 显存占用不是模型文件大小很多新手以为 7B 模型占用显存就是模型权重大小实际上推理时显存至少要留出模型权重、KV Cache、中间激活值和 CUDA context。上下文越长、并发 batch 越大KV Cache 增长越快。因此同一个模型在不同推理配置下占用可能是两倍甚至更多。部署时不要直接给 vLLM 设置--gpu-memory-utilization 1.0建议从 0.85 或 0.9 起步观察一段时间。峰值场景下如果显存打满并出现CUDA out of memory按以下顺序排查降低 batch size、减少 max-model-len、启用更小的量化精度、换用更高显存的卡。7.2 观察维度不只是 GPU 利用率GPU 利用率高不一定代表用户响应快。如果某个请求因等待上一个 batch 完成而排队GPU 可能一直跑满但 API 的 P99 延迟很高。因此至少要看三组指标GPU 侧利用率、功耗、显存占用、温度。服务侧QPS、TTFT、TPOT、P99 延迟、排队长度。网络侧内网带宽、外网流量、丢包率。如果没有部署 Prometheus先用nvidia-smi和推理框架自带的 metrics 做快速观测。vLLM 会暴露/metrics接口可以抓取每秒 token 吞吐相关指标。生产环境再接入监控大盘并设置告警。7.3 如何降低资源占用如果模型推理很吃显存优先尝试这几个方法启用 FlashAttention 或 vLLM 的缓存功能减少 KV Cache 重复计算。使用 AWQ/GPTQ/FP8 量化但注意量化后输出质量需要回归测试。开启 prefix caching让系统 prompt 或公共文档部分复用缓存。在测试阶段降低最大并发数和max_tokens避免显存被长回复占满。长文本离线任务分段处理不要把整本书一次性塞给单次请求。这些优化不一定改变单次请求的准确率但能明显提升单卡吞吐。对批量任务来说吞吐提升等于账单下降因此值得花时间调参。8. 常见问题与排查方法问题现象可能原因排查方式解决方案nvidia-smi不存在容器镜像没装驱动或用的是 CPU 节点在宿主机上执行nvidia-smi换用带 CUDA 的镜像或确认资源确实调度到 GPU 节点能启动服务但模型推理特别慢数据不在同一可用区或网络带宽不足查看跨网传输延迟用iperf3测试内网带宽把数据迁移到 GPU 集群同区域存储模型加载时显存不足模型权重或 KV Cache 超过单卡显存查看启动日志和nvidia-smi降低上下文长度、启用量化、减少 batch、换更大显存机型API 返回 429 或 503并发请求超过推理框架能力查看服务端日志和排队数增大实例数、降低客户端并发、开启自动退避重试容器无法拉取镜像平台网络策略限制外部仓库检查平台网络文档和镜像仓库配置使用平台内置镜像仓库或提前把镜像推到目标环境端口访问超时安全组或集群 Service 没暴露检查监听地址、负载均衡、防火墙把端口绑定到 0.0.0.0 并配置安全组白名单显存持续上涨但不会下降推理服务存在缓存或显存泄漏观察长时间运行后的显存曲线升级框架版本、定期重启无状态服务账单超出预算实例数、存储和流量分布不合理拉取云平台计费明细按项目拆分为任务设置配额提醒给非生产环境设置自动关停排错优先级建议是先看服务日志再查资源监控最后看网络和权限。很多模型服务问题在第一行错误日志里就能找到方向不要一上来就重启实例。重启会掩盖真实原因尤其是显存泄漏和配置错误。9. 最佳实践与合规使用建议9.1 从最小规模开始测试第一次接触某个算力平台不要直接租 8 卡跑全量微调。先租 1 到 2 卡部署一个小模型验证以下流程虚拟机或容器的登录方式、Kubernetes 调度是否顺畅、API 服务能否被外部访问、数据是否可以通过内网传输、账单是否按预期生成。整套流程跑通后再上规模能避免在排错过程中产生大量无意义费用。建议保留一套最小可运行配置包括基础 Dockerfile、启动命令、模型下载脚本和测试请求。这套配置可以作为平台切换时的验证工具也可以给团队内其他成员做参考。9.2 模型、数据、输出分目录管理训练、推理和批量任务都会产生大量文件越早分类越容易排查。建议在对象存储或共享存储里建立三个目录models/放权重和 tokenizerdatasets/放输入和标注数据results/放输出和日志。为每个任务打上批次 ID并在结果文件里记录模型版本、推理参数、平台实例规格和启动时间。这样出现问题时能根据结果文件直接复现而不是反复询问“当时用的是哪个版本”。9.3 权限与隐私合规使用第三方算力平台时要特别关注训练数据是否包含敏感个人信息、商业机密或受版权保护的素材。不要因为数据只在云端临时处理就忽略数据驻留规则。比较稳妥的做法是能脱敏的先脱敏能本地预处理的先本地完成只有必须上云的再上传。涉及人脸、声音、图像素材时必须确认是否有合法授权否则不仅可能违反平台规则还会带来法律风险。算力平台的 API Key、KubeConfig、云凭证要放在密钥管理服务里不要硬编码进代码仓库。对外暴露的推理服务应该设置访问白名单并用网关做限流。若只是内部调试不要把服务直接暴露到公网如果必须公网访问至少添加 Token 校验和 HTTPS。9.4 关注成本而不是只看单价比较不同平台的成本不要只看 GPU 每小时租用价格。还要计算存储费用、出网流量费用、模型下载费用、失败任务重跑费用、人工运维费用。有时候单卡价格稍贵但平台提供了更优的数据缓存和自动扩容能力最后总账单反而更低。因此建议在同一套基准模型、同一个请求集上分别跑一次成本压测记录总耗时和总费用这才是对业务更有意义的指标。10. 结语与后续动作比起猜关系不如把验证流程跑熟回到标题里那个问题CoreWeave、Nebius 这类“英伟达生态伙伴”能持续多久取决于它们能不能把资源稳定交付、价格透明、接口易用。对普通开发者和技术团队来说重要的不是给它们站队而是把下面这几件事落地。先做一次算力平台成本盘点用统一口径列出各平台卡型、显存和小时价格再用一套标准请求集测试部署链路最后把接口 API、批量任务脚本和故障恢复流程沉淀成内部工具。只要这套流程建立起来无论哪个云平台后续涨价、改版或推出新卡你都可以快速做二次评估而不是被新闻标题牵着走。如果你正准备租 GPU 推理建议先收藏这套验证流程。第一批任务不要追求性能最大化先保证显存占用、请求延迟、费用账单都是可观测的。可观测性一旦到位后面优化算力、调整并发、切换平台都会顺手很多。