一、评测概述：为什么要重新做一次横向评估

本地部署开源大模型的技术路线，长期存在两条主线：

• 路线 A（单卡全量驻留）：选择参数量中等的稠密模型（约 270 亿参数级），把权重完整放进显存，靠”硬件门槛低 + 能力够用”取得平衡，因而在个人开发者与小型团队中被反复验证。
• 路线 B（分层卸载承载）：通过把部分权重分层放到系统内存与本地存储、按层或按块按需换入换出，让千亿参数级模型在 8GB~12GB 级别显存的消费级显卡上也能跑起来，代价是内存、磁盘容量与 I/O 带宽成为新的瓶颈。

当路线 B 出现时，很多”本地部署党”的关注点从”中等参数模型够不够聪明”迅速转向”小显存能不能上更大模型”。但这种转向往往基于理论可行性而非实测可用性。评测的意义正在这里：不是简单判断哪条路线”更好”，而是在给定硬件、给定任务、给定并发和给定预算下，判断哪条路线更可交付。

本文面向的读者与可获得的价值：

读者角色	关心的问题	本文能提供的判断依据
个人开发者 / 爱好者	现有显卡能否跑更大模型	门槛类指标（显存/内存/磁盘）与可用性指标（首字时延、出字速度）
应用开发者	接入哪个模型、如何设计上下文	有效性评测方法与失败案例分析流程
运维 / SRE	长时间运行是否稳定	长稳测试、异常注入、可观测性清单
技术负责人 / 架构师	成本与扩容路径	成本结构拆解、并发容量评估、混合部署策略

二、评测目标：把”馋不馋”翻译成可回答的问题

评测开始前必须先把问题写清楚，否则会陷入”指标很多但无法决策”的状态。本文的评测目标收敛为五个问题：

1. 门槛问题：在目标硬件上，两条路线分别是否可启动、可完成一次完整推理？显存、内存、磁盘的最低需求是多少？
2. 交互体验问题：单请求与多并发下，首字时延与持续出字速度处在什么量级，是否满足交互式使用（聊天、补全、代码助手）的体感要求？
3. 有效性问题：在真实业务任务上（摘要、结构化抽取、代码生成、长文档问答），输出质量是否达到可交付水平，失败集中在哪类样本？
4. 稳定性问题：连续运行数小时、上下文反复增长、依赖服务抖动、磁盘 I/O 竞争时，是否出现崩溃、显著降速或结果漂移？
5. 总拥有成本问题：为达到同等可用性，两条路线在硬件购置、扩容弹性、人力运维、迁移成本上的差异是什么？

注意：本文不给出任何具体分数、吞吐数值或排名。原因很直接——这类结论强依赖显卡型号、显存带宽、内存通道数、存储介质类型、量化位宽、上下文长度与并发模型，脱离环境的具体数值没有可迁移性。可交付的是方法、指标定义与解读逻辑。

三、评测对象说明：两条路线的技术本质差异

要理解结果为什么长这样，先要理解两条路线的资源模型差异。

路线 A：权重全量驻留显存

• 权重加载一次，后续每步推理都在显存内完成矩阵运算。
• 性能主要受显存带宽与算力限制，访存路径最短，延迟可预测性最好。
• 显存占用近似为常量，与生成长度关系较小（KV Cache 随上下文线性增长，需要单独预留）。
• 天花板明确：模型装不进去就是装不进去，无法通过”加内存”绕过。

路线 B：权重分层卸载 + 混合存储

• 权重被切分为层或块，活跃部分驻留显存，非活跃部分驻留内存或本地存储，按调度策略换入换出。
• 单次生成 token 需要等待权重搬运完成，延迟构成从”纯计算”变成”计算 + 等待 I/O”。
• 显存门槛显著下降，但把压力转移到内存容量、内存带宽、存储顺序读带宽与 I/O 队列深度上。
• 调度策略、预取命中率、块大小、量化位宽都会显著影响实测结果，因此它是”高方差”方案：配置对了可用，配置不对可能慢到无法交互。

这个差异决定了一个重要结论：两条路线的评测重点不同。路线 A 主要验证”能力上限与稳定性”，路线 B 必须先验证”可用性阈值”，再谈能力上限。

四、评测维度设计：把体验拆成可观测指标

