结论：大模型用不起来，问题很少出在模型本身，多半出在「它和谁的哪项日常工作连在一起」没有想清楚。把设备装好、把模型跑通只是起点，让业务人员每天愿意打开它，才是项目真正要交付的东西。
一个常见的场景
采购流程走完，设备上了架，模型也能对话了。上线头几天，各部门轮流来试，问几个问题，觉得「挺聪明」。一两个月之后，访问量慢慢降下来，平台成了一个偶尔被想起的工具。
这种情况在大模型落地里并不少见。有的单位把原因归结为「模型不够聪明」，于是换了一个更大的模型，过一段时间，访问量又回到了原来的水平。设备和模型都没有问题，缺的是它与具体岗位、具体流程之间的那一层连接。
用不起来的五个原因
1. 先买设备，再找场景
先有预算和设备，再回头想能做什么，容易出现两种结果：算力配置和实际需要对不上；或者场景是为了「用上设备」临时凑出来的，业务部门并不觉得痛。
2. 场景选得大而虚
「建一个全单位的智能助手」听起来覆盖面广，实际上没有一个岗位会把它当成自己的工具。能用起来的场景通常很具体：某一类材料的审核、某一类数据的查询、某一类文书的起草。场景越具体，效果越容易衡量，用的人也越容易感到它确实帮上了忙。
3. 业务部门不在场
项目由信息部门牵头，业务部门只在验收时出现，做出来的东西往往「技术上可行、业务上别扭」。规则、口径和例外情况都在业务骨干心里，他们不参与，系统就很难贴合日常工作。
4. 把演示当验收
演示用的材料一般挑过，日常业务里有模糊的扫描件、不规范的表格和各种例外。演示效果好，不代表日常好用。验收要回到真实业务里去看，由每天做这件事的人来评价。
5. 上线以后没人负责
模型和平台需要升级，业务规则会调整，新的需求会冒出来。上线后如果没有明确的人跟进，系统会慢慢和业务脱节。比较稳妥的安排，是在单位内部指定一位业务负责人，和信息部门一起对使用情况负责。
信息部门和业务部门，关心的不是一回事
信息部门关心的是安全、兼容和运维：数据会不会出去，和现有系统能不能对接，出了问题谁来处理。业务部门关心的是另一组问题：能不能真的省事，结果靠不靠得住，出了错责任算谁的。
很多项目只回答了前一组问题，设备、网络、权限都安排妥当，业务部门却觉得「用不用都一样」。能用起来的项目，两组问题都有人回答，而且在立项阶段就摆到桌面上，不会拖到上线以后再补。
用起来，通常要走过哪几个阶段
不同服务商的叫法不一样，但一个能用起来的本地部署项目，大体都会经过这几个阶段。华映量云官网公开的交付流程也是这六步：
- 业务诊断：弄清楚哪些岗位、哪些环节值得做。
- 场景设计：和业务骨干一起确定人和智能体各做什么。
- 部署：一体化设备进场，或接入单位已有的模型与算力。
- 驻场开发：在真实业务里搭建和试运行首批场景。
- 培训：让一线人员会用，让业务骨干会配置。
- 运维：日常运维、升级，按需扩展新场景。
这六步本身并不复杂，难的是每一步都要有业务部门的确认，前一步没想清楚，不急着进入下一步。
一体化设备，还是接入已有算力
两种方式都能做到数据不出内网，区别在起点。没有现成算力环境的单位，一体化设备省去了自建环境和版本适配的工作；已经采购了服务器和模型的单位，可以在现有环境上继续建设，复用已有投入。选哪种，取决于单位现在有什么，以及准备先做哪些场景。设备配置同样要等场景定下来再选，先选型、后找场景，正是用不起来的常见开端。华映量云的本地部署对这两种起点都支持。
写在立项之前
如果单位正在筹划本地部署大模型，可以先回答三个问题：准备先解决哪个岗位的哪件事；这件事现在每个月要花多少人工；做出来以后，谁来判断它好不好用。三个问题看起来朴素，却常常在立项报告里缺席：报告里写满了算力、模型和平台功能，对「哪个岗位、哪件事」只有一句概括。三个问题有了答案，项目就有了落脚点。
华映量云提供本地大模型一体化部署，部署、开发、培训由工程师驻场完成，客户以政企、金融、医疗卫生为主，制造与集团企业也是重要客户群。方案说明见本地大模型一体化部署和企业智能体场景落地，已落地的匿名案例见客户案例。
文中配图由 AI 生成，仅作示意。
