企业官网建设流程全解析

上周有个做企业信息化的朋友问我：大模型到底能不能部署在内网？他们公司硬件只有一台老旧的GPU服务器，还不想把业务数据送出去。这个问题我太熟悉了，过去半年我们项目组一直在折腾同一件事——把智能交互放到客户本地，让数据出不了域，让模型跑得起来。最终交付的版本，就是龙呤AI 1.5，一个本地轻量化智能交互系统，底层由OCT（Ontology Cognition Tree，本体认知树）+ DSS（Decision Support Service，决策支持服务）+ ODP（Offline Deployment Pipeline，离线部署管线）三个核心模块组成。整套东西的定位很明确：私有化AI，轻量落地，能内网跑，能持续迭代。

这篇文章我会把从架构选型到压测调参的完整过程都写下来，包括每个模块为什么要这么设计、本地部署到底需要什么样的硬件底线、以及我们踩过的坑。如果你也在做企业私有化AI，尤其是资源有限、数据敏感的环境，这篇复盘可以直接参考。

1. 私有化部署的真实困境：不是不想用AI，是AI太“重”了

1.1 云端方案的算账逻辑，算到最后都不划算

先说个现象。很多企业一开始考虑AI，第一反应是接入云端大模型API。注册账号、拿Key、调接口，看起来很快。但真放到生产环境里，问题就一个个冒出来。

第一个问题是数据出域。业务对话里全是客户信息、内部流程、项目数据，发送到云端就意味着这些数据要去别人的服务器上溜一圈。安全部门大概率直接否决。第二个问题更实际——钱。API按token计费，看起来单次不贵，但多轮对话、知识库检索、固定任务调用，一个月几千上万次请求，月账单很快就能压到项目预算的临界点。我见过一个客户，他们一个月光是在AI功能上的API费用就到了六位数，这还只是用量，还没算开发联调的人力成本。

第三个问题是被忽略的：网络。工厂、医院、政务内网，很多环境是物理隔离的，压根连不上外网。API模式天然就没法用。

所以私有化AI不是锦上添花，是这些场景的刚需。龙呤AI 1.5从立项开始就没把“接入云端大模型”放进选项清单，目标只有一条——让模型+交互+知识库整套系统，完整地跑在客户自己的机器上。

1.2 “轻量化”的边界到底画在哪里

私有化一个模型，听起来简单，但这几年“私有化”这三个字被概念化得厉害。最典型的方案是直接搬开源大模型，70B以上的参数要跑得动，显存至少百G级别，得配多张A100或H100。普通企业哪有这种硬件。我们在客户现场见得最多的，是单张RTX 3090/4090，甚至是只有CPU没有GPU的老服务器。

龙呤AI 1.5把部署基线定得比较激进：单张12GB显存GPU可跑，16GB内存可跑，纯CPU也能通过INT8量化做基础问答。这不是拍脑袋定的，是我们跑了三轮压测后画出来的底线。

现在很多方案一开口就是“7B做不了复杂任务”，这话对也错。7B在通用闲聊上确实不如大模型，但在企业垂直场景里，配合知识库和决策链路，完全够用。后面我会详细说我们怎么让一套7B模型在一个受限环境里稳定工作的。

2. OCT+DSS+ODP的架构链路：把“会聊天”变成“能干活”

2.1 OCT：本体认知树，多轮对话不再靠“截断”

先聊OCT。全称是Ontology Cognition Tree，本体认知树。这个模块要解决的是智能交互系统最头疼的问题——多轮对话的记忆与理解。

很多人在做本地对话系统时有个误区：把所有历史消息全部塞进上下文窗口。一次会话聊了20轮，就一股脑把20轮内容都喂给模型。这种做法有两个严重问题。第一，上下文窗口有限，聊长了直接爆掉，只能截断，一截断前面的关键信息就丢了。第二，就算没爆掉，塞太多无关信息会严重干扰模型注意力，答非所问的概率大幅上升。

OCT的思路是把对话记忆“结构化”，而不是“堆叠”起来。每一次多轮对话，系统会实时抽取出三类信息：

• 实体节点：人、设备、项目、地点、时间等关键对象
• 关系节点：实体之间的关联，例如“张三负责A设备”“B项目在C厂区”
• 状态节点：当前任务的完成度，例如“已确认故障类型，待确认维修方案”

所有节点构成一棵不断生长的树。新来一句话，系统先在这棵树上找挂载点，判断它是在补充哪个实体、更新哪个状态，还是新建一个分支。这样模型每次真正拿到的不是“全部历史”，而是“跟当前问题相关的子图”。

