云端算力与开源大模型齐发力，开发者如何做好选型？

一边是AWS公开表示其全球基础设施新增约200万颗NVIDIA GPU云端算力一下子被抬高了好几个量级另一边是腾讯开源了总参数量达到770B的大模型权重和推理脚本直接公开圈内又多了一个能研究的“大家伙”。两件事单拎出来都是重磅但叠在一起最头疼的反而是我们这些做应用和做产品的开发者。我过去一年帮三家团队做过大模型落地的选型方案上过云、买过卡、也折腾过开源模型的本地部署。每次做选型本质上都在算三本账性能账、成本账、风险账。这两条消息出来后问得最多的两个问题分别是云端算力这么多我是不是不用折腾本地部署了开源模型这么大就算不要钱我到底跑不跑得动这篇不打算给你一个放之四海而皆准的答案那不存在。我更想把从这两件事里读出来的信号加上自己实际选型和部署中的完整判断过程老老实实写下来。无论你现在是个人开发者、创业团队还是公司里的技术负责人看完应该都能自己把账算清楚。1. 先把两则消息翻译成“大白话”1.1 AWS新增200万颗GPU到底意味着什么先看AWS这边。200万颗NVIDIA GPU是什么量级目前公有云里最紧缺的资源就是GPU实例尤其是高性能训练卡。过去经常出现的情况是想租一个P4d或者P5实例控制台界面显示容量不足反复刷新也抢不到。新增200万颗GPU以后这个局面会明显缓解相当于给整个云计算池子注入了一大笔“算力库存”。对开发者来说最直观的影响有三个。第一GPU资源的可及性提高按需实例更容易拿到Spot实例的供应量也会增加第二竞价实例的价格中枢大概率会回落尤其是一些老型号会逐步让位预算有限的个人开发者可以用更低的成本跑实验第三基于这些GPU构建的托管平台比如SageMaker、Bedrock这类服务相应也会释放更多容量使用门槛进一步降低。但也别高兴太早。云算力再多最终都会通过账单变成现实。AWS的GPU实例按小时计费开机就烧钱200万颗解决的是资源供给问题解决不了你对账单的预期管理问题。所以选型工作真正的起点不是“看有没有机器”而是“看我的任务到底需要多少机器”。1.2 770B开源模型是道硬菜再看腾讯这则消息。开源一个总参数量770B的大模型这不是开玩笑的。700B以上是什么概念市面上用得最多的开源模型一般是7B、13B、70B这个参数规模直接往上翻了很多倍。要知道连Llama 3.1 405B都让不少团队的部署预算很紧张770B的模型如果采用MoE架构推理时只激活一部分专家参数计算量能压下来但把所有专家权重完整加载进内存这件事一点都不会少。对开发者而言它的意义在于开源模型的天花板被抬高了。过去必须在闭源企业API和开源小模型之间做二选一的场景现在多了一个“开源大模型”选项。但用它并不是下载一个文件夹那么简单。你必须有足够的显存和内存、有卡间互联带宽、有成熟的推理框架还得有能处理紧急故障的运维能力。开源不等于免费。模型权重不要钱但跑起来的电费、硬件折旧、工程师时间全是成本。所以我说它是一道硬菜饭店里有、食材也好但你的厨房得够大灶台得够火。1.3 为什么这两件事必须放在一起看单独看这两条消息都是技术新闻。放在一起就是一次选型拐点。过去大家默认的决策路径是这样的要快速上线直接用云上现成的大模型API要数据私有就本地部署一个7B或13B的开源小模型。选择很少不太纠结。现在变了。你既可以在云端租大规模GPU集群也可以拿到770B级别的开源权重。于是至少有四种组合同时成立云端闭源API、云端开源大模型、本地开源小模型、本地开源大模型。这四种组合在性能、成本、运维复杂度上的差异非常大。所以现在的选型已经不是“上云还是本地”的二元问题而是四个变量的组合题算力从哪来、模型用哪个、数据放在哪、谁来做运维。下面先把选型必须理解的四个底层逻辑讲清楚再聊具体操作。2. 选型前必懂四个底层问题决定方向2.1 先分清任务类型训练、微调还是推理云上和本地都在买算力但算力买来干什么直接决定选型方向。大模型的真实工作负载可以分成三类预训练、微调、推理。预训练也就是从零开始训练一个超大模型这基本是超大公司或头部研究机构的行为。我们普通团队如果要用770B开源模型大概率不会从头训一遍直接拿现成权重做微调或推理就好。微调是很多团队会做的事。如果要做全参数微调770B模型的显存需求会非常夸张单机几乎不可能。即便是LoRA这类PEFT方法也需要先把base model的全部权重加载进显存这部分占用一点都躲不掉。所以我常跟团队讲微调的成本不是说只看训练增加的参数base model的“地基”费用必须先算上。推理是绝大多数团队真正会长期跑的工作。推理是显存和内存密集型的负载计算量相对训练轻很多但700B的模型光是加载权重就已经很夸张。做选型时先问自己这个项目是长期在线服务还是周期性调优长期服务按推理成本算周期性调优按训练和微调成本算。很多选型错误都源于这个分类没做好把一个推理需求设计成了训练需求白白多花好几倍的钱。2.2 显存需求怎么算给770B模型称重算显存是大模型部署的基本功。我给一个最常用的估算公式模型权重显存约等于 参数量 × 每个参数的字节数拿770B模型来套FP16或BF16每个参数占2字节770B × 2 1540GB约1.5TBFP8每个参数占1字节770GBINT4量化每个参数占0.5字节385GB这还只是模型权重的裸占用。实际部署时还要算上KV Cache、激活值、推理框架自身的额外开销。我做预算时一般按“权重显存 × 1.2到1.5”留余量。以INT4量化为例385GB × 1.3大约是500GB也就是说至少需要6到8张H100 80G才能比较稳妥地跑起来。如果不用量化、直接用BF16跑20张H100起步。这个计算没人能绕过。看完这些数字很多人心里应该有数了770B模型的本地部署绝不是一台游戏电脑或者一台48G显存的工作站能搞定的事。想把它真正用起来要么接受量化要么攒集群要么直接上云租机器。2.3 MoE架构带来的变数再单独说说MoE架构因为大参数模型基本都往这个方向走。MoE的全称是Mixture of Experts核心思路是把网络拆成若干专家子网络推理时根据当前输入的路由结果选择性地激活其中一部分专家。这个设计的好处很明显模型虽然总参数大但单次推理只用一小部分专家参数计算量会远小于同尺寸的Dense密集模型。比如某些总参数400B的MoE模型单token只激活30到50B参数推理速度能接近70B的Dense模型。这也是为什么现在大家敢把模型做到几百B甚至上千B的原因。但MoE不是省显存的魔法。计算时只激活一部分专家权重文件仍然是完整的启动服务时所有专家权重都必须加载到显存或内存里。也就是说MoE解决的是“跑得不慢”的问题没有解决“放不放得下”的问题。很多人以为MoE模型参数大但推理便宜于是租了很小的机器结果启动直接OOM这是我见得太多的翻车现场。所以看到MoE模型要同时评估两个指标总参数量决定显存下限激活参数量决定计算成本。两个都要看缺一不可。2.4 数据安全与合规不是“我以为”接下来是一个非常现实的问题数据能不能出域。把数据发到云端API哪怕是企业级API很多行业也是不允许的。医疗数据、金融数据、政务数据、核心代码仓库这些都有明确的合规红线。有些公司对数据泄密是零容忍宁可让工程师麻烦一点也要本地部署。如果你在这种行业其实选型结果已经被锁死了本地部署或者私有化云没有太多讨论空间。反过来如果业务数据本身不敏感或者已经用脱敏手段处理过把用户请求发到云上API完全没问题那云端方案就是省心省力。很多人会有一种“本地永远最安全”的错觉但自建GPU集群的安全运维风险其实比云上更大因为你是在用自己的设备承担所有安全责任包括机房物理安全、系统补丁、权限管理这些事全得自己扛。数据合规这个问题没有标准答案但必须在选型最开始就问清楚。不要在买好机器之后才发现数据不能出域那是把顺序彻底搞反了。3. 云上GPU选型实操AWS这么挑才不踩坑3.1 先认一认AWS的GPU实例家族假设你决定用云端方案那么第一步是看懂AWS的GPU实例家族。目前主流的实例大致分四个梯队实例族GPU型号单卡显存适合场景G4dnT416GB轻量推理、小模型、图像类服务G5A10G24GB中等推理、SD图像生成、小规模微调P4d/P4deA10040GB/80GB训练、70B级别推理、专业渲染P5/P5eH10080GBLLM训练和推理、大规模微调P6等新系列按区域逐步开放更高显存和互联能力超大模型训练、集群推理还要注意同一系列有不同的实例大小。比如P5.48xlarge是8张H100单实例就能撑起70B级别的模型推理和微调P4d.24xlarge是8张A100 40GB做量化后的70B模型推理也够用。选实例前先把你模型的显存估算出来再倒推需要几张卡这是最不容易出错的方法。如果只是做轻量推理完全没必要上P5。用G4dn跑T4 16GB加载7B模型配合INT8量化刚刚好。这个选择直接决定账单量级T4一小时一两美元H100一小时接近百美元差了五十倍。3.2 三种计费方式的真实账AWS的GPU实例计费主要有三种按需、竞价、Savings Plans。很多人在这一步摔跟头核心原因是没搞懂竞价实例的回收机制。计费方式价格水平稳定性适合场景按需原价永远可用生产环境、紧急需求竞价Spot通常便宜60%到80%可能随时被回收离线批量任务、评测、弹性扩容Savings Plans承诺1年或3年用量约5折稳定长期稳定运行的7×24服务算一笔账P5.48xlarge按需价格大约每小时100美元一天就是2400美元一周168小时接近16.8万美元。如果做的是离线评测、批量推理这类可以容忍中断的任务用Spot实例价格可能只有三到四成一周成本能压到五六万美元。差别非常大。但Spot实例有一个致命机制当竞价价格上涨或者容量不足时AWS可能在两分钟内回收实例。所以凡是跑Spot必须做好检查点。用脚本定期保存模型权重和中间结果任务中断后自动重新拉起。把Spot当按需用的人基本都吃过亏。3.3 AWS部署实战清单这里给一份我实际用过的AWS GPU部署清单照着做能少踩一半坑选择区域。先看目标区域里有哪些GPU实例可用再看数据合规要求。很多新实例只在特定区域开放别等配置完了才发现没有货。选择AMI。别从裸Ubuntu开始配环境直接用AWS的Deep Learning AMI。CUDA、cuDNN、NVIDIA驱动都是预装好的能省至少半天时间。设置安全组。只开放需要的入站端口。GPU实例通常是开发机或服务节点建议通过SSH隧道或跳板机访问不要直接暴露22端口。挂载存储。模型权重动辄几十GB到几百GB建议用EBS gp3或者FSx单独挂载。实例本身本地盘在实例被回收后会丢数据别把权重放上面。启动后验证环境。跑一下nvidia-smi确认GPU型号和驱动版本再跑python -c import torch; print(torch.cuda.is_available())确认PyTorch能调用CUDA。配置监控。CloudWatch里盯住GPU利用率、显存利用率、网络流量否则资源浪费了你都不知道。如果是团队协作建议直接上EKS或SageMaker不要裸EC2。裸EC2对个人实验很灵活一旦变成多人共用环境冲突和依赖管理会非常痛苦。Kubernetes加GPU调度能力能把资源利用率拉起来长期算下来反而省钱。3.4 最容易忽视的隐形费用GPU实例本身贵这是共识。但更气人的是那些“明明关了机器还在扣费”的账单。把EC2实例停了、甚至把ASG的Desired设置为0计算费确实停了但下面这些项目一个都不会少EBS卷实例终止后如果没删卷卷照常按GB月计费。几块大容量EBS卷挂一个月就是几千元。弹性IP只要绑定了弹性IP并且没有释放即使没有关联实例也会按小时收费。NAT网关VPC里如果建了NAT网关即使没有任何任务在跑它照常按小时计费。负载均衡ALB标准ALB即使没有流量也按小时收取固定费用。快照和备份EBS快照、S3存储、日志流都会持续计费。云上省钱的第一原则不是“关实例”而是“清理资源”。我自己的习惯是每次跑完实验用一个脚本把ASG、EC2、EBS、EIP、NAT、ALB全部列出来核对一遍该删的彻底删掉。坚持一个月成本能省百分之三四十。4. 本地部署开源大模型的完整路径4.1 硬件预算先算算你要花多少钱再来看本地部署。如果你决定把开源大模型放到自己机房或办公区硬件预算是一道绕不过去的坎。针对770B这个量级入门配置是8张H100 80G或者8张A100 80G总额通常在百万人民币级别这不是小团队能随便拍板的事。如果退一步只用70B级别的开源模型选择就多很多4张A100 40G可以跑INT4量化2张RTX 4090 24G也能勉强跑量化后的70B模型做实验只是推理速度会比较感人。再往下7B和13B模型用一张RTX 4090或者A6000 48G就能部署得很舒服。不同规模模型对硬件的需求完全不是一个数量级所以先把模型规模定下来再搭硬件这是基本顺序。另外记住一个容易犯的错CPU内存不能太小。大模型启动时权重会先从磁盘载入内存再拷贝到显存。如果机器内存比模型文件还小进程会直接崩溃。我见过有人买了几十万的GPU结果机器只有64G内存加载一个70B模型就内存耗尽来回折腾半天。内存建议至少是模型文件的1.5倍以上有条件直接上1T不亏。4.2 量化是本地部署的命门本地部署大模型绕不开量化。量化的本质是用更少的比特数去表达权重参数换来显存和速度代价是模型输出质量的轻微下降。精度/格式每参数字节质量损失典型使用场景FP16/BF162字节无生产级高精度场景FP81字节可忽略训练和推理都兼顾INT8GPTQ/AWQ1字节很小70B以下模型部署INT4/NF4GGUF Q4_K_M0.5字节可接受低显存部署、单卡场景Q2/Q30.3字节左右明显仅用于应急演示如果要跑770B模型不做INT4量化基本很难落地。主流量化工具是GPTQ、AWQ、GGUF。GPTQ和AWQ适合在GPU环境下做推理加速GGUF则配合llama.cpp这类框架可以在CPU和GPU混合环境里运行。选择哪种格式取决于你用什么推理框架。这里给一个实操经验用llama.cpp跑GGUF量化模型时可以用-ngl参数控制多少层放到GPU上。比如-ngl 999代表全部层都放到GPU第一次跑可以先放一半观察显存占用再逐步调整。很多人问llama.cpp运行怎么才能用上GPU其实就两件事编译时确认开启了CUDA支持然后把-ngl参数调对。就这么简单。4.3 推理框架选型vLLM、llama.cpp、Ollama怎么挑本地部署还有个绕不开的选择推理框架。我常用的三个是vLLM、llama.cpp、Ollama它们各管一段。框架特点适合场景vLLM高吞吐、支持PagedAttention、多卡张量并行生产级服务、大量并发请求llama.cpp跨平台、CPU和GPU混合、GGUF量化本地实验、单机部署、Mac也能跑Ollama一条命令启动、内置模型管理快速验证、开发调试、个人电脑vLLM是我生产环境的首选。它对高并发请求的吞吐优化非常明显可以把一个70B模型的推理吞吐拉得很高同时支持多卡张量并行。启动方式类似这样python -m vllm.entrypoints.openai.api_server \ --model /path/to/model-770b \ --tensor-parallel-size 8 \ --quantization awq \ --gpu-memory-utilization 0.9 \ --port 8000这里--tensor-parallel-size设成8表示把模型切到8张卡上跑--quantization awq表示加载AWQ量化权重--gpu-memory-utilization控制显存占用上限别写成1.0要给系统留点余地。启动之后它提供一个OpenAI兼容的API业务代码几乎不用改就能接入。Ollama则是零门槛工具适合个人笔记本上快速实验。但它的定位是工具不是生产平台大规模并发和多卡集群管理就别指望它了。4.4 从权重到服务的四步走不管用哪个框架部署流程大体一致下载权重。从官方仓库拉取权重文件。770B模型的权重动辄几百GB甚至1TB必须确认网络带宽和磁盘空间都够。转换格式。根据选择的框架把原始权重转成GGUF或GPTQ等格式。用官方脚本或社区转换工具做一次转换把日志路径保留下来方便排查。启动服务。生产环境优先用vLLM或SGLang提供OpenAI兼容API实验环境可以先用Ollama或llama.cpp验证效果。压测调优。用脚本模拟真实并发请求观察显存占用、Token吞吐、首Token延迟。显存压力大时依次调整量化级别、并发数和KV Cache策略。第4步往往最花时间。一个模型刚部署完看起来能跑一压测就现原形有的卡在显存有的卡在网络有的卡在磁盘IO。我的建议是把压测当成上线前的必做动作不要等上线后再补。5. 选型决策矩阵一张表找到你的答案5.1 七个问题快速自测面对各种组合我整理了一张快速自测表按自己的实际情况去判断即可问题倾向云端倾向本地数据能出域吗能出域优先考虑不能出域大概率只能本地并发峰值高且波动大吗云端弹性扩展更香本地要按峰值买机器容易浪费延迟要求有多严格看区域和网络通常够用本地机房间延迟最低预算是按月还是按一次性投入按小时走运营成本一次性硬件投入加运营成本团队有GPU运维能力吗托管服务已封装很多自己维护驱动、调度门槛高要用的模型有多大大模型随便租机器越大越贵必须精确算显存业务生命周期稳定吗适合探索阶段稳定运行后本地更划算注意这不是非黑即白的选择题。同一个团队、同一个项目完全可以分阶段走。我的建议是把这些维度整理成表格给每项赋权重量化再决定。别凭感觉拍脑袋。5.2 四种典型组合方案结合上面的判断我整理出四种比较典型的落地组合方案A纯云端托管API。适合原型验证、数据不敏感、团队没有运维能力的场景。用云厂商托管的大模型API上线最快但单Token成本长期偏高也存在数据出域风险。方案B云端GPU加开源大模型。适合已有技术团队、任务重但暂时不想买机器的场景。在AWS上租用P4d或P5系列用vLLM部署开源模型。优点是灵活弹性大缺点是要把账单控制做好运维能力要求也不低。方案C本地集群加开源大模型。适合强隐私、稳定运行、数据极度敏感的场景。自建8卡集群用vLLM或本地推理平台部署量化模型。优点是数据控制力最强缺点是一次性投入大、运维重。方案D混合架构云端训练评测加本地推理。云端做模型微调、评测、压测稳定后把权重拉到本地部署。兼顾弹性和数据隐私是我在大多数情况下推荐的做法。这四种方案完全不互斥项目在不同阶段可以切换。选型不是一锤子买卖而是给自己预留调整空间。5.3 为什么我建议大多数团队用混合路线我帮团队做选型时很多case最终落在方案D。原因很简单云端和本地解决的问题不一样。云端解决的是“今天就要跑起来”和“突然来100倍流量”的问题本地解决的是“数据不能出去”和“长期运行成本要压下来”的问题。这两个需求经常同时存在。更实际的做法是先用云端按需GPU做一轮小样本评测确认开源模型量化版本在业务效果上达标然后用Spot实例跑离线任务和周期性微调最后把验证过的模型权重和配置同步到本地集群用于生产推理。云端当测试场本地当生产场。这样既不会因为迁到本地而错过业务上线节奏也不会因为一直跑在云端而被账单拖垮。6. 常见问题与排查技巧实录6.1 ASG的Desired设为0之后为什么账单还在跳这个坑我见过太多人踩了单独拿出来说。ASG的Desired设为0意味着它把管理的EC2实例全部终止计算费用确实停了。但ASG管不到的附属资源还在继续扣费实例终止但EBS卷没删。很多自定义启动配置不会自动勾选“删除实例时删除卷”这些卷会变成孤立EBS卷按GB月计费。弹性IP没释放。绑定状态下的EIP按小时收费即使没有关联实例保留也可能产生费用。NAT网关、ALB、快照、S3存储。全部按资源存在时间持续计费。排查方法很直接打开Cost Explorer按服务维度看计费最高的项目顺着账单里的资源ID去对应控制台检查。最快的办法是给每个实验环境打Tag按Tag看成本归属。没有Tag的云环境账就是一笔糊涂账。6.2 显存不足的三种表现与应对显存不足是本地部署和云端部署都会遇到的常见问题表现不止“CUDA out of memory”这一种表现可能原因处理方式启动时直接OOM权重加载超出了显存容量降低量化级别、增加GPU数量跑一段时间后OOMKV Cache不断累积降低max-seq-len、调小并发数请求变慢但无报错显存碎片化导致有效空间不足开启KV Cache自动合并、调低gpu-memory-utilizationKV Cache是最容易被忽略的部分。单条长文本请求会占掉大量KV Cache再叠加并发显存会快速上涨。解决思路是限制单次请求的最大Token数同时用PagedAttention这类机制减少碎片。在vLLM里对应的是--max-model-len参数实际部署我一般会设成业务最长输入再乘1.2而不是直接用模型上限。6.3 驱动、CUDA、框架三方版本不匹配本地部署最崩溃的时刻刚装好PyTorchimport torch报错说CUDA driver版本太老或者nvidia-smi显示驱动正常但容器里却找不到GPU。这些基本都是版本匹配问题。我的标准做法是用官方深度学习镜像把环境固定住避免每次重新找版本。比如docker run --gpus all -it --shm-size16g \ -v /data/models:/models \ pytorch/pytorch:2.3.1-cuda12.1-cudnn8-runtime这样驱动、CUDA、PyTorch版本都由镜像统一管理宿主机只需要保证NVIDIA驱动支持容器即可。如果非要在裸机上装记住一个原则CUDA Toolkit版本和显卡驱动不是一回事PyTorch要匹配CUDA版本CUDA要匹配驱动版本。依次检查nvidia-smi给出的驱动支持的最高CUDA版本然后按这个版本选择PyTorch安装包。6.4 开源模型License与商用边界最后说一个很多人都会忽略的点开源模型不等于可以随便商用。开源模型也有不同的许可证有的允许商用但要报备有的对月活用户数有限制有的只是开放了权重代码和训练数据不一定开放。怎么自查下载模型时看官方仓库里的LICENSE或MODEL_LICENSE文件有疑问就直接咨询法务。尤其是要把它集成到对外商业产品里的场景License问题不是小事。我见过不止一个团队产品做到一半发现模型License不允许商用只能推翻重选。这不算技术问题但它就是选型的一部分而且是被忽视最多的一部分。选型如果不把License算进去后面付出的代价比选错硬件还大。最后分享一点我自己实际在做的事情。这两条消息出来之后我手上几个项目不约而同回到了同一个路线先用云端把效果和成本测出来再用本地把稳定性和隐私管起来。别被“200万颗GPU”吓到也别被“770B开源模型”迷住真正决定选型的始终是数据、预算和团队能力这三件事。另外送一个小技巧如果你不确定一个模型在你业务上的效果别急着买大机器。先用云上一张卡跑一个量化小版本用真实业务样本打几十个批次的分数效果达标再进生产环境。这个流程能帮你省至少一个月的踩坑时间。希望这篇能让大家少烧钱少加班。