维度	具体指标	采集方式	判读要点
门槛（可启动性）	显存峰值占用、内存峰值占用、磁盘占用、冷启动加载耗时	系统资源采样 + 进程级监控	低于物理容量多少余量才算安全，需按 KV Cache 增长留白
时延	首 token 时延（TTFT）、每 token 生成时延（TPOT）、长上下文下的时延增幅	客户端打点，记录请求级时间戳	TTFT 反映排队与预填充成本，TPOT 反映稳态体感
吞吐	单请求出字速度、并发 N 下的总吞吐、并发与延迟的拐点	阶梯式并发压测	关注 P50/P95/P99，平均值会掩盖长尾
有效性	任务成功率、格式合规率、人工评分、失败样本分类	固定评测集 + 人工抽检	必须区分”能力不足”与”截断/参数不当”
稳定性	连续运行时长、错误率、降速事件、内存增长趋势	长稳测试 + 资源曲线	关注曲线是否单调抬升（泄漏或缓存膨胀）
兼容性	运行环境、推理运行时版本、量化格式、接口规范、上层框架适配	环境矩阵测试	卸载方案的兼容性通常比全量驻留更敏感
可观测性	日志字段完整性、指标可采集性、链路追踪、换入换出命中率可见性	检查清单核对	看不到 I/O 等待就无法解释降速
可维护性	升级成本、配置管理、故障定位路径、容量规划难度	变更演练	卸载方案的参数空间大，调优成本高
安全	认证鉴权、权限控制、传输加密、数据隔离、日志脱敏与审计	安全基线核查	本地服务暴露端口是高频风险点
成本	硬件购置、扩容弹性、人力运维、迁移与试错成本	成本结构拆解	只比硬件价格会严重低估隐性成本

其中，成本结构需要特别强调：常见误区是”内存和硬盘比显卡便宜，所以卸载方案更划算”。这句话在采购单价上成立，但不等于总拥有成本更低。扩容弹性差（内存/磁盘不能像显卡那样直接提升算子吞吐）、调优人力成本高、稳定性风险需要额外投入，都属于成本项。评测应把这几项显式列出，而不是隐含假设为零。

五、评测环境与前提：控制变量清单

结论能否复用，取决于变量是否受控。测试前必须固定并书面记录以下条件：

必须固定的变量

• 显卡型号与显存容量、驱动与运行时版本；
• 内存容量、内存通道数与频率；存储类型（内存盘 / 固态 / 机械）、剩余空间、文件系统缓存策略；
• 模型权重版本、量化方式与位宽、上下文长度上限、批处理与并发设置；
• 采样参数（温度、top-p、最大输出长度）——这项对有效性和时延影响都很大，最容易被忽略；
• 网络条件（本地推理也应固定，避免上层服务成为瓶颈）。

建议建立的基线

先在同机运行一个较小的参考模型或固定计算负载，记录其稳态资源占用与时延，作为环境健康度的参照。若基线本身波动很大，后续对比结论不可信。

建议的样本设计

评测集要覆盖”典型 + 边界 + 对抗”三类：

• 典型样本：日常真实请求分布（短问答、摘要、改写）；
• 边界样本：接近上下文上限的长文档、超长输出、极短输入；
• 对抗样本：格式要求严格的结构化输出、含歧义或多跳推理的题目、异常编码与截断输入。

每条样本在两条路线上使用完全相同的输入与采样参数，并重复多次以观察方差，而不是只跑一次。

六、评测方法：可执行的测试流程

6.1 阶段一：门槛验证（先确认能不能用）

1. 冷启动加载，记录加载耗时与峰值资源占用；
2. 单条短请求推理，确认输出正常、无异常回退；
3. 逐步拉长上下文，观察 KV Cache 增长与显存余量变化；
4. 逐步拉长最大输出长度，观察内存与存储占用是否线性增长。

判定标准应是定性的：”是否在留有余量的前提下稳定运行”，而不是”是否刚好能跑起来”。刚好卡在容量上限的配置，在真实使用中会因为上下文增长而崩溃。

6.2 阶段二：时延与吞吐基线

单请求串行测试，得到 TTFT 与 TPOT 的基线；再做阶梯并发（1、2、4、8…直到 P95 延迟明显恶化），记录吞吐拐点。

