企业级 RAG 智能知识库
私有化部署项目规划

主要有三个原因：

• 并发能力：Ollama 是单请求串行处理，并发高了响应慢。vLLM 的连续批处理（Continuous Batching）可以把多个请求动态合并成一个批次推理，吞吐量差距在高并发下能有5-10倍。
• 显存管理：vLLM 的 PagedAttention 把 KV Cache 做了分页管理，显存利用率更高，能支持更长的上下文而不OOM。
• 多卡支持：vLLM 原生支持张量并行，一行参数 tensor-parallel-size=2 就能把模型权重切到两张卡上，解决单卡显存不够的问题。Ollama 在多卡并行这块支持没那么完善。

分三个层面管理：

• 资源纳管：用 NVIDIA GPU Operator 自动安装驱动、CUDA、Device Plugin，不需要每个节点手动配置，集群扩容加GPU节点也很方便。
• 资源隔离：通过节点标签（node label）区分推理节点和向量化节点，再用 nodeAffinity 配置 Pod 的调度偏好，推理任务只调到推理节点，向量化任务只调到向量化节点，避免显存抢占。
• 资源配额：在 Pod 的 resources 里设置 nvidia.com/gpu: 1 或 2，K8s 会保证这个 Pod 独占对应数量的GPU，不会出现多个Pod争一张卡的情况。

我们遇到过这个问题，排查思路是：

• 定位问题层：先看是检索层的问题还是生成层的问题。把检索出来的文档片段直接展示出来，如果片段本身就不相关，是检索问题；片段相关但回答不对，是生成问题。
• 分段策略调优：chunk_size 太大上下文噪音多，太小语义不完整。我们针对不同文档类型（FAQ类、手册类）设置了不同的分段长度，FAQ用短分段，手册用长分段加overlap。
• 召回参数调整：Top-K 从默认3调到5-8，召回更多候选，再用 Reranker 重排序筛掉不相关的，召回率和精度都有提升。
• Embedding模型：换成 BGE-M3 替代默认模型，中文场景下检索相关性明显更好。

这是一个典型的企业生产环境选型问题，我们的考量是：

• vs RTX 4090：4090是消费级卡，功耗450W，7×24小时满载运行散热压力大，没有ECC内存纠错，长时间推理可能因内存错误崩溃，也没有企业级质保。A10功耗只有150W，企业级稳定性更可靠。
• vs A100：A100单张8-15万，我们3张A10的成本还不到一张A100，但对于500-1000人企业的并发量完全够用，A100的算力在这个场景下是浪费。
• A10的优势：24GB显存够跑14B模型双卡并行，功耗低、散热好、有企业质保，性价比在中小企业生产场景下最优。

• 3个Master节点：etcd 是奇数节点分布式存储，3个节点允许1个挂掉集群仍然正常工作。
• APIServer 高可用：用 keepalived + VIP 做虚拟IP漂移，任意一个Master挂掉，VIP自动漂移到其他Master，kubectl 和 Worker节点的连接不中断。
• etcd 备份：定期执行 etcdctl snapshot save 备份etcd数据，出现问题可以快速恢复。
• Worker节点的应用：K8s 会自动把故障节点上的 Pod 重新调度到其他健康节点，应用层自动恢复。

• 数据不出内网：整套系统部署在企业内网，vLLM、Milvus、Dify全部私有化，不调用任何外部API，从根本上杜绝数据外传。
• 访问控制：Nginx 层配置IP白名单，只允许内网IP段访问；外网员工必须先连VPN再访问。
• 镜像安全：所有镜像走私有 Harbor 仓库，不从公网拉取，避免镜像投毒风险。
• 存储隔离：Milvus 向量数据和原始文档存储在内网存储节点，配置 PVC 权限隔离，非授权 Pod 无法访问。

张量并行（Tensor Parallelism）是一种模型并行方式，把模型的权重矩阵按列或行切分到多张GPU上，每张GPU只保存一部分权重，推理时各卡并行计算再合并结果。

我们的场景：14B 模型 FP16 权重约 28GB（参数量 × 2 字节），单张 A10 只有 24GB 显存装不下，所以用 tensor-parallel-size=2 切到两张 A10 上，每张卡分到约 14GB 权重。

注意区分两个数字：14GB 是切分后的「权重显存」，但实际运行还要叠加 KV Cache 和激活值。我们设 gpu-memory-utilization=0.85，每卡实际占用约 20GB，剩下的显存留给 KV Cache 做并发缓存——这个余量直接决定能扛多少并发，不能拉满。

遇到过三个比较典型的难点：

