最近在帮几个团队做大模型技术选型时遇到一类很典型的诉求大家想用大模型做内部知识库问答、代码审查辅助、文档分类这些高频低复杂度任务但一看云 API 账单就犹豫了。按 token 计费的模式下内部工具一旦被团队日常使用用量会快速上涨数千甚至上万元的成本压力随之而来如果业务还涉及客户隐私数据数据能不能离开设备本身又是一道合规门槛。于是越来越多人把目光转向端侧模型把模型下载到本地用 Qwen3.8-27B 这类 8B 到 27B 规模的模型在自有硬件上完成推理。这里有一个必须说清楚的前提所谓“零成本推理”真正省掉的是按 token 叠加的边际成本而不是总拥有成本。模型可以免费下载但你需要一台能跑得动的设备、一套能稳定调用模型的工程脚手架还要解决量化、显存、工具调用、上下文管理这些问题。换句话说端侧模型本身并不等于“开箱即用”真正让模型从“能聊天”变成“能干活”的是包在模型外面那层 Harness。这篇文章会从工程视角拆解这件事什么是 Harness为什么端侧模型尤其需要专用 Harness如何用 Qwen3 8B/27B 规模模型在本地搭出一个最小可用的 Harness并给出完整代码、运行验证、常见问题和生产建议。如果你正在考虑把内部场景切到本地推理这篇文章可以帮你少走不少弯路。1. 端侧模型为什么值得做以及“零成本”的真实含义1.1 云 API 方案的四道坎先看传统路线。调用云端大模型 API 看起来简单只要拿到 Key、写几行请求就能跑起来但到了生产环境会陆续遇到四个问题。第一是成本。API 按 token 计费调用量小时没感觉一旦变成团队日常工具日请求量很容易达到百万 token 级别账单会线性增长。更麻烦的是成本通常难以预测一次不确定的会话可能消耗大量 token。第二是合规。客户数据、财务数据、内部源码一旦发送到外部 API就需要服务商的数据处理协议来兜底。很多企业和政务场景对此有硬性要求数据不能出境甚至不能离开内网。第三是网络依赖。内网物理隔离环境、机房断网、弱网环境云 API 方案直接不可用。即便网络正常公网往返也会带来额外延迟交互体验不如本地模型稳定。第四是控制权。服务商可能在未通知的情况下调整模型版本、限流策略、接口参数你的应用只能被动适配。模型下架或政策变化更是外部黑天鹅。1.2 端侧模型确实解决了一部分问题端侧模型在这四个维度上都有明显改善。模型文件下载到本地后推理过程不产生任何 API 费用数据也不需要离开设备完全离线可用不依赖公网模型版本由你自己控制换版本、回滚都是本地操作。对高频、低复杂度、敏感数据场景来说“本地跑模型”天然就是更合适的架构。用 8B 到 27B 规模的模型搭配合理量化在消费级 GPU 或 Apple Silicon 上就能获得可交互的推理速度。Qwen 系列对中文场景支持好工具调用能力在开源模型里也属于可用水平是端侧应用非常合适的底座。1.3 “零成本”不是“零代价”这里一定要把概念说清楚。“零成本推理”在营销话语里很常见但它实际指的是每次推理的边际成本趋近于零只需支付电费和硬件损耗不再按 token 付费意味着你可以在不心疼的情况下多做尝试、多跑流程数据不出设备省掉了合规审计和第三方处理相关的大量隐性成本。但真正的成本并没有消失只是转移了需要一台配置足够的设备8B 级别和 27B 级别的硬件要求完全不同需要有人负责模型下载、量化、部署、升级和排错需要开发 Harness 层否则本地模型很难稳定接入业务。因此更稳妥的判断是如果你的场景是“高频、低复杂度、敏感数据、离线可用”端侧模型是很划算的方案如果你的场景是“低频率、高难度、需要复杂推理”直接调用云 API 可能反而更省事。这篇文章讨论的是前者落点是后者这也是“端侧模型专用 Harness”真正要解决的问题让本地模型在工程上变得可靠、可维护、可观测。2. Harness 是什么从模型到能力的最后一层脚手架2.1 从评测 Harness 到任务 Harness很多开发者第一次