企业官网建设流程全解析

1. 当老板说“数据不能出公司”，他到底在担心什么

“数据不出公司也能用大模型”这句话，我第一次从业务部门负责人嘴里听到时，他的原话更直白：“你别跟我讲云端API多便宜，我们那些合同、客户名单、工艺参数，只要有一个字节离开内网，法务就先把我按在地上摩擦。”这句话基本概括了企业级大模型落地最核心的矛盾——模型能力越强，越依赖数据；而企业越有价值的数据，越不能往外走。

这个矛盾不是技术问题，是信任边界问题。公有云大模型服务再便宜、再强，只要数据要经过公网传输、要在别人的服务器上做推理，很多行业就直接出局。金融、医疗、法律、制造、政务相关的场景，数据主权和合规要求是硬门槛，不是“优化项”。所以“数据不出公司也能用大模型”这件事，本质上是把大模型的推理能力搬进企业自己的机房或者专有云里，让数据在物理边界内完成闭环。

适合看这篇内容的人有三类：一是正在做企业AI选型的技术负责人，需要判断私有化部署到底值不值得投入；二是被老板要求“搞个内部大模型”的工程师，手里有GPU但不知道从哪下手；三是做知识库问答、内部Agent的产品同学，想知道私有化之后能力会打多少折扣。我会把选型逻辑、部署路径、微调取舍、踩坑经验都摊开讲，尽量让你看完能直接对照自己公司的情况做判断。

先给一个结论性的判断：私有化部署不是“把云端模型下载下来跑起来”这么简单，它是一整套围绕数据边界重新设计的技术栈。模型只是其中一环，推理框架、向量库、权限体系、监控运维，缺一个都会在真实业务里翻车。下面我按实际落地的顺序，一层一层拆。

2. 私有化大模型的技术栈到底由哪几块拼成

2.1 模型权重：开源基座是唯一现实选择

数据不出公司，意味着你不能调用任何外部API。那模型从哪来？答案基本只有一个方向：开源可商用的基座模型。目前企业私有化场景里，主流选择集中在几个系列上，参数规模从7B到72B不等。选多大的模型，不是越大越好，而是要看你的GPU显存和业务对延迟的容忍度。

我一般用这个粗略公式估算显存需求：FP16精度下，每10亿参数约需2GB显存。也就是说，一个70B的模型，光权重就要吃掉140GB左右显存，再加上KV Cache和推理框架开销，实际需要2张80GB的卡才能比较舒服地跑起来。如果是7B模型，一张24GB的消费级卡就能推理，这也是为什么很多企业第一版POC都从7B或14B起步。

这里有个容易被忽略的点：量化能大幅降低显存门槛，但会损失精度。INT8量化大约能把显存砍半，INT4再砍一半，但4bit量化在长上下文和复杂推理任务上掉点明显。我的经验是，知识库问答这种以检索为主的任务，INT4可以接受；但涉及数值计算、逻辑链推理的场景，尽量用FP16或者至少INT8。

2.2 推理框架：决定吞吐和并发上限

模型权重有了，怎么把它高效地跑起来，靠的是推理框架。目前企业私有化里用得最多的是vLLM这一类基于PagedAttention的框架，核心优势是显存利用率高、并发吞吐大。它把KV Cache按页管理，避免了传统实现里的显存碎片问题，同样一张卡能扛的并发请求数能翻好几倍。

我实测过同一个7B模型，用原生Transformers推理和用vLLM推理，在并发10路请求时，vLLM的吞吐大概是前者的5到8倍。这个差距在真实业务里就是“能不能支撑全公司几百人同时用”的区别。所以私有化部署里，推理框架不是可选项，是必选项。

除了vLLM，还有一些面向边缘设备或低资源场景的框架，比如针对单卡甚至CPU推理做优化的方案。如果公司只有一张消费级显卡，又不想投入太多，可以考虑这类轻量框架，但要做好并发能力有限的预期。

2.3 知识库与向量检索：让模型“知道公司的事”

基座模型再强，也不知道你公司的产品手册、历史工单、内部制度。私有化场景里，检索增强生成（RAG）是标配。流程是：把公司文档切块、向量化、存进向量数据库；用户提问时，先检索最相关的片段，再连同问题一起喂给模型生成答案。

向量数据库的选择上，轻量场景可以用FAISS这种本地库，部署简单、零依赖；要支持多用户、权限隔离、增量更新，就得用Milvus、Qdrant这类服务化方案。我踩过的一个坑是：文档切块策略直接决定问答质量。按固定字数切，经常把一句话拦腰截断，检索出来的片段语义不完整。后来改成按段落+重叠窗口切，召回质量明显提升。

2.4 权限与审计：私有化的真正价值所在

