企业选择本地 AI 模型时，最危险的问题不是“哪个模型最强”，而是在没有写清数据边界、并发、响应时间和运维责任前，就先下载一个热门模型。一个模型能够在笔记本上启动，只能证明文件可以加载；它不能证明知识库回答可验收、并发可承受、许可证允许商用，也不能证明升级后业务结果仍然稳定。
更可靠的顺序是：先决定哪些数据和任务必须留在本地，再为硬件、延迟、并发和运营设上限；然后按模型规模和任务形成候选集，最后用企业自己的样本做同条件试点。本地部署是数据与运行位置的选择，模型选型是质量、容量、许可和生命周期的共同决策。两者不能被一张“十大模型榜单”替代。
1. 先否决错误问题：不要从模型名开始
旧式榜单通常把开放权重模型、托管 API、研究模型和商用许可模型放在一张表里，再用“中文好”“推理强”“单卡可用”做结论。这种比较会制造三个工程错误。
第一，可调用不等于可私有部署。只有能合法取得权重，并在企业控制的基础设施上运行，才属于本文讨论的本地候选。Claude、Gemini 等托管服务可以进入“云端或混合方案”对比，但不能被写成本地权重模型。
第二，参数量不等于业务效果。同一规模的通用、代码、推理、多模态和嵌入模型服务不同任务。企业知识库需要事实引用和拒答能力，代码助手需要仓库语境，边缘设备需要功耗、包体与离线稳定性。拿单一公开榜单替代业务测试，结果往往是模型分数好看、流程仍不可用。
第三，能跑不等于能运营。模型服务还需要身份、限流、日志、版本、回归集、灰度、回滚与容量告警。若这些责任无人承担，私有化只把 API 账单换成了更隐蔽的基础设施和运维账单。
因此，第一轮不是给模型打分，而是给方案设置否决条件：不满足数据边界、许可、容量或责任归属的方案，直接退出候选集。
2. 把业务需求翻译成五个硬约束
一份可执行的选型输入至少包含五类约束。缺任何一类，模型比较都容易失真。
| 约束 | 必须回答的问题 | 不回答的后果 |
|---|---|---|
| 数据边界 | 原文、提示词、检索片段、日志和输出能否离开内网 | 以为“模型在本地”就安全，实际日志或向量仍外传 |
| 任务合同 | 输入、输出、拒答、引用、结构化字段怎样验收 | 只比较聊天观感，无法判断业务可用性 |
| 容量预算 | 峰值并发、上下文长度、首 token 与总响应上限是多少 | 单人演示成功，团队上线后排队或内存溢出 |
| 许可与供应 | 权重许可、衍生模型许可、商用条款和版本来源是什么 | 技术验证完成后才发现不能按计划商用或再分发 |
| 运营责任 | 谁负责镜像、模型、量化、监控、回归、升级和回滚 | 故障后无法判断是模型、运行时、数据还是应用问题 |
数据边界还应再拆一层。某些项目要求原始数据不出厂区，但允许匿名指标进入云端；某些项目只禁止长期留存，却允许受控 API 推理；另一些项目必须在断网时继续工作。三种边界对应“纯本地”“本地优先 + 云端降级”和“云端优先 + 敏感任务本地”三种架构，不应被统一写成“私有化”。
任务合同也不能只写“做知识库”。应写成可测条件，例如：回答必须给出文档片段；没有证据时必须拒答；JSON 字段必须通过 schema；设备建议不得直接进入控制闭环；超时后返回规则结果或转人工。模型只有在这个合同里才能被比较。
3. 用容量带缩小候选集，而不是猜显存
以 Apple M1、16 GB 统一内存的机器为容量估算示例：预留 4 GB 给系统和应用后，把 12 GB 作为规划预算。按 Q4 权重约 0.5 byte/parameter，再加 25% 规划余量，估算公式为 参数量 × 0.5 × 1.25 ÷ 1024³，结果单位为 GiB。8B 约为 4.66 GiB，14B 约为 8.15 GiB；32B 约为 18.63 GiB，70B 约为 40.75 GiB，后两者已超过这台机器的规划预算。
这不是吞吐 benchmark。估算没有包含 KV cache、并发、上下文增长、运行时碎片和具体架构，也不是模型实测。因此，正确结论只是：在这个 16 GB 单机预算下，32B 和 70B 不应进入首轮候选；3B、4B、8B 和部分 14B 仍需通过真实运行测试决定。 读者可用上述公式替换参数量进行初筛，再记录实际运行时的峰值内存与响应时间。
可将项目先分成三条容量带：
| 容量带 | 典型候选 | 更适合的任务 | 首轮验证重点 |
|---|---|---|---|
| 端侧 / 小型边缘 | 0.5B–4B，量化版本 | 分类、抽取、短摘要、受控工具路由、离线辅助 | 功耗、包体、冷启动、离线稳定性 |
| 工作站 / 单机服务 | 7B–14B，量化或低精度 | 内部助手、RAG、代码辅助、低并发多模态 | 长上下文内存、并发排队、首 token 延迟 |
| GPU 服务器 / 集群 | 30B 以上或大 MoE | 高质量推理、复杂代码、多团队共享 | GPU 拓扑、吞吐、弹性、成本和故障域 |
MoE 还会制造一个常见误解：每 token 激活参数较少，不代表完整权重可以忽略。模型下载、加载、跨卡通信和运行时仍受总参数与实现方式影响。容量规划必须以实际 checkpoint、量化格式、上下文和推理后端为准。
4. 候选模型家族要按任务分组
2026 年的合理候选集不应是一张永久排名，而应是一组可替换的模型家族。官方资料显示，Qwen3 提供从小型 dense 到 MoE 的多种规格，并给出 Ollama、llama.cpp、vLLM 与 SGLang 等本地或服务化路径；Gemma 3 覆盖小型文本到 4B、12B、27B 多模态规格；Mistral 3 的 Ministral 系列提供 3B、8B、14B 的端侧与本地候选；Phi-4-mini 面向紧凑型与边缘任务；DeepSeek-R1 提供基于 Qwen、Llama 的蒸馏版本；Llama 则有自己的许可、权重获取和本地运行要求。
这些信息只能帮助建立候选集，不能替代企业测试。更实用的分组如下：
| 任务组 | 可进入试点的模型家族示例 | 先验证什么 | 不应直接推导什么 |
|---|---|---|---|
| 中文知识库与工具调用 | Qwen3 4B/8B/14B 等 | 引用、拒答、JSON、中文术语、工具参数 | 公开 benchmark 高就等于企业知识正确 |
| 轻量边缘与离线助手 | Gemma 3 小规格、Phi-4-mini、Ministral 3 3B/8B | 包体、功耗、冷启动、断网、输出约束 | “edge” 标签就等于能在任意 IoT 芯片运行 |
| 推理与复杂分析 | DeepSeek-R1 distill、Qwen thinking/reasoning 变体 | 推理时延、输出长度、可验证性、成本 | 思考更长就一定更可靠或更便宜 |
| 通用企业助手 | Llama、Qwen、Gemma、Mistral 的合适规格 | 多语言、RAG、工具、治理和许可证 | 一个模型可以同时优化全部部门任务 |
| 大规模服务 | 适配 vLLM/SGLang/TensorRT-LLM 的候选 | 批处理、并发、GPU 利用率、故障恢复 | 本地工作站结果能直接外推到集群 |
这里故意不列“第一名”。模型版本会变化，运行时支持会变化，许可证也可能分家族或衍生版本变化。可维护的决策资产应是任务合同、测试集和评分规则，而不是文章发布当天的排行榜。
5. 用加权矩阵评分，但先设置淘汰线
评分矩阵不能掩盖硬性失败。建议先设四条淘汰线：权重或许可不满足计划用途；真实峰值内存超过预算；关键任务通过率低于业务底线；敏感数据链路无法审计。任何一条失败都淘汰，不允许靠其他高分补回来。
剩余候选再使用加权评分。下面是一组适用于企业知识助手和 IoT 运维助手的起始权重，团队可按项目调整：
| 维度 | 权重 | 可复核测量 |
|---|---|---|
| 任务正确性与拒答 | 30% | 真实问题集通过率、无证据拒答、引用一致性 |
| 容量与延迟 | 20% | 峰值内存、p50/p95 首 token、总响应、并发 |
| 数据与安全边界 | 15% | 出域点、日志内容、身份、网络和存储控制 |
| 可运营性 | 15% | 指标、日志、追踪、版本、灰度和回滚 |
| 许可与供应稳定性 | 10% | 权重来源、许可证、镜像锁定、依赖维护状态 |
| 三年 TCO | 10% | 硬件、托管、电力、值守、升级和故障成本 |
评分时必须固定模型版本、量化、系统提示词、采样参数、上下文、检索结果和硬件。否则团队比较的不是模型，而是多组不同实验配置。最好隐藏模型名，让业务审核者只看答案、引用、格式和失败类型，减少品牌预期影响。
6. 成本模型要把闲置和运维算进去
本地部署并不天然便宜。云端成本多为调用量；本地成本则由硬件峰值容量、闲置、机房、电力、备件、网络、值守和升级共同构成。一个简单的三年 TCO 可以写成：
TCO = 服务器与加速卡 + 机房/电力 + 软件与支持 + 平台工程 + 模型评估与升级 + 故障与闲置成本
对低频任务，云端 API 可能更便宜，因为企业不必为峰值容量提前买设备。对稳定高频、数据严格出域、断网必须运行的任务，本地方案可能更合理。混合方案则可以让敏感与离线任务留在本地，把高难度、低频请求转向受控云端，但要同时设计数据分类和降级策略。
边缘项目还要增加设备生命周期成本。部署到数百台门店盒子或工业网关后，模型文件分发、断点续传、磁盘空间、回滚包、功耗与热管理会放大。小模型带来的价值不仅是“速度快”，还包括更容易分发、启动和回退。
7. 上线责任必须覆盖可观测、升级和回滚
生产模型至少需要三层版本：模型权重与量化版本、推理运行时与镜像版本、提示词/检索/工具配置版本。只记录“Qwen”或“Llama”无法重现问题。一次升级可能没有改变模型家族，却改变 tokenizer、chat template、量化、上下文或工具调用行为。
最低可观测集应包括：请求量、排队时间、首 token 与总响应延迟、输入输出 token、峰值内存或显存、超时、OOM、结构化输出失败、检索命中、引用缺失、拒答率和人工接管。高风险任务还要记录模型建议是否被规则或人员接受，但日志必须避免无控制存储敏感原文。
升级流程不应直接覆盖线上模型。先锁定旧版本和回归集，再让新旧模型在相同输入上运行；把质量、延迟、内存和失败类型一起比较；小流量灰度后再扩大。回滚条件应预先定义，例如 p95 延迟超过上限、结构化输出失败翻倍、关键问题通过率下降或 OOM 连续出现。回滚资产必须包含旧权重、旧镜像、旧配置和兼容的数据 schema。
8. 三类失败比成功演示更值得保留
第一类失败是榜单命中，任务失败。团队选择公开得分更高的推理模型，但内部工单需要稳定 JSON 和短响应；模型输出很长、延迟高、字段漂移，最终自动化链路无法使用。修复方向不是继续调 prompt，而是回到任务合同，可能选择更小的 instruct 模型。
第二类失败是单机成功，容量失败。工程师在空闲工作站上完成演示，部署到共享服务后，上下文、并发和 KV cache 叠加，出现排队和 OOM。修复需要真实峰值测试、并发控制、上下文上限与降级，不是引用“单卡可运行”。
第三类失败是本地运行，治理失败。模型和文档都在内网，但 API 无身份、日志保留完整提示词、RAG 越权返回其他部门资料。这里的问题不在模型，而在访问控制、数据分级和审计设计。把“本地”当安全结论会掩盖真正风险。
9. 哪些情况不该优先本地部署
如果业务调用量低、数据允许受控出域、团队没有模型平台运维能力，而任务又依赖最强通用推理或快速变化的多模态能力，优先采用受控云端服务通常更合理。若需求还没有稳定，先购买 GPU 集群会把探索问题变成沉没成本。
如果任务属于硬实时控制、安全联锁或高风险自动决策，LLM 无论本地还是云端都不应直接成为最终控制器。它可以生成解释、摘要或候选操作，但最终动作应由确定性规则、状态机、权限和人工确认约束。
如果许可证、权重来源、依赖镜像或安全更新无法持续维护，也不应因为“开源”两个字进入生产。开放权重降低了部署门槛，不自动提供供应链、漏洞响应和生命周期承诺。
10. 一次有效试点应该留下什么
一次两到四周的试点至少应留下：版本锁定的候选清单；企业真实且脱敏的测试集；通过、失败、拒答和人工复核定义；固定硬件与参数；内存、延迟、并发和错误结果；许可证核对；日志与访问控制设计；三年 TCO 假设；升级与回滚演练结果。
只有“安装成功截图”和几段聊天记录，不足以支撑采购或上线。相反，即使最终没有选择本地模型，只要试点明确了数据边界、容量上限和失败类型，它仍然形成了可复用的决策资产。
11. 给项目负责人的决策结论
企业本地 AI 模型选型应采用两阶段法：先用数据、许可、容量和运营责任淘汰不成立的方案，再让剩余候选在同一业务合同下做盲测与 TCO 比较。3B、8B、14B、32B 只是容量入口，不是质量结论；Qwen、Gemma、Mistral、Phi、DeepSeek 和 Llama 只是候选家族，不是永久排名。
如果团队还没有任务合同和回归集，先不要争论模型品牌；如果没有真实峰值容量测试，不要把“能运行”写成“可生产”；如果没有升级回滚和访问控制，不要把“本地”写成“安全”。需要从 PoC 进入受控生产时，可结合本地大模型私有化部署服务和Ollama 企业适用场景与边界进一步设计运行时、网关、监控与治理路径。
参考资料与证据边界
- Qwen3 official repository: https://github.com/QwenLM/Qwen3
- Google Gemma 3 model card: https://ai.google.dev/gemma/docs/core/model_card_3
- Mistral 3 official announcement: https://mistral.ai/news/mistral-3/
- Microsoft Phi-4 mini announcement: https://techcommunity.microsoft.com/blog/educatordeveloperblog/welcome-to-the-new-phi-4-models—microsoft-phi-4-mini–phi-4-multimodal/4386037
- DeepSeek-R1 official repository and license: https://github.com/deepseek-ai/DeepSeek-R1
- Meta Llama models repository: https://github.com/meta-llama/llama-models
- Ollama model library: https://ollama.com/library
- 容量估算方法见第 3 节；它是公开计算示例，不是模型性能测试报告。
本文没有运行上述模型，不提供 tokens/s 或质量排名。厂商公开 benchmark 仅用于识别候选能力与部署形态，最终选择必须由企业自己的数据、硬件、参数和验收合同决定。
