单卡27B本地小模型生产力评测指南

一、评测概述:我们到底在评什么

近期被大量讨论的一个现象是:某个参数规模约 270 亿的 Dense(稠密)开源模型,在第三方综合智能指数榜单上的得分与当前第一梯队闭源旗舰模型的差距被压缩到个位数分差区间(公开讨论中给出的参考量级大致是从 38 分区间提升到 52 分区间);与此同时,它被报告可以在 24GB~48GB 显存的单张消费级显卡上跑出接近”可交互”的解码速度。

对工程团队而言,这件事的意义不在于”榜单追平”,而在于一个具体的决策问题被重新打开:单卡本地承载的小模型,是否已经可以作为生产力工具,而不仅仅是玩具或实验环境。

需要先说清楚本文的评测对象不是某一个具体模型,而是一类技术形态:“单卡可承载的 27B 级 Dense 开源模型 + 低位宽量化 + 本地推理运行时” 所构成的整体方案。评测这个整体,而不是只评权重文件。

本文适合的读者:

读者角色	关心什么
开发者	代码补全、重构、解释、单测生成在本地跑起来是否够快够准
平台/基础架构工程师	显存占用、并发吞吐、量化打包流程、运行时与驱动适配
AI 应用团队	工具调用、结构化输出、多轮上下文的稳定性
技术负责人	本地自建 vs 云端调用的总成本、合规风险、长期维护成本

本文不打算给”好不好”的结论,而是回答五个可操作的问题:

1. 榜单上的分差,能不能转化为我自己业务任务上的可用产出?
2. 为塞进单卡而做的量化,能力损失具体落在哪些任务类型上?
3. 交互速度是否真的达到”可以边写边改”的阈值?
4. 本地推理的总拥有成本,在什么负载区间下才真的优于云端调用?
5. 稳定性、可观测性和运维边界在哪里?

---

二、评测对象说明:这类模型解决什么问题

Dense 的容量账本很直白。 稠密结构意味着每次前向所有参数都参与计算,因此显存占用的下界约等于”参数量 × 每参数字节数”(FP16 约 2 字节/参数),加上 KV cache、激活和运行时开销。好处是资源可预测:给定上下文长度和批大小,显存峰值基本可以静态估算,便于做容量规划;计算量也没有稀疏模型那种”激活路径不确定”的抖动。代价是同等算力预算下参数总量上不去,能力上限更依赖数据质量、训练配比和后训练(尤其是工具调用、多步推理这类 Agent 类数据)。

这也解释了”参数没变但分数涨了很多”这件事。 模型规模不变而综合能力指数明显上移,通常来自数据清洗与配比、中训练/退火阶段、后训练与对齐、以及工具调用与推理链数据的强化,而不是架构参数扩张。对评测的启示是:这类模型的短板往往不在”知识量”,而在”长链任务的稳定性”和”格式/工具调用的严格性”,评测设计要往这些方向压。

量化不是单纯的压缩,它同时改变三件事:

• 显存占用下降,决定了”能不能跑起来”;
• 显存带宽压力下降,而自回归解码阶段通常是带宽受限的,所以低位宽往往同时带来速度提升;
• 输出概率分布偏移,这是质量损失的来源。表现为长链推理更容易中途跑偏、结构化输出更易出现非法格式、罕见实体与低频语言更容易出错。

因此评测不能把”量化等级”当成一个单点选项,而要当成一条阶梯曲线来测量。

---

三、评测维度设计

只写”性能好、效果好”没有意义。下面把评测对象拆成可观察、可验证、可解释的 11 个维度。