数据不出公司，不只是网络隔离，还包括谁能问什么、问了什么、答案给了谁。企业级私有化必须有一套权限体系：不同部门的人只能检索自己有权限的文档，所有问答记录要留痕可审计。这块经常被技术团队忽略，但恰恰是业务和法务最看重的。

我见过一个反面案例：某团队把全公司文档一股脑灌进向量库，结果实习生问了一句“今年高管薪酬方案”，模型直接把敏感内容吐出来了。后来补权限过滤，是在检索层加了一道基于用户角色的元数据过滤，确保召回阶段就只返回有权限的片段。

3. 从零到一：一套可复现的私有化部署路径

3.1 环境准备中最容易翻车的三个细节

第一是GPU驱动和CUDA版本匹配。推理框架对CUDA版本有明确要求，驱动太旧会直接报错。我的习惯是先确定框架要求的CUDA版本，再倒推装驱动，而不是先装最新驱动。第二是显存被其他进程占用，尤其是多人共用的测试机，跑之前先用nvidia-smi确认干净。第三是磁盘空间，模型权重动辄几十GB，下载和解压都需要预留足够空间，我一般会留出模型体积3倍以上的余量。

3.2 模型下载与本地加载

模型权重通常从开源社区获取，下载方式有命令行工具和直接拉取两种。下载完成后，目录结构要保持完整，配置文件、分词器文件、权重分片一个都不能少。加载时指定本地路径，确保推理框架从本地读取，不走任何网络请求。

# 以命令行工具下载模型为例（示意） huggingface-cli download <model-repo> --local-dir /data/models/xxx

加载之后先做一次冒烟测试：用一句简单的话让模型续写，确认能正常输出。这一步能排除掉大部分环境问题。

3.3 推理服务启动与接口封装

推理框架一般提供OpenAI兼容的HTTP接口，这样上层应用不用改代码就能对接。启动时关键参数包括：模型路径、张量并行数（多卡时）、最大上下文长度、显存占用比例。显存占用比例这个参数很关键，设太高容易OOM，设太低浪费显存，我一般从0.9开始试，不稳定就往下调。

# 启动推理服务（示意） python -m vllm.entrypoints.openai.api_server \ --model /data/models/xxx \ --tensor-parallel-size 2 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9

服务起来后，用curl测一下接口通不通，再接入上层应用。

3.4 知识库灌入与检索链路打通

文档灌入分三步：解析、切块、向量化。解析要处理PDF、Word、Excel、HTML等多种格式，PDF里的表格和扫描件是最难啃的，必要时得上OCR。切块我建议按语义段落切，块大小控制在300到500字，块之间留10%到20%的重叠，避免语义断裂。

向量化用嵌入模型，同样要选开源可私有化的。灌入完成后，用几个已知答案的问题测召回，看返回的片段是否包含正确答案。这一步不通过，后面生成质量无从谈起。

3.5 端到端联调与压测

把检索、拼接提示词、调用模型、返回答案串起来，做一轮端到端测试。然后上压测，模拟10路、50路、100路并发，观察响应时间和错误率。我一般会记录P95延迟，这个指标比平均延迟更能反映真实体验。如果P95超过业务容忍阈值，就要考虑加卡、量化或者优化检索链路。

4. 微调还是RAG：企业最纠结的一道选择题

4.1 两者解决的根本不是同一个问题

很多人把微调和RAG当成二选一，其实它们解决的是不同层面的问题。RAG解决的是“模型不知道的事实”，比如公司内部制度、产品参数、历史案例，这些是外部知识，靠检索注入。微调解决的是“模型不会的风格和格式”，比如让模型按公司特定的报告模板输出、用行业术语回答、遵循特定的对话逻辑。

打个比方：RAG是给模型配了一本可以随时翻的参考书，微调是让模型去上了一门专业课，改变了它的表达习惯。两者可以叠加，但优先级不同。我的建议是先做RAG，再考虑微调。因为RAG见效快、可解释、更新方便，文档变了重新灌入就行；微调成本高、周期长，而且一旦基座模型升级，微调成果可能白费。

4.2 什么情况下微调才真正值得做

有三种情况我会建议上微调：一是输出格式要求极严，比如必须输出特定结构的JSON，RAG提示词怎么调都不稳定；二是领域术语密集，基座模型对行业黑话理解偏差大，检索也救不回来；三是有大量高质量标注数据，且业务场景稳定，值得投入训练成本。

微调数据量上，指令微调一般几千到几万条就能看到效果，但数据质量比数量重要得多。我见过用500条精标数据跑出比5万条脏数据更好的效果。数据构造上，要覆盖真实业务里的各种问法和边界情况，不能只挑简单样本。

4.3 微调的显存账和常见参数

