1. 背景与核心概念
1.1 为什么高校需要私有化部署大模型
近期在协助上海某高校推进智慧校园建设时，核心需求是把大模型能力融入校内教学、科研和行政办公场景。最初他们使用的是公有云 API，但实际试用一段时间后，几个问题逐渐暴露出来。
首先是数据合规压力。高校内部涉及学生成绩、科研课题、人事信息等敏感数据，如果把这些数据发送到外部 API，很难通过校网络信息中心的合规审查。其次，师生对 API 调用稳定性要求很高，教学高峰期并发上来之后，公有云接口的响应延迟波动明显，很多助教和教务老师都在抱怨。还有一个很现实的原因是成本模型不透明，按 Token 计费的方式在校园场景下不好预算，特别是有些课题组要做批量文本处理，费用很难控制。
综合评估之后，校方决定将大模型直接部署在校内算力平台上。私有化部署的核心价值在于：数据不出校园、推理延迟可控、后期可按需扩容、师生通过校园网即可访问统一的大模型服务，无需关心底层算力调度逻辑。
1.2 技术选型：为什么用智谱 GLM
智谱 GLM 系列是当前国内高校和政企机构私有化部署中比较常见的选择。一方面，GLM 的开源权重和商用授权边界相对清晰，校内非商业化科研与教学使用有比较好的合规基础；另一方面，GLM 的模型结构对主流推理框架支持较好，部署资料相对完整，遇到问题也更容易找到社区方案。
本次项目中涉及的 GLM-5.2 是校方提供的内网部署包版本标识。由于大模型迭代速度非常快，部署时版本号要以校内镜像仓库实际下载到的模型权重和推理框架版本为准，不要照搬网上任意一篇教程的固定版本。本文的重点是讲清楚私有化部署的完整链路和工程化落地方案，版本细节按实际操作环境动态调整即可。
1.3 整体方案拆解
整个项目的目标不是简单把模型权重跑起来，而是要建设一个可供校内多个业务系统复用的“大模型能力中台”。整体架构可以拆成三个层次：
- 模型推理层：GPU 服务器承载大模型权重，通过推理框架暴露标准化 API。
- 应用编排层：接入 Dify 这类 LLMOps 平台，把模型能力包装成知识库问答、智能客服、文档处理等具体应用。
- 业务接入层：教务系统、OA 系统、在线学习平台通过 API 或前端组件调用统一的大模型服务。
此外，办公场景往往还需要配套 OnlyOffice 私有化部署，用于在线文档预览与协同编辑，再叠加模型能力实现文档摘要、内容生成、智能批改等功能。接下来按项目实施顺序逐一拆解。
2. 环境准备与硬件规划
2.1 硬件资源评估
大模型私有化部署对硬件的要求不能简单看模型参数量，还要看推理框架、并发规模、量化方式以及是否启用长文本能力。
以本次高校项目为例，校内规划是面向 300 名左右教职工提供日常 AI 助手服务，同时支持 2 到 3 个重点课题组做科研数据处理。按这个规模，硬件配置初步建议如下：
| 资源项 | 建议配置 | 说明 |
|---|---|---|
| GPU | 单卡 48GB 及以上显存，建议 2 卡起步 | 显存决定可加载的模型规模和并发吞吐 |
| CPU | 32 核以上 | 负责数据预处理、调度、Token 化等任务 |
| 内存 | 256GB 起步 | 长文本场景下 KV Cache 占用明显 |
| 系统盘 | 1TB SSD | 存放系统、推理框架和日志 |
| 数据盘 | 4TB 以上 NVMe SSD | 存放模型权重、Dify 数据、向量库 |
| 网络 | 双万兆网卡 | 多卡并行时通信压力大 |
需要说明的是，大模型部署硬件选型没有“标准答案”，不同量化精度、不同输入输出长度对显存的影响差别很大。原则是先用小规模压测数据估算，再根据实际评测结果决定是否扩容。
2.2 操作系统与基础软件环境
操作系统层面，本次项目选择的是 Ubuntu 22.04 LTS。原因很简单：依赖兼容性好、驱动安装资料多、遇到问题容易排查。如果是 CentOS 7 这类老系统，建议先做升降级评估，因为较新版本的 PyTorch 和推理框架可能不再支持旧版本 glibc。
基础软件环境如下：
- Docker 与 Docker Compose：负责一键拉起 Dify、OnlyOffice 等服务。
- NVIDIA 驱动与 CUDA：版本必须与推理框架匹配，建议优先使用 NVIDIA 官方驱动。
- Python 3.10 或 3.11：用于后续安装推理框架和脚本工具。
- Git LFS：下载大体积模型权重文件时使用。
驱动安装完成后，用nvidia-smi验证 GPU 是否正常识别：
nvidia-smi如果能看到类似下面的输出，说明驱动和 CUDA 环境没有问题：
+-----------------------------------------------------------------------------+ | NVIDIA-SMI 535.154.05 Driver Version: 535.154.05 CUDA Version: 12.2 | +-----------------------------------------------------------------------------+如果命令提示未找到，需要先确认 PCIe 设备是否识别，再检查驱动安装是否与内核版本匹配。
2.3 项目目录规划
私有化部署涉及的服务比较多，统一规划目录结构可以显著降低后期维护成本。本次项目采用如下目录结构：
/opt/llm-platform/ ├── models/ # 模型权重文件存放目录 ├── vllm/ # vLLM 推理服务配置与日志 ├── dify/ # Dify 平台部署目录 │ ├── docker-compose.yaml │ └── volumes/ # 数据持久化目录 ├── onlyoffice/ # OnlyOffice 文档服务 └── scripts/ # 运维与监控脚本目录规划的本质是让“哪个服务、哪个数据、哪个配置文件”一目了然。后续排错、备份、权限管理都围绕这个目录展开。
3. 模型部署与推理服务搭建
3.1 模型权重准备
模型权重一般是通过校内镜像仓库或者离线包方式获取。如果是从 Hugging Face 或 ModelScope 下载，建议提前确认网络策略，并申请相应权限。高校内网环境往往无法直接访问外部资源，最稳妥的方式是找一台有外网权限的机器先下载完整权重，再通过内网传输到 GPU 服务器。
如果使用 Git LFS 下载，示例命令如下：
git lfs install git clone https://huggingface.co/THUDM/glm-model这里要特别提醒：大模型权重文件往往有几十 GB，下载完成后一定要校验文件完整性，避免传输出错导致模型加载失败。建议记录下发布方提供的 SHA256 校验值，对比确认无误再继续部署。
3.2 部署 vLLM 推理服务
vLLM 是目前私有化部署大模型时使用率很高的推理加速框架，其核心优势是 PagedAttention 显存管理机制，能够显著提升吞吐量，同时提供兼容 OpenAI 的 API 接口。这意味着我们不需要编写额外的协议转换层，业务系统改造时直接把 Base URL 指过来即可。
安装 vLLM 推荐使用 Docker 方式，环境隔离更彻底。先拉取镜像：
docker pull vllm/vllm-openai:latest然后启动推理服务。以下命令是一个基础示例，实际部署时需根据模型路径、GPU 数量和显存情况调整参数：
docker run -d \ --name vllm-glm \ --gpus all \ --ipc=host \ -v /opt/llm-platform/models:/models \ -p 8000:8000 \ vllm/vllm-openai:latest \ --model /models/glm-5.2 \ --served-model-name glm-chat \ --tensor-parallel-size 2 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --trust-remote-code下面对关键参数做说明：
--model：模型权重在容器内的路径。--served-model-name：对外暴露的模型名称，业务系统调用时使用这个名字。--tensor-parallel-size：多卡并行推理时使用的 GPU 数量。2 卡就写 2，4 卡写 4。--max-model-len：最大序列长度。长度越长，显存占用越高，需要根据 GPU 显存谨慎调节。--gpu-memory-utilization：允许推理服务使用的显存比例，0.9 表示最多占用 90% 显存，预留一部分给系统和其他进程。--trust-remote-code：允许加载模型目录中的自定义代码文件。仅在模型来源可信时使用，这一点要特别谨慎。
启动后，通过日志确认服务是否正常运行：
docker logs -f vllm-glm看到类似Uvicorn running on http://0.0.0.0:8000的日志，说明推理服务已经就绪。
3.3 验证 OpenAI 兼容接口
vLLM 启动后，我们可以直接使用 OpenAI SDK 来调用。因为接口格式兼容，所以不需要额外安装其他 SDK。
先用 curl 做一个最简单的验证：
curl http://localhost:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "glm-chat", "messages": [ {"role": "user", "content": "用一句话介绍上海"} ], "max_tokens": 100, "temperature": 0.7 }'如果配置正确，会返回一段 JSON 数据，其中choices[0].message.content就是模型生成的文本内容。这一步验证通过后，模型推理层就已经具备对外提供服务的能力了。
从工程角度看，这里还需要注意几个点。第一，不要直接把 vLLM 端口暴露给校园网所有用户，应该在前面加一层 API 网关，统一处理鉴权、限流和日志记录。第二，max_tokens要根据实际业务场景合理设置，校内知识库问答通常不需要太长的生成内容，设置过大会浪费显存资源。第三，推理服务的健康检查接口要接入监控系统，vLLM 本身没有特别完善的管理界面，需要通过外部监控补齐。
3.4 配置长文本与吞吐参数
高校场景中经常遇到长文档分析需求，比如论文摘要、课程资料解析。如果部署的模型版本支持长文本，需要重点调整两个方向：一是max-model-len参数，二是编码阶段的显存分配策略。这里需要特别提醒，长文本不是越大越好。序列长度翻倍，KV Cache 显存占用也近似翻倍，超出 GPU 显存就会导致请求失败或者 OOM。上线前建议用目标长度的真实文本做压测，再确定合理的模型长度上限。
4. 接入 Dify 构建 AI 应用平台
4.1 为什么选 Dify
模型推理层就绪后，如果直接让各业务系统对接裸 API，开发和维护成本会非常高。每个系统都需要自己实现会话管理、提示词模板、知识库检索、内容审核等等。为了把能力沉淀为可复用的平台，本次项目选择了 Dify 作为应用编排层。
Dify 的核心价值在于：
- 可视化编排 Agent、工作流和对话应用，非深度开发人员也能搭建应用。
- 内置知识库功能，支持文档上传、分段、向量化、检索，适合学校各类资料库场景。
- 与 OpenAI 兼容 API 可以直接对接，添加模型供应商非常方便。
- 提供 Web App 和 API 两种形态，既能快速预览，也能集成到现有系统。
4.2 Dify 部署与配置
Dify 官方提供 Docker Compose 部署方式。在/opt/llm-platform/dify目录下，拉取部署仓库：
git clone https://github.com/langgenius/dify.git cd dify/docker cp .env.example .env docker compose up -d首次启动会拉取多个镜像，时间取决于网络情况。启动完成后，访问http://服务器IP/install进行初始化安装，设置管理员账号密码。
安装完成后，进入“设置 -> 模型供应商”，添加自定义模型供应商。由于 vLLM 暴露的是 OpenAI 兼容接口，选择 OpenAI 类型供应商即可。配置信息如下：
API Base URL: http://<vLLM服务器IP>:8000/v1 API Key: vllm 服务未配置鉴权时可先填任意值 Models: glm-chat这里需要说明，默认情况下 vLLM 没有开启 API Key 校验，Dify 接入时填一个形如sk-noauth的占位值即可。但在生产环境，必须在前置网关层启用真实鉴权，避免内网任意用户直接调用模型接口。
4.3 创建知识库与问答应用
以校内“规章制度智能问答”为例，演示完整配置流程。
第一步，创建知识库。在 Dify 控制台进入“知识库”，上传学校规章制度文档。上传后设置分段规则，一般建议按标题层级分段，每段长度控制在 500 到 1000 Token 之间。分段过长，检索命中后返回内容太泛；分段过短，上下文信息容易缺失。然后选择 Embedding 模型，这一步需要确认 vLLM 部署的模型是否具备 Embedding 能力，如果不具备，可以考虑单独部署一个 Embedding 镜像服务。
第二步，创建应用。在“应用”中选择“聊天助手”，选择刚刚添加的glm-chat模型。填写系统提示词，示例内容如下：
你是上海某高校的智能校务助手，请根据知识库内容回答师生关于规章制度的问题。 回答时先给出明确结论，再引用知识库原文佐证。 如果知识库中没有相关信息，请如实说明“暂未查到”，不要编造内容。第三步，在应用编排页面左侧点击“添加”，关联刚创建的知识库。这里有一个关键参数叫“召回模式”。如果选择“向量检索”，响应速度快但可能遗漏同义表述；如果选择“全文检索”，匹配更全面但可能引入噪音。实际项目中建议选择“混合检索”，并设置合理的相关性阈值。
第四步，发布应用。Dify 提供调试预览界面，可以先在页面上测试几个典型问题，确认回答质量和知识库召回效果后，再发布为 Web App 或 API 服务。
4.4 Dify 与 vLLM 的协作边界
在整个链路中，vLLM 只负责模型推理，Dify 负责应用编排和知识库管理。两者通过 HTTP 接口通信。这种拆分的好处是职责清晰，模型升级时只需要更换 vLLM 的启动参数，Dify 侧基本不用改。同时，Dify 可以对接多套模型服务，例如用较大的 GLM 模型做复杂推理，用较小的模型做摘要或者意图识别，按场景动态路由。
5. 私有化部署 OnlyOffice 实现文档协同
5.1 办公场景下的文档需求
高校行政办公中，大量文档流转仍然依赖本地 Office 软件，版本不一致、无法在线协同、内容留痕困难等问题长期存在。在部署大模型平台的同时，校方提出希望一并解决在线文档预览和协作编辑问题。经过选型，确定了 OnlyOffice 作为文档服务底座。
OnlyOffice 的优势是社区版功能完整，支持 docx、xlsx、pptx 等主流格式在线编辑，部署方式简单，并且可以通过 API 与现有 OA 系统集成。文档在线后，大模型能力也能进一步接入，比如一键生成文档摘要、批量格式整理、智能校对等。
5.2 部署 OnlyOffice Document Server
使用 Docker 部署 OnlyOffice 是最直接的方式。示例命令如下：
docker run -d \ --name onlyoffice-document-server \ -p 8080:80 \ -v /opt/llm-platform/onlyoffice/logs:/var/log/onlyoffice \ -v /opt/llm-platform/onlyoffice/data:/var/www/onlyoffice/Data \ -v /opt/llm-platform/onlyoffice/lib:/var/lib/onlyoffice \ -v /opt/llm-platform/onlyoffice/db:/var/lib/postgresql \ onlyoffice/documentserver启动后访问http://服务器IP:8080，如果能打开 OnlyOffice 欢迎页，说明部署成功。这里有几个配置细节需要注意。
第一，OnlyOffice 的 JWT 鉴权默认开启，其他系统调用编辑接口时必须带上正确的Authorization头。在/etc/onlyoffice/documentserver/local.json中配置密钥，修改后需要重启容器生效：
docker exec onlyoffice-document-server supervisorctl restart all第二，如果前级有 Nginx 反向代理，WebSocket 连接需要特殊配置，否则多人同时编辑时会出现连接断开的问题。需要在 Nginx 配置中开启 WebSocket 升级头支持。
第三，文档存储目录必须做持久化，否则容器重建后所有文档数据都会丢失。这一点在部署时就要规划好。
5.3 OnlyOffice 与大模型平台整合思路
文档服务就绪后，可以在 Dify 中创建一个“文档助手”应用。流程是：用户上传文档到 OnlyOffice 或 OA 系统，系统调用 Dify 工作流对文档内容进行解析和摘要生成，再把摘要和批注写回文档，实现“文档 + 大模型”的闭环。这个场景的落地价值比较明显：教务通知自动生成精简版、科研结题报告自动校对格式、制度文件自动提取要点等。
6. 安全加固与生产环境部署
6.1 接入层鉴权与限流
大模型服务部署在内网不代表不需要鉴权。校园网用户规模大，一旦有学生扫描到端口并批量调用，GPU 资源会被迅速占满，影响正常教学使用。
生产环境建议在所有服务前面加一层 Nginx 反向代理，统一入口、统一鉴权、统一限流。Nginx 限流配置示例：
limit_req_zone $binary_remote_addr zone=llm_limit:10m rate=10r/s; server { listen 443 ssl; server_name llm-api.example.edu.cn; ssl_certificate /etc/nginx/ssl/example.crt; ssl_certificate_key /etc/nginx/ssl/example.key; location /v1/ { limit_req zone=llm_limit burst=20 nodelay; proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } location /health { proxy_pass http://127.0.0.1:8000/health; access_log off; } }上述配置中，limit_req_zone按客户端 IP 限制每秒 10 个请求，burst=20允许短暂突发 20 个请求。更大的并发可以通过单独部署 API 网关或负载均衡器解决。这只是基础防护，不能替代完整的认证中心接入，高校场景更推荐对接统一身份认证平台（CAS/OAuth2），让师生使用校园账号直接登录访问大模型服务。
6.2 数据安全与合规
高校数据合规的核心要求是：数据不出校、访问有留痕、删除可追溯。
在数据不出校层面，模型权重、知识库文件、对话日志都必须存储在校园网内部，禁止任何形式的外部数据回传。Dify 部署时要注意关闭遥测上报和外部统计功能，仔细检查 Docker 镜像的默认配置。vLLM 进程也不要设置任何外网回调地址。
在访问留痕层面，建议由 Nginx 记录完整的访问日志，包括调用时间、来源 IP、请求模型、Token 消耗量以及响应状态码。日志保留周期需要满足校内安全审计要求，一般建议至少保留 180 天。对于包含敏感内容的 Prompt 和响应，不要完整记录，可以做脱敏处理，只保留长度和主题标签。
在删除可追溯层面，知识库文档更新、用户会话清除等操作都要记录操作人、操作时间、操作内容。这里需要特别强调权限边界：模型服务的管理员权限与普通用户权限必须隔离，不要把管理端口暴露给业务网段。
6.3 日志、监控与告警
大模型平台运行监控与常规 Web 服务不同，除了 CPU、内存、磁盘等常规指标，还需要特别关注 GPU 显存利用率、推理延迟、Token 吞吐量、排队请求数等指标。这些指标可以通过 vLLM 的/metrics接口暴露给 Prometheus 采集。
Prometheus 配置中添加 vLLM 采集任务的示例：
scrape_configs: - job_name: 'vllm' static_configs: - targets: ['<vLLM服务器IP>:8000'] metrics_path: '/metrics'Grafana 中建议配置以下告警规则：
| 告警项 | 触发条件 | 处理建议 |
|---|---|---|
| GPU 显存使用率过高 | 持续 5 分钟超过 95% | 检查并发请求，考虑扩容或限流 |
| 推理请求 P95 延迟超时 | 超过 10 秒 | 检查模型负载，必要时增加 GPU |
| 推理服务不可用 | 健康检查连续 3 次失败 | 立即查看容器状态和系统日志 |
| 磁盘空间不足 | 使用率超过 85% | 清理日志，检查模型缓存目录 |
日志集中管理方面，可以采用 Loki 或 ELK 方案，将所有容器日志汇聚到统一平台。不推荐只依赖docker logs，因为多服务分散查看效率太低，问题定位非常慢。
6.4 备份与恢复策略
模型权重文件不需要频繁备份，但 Dify 的数据库、知识库向量数据、OnlyOffice 文档数据都需要定期备份。推荐采用“应用数据每日备份 + 配置更改后即时备份”的策略。
Dify 使用 Docker Compose 部署时，备份的关键是 PostgreSQL 数据卷。备份命令示例：
docker exec -t dify-db pg_dump -U dify dify > /backup/dify_$(date +%Y%m%d).sqlOnlyOffice 的文档数据直接备份持久化目录即可：
tar -czvf /backup/onlyoffice_$(date +%Y%m%d).tar.gz /opt/llm-platform/onlyoffice/data备份文件要通过脚本定期同步到独立的备份存储中，并定期演练恢复流程。对于生产环境，建议在正式切换前至少做一次完整恢复演练，避免真出问题的时候发现备份不可用。所有备份数据的访问权限要严格控制，因为文档数据中很可能包含学生个人信息。
7. 版本兼容性与性能调优经验
7.1 常见版本兼容性问题
私有化部署项目中最耗时的往往不是模型本身，而是版本兼容性问题。以下几个问题在本次项目中都实际遇到过，整理出来供参考。
第一个是 CUDA 与 PyTorch 版本不匹配。推理框架依赖特定版本的 CUDA 运行时，如果数据库里已经有旧版本 PyTorch，新启动的容器可能因为找不到libcudart.so而失败。这类问题排查时优先看容器启动日志，而不是盲目重装驱动。
第二个是 vLLM 与模型权重的兼容性。大模型迭代速度很快，新版本模型可能依赖较新的 vLLM 版本，而新版本 vLLM 又可能要求更高版本 CUDA。建议部署前先查看模型发布页的部署文档，确认推荐的推理框架版本范围。
第三个是 Dify 版本与模型供应商配置的兼容性。Dify 迭代较快，不同版本的模型供应商配置界面有差异。参考网上教程时，一定要确认教程对应的 Dify 版本，不能直接照搬。
第四是 GPU 驱动与 Docker 环境的配合问题。Docker 容器内使用 GPU 需要安装 NVIDIA Container Toolkit，否则即使宿主机能识别 GPU，容器内也调用不了。
7.2 性能调优实践
模型推理性能调优需要从多个维度综合考虑。首先是并发参数，vLLM 本身会自动管理连续批处理，但实际能支撑的最大并发数取决于显存和模型长度。建议先用压测工具做梯度压测，分别测试 1、4、8、16 路并发下的延迟和吞吐量，找到性能拐点。
其次是输入输出长度控制。高校问答场景中，大部分问题在 200 Token 以内，回答控制在 500 Token 以内。如果默认配置允许 8192 Token，就会导致显存预留过大，单位时间吞吐量下降。建议在业务层面对长度做硬性限制，而不是完全依赖模型侧参数。
第三是 Embedding 与向量检索的瓶颈。知识库文档量上来之后，向量检索可能成为新的性能瓶颈。Dify 内置的向量数据库在小数据量下表现尚可，但超过百万级向量后建议切换到独立的向量数据库服务。
第四是缓存策略。对于高频问题，可以在 Dify 外层加一层 Redis 缓存，把 Prompt 向量和生成结果缓存起来，命中缓存时直接返回，不再调用模型，这样可以显著降低 GPU 压力。
7.3 多模型路由策略
高校场景下，单一模型往往不能覆盖所有需求。例如，日常问答希望响应快、成本低，复杂公文写作希望质量高，长文档总结希望上下文窗口大。更好的做法是在 Dify 中配置多个模型，然后通过工作流按条件路由。
简单路由逻辑可以这样实现：根据用户问题的关键词或长度，区分任务类型，分发到不同模型。例如，涉及“规章制度”“办事流程”的问题走知识库问答链路，涉及长篇文章的任务走长文本模型链路。Dify 工作流中的“条件分支”节点可以完成这个编排，整个配置过程无需编写代码。
8. 常见问题与排查清单
8.1 高频问题汇总
这里把高校私有化部署项目中最容易遇到的问题整理成表格，方便现场运维人员快速对照排查。
| 问题现象 | 常见原因 | 解决思路 |
|---|---|---|
| 容器启动后立刻退出 | 模型路径错误或权重文件不完整 | 检查挂载路径，重新校验模型文件哈希 |
| GPU 显存不足导致 OOM | max-model-len设置过长或并发过高 | 调低最大序列长度，减少并发，调整显存利用率 |
| 接口响应极慢 | GPU 利用率过高或模型长度超限 | 查看监控指标，优化业务请求长度，考虑扩容 |
| Dify 无法连接模型供应商 | Base URL 配置错误或 vLLM 端口未开放 | 在 Dify 容器内 curl 测试模型接口连通性 |
| 知识库召回结果不相关 | 分段策略不合理或检索模式不合适 | 调整分段长度，改用混合检索并调相关性阈值 |
| OnlyOffice 无法保存文档 | JWT 鉴权未正确配置 | 检查生成 editorConfig 时的 token 是否正确 |
| WebSocket 连接频繁断开 | Nginx 未配置 WebSocket 升级 | 配置 Upgrade 与 Connection 请求头转发 |
8.2 排查思路示例
举一个实际案例。部署完成后使用 Dify 测试问答，发现模型响应内容正确，但整体耗时高达 30 秒以上，远超出预期的 3 秒左右。
排查过程如下：
第一步，先确认耗时发生在哪个环节。查看 Dify 日志，发现请求在等待模型响应阶段耗时了 28 秒。这基本说明问题出在 vLLM 推理层，而不是 Dify 编排或知识库检索。
第二步，进入 vLLM 容器查看日志，发现多个请求排队等待，且 GPU 显存利用率接近 100%。说明在并发请求下显存被打满，新的请求只能排队等待前面的请求释放显存。
第三步，查看当前模型长度配置，发现max-model-len设置为 8192。虽然单次请求没有达到这个长度，但 KV Cache 预分配空间已经占满了全部显存，导致无法并发处理多个请求。
第四步，将max-model-len调整为 4096，同时限制 Dify 侧最大输出 Token 数为 512。重启 vLLM 容器后，并发能力明显提升，P95 延迟降到 5 秒以内，满足业务要求。
这个案例说明，大模型服务的性能问题通常不是单点原因，需要从请求长度、显存分配、并发模型、业务限制多个角度协同优化。
9. 运维配套与团队协作建议
9.1 建设模型运营管理制度
技术部署只是项目的第一步，后续的运营管理更为关键。高校环境的特点是使用者类型多样、需求变化频繁、预算规模有限，因此需要建立一套适合校内环境的模型运营制度。
建议由校网络信息中心牵头，设立“模型服务管理员”和“应用接入管理员”两个角色。模型服务管理员负责 GPU 服务器、推理框架、模型版本的日常运维，只有这个角色有权限登录 GPU 服务器和管理模型服务。应用接入管理员负责 Dify 平台上各业务部门的应用创建、知识库管理和资源配额分配，指导各院系自助搭建应用，而不是由信息中心包办所有需求。
在流程上，各院系提出接入申请后，应在 Dify 的隔离环境中先进行小范围测试，确认效果后再发布到生产环境，降低误操作影响。
9.2 模型版本与业务应用解耦
大模型迭代快，业务系统不能每次模型升级都跟着改代码。这就要求从一开始就设计好模型名与业务调用的关系。在 vLLM 启动参数中，--served-model-name指定的是对外暴露的模型名。当部署新版本模型时，可以启动一个新的 vLLM 实例，使用新的模型名，例如glm-chat-v2，在 Dify 中新增一个模型供应商配置，让测试人员在应用编排器里切换验证。验证通过后，再统一把生产应用的模型指向新版本。
采用这种灰度思路，可以避免“升级后效果不如预期”时无法快速回滚的问题。
9.3 项目交付文档清单
私有化部署项目验收时，建议交付的技术文档包括：
- 架构设计与网络拓扑文档。
- 服务器硬件清单与资源分配表。
- 模型部署手册与版本记录。
- Dify 平台使用手册与知识库维护规范。
- OnlyOffice 运维手册与备份恢复方案。
- 监控告警配置说明。
- 安全白名单和鉴权配置说明。
- 常见故障排查手册。
- 校方验收测试记录与性能压测报告。
这些文档是项目可持续运转的基础。如果只交付一个可运行的系统而没有任何文档，后续人员变动将带来极高的维护成本。
整个项目交付时，从 GPU 服务器上电、驱动安装、模型部署、Dify 应用编排到 OnlyOffice 文档协同，形成了一条完整可复用的链路。对高校和中小型组织来说，这种“大模型 + LLMOps 平台 + 在线文档”的私有化组合，可以花相对可控的成本，把大模型能力真正变成日常教学、科研与办公的基础设施。后续扩展的方向也清晰，比如增加语音识别服务、引入多模态模型、建设校级智能体广场，都只是在现有底座上继续叠加能力，不需要重新规划整体架构。如果你也在做类似的私有化部署项目，建议先把模型推理这层跑稳，再逐步叠加上层应用，这样每个阶段的收尾状态都是可测试、可交付的。