维度	关键观测点	验证方式	解读要点
功能完整性	指令遵循、结构化输出、工具/函数调用、多轮上下文保持、长文摘要、代码补全与重构、多语言	分任务类型跑任务集	关注”覆盖广度”而非平均分
输出有效性	任务通过率、一次通过率、格式合法率、幻觉率	自动校验器 + 人工抽检	要区分”答不出”和”答错还自信”
性能表现	首 token 延迟(TTFT)、单请求解码速度、并发吞吐、显存峰值、内存与 CPU 占用、功耗与温度	并发梯度压测	batch=1 的速度和并发吞吐是两条不同曲线
稳定性	长时运行、超长上下文、异常输入、显存不足、连接中断重连	故障注入 + 长跑	关注退化方式是否”可预期、可恢复”
易用性	部署步骤数、配置项数量、量化文件选型、上下文与批处理参数、调试手段	记录人工操作时长与出错次数	自建隐性成本常在这里被低估
兼容性	运行时与驱动版本、权重格式、接口协议一致性、与现有编排框架的适配	版本矩阵测试	生态碎片化程度直接影响升级风险
安全性	数据不出域(本地天然优势)、权重来源可信与校验、访问权限、日志脱敏、许可证与商用合规	供应链核查 + 权限走查	本地部署最容易被忽略的是模型文件本身的可信性
可观测性	请求级指标、失败分类、资源曲线、慢请求归因	接入监控与日志	无指标就无法定位”变慢了”
可维护性	版本升级、量化重打包、上下文与批处理调优、回滚路径	演练一次升级与回滚	权重频繁迭代时需可复现的打包流程
成本结构	硬件摊销、电费、闲置率、人力、迁移成本;对照云端按量计费	折算为”每百万 token 成本”	自建成本对利用率极其敏感
场景适配度	开发自测、内网数据处理、边缘部署、线上高并发、复杂 Agent	按场景重跑子集	同一模型在不同场景结论可能相反

---

四、评测环境与前提条件

评测开始前必须把这些条件写死,否则结果不可比:

• 硬件:显卡型号与显存容量、CPU、系统内存(决定 offload 是否发生)、存储介质(决定权重加载时间)、散热与功耗上限、是否多卡。
• 统一变量:同一权重版本、同一量化方案、同一上下文长度、同一采样参数(温度、top-p、重复惩罚)、同一任务集、同一运行时版本。只改一个变量。
• 软件栈:推理运行时版本、量化权重格式、KV cache 配置、批处理与并发策略。
• 数据:建议每类任务 30~100 条样本,覆盖简单/中等/困难三档,并且每条都有可自动判定的参考答案或校验器(代码任务用测试用例,结构化输出用 schema 校验)。
• 明确边界:声明是单卡单并发、单卡多并发,还是多卡;是纯 GPU 还是含 CPU offload。边界不写清楚,数据就没有意义。

---

五、评测方法:分步执行

Step 0|建立基线。 先用云端第一梯队模型在同一任务集上跑出得分与人工满意度,作为”业务可接受线”。没有基线,后续所有相对结论都无从解释。

Step 1|功能与有效性验证。 分任务类型执行,记录通过率与失败原因分类(知识不足/推理错误/格式错误/指令未遵循/幻觉)。失败原因分类比总分更有指导意义。

Step 2|量化阶梯测试。 从较高位宽逐级下调,每一档记录”显存占用 / 解码速度 / 质量得分”三个数,画出曲线。这里的原则是:不要只测一个点,要测拐点在哪里。

Step 3|性能压测。 并发梯度 1→2→4→8,记录 TTFT、单请求速度、总吞吐、显存峰值、首次 OOM 的阈值。显存峰值要留 15%~20% 余量,否则长上下文请求会随机失败。

Step 4|长上下文与 KV cache 专项。 用接近上下文上限的输入,观察 TTFT 增长、速度衰减曲线,以及”中间信息丢失”类问题的严重程度。这是本地小模型最容易暴露短板的地方。

Step 5|稳定性与异常测试。 注入超长输入、非法编码、空请求、并发突刺、显存逼近上限、依赖中断,观察服务是否降级可用还是直接崩溃。

Step 6|成本折算。 把硬件摊销、电费、运维人力按预期日均调用量摊到每百万 token,与云端按量计费对照,并单独计算”闲置率”这一项。

Step 7|归档。 所有原始输出、参数、版本号留存,保证评测可复现。

