前两年大家都在追大参数，参数越大越好。今年风向变了：客户开始问"能不能不上云、就在本地跑"。我们做了几个 7B 级模型的端侧项目，把能力边界摸得比较清楚了，分享一下。

## 端侧部署的场景取舍

7B 级模型适合的场景有明显特征：任务边界清晰、输入输出格式固定、对世界知识要求不高。比如：工单分类、表单信息抽取、设备日志异常判断、固定话术的客服应答。这些场景下，7B 模型微调后表现完全够用。

不适合的场景：开放域问答、复杂多步推理、需要大量背景知识的咨询。别指望 7B 模型背下整个百科全书，它的天花板就在那里。

## 量化之后能力掉了多少

端侧通常要量化（INT8/INT4）才能跑得动。我们的实测经验：INT8 量化后，分类、抽取类任务几乎无感；INT4 量化后，生成类任务的流畅度和长文本连贯性会有可感知的下降，但简单任务依然可用。

关键结论：量化掉的主要是"通用能力的上限"，而垂直任务经微调后，下限是保得住的。所以路线是"先按任务微调、再量化部署"，而不是拿通用 7B 直接量化上线。

## 什么时候够用，什么时候不够

够用的信号：评测集上微调后的 7B 达到业务可用线（比如抽取准确率满足 SLA），且 badcase 集中在可规则兜底的长尾。

不够用的信号：badcase 分散在核心能力上（比如连贯推理都错）、加数据微调也上不去。这时候别硬撑，老老实实上更大模型或走云端。

我踩过最大的坑：为了省成本硬把不适合的任务塞给 7B，加了三层 prompt 工程和后处理，维护成本反而超过了直接用大模型的费用。

## 实战建议清单

- 先定义任务边界，再选模型，别反过来
- 路线固定为：任务微调 → 量化 → 端侧评测，三步缺一不可
- INT4 之前先试 INT8，很多时候 INT8 就够，精度损失更小
- 端侧评测要用真实业务数据，别只看公开榜单分数
- 给 7B 配规则兜底和置信度阈值，低置信转人工或转云端大模型

## 结尾讨论

你们在端侧用 7B 级模型时，能力边界卡在哪里？有没有"本以为不够、结果够了"的惊喜场景？聊聊。