一、评测背景:从”参数规模崇拜”回到工程可验证问题

开源大模型生态中,中等参数规模的稠密模型长期是本地部署群体的默认选择,原因并不神秘:它在”模型能力够用”与”单张消费级显卡装得下”之间取得了较好的平衡,权重可以整体常驻显存,推理路径简单,时延可预期,调试成本低。每一代更新都能引发大量本地部署爱好者的关注。

最近出现的变量是另一类技术路线:把超大规模模型的权重绝大部分放在系统内存甚至本地存储介质中,仅让少量常驻层驻留显存,按层、按块按需换入换出,配合低比特权重量化,使原本需要多卡或大显存的模型,在显存容量有限的设备上”能跑起来”。代价是显存门槛被转化为内存与存储容量门槛,同时引入了对内存带宽、外设总线带宽和存储顺序读速度的强依赖。

社区讨论中出现”关注点转移”很正常,但关注度不是工程结论。真正需要回答的是:在我的任务类型、时延约束、并发规模和总预算下,两条路线各自的收益与代价是什么,以及哪些代价只有在长时间、带负载的运行中才会暴露。 这正是本文评测的对象。

本文适合以下读者:需要做本地或私有化推理选型的应用开发者;负责算力与硬件预算的架构师与技术负责人;承担模型服务上线与稳定性保障的运维人员;以及需要在有限设备上做多模型对比实验的研究型用户。

需要强调的是,本文不做”谁更强”的绝对化判断。模型路线的优劣高度依赖场景:交互式对话、离线批处理、多人共享服务、边缘低功耗设备,关注点完全不同。本文提供的是评测方法与结果解读口径。

二、评测对象说明:两条路线的技术本质

为避免后续指标解释混乱,先明确两条被评测路线(下称路线A与路线B)的技术差异。

路线A:权重常驻显存的中等参数模型
模型权重经常规权重量化后整体驻留显存,前向计算的访存与计算均在显存内完成。特点是显存占用可预估、时延稳定、对内存与存储容量要求低,主要受显存容量上限约束。

路线B:权重跨介质卸载的超大模型推理
权重绝大部分存放在系统内存或本地存储中,运行时逐层或逐块加载。其性能瓶颈通常从”算力”转移到”带宽”与”介质随机/顺序读能力”:如果单请求的每token时间明显长于路线A,通常不是GPU算不动,而是每步都要等待权重搬运。

对比维度	路线A(显存常驻)	路线B(跨介质卸载)
显存需求	与参数量强相关,必须一次装下	显著降低,可压缩到较小显存
内存/存储需求	较低	显著上升,是主要新增成本
关键瓶颈资源	显存容量与显存带宽	内存容量、总线带宽、存储读取速度
单请求时延	通常更稳定可预期	对缓存命中率与介质状态高度敏感
并发扩展	可通过批处理获得较好收益	带宽易被抢占,并发收益可能迅速衰减
失效模式	显存溢出,报错明确	内存不足时退化为频繁读盘,表现为”突然变慢”而非报错
部署复杂度	低	高,需调优卸载层数、量化方案与缓存策略

这张表本身就是评测的假设来源:后文所有维度都是围绕验证这些假设展开的。

三、评测目标:本次重点回答六个问题

1. 质量增益是否真实存在:更大的参数规模带来的效果提升,在目标任务上是否大于低比特量化带来的精度损失?
2. 时延是否落入业务可接受区间:首字延迟与每token生成时间,是否满足交互式使用的基本体验门槛?
3. 并发能力如何:从单路升到多路时,吞吐是线性改善、持平还是恶化?
4. 稳定性边界在哪里:长上下文、长时间运行、资源紧张、异常输入下的表现如何?
5. 成本结构如何变化:硬件构成、内存与存储扩容、电力与散热、运维人力的综合代价是多少?
6. 易用性与可维护性:配置复杂度、故障定位难度、版本升级成本是否可接受?

这六个问题对应后文六类评测维度,任何一项缺失都会让选型结论不完整。

四、评测维度设计与验证方法

4.1 输出质量(有效性)

为什么重要:参数规模的吸引力几乎全部来自能力预期。若能力增益在目标场景不成立,卸载带来的所有代价都变成纯损失。
如何验证:构建 60~200 条与真实业务同分布的题目集,覆盖结构化输出、代码生成与修复、长文摘要、多轮指令遵循、数值与格式约束五类任务;同一题目集在两条路线下各跑三次,采用人工盲评(不清楚哪条输出属于哪条路线)按”是否正确/是否可用/是否需大改”三级打分。
如何解读:增益只有在同一任务集、同一采样参数、可重复的条件下才可比。如果三次重复的评分离散度接近路线间差值,说明增益不显著,不能作为选型依据。同时必须单独检查量化引入的典型问题:长上下文中的信息遗漏、格式约束的服从度下降、小语种与专业术语的退化。

4.2 性能表现(时延与吞吐)

