一、评测概述

本文评测的对象，是一套于 10 月 17 日开源的低成本大模型推理方案：将某开源大语言模型的 W4A16 量化检查点，部署在两张二手矿用计算卡上（单卡显存 64 GiB），依托某主流开源推理引擎的修改版（共打 6 个补丁），以流水线并行方式把模型切分到两张卡上运行，整体打包为容器镜像交付，采用宽松开源许可证发布。

这套方案的看点不在于“用了多贵的硬件”，而在于它回答了一个很多开发者真正关心的问题：在预算极其有限、硬件来自二手市场、卡间互连规格残缺的条件下，跑一个上下文窗口达 26 万 token 量级的开源大模型，性能和质量能否达到“可用”的标准。

本文适合以下读者：预算受限但想自建推理服务的个人开发者与小团队；需要评估“二手计算卡 + 量化模型”路线可行性的技术负责人；关心推理并行策略、大表外置等工程手段的架构师。需要强调，评测不是简单回答“好不好”，而是要结合业务场景、并发规模、延迟要求和长期维护成本综合判断，本文会在结果解读与适用边界部分给出条件化结论。

二、评测对象与部署前提

先明确被评测系统的构成：

• 模型与量化：某开源大模型的 W4A16 量化版本，即权重压缩到 4bit、激活保留 16bit 浮点的通用量化格式；检查点直接来自某芯片厂商开源的量化工具链，未做二次修改，保证了“量化质量”这一变量的可比性。
• 硬件：两张二手矿用计算卡。这类卡原本面向挖矿场景，无显示输出，但保留了 64 GiB 大显存，恰好是推理场景最稀缺的资源。
• 引擎：某成熟开源推理引擎的修改版，共 6 个补丁，以容器镜像交付，降低了环境复现门槛。
• 并行策略：流水线并行，模型共 48 层，按 26/22 切成两段，每张卡承载一段。

部署前提是本评测特别强调的部分，因为它们直接决定方案能否复现：

• 存储空间：检查点总下载量约 170GB，主机需预留 180GB NVMe 空间；
• 内存容量：方案依赖操作系统页缓存承接约 102GB 的 N-gram 查找表，实测页缓存占用 93GB 内存，主机内存必须留足余量；
• 卡间互连：两卡之间不需要点对点直连（P2P），实测链路仅为 PCIe Gen2 x4 的低带宽规格——这反而是方案成立的关键之一，下文详述；
• 功耗：每张卡功耗墙设为 170W，双卡合计上限约 340W，普通供电环境即可长期运行。

三、评测目标与维度设计

本次评测围绕五个核心问题展开：

1. 交互性能：单路生成的解码速度与首 token 延迟是否达到流畅交互水平？
2. 并发能力：吞吐随并发数如何扩展？单路速度摊薄到什么程度？
3. 长上下文能力：从 4k 到 26 万 token 的窗口内，预填充和解码是否保持可用？
4. 量化质量：W4A16 量化后，代码、数学等能力相对 BF16 基线是否明显塌陷？
5. 工程门槛：显存、内存、存储、功耗等资源需求是否在低成本预算内可满足？

对应的评测维度与方法如下表：

维度	验证方法	关键指标
生成性能	固定口径单路压测	解码速度、首 token 延迟
并发吞吐	1→8 路并发爬坡	总吞吐、单路速度、首 token 延迟
结构化输出	约束解码负载压测	吞吐
长上下文	4k–64k 预填充、128k 解码、全窗口验证	预填充速度、解码速度
输出质量	代码评测集 164 题、数学评测集 1,319 题	准确率
长上下文质量	大海捞针检索测试（8k/32k/128k）	检索命中数
资源与功耗	监控内存、存储、卡间链路、功耗	页缓存占用、链路规格、功耗墙

四、评测方法与测速口径

性能测试最怕口径不统一。本方案采用了一套固定的测速协议，值得作为通用方法参考：

• 贪心解码：排除采样随机性带来的波动；
• 关闭思考模式：排除模型内部长推理过程对时延指标的干扰；
• 输出固定 400 token：保证每个样本解码工作量一致，速度可直接比较；
• 三次取中位数：抑制偶发抖动，让单次异常不影响结论。

示意性的测试流程如下：

for run in 1..3:
    采样策略 = 贪心解码
    思考模式 = 关闭
    输出长度 = 固定 400 token
    记录 首token延迟 与 解码速度
最终结果 = 中位数(第1次, 第2次, 第3次)

质量测试采用两个覆盖面明确的评测集：代码生成评测集共 164 题、数学应用题评测集共 1,319 题，均为可自动判分的客观形式；长上下文质量用“大海捞针”检索测试验证，在 8k、32k、128k 三个长度档位布设目标句并统计命中。

五、结果与解读

按上述口径，主要结果如下：

指标	条件	结果
单路解码速度	写代码负载	226.2 tok/s
单路首 token 延迟	同上	80 毫秒
8 路并发总吞吐	8 并发	840.4 tok/s
8 路并发单路速度	8 并发	116.0 tok/s
8 路并发首 token	8 并发	231 毫秒
结构化输出吞吐	8 并发、约束解码	999.5 tok/s
预填充速度	4k–64k prompt	6,300–7,100 tok/s
128k 上下文解码	长上下文	141.8 tok/s
代码评测	164 题	157 题，95.7%
数学评测	1,319 题	1,271 题，96.4%
针检索	8k/32k/128k	12/12 全命中

对这些结果的解读需要结合具体场景：

