今年上半年我把一套本地部署的AI系统从1.0版本重构到了1.5版本也就是后来被团队内部叫做“龙呤AI 1.5”的那套东西。动机其实非常朴素公司业务数据不能直接发给在线大模型但大家又都想要一个能随叫随到、能翻知识库、能帮写材料的助手。当时市面上的本地AI方案要么太重要么只是把模型跑起来就完事缺少和业务系统、知识库的联动。后来我基于OCTDSSODP这套自研分层架构把整个系统重写了一遍跑在一台消费级显卡的机器上完成了从“能对话”到“能用、好用、敢用”的转变。这篇内容就是这次重构过程的完整复盘包括架构拆解、模型选型、部署流程和踩坑记录希望能给同样在做私有化AI落地的朋友一些参考。1. 为什么要做私有化AI数据不出内网这件事比省钱重要得多1.1 从一次数据合规风险说起上云还是本地部署这不是一道技术题而是一道数据题。我们公司有大量客户合同、财务明细、产品配方和内部流程文档这些内容如果直接粘贴到在线大模型对话框里等于把核心资产交到了别人手里。很多同行可能觉得“就测试一下应该没事”但真到合规审计或者数据泄漏的那一天代价绝对不会小。我亲历过一次内部审查业务同事用在线AI工具整理经销商的合同材料结果把客户名称和分成比例带进了提示词之后这条对话记录被第三方的日志系统留存。虽然最终没有造成实质性损失但审计报告上白纸黑字写着“存在敏感数据外传风险”。从那以后公司对AI工具的采购和选型多了一条硬性红线核心数据不允许出内网。这就是私有化部署最根本的价值所在——模型、数据、推理记录全部留在自己的服务器上从源头上规避外传风险。很多人一听到“私有化AI”第一反应是“那得花多少钱、配多大集群”实际上轻量化本地系统并不需要那么贵一台配置稍像样的工作站就可以起步。1.2 轻量化定位不追求最强追求够用在选择方案时我给自己定的目标是单机部署、离线可用、支持知识库问答、支持接入内部业务系统、普通人也能维护。说白了我要的不是一个能PK顶级大模型的系统而是一个够用的“团队AI助理”。这个定位决定了整套系统的技术路线不追求千亿参数大模型而是选择7B量级的开源模型做量化部署不依赖外部API做Embedding全部使用本地推理不搞复杂的分布式框架所有模块跑在同一台机器上用进程和Docker容器做隔离。做完之后回头看这个“够用”的定位非常关键。它让整个团队在成本、效率和效果之间找到了一个平衡点也让我可以在后续迭代中放心大胆地调整架构而不用时时盯着硬件成本。1.3 龙呤AI从1.0到1.5的演进初版龙呤AI 1.0其实只是个“聊天壳子”把模型部署到服务器上写了个简单的Web对话框。刚开始大家还挺新鲜但用了几天就发现问题问它内部报销流程它回答得模棱两可问它“上月华东区销售为什么下滑”它根本不知道华东区数据在哪个表里问完第二句它连第一句聊过什么都忘了。问题的根源在于1.0版本只有“模型提示词”没有知识库、没有业务系统的数据通路、没有对话状态的精细管理。于是1.5版本的重构目标就变成了增加一个专门负责数据接入和语义检索的模块增加一个负责编排对话流程的模块再把模型推理单独隔离出来。这就是OCTDSSODP架构的来源。2. 龙呤AI 1.5的架构拆解OCT、DSS、ODP各管什么2.1 项目内部的三个缩写别急着去外面搜标准定义先说清楚OCT、DSS、ODP这三个缩写是龙呤AI项目组自己的叫法不是某个行业惯用标准所以网上搜不到完全一致的定义。当时定这套命名是为了内部沟通时能准确地说清问题出在哪一层而不是笼统地来一句“AI那边坏了”。这也是我推荐其他团队做私有化AI时采用的做法——架构层的命名必须服务于故障定位和责任边界。三层架构的具体含义如下层级缩写全称核心职责类比上层OCTOrchestration Context Transformation对话编排、意图识别、上下文管理、工具调用规划大脑额叶做决策规划中层DSSDomain Service Semantic Store知识库接入、向量化、混合检索、业务系统API封装档案管理员加接线员底层ODPOn-Device Pipeline本地模型加载、推理调度、量化加速、输出解析执行肌肉负责具体干活OCT层负责“想清楚要做什么”DSS层负责“把需要的信息找到”ODP层负责“把问题算明白”。这样的分工让我能在排障时快速定位如果回答内容空泛问题多半在DSS的检索质量如果回答速度慢问题在ODP的推理管线如果答非所问问题在OCT的意图判断。2.2 一次请求的完整旅程从“销售为什么下滑”说起用一个实际业务问题来串一遍流程市场部同事问“本月华东区销售为什么下滑”。请求到达OCT层后OCT先把这句话拆解成两个子任务第一去销售数据库查询华东区的月度数据和去年同期数据第二检索公司内部关于华东区销售策略调整的文档。OCT通过内置的意图识别规则判断出这属于“数据查询知识检索”的复合请求于是把它转换成结构化的任务清单。接着DSS层开始干活。它一边通过封装的数据库查询接口拉取销售明细计算环比和同比变化一边把“华东区销售下滑原因”文本做过Embedding去知识库向量索引里召回相关文档。两个来源的结果都准备好后DSS层把结构化数据格式化成一个临时数据表格把文档段落也打包好一起交回给OCT。OCT层把数据结果和检索文档组装成一个上下文包连同系统提示词一起发给ODP层的本地推理引擎。ODP层的量化大模型基于这个上下文包生成一段解释“华东区本月销售额环比下降12%主要原因是核心经销商B类渠道调整……”最后回复文本传回OCTOCT再做一次格式整理和敏感信息检查返回到用户的对话框。整套流程跑下来大约需要30秒其中模型推理占了大头。用户感受是“这个AI居然真的能查数据库、能看文档、能把结论说清楚”。2.3 这个分层方式带来的三个好处第一个好处是模块可替换。我最初用的Embedding模型效果不好只需要替换DSS层的一个组件OCT和ODP完全不动。后来要把7B模型换成13B模型也只需要改ODP层的配置上层代码一行不用改。第二个好处是并发控制能力。没有分层时请求直接打到模型上多人同时使用只能听天由命。分层之后ODP层可以设置推理队列OCT层可以设置会话级互斥DSS层可以做检索结果的缓存。每一层都能独立调优。第三个好处是可观测性。每一层都记录结构化日志问题出现时能直接搜索“哪一层花了多少时间、返回了什么结果”。之前1.0版本遇到的“模型知识很丰富但回答用不上”这类问题就是因为少了DSS的存在。分层之后这种灰色地带被彻底消灭了。3. 模型选型与机器配置7B量化怎么在消费级显卡上跑起来3.1 先定边界单机、8GB显存、24小时待命部署之前我把硬件边界定得很明确不用多卡服务器不使用云GPU仅使用一台普通的深度学习工作站配备一块RTX 4060 Laptop 8GB显卡之后测试过RTX 4070 Ti SUPER 16GB版本内存32GB系统盘1TB SSD。8GB显存听起来不大但做私有化轻量部署其实是够用的。关键是别想着把大模型全家桶都塞进去要有取舍。目标模型大小锁定在7B这个量级量化方式采用INT4推理引擎选择了兼容性好、安装方便的Ollama。3.2 模型与引擎选型模型选型上我最终在Qwen2.5-7B-Instruct和Llama 3.1 8B之间做了测试。中文场景下Qwen系列的输出质量和指令遵循能力明显更好特别是在回答财务制度和内部流程类问题时更贴近中文表达习惯。和很多小团队交流下来用Qwen系列做中文私有化部署是目前公认的高性价比选择。嵌入模型选用bge-m3。这个模型的中文语义理解能力不错而且支持8192长度的输入对处理长文档非常友好。向量数据库没有用Milvus这类重型分布式方案而是选了轻量的Chroma单机场景完全够用。推理引擎当时在Ollama和llama.cpp之间犹豫过。llama.cpp的性能确实更强但编译配置对普通维护人员不友好。Ollama胜在安装简单、模型管理方便还有现成的API接口配合Python后端开发效率极高。为了减少团队维护成本我选了Ollama。3.3 显存估算与实测数据这里给一个非常保守但好用的显存估算公式模型文件大小加上约2GB的KV Cache和运行时开销再留出30%的余量。以Qwen2.5-7B的INT4量化版本为例GGUF Q4_K_M文件体积约4.6GB加上运行时开销后8GB显卡可以稳定运行最高同时推理并发建议不超过1。实测数据如下环境RTX 4060 Laptop32GB内存Ollama作为推理引擎模型使用Qwen2.5-7B-Instruct Q4_K_M指标数值备注平均首Token延迟0.4秒 - 0.8秒受输入提示词长度影响平均生成速度18 tokens/s上下文长度设8192峰值显存占用6.8GB上下文满负荷时实际内存占用12GB模型和上下文碎片单日稳定运行时间连续72小时未出现OOM崩溃这套配置下的回答质量应付日常内部知识问答、制度解读和写作辅助完全没有问题。当然如果你想要更强的代码能力推荐换Qwen2.5-Coder-7B如果任务非常垂直也可以考虑用13B模型在16GB显卡上跑但生成速度会下降到10-12 tokens/s需要有取舍。3.4 几个直接影响体验的参数第一是temperature我调到了0.3左右。太低0.1以下会让回答变得机械、不断重复模板太高0.7以上虽然“有创意”但输出格式极不稳定容易冒出奇怪的表述。0.3这个值在稳定性和表达流畅度之间比较均衡。第二是top_p保持在0.85。它主要管候选词的概率累积范围太低会让回答过于死板太高又容易跑题。第三是num_ctx也就是上下文窗口长度。我给模型设置了8192这个值能容纳“指令检索文档历史对话”的完整上下文。每增加2048的上下文长度KV Cache大约多占0.7GB显存所以如果你的显卡更小建议把上下文窗口降到4096并通过DSS层压缩检索片段补足信息量。第四是系统提示词。单独的模型用和接入了知识库的模型用系统提示词写法完全不同。接入知识库后我会在提示词里明确写“优先依据背景资料回答不要编造业务流程和数据。如果资料不足直接说明未知。”这个提示词能明显减少“一本正经地胡说八道”的情况。4. 从0到1部署的完整流程含可直接抄的配置4.1 环境准备与依赖安装我的部署环境是Ubuntu 22.04 LTS显卡驱动版本535CUDA 12.2。如果你用的是Windows过程会有一些差异但大体思路一样。基础环境三条命令搞定# 安装Ollama本地推理引擎 curl -fsSL https://ollama.com/install.sh | sh # 安装Python依赖DSS和OCT层使用 pip install fastapi uvicorn chromadb bge-reranker pypdf python-docx # 拉取中文模型和嵌入模型 ollama pull qwen2.5:7b-instruct-q4_K_M ollama pull bge-m3这里有个容易忽略的细节嵌入模型和对话模型最好用同一个推理引擎管理避免多套环境的内存冲突。Ollama同时支持对话模型和嵌入模型省掉了单独运行一个Embedding服务的麻烦。4.2 本地推理服务先用Ollama跑通模型模型拉取完成后我用下面的命令启动Ollama服务# 限制并发数为1防止并发请求把显存打爆 OLLAMA_NUM_PARALLEL1 OLLAMA_MAX_LOADED_MODELS1 ollama serve很多初学者默认配置启动Ollama结果几个人同时提问时显卡瞬间OOM。我在1.0版本就吃过这个亏所以1.5版本直接把并发数锁死成1。这里解释一下原因7B模型在单张消费级显卡上本身就对显存高度敏感一旦并行处理两个请求KV Cache会翻倍显存直接不够用。Ollama默认会尝试并行所以必须手动限制。启动之后用一行命令验证服务是否正常curl http://localhost:11434/api/generate -d {model: qwen2.5:7b-instruct-q4_K_M, prompt: 你好, stream: false}如果返回包含“你好”的回复推理引擎就绪。4.3 DSS层的知识库搭建从目录扫描到混合检索知识库模块是整个架构的灵魂。1.0版本一个很大的缺陷就是不会检索只知道凭模型记忆回答。1.5版本我重新设计了知识库处理流程分三步走。第一步是文档预处理。我写了一个定时任务扫描指定目录下的PDF、Word和TXT文件将它们转成纯文本再按固定逻辑切块。切块参数是chunk_size500、chunk_overlap50。这个参数不是拍脑袋定的而是根据业务文档的平均段落长度实测得出的。太小比如100会把语义拆碎太大比如2000又会让单个块混杂太多无关内容。第二步是向量化并写入Chroma。用bge-m3模型对每个块生成向量向量的维度是1024维。写入时把文件的原始路径、页码、块序号一起作为元数据存储这样检索命中后可以直接反查原文位置。第三步是实现混合检索。实际的业务问题往往涉及专有名词和人名纯向量检索可能召回不准所以我加了BM25关键词语义召回和向量召回两条路线再用一个轻量reranker对两者结果做融合排序。改造之后的效果非常明显。问“报销发票超过5000元是否需要财务总监审批”这类问题时系统能从文档库里准确召回对应的制度条款回答得分明显提升。4.4 OCT层和统一APIOCT层负责把用户的自然语言请求编排成“检索推理”流程并做上下文管理。我用FastAPI写了一个统一入口核心逻辑如下from fastapi import FastAPI, HTTPException from pydantic import BaseModel import requests import uuid app FastAPI() OLLAMA_URL http://localhost:11434/api/generate SESSION_STORE {} class ChatRequest(BaseModel): session_id: str query: str need_knowledge: bool True app.post(/api/v1/chat) def chat(req: ChatRequest): if not req.session_id: req.session_id str(uuid.uuid4()) history SESSION_STORE.get(req.session_id, []) # 1. DSS层检索知识库示意性调用 knowledge retrieve_knowledge(req.query) if req.need_knowledge else # 2. 组装上下文 system_prompt 你是一个企业内部AI助理请优先根据背景资料回答问题。资料\n knowledge # 3. 调用ODP层本地模型 payload { model: qwen2.5:7b-instruct-q4_K_M, prompt: f{system_prompt}\n\n历史对话{history}\n\n当前问题{req.query}, stream: False, options: {temperature: 0.3, top_p: 0.85} } resp requests.post(OLLAMA_URL, jsonpayload, timeout180) if resp.status_code ! 200: raise HTTPException(status_code502, detail推理引擎异常) answer resp.json().get(response, ) history.append({role: user, content: req.query}) history.append({role: assistant, content: answer}) SESSION_STORE[req.session_id] history[-8:] # 只保留最近4轮 return {session_id: req.session_id, answer: answer}这段代码是简化后的核心骨架生产环境还会加权限校验、日志落库和敏感词过滤。关键的设计点是历史会话只保留最近4轮防止多轮对话把上下文撑爆。有些团队一开始保留全部历史对话结果几十轮之后上下文窗口被撑爆回答质量急剧下降。4.5 接入企业现有系统API写好之后对接前端就很简单了。团队内部用的是企业微信和一套自研的工单系统我在工单系统里加了一个侧边栏组件把对话API直接嵌进去。同事点开工单详情页就能在右边直接问AI“这个工单的处理时限是几天”“客户反馈的设备型号对应的质保政策是什么”。嵌入方式不复杂前端用WebSocket或者轮询方式调用统一API然后渲染流式输出。关键的体验优化是给API加了一个事件流接口让AI回答时逐字显示而不是用户等30秒之后一次性看到整段文字。没有流式输出时延迟感特别强加上流式输出之后同事普遍反馈“速度快多了”。接入第三方系统时还有一个小提示统一API一定要把模型细节封装在内部对外只需要暴露一个“输入问题和会话ID输出答案”的接口。这样未来替换模型、升级DSS检索策略时前端完全不用动。5. 上线这些天踩过的坑与处理方案5.1 性能实测速览先说结论系统上线三周服务稳定运行总共处理了1800多个提问。知识库问答占比最高达到55%业务流程咨询占25%文档写作辅助占15%闲聊类只占5%。平均响应时间整体是25秒左右其中大文档相关的长提问会慢一些简单知识问答普遍10秒以内能出结果。同事满意度还可以至少没人抱怨“比检索网站还难用”。具体的效果对比和常见问题我整理了一个表问题症状根因解决方案回答中内容被截断DD以为模型“卡住”量化模型生成EOS过早调高temperature到0.3输出加前缀约束引用不存在的公司制度模型“编造”检索没有命中相关内容改成混合检索加reranker多用户同时使用深卡死显卡OOMOllama默认并行OLLAMA_NUM_PARALLEL1扫描版PDF内容乱知识库检索不到文字层缺失接入OCR预处理加PaddleOCR日志中出现手机号等敏感信息合规风险明文记录输出前做日志脱敏这几个坑每个都有代表性下面展开说一下。5.2 坑一量化模型输出被截断上线第一天就遇到一个问题回答比较长的制度条款时内容总在中间停下来像是突然“咽住”了。我一开始怀疑是推理引擎超时查了日志才发现生成很快结束了结束标记比预期更早出现。原因出在INT4量化模型上量化过程会损失一些精度模型对生成结束标记的概率判断变得敏感稍有波动就提前结束。当时试了很多办法最终有效的方案是把temperature从0.1调到0.3同时对输出格式加了约束。如果是要求模型输出JSON的场景我在提示词里明确写“严格按JSON格式输出”并在后处理时做一次修复显著减少了截断风险。5.3 坑二知识库直接硬塞上下文效果反而更差第一次做知识库问答时我走了一个弯路为了“让模型掌握足够多信息”我把相关的五个文档段落一次性全部塞进提示词上下文长度很快冲到6000多结果模型回答质量不升反降还经常引用到了无关段落的细节。这个坑在RAG类系统里其实很常见。模型能聚焦关注的信息其实有限给太多低相关度材料等于让它在垃圾堆里找宝贝。后来的方案是把检索返回的段落数从5段削减到3段同时利用reranker做重排序把最相关的段落排在最前面。只保留真正高价值的段落回答的准确率和速度都上来了。5.4 坑三多人同时用显卡直接OOM这个坑在4.2节已经提过。当时同事们在群里说“AI卡死了”我上服务器一看进程还在但显存已经跑满8GB的卡直接被多个推理实例撑爆。Ollama默认每个模型可以处理多个并行请求这在显存充裕的大服务器上是好事但在消费级显卡上就是灾难。解决方法是把并发数限制为1。这个配置会成为Ollama服务部署的默认必改项没有例外。如果你确实需要多人同时使用要么换更大显存的显卡要么加一个请求排队机制而不是指望消费级显卡靠高并发硬扛。5.5 坑四扫描版PDF文档解析一塌糊涂公司里有很多制度文件是扫描版PDF本质上是一张图片没有文字层。直接把这样的文件喂给文本解析器得到的要么是乱码要么是一片空白。解决思路是加一个OCR预处理。我在文档处理流水线里加入了PaddleOCR对扫面版文档先做文字识别再进入切块和向量化流程。这里还要提醒一个细节多栏PDF必须先做分栏检测再识别否则左右两栏的文字会混在一起识别后的顺序完全错乱检索命中率反而更差。5.6 坑五日志里的敏感信息上线一段时间后我做安全巡检时发现系统日志里把所有用户提问和AI回答都原样打印了出来其中包含同事的手机号、客户名称、内部项目代号等信息。如果日志被同步到第三方运维平台等于把核心数据链路又拆了一道口子。处理方案是双管齐下第一日志输出前经过一个脱敏过滤器用正则把11位手机号、身份证号、标注为敏感的关键词替换成掩码第二给统一API加上了权限校验必须携带访问Token才能调用同时记录调用方身份。如果你们用的不是自研前端这一步更不能省。6. 架构取舍、当前限制与下一步打算6.1 三个我比较得意的设计取舍重读整份架构有三个取舍我觉得特别值得守住。第一把模型推理单独拆成ODP层而不是直接在大模型应用框架里调用。这个做法的收益在后期的排障中非常明显任何一次性能瓶颈都能对准具体层处理而不是从用户输入一路查到模型参数。第二使用混合检索而不是纯向量检索。纯向量检索对同义改写类问题效果很好但对“编号名字”这种企业高频检索场景容易被专有词影响。加上BM25精确匹配并做融合排序后知识库命中率提升了一大截。第三对外统一API对内自由模块化。接口明确之后团队可以放心地试各种嵌入模型和推理参数而外部使用者的体验始终稳定。6.2 当前版本的限制这些限制我认为值得坦白。第一是多轮复杂任务的处理能力有限。当用户连续追问“那去年同期呢再对比一下华北区数据”时OCT层的简单规则已经很难正确识别指代偶尔会把“去年同期”当成“华北区本月”去检索。第二是纯文本之外的多媒体支持不足用户上传一张图片问“这是哪个型号的设备”系统目前无法解析。第三是模型自身的知识截止日期限制新政策发布后如果文档库还没有更新模型只能“不知道”。6.3 后续我想继续推进的方向短期计划是把DSS层扩展成支持数据库的自然语言查询。目前销售数据的查询仍然是OCT里写死的一小套模板后续想加入动态文本转SQL能力让市场部的人直接问“各区域本月回款环比排名”这类问题系统实时生成查询语句并返回结果。中期计划是给OCT层加入真正的Agent能力让它能按需调用多个业务API而不仅仅是知识检索和对话。长期来看我打算让这套私有化部署方案支持多机扩展模型推理节点和数据检索节点分离用消息队列连接。虽然单机轻量化是当前的主打卖点但如果后续团队增加到上百人使用单机模式必然撑不住。最后一件事也是我认为这次项目中最重要的一条经验做这种本地私有化AI项目不要在开始阶段沉迷于调参和换模型先把数据通路打通再把上下文管理做扎实最后才回头优化生成效果。顺序一旦反了大概率会把时间浪费在反复推倒重来上。这套OCTDSSODP架构的真实价值不在于那些缩写有多唬人而在于它把“对话、检索、算力”这三件事彻底拆开每一件都能独立演进这才是轻量化私有化系统在真实业务里站稳脚跟的关键。