我举个例子。客户在咨询里先后说了“我们工厂有两条产线”“第一条产线最近老出故障”“故障主要集中在上料环节”。传统做法是把这三句话原样存进上下文，第二次提问“上料环节故障率多少”时，模型要从大段历史里自行找线索。而OCT的做法是直接维护一个“产线A——上料——高故障率”的认知分支，模型无论何时问“上料环节”，都能立刻从这个分支拿到答案。实测下来，超过20轮的复杂会话，传统上下文的答非所问率能到30%以上，而OCT把这个数字压到了6%以内。

2.2 DSS：决策支持服务，一句话先过三道闸

第二个模块是DSS，Decision Support Service，决策支持服务。这个模块是我们团队内部最坚持的一层，也是市面上很多“私有化AI”完全没做的一层。

大模型本身是个“生成器”，你问什么它都会往外蹦句子，但企业场景要求的是“确定性”——该查资料就查资料，该算数字就算数字，该拒绝就拒绝，不能什么都靠模型自由发挥。DSS就是在这条链路上做控制的：

第一道闸，意图判别。把用户输入分为四类：闲聊类、知识问答类、任务执行类、敏感越权类。每一类走完全不同的处理管道。知识问答类强制走RAG检索，任务执行类强制走工具调用，越权敏感类直接拦截。这里我们不依赖模型做判断，而是用一个轻量分类模型+规则模板的双通道方案，分类速率控制在毫秒级，并且给每个意图输出一个置信度分数，低于0.72的输入一律进入“人工重试”流程，不让模型硬答。

第二道闸，工具路由。判定为任务执行类之后，DSS要决定调哪个内部工具：查数据库、生成报表、修改工单、还是调用外部API。每个工具都预先定义了参数模板和权限等级。以“查一下上季度设备故障率”为例，DSS先从OCT节点里取出“设备=上料机”，再从业务系统映射表里定位数据源，最后生成结构化查询指令，整个路由过程不需要大模型介入。

第三道闸，答案置信校验。模型生成答案后不直接返回，先过一遍校验器。校验器会把模型答案和检索结果做比对，如果关键数字或实体不一致，会触发二次生成，或者直接返回“暂时无法确认，请稍后再试”。这一步很关键，我们用这道闸把幻觉率从裸模型的6%级别压到了1.8%级别，后面压测部分会详细展开。

DSS本质上是给模型套了一层“企业级刹车”，它让AI在私有化环境里不止能“聊天”，还能“干活”，并且干错活的概率是可控的。

2.3 ODP：离线部署管线，升级和回滚不再提心吊胆

第三个模块ODP，Offline Deployment Pipeline，离线部署管线。私有化环境的运维和云端完全是两个画风。云端更新模型，后台切个镜像就行，私有化环境很多客户现场没有专门的运维工程师，更新系统全靠我们远程指导，一旦出问题可能整个系统瘫在那里。

龙呤AI 1.5的ODP模块把整个升级过程做成了“流水线式”的本地操作：

• 模型版本管理：基座模型、量化模型、微调模型都打上版本标签，多版本并存，不覆盖。
• 热加载与灰度切换：新模型加载完成后，先跑一组内置烟囱测试，给10%的会话流量试用，确认无异常再全量切换。
• 一键回滚：保留上一个可用版本的全部文件和配置，只要在管理后台点一下“回滚”，整个系统在5分钟内恢复到上一版本。

这套机制在我们交付的某个工厂客户那里实战验证过。上线一个新版量化模型后，发现它在特定方言识别上不如旧版，现场运维在管理后台直接回滚，整个过程没中断任何会话，客户甚至没察觉到发生了变更。

ODP的价值不在于技术难度，而在于“把私有化部署的运维门槛降到了普通人能操作的水平”。没有这一层，龙呤AI 1.5就不敢称为完整的“解决方案”，只能算个模型壳子。

2.4 三者协作的一次完整链路拆解

说了三个模块各自的职责，串一遍完整链路。

用户输入“帮我查一下第一产线上料环节的故障率，并生成一份摘要”。

• 第一步，输入进入DSS意图判别，判定为“任务执行类”，置信度0.85。
• 第二步，OCT从知识树里检索“第一产线”“上料环节”，定位到对应的设备实体和故障状态节点。
• 第三步，DSS工具路由层根据检索结果，匹配到“设备故障率查询”工具，生成结构化查询指令，到业务数据库执行SQL。
• 第四步，查询结果转成限定上下文，喂给基座模型，限定其只根据查询结果生成摘要，不自由发挥。
• 第五步，生成的摘要经过DSS答案校验器，核对“上料设备”“故障率数值”是否与原数据一致，确认通过后推送到前端。
• 第六步，ODP记录整个链路的日志，包括模型版本、工具调用记录、返回内容摘要，作为后续审计依据。

你会发现，模型在整个流程里只承担了“摘要生成”一个相对简单的角色，真正控制流程、保证精度的是OCT和DSS。这也是我坚持的一个观点，在私有化AI里，架构的价值远大于模型参数的价值。