为什么重要:这是两条路线差异最可量化的部分,也最直接决定可用性。
如何验证:区分三个独立指标——首字延迟(从请求发出到第一个token返回)、每token生成时间、单位时间总输出token数;分别在 1 路、2 路、4 路、8 路并发下测量。
如何解读:如果首字延迟明显上升而每token生成时间相对稳定,说明瓶颈在权重加载与预热阶段,更适合可容忍启动开销的离线任务;如果每token时间本身就被拉长,说明每个解码步都受带宽限制,交互式体验受损;如果并发上升后总吞吐不增反降,说明带宽已被瓜分,批处理的收益有限。这些判断不应依赖单次测量,建议做多轮取中位数并观察离散程度。

4.3 稳定性

为什么重要:卸载路线的失效往往不是崩溃,而是”变慢”,更难被常规健康检查发现。
如何验证:连续运行数百轮会话或数小时不间断请求,持续采样内存占用、显存占用、缓存命中率与响应时延曲线;逐步增加上下文长度至模型上限附近;人为制造资源紧张(后台占用内存、存储接近写满)与异常输入(超长文本、乱码编码、极端特殊字符、并发抢占)。
如何解读:内存曲线单调上升且不回落,提示存在碎片或泄漏风险;当内存逼近物理上限时性能出现数量级跳变,说明已进入频繁读盘路径,这是路线B最危险的运行区间,必须在容量规划中预留安全余量。

4.4 易用性与可观测性

为什么重要:路线B的可调参数明显更多,调优成本与排障难度会转化为长期人力成本。
如何验证:记录从零到跑通所需步骤数与配置项数量;检查是否具备请求级日志、资源占用指标、错误分类统计与告警能力;模拟一次配置错误的排障过程,记录定位耗时。
如何解读:若关键指标只能依赖人工观察,难以接入统一监控告警体系,则在多人共享或线上服务场景下风险较高。

4.5 兼容性与工程集成

为什么重要:模型能否稳定嵌入现有调用链,决定了改造成本。
如何验证:验证接口形态是否与现有服务一致(统一的请求/响应结构、流式返回、超时与重试语义)、上下文长度与并发上限是否满足业务要求、是否与现有网关、负载均衡、日志服务、监控告警、身份认证与权限控制体系兼容。
如何解读:兼容性问题的典型表现是”能跑但不好用”,例如缺少流式返回导致首字等待被放大,或缺少超时控制导致慢请求拖垮整体服务。

4.6 成本结构

为什么重要:路线B常被描述为”用便宜的内存和硬盘换昂贵的显卡”,这个判断只在部分条件下成立。
如何验证:按同一预算列出三种硬件组合的构成(显卡容量、内存容量与通道数、存储类型与容量),估算电力与散热开销,并计入部署调优与长期运维的人力投入。
如何解读:内存与存储的单价优势,只有在其容量恰好匹配需求且不引发性能塌陷时才成立。若为了消除性能塌陷而不断加内存,总成本可能反超直接升级显卡;此外高频读盘会带来的介质寿命问题,也应纳入长期成本核算。

五、评测环境与前提:控制变量比选工具更重要

评测结论的可信度几乎完全取决于变量控制。上线测试前应先固定以下条件并记录成表:

• 硬件:CPU 型号与核心数、内存容量与通道数、显卡型号与显存容量、外设总线代数与通道数、存储介质类型与容量;
• 模型侧:参数量级、量化位数与量化方案、上下文长度上限——量化方案的差异对精度和速度的影响不可忽略,不能只比较位数;
• 推理配置:卸载策略(常驻显存层数)、批处理设置、缓存策略、并发上限;
• 解码参数:温度、top_p、最大输出长度、重复惩罚、系统提示模板——两条路线必须使用完全一致的解码参数,否则质量对比无效;
• 测试数据:同一份题目集、同一顺序、同一输入长度分布;
• 环境状态:关闭后台无关进程,记录环境温度与是否出现降频,首轮结果建议丢弃以排除缓存预热影响。

评测边界声明:单机单卡的交互式使用,与多用户在线服务的评测口径不同;离线批处理场景不必用交互时延作为否决依据。结论必须绑定其成立条件。

六、测试流程与示意性实现

推荐按以下顺序推进,每步产出可复核的记录:

1. 建基线:固定输入集与解码参数,先跑路线A,记录时延、吞吐、资源曲线与质量评分;
2. 切路线:切到路线B,尽量对齐量化级别,重复完全相同的输入集;
3. 分档压测:1/2/4/8 路并发逐级加压,每档记录首字延迟、每token时间、总吞吐、资源占用;
4. 上下文压力测试:从短提示逐步加长至接近上限,绘制速度衰减曲线与资源增长曲线;
5. 长稳测试:持续运行并采样,观察内存与显存曲线、缓存命中率、错误率;
6. 异常测试:超长输入、乱码、并发抢占、资源紧张、进程中断恢复;
7. 质量盲评:人工双盲打分,记录评分离散度;
8. 复盘:所有数据落成表格与曲线,标注异常点与可能原因。

