单卡24G跑OpenClaw+千问3.5-9B：24小时推理压测与显存并发复盘

上周三晚上十一点我把一台装着单张24G显卡的机器挪到阳台上——风扇全速转起来那个噪音屋里实在待不住人——然后给它挂上持续24小时的推理负载回屋睡觉。第二天同一时间去收数据屏幕上留下的是一条完整的显存曲线、一条温度曲线、一份两万多行的请求日志以及几个足够写进复盘文档的坑。这篇东西就是那次实验的完整记录从显存怎么算、负载怎么设计到半夜三点到底发生了什么。先把名词交代清楚。OpenClaw是一个开源的智能体运行时框架你可以把它理解成给大模型装上一圈手脚能调用工具、读写本地文件、维护多轮任务状态、在失败时自己重试。千问3.5-9B是我这次选来当大脑的模型9B 参数量中文表达扎实量化之后单卡能塞得下。压力测试这件事说白了就是把这套组合按在椅子上连续干活一天一夜看它会不会中途罢工、变慢、失忆或者开始胡说八道。适合谁看手上有一张消费级大显存卡、想在自己机器上跑智能体、又不想等上线之后才被 OOM 和延迟打脸的同行也适合已经在跑但总觉得跑一会儿就变慢、找不到原因的人。全程没有云服务、没有多卡集群就是一台机器、一张卡、24小时。1. 这次压测要回答的三个问题动手之前我先给自己划了范围。压测最怕的是什么都想测最后跑了一天数据一堆结论一个没有。所以我把目标收敛成三个能落地的问题其他一律砍掉。1.1 OpenClaw 在这条链路里到底干什么活很多人对智能体框架的想象停留在套一层 prompt 让它调用函数实际跑起来远比这复杂。OpenClaw 在整条链路里承担的是调度与状态维护它要决定这一轮是直接回答、还是去调工具要维护对话历史和中间结果要在工具返回异常时判断是重试还是换路径还要控制整个任务最多走多少步防止无限循环。这些动作每一个都会往推理服务端发请求而且请求长度极不均匀——一次工具调用可能只发 200 个 token一次带完整上下文的总结可能塞进去 7000 个 token。这直接决定了压测的请求体不能是固定长度的假数据必须模拟真实的任务流。我在设计负载时专门做了一份任务样本池后面第 3 节会细说。另外还有个容易忽略的点框架本身的 CPU 和内存开销。推理跑在 GPU 上但 OpenClaw 的进程在 CPU 侧要解析 JSON、拼装上下文、写日志。24 小时下来如果这块有内存泄漏表现不是显存爆而是系统内存缓慢爬升最后被系统直接杀掉进程。这也是我这次重点盯的一项。1.2 为什么偏偏选 9B 这个档位参数量的选择本质上是一道成本与能力的平衡题。3B 以下的模型在工具调用格式的遵循度上经常出问题——你让它输出结构化参数它给你一段散文重试三次才对实际吞吐被重试吃掉了。30B 以上的模型单卡放不下得上量化到很低的档位质量掉得厉害而且显存余量小到没法开并发。9B 这个档位是我实测下来性价比曲线的拐点指令遵循基本稳定中文长文本不塌Q4 量化后权重只占五个多 G剩下的显存足够撑起一个有意义的并发数。换句话说它让我能在一个真实可用的配置下测出有参考价值的数据而不是在极限边缘测出一堆理论上可行的结论。这里有个判断标准值得分享选模型不要看榜单分数要看在你实际任务上的重试率。我拿二十条典型任务跑了一遍统计每个候选模型需要重试几次才能产出合法结构9B 这个档位的重试率大概在 8% 左右再小一号的模型直接飙到 30% 以上那点省下来的显存完全被重试抵消了。1.3 我明确不测的东西为了不跑偏有几件事我提前排除在外。第一不做多卡分布式这次就是单卡因为绝大多数个人和小团队的实际部署形态就是单卡。第二不做模型微调相关的测试压测针对的是推理稳定性不是训练。第三不测极限并发下的质量崩塌那是另一个话题需要人工标注才能评估24 小时自动化跑不出来。还有一条不追求跑出最高分。压测的价值不在于把机器压到冒烟而在于找到能长期稳定运行的那个点在哪里。所以我全程盯的是稳态表现尖峰阶段只是短暂试探不把机器按在极限上烤二十个小时——那样测出来的数据没有部署参考价值。2. 显存账本把 24G 掰成八瓣花这一节是我认为整篇最有价值的部分。很多人部署失败不是因为不会装环境而是一开始就没算清楚显存去哪了装完发现差 2G然后开始瞎调参数碰运气。我把这笔账完整算一遍。2.1 权重、KV Cache、激活值三笔开销显存开销可以拆成三大块缺一不可。第一块是模型权重。9B 参数在不同精度下的占用差别很大粗略按参数量 × 每参数字节数估量化档位每参数字节权重占用9B质量损失感受FP162.0约 18 GB基准无损失Q8_0约 1.06约 9.6 GB几乎无感Q5_K_M约 0.72约 6.5 GB轻微长文偶有跳字Q4_K_M约 0.62约 5.6 GB可接受复杂推理略降Q3_K_M约 0.50约 4.5 GB明显不建议生产用第二块是 KV Cache也就是上下文缓存这块最容易被低估。它的计算方式是每 token 每层的缓存字节数 2K 和 V 各一份× KV 头数 × 头维度 × 每元素字节数。以 9B 级别模型常见的配置32 层、4 个 KV 头、头维度 128、FP16 存储来算每层每 token 是 2 × 4 × 128 × 2 2048 字节乘 32 层就是每 token 约 64 KB。那么单个 8192 token 的请求KV Cache 就要吃掉 8192 × 64KB ≈512 MB。如果同时跑 16 个这样的请求就是8 GB。这个数字非常吓人——它和权重是一个量级的开销但很多人部署时只算了权重。第三块是激活值和框架开销包括推理引擎的调度结构、CUDA 上下文、临时缓冲区。这部分不好精确算经验值按 1.5 到 2.5 GB 预留比较稳妥。三笔加起来Q4_K_M 权重 5.6 GB 16 并发 × 8K 上下文的 KV 8 GB 框架开销 2 GB ≈15.6 GB24G 卡上还剩 8G 多能扛住请求长度的波动。如果换成 Q8_0权重 9.6 KV 8 2 19.6 GB只剩 4G 余量长请求一来就容易 OOM。注意上面这个算法假设 KV Cache 全部按 FP16 存。有些推理引擎支持 KV 量化到 INT8能把这部分砍一半但会带来轻微的质量损失长上下文下尤其明显。我这次没用因为要留一个干净的基线。2.2 量化档位的取舍算完账Q4_K_M 基本是唯一合理的选择。但这里有个细节值得说同样是 Q4不同实现的质量差异比想象中大。我做过一个粗糙的对比用同一批包含数字提取和格式转换的任务Q4_K_M 的准确率比重一点的 Q5 档低大概 3 到 5 个百分点但在纯生成类任务上几乎看不出区别。所以我的策略是按任务分流结构化输出、参数提取这类对精度敏感的任务把温度压到 0.1 以下减少随机性带来的偏差开放式的写作、总结类任务正常温度跑。这样在同一个模型上兼顾了两类需求不用为了少量任务去堆更高的精度。还有个实操细节量化文件的分片方式会影响加载速度。单文件加载比多分片快但如果显存紧张需要部分卸载到内存分片反而更灵活。我这次是全量上卡所以选了单文件冷启动从点击到能接受请求大概 12 秒。2.3 上下文长度与并发的乘积关系这是整篇里我最想强调的一条经验上下文长度和并发数是相乘关系不是相加。你把上下文从 4K 提到 8K看起来只是能处理更长的文档实际上显存开销翻倍如果并发数不变等于把安全余量直接吃掉一半。我给自己定的规矩是先定并发再定上下文。因为并发决定了服务能承受多少同时到达的请求这直接关系到用户体验上下文长度则可以根据实际任务分布来裁剪。具体做法是统计任务样本池里的输入长度分布。我统计下来90% 的请求在 3000 token 以内只有不到 3% 会超过 7000。所以最终配置是上下文上限设 8192但调度上按 4096 分配 KV 空间超长请求单独排队。这样大部分请求走快车道长请求走慢车道整体显存占用降下来了用户体验反而更稳。3. 负载曲线设计让 24 小时不是简单重复如果 24 小时都用同一个并发数压测出来的东西意义有限——真实的负载从来不是一条直线。它会爬坡、会平稳、会突然来一波尖峰、会掉下来。所以我把整条曲线设计成五个阶段。3.1 五个阶段的节奏安排阶段时间窗并发数目的基线0-2h1建立单请求性能基准排除冷启动影响爬坡2-8h1→16 线性递增找吞吐拐点和延迟开始劣化的临界点稳态8-18h16 恒定长时间稳定性盯显存泄漏和温度尖峰18-22h16→32 脉冲短时过载表现看恢复能力收尾22-24h16→1 递减观察资源释放是否干净这个设计的关键在爬坡阶段。线性递增的好处是能看到延迟曲线的形状一开始请求稀疏延迟基本等于单次推理时间并发加上去之后请求开始排队延迟上升到某个点会突然陡增那就是拐点。拐点之前的并发数才是安全并发之后的都是拿延迟换吞吐。我这次实测的拐点在18 到 20 并发之间。16 并发时 P95 延迟还在 4 秒左右到 20 并发就跳到 7 秒以上24 并发直接突破 12 秒。所以稳态阶段我把并发定在 16留了一点余量。3.2 请求体怎么构造才像真实业务这一块如果做假了整个压测的数据就废了。我用的是任务样本池随机抽取 长度分层的方式。样本池里放了五类任务短问答100-300 token 输入、工具调用300-800带结构化参数、文档摘要2000-4000、多轮对话续写累计 1000-6000、长文档分析5000-8000。比例按真实使用分布来配大概 40% 短问答、25% 工具调用、20% 摘要、10% 多轮、5% 长文档。输出长度也要控制。统一按 256 token 上限跑会导致数据好看但不真实——实际业务里输出长度是波动的有时候一句话就结束有时候要写上千字。我设成按任务类型随机 64 到 1024 token并且开启流式输出这样才能真实测到首 token 延迟TTFT这个关键指标。还有一个细节请求之间要有间隔抖动。如果所有请求严格同时发出测出来的是理论峰值真实的用户请求是泊松分布的有疏有密。我在请求生成器里加了 50 到 500 毫秒的随机间隔让到达曲线更接近真实流量。3.3 采样频率与数据落盘采样频率这道题很多人会做错。采太密数据量大到没法分析而且采集本身消耗资源影响被测对象采太疏尖峰被平滑掉什么都看不见。我的设置是分层的系统层指标显存、温度、功耗、利用率每 2 秒采一次因为变化快需要细粒度服务层指标吞吐、延迟分位每 10 秒聚合一次按滑动窗口算应用层指标任务完成率、重试次数、token 消耗每个请求记录一条最后汇总。落盘策略上我用了原始日志 分钟级聚合双写。原始日志保留全部请求明细方便事后追查单个异常聚合数据用来画曲线文件小、加载快。24 小时下来原始日志大概 2.3 GB聚合文件不到 5 MB。提示日志一定要写到独立磁盘或者至少独立分区。我第一次跑的时候日志和模型文件在同一个盘写到第 14 小时磁盘满了推理服务直接报错退出白跑半天。4. 监控链路搭建看不见的指标等于没有压测做到一半最怕的情况是机器变慢了但你不知道从什么时候开始慢的、慢在哪个环节。所以监控必须提前搭好而且要在正式跑之前先空跑半小时验证采集正常。4.1 系统层显存、温度、功耗、降频这四项是硬件健康的晴雨表。显存看的是绝对值 增长斜率绝对值判断是否接近上限斜率判断有没有泄漏——如果稳态阶段显存每小时涨 200 MB24 小时就是 4.8 G必爆。温度要分核心温度和热点温度看。核心温度是芯片整体的热点是局部最热区域的后者通常高 10 到 15 度。判断是否降频要看频率是否随温度下降而不是只看温度数字。我这次设定核心 83 度、热点 95 度为警戒线超过就开始记录降频事件。功耗这一项很多人不采但它其实很有用功耗异常下降往往意味着降频或者部分单元空闲是一个综合信号。我这次全程功耗稳定在 330 到 350 W 之间只有在收尾阶段并发降下来之后才明显下降说明中间没有出现异常的降频。4.2 服务层吞吐、延迟分位、队列深度吞吐用每秒生成的 token 数衡量比用请求数更准因为请求长度差异大。延迟必须看分位数平均值毫无意义——平均 3 秒可能是 95% 的请求 1 秒加 5% 的请求 40 秒。我盯的三个数是TTFT 的 P50 和 P95、端到端延迟的 P95 和 P99、队列深度。队列深度这个指标特别有用它是并发压力的直接体现队列一长说明处理不过来接下来延迟必然劣化。实测稳态阶段16 并发TTFT 的 P50 约 0.35 秒P95 约 1.2 秒长 prompt 拉高了尾部端到端 P95 约 4.1 秒P99 约 8.7 秒队列深度基本在 0 到 2 之间波动。这组数字我认为是可以接受的用户的感知延迟主要落在首 token 上。4.3 应用层Agent 循环、工具调用、token 账本这一层是智能体特有的普通推理服务不需要但跑 OpenClaw 就必须盯。循环步数是第一位的。智能体最危险的失败模式是陷入调工具 → 结果不满意 → 再调 → 还不满意的死循环一次任务烧掉几万 token既慢又贵。我给每个任务设了硬上限最多 8 步超过强制终止并返回中间结果。工具调用成功率是第二位的。如果某个工具持续失败框架会不停重试表现出来就是吞吐虚高但任务完成率低。我按工具维度统计成功率跑下来文件读写类 99.2%结构化解析类 96.5%后者偏低是因为有些输入本身格式不规范。token 账本是第三位记录每个任务消耗的输入输出 token。这个数据直接决定了成本估算也能暴露出异常任务——比如某个任务消耗了平均值的 20 倍那大概率是循环没刹住。5. 24 小时实录每个阶段发生了什么前面都是准备工作这一节是真正跑起来之后的情况。我按时间段把关键现象和判断记下来附上当时的处理动作。5.1 0-2 小时基线阶段刚启动的前 20 分钟有个明显现象首次请求特别慢TTFT 超过 8 秒。这不是性能问题是模型权重和计算图第一次加载之后就走缓存了。所以基线段我特意留了 20 分钟预热不计入统计。预热完成后单请求并发 1的表现相当稳定短问答的 TTFT 在 0.18 到 0.25 秒之间输出速度大概 68 到 75 token/s长文档分析7000 token 输入的 TTFT 涨到 2.4 秒左右因为要先把整个上下文编码一遍。这个 2.4 秒是后面所有延迟分析的基准线。显存占用在这个阶段稳定在 8.1 GB 左右权重 5.6 单请求 KV 开销。温度爬升到 62 度后基本不再涨风扇转速 55%。一切正常。5.2 2-8 小时爬坡阶段线性爬坡从并发 2 开始每 12 分钟加 1到第 8 小时刚好到 16。这条曲线跑出来信息量很大。并发 1 到 6 这一段吞吐几乎线性增长延迟基本不变。说明这个区间内请求根本不需要排队来一个处理一个。并发 7 到 12吞吐继续涨但斜率变缓TTFT 的 P95 从 0.4 秒涨到 0.9 秒。这是因为批处理开始起作用了——多个请求被合到同一个批次里算单次计算时间变长但总吞吐提高属于正常现象。并发 13 到 16吞吐增长明显放缓延迟开始有感知。16 并发时总吞吐大概 420 token/s而 12 并发时是 380 token/s多 4 个并发只换来 10% 的吞吐提升延迟却涨了 60%。这就是典型的投入产出比恶化区间。显存占用在这个阶段从 8.1 GB 爬到 19.7 GB涨幅主要来自 KV Cache。这里有个值得注意的细节显存不是均匀上涨的而是阶梯式跳变——因为 KV 空间是按块分配的每满一块才分配新的一块。所以看到曲线突然跳高 512 MB不用紧张那是正常的块分配。5.3 8-18 小时稳态阶段最考验人的十个小时。这段时间并发恒定 16理论上所有指标应该走平。实际情况是前 4 小时完全平稳各项指标波动都在 5% 以内。第 5 小时开始出现一个缓慢的趋势——显存每小时涨 120 MB 左右。虽然涨得慢但方向明确不是随机波动。我当时的处理是继续观察而不是立刻重启。因为重启会打断测试而这个涨幅在 10 小时内总共只有 1.2 GB不会立刻爆。结果到第 12 小时涨幅自己停了显存稳定在 21.3 GB一直保持到稳态结束。事后分析这 1.2 GB 大概率是碎片而不是泄漏。原因是请求长度不均匀长短请求交替导致 KV 块分配释放不规整产生了无法复用的空洞。这不算 bug但提醒了一件事跑长时间服务显存要留 15% 以上的余量给碎片不能算到刚刚好。温度方面稳态阶段核心温度在 74 到 78 度之间波动热点 89 到 92 度风扇 88% 到 95%。频率全程没有下降说明散热压住了没触发温度墙。功耗稳定在 345 W。5.4 18-22 小时尖峰阶段这一段是故意找麻烦。从 16 并发开始每 15 分钟来一次 3 分钟的 32 并发脉冲一共四次。第一次脉冲的反应很典型并发一加上去队列深度从 2 秒内冲到 28TTFT 的 P95 直接飙到 14 秒端到端 P99 突破 30 秒。更关键的是恢复时间——脉冲结束后队列需要大概 90 秒才排空指标回到正常水平。这个 90 秒的恢复时间是有意义的。它说明服务有一定的缓冲能力短时过载不会导致雪崩但如果尖峰持续时间超过 3 分钟队列会积压到不可接受的程度。所以生产环境里过载保护必须在队列深度超过阈值时就开始拒绝或降级而不是等延迟已经烂了再动手。第二次到第四次脉冲表现基本一致没有出现累积恶化——说明资源释放是干净的没有因为过载留下后遗症。这一点比峰值数据更重要。5.5 22-24 小时收尾阶段并发从 16 逐步降到 1重点观察两件事显存能不能还回去延迟能不能回到基线。显存方面从 21.3 GB 降到 8.4 GB但没有回到初始的 8.1 GB差了 300 MB 左右。这个差值一直保持到测试结束。我的判断是正常的运行时缓存——推理引擎会保留一些预分配的缓冲区不释放为了下次请求能快速响应。300 MB 在 24G 卡上占 1.2%可以接受。延迟方面回到并发 1 之后TTFT 是 0.21 秒比基线的 0.18 到 0.25 中位数还略好一点。说明长时间运行没有导致性能衰退这是个好消息。整个 24 小时累计处理请求约 8.7 万个生成 token 约 2100 万。电费按 350 W 平均功耗算24 小时 8.4 度不到六块钱。6. 六个坑与排查速查表这一节是踩坑记录。有些是这次新遇到的有些是老问题在新场景下的变种都值得记下来。6.1 显存只涨不跌这是最常见的问题但原因不止一种得分开看。第一种真的有泄漏。特征是线性稳定增长重启就恢复跑久了必爆。定位方法是看增长斜率是否恒定如果每小时固定涨 X MB那基本确定。常见来源是框架层的引用没释放或者请求对象被全局缓存持有。第二种碎片累积。特征是有涨有停达到某个值后稳定。这是长短请求混合导致的处理办法是调整 KV 块大小或者定期做一次整理清空缓存重新预热。第三种长请求堆积。特征是与请求长度分布强相关长请求多的时候涨得快。这种不是问题是正常现象只要总量在预算内就行。判断顺序建议先看斜率是否恒定区分泄漏和碎片再看是否与请求长度相关区分堆积最后再动代码。6.2 长上下文下的性能断崖这个问题我这次专门测了。从 2K 上下文逐步加到 8K观察 TTFT 的变化。结果是非线性的2K 到 4KTTFT 从 0.6 秒涨到 1.1 秒接近线性4K 到 6K涨到 2.0 秒开始超线性6K 到 8K直接跳到 3.8 秒。最后这一段涨幅明显不正常。原因是注意力计算的复杂度随长度呈平方增长而且长上下文会撑爆缓存层级导致显存访问效率下降。实践上的应对办法不是优化算法而是在应用层做分块超过 5K 的文档先切分成段落分别处理再合并结果。这样虽然多花几次调用的时间但总延迟反而更低而且质量更稳定——长上下文里模型容易忘记中间部分的内容。6.3 温度墙与降频消费级卡在持续满载下很容易撞温度墙。我这次没撞上但做了压力试验把风扇手动锁到 60%跑 30 分钟核心温度冲到 86 度频率从 2.5 GHz 掉到 2.1 GHz吞吐直接降了 18%。这个实验说明一件事散热余量就是性能余量。如果机箱风道不好或者环境温度高你可能在 12 小时之后就进入降频状态但因为没有监控频率只感觉越跑越慢找不到原因。实操建议跑长时间任务之前先做一次 30 分钟满载测试记录稳定后的温度和频率。如果核心温度超过 80 度先解决散热再谈压测否则数据没意义。我这次把机器挪到阳台、拆了侧板、加了一个辅助风扇稳定温度比放屋里低了 9 度。6.4 Agent 空转烧 token这是智能体特有的坑也是最烧钱的。表现是某个任务迟迟不结束token 消耗快速上涨。我这次抓到一次一个文件解析任务因为输入格式不规范工具返回了错误信息框架判断重试可能有不同结果连续重试了 11 次消耗了 1.8 万 token 才被步数上限拦住。这 11 次重试全部是无效的因为输入本身就有问题重试多少次都一样。改进办法有两个一是给重试加条件同样的错误连续出现两次就判定为不可恢复直接失败返回二是给单个任务的 token 消耗设上限超过就终止。这两条加上之后后续 12 小时没有再出现类似情况。6.5 磁盘与日志前面提过一次这里展开说。日志写满磁盘是个低调的杀手因为它不会立刻报错而是先让写入变慢然后服务开始异常最后进程被杀。我的教训是第 14 小时磁盘满了推理服务直接崩。事后算了一下原始请求日志每条平均 28 KB包含完整 prompt 和输出8.7 万条就是 2.3 GB加上框架自己的运行日志、系统日志总共 4 GB 多。如果盘小撑不过一天。处理办法日志按小时切分超过阈值的旧日志自动压缩归档关键指标单独走一条轻量通道不跟详细日志混在一起。这样即使详细日志出问题监控数据还在。6.6 问题速查表现象最可能原因快速验证处理显存线性上涨引用泄漏重启后是否恢复排查框架层缓存显存阶梯跳变KV 块分配跳变是否规律正常无需处理显存涨到某值停住碎片累积长短请求比例调块大小或加余量延迟突然整体上升温度降频看频率曲线改善散热延迟随长度非线性涨注意力平方复杂度分段测 TTFT应用层分块队列深度持续大于 10过载看并发数限流或降级任务不结束且 token 暴涨重试死循环看步数统计加重试条件和上限服务无故退出磁盘满或内存不足看系统日志日志分离、限制内存吞吐高但完成率低工具持续失败按工具统计成功率单工具隔离重试7. 压测之后这套组合能上什么场景跑完这一天我对9B 模型 智能体框架 单张 24G 卡这个组合的能力边界有了比较清楚的认识。这里说说我的判断都是基于实测数据的不是拍脑袋。7.1 可以直接用的场景个人或小团队的知识库问答。16 并发、P95 延迟 4 秒左右支撑十几个人同时用完全够。8K 上下文能塞进一份中等长度的文档配合分块检索效果更好。这类场景不需要极致延迟稳定比快更重要。本地化的文档批处理。比如批量提取合同要素、批量生成摘要、批量做格式转换。这类任务可以串行跑用不到并发单请求 70 token/s 的速度处理一千份文档大概几个小时晚上挂机第二天收结果。数据不出本地这一点对很多场景是刚需。开发阶段的智能体调试。在自己机器上跑改一行代码就能看到效果不用等云端部署。这个价值其实很大——智能体的行为调优需要大量试错反馈循环越短越好。7.2 必须加护栏的场景面向外部用户的服务。这台机器的能力上限就在 16 到 20 并发之间超过就雪崩。如果对外开放必须在前置层做限流、排队、降级不能让请求直接打到推理服务。而且要有熔断机制队列深度超过阈值就快速失败别让用户干等 30 秒。长文档处理。8K 上下文是个硬边界超过就得切分。而且前面测过6K 以上性能断崖明显实际可用区间是 5K 以内。如果业务里有大量长文档要么上更大的上下文配置但这会吃掉并发要么在应用层做好分块和结果合并。高精度结构化输出。Q4 量化的模型在参数提取上还有 3 到 5 个百分点的损失而且偶尔会漏字段。如果业务对准确率要求极高要么上更高精度的量化牺牲显存和速度要么加一层校验和重试。成本敏感的场景。这一点容易被忽略。本地跑看起来不要钱实际上电费、硬件折旧、维护时间都是成本。如果每天只是偶尔用几次云端按量付费反而更划算。本地的优势在于数据不出门和长期高频使用不在于绝对便宜。跑完这次测试我最大的感受是压测的价值不在于跑出多高的数字而在于让你知道边界在哪里。知道 16 并发是安全线、知道 5K 上下文是性能拐点、知道显存要留 15% 给碎片这些具体的数字比任何性能优异的结论都有用。它们让你在设计方案的时候不用猜可以直接按数据来配。还有一个体会是关于稳定这件事的定义。跑一小时不崩不叫稳定跑一天不崩、延迟不劣化、显存不失控、任务完成率不掉才叫稳定。而要验证这些除了老老实实挂机 24 小时没有捷径。