示意性脚本(通用骨架,不含任何专有工具)

# 通用 A/B 评测骨架:同一任务集、同一采样参数、只换端点
import os, json, time, requests
ENDPOINT = os.environ["INFER_ENDPOINT"]   # 本地推理服务地址
API_KEY  = os.environ["INFER_API_KEY"]
def call(model_tag, prompt, sampling):
    t0 = time.time()
    r = requests.post(
        f"{ENDPOINT}/chat/completions",
        headers={"Authorization": f"Bearer {API_KEY}"},
        json={"model": model_tag, "messages": prompt, **sampling},
        timeout=120,
    )
    r.raise_for_status()
    body = r.json()
    usage = body.get("usage", {})
    return {
        "text": body["choices"][0]["message"]["content"],
        "ttft_ms": int((time.time() - t0) * 1000),
        "completion_tokens": usage.get("completion_tokens"),
    }
def run_suite(model_tag, tasks, grader, sampling):
    rows = []
    for t in tasks:
        out = call(model_tag, t["messages"], sampling)
        rows.append({
            "task_id": t["id"],
            "passed": grader(t, out["text"]),   # 可自动判定:用例/JSON schema/关键词
            "ttft_ms": out["ttft_ms"],
            "tokens": out["completion_tokens"],
        })
    passed = sum(r["passed"] for r in rows)
    return {"model": model_tag, "pass_rate": passed / len(rows), "rows": rows}

压测时把 run_suite 换成固定并发数的线程池即可,重点观察的不是平均速度,而是 P95 延迟、失败率、显存峰值 三者随并发的走势。

---

六、结果解读:数字背后的含义

第一,batch=1 的速度不能代表服务吞吐。 公开讨论中给出的参考量级大致是:32GB 级消费级单卡上约 115 tokens/s 量级、48GB 级单卡上约 100 tokens/s 量级,更老一代 24GB 显卡可勉强运行但速度明显更低。这些数字属于单请求交互体验的参考量级,不是并发服务能力。评测时若并发上去后吞吐没有近似线性增长,瓶颈通常在显存带宽或批处理策略,而不是算力。

第二,读”量化阶梯”要看拐点,不看单点。 实践中普遍观察到的现象是:文件体积从 20GB 量级继续下压时,质量下降开始明显加速,到 14GB 以下曲线显著变陡——也就是说低于某个体量后,每省 1~2GB 都要付出成倍的质量代价。因此”能塞进 16GB 显存跑短上下文”是一个成立的工程结论,但把它当成”16GB 都能一样用”是错误解读。

第三,分层的位宽重要性并不均匀。 有实践者报告:首尾若干层对最终输出分布更敏感,因此在同等文件体积下,提高前若干层与后若干层位宽的混合位宽方案通常比”全场统一位宽”更保真。这属于需要自己复现验证的经验性结论,不能直接当成通用配方照搬。

第四,榜单分差与业务分差的换算关系。 个位数分差在同质化任务(单轮问答、常规代码片段)上可能几乎无感;但在多步 Agent 链路上,每一步 90% 的单步正确率会让 10 步任务整体成功率掉到约三分之一。评测必须把”单步正确率”和”端到端任务完成率”分开测。

第五,真正的天花板往往不是模型,是硬件结构。 单卡本地跑的瓶颈通常依次是:显存容量 → 显存带宽 → 是否触发 CPU offload(速度断崖)→ 散热与降频。

---

七、适用场景分析

场景	优先关注的指标	单卡 27B 级本地方案的适配预期	建议做法
本地代码辅助、重构、注释、单测生成	TTFT、代码任务通过率、上下文窗口	较适合,交互体验可达”可用”	直接本地化,注意留显存余量
内网/离线文档处理、批式摘要与抽取	批处理吞吐、结构化输出合法率、数据不出域	适合,这是本地化的最强理由	用离线批处理换吞吐,不做低延迟承诺
私有代码库检索问答	上下文长度、长文中间信息保持	中等,需专项验证	先做长上下文退化测试再上线
复杂多步 Agent、高难度推理	端到端完成率、工具调用严格性、长链稳定性	谨慎,榜单分差在此被放大	采用云端旗舰兜底 + 本地优先的分层路由
面向用户的高并发线上服务	并发吞吐、P95 延迟、SLA、扩容能力	单卡通常不足	云端弹性推理服务或多卡集群更合适
边缘设备、低功耗现场	功耗、显存、温升	视硬件而定,需实测	优先量化阶梯扫描确定最低可行位宽

