1. 先把“显存墙”这件事拆开96GB 到底卡在哪个环节RTX PRO 6000 这卡去年渠道价还在七八万区间晃今年一路摸到 11 万问了几家代理回答基本一致现货不多排队要等加价才有。奇怪的地方在于这不是消费级显卡那种被游戏和矿潮推着走的价格曲线而是一张面向专业工作站的卡买它的人大多不是装机打游戏而是拿它去跑模型、做渲染、跑仿真。价格涨成这样还在抢说明它解决的不是“性能快一点”的问题而是“这件事没有它就做不成”的问题。我把这半年接触到的实际用例捋了一遍从本地大模型推理、影视渲染农场、工业仿真到医疗影像重建发现大家嘴里说的“96GB 显存”本质上指向同一个东西显存墙。算力不够可以等可以排队可以降精度慢慢跑显存不够程序直接报错退出连跑的机会都没有。这就是它和算力瓶颈最本质的区别——算力决定了你多久出结果显存决定了你能不能出结果。这篇内容适合三类人看正在评估要不要上这张卡的技术负责人手里有多卡方案但被通信和调度折磨过的工程师以及单纯想知道“96GB 到底能干什么”的从业者。我会把显存的账一笔一笔算给你看把涨价背后的成本逻辑拆开也会写清楚拿到卡之后怎么配置才不浪费这 96GB。技术细节我会尽量给到能直接抄作业的程度涉及具体参数的地方都会说明为什么这么取。1.1 一次显存溢出报错引出的四个账本先讲个真实场景。某团队做本地推理服务用的是四张 24GB 消费级卡拼起来的方案模型是一个 70B 级的稠密模型量化到 4bit 之后权重占用大概 35GB看起来四张卡加起来 96GB绰绰有余。结果上线第一天就崩了报的是显存不足。他们一开始以为是权重放不下查了半天发现权重确实放得下问题出在别的地方。显存占用从来不是一个数而是四本账加在一起模型权重参数量乘以每个参数的字节数。fp16 是 2 字节int8 是 1 字节int4 是 0.5 字节。这是最容易算、也最容易被高估的一部分。KV Cache推理时缓存历史 token 的键值对随上下文长度和并发数线性增长。这部分是真正的隐形杀手很多人只算权重上线之后被它撑爆。激活值与临时缓冲前向计算过程中的中间结果尤其是长序列场景下的注意力矩阵短上下文时不起眼长上下文时能吃掉十几 GB。框架与运行时开销CUDA context、通信缓冲、内存池碎片、显存分配器的预留空间。这部分最玄学通常按总显存的 5% 到 10% 预留实际踩坑时可能更多。那个团队崩溃的原因就是第二本账。他们把上下文开到 32K并发开到 16KV Cache 直接把剩下的 60GB 吃干净了再加上多卡张量并行时的通信缓冲最后一张卡先 OOM整个服务挂掉。多卡方案最难受的地方就在这里显存是分片的任何一张卡先满整个任务就死不会因为你别的卡还有空余就宽容一点。1.2 权重、KV Cache、激活、框架开销的占比实测我把同一套模型在不同配置下的显存分布做了个粗略统计用的是 70B 级稠密模型4bit 量化上下文 8K并发 8数据来自实际压测时的显存采样不是理论推算占用项显存占用GB占比备注模型权重4bit约 3643%含量化零点与缩放因子KV Cache8K 上下文 × 8 并发约 3440%与层数、KV 头数强相关激活与临时缓冲约 67%随 batch 波动框架与通信开销约 810%多卡时更高这张表最值得盯的是第二行。权重是固定的KV Cache 是活的你改一个参数它就能翻倍。很多人买卡的时候按权重算容量用起来才发现真正的瓶颈在 KV Cache 上。这也解释了为什么 96GB 比“两个 48GB”有价值得多——不是容量数字的差别是能不能把权重和长上下文的 KV Cache 放在同一块显存里、省掉跨卡搬运的差别。顺带说一句显存分配器的工作方式也影响实际可用量。主流框架启动时会预分配一大块显存作为内存池池子一旦按峰值撑开就不会立刻还回去所以你在监控里看到的“已用显存”往往比真实需求高。判断是否真的吃紧要看长时间稳定运行后的水位而不是启动瞬间的数字。2. 96GB 的账怎么算几个典型场景的显存预算表买卡之前最该干的事不是看评测跑分而是坐下来把显存预算算清楚。算错这一步后面所有的选型讨论都是空的。我见过太多团队按“参数量除以二”这种简化公式拍脑袋结果要么买大了浪费预算要么买小了天天救火。2.1 参数量到显存的换算公式与误差来源基础公式很简单权重显存(GB) ≈ 参数量(B) × 每参数字节数 × 1.05量化元数据与对齐开销举几个常见档位7B 模型fp167 × 2 × 1.05 ≈ 14.7GB32B 模型fp1632 × 2 × 1.05 ≈ 67GB70B 模型fp1670 × 2 × 1.05 ≈ 147GB70B 模型int870 × 1 × 1.05 ≈ 73.5GB70B 模型int470 × 0.5 × 1.05 ≈ 36.8GB这里有几个误差来源必须知道。第一4bit 量化不是精确的 0.5 字节实际实现里有分组缩放因子、零点、以及部分层保持高精度的策略通常要比理论值多出 5% 到 15%。第二嵌入层和输出层往往不参与量化参数量大的模型这两层能占好几个 GB。第三词表大小影响嵌入矩阵多语言模型的词表动辄十几万这块开销不能忽略。我自己的习惯是按理论值上浮 20% 做预算宁可留出余量也不要上线之后因为几百 MB 的差距反复调参。显存这东西和硬盘不一样没有“压缩一下再塞进去”的余地差一点就是差一点。2.2 70B 稠密模型单卡与四卡的分水岭还是拿 70B 稠密模型举例把几种典型配置的账算全配置方案权重KV Cache8K × 8 并发激活与开销合计可行性单卡 24GBint436.8无法容纳——不可行双卡 24GBint436.8分片分片后每卡约 17约 6约 60勉强无余量四卡 24GBint436.8分片分片后每卡约 8.5约 10约 55可行但通信开销大单卡 48GBint436.8约 34约 6约 77不可行超容单卡 96GBint436.8约 34约 6约 77可行余 19GB这张表把问题说得很清楚了。四卡 24GB 的方案和单卡 96GB 方案理论总容量都是 96GB但前者在权重分片、通信缓冲、调度开销上要多付出接近 10GB 的代价实际可用余量只有十几个 GB而后者能留出将近 20GB 的余量。更关键的是多卡方案里每一层的前向计算都要做一次跨卡同步70B 模型七八十层一层一次延迟累加起来非常可观。我用过类似的四卡消费级方案跑推理吞吐只有单卡大显存方案的六成左右还得额外维护张量并行的配置出问题时排查难度翻倍。再看 32B 模型的情况这个档位最能体现 96GB 的价值配置方案精度权重长上下文32KKV Cache结论单卡 48GBint416.8约 20只能跑短上下文单卡 48GBfp1667—放不下单卡 96GBfp1667约 20长上下文可行余 9GB单卡 96GBint416.8约 20可以开大并发余 50GB 以上48GB 卡跑 32B 模型只能上 4bit精度损失摆在那96GB 卡可以直接上 fp16还能带 32K 上下文。对于那些对量化敏感的任务——比如需要精确数值推理、代码生成、结构化输出——这个差别是决定性的。量化不是免费的午餐4bit 在某些任务上掉点很明显能上高精度就上高精度这是 96GB 最直接的溢价来源。2.3 长上下文与 MoE 场景下 KV Cache 的放大效应KV Cache 的计算公式值得单独拿出来说因为它是最容易失控的一项KV Cache 字节数 2 × 层数 × KV头数 × head_dim × 序列长度 × 并发数 × 字节数注意这里用的是KV 头数不是注意力头数。用了分组查询注意力的模型KV 头数可能只有注意力头数的几分之一这一项能省下大量显存。举个具体例子一个 80 层、64 个注意力头、head_dim 为 128、KV 头数为 8 的模型每 token 每层的 KV 占用 2 × 8 × 128 × 2 字节 4KB每 token 全模型 4KB × 80 320KB32K 上下文单并发 320KB × 32768 ≈ 10.5GB32K 上下文 8 并发 约 84GB单并发 10.5GB 看着还行八并发直接飙到 84GB。这就是为什么长上下文服务对显存的渴求是超线性的上下文长度翻倍KV Cache 跟着翻倍并发再翻倍直接四倍。96GB 的卡能撑住 32K 上下文加中等并发48GB 的卡在这个场景下连单并发都紧张。MoE 架构是另一个放大器。总参数几百 B、激活参数几十 B 的模型权重占用按总参数算激活按实际路由算看起来存储效率高但实际部署时有个坑专家分布不均会导致显存访问热点某些专家被频繁命中所在显存的带宽压力陡增而其他专家所在区域闲置。这种情况下多卡方案更难受因为专家并行需要额外的 All-to-All 通信对互联带宽要求极高。单卡 96GB 在这类模型上虽然也放不下完整的大 MoE但能放下中等规模的 MoE 或者大 MoE 的单机分片省掉跨机通信这一层麻烦。3. 涨价还被抢的真实原因四类买家和一笔隐性成本账价格从七八万涨到 11 万涨幅接近四成按常理需求该萎缩了。但实际情况是排队的人更多了。这个反常现象背后是需求侧结构发生了变化——买的不是同一批人买的理由也不一样了。3.1 买家画像不只是做推理的我把接触到的采购方归了归类大致四类第一类本地化推理服务商。这类客户最看重的是单机部署能力和数据不出域。他们的客户往往对数据流向有硬性要求模型必须跑在自己的机房里。一台机器塞一张 96GB 卡能顶过去一个四卡小集群机位、功耗、运维成本全省下来。他们算的账是这样的四卡方案整机功耗接近 2000W单卡方案 600W 出头按工业电价和三年周期算电费差价能抵掉相当一部分购卡成本还不算机房空间和故障率。第二类影视与设计渲染。这个群体对显存的需求和 AI 圈不太一样他们要的是场景资产能完整驻留显存。一个复杂的三维场景贴图、几何、光照缓存加起来轻松超过 40GB48GB 卡在渲染高分辨率帧时频繁触发显存换出速度断崖式下跌。96GB 能让整个场景常驻渲染农场的单帧时间能压下来三成以上。这类客户对价格不敏感因为他们的成本大头是人力机器贵几万块项目周期缩短两周就赚回来了。第三类工业仿真与科学计算。有限元分析、流体仿真、分子动力学这类任务网格规模一大显存需求是指数级往上走的。以前的做法是降精度或者拆分区精度损失直接影响结论可信度。96GB 让他们能把网格规模提上去或者把双精度计算的比例调高。这类任务还有个特点跑一次可能要几十小时中途 OOM 就是几十小时白费所以他们对显存余量的要求格外保守。第四类研发团队的自建训练与小规模微调。全量微调大模型不现实但参数高效微调和中等规模模型的继续预训练是刚需。96GB 能支撑 32B 级模型的全参数微调配合优化器状态分片和梯度检查点或者 70B 级模型的低秩微调这在以前需要至少两张 80GB 卡才能做。这四类买家有个共同点他们买的不是算力峰值买的是“一次跑通”的确定性。项目周期、交付节点、实验可复现性这些东西的价值远超几万块的差价。3.2 四张 24GB 拼不出 96GB多卡的隐性成本清单很多人的第一反应是既然 96GB 这么贵我用四张 24GB 拼不行吗总价便宜一半还多。这个想法在纸面上成立实际落地时会撞上一堆隐性成本。我把踩过的坑列成清单成本项单卡 96GB四卡 24GB 并联差异说明卡本身11 万约 6 万差价约 5 万主板与平台单路即可需要多 PCIe 插槽平台贵差价 1 万以上电源850W 够用需 1600W 以上且要高品质差价 3000 元机箱与散热常规需大机箱、强风道差价 2000 元通信开销无张量并行同步延迟吞吐损失 20% 到 40%显存可用率约 90%约 75%分片与缓冲实际可用差 15GB 以上故障排查单点定位多卡状态耦合难定位排障时间翻倍模型兼容性基本无坑部分算子对多卡支持不佳需要改代码适配这张表最后两行才是真正的成本。多卡方案的复杂性是随卡数非线性增长的两张卡调通可能花半天四张卡调通可能要一周中间会遇到各种奇奇怪怪的问题某个算子在特定并行策略下结果不对、通信库版本不匹配、某张卡因为散热问题降频拖慢整体、显存碎片导致长跑之后突然 OOM。我见过一个团队为了调通四卡推理前后花了一个多月人力成本早就超过省下的那五万块了。还有一点经常被忽略四张 24GB 卡的显存是不连续的模型必须切分切分就意味着某些层需要跨卡读取参数层与层之间的数据传输全靠互联带宽。消费级平台普遍是 PCIe 通道带宽比专业卡之间的高速互联差一个数量级。推理时每生成一个 token 都要走一遍这个链路延迟累积起来非常明显。实测下来四卡 PCIe 方案跑 70B 模型单 token 延迟比单卡方案高出 60% 以上。所以那句“涨价还被抢”就有了合理解释在这个价位段能提供 96GB 单卡可用显存且没有替代方案的产品基本就这一张。供需关系摆在那里价格自然往上走。上一代专业卡是 48GB再往上要跨到数据中心级产品价格和形态完全是另一个量级。中间这个空档被 RTX PRO 6000 结结实实地占住了。4. 拿到卡之后把 96GB 真正吃满的配置实操卡买回来不等于能用好。我见过太多案例96GB 的卡按 24GB 卡的思路配置显存利用率长期停在四成等于花了大价钱只用了小部分。下面这套流程是我自己反复验证过的从开箱验证到长稳压测可以直接照着做。4.1 上电验证与基线压测第一步永远是确认卡是好的、驱动是干净的。别急着装框架先把基础环境验一遍。# 查看卡的基本信息与显存总量 nvidia-smi --query-gpuname,memory.total,memory.used,driver_version --formatcsv # 持续采样观察是否有掉卡或降频 nvidia-smi --query-gputimestamp,temperature.gpu,power.draw,clocks.sm,memory.used \ --formatcsv -l 2几个关键的观察点。第一显存总量应该显示接近 96GB 的可用值专业卡通常不会有消费级那种大幅预留但仍会有一小部分被系统占用实际可用在 93GB 到 95GB 之间属于正常。第二跑满负载看功耗和温度专业卡的散热设计一般比较扎实但如果装在风道不好的机箱里温度上到 85 度以上就会开始降频性能直接打八折。第三看 PCIe 链路宽度用nvidia-smi -q查 Link Width如果是 x8 而不是 x16说明插槽或主板有问题带宽减半会影响模型加载速度和跨设备传输。基线压测我一般用两个工具一个简单的矩阵乘法基准测算力是否达标一个显存填充测试测实际可用容量。import torch # 逐步申请显存找到真实的可用上限 device torch.device(cuda:0) tensors [] allocated 0 step 1024 # 每次申请 1GB try: while True: t torch.empty(step * 1024 * 1024, dtypetorch.uint8, devicedevice) t.fill_(1) tensors.append(t) allocated step if allocated % 10240 0: print(f已分配 {allocated} MB) except RuntimeError as e: print(f在 {allocated} MB 处触顶{e})这个测试能告诉你真实可用显存比看规格书有用。我测过的一张卡标称 96GB实际能稳定分配 94.2GB剩下的是运行时固定占用。做预算的时候按这个实测值算不要按标称值算。4.2 推理服务的关键参数怎么定推理框架的参数配置是显存利用率的决定因素。以主流的连续批处理框架为例几个参数必须理解透# 启动参数示例框架名称与具体字段以实际版本为准 python -m serve \ --model /path/to/model \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.92 \ --max-model-len 32768 \ --max-num-seqs 24 \ --kv-cache-dtype auto \ --enable-chunked-prefillgpu-memory-utilization是最关键的一个。它的含义是框架可以占用单卡显存的百分比。默认值通常偏低很多人不动它结果显存只用了一半。设到 0.90 到 0.94 之间比较稳妥留出的 6% 到 10% 给框架运行时、CUDA context 和其他进程。设到 0.98 虽然在空载时能启动但一旦有其他进程或显存碎片立刻 OOM。我自己在纯推理专用机器上用 0.92在和别的任务混跑的机器上用 0.85。max-model-len决定 KV Cache 的上限。这个值设得越大框架预留的 KV Cache 空间越多能支持的并发就越少是此消彼长的关系。设 32K 时并发可能只有十几个设 8K 时并发能到四十以上。怎么定看你的实际业务分布如果 95% 的请求都在 4K 以内就没必要为那 5% 的长请求牺牲整体吞吐可以单独部署一个长上下文实例做分流。max-num-seqs控制同时处理的请求数上限。这个值和 KV Cache 直接挂钩设太大只会让调度器在显存边缘反复挣扎反而降低吞吐。我的经验值是先按max-model-len算出单请求的最大 KV 占用再用可用显存除以它得到的数字打七折作为初始值然后根据压测结果上下调。kv-cache-dtype可以设成 fp8能省一半 KV Cache 显存代价是极小的精度损失。在长上下文场景下这个开关非常值多出来的显存可以换更高的并发。我在几个任务上对比过fp8 的 KV Cache 在生成质量上的差异基本感知不到但并发能力能提升接近一倍。还有一个容易被忽略的chunked prefill。开启之后长 prompt 的预填充会被切块处理避免单个超长请求瞬间吃满显存把其他请求挤死。对于请求长度分布很分散的场景这个开关能显著降低尾延迟。4.3 显存监控与长稳压测配置好只是开始能不能稳住要看长跑。我做压测的标准流程是这样的先做阶梯式并发测试从 1 并发开始每 5 分钟翻倍观察显存水位和延迟曲线的变化。正常情况下显存水位会在某一档稳定下来延迟随并发上升到某个点后开始陡增那个拐点就是这台机器的实际容量上限。拐点之前是舒适区拐点之后是排队区压测的目的就是找到这个拐点并留出 30% 的余量。再做长稳测试按拐点的七成负载连续跑 24 小时重点看三个指标显存水位是否缓慢爬升如果有说明存在泄漏或碎片累积、不同请求之间的延迟方差是否变大、是否有间歇性的 OOM 但没有导致服务崩溃。第三种情况最阴险框架可能捕获异常后重试表面上服务正常实际上部分请求一直在失败。import subprocess, time, csv def sample(interval5, duration3600): with open(mem_log.csv, w, newline) as f: w csv.writer(f) w.writerow([ts, used_mb, total_mb, util]) end time.time() duration while time.time() end: out subprocess.check_output([ nvidia-smi, --query-gpumemory.used,memory.total,utilization.gpu, --formatcsv,noheader,nounits ]).decode().strip().split(, ) w.writerow([int(time.time()), out[0], out[1], out[2]]) time.sleep(interval) sample()这个脚本跑一晚上第二天看 used_mb 的曲线。健康的曲线是锯齿状的随请求波动但整体水平线不抬升不健康的曲线是台阶状缓慢上爬那就是有问题。遇到爬升先别怀疑框架八成是自己的代码里有什么持有引用的地方没释放或者日志、缓存对象越积越多。我遇到过一次是日志模块把每个请求的中间张量都存了一份做调试忘了关跑十个小时之后显存涨了 8GB。5. 常见问题与排查实录显存问题最烦人的地方是现象相似、原因各异。同一个 OOM 报错可能是参数配错、可能是内存碎片、可能是多进程抢卡、也可能是代码泄漏。我把自己踩过的和帮别人排查过的整理成一套分类方法按现象反推原因比盲目试参数快得多。5.1 显存明明够却 OOM 的五种情况第一种启动时 OOM但显存监控显示占用不高。这是典型的预分配问题。框架启动时会按gpu-memory-utilization一次性申请一大块显存作为内存池如果这个值设得太接近 1.0预分配本身就会失败。解决方法是降到 0.9 以下或者检查是否有其他进程占着显存没释放。用nvidia-smi看进程列表经常能发现上次异常退出的残留进程还在占着几个 GB。第二种跑一段时间后 OOM重启就好。九成是显存碎片。频繁申请释放不同大小的显存块分配器找不到连续空间即使总空闲量足够也分配不出来。缓解办法是尽量让请求的输入长度接近避免忽长忽短开启框架的内存池复用机制实在不行就设个定时重启虽然土但有效。第三种单请求正常并发一上来就 OOM。这就是 KV Cache 的账没算对。并发数乘以单请求最大 KV 占用超过可用显存就必然出问题。很多人只按平均长度算忽略了长尾请求。解决办法是给请求长度设上限超过的截断或走异步队列同时把max-num-seqs调低到安全值。第四种加载模型时 OOM但模型权重明明放得下。注意检查加载过程中的峰值占用。有些实现会先把权重加载到 CPU 再逐层搬到显存峰值时 CPU 和显存各有一份有些会先加载 fp16 再量化中间峰值是最终占用的两倍。加载阶段的峰值往往是稳态的两倍以上96GB 的卡加载 70B fp16 模型时如果中间不做流式加载很容易在加载途中就爆掉。第五种多卡环境下某一张卡 OOM其他卡还有空。这是负载不均或者通信缓冲分配不均。张量并行时每个卡负责的层数应该一致但如果模型层数不能被卡数整除最后一张卡会多担一层显存占用略高。解决办法是选层数能被卡数整除的模型或者手动调整切分策略。5.2 速查表现象最可能原因快速验证方法处理方式启动即 OOM显存被残留进程占用nvidia-smi查进程列表清理进程或重启启动即 OOM预分配比例过高降低 utilization 重试调到 0.90 以下长跑后 OOM显存碎片观察空闲总量够但分配失败统一请求长度、定时重启并发升高 OOMKV Cache 超预算用公式估算峰值降并发或降上下文长度加载中 OOM加载峰值过高监控加载阶段显存曲线启用流式加载或分片加载单卡 OOM 其他卡空闲切分不均或通信缓冲查每卡显存占用曲线调整切分或换模型显存缓慢爬升代码持有引用未释放长跑采样对比排查缓存与日志对象温度高时性能骤降散热不足触发降频监控温度与频率改善风道、限制功耗这张表建议打印出来贴机房。我个人的经验是八成的显存问题在表的前三行真正需要深入排查的复杂情况并不多。遇到问题先按现象定位到可能原因再做一次验证比漫无目的地调参数效率高得多。还有一条避坑经验值得单独说不要在生产环境上直接改参数试。显存相关的参数改动往往有滞后效应改完当时看着正常跑几个小时才暴露问题。我习惯的做法是先在测试机上用相同配置压测两小时确认曲线平稳再上生产这个习惯帮我避免过好几次半夜被叫起来的事故。6. 采购决策什么情况下这 11 万该花什么情况下不该聊到这里该说说钱的事了。11 万不是小数目尤其在预算收紧的时候怎么证明这笔投入合理是每个技术负责人要面对的问题。我的看法是这张卡不是万能解它在特定场景下无可替代在其他场景下则是明显的过度配置。6.1 三类不该买的场景第一类只做小模型推理的场景。如果业务用的都是 7B 到 14B 级别的模型24GB 的消费级卡完全够用甚至能同时跑好几个实例。这种情况下买 96GB 的卡等于用四倍的钱换四倍的空闲显存利用率长期在 20% 以下纯属浪费。判断标准很简单把权重的显存占用乘以二如果结果远小于 48GB那就没必要看这张卡。第二类算力瓶颈而非显存瓶颈的场景。有些任务显存占用不高但计算量极大比如大规模矩阵运算、批量图像处理。这类任务的瓶颈在算力单元不在显存容量买大显存的卡反而单位算力的性价比更低。这时候多卡小显存的方案更合适或者干脆上云端按需付费。第三类负载波动极大的场景。如果业务有明显的波峰波谷比如只在白天有请求、晚上空转那自购硬件的利用率会很难看。这种情况下云端的弹性计费更划算虽然单价高但只为实际用量付费总体成本可能更低。我自己测算过负载利用率低于 40% 的场景云端方案的综合成本通常更优。6.2 自购、租赁与云端的取舍这三条路的取舍核心是算一笔三年周期的总拥有成本账。维度自购长期租赁云端按需初始投入高11 万 平台低无月度成本电费与运维固定租金按用量计费利用率要求需 50% 以上才划算需 60% 以上无要求数据可控性完全可控较好视方案而定弹性无有限强硬件迭代风险自担转移给出租方转移给云方适合场景稳定高负载、数据敏感中期项目、试用验证波峰波谷、短期项目自购的最大优势是边际成本趋零买回来之后跑得越多越划算。如果一台机器能常年保持七成以上利用率两年左右就能摊平购机成本之后全是净收益。租赁适合那些不确定需求能持续多久的项目先租三个月验证业务模型跑通了再决定买不买。云端适合验证阶段和突发需求但长期跑下来账单会很吓人我见过一个团队用云端跑常驻推理服务月账单超过自购机器的一年折旧。还有一个折中方案值得考虑买一台自用云端做溢出。核心业务放在自购机器上保底突发流量走云端这样既控制了固定成本又保留了弹性。这套架构的关键是把模型分发和请求路由做统一保证两边行为一致不然调试起来会很痛苦。我个人在这件事上的体会是硬件采购决策从来不是纯技术问题而是对业务增长曲线的一次下注。如果你相信未来两年显存需求只会涨不会跌那现在这个价位买入是合理的因为需求一旦涨上去96GB 不够用的时候你要面对的不只是再花 11 万还有重新设计整套部署架构的代价。反过来如果需求大概率持平甚至收缩那就老老实实租或者用云把钱留给更确定的地方。最后分享一个我在选型时常用的小技巧别按当前需求买按一年后的需求买但别按三年后的买。按当前需求买半年后就会捉襟见肘按三年后买大部分容量在折旧周期里空转。一年这个尺度刚刚好既能覆盖业务的自然增长又不至于过度投资。这条经验在显存这种“差一点都不行”的资源上比在任何其他地方都更管用。