3. 1.5版本本地落地的工程细节：从模型选型到流式输出

3.1 基座模型与量化路径，怎么选最适配“本地轻量化”

龙呤AI 1.5的基座模型选型经历了好几轮徘徊。最开始我们试过13B模型，效果确实好，但部署要求高，单张12GB显卡跑不了FP16，只能INT8量化，量化后效果衰减让我不太满意。后来转战7B系列，在效果与资源之间找到了平衡点。

选型原则其实很朴素：

• 效果优先看垂直能力：企业场景最看重的是指令遵循能力、结构化输出能力、多轮稳定性，而不是广谱知识量。
• 量化路径要预留余量：我最终采用的是“FP16全精度+INT8动态量化”双轨方案。默认7B模型以FP16精度运行，显存不够时自动切到INT8。比如12GB显存的环境，FP16大概吃9GB左右，切到INT8能降到5GB，给向量检索和上下文缓存留出空间。
• 舍不得裁剪的“尾巴”：输出层始终保持FP16精度。之前踩过一次坑，为了省显存把输出层也量化了，结果是文本生成的流畅度肉眼可见地下降，后来这部分坚决保留FP16。

7B模型在一张消费级显卡上，单token生成速度大约在38-45之间，这个速度对于交互式问答完全够用。

3.2 上下文窗口管理：三层状态与Token预算

前面提到OCT负责结构化的“知识树”，但模型实际生成时还是需要上下文。龙呤AI 1.5把上下文按功能切成三层，每一层有独立的Token预算：

三层预算总计不超过9344 token，塞进8K窗口刚好留有余量。这个设计解决了一个很实际的问题——企业用户聊着聊着忽然岔开问另一个问题，传统上下文机制会把前面聊的东西全丢了，但三层结构里“工作记忆层”始终保留了当前任务的骨架，岔开的问题走OCT分支继续，过一阵还能绕回来接着聊。

给个小技巧：短期记忆层最好按“最近8轮”做滑动窗口，而不是按内容长度做。用户平均对话轮次短且密集，8轮正好覆盖一个典型任务的推进过程，再多就是噪音。

3.3 流式响应与首字延迟的优化

本地部署还有一个体验维度经常被忽略——首字延迟（TTFT）。云端大模型基本都有专用加速，可以做到几百毫秒出第一个字，本地环境没有这种条件，优化全靠自己。

我们做了三件事：

• 减少预填充长度：每次生成前，只把当前轮问题和OCT相关子图喂进模型，不把整个三层上下文全部预填充。预填充短了，计算量小了，TTFT自然降下来。
• SSE流式推送，每50毫秒一flus：前端用Server-Sent Events接收token，客户端每50ms渲染一次，而不是攒一整个句子。实测下来即便单token生成只有40出头，用户体感也接近“打字机式流畅”。
• 缓存KV Cache：把高频查询的KV Cache做本地缓存，比如“产线A的基本信息”“设备B的参数表”。这个缓存命中一次，TTFT能直接压到0.3秒以内。

优化后的实测数据：单会话TTFT约0.4秒，生成速度约38 tokens/s，体验接近云端轻量模型。

3.4 私有化环境里的向量检索与知识库对接

企业私有化部署通常要对接大量内部资料：产品手册、故障案例、SOP文档、历史工单等。龙呤AI 1.5自带一个轻量级向量检索模块，针对PDF、Word、TXT、Markdown四种格式做文档解析。

处理链路是：文档切块（按段落和标题层级，块大小控制在256-512字）→ Embedding嵌入 → 本地向量库存储 → 查询时Top-K召回，K值默认5，召回段落按相似度从高到低排列。这部分我踩过的坑是文档切块切太随意会严重降低检索精度。按固定字符切，比如每512字一刀切，会把语义完整的段落拦腰截断；我们的做法是先识别文档标题层级，再按“标题+段落”的结构化方式切块，语义完整度会好很多。

一个值得注意的参数：K值不是越大越好。在私有化知识库里，K=5召回精度最高，K调到10之后噪声明显增加，模型答案里开始混入无关段落里的词汇。如果算力允许，可以在召回后加一层轻量重排模型，但我们为了控制部署体积没有上，靠DSS的答案校验闸也能兜住大部分问题。

4. 压测复盘：并发、延迟、幻觉率与关键超参

4.1 测试环境与基准数据

先交代测试环境。我们在一台客户退下来的旧服务器上做了完整压测：

• CPU：双路Xeon Silver 4210（20核40线程）
• 内存：128GB DDR4
• GPU：单张RTX 3090（24GB显存）
• 存储：NVMe SSD，用于向量库和模型文件
• 操作系统：Ubuntu 20.04 + CUDA 11.8