• 难点1 – 显存OOM：初期推理和向量化服务部署在同一节点，高并发时显存被抢占导致推理服务OOM崩溃。解决方案是通过节点亲和性把两类任务调度到不同节点，彻底隔离显存资源。
• 难点2 – 检索准确率低：初期用默认分段策略，长文档切出来的片段语义不完整，召回质量差。通过调研不同文档类型，针对性调整chunk_size和overlap，加上Reranker重排序，准确率得到明显提升。
• 难点3 – Milvus集群模式部署复杂：Milvus依赖etcd和MinIO，初期配置不当导致集群启动失败。通过仔细研读官方文档、拆解各组件依赖关系，重新规划存储配置后解决。

PagedAttention 借鉴了操作系统的虚拟内存分页机制。

传统推理框架会为每个请求预分配一块连续的 KV Cache 显存，但请求的实际长度不固定，导致大量显存碎片浪费，真实利用率只有20-40%。

PagedAttention 把 KV Cache 切成固定大小的"页"，按需动态分配，不同请求的页可以不连续存放，显存利用率提升到接近100%。

结果是：同样的显存能并发处理更多请求，推理吞吐量大幅提升，高并发场景下效果特别明显。

核心区别在于检索方式不同：

• 普通数据库（MySQL等）：做精确匹配，用SQL查"标题='xxx'"或关键词like查询，找不到语义相近的内容。
• 向量数据库（Milvus）：把文本转成高维向量（embedding），存储向量。查询时把问题也转成向量，计算向量间的余弦相似度，返回语义最相近的文档片段，哪怕用词不同也能找到。

比如员工问"怎么请假"，文档里写的是"休假申请流程"，关键词搜不到，向量检索因为语义相似可以召回。这就是RAG必须用向量数据库的原因。

监控是这个项目我作为运维最核心的工作，分四层：

• 主机层：每个节点装 node-exporter，采集 CPU、内存、磁盘、网络。Prometheus 抓取，Grafana 出大盘。
• GPU 层：用 NVIDIA 的 dcgm-exporter（以 DaemonSet 跑在 GPU 节点上），采集显存占用、GPU 利用率、温度、功耗、ECC 错误。这是 nvidia-smi 拿不到的细粒度指标。
• K8s 层：kube-state-metrics + cAdvisor，监控 Pod 重启次数、容器资源用量、节点状态。
• 应用层：vLLM 本身暴露 /metrics 接口（Prometheus 格式），能拿到推理延迟、吞吐 token/s、KV Cache 利用率、排队请求数。Milvus 也有自己的 metrics 端点。

用 Prometheus 的 Alertmanager，告警分级推送（企业微信/钉钉机器人 + 邮件，紧急的电话）。几条核心规则：

• 显存告警：GPU 显存使用率 > 90% 持续 2 分钟，告警——可能要 OOM。
• 推理排队：vllm:num_requests_waiting > 20 持续 1 分钟，说明并发顶不住，提示扩容。
• Pod 重启：kube_pod_container_status_restarts_total 在 5 分钟内增长，说明服务在崩溃重启。
• 节点失联：up == 0 或 node NotReady，立即电话告警。
• 磁盘水位：存储节点磁盘 > 85%，提前清理（向量库和日志最容易撑爆）。

用 EFK 方案（K8s 里更常用 Fluent Bit 替代 Logstash，更轻量）：

• 采集：Fluent Bit 以 DaemonSet 部署在每个节点，挂载 /var/log/containers，自动收集所有 Pod 的 stdout/stderr 日志。
• 处理：Fluent Bit 解析日志、打上 K8s 元数据标签（namespace、pod、container），过滤掉无用的 health check 噪音。
• 存储检索：送进 Elasticsearch，按天建索引（方便定期清理冷数据），Kibana 做查询和可视化。
• 排查实战：推理服务报错时，直接在 Kibana 按 pod 名 + 时间范围过滤，比 kubectl logs 翻历史方便得多，尤其 Pod 重启后旧日志已经没了，集中收集就能回溯。

这是运维日常，我的标准排查流程：

按状态对症：

• Pending：调度不上去。常见原因——资源不够（GPU 被占满）、节点亲和性/污点不匹配、PVC 没绑定。describe 的 Events 会直接说。
• CrashLoopBackOff：容器启动后崩溃在重启。看 logs --previous，常见是配置错误、依赖服务连不上、OOMKilled（describe 看 Last State）。
• ImagePullBackOff：拉镜像失败。检查 Harbor 地址、imagePullSecret、镜像 tag 是否存在。
• OOMKilled：内存超 limit 被杀。调大 limit 或查内存泄漏。