示意性测试骨架(通用伪代码,不依赖特定第三方工具):

config = {
  "route": "A | B",
  "quant_bits": 4,
  "context_len": 8192,
  "decode": {"temperature": 0.2, "top_p": 0.9, "max_tokens": 1024},
  "concurrency_levels": [1, 2, 4, 8],
}
for level in config.concurrency_levels:
    metrics = []
    for sample in dataset:            # 同一份题目集,顺序固定
        t0 = now()
        resp = client.stream_chat(sample.prompt, **config.decode)
        ttft = first_token_time(resp) - t0
        tps  = tokens(resp) / (finish_time(resp) - first_token_time(resp))
        metrics.append({"ttft": ttft, "tps": tps,
                        "ram_peak": sample_ram(), "vram_peak": sample_vram(),
                        "errors": resp.errors})
    report(level, summarize(metrics))  # 输出中位数与离散度,不只看平均值

记录时务必同时保存中位数与离散度:平均值会掩盖长尾,而长尾时延恰恰是交互体验的决定因素。

七、结果解读:什么样的结果支撑什么判断

• 首字延迟升高但每token时间稳定 → 卸载路线在可容忍启动与预热开销的离线任务中具备可行性;
• 每token时间显著被拉长 → 瓶颈为带宽,交互式场景不建议;
• 并发上升后总吞吐持平或下降 → 带宽已被占满,批处理收益有限,不宜承担多用户服务;
• 内存占用逼近物理上限时出现性能数量级跳变 → 已进入频繁读盘区间,必须扩容或降载;
• 更大参数模型的评分离散度接近路线间差值 → 质量增益不显著,不应作为选型主要理由;
• 长稳测试中出现内存曲线单调上升 → 存在稳定性风险,上线前需复现并定位。

需要特别说明的技术原因:两条路线的性能差异,通常并非来自算力差距,而是来自权重搬运路径。前者每步都在显存内完成访存,后者每步都要等待跨介质加载,因此后者的实际表现对缓存命中率、总线带宽与存储介质状态极度敏感,也就更难用一次简短测试代表其真实水平。

八、适用场景分析

场景	首要关注指标	倾向判断
交互式对话、实时代码辅助	首字延迟、每token时间、长尾稳定性	倾向权重常驻显存
离线批处理、长文生成、夜间任务	吞吐总量、单位任务成本、质量	卸载路线有机会
多人共享的团队服务	并发吞吐、超时与重试、隔离与权限	需先验证并发后再定
多模型能力探索与研究实验	可切换性、部署速度、质量对比	卸载路线价值明显
边缘或低功耗设备	功耗、介质寿命、散热	需额外评估长期损耗
需要弹性伸缩的在线业务	扩容路径、监控告警、成本模型	通常更适合在云上 GPU 实例配合负载均衡与弹性伸缩承载

九、风险与限制

• 样本偏差:题目集过小或任务类型单一,会放大偶然差异;
• 环境差异:介质缓存冷热状态不同、后台进程干扰、散热降频,都会显著改变卸载路线的结果;
• 资源限制:内存不足时性能可能不是”变慢一点”,而是数量级恶化;
• 长期不确定性:长时间运行的内存碎片、存储介质写入寿命、版本升级后的行为变化,短期内无法测全;
• 量化实现差异:不同量化方案在同一位数下的精度与速度表现不同,不能只按位数横向比较;
• 热度偏差:社区讨论热度反映的是可获得性与好奇心,不是场景适配度。

十、选型与使用建议

1. 先确定任务的时间约束(实时、准实时、离线),再谈模型规模;
2. 再确定并发规模(单人、小团队、公共服务),据此决定是否需要重点验证并发能力;
3. 用总拥有成本而非单一硬件单价做决策,把内存、存储、电力、散热、调优与运维人力一并计入;
4. 以小规模 POC 代替社区结论,固定变量、重复测量、记录离散度;
5. 保留回退方案与统一评测脚本,使不同模型、不同硬件组合的结论可横向复用;
6. 若走云上路线,可借助云服务器、GPU 实例、对象存储、负载均衡、监控告警与日志服务等通用能力承载弹性与可观测性需求,避免把容量风险压在单机上。

十一、总结

本文的评测对象是两条本地推理路线的取舍:显存常驻的中等参数模型,与依靠内存与存储卸载承载的超大模型。核心结论是条件化的:前者在时延可预期性与工程简洁性上具备优势,适合交互式与在线场景;后者降低了显存门槛,使原本无法运行的模型变为可用,更契合离线与实验类任务,但其性能高度依赖带宽与缓存命中,稳定性风险更容易在长时间运行与资源紧张时暴露。

评测的关键不在于选出”更强的一方”,而在于用固定变量、分维度验证、记录离散度、声明适用边界的方法,把热度问题转化为可验证的工程问题。质量增益必须扣除量化损失后实测,性能结论必须区分首字延迟与每token时间,成本结论必须计入内存、存储与运维的长期投入。按此框架完成 POC,选型判断才有可复核的依据。