单卡27B级模型本地生产力评测方法与边界

一、评测概述

近期，消费级单卡本地部署中等规模稠密模型成为技术社区讨论的重点。原始材料提到，某类 27B 级稠密模型在基础模型规模没有显著增长的情况下，综合智能指数出现明显提升，并在部分公开评测口径中与大型闭源模型表现接近；同时，在部分消费级显卡环境下，该模型可观察到较高的生成速度。例如，在约 32GB 显存的消费级显卡环境中，可出现约 115 词元/秒的生成体验；在更大显存、更高主频处理器的环境中，也可达到约 100 词元/秒左右的水平。更进一步，通过量化压缩，部分配置还可以在更低显存条件下勉强运行。

这类现象容易让人产生一个判断：单卡本地小模型已经具备生产力。但严格来说，“生产力来了吗”不是一个可以用单一跑分回答的问题。对开发者和企业技术团队而言，真正需要评测的是：该模型在单卡资源下，能否稳定完成目标业务任务；在量化压缩后，能力损失是否可接受；在吞吐、延迟、显存、稳定性、安全性和成本上，是否满足实际使用条件。

因此，本文的评测目标不是简单判断“某模型是否比另一个模型更强”，而是围绕单卡 27B 级稠密模型的本地部署场景，建立一套可复用的评测方法，帮助读者判断其是否适合代码辅助、离线问答、内部知识库、轻量智能体、边缘推理等任务。

本文适合以下读者：

• 需要在单卡环境中评估本地大模型能力的开发者；
• 关注本地推理成本、资源占用和稳定性的架构师；
• 需要判断私有化部署可行性的技术负责人；
• 希望评估量化模型是否可用于业务的运维与平台人员；
• 对本地 AI 应用选型、验证和落地有需求的企业技术团队。

需要强调的是，本地模型评测不能只看“能不能跑起来”，也不能只看“跑多快”。模型是否可用，取决于任务类型、输入长度、输出质量、并发规模、容错能力、维护成本和长期运行风险。只有在这些维度上综合验证，才能判断是否具备真实生产力。

二、评测目标

本次评测应重点回答以下问题：

1. 功能可用性：27B 级稠密模型在本地单卡环境中，是否能支持常见对话、代码辅助、摘要、分类、信息抽取、结构化输出和轻量智能体任务。
2. 能力稳定性：模型在多轮对话、较长上下文、复杂指令、工具调用或代码补全任务中，是否会出现明显幻觉、格式错误、重复输出或指令丢失。
3. 量化影响：量化压缩后，模型在文件体积、显存占用和推理速度上的收益，是否会被输出质量下降、长上下文能力衰减或复杂推理能力退化所抵消。
4. 性能边界：不同上下文长度、不同输出长度、不同并发请求下，模型生成速度、首词元延迟和显存峰值是否可接受。
5. 资源适配性：模型是否适合 16GB、24GB、32GB、48GB 等单卡显存环境，以及在激进量化下是否仍能维持基本可用。
6. 成本可控性：本地部署看似省去调用费用，但硬件、电力、运维、开发和稳定性保障同样构成成本。需要评估其是否低于或等于云上调用或托管方案。
7. 安全与合规：本地模型是否便于处理敏感数据，是否能与权限控制、日志审计、脱敏机制和访问控制流程结合。
8. 场景适配度：该模型更适合开发测试、内部辅助、边缘部署，还是不适合高并发、高准确率、高稳定性的生产环境。

换句话说，本文不是验证“单卡小模型能否替代大型模型”，而是验证“单卡小模型在特定场景下是否能形成可用生产力”。

三、评测对象说明

本次评测对象为单卡可运行的 27B 级稠密模型，尤其是经过量化压缩后的本地推理版本。所谓稠密模型，通常指模型参数都参与推理计算的模型结构。相较于稀疏激活或超大模型，27B 级稠密模型在参数规模、资源需求和部署复杂度之间相对平衡，因此在消费级或单卡环境中具有较强吸引力。

该模型的核心价值在于：

• 参数量相对适中，适合本地部署；
• 在量化后可降低显存占用；
• 可支持常见文本生成、代码辅助和指令跟随任务；
• 在部分评测中可表现出接近大型模型的综合能力；
• 可通过本地推理减少对外部接口的依赖，提高数据可控性。