K8s 网络排查从下往上分层定位：

• ① Pod 自己活着吗：kubectl get pod 看 vLLM Pod 是不是 Running、Ready 1/1。没 Ready 说明探针没过，服务没真正起来。
• ② Service 选对 Pod 了吗：kubectl get endpoints <svc> 看有没有后端 IP。空的说明 Service 的 selector 标签和 Pod 标签对不上——这是最高频的坑。
• ③ DNS 解析通吗：进一个 Pod 里 nslookup <service>.<namespace>，解析不了是 CoreDNS 问题。
• ④ 端口对吗：Service 的 targetPort 要和容器实际监听端口一致（vLLM 是 8000）。
• ⑤ 网络策略拦了吗：有没有 NetworkPolicy 把流量挡了。

有状态服务的数据必须持久化，不能存容器里（Pod 一重建就没了）。三个概念的关系：

• PV（PersistentVolume）：实际的存储资源，对应后端的一块磁盘/NFS/Ceph。
• PVC（PersistentVolumeClaim）：Pod 对存储的"申请单"，声明要多大、什么读写模式。
• StorageClass：动态供给的模板。配了 SC 后，创建 PVC 会自动生成对应 PV，不用手动建。

我们的方案：存储节点用 SSD，通过 StorageClass 做动态供给。Milvus、PostgreSQL 用 StatefulSet 部署（保证 Pod 名字稳定、PVC 一一对应），配 volumeClaimTemplates 自动给每个副本分配独立存储。

Nginx 在这套系统里干三件事：反向代理、负载均衡、访问控制。

RAG 应用层（Dify 自定义组件、配置）和一些工具镜像走 CI/CD，模型镜像因为大不频繁动。流程：

• ① 代码提交：开发推代码到 GitLab，触发 Jenkins Webhook。
• ② 构建：Jenkins Pipeline 拉代码 → docker build 打镜像 → 打 tag（用 git commit id 或时间戳，不用 latest，方便回滚）。
• ③ 推送：推到私有 Harbor 仓库。
• ④ 部署：kubectl set image 更新 Deployment 镜像，或改 manifest 后 apply，K8s 滚动更新。
• ⑤ 回滚：出问题 kubectl rollout undo 一键回退上个版本。

靠滚动更新 + 探针配合实现不中断：

• 滚动更新：Deployment 默认策略，逐个替换 Pod。配 maxSurge（最多多起几个）和 maxUnavailable（最多几个不可用），保证全程有可用副本。
• readiness 探针（就绪）：探针不过，Pod 不会被加进 Service endpoints，流量不会进来。新 Pod 必须 readiness 通过才接流量——这是不中断的关键。
• liveness 探针（存活）：探针不过，kubelet 直接重启容器。用来自愈卡死的服务。

etcd 是 K8s 的大脑，存了所有集群状态，必须备份。

• 本质区别：虚拟机虚拟化的是硬件，每个 VM 跑完整的操作系统内核，重；容器共享宿主机内核，只隔离进程和文件系统，秒级启动、资源开销小。
• 用容器的理由：环境一致性（镜像打包好依赖，开发测试生产一个样，杜绝"我机器上能跑"）、快速弹性扩缩容、K8s 统一编排调度、故障自愈。
• GPU 容器化：靠 NVIDIA Container Toolkit 把 GPU 设备透传进容器，配合 GPU Operator 在 K8s 里像调度 CPU 一样调度 GPU。

经典 Linux 性能排查，按 CPU → 内存 → 磁盘 → 网络 顺序定位：

• 多阶段构建：build 阶段装编译工具、编译，最终镜像只 COPY 产物，把编译环境甩掉，体积能降一大半。
• 选小基础镜像：能用 alpine / slim 就别用完整 ubuntu；Python 服务用 python:3.x-slim。
• 合并 RUN 层 + 清缓存：多条命令用 && 合并成一层，结尾清 apt/pip 缓存，减少镜像层和体积。
• .dockerignore：排除 .git、测试数据、文档，别打进镜像。
• 层缓存顺序：不常变的（装依赖）放前面，常变的（拷代码）放后面，最大化利用构建缓存。

• requests（请求）：调度依据。K8s 按 requests 找有足够空闲资源的节点放 Pod，是"保底预留"。
• limits（限制）：运行上限。容器用超 CPU limit 会被限流（throttle），用超内存 limit 会被 OOMKilled 杀掉。

设不好的后果：

• requests 设太低：节点超卖，实际跑起来资源不够，互相抢，服务卡顿。
• limits 设太低：内存稍微一涨就被 OOMKilled 反复重启。
• 不设 limits：单个 Pod 内存泄漏能拖垮整个节点上的其他服务。