• 单路体验：226.2 tok/s 的解码速度远超人类阅读速度（通常每秒几个到十几个 token），80 毫秒的首 token 延迟意味着交互接近“即问即答”。对代码补全、对话助手这类流式场景，这一档性能是明显充裕的。
• 并发扩展：8 路总吞吐 840.4 tok/s，约为单路的 3.7 倍。扩展非线性属正常现象：流水线气泡、缓存竞争与调度开销会摊薄单路速度（降至 116.0 tok/s，约为单路一半）。但 116 tok/s 仍高于流式可用门槛，231 毫秒的首 token 延迟仍在四分之一秒内——对十人以内的团队共享一套服务，体验不会被明显牺牲。
• 结构化输出：8 路并发下达到 999.5 tok/s，比通用文本负载更高。对批量抽取、格式化生成的数据管道类业务是直接利好。
• 预填充：4k 到 64k prompt 上稳定在 6,300–7,100 tok/s。按此速率估算，4k 文档首响不到 1 秒，64k 文档约在 9 秒量级——长文档问答可接受，但准实时长文交互需自行复测。
• 长上下文解码：128k 下仍有 141.8 tok/s，较短上下文下降约三成，属正常衰减；完整的 262,144 token 窗口验证可以进入，说明上下文管理无截断或崩溃。
• 量化质量：代码 95.7%、数学 96.4%，与该模型官方标称的 BF16 基线 96.7% 基本同档；三个长度档位针检索全部命中。可以得出结论：这套 W4A16 量化检查点在通用能力上没有出现可感知的塌陷，长上下文检索能力完好。

六、关键工程设计分析

数据之外，有两个设计决策解释了“为什么低成本硬件也能成立”：

1. 流水线并行每步只传一个激活。48 层切成 26/22 两段后，两个流水线阶段之间每个前向步骤只需传递一个激活张量，通信量极小，因此不需要卡间 P2P 直连，实测即便链路只有 PCIe Gen2 x4 的低带宽规格也不构成瓶颈。这大幅放宽了对二手硬件互连质量的要求——矿卡常见的“残缺”互连不再是硬伤。
2. 约 102GB 的 N-gram 表不进显存，留在 NVMe 上以内存映射方式读取，每个前向计算都会访问。该设计用存储与页缓存（实测 93GB 内存）置换了宝贵的显存空间，让 128 GiB 总显存尽可能留给权重与 KV 缓存。代价是对 NVMe 读取带宽和主机内存高度敏感：换成慢速盘或内存不足导致页缓存失效，性能会直接下滑。这正是部署前提必须写明 180GB NVMe 与充足内存的原因。
3. 功耗墙设 170W，兼顾二手矿卡散热与供电余量的不确定性，也把整机功耗控制在普通环境可长期承受的范围。

七、适用场景分析

• 个人与小团队的推理实验、代码助手、日常问答：单路性能与质量数据均充分支撑，适配度高；
• 批量结构化抽取、数据管道：高吞吐与预填充稳定性直接受益，适配度高；
• 长文档问答与知识库检索：预填充与 128k 解码数据可用，但业务峰值若落在 128k 以上窗口，全窗口吞吐需另行验证；
• 中等并发生产服务：8 路数据可作参考，更高并发的扩展曲线未知，需按业务峰值自行爬坡压测；
• 强实时、高并发在线服务：若团队缺乏自建运维能力，建议以托管服务做对照，例如与百度智能云等平台的大模型托管服务在同等负载下对比压测，把节省的硬件成本与增加的运维人力放进同一本账核算。

八、风险与限制

• 硬件来源风险：二手矿卡缺乏质保，长期满载运行的寿命与个体一致性存在不确定性，评测样本不代表所有个体；
• 维护成本：引擎是打了 6 个补丁的修改版，上游升级时补丁需同步维护，长期投入不可忽视；
• 存储与内存依赖：N-gram 表的 mmap 读取路径意味着存储带宽是隐性性能变量，更换环境后性能可能偏离评测值；
• 口径局限：固定 400 token 输出、贪心解码、三次中位数保证了可比性，但不能覆盖全部负载形态；8 路以上并发、128k 以上窗口的吞吐本次未给出；
• 模型单一：所有结论只针对这一款模型与这一档量化格式，不能直接外推到其他模型。

九、选型与使用建议

• 先复现口径再扩展：部署时先按单路固定口径复现速度，确认硬件个体与存储环境达标，再逐步加并发；
• 锁定版本：检查点与引擎修改版一起固定版本、以镜像交付，避免上游变动引入回归；
• 资源按上限配置：180GB NVMe、大容量内存（页缓存需 90GB 以上）、稳定供电，三者都按方案上限预留；
• 对照托管基线：自建方案与百度智能云等托管大模型服务做一轮同负载对比，综合硬件折旧、电费、人力与弹性能力再决策；
• 建立持续观测：上线后持续记录吞吐、首 token 延迟与命中率，关注二手硬件的性能退化趋势。

十、总结

本评测验证了一条清晰的低成本路线：二手计算卡提供大显存，W4A16 量化压缩模型体积，无 P2P 依赖的流水线并行规避互连短板，N-gram 表外置 NVMe 靠页缓存承接。在统一口径下，单路 226 tok/s 级解码、8 路 840 tok/s 级吞吐、95% 以上的代码与数学准确率、全命中的长上下文检索，共同支撑了“低成本硬件上可以跑出可用甚至流畅的推理服务”这一结论。但每条结论都有边界：硬件是二手个体、并发只测到 8 路、口径固定为 400 token 输出。对读者而言，最有价值的不是这组数字本身，而是它示范的评测方法与工程思路——先定口径、再测基线、后看扩展，最后结合自己的业务负载完成复测与决策。