压测工具是自己写的Python asyncio并发脚本，模拟30路用户同时发起混合会话（知识问答、任务查询、多轮追问各占三分之一）。每路会话持续30分钟，关注三个指标：首字延迟、完整回复时长、成功率。

4.2 并发与显存实测

这个数据可以说非常符合预期。20路以内是这台配置的舒适区，30路明显开始排队，但成功率掉到91.5%，主要原因是KV Cache暴涨导致显存接近上限，触发了部分请求的OOM。后来我们把最大并发上限默认改为20，并在超过15路时对“重度推理任务”自动降级为“轻量摘要模式”，成功率重新拉到了99%以上。

给个参考结论：单张24GB显卡的7B私有化系统，日常交互控制在15-20路并发是安全的，再往上就得考虑多卡或排队策略了。

4.3 幻觉控制：为什么裸跑7B会失控

这轮压测里我最关注的其实是幻觉率。我们设计了一套基准测试集：500条知识问答，全部来自企业文档，每条都有标准答案。

裸跑7B模型（只喂文档上下文、不经过DSS校验）的幻觉率是6.2%，这个数字在企业场景是致命的——每100条回答里有6条是“看似合理但数据错误”的，没人敢用。问题出在哪里？模型有很强的“补全倾向”，遇到不确定的区域会用语言习惯把话圆过去，而不是承认不知道。

加上DSS三层校验后，幻觉率降到了1.8%。核心策略有三个：

• 知识类问题强制走RAG，且要求“检索不到就不答”：当召回结果的最高相似度低于阈值0.55时，系统直接返回“暂未检索到可依据资料”，不让模型编。
• 数字与实体一致性验证：模型生成的答案里如果出现数字或设备名，必须能和检索结果里的对应内容匹配，匹配不上就二次生成或拒答。
• 置信度0.62以下的提交人工兜底：企业场景里宁可不给结论，也不能给错结论。这个阈值我们在客户现场调研过，最终定为0.62。

因为加了这道“宁缺毋滥”的规则，系统偶尔会答不上来，但答上来的内容可信度大幅提升。你要知道，在企业私有化AI的交付里，可信度比覆盖率重要得多。

4.4 关键超参：温度、重复惩罚与路由阈值的最终取值

压测调参阶段我们走了不少弯路，这里直接给最终验证过的参数和依据：

• temperature = 0.6：低于0.4时答案太“干”，表达生硬；高于0.85时发散严重，开始出现幻觉。0.6是任务型交互和自然表达之间的平衡点。
• top_p = 0.9：与temperature配合使用，给生成留一点多样性，但限制在可控范围。
• repetition_penalty = 1.05：很重要！本地化模型对重复循环很敏感，1.05能压住80%的重复段。之前用默认值1.0，长文本里经常出现“然后然后然后”之类的情况。
• DSS路由阈值 = 0.72：意图分类的动作阈值。调成0.8时太多输入没能通过路由，用户感觉系统“拒答率太高”；调成0.65后误判率上升，一些明显是闲聊的输入被送进了任务执行管道。0.72是召回率和精度的交叉点。
• 检索触发阈值 = 0.55：召回相似度最低线，0.55以下不进上下文。

还有一个细节：任务执行类的回答，温度可以临时降到0.4，因为这类回答要求精确，不能发散。我们做了一套“温度随意图动态调整”的规则，不在系统里用单一温度值，实测对任务完成度有明显帮助。

5. 写在最后：几个必须亲手踩过才相信的经验

关于龙呤AI 1.5，最后聊几点我觉得其他项目也能直接复用的体会。

第一，私有化AI最容易被“模型参数迷思”带偏。一开始我们也是盯着模型排行榜选基座，后来发现企业客户根本不在乎模型知识面多广，只在乎三步之内能不能答对事。把重心从模型选型转移到“控制链路设计”上之后，交付质量才真正稳定下来。识别层（OCT）做重、推理层（DSS）做重、生成层做轻——这套思路用在哪类私有化项目都不会错。

第二，上下文管理一定要提前做预算。不要等高并发场景压进来，再去临时砍上下文长度，那种做法只会让模型答得更差。龙呤AI 1.5的三层预算模式是我们在项目中途重新设计的，改一次的成本远高于一开始就设计好。

第三，离线部署必须把“回滚”当第一功能来做，而不是最后补丁。云端出问题可以马上改，私有化环境出了问题可能就是客户现场停摆，压力完全不同。ODP的一键回滚在客户那边救了我们一次，也让客户对系统建立起了信任。

如果你正好也在考虑私有化AI方案，或者已经踩在“大模型部署不下去”的坑里，这套架构和数据可以直接拿去做参考。硬件不够、数据敏感、又要保证交互质量，龙呤AI 1.5这个方向，是值得走通的一条路。