全量微调70B模型基本不现实，企业里常用的是参数高效微调（PEFT），典型代表是LoRA。LoRA只训练一小部分低秩矩阵，显存需求大幅下降。以7B模型为例，LoRA微调大概需要16到24GB显存，单张消费级卡就能跑。

关键参数上，学习率一般设在1e-4到2e-4，秩（rank）从8到64不等，秩越高表达能力越强但越容易过拟合。训练轮数不宜多，2到3轮通常就够，多了会过拟合。我一般会留10%数据做验证，盯着验证损失，一旦回升就停。

4.4 微调之后的评估不能只看loss

训练损失下降不代表业务效果变好。我一般会准备一套业务评测集，包含真实问题和期望答案，微调前后各跑一遍，人工或自动打分对比。重点看三类指标：格式合规率、术语准确率、拒答率。拒答率这个指标容易被忽略，微调过头会让模型变得“不敢回答”，什么都说“我不确定”，这在实际业务里是灾难。

5. 真实落地时那些文档里不会写的坑

5.1 长上下文不是越长越好

很多业务方一上来就说“我们要支持10万字上下文”。实际上，上下文越长，推理越慢、显存占用越高，而且模型在超长上下文里的注意力会稀释，关键信息反而被淹没。我的做法是用RAG把上下文控制在合理范围，通常4K到8K就够覆盖绝大多数问答场景，实在需要长文档理解，再单独走长上下文通道。

5.2 并发一上来，延迟就崩

单用户测试时响应飞快，全公司一用就卡。这是私有化部署最常见的翻车场景。根因通常是推理框架的并发配置没调好，或者GPU数量不够。解决办法：一是用支持连续批处理的推理框架，把多个请求合并成一批一起算；二是做好限流，避免突发流量打垮服务；三是监控显存和队列长度，提前扩容。

5.3 模型“胡说八道”的治理

私有化模型没有云端那么强的安全对齐，幻觉问题更突出。治理手段有三层：检索层保证召回内容真实可靠；提示词层明确要求“只根据提供的资料回答，不知道就说不知道”；后处理层对输出做关键词和格式校验，发现异常就拦截。我实测下来，这三层叠加能把幻觉率压到可接受范围。

5.4 模型更新与版本管理

基座模型迭代很快，新版本能力更强，但直接替换可能让原有提示词和微调失效。我的做法是保留多版本模型并行，新版本先在小流量上灰度，对比业务指标，稳定后再切主流量。同时把提示词模板、微调权重、评测集都纳入版本管理，确保任何一次更新都可回滚。

6. 成本、效果与合规之间的平衡术

6.1 算一笔真实的账

私有化部署的成本不只是GPU采购。我一般按这几块算：硬件采购或租赁、机房电力和散热、运维人力、模型迭代的持续投入。一张80GB的卡采购价不低，但如果按三年折旧摊到每月，再对比云端API按token计费的成本，很多高频场景下私有化反而更划算。关键是看调用量，量越大，私有化的单位成本越低。

6.2 效果打折是必然，关键是打多少

必须承认，私有化的开源模型在通用能力上通常不如顶级云端模型。但在垂直业务场景里，通过RAG注入企业知识、通过微调对齐业务风格，实际效果可以非常接近甚至超过通用云端模型。因为业务问答要的不是“什么都懂”，而是“懂我们公司的事”。这个认知转变很重要，能帮你设定合理的预期。

6.3 合规不是负担，是护城河

数据不出公司这件事，表面上是限制，实际上是企业AI应用的信任基础。当业务方知道数据全程在内网闭环，他们才愿意把真正有价值的场景交出来。我见过太多因为担心数据外泄而搁置的AI项目，私有化部署恰恰是解开这个死结的钥匙。把权限、审计、加密这些合规能力做扎实，反而能加速AI在内部的推广。

7. 我个人在私有化项目里最看重的几条经验

第一，先跑通最小闭环，再谈优化。不要一上来就追求70B、追求全量微调，先用7B加RAG跑通一个部门的小场景，拿到真实反馈再迭代。第二，评测集比模型更重要。没有业务评测集，你根本不知道换模型、调参数是变好还是变坏。第三，把运维监控当一等公民。显存、延迟、并发、错误率这些指标要实时可见，否则出了问题只能靠猜。第四，和业务方对齐预期。私有化模型不是万能助手，它是一个需要持续喂养和调教的内部工具，把边界讲清楚，后续合作才顺畅。

最后分享一个我常用的小技巧：在正式上线前，找几个“刁钻”的业务用户来做红队测试，专门问边界问题、敏感问题、超纲问题，把暴露出来的bad case整理成评测集。这一轮下来，你会发现很多自己想不到的坑，比任何技术文档都管用。