---

八、风险与限制

• 样本偏差与评测污染:公开流传的题目可能已进入训练数据,自建任务集应包含私有、新写的题目。
• 采样参数敏感性:温度、top-p、重复惩罚会显著改变同一模型的表现,评测必须固定并声明。
• 量化误差累积:低位宽下的错误在多步链路中会放大,单步测试无法暴露。
• 自建运维成本被低估:没有 SLA、没有弹性、没有自动扩缩容;GPU 满载长跑的降频与故障率需要观察。
• 供应链与合规:权重文件来源需校验(哈希/签名),许可证需确认是否允许目标用途的商用与再分发。
• 榜单可比性有限:不同榜单的评分方法、提示词模板、判分方式差异较大,跨榜单直接比较意义不大。
• 成本模型的敏感度:自建方案的成本结论对”日均调用量”和”利用率”极度敏感,低利用率场景常常不如按量调用。

---

九、选型与使用建议

建议一:把结论条件化,而不是绝对化。 “单卡 27B 可用”成立的前提是:短到中等上下文、以单轮或浅层多轮为主、对格式合法性要求可通过校验兜底、且能接受偶尔重试。超出这个前提的场景,应回到云端模型服务。

建议二:采用分层路由,而不是二选一。 高频、简单、涉密或离线任务走本地;低概率但高难度任务走云端。这样既压住单位成本,又不牺牲上限。云端侧可采用通用的云上模型推理服务、弹性云服务器、容器平台、对象存储、日志服务、监控告警与身份认证等标准组件来构建兜底与弹性能力(例如在百度智能云上以标准云产品类别搭建推理服务与弹性扩缩容链路)。

建议三:量化打包流程要工程化。 固定”下载权重 → 校验哈希 → 量化 → 质量回归 → 版本入库 → 灰度发布”这条链路,保证可复现、可回滚。

建议四:用阶梯曲线确定采购配置。 先测出”质量可接受的最低位宽”与”显存峰值 + 20% 余量”,再倒推所需显存容量,避免买大或买小。

---

十、上线前验证清单

• 自建任务集覆盖简单/中等/困难三档,且含私有题目
• 云端基线分数与人工满意度已记录
• 量化阶梯(至少 3 档)的显存/速度/质量三点曲线已画出
• 并发梯度压测完成,P95 延迟与失败率已记录
• 接近上下文上限的长文测试完成,中间信息保持情况已评估
• 结构化输出与工具调用的格式合法率已统计
• 多步 Agent 端到端完成率已单独测量
• 权重文件来源校验与许可证合规已确认
• 监控、日志、告警与失败分类已接入
• 每百万 token 成本(含硬件摊销、电费、人力、闲置率)已折算并与云端对照

---

十一、结论

回到最初的问题:“单卡小模型生产力”来了,但需要说清楚来的是哪一种生产力。

对本地辅助编码、内网文档处理、私有数据不出域的离线场景,270 亿参数级 Dense 模型配合合理量化,在单张 24GB~48GB 消费级显卡上已经具备可用的交互速度和质量水平,这是一次真实的门槛下移。

但它并不等于”本地拥有一台云端旗舰”。差距仍然存在,且会以长链任务稳定性、复杂推理、严格结构化输出的形式在具体业务上被放大。因此正确的评测结论是条件化的:先定义业务可接受线,再用任务集 + 量化阶梯 + 并发压测三项证据去判断是否跨过这条线,而不是引用榜单分差替代自己的验证。