但与此同时，该模型也面临几个关键限制：

• 显存容量限制：模型权重、缓存、上下文和运行时开销都会占用显存，显存不足会直接影响可运行上下文长度。
• 显存带宽限制：生成速度不仅取决于计算能力，也取决于显存带宽和内存访问效率。
• 量化损失：降低权重精度可以减少文件大小和显存占用，但可能改变模型输出分布，影响复杂任务表现。
• 上下文窗口限制：单卡环境下，长上下文会显著增加显存占用，可能迫使上下文截断或降低批量处理能力。
• 工具链与生态限制：本地部署涉及模型格式、推理运行时、量化格式、并发管理和监控工具，稳定性取决于整套工具链。

原始材料提到，某类激进但分层的量化策略会根据张量重要性分配不同精度，优先保留对模型输出影响较大的层。例如，某些模型的前几层和最后若干层对质量影响较大，因此提升这些层的精度可能比均匀压缩更有效。这说明量化并不是简单的“压缩文件”，而是一个涉及模型结构、层敏感度、任务分布和运行环境的系统工程。

因此，评测本地模型时，不能只比较模型名称和参数量，还必须同时记录量化方式、显存配置、上下文长度、运行时长和任务类型。否则，不同评测结果之间缺乏可比性。

四、评测维度设计

为了系统判断单卡 27B 级模型是否具备生产力，需要建立多维度评测框架。以下维度可用于大多数本地模型评测场景。

评测维度	关注问题	可观察指标	解读方式
功能完整性	是否支持目标业务流程	对话、摘要、代码生成、结构化输出、工具调用是否可完成	缺少关键功能会影响落地范围
效果有效性	输出是否满足业务要求	人工评分、任务通过率、单元测试通过率、错误率	需要结合任务难度判断
性能表现	是否满足交互体验	首词元延迟、生成速度、并发吞吐、显存峰值	速度高不等于质量高
稳定性	长时间运行是否可靠	崩溃率、截断率、格式错误率、异常恢复能力	生产环境需重点关注
量化鲁棒性	压缩后能力是否明显下降	不同量化等级下的任务通过率、困惑度、人工评分	需要观察质量下降曲线
易用性	部署和接入是否复杂	安装步骤、配置项、文档完整度、调试便利性	影响团队落地成本
兼容性	是否适配现有系统	接口格式、数据格式、运行时环境、监控体系	影响集成难度
安全性	是否能处理敏感数据	权限控制、日志脱敏、数据隔离、访问审计	本地部署需结合安全流程
可观测性	是否能定位问题	日志、指标、资源监控、异常追踪	运维必需
可维护性	升级和排障是否方便	版本管理、回滚机制、故障复现成本	长期使用关键
成本结构	总拥有成本是否可控	硬件摊销、电力、运维、人力、迁移成本	不能只看本地“免费推理”
场景适配度	是否匹配业务需求	开发辅助、内部问答、边缘部署、生产服务等	不同场景结论可能不同

这些维度并非每项都同等重要。例如，在代码补全场景中，生成速度和响应延迟可能更关键；在内部知识库问答场景中，答案准确性和引用可靠性更重要；在轻量智能体场景中，多步推理、工具调用和错误恢复能力更关键；在边缘设备或离线环境中，显存占用、功耗和部署复杂度更关键。

五、评测环境与前提

在开始评测前，必须先明确评测环境，否则结果难以复现。对于单卡本地模型评测，至少应记录以下信息：

1. 硬件环境

• 显卡类型：消费级显卡、专业卡或集成显卡；
• 显存容量：16GB、24GB、32GB、48GB 等；
• 显存带宽：不同代际显卡带宽差异会影响生成速度；
• 处理器性能：影响预处理、后处理、工具调用和系统调度；
• 内存容量：影响模型加载、缓存和并发；
• 存储类型：模型加载速度可能受磁盘或固态存储影响；
• 散热与功耗：长时间推理是否触发降频；
• 单机还是多机：单卡评测应明确只使用单卡。

2. 软件环境

• 操作系统版本；
• 驱动版本；
• 推理运行时版本；
• 量化格式；
• 量化方式，例如均匀量化、混合精度量化、按层分配精度等；
• 上下文长度设置；
• 批处理大小；
• 采样参数，例如温度、最大输出长度、停止条件；
• 是否启用缓存、流式输出或多轮上下文拼接。