按数据重要性和恢复成本分类备份：

• etcd（最高优先级）：集群状态，每天定时 snapshot，丢了整个集群配置就没了。
• 原始文档（MinIO/对象存储）：知识库的源文件，定期同步到另一台存储节点或离线介质。这是最该保的——向量库挂了能重新灌，原始文档丢了无法重建。
• Milvus 向量数据：配 PVC 持久化 + 定期备份索引。但即使丢了，有原始文档就能重新向量化，所以优先级低于原始文档。
• PostgreSQL（Dify 元数据）：pg_dump 定期逻辑备份，存了知识库配置、用户数据。
• K8s manifests / Helm values：全部进 Git 版本管理（GitOps 思路），集群重建能快速还原。

先定位瓶颈在哪，再决定怎么扩：

• ① 看监控判断瓶颈：vllm:num_requests_waiting 持续高 = 推理算力不够；GPU 利用率没满但延迟高 = 可能是 CPU/网络/向量检索拖累。先确认是 GPU 瓶颈再扩 GPU，别盲目加卡。
• ② 横向扩推理副本：加 GPU 节点，多起几个 vLLM 副本，Nginx 层 least_conn 负载均衡分流。这是最直接的水平扩展。
• ③ 提高单卡吞吐：调 vLLM 的 max-num-seqs（提高批处理并发）、gpu-memory-utilization（给 KV Cache 更多显存）。先榨干现有卡再加卡。
• ④ 优化检索链路：Milvus 加索引/副本，Embedding 服务扩副本。
• ⑤ 加缓存：高频重复问题用 Redis 缓存结果，直接命中不走推理，省算力。

这是个好问题，我的考量是高可用优先靠软件，而不是堆硬件冷备，原因有两点：

• 成本：500–1000人内部知识库，并发不高，再买一台带双 A10 的推理服务器(四五万)平时基本闲置，对中小企业不划算。钱应该花在刀刃上。
• 软件层已能覆盖大部分故障：真正高频的故障是进程崩溃、OOM、Pod 卡死，这些靠 K8s 就能自愈——liveness 探针自动重启、Pod 异常自动重新调度。硬件整机宕机是低频事件。

我实际的高可用设计：

• 推理服务跑成 Deployment 多副本(节点显存够时单机多实例)，配 readiness 探针，挂一个不影响整体接流量。
• 滚动更新 + rollout 历史，更新或回滚全程不中断。
• 监控告警盯着 Pod 重启和推理排队，异常第一时间介入。
• 真要做整机冗余，也是等业务量上来、SLA 要求提高后再横向加节点——架构上预留了扩展能力(Nginx upstream 加 server 就行)，但不在初期为小概率事件预付硬件成本。

• 网络隔离：用 NetworkPolicy 限制 Pod 间通信，比如只允许 Dify 访问 vLLM，数据库只接受应用层访问，最小权限。
• RBAC：给不同角色配最小权限的 ServiceAccount，运维、开发权限分开，不给所有人 cluster-admin。
• 镜像安全：全走私有 Harbor，开启镜像扫描（Trivy）查漏洞，不从公网拉镜像防投毒。
• Secret 管理：密码、密钥用 K8s Secret 存（不硬编码进镜像或 yaml），有条件接 Vault。
• 主机加固：关闭无用端口、SSH 禁 root 密码登录改密钥、定期打补丁、最小化安装。
• 入口控制：Nginx IP 白名单 + 外网 VPN，数据全程内网不出。

我负责的是基础设施和运维保障这条线（诚实界定范围，别什么都往身上揽，容易穿帮）：

• 集群搭建：kubeadm 搭 7 节点高可用 K8s，GPU Operator 纳管 GPU 资源，Harbor 私有仓库。
• 服务部署：容器化部署 vLLM、Milvus、Dify 等组件，配置调度、存储、网络。
• 稳定性保障：搭建 Prometheus+Grafana 监控、EFK 日志、告警体系，处理 OOM、调度、网络等线上问题。
• 持续运维：CI/CD 流程、备份容灾、扩容调优、安全加固。

量化价值（用相对值，别编绝对数字）：

• 系统可用性维持在 99% 以上，核心服务故障自愈。
• 通过节点隔离 + 监控告警，把推理服务 OOM 故障从频发降到基本消除。
• vLLM 调优后单卡并发吞吐相比初始配置提升明显（连续批处理 + KV Cache 优化）。
• 重复性问题答疑由系统自动承接，释放了人工支持的工作量。