示意性测试框架伪代码（通用逻辑，不含任何厂商工具或接口）：

# 通用压测骨架：同一份用例集，分别指向两条部署路线
CASES = load_cases("eval_set.jsonl")   # 含 typical / boundary / adversarial
def measure_one(endpoint, case, repeats=5):
    records = []
    for _ in range(repeats):
        t0 = now()
        resp = post(endpoint, {
            "prompt": case["prompt"],
            "max_tokens": case["max_tokens"],
            "temperature": case["temperature"],   # 必须与另一条路线一致
            "stream": True,
        })
        ttft, tokens = None, []
        for chunk in stream_chunks(resp):
            if ttft is None:
                ttft = now() - t0               # 首 token 时延
            tokens.append(chunk.text)
        total = now() - t0
        records.append({
            "ttft_ms": ttft,
            "total_ms": total,
            "tpot_ms": (total - ttft) / max(len(tokens), 1),
            "tokens": len(tokens),
            "output": "".join(tokens),
        })
    return {
        "ttft_p50": percentile([r["ttft_ms"] for r in records], 50),
        "ttft_p95": percentile([r["ttft_ms"] for r in records], 95),
        "tpot_p50": percentile([r["tpot_ms"] for r in records], 50),
        "variance": stdev([r["ttft_ms"] for r in records]),
        "outputs": [r["output"] for r in records],
    }
def run_suite(endpoint):
    result = {}
    for case in CASES:
        result[case["id"]] = measure_one(endpoint, case)
    return result
route_a = run_suite("local://route_a")   # 单卡全量驻留
route_b = run_suite("local://route_b")   # 分层卸载
compare(route_a, route_b)

采样侧要同步采集：显存/内存/存储占用曲线、磁盘顺序读带宽与 I/O 等待时间、CPU 占用、进程重启次数。缺少 I/O 指标，卸载方案的降速就无法归因。

6.3 阶段三：稳定性与异常测试

• 长稳测试：连续运行数小时，混合长短请求，观察资源曲线是否单调抬升、错误率是否随时间上升；
• 异常输入：超长上下文、空输入、异常字符、超大 max_tokens，验证是否优雅报错而非崩溃；
• 依赖异常：模拟存储读延迟升高、内存压力增大、并发抢占，观察是否出现显著降速或超时；
• 恢复测试：异常发生后能否自动恢复，是否需要人工重启。

6.4 阶段四：有效性评测

用固定评测集跑两条路线，做三项检查：任务是否完成、输出格式是否合规、人工评分是否在可接受区间。关键动作是失败归因：把失败样本分成”模型能力不足””上下文被截断””采样参数不当””输出格式解析失败”四类。很多看似”大模型更强”的差异，实际来自上下文长度或采样设置不一致，属于评测噪声而非真实能力差异。

6.5 阶段五：安全与运维核查

• 本地推理服务是否只监听回环地址，是否启用鉴权；
• 是否记录审计日志，敏感输入是否脱敏；
• 日志是否包含足够信息定位”降速发生在计算还是等待 I/O”；
• 升级流程是否可回滚，配置是否纳入版本管理。

七、结果解读：什么结果能支撑什么结论

关于时延与体感：判断标准不是某个绝对毫秒数，而是相对交互阈值的位置关系。若首字时延在长上下文下增长明显、出字速度在并发上升后快速下滑，说明系统已进入排队受限区间，交互式使用体验会下降。卸载路线更容易出现”长尾抖动”——平均值尚可但 P95 很差，这种抖动通常来自权重换入换出的 I/O 等待，而非算力不足。可通过对比”顺序读带宽利用率高 + 计算单元利用率低”这一组合来确认。

关于吞吐拐点：并发提升后总吞吐不再增长而延迟持续上升，说明瓶颈已从计算转移到访存或调度。两条路线的拐点位置差异，直接决定它适合单人使用还是多人共享。

关于有效性：只有在输入长度、采样参数、并发条件完全一致时，输出质量差异才可归因于模型本身。若差异同时伴随大量截断，应先修复上下文管理再重测。

关于稳定性：单次的”跑得动”不构成结论。资源曲线平坦、错误率为零、长稳期间无重启，才是可交付性的支撑证据。