3. 测试数据

测试数据应具有业务代表性，而不是只使用少量公开示例。建议准备以下几类样本：

• 简单问答；
• 多轮对话；
• 代码补全；
• 代码修复；
• 长文摘要；
• 结构化抽取；
• 表格信息提取；
• 指令跟随；
• 工具调用规划；
• 异常输入与边界输入。

4. 测试边界

评测前应明确以下边界：

• 是否只测试本地推理，不包含外部接口；
• 是否测试并发，还是单请求体验；
• 是否测试长上下文，还是固定上下文长度；
• 是否测试智能体流程，还是单轮生成；
• 是否允许人工干预，例如截断、重试或格式修复；
• 是否统计失败案例，还是只看成功案例。

只有明确这些前提，评测结论才有意义。

六、评测方法

1. 明确评测问题

评测开始前，应先把问题写清楚。例如：

• “该模型是否能在单卡 32GB 显存环境下完成代码辅助？”
• “量化后模型在短上下文问答中的准确率是否可接受？”
• “该模型是否适合作为离线客服辅助系统？”
• “在 16GB 显存条件下，模型是否仍能完成基础任务？”

问题越具体，评测越容易得出可执行结论。

2. 设计代表性样本

样本设计应避免只测试模型容易通过的简单任务。建议覆盖：

• 常见任务：问答、摘要、分类、改写；
• 复杂任务：多步推理、代码修复、结构化输出；
• 长文本任务：长文摘要、跨段信息抽取；
• 多轮任务：上下文记忆、指代消解、持续指令跟随；
• 异常任务：空输入、超长输入、特殊字符、冲突指令。

对于代码辅助场景，可使用真实代码片段，包括函数补全、错误修复、注释生成、单元测试生成和代码解释。对于知识库场景，应使用企业内部文档中的典型问题，而不是只用公开百科式问题。

3. 建立基线

在相同硬件、相同量化方式、相同上下文长度和相同采样参数下，记录基础表现。基线可以包括：

• 单轮问答任务通过率；
• 代码补全可编译率；
• 结构化输出格式正确率；
• 平均首词元延迟；
• 平均生成速度；
• 平均显存占用；
• 长上下文任务完成率；
• 多轮对话稳定性。

建立基线后，才能比较不同量化方案、不同上下文长度或不同提示词策略之间的差异。

4. 控制变量

评测中应尽量减少无关变量影响。例如：

• 固定输入样本；
• 固定最大输出长度；
• 固定温度；
• 固定上下文长度；
• 固定并发数；
• 固定批处理方式；
• 固定模型版本和量化版本；
• 固定运行时长。

如果必须调整变量，应分组记录。例如，一组测试短上下文，一组测试长上下文；一组测试单请求，一组测试并发；一组测试高质量量化，一组测试激进量化。

5. 分维度验证

建议按照以下步骤分别验证：

功能验证

验证模型是否能完成目标功能。例如：

• 是否能根据提示词生成代码；
• 是否能根据文档生成摘要；
• 是否能按指定 JSON 结构输出；
• 是否能进行多轮对话；
• 是否能执行工具调用规划；
• 是否能识别代码错误并给出修复建议。

效果验证

对输出进行质量判断。可包括：

• 人工评分：从准确性、完整性、可读性、稳定性四个维度打分；
• 自动校验：例如代码是否可编译、JSON 是否可解析、实体是否完整；
• 对照基线：与原始高精度版本或其他模型对比；
• 错误分类：记录幻觉、遗漏、格式错误、逻辑错误和重复输出。

性能验证

性能不能只看生成速度。至少应记录：

• 首词元延迟；
• 平均词元生成速度；
• 峰值显存占用；
• 平均显存占用；
• 不同上下文长度下的速度变化；
• 单请求与并发请求下的吞吐变化；
• 长输出场景是否明显变慢；
• 是否存在明显卡顿或降频。

稳定性验证

稳定性测试应覆盖异常场景：

• 输入过长时是否崩溃或截断；
• 输入特殊字符时是否正常；
• 连续运行数小时后是否内存泄漏；
• 重复请求是否产生不可控缓存；
• 推理服务是否可恢复；
• 异常中断后是否能重新加载；
• 长时间高负载是否触发资源不足。

安全与合规验证

