nvidia l20 gpu避坑，从选型到落地的完整流程说明

准备上 L20 跑推理或者微调，最容易卡在几个地方：显存够不够、租来的卡是不是真卡、报价口径对不齐、算力账算糊。这篇按「先定需求、再看规格、再比价格口径、最后验收」的顺序给判断标准和可执行动作，涉及具体数字的地方都指到站内页面去核。

准备上 L20 跑推理或者微调，最容易卡住的地方其实不是卡本身，而是几个前置问题没想清楚：显存够不够、租来的卡是不是真卡、几家的报价口径对不齐、跑起来之后算力账算糊。这篇按「先定需求、再看规格、再比价格口径、最后验收和切换」的顺序，把每步的判断标准和可执行动作讲一遍。涉及具体数字的地方不写死，都指到站内页面去核当时的数。

先说明一点：这篇不替你决定要不要选 L20，只帮你在选它的过程中少踩坑。判断类的内容都会写清什么情况下不适用，别硬套。真到要下单或者切流量的那一步，去站内对应的页面把当时的数字和条款翻出来，比看任何总结都靠谱。

第一步不是看卡，是先把自己的需求钉死

很多人上来就比参数、比报价，结果买完发现模型加载都费劲。正确的顺序是先把用途钉死：在线推理、批量离线推理、微调、训练，这四类活对显存和带宽的要求完全不一样。在线推理怕延迟抖动，批量推理怕显存装不下，微调怕显存和带宽一起不够，训练还额外吃卡间互联。先说清是哪一类，后面的规格才有意义。

接着把三个输入量化出来：模型参数量和精度、并发数和上下文长度、可接受的延迟范围。这三项不定，显存留多少余量就是拍脑袋。判断标准是：模型权重加 KV 缓存加框架自身开销，加起来占不满显存，才谈得上稳定；余量按并发峰值的 KV 缓存估，而不是按平均值估。

• 用途先写死：在线推理 / 批量离线推理 / 微调 / 训练，四选一，别写「都行」
• 模型参数量和精度写清楚，权重占多少显存先粗算一遍
• 并发峰值和上下文长度写清楚，KV 缓存按峰值估不按均值估
• 可接受的延迟范围给一个区间，别用「越快越好」这种话
• 什么情况下不适用：大并发长上下文，或者要在卡上做训练，这类卡本身不是首选，别硬凑

对照规格表看它到底适合什么活

需求钉死之后再去对规格。到 /compute/gpus 看加速卡的显存容量、显存带宽、互联方式和精度支持，别只盯「显存多少 G」一个数。推理吃带宽和显存，训练吃带宽加卡间互联，同一张卡在这两件事上的体验差别可能很大。规格表里的互联方式那一栏，尤其别跳过。

这里要区分「能跑」和「跑得舒服」。单请求跑通是一回事，稳定服务多个用户是另一回事。判断标准很简单：拿真实业务的请求样本跑一轮，看延迟分布的长尾，而不是看平均延迟。平均好看、长尾抽搐，上线后挨骂的是你。

报价口径先对齐，再谈贵不贵

报价是最容易糊的地方。按小时、按天、按月、按时长包段的报价不能直接比，先换成同一单位再对比。到 /compute/price-index 看租金的涨跌趋势，到 /compute/gpu-rental 做同规格比价，把不同口径的报价拉到一张表里再说贵不贵。

比价之前，先把清单里要问清的项列出来：是否独占、是否含带宽、是否含存储、超时怎么算、断线怎么计费。这几项任何一项含糊，最后的账单都可能和你的预期差一截。判断标准是：同一份清单问三家，能逐项对齐的才拿来比价。

• 是否独占整卡，还是共享算力
• 是否含带宽，超出怎么计
• 是否含存储，容量和读写有没有限制
• 超时和断线怎么计费，按分钟还是按小时
• 什么情况下不适用：只是短时试跑，包段单价再低也没意义，按小时更划算

买卡还是租卡：三年账怎么摆

买还是租，别凭感觉。到 /compute/tco 用三年周期把购卡、电费、机位、运维、折旧放进同一张表里算。判断标准是使用率：长期满载，自购才可能划算；使用率低于一半的场景，租基本不会输。这个结论对大多数团队都成立，别被单卡报价迷惑。

别漏隐性成本。电费口径到 /compute/power 看，自建还要算上人力和备件。还有一个不适用场景要记住：团队没有运维能力时，哪怕账面上自购更便宜，也不建议，停机损失和排障时间比省下的钱更贵。

使用率

实际跑业务的时长占理论可用时长的比例，是买租决策的分水岭

隐性成本

电费、机位、人力、备件、停机损失，账面之外的那一截

空转

卡开着但没跑有效负载的时间，常常是账单里最大的一笔

到手先验，别急着把业务切上去

卡到手或者实例开通后，先验再付长约。验证顺序是：先跑一次显存识别和型号确认，再跑稳定性压测，最后跑真实业务请求。到 /tools/verify 和 /tools/verify#probes 了解怎么判断一台机器是不是宣传的那台，探测项别只看显存一个数。

验的过程中要记录基线：延迟、吞吐、显存占用曲线。后面出问题才有对比物。判断标准很直接：压测中出现降频、掉卡、显存占用异常增长，先别签长约，先让服务方解释清楚再说。

1. 确认型号和显存跑一遍识别命令，确认型号、显存容量和驱动版本与宣传一致，截图留档
2. 跑稳定性压测用接近真实业务负载的请求压一段时间，盯延迟长尾和显存曲线，看有没有降频或掉卡
3. 跑真实业务请求拿一批线上真实请求样本回放，对比延迟和成功率，别只跑合成负载
4. 记录基线并留档把延迟、吞吐、显存占用记下来，作为后续对账和排查的参照

跑起来之后，算力账要能对上

跑起来之后最容易失控的是空转。把「卡时 × 单价 × 空转比例」当成一个固定公式，每周拉一次实际使用时长和账单逐条核。到 /compute/platforms 看不同平台的计费说明，各家对空转、超时、断线的处理不一样，对账前先看清规则。

计费方式也别全压一种。峰值用按量补，基线用长约兜，是常见做法。不适用场景要写清：负载波动极大且无法预测的业务，硬套长约会被空转成本反噬，这种时候按量反而更稳。

• 固定公式：卡时 × 单价 × 空转比例，空转比例按周统计
• 每周对账一次，实际使用时长和账单逐条核
• 峰值按量补、基线长约兜，别全压一种计费
• 发现空转比例持续偏高，先查调度和排队，再谈换卡

落地切换的四步节奏

验收通过、账也对得上，再谈切换。切换别一步到位，按四步走：第一步小流量灰度，只切一部分请求到新卡环境；第二步对比同一批请求的延迟、成功率和单位成本；第三步设定回退条件，明确触发阈值和回退动作；第四步再放量，每次放量前复跑一遍基线。四步里任何一步的数据对不上，就停在那一步查，别硬推。

回退条件要提前写死，别等出问题再临时讨论。触发阈值通常看成功率和延迟长尾两个指标，回退动作写清楚是切回旧环境还是降级服务。判断标准：回退动作能在几分钟内执行完，才算真的准备好了。

选卡不是比参数，是把需求、规格、报价口径和验收顺序按顺序走完，每一步都留下可核对的记录。