关于成本：应比较”达到同一可用性水平的整体投入”，而不是硬件单价。若卸载方案需要额外调优人力、更高规格内存与高速存储、并且需要为不稳定性预留冗余，其总成本优势会被显著削弱。

条件化表达示例：

• 单用户、离线批处理、对时延不敏感、追求任务上限的场景，分层卸载方案更值得验证；
• 多人共享、交互式使用、对 P95 延迟敏感的场景，应重点验证并发拐点与长尾抖动，全量驻留路线的可预测性通常更有优势；
• 数据不可出内网的场景，本地部署是硬约束，应把安全与审计维度前置到功能评测之前。

八、适用场景分析

场景	优先关注维度	说明
个人开发调试	门槛、易用性、冷启动耗时	能否快速跑起来比极限性能更重要
交互式应用（助手/补全）	TTFT、TPOT、P95 稳定性	长尾抖动直接影响可用性
离线批处理（摘要、抽取、标注）	总吞吐、任务成功率	时延容忍度高，可放大吞吐优势
多用户共享服务	并发拐点、资源隔离、鉴权	卸载方案的显存共享需重点验证干扰问题
边缘 / 低配设备	门槛、功耗、散热、稳定性	长期满载的降频风险需实测
数据敏感场景	安全、审计、离线可用性	本地化是前提条件，不进入性价比讨论

若本地硬件无法满足需求，也可用同一套评测清单去横向对比托管式方案：把门槛类指标替换为弹性扩容能力，把可观测性指标替换为平台提供的日志与监控类目，把成本项替换为按需计费的资源成本。百度智能云等平台提供的模型服务、云服务器、容器平台、对象存储、监控告警等通用能力类目，都可以作为这套框架的对比对象——方法一致，结论才可比。

九、风险与限制

• 样本偏差：评测集若只覆盖短问答，会系统性低估长上下文场景的问题；反之亦然。
• 环境差异：显卡驱动、内存频率、存储介质差异足以改变卸载路线的结论方向，跨环境结论不可直接迁移。
• 测量误差：客户端打点与系统资源采样精度有限，高并发下需多次重复取分位数，单次结果无参考价值。
• 量化影响：不同量化位宽会同时改变显存占用与输出质量，混用会导致门槛与能力两个维度的结论相互污染。
• 长期不确定性：长时间运行下的内存增长、存储磨损、散热降频等问题，短测试无法暴露。
• 版本漂移：模型、运行时、量化格式任一升级都可能使结论失效，评测报告必须绑定版本号与日期。

十、选型与使用建议（决策清单）

1. 先测门槛，再谈能力：确认在留有余量（为 KV Cache 和上下文增长预留）的前提下能稳定运行，再进入质量对比。
2. 固定采样参数：两条路线的温度、top-p、最大输出长度必须一致，否则质量对比无效。
3. 看分位数不看均值：以 P95 延迟和抖动幅度作为交互体验的主判据。
4. 做失败归因：把失败样本按”能力不足/截断/参数/解析”分类，避免把工程问题误判为模型问题。
5. 补齐可观测性：确保能区分”计算慢”与”等 I/O 慢”，否则优化方向无从判断。
6. 算全成本：把调优人力、扩容弹性、稳定性冗余一并计入，而不是只比硬件单价。
7. 保留退路：把中等参数全量驻留方案作为稳定基线并行维护，作为卸载方案不达标时的回退选项。
8. 安全前置：本地服务默认只监听回环地址、开启鉴权、对日志脱敏。

十一、总结

“更小的显存门槛能跑更大的模型”是一个资源可行性的突破，但不自动等于交付可行性的提升。两条路线真正的差异在于延迟构成：一条以计算为主、可预测性强；另一条叠加了 I/O 等待、方差更大、对配置更敏感。因此评测必须分层推进——先验证门槛与可用性，再比较时延与吞吐，再验证稳定性与有效性，最后核算总成本，并在每一步用控制变量的方式确保结论可归因、可复现。

对新一代入门级中等参数模型失去兴趣、转向更大参数卸载方案，本身是一种合理的探索方向；但结论应当来自”在我的硬件、我的任务、我的并发下实测过”的数据，而不是来自门槛数字的对比。按上述框架完整走一遍，无论最终选择哪条路线，都能拿到有边界、可追溯、可回退的决策依据。