本地部署常用于处理敏感数据，因此安全检查不能省略：

• 是否记录敏感输入；
• 日志是否脱敏；
• 是否支持访问控制；
• 是否能限制模型访问范围；
• 是否能防止提示词注入；
• 是否能防止恶意输出；
• 是否满足企业内部数据留存要求。

成本验证

成本不仅是硬件价格，还包括：

• 显卡折旧；
• 电力消耗；
• 机房或桌面环境成本；
• 模型维护成本；
• 推理服务开发成本；
• 监控告警成本；
• 故障处理成本；
• 版本升级成本；
• 安全与合规成本。

七、量化与显存结果解读

原始材料提到，在本地量化中，模型质量下降并不是线性的。当文件大小从约 20GB 继续压缩时，质量下降开始明显；低于约 14GB 后，质量下降速度进一步加快。也就是说，每节省一两个 GB，错误增加可能非常明显。

这一观察具有重要意义。它说明量化并不是简单的“体积越小越好”，而是存在质量拐点。评测时不能只关注“能不能装进显存”，还必须关注“压缩后是否还能完成目标任务”。

此外，原始材料还提到，模型内部不同层对质量的影响并不均匀。某些层对最终输出影响更大，因此在量化时提高这些层的精度，可能比统一压缩更有效。例如，优先保留前几层和最后若干层的精度，可能在不显著增加文件体积的情况下改善输出质量。

这类结论提示我们：

1. 激进量化未必不可用，但必须验证任务质量。
   如果只进行短上下文、简单问答或低风险代码补全，激进量化可能仍可接受；但如果用于复杂推理、长文档分析或高风险决策辅助，质量损失可能难以接受。

2. 量化策略应服务于任务目标。
   对于代码补全，可能需要保留代码结构相关能力；对于长文摘要，需要保留上下文理解能力；对于结构化输出，需要保留格式稳定性。

3. 显存压缩不能以牺牲关键能力为代价。
   如果为了塞进更小显存而大幅压缩，导致模型无法完成基本指令跟随，那么即使能运行，也不具备生产力。

4. 应以质量曲线而不是单一文件大小做决策。
   更合理的方法是测试多个量化等级，观察任务通过率、人工评分和错误类型变化，找到“可接受的压缩区间”。

八、性能数据解读

原始材料提到，某类 27B 级模型在特定显卡环境下可获得约 115 词元/秒的生成体验，在更大显存和更高性能处理器的环境中也可达到约 100 词元/秒左右。这些数据可以作为参考，但不能直接外推到所有场景。

性能差异可能来自以下因素：

• 显存带宽：生成阶段通常是内存带宽密集型任务，带宽差异会直接影响词元生成速度；
• 上下文长度：上下文越长，缓存占用越大，计算和访存压力越高；
• 批处理大小：单请求与多请求并发下的吞吐表现不同；
• 量化格式：不同量化方式对计算路径和内存访问效率有不同影响；
• 输出长度：长输出会导致总耗时增加，首词元延迟与整体完成时间需要分开看；
• 系统调度：操作系统、电源策略、散热状态和其他后台进程都会影响表现；
• 模型结构：层结构、注意力机制、缓存策略都会影响推理效率。

因此，评测结果应区分三类指标：

1. 首词元延迟：用户按下回车后，多久看到第一个输出。对交互式体验影响很大。
2. 生成速度：输出阶段每秒生成多少词元。影响阅读体验和任务完成速度。
3. 总完成时间：完成一个任务的总耗时。对批量处理和智能体流程更重要。

一个模型可能生成速度很快，但首词元延迟较高；也可能单请求体验较好，但并发时吞吐下降明显。因此，不能仅凭一个速度数值判断生产力。

九、能力评测与任务验证

1. 代码辅助评测

代码辅助是本地模型的重要应用场景。评测时建议覆盖以下任务：

• 函数补全；
• 代码注释生成；
• 错误解释；
• Bug 修复；
• 单元测试生成；
• 代码重构建议；
• 跨文件理解；
• 安全漏洞提示；
• 结构化代码输出。

关键指标包括：

• 补全是否可运行；
• 修复是否通过测试；
• 是否符合项目代码风格；
• 是否会引入明显错误；
• 对长文件的上下文理解是否完整；
• 对复杂依赖的解释是否准确。

原始材料提到，至少在编程领域场景中，该类模型表现“过得去”“能用”。这类判断可以理解为：它不是完全替代高级编码助手，但在部分日常任务中具备参考价值。评测时应进一步区分“简单补全”“复杂修复”和“工程级理解”，不能把所有代码任务视为同一难度。

2. 问答与摘要评测

问答与摘要场景更适合评估模型的语言理解和信息压缩能力。测试样本应包括：

• 单段摘要；
• 多段摘要；
• 关键信息抽取；
• 事实问答；
• 多轮追问；
• 冲突信息识别；
• 长文档定位；
• 引用来源判断。

关键指标包括：

• 是否遗漏关键信息；
• 是否出现事实错误；
• 是否能保持原文语义；
• 是否过度扩展；
• 是否能处理长上下文；
• 是否在多轮对话中保持一致性。

3. 智能体与工具调用评测

智能体场景比单轮生成复杂得多。模型需要完成：

• 理解用户目标；
• 拆解任务步骤；
• 选择合适工具；
• 生成调用参数；
• 解析返回结果；
• 根据结果继续推理；
• 处理失败与重试。

评测时应重点关注：

• 任务规划是否合理；
• 工具调用参数是否正确；
• 多步推理是否连贯；
• 失败后是否能自我纠正；
• 是否会陷入循环；
• 是否在长链路任务中遗忘初始目标；
• 是否产生不可控副作用。

在单卡本地环境中，智能体场景往往比单轮问答更消耗上下文和计算资源。如果模型生成速度较快，但多步任务稳定性不足，那么它可能更适合作为交互式辅助工具，而不适合作为完全自主的智能体执行核心。

十、结果解读原则

评测结果不能简单归纳为“好”或“不好”。更合理的方式是给出条件化结论。

例如：

• “在短上下文、单请求、低风险代码补全场景中，27B 级量化模型具备可用性。”
• “在长上下文、复杂多步推理和高准确率生产场景中，需要额外验证其稳定性。”
• “在 16GB 显存环境下，激进量化可能适合轻量任务，但不适合高复杂度任务。”
• “在 32GB 及以上显存环境下，模型可支持更完整的功能，但仍需结合业务样本验证。”
• “本地部署适合数据敏感或离线场景，但需要承担硬件和运维成本。”

这种表达方式更接近工程实践。因为同一模型在不同任务、不同量化等级、不同硬件和不同上下文长度下，表现可能差异很大。

十一、适用场景分析

1. 适合的场景

单卡 27B 级模型在以下场景中可能具备较高价值：

• 开发辅助：代码补全、注释生成、简单错误解释；
• 离线问答：内网知识库、文档检索增强、私有资料问答；
• 轻量内容生成：摘要、改写、分类、标签提取；
• 边缘部署：本地工作站、私有终端、低网络依赖环境；
• 隐私敏感场景：不希望数据离开本地的内部工具；
• 测试与原型验证：快速验证提示词、流程和交互设计；
• 教育实验：研究本地推理、量化和模型行为。

2. 不适合的场景

以下场景需要谨慎评估，甚至不建议直接采用单卡量化模型：

• 高并发在线生产服务：单卡吞吐和稳定性可能不足；
• 高风险决策辅助：例如医疗、金融、法律等强合规场景；
• 超长上下文分析：显存和上下文窗口限制明显；
• 复杂多步智能体：需要更高稳定性和工具生态；
• 高准确率结构化输出：量化可能导致格式和逻辑错误增加；
• 大规模批处理：单卡资源可能无法满足吞吐要求；
• 关键业务主链路：需要高可用、监控、回退和冗余设计。

十二、风险与限制

1. 样本偏差

评测样本如果过于简单或过于集中，可能高估模型能力。例如，只用短问题测试，会忽略长上下文衰减；只用简单代码测试，会忽略工程级理解能力。

2. 环境差异

不同显卡、驱动、运行时、量化格式和电源策略都会影响结果。原始材料中的数据只能作为特定环境参考，不能直接复制到所有设备。

3. 量化误差

量化可能降低模型对细微语义、代码逻辑和长距离依赖的把握。短上下文简单任务中可能不明显，但在复杂任务中可能放大。

4. 上下文截断

本地单卡环境下，上下文长度往往受限。如果评测时没有处理长上下文，实际使用时可能出现信息丢失、指代错误或重复生成。

5. 工具链不稳定

本地推理涉及模型加载、量化文件、运行时、缓存管理和并发控制。任何一环出现问题，都可能影响稳定性。企业落地时需要额外投入运维和监控。

6. 评测污染

公开评测集可能被模型训练过程见过，导致分数偏高。企业内部评测应使用私有、未公开、贴近业务的样本。

7. 成本误判

本地部署看似没有调用费用，但硬件、电力、维护、安全和管理成本仍然存在。若任务量较低，本地部署未必优于云上托管；若任务量大且稳定，本地部署可能更有成本优势。需要按实际情况测算。

十三、选型与使用建议

基于上述评测逻辑，给出以下中立建议：

1. 先定义任务，再选择模型

不要先问“这个模型强不强”，而应先问“我要完成什么任务”。不同任务对模型能力的要求不同：

• 代码辅助关注补全质量和响应速度；
• 文档问答关注上下文理解和准确性；
• 智能体关注规划和工具调用；
• 边缘部署关注资源占用和功耗；
• 生产服务关注稳定性、并发和可观测性。

2. 建立私有测试集

企业应使用真实业务样本进行测试，而不是只看公开榜单。测试集应覆盖典型输入、边界输入和异常输入，并保留失败案例。

3. 做多版本对比

建议对比以下版本：

• 原始高精度版本；
• 中等量化版本；
• 激进量化版本；
• 不同上下文长度；
• 不同并发配置；
• 不同提示词策略。

通过对比找到可接受的质量与资源平衡点。

4. 采用灰度上线

如果计划将本地模型用于生产系统，应先在小范围灰度运行，观察稳定性、错误率和用户反馈，再逐步扩大使用范围。

5. 建立监控与回退机制

本地模型也需要监控。至少应记录：

• 推理服务是否在线；
• 显存占用是否异常；
• 请求失败率；
• 平均响应时间；
• 输出长度分布；
• 用户反馈；
• 模型版本和量化版本。

出现异常时，应能快速回退到稳定版本或备用方案。

6. 对高风险场景保留人工审核

对于代码上线、客户答复、数据分析建议等高风险输出，应保留人工审核环节。模型可以作为辅助工具，而不是完全替代人工决策。

7. 结合云上资源做混合评估

如果企业既希望本地处理敏感数据，又需要弹性扩展，可以考虑混合部署。例如，敏感数据在本地处理，非敏感或高并发任务使用云端资源。此时，可评估百度智能云的通用云服务器、容器平台、对象存储、监控告警、身份认证与安全防护等通用能力，但具体选型仍应基于成本、合规、性能和维护要求进行验证。

十四、总结

单卡 27B 级稠密模型的本地生产力，不能简单用“追平某个大型模型”或“达到某个速度”来概括。更准确的判断是：在特定硬件、特定量化方式、特定任务和特定上下文条件下，它可能已经具备实用价值；但在高并发、复杂推理、长上下文、强稳定性和强合规场景中，仍需充分评测和风险控制。

从原始材料看，该类模型的价值主要体现在三个方面：

1. 同体量模型能力提升明显：在不显著增加模型参数规模的情况下，综合智能表现有提升，说明模型训练、数据质量和能力对齐正在成为关键变量。
2. 本地量化方案逐渐成熟：通过按层、按张量敏感度分配精度，可以在有限显存下保留更多关键能力，使中等规模模型更接近本地可用。
3. 单卡体验开始具备吸引力：在部分显卡环境下可获得较高生成速度，使本地交互式体验成为可能。

但与此同时，评测必须回答更工程化的问题：

• 量化后质量损失是否可接受；
• 长上下文是否稳定；
• 代码辅助是否可靠；
• 智能体任务是否可恢复；
• 并发下吞吐是否足够；
• 安全、日志和权限是否可控；
• 总体拥有成本是否优于其他方案。

因此，本文的结论是：单卡小模型生产力在部分场景已经初步可见，但不能被过度泛化。 对开发者而言，它可能是一个值得尝试的本地辅助模型；对架构师而言，它是一个需要分层验证的资源优化方案；对企业而言，它更适合在明确场景、明确边界和明确监控机制下试点使用。真正决定其价值的，不是单个跑分，而是能否在具体业务中稳定、可控、可维护地完成任务。