# L2-08C 加餐：本地 RAG 量化、负载效率与企业级并发部署

> **课程定位**：承接 L2-08B 的“解析 → Chunk（把长文切成小段）→ Embedding（把文字变成可比较的数字）→ 混合检索（用多种方法一起找资料）→ Rerank（把找到的资料重新排队）→ 生成 → 评测”，进一步回答两个生产问题：一台本地设备怎样跑得稳、多人同时使用时怎样扩展且不形成单点故障。

## 课程导入：RAG 是什么，可以做什么

### 先想一个常见问题

你把公司的制度、课程资料、产品说明和客户项目文件放在电脑里，然后问 AI：

> “客户项目延期以后，应该按照什么流程汇报？”

普通大模型可能不知道你公司的内部流程。它只能根据以前学过的公开内容回答，有时还会把不确定的内容说得很像真的。

RAG 解决的就是这个问题：**先让 AI 去你指定的资料里找证据，再根据找到的证据回答。**

可以把它理解成两种考试：

| 回答方式 | 像什么 | 可能出现的问题 |
| --- | --- | --- |
| 普通大模型直接回答 | 闭卷考试，只能依靠以前记住的内容 | 不知道内部资料；资料可能过时；有时会猜答案 |
| RAG 回答 | 开卷考试，先翻指定教材，再写答案并标出页码 | 如果教材本身错误、搜索没找到正确段落，答案仍可能出错 |

### RAG 的全名不用死记

RAG 是 `Retrieval-Augmented Generation` 的缩写，中文常叫“检索增强生成”。

- **检索**：从资料库里搜索和问题最相关的内容。
- **增强**：把找到的资料交给 AI，补充它原本不知道的信息。
- **生成**：AI 根据问题和资料组织答案，并尽量给出来源。

一句话记忆：

> **RAG = 先找资料，再让 AI 根据资料回答。**

> **把 RAG 想成一位图书管理员**：你提出问题后，他不会凭记忆乱答，而是先跑到正确的书架，找出几页最相关的内容，放到桌上，再根据这些页面回答你，并告诉你书名和页码。

![RAG 四步流程：提问、查资料、选证据、带来源回答](插图素材/35_RAG是什么_四步流程_无字_001.jpg)

图中从左到右表示：

1. **提出问题**：用户输入自己真正想解决的问题。
2. **查找资料**：系统从 PDF、Word、Markdown 或知识库中寻找相关内容。
3. **挑选证据**：系统去掉不相关内容，把更有用的资料排在前面。
4. **组织答案**：AI 根据这些证据回答，并告诉用户答案来自哪里。

### RAG 可以做什么

| 场景 | 放入什么资料 | 可以向 AI 问什么 | 得到什么帮助 |
| --- | --- | --- | --- |
| 课程学习 | 讲义、书籍、课堂笔记、练习题 | “这节课的三个重点是什么？” | 总结、复习、出题，并找到对应章节 |
| 企业制度 | 员工手册、审批制度、报销流程 | “出差报销需要准备哪些材料？” | 根据当前制度回答并引用条款 |
| 产品客服 | 产品说明、常见问题、售后规则 | “这个错误代码应该怎么处理？” | 找到对应说明，生成客服答复草稿 |
| 项目管理 | 会议纪要、合同、计划、风险记录 | “项目延期会影响哪些里程碑？” | 汇总多个文件中的事实和风险 |
| 销售支持 | 产品资料、案例、报价规则 | “这个客户适合哪个方案？” | 找相关案例和产品信息，辅助准备方案 |
| 个人知识库 | 收藏文章、研究资料、工作记录 | “过去关于这个主题做过哪些决定？” | 从个人资料中找回历史信息 |

### RAG 在企业中一般做哪些工作

在企业里，RAG 通常不是一个只会聊天的机器人。它更像一名“数字资料助理”：每天接收新文件、整理资料、帮助员工查找信息、起草答案，并把使用反馈变成下一轮改进依据。

| 企业工作 | RAG 实际在做什么 | 给员工带来的帮助 | 必须由人负责什么 |
| --- | --- | --- | --- |
| 接收和整理资料 | 接收 PDF、Word、表格、扫描件；识别重复版本并建议分类 | 少做重复的搬运和归档工作 | 确认资料归属、保密级别和最终分类 |
| 建立企业知识库 | 解析文件、切成小段、生成向量并建立搜索索引 | 让大量资料变成“可以快速翻查的图书馆” | 决定哪些资料可以进入知识库 |
| 内部制度问答 | 从员工手册、流程和制度中找证据后回答 | 快速查询报销、请假、采购和审批要求 | 人事、财务等负责人确认正式规则 |
| 客服和售后辅助 | 查产品手册、故障案例和服务政策，生成回复草稿 | 客服更快找到处理办法，减少漏项 | 客服人员检查语气、承诺和特殊情况 |
| 销售与项目支持 | 跨合同、会议纪要、案例和产品资料做比较与总结 | 准备方案、风险清单和会议材料更快 | 负责人判断商业条件并批准对外内容 |
| 经验复用 | 从历史项目中找相似问题、解决办法和复盘记录 | 新员工不必从零开始摸索 | 专家判断旧经验是否仍适用于当前情况 |
| 质量持续优化 | 记录“有用 / 没用”反馈，找到漏检和错检案例 | 搜索结果会随着真实使用不断改善 | 业务人员提供真实问题并设定验收标准 |
| 权限、版本和审计 | 按部门过滤资料，记录谁问了什么、引用哪个版本 | 降低越权查看和引用过期资料的风险 | 管理员配置权限、保存期限和审计规则 |

企业中的日常工作循环可以记成五步：

1. **资料负责人上传文件**：例如新制度、产品手册或项目复盘。
2. **RAG 整理并建立索引**：像图书管理员给新书分类、贴标签并放上书架。
3. **员工用自然语言提问**：不用记住文件名和文件夹位置。
4. **系统查证据后回答**：答案旁边显示文件名、章节或页码。
5. **员工反馈结果是否有用**：系统据此调整切分、搜索和排序方法。

> **企业落地的关键**：AI 负责“搬资料、找资料、写草稿”，人负责“定权限、验事实、做决定”。涉及合同承诺、人事决定、财务付款、安全操作和对外发布时，不能只凭 RAG 自动完成。

### 本地 RAG 又是什么

“本地”表示资料解析、搜索、向量库和模型可以在自己的电脑或公司内网运行，资料不必发送到外部云服务。

它适合：

- 公司内部制度、合同和项目资料。
- 不方便上传公网的个人或客户文件。
- 需要断网使用的知识库。
- 希望自己控制模型、更新、权限和备份的团队。

但“放在本地”不等于自动安全。仍然需要设置账号权限、文件权限、日志、备份和人工确认。

### RAG 不是什么

- **不是把 PDF 整本塞进提示词**：资料太多会超过模型一次能读完的长度，也会浪费算力。
- **不是重新训练一个大模型**：大多数 RAG 项目只是建立可搜索的资料库，不需要从头训练模型。
- **不是百分之百正确**：资料错误、解析失败、搜索漏掉或模型理解错误，都可能影响答案。
- **不是资料越多越好**：重复、过期和没有权限标记的资料，会让结果更混乱。
- **不是完全无人管理**：分类、权限、质量抽查、坏例判断和正式发布仍需要人负责。

### 一套完整 RAG 在背后经历什么

```text
准备资料
  → 解析 PDF / Word / 图片
  → 清理重复、乱码和过期内容
  → 把长文切成小段
  → 把每段文字转换成向量
  → 保存到可以搜索的知识库
  → 用户提出问题
  → 找出相关资料并重新排序
  → AI 根据证据回答并给出引用
  → 用真实问题评测并持续优化
```

这节加餐后面的“量化、负载、并发和企业部署”，都是为了让这套流程在本地设备上跑得更省资源、更稳定，并能同时服务更多人。

## 一、学完这节课，你能做出什么

- 一张本地设备容量表：模型、上下文、并发数、内存 / 显存和目标延迟。
- 一份量化决策：哪些组件可以量化，精度下降是否在可接受范围内。
- 一套单机 RAG 服务：有队列、限流、超时、降级、健康检查和监控。
- 一套忙时 / 闲时调度规则：在线任务保响应，后台归档任务可抢占、可断点。
- 一张当前本地模型参考表：Embedding、Reranker、生成模型和热 / 温 / 冷归档策略。
- 一张企业级部署图：入口、检索、推理、数据和监控均有冗余，不依赖单台机器。
- 一份压测与验收记录：用数据决定并发上限，不凭“感觉很快”。

### 本课技术词“人话翻译”

第一次读时，可以把下面这些技术词直接替换成右侧的话。后文再次出现时，不再重复写长解释。

| 技术词 | 初中生也能懂的解释 |
| --- | --- |
| RAG | AI 回答前先去指定资料库找证据，再根据证据回答，像“开卷考试”。 |
| LLM / 大语言模型 | 负责读文字、理解问题和组织答案的 AI 模型。 |
| 量化 / Q4 / Q8 | 把模型里的数字记得更简略，让它占更少内存；Q4 更省，Q8 通常更接近原模型。 |
| token | AI 读写文字时使用的小单位，一个汉字有时约占一个或多个 token。 |
| 上下文 | 这一次提问时，AI 能同时看到的问题、资料和历史对话。 |
| Chunk | 从长文档中切出来的一小段，方便搜索和引用。 |
| Embedding / 向量 | 把一段文字转换成一串数字；意思越接近，两串数字通常越接近。 |
| Dense 检索 | 按“意思像不像”找资料，例如“退款”和“退费”也可能被认为相近。 |
| Sparse / BM25 检索 | 按关键词是否出现来找资料，特别适合编号、名称、型号和精确词。 |
| Reranker | 把第一轮找到的资料再精读一次，重新排出更可靠的前几名。 |
| Top-K | 搜索后先取前 K 条结果；Top-10 就是先看最相关的 10 条。 |
| Recall@K | 正确资料有没有出现在前 K 条里；越高说明越不容易漏掉。 |
| KV Cache | 模型生成答案时使用的“临时记忆区”，对话越长、同时回答的人越多，占用越大。 |
| batch / 批处理 | 把多个小任务凑成一批一起算，像一次洗一桶衣服，而不是一件一件洗。 |
| 并发 / slots | 同一时间有多少任务正在处理；slot 可以理解成模型的“服务窗口”。 |
| TTFT | 从点击发送到 AI 出现第一个字的等待时间。 |
| TPOT / tokens/s | AI 开始回答以后，后面的字出来得快不快。 |
| p95 | 100 次请求里，大约有 95 次不会比这个时间更慢，用来观察大多数人的真实体验。 |
| QPS / RPM | 每秒 / 每分钟来了多少个请求，表示系统有多忙。 |
| 背压 | 系统忙不过来时，让新任务排队或稍后重试，而不是继续硬塞直到崩溃。 |
| 降级 / 熔断 | 某个高级功能出问题时改用简单方案，或暂时停止调用故障服务。 |
| 影子索引 | 在不影响旧知识库的地方先建一套新版，测试通过后再切换。 |
| collection / alias | collection 是一套向量资料；alias 是指向当前正式版本的“快捷名称”。 |
| ACL | 谁能看哪些资料的权限名单。 |
| SLO | 系统答应达到的服务目标，例如“95% 的请求在 3 秒内开始回答”。 |
| RPO / RTO | RPO 是最多允许丢多久的数据；RTO 是故障后最多允许多久恢复。 |
| HNSW | 向量数据库为了更快找相似资料而建立的“近路地图”。 |
| CPU / GPU | CPU 像通用员工，什么都能做；GPU 像大量并排的计算员工，特别适合模型计算。 |
| RAM / VRAM | RAM 是整台电脑的工作台；VRAM 是显卡自己的高速工作台。 |
| FP16 / INT8 / INT4 | 保存模型数字的精细程度；数字越小越省空间，但可能损失质量。 |
| GGUF / AWQ / GPTQ | 不同的本地模型压缩和保存格式；选哪种取决于设备与推理软件。 |
| ONNX | 一种方便模型在不同设备和软件中运行的通用格式。 |
| OCR | 把扫描图片里的文字识别成可搜索文本。 |
| API / API Gateway | API 是软件之间说话的接口；Gateway 是统一接待、鉴权和限流的前台。 |
| Load Balancer / LB | 负载均衡器，把请求分给多台机器，避免所有人都挤到一台。 |
| 副本 / 分片 | 副本是多存一份防故障；分片是把大知识库分成几块分别保存。 |
| 无状态服务 | 服务本身不独占用户记录，换一台相同服务也能继续处理请求。 |
| Kubernetes / Pod / HPA | Kubernetes 管理许多服务；Pod 是一个运行单元；HPA 会根据忙闲自动增加或减少 Pod。 |
| 租户 | 共用一套系统的不同公司、部门或客户，彼此资料和配额需要隔离。 |
| 快照 | 某个时间点的完整备份，出问题时可以恢复。 |
| 幂等 | 同一个任务重复执行，也不会产生重复资料或破坏结果。 |

### 贯穿全课的比喻地图

| 技术概念 | 可以想成什么 |
| --- | --- |
| Chunk | 把一本很厚的书做成一张张知识卡片；每张卡片要保留标题和页码，不能剪成看不懂的碎纸。 |
| Embedding | 把所有知识卡片放到一张“意思地图”上；意思接近的卡片会住在同一个街区。 |
| Dense + Sparse | Dense 像按意思问图书管理员；Sparse 像拿着准确书名、编号去查目录。两种方法一起用更稳。 |
| Reranker | 第一位同学先拿来一叠可能相关的资料，第二位老师再认真检查，把最有用的几张放到最上面。 |
| 量化 | 像把冬天的大棉被压进真空袋，变小以后更容易放进行李箱，但压得太狠可能让细节变差。 |
| KV Cache | 像做题时的草稿纸；题目越长、同时做题的人越多，需要的桌面和草稿纸越大。 |
| batch | 像校车凑齐一批学生一起出发，比每个学生单独叫一辆车更省资源。 |
| 并发 slots | 像食堂的打饭窗口；窗口越多，同时服务的人越多，但每个窗口都要占用工作人员和空间。 |
| 背压 | 像热门餐厅先发号码牌；厨房忙不过来时先排队，而不是让所有人一起冲进厨房。 |
| 影子索引 | 像演出前在排练厅搭一套新舞台，确认没问题后，才把正式舞台切换成新版。 |
| 副本与分片 | 副本像同一本书在不同分馆各放一本；分片像把一套百科全书分别放在几个书柜。 |
| RPO / RTO | 像游戏存档：RPO 决定最多退回多久以前的存档，RTO 决定坏掉后多久能重新进入游戏。 |

---

## 二、先分清三种“量化”

本地 RAG 里至少有三类量化（把数字用更省空间的方式保存），它们优化的对象不同，不能只说“把模型改成 4 bit”。

| 位置 | 量化对象 | 主要收益 | 主要风险 | 先验证什么 |
| --- | --- | --- | --- | --- |
| 生成模型 | LLM 权重、激活、KV Cache（生成时的临时记忆区） | 降低模型常驻内存，让更大模型或更多并发进入设备 | 回答质量、长上下文稳定性、工具调用格式可能下降 | 业务测试集通过率、首字延迟、输出速度 |
| Embedding / Reranker | 编码器权重与推理精度 | 提高批处理吞吐（单位时间完成的任务量），降低嵌入与重排服务占用 | 相似度排序和召回率下降 | Recall@K（正确资料是否进入前 K 条）、MRR / nDCG（正确资料排得是否靠前）、任务命中率 |
| 向量数据库 | 已存向量的 Scalar / Product / Binary Quantization | 降低向量内存和磁盘占用，提高缓存命中与扫描速度 | 近邻排序发生偏移，需要原向量重打分 | Recall@K、p95 检索延迟、索引体积 |

### 量化选择的实用顺序

1. 先建立 FP16 / BF16 或原始向量的质量基线。
2. 优先试风险较低的权重量化或向量 Scalar INT8。
3. 如果仍放不进设备，再试 Q5 / Q4、量化 KV Cache或更激进的向量压缩。
4. 每改一项只做一次变量变化，跑同一套真实业务题。
5. 只有“质量过线 + p95 延迟过线 + 峰值内存安全”才进入生产。

> **关键判断**：量化不等于一定更快。格式与硬件内核不匹配时，虽然模型更小，反量化开销或内存搬运仍可能让延迟变差。最终结论必须来自目标设备上的压测。

> **生活比喻**：把高清照片压缩成小图片，文件会变小、传得更快，但压缩太狠就看不清细节。模型量化也是一样：省下的内存和速度，必须拿真实问题检查有没有损失重要信息。

---

## 三、显存 / 内存怎样估算

### 1. 模型权重的粗估

```text
权重占用 ≈ 参数量 × 每参数 bit ÷ 8 × 运行时系数
```

运行时系数可先按 `1.10～1.25` 做规划，用来容纳元数据、量化分组和运行时开销。例如 8B 模型采用 4 bit，裸权重约 4 GB，但不要把“4 GB 模型文件”等同于“只需要 4 GB 内存”。

### 2. KV Cache（模型的临时记忆区）是并发时最容易漏算的部分

```text
单请求 KV Cache（近似）
≈ 2 × 层数 × KV heads × head_dim × 上下文 token 数 × 每元素字节数
```

具体值受模型结构、GQA / MQA、KV 数据类型、分页缓存和推理框架影响，应以服务启动日志和监控数据校准。上下文从 4K 增至 16K，KV 占用通常也会接近线性增加；并发会让多条活动序列共同占用 KV 空间。

> **生活比喻**：KV Cache 就像桌上的草稿纸。一个人做一道短题，只需要一小块；四个人同时做长题，就需要四张更大的桌子。电脑内存不够时，不是大家“挤一挤”就行，而是会明显变慢甚至停下来。

### 3. 整机安全预算

```text
总占用 ≈ 模型常驻 + 活动请求 KV + 批处理工作区
       + Embedding / Reranker + 向量索引 + 服务进程 + 操作系统预留
```

课堂起始建议（是容量规划经验值，不是硬性标准）：

- 统一内存或 RAM 长时间稳定运行时，先把目标峰值控制在物理内存的 70%～80%。
- 独立 GPU 显存先把目标峰值控制在 85%～90%，为突发批次、驱动和内存碎片留余量。
- 如果模型、向量库和业务程序共用一台机器，必须按“同时峰值”计算，不能分别看都没超限。
- 先降低上下文、活动槽位或批量大小，再考虑让系统使用交换空间；频繁 swap 往往意味着容量设计已经失败。

### 4. 本地设备选型参考

| 设备与场景 | 建议起点 | 并发策略 | 不建议做法 |
| --- | --- | --- | --- |
| 16 GB Apple Silicon / 个人知识库 | 3B～8B 的 Q4 / Q5；Embedding 单独小批处理 | 生成活动槽位从 1 开始，检索可并发 2～4 | 一开始就开 16K/32K 上下文和多个生成槽位 |
| 32～64 GB Apple Silicon / 小团队 | 7B～14B 的 Q4 / Q5，视质量测试选型 | `llama-server` 从 2～4 slots（同时服务窗口）压测，入口队列限长 | 只看模型能加载，不测多人长回答 |
| 单张 16～24 GB NVIDIA GPU | AWQ / GPTQ / FP8 等须先核对 GPU 和推理框架兼容表 | vLLM 连续批处理；以活动 token 和 KV 使用率限流 | 因为量化更小就盲目复制多个模型实例 |
| CPU 服务器 / 内网轻负载 | GGUF Q4～Q8；Embedding 使用 ONNX / CPU 优化 | 控制线程数，避免推理与向量索引争抢全部核心 | 把线程数直接设成逻辑核心数并无限接收请求 |

以上范围只是压测起点，最终模型大小和并发数由业务质量门槛、上下文长度和目标 SLO（系统承诺达到的服务目标）决定。

---

## 四、并发不是一个数字，而是四层负载

```text
用户请求
  → 入口并发（鉴权、限流、排队）
  → 检索并发（解析、Embedding、向量/BM25、Rerank）
  → 生成并发（活动序列、连续批处理、KV Cache）
  → 后台并发（文档导入、重建索引、备份、评测）
```

### 1. 先定义四个指标

| 指标 | 含义 | 为什么重要 |
| --- | --- | --- |
| QPS / RPM（每秒 / 每分钟请求量） | 单位时间进入多少请求 | 决定入口压力，但不能单独代表推理压力 |
| TTFT（等到第一个字的时间） | 从请求到首个 token 的时间 | 直接反映排队、Prefill（先读完问题和资料）和检索体验 |
| TPOT / tokens/s（开始回答后的输出速度） | 每个后续 token 延迟或生成速度 | 反映 Decode（逐步生成答案）阶段体验 |
| p95 / p99 总延迟（绝大多数人的最慢体验） | 95% / 99% 请求完成需要多久 | 平均值会掩盖峰值拥堵 |

估算所需并发槽位可先用 Little's Law：

```text
所需在途并发 ≈ 到达率（请求/秒）× 平均处理时间（秒）
```

例如平均每秒 0.5 个请求、一次请求平均占用 12 秒，则系统平均约有 6 个在途请求。但“在途”不等于 6 个都必须同时生成，可以让 2～4 个活动生成，其余进入有上限的等待队列。

> **生活比喻**：食堂来了 20 名学生，并不需要马上开 20 个打饭窗口。可以开 4 个窗口稳定服务，其余学生排队；如果队伍太长，就提前告诉后来的人稍后再来。

### 2. RAG 每层的并发原则

- **Embedding**：短输入适合微批处理；设置很小的聚合窗口，凑批提高吞吐，但不能让等待凑批拖慢 TTFT。
- **向量检索**：限制单请求 `top_k`、过滤范围和超时；索引线程不能吞掉生成所需的全部 CPU。
- **Rerank**：候选数从“够用”开始，例如先取 20～50 条再重排到 5～10 条；候选越多不一定越准确，却会线性增加推理量。
- **LLM Prefill（模型先读完问题和资料）**：长上下文最吃瞬时算力和缓存；应限制最大输入 token，并对超长文档先摘要或分阶段处理。
- **LLM Decode（模型逐步生成答案）**：连续批处理能共享一次解码调度，但活动序列太多会让单用户 tokens/s 下降。
- **文档导入**：与在线问答分队列、分资源配额；重建索引最好安排在低峰或使用影子索引（在旁边先建新版）后原子切换（一次完成新旧替换）。

### 3. 背压（忙不过来就排队）与降级（高级功能失败就用简单方案）规则

一个稳定的本地服务一定会说“现在太忙”，而不是无限堆积直到崩溃。

> **生活比喻**：背压像餐厅取号，降级像招牌菜卖完后改为供应简单套餐，熔断像发现煤气故障后先关闭厨房。它们的目的不是“少服务”，而是避免整个系统一起出事故。

| 触发条件 | 推荐动作 |
| --- | --- |
| 活动生成槽位已满 | 新请求进入有界队列，不直接创建更多推理任务 |
| 队列超过长度或等待超时 | 返回 429 / 503 和 `Retry-After`，记录拒绝次数 |
| KV Cache 或显存达到高水位 | 暂停接收长上下文；降到短上下文或小模型路由 |
| Reranker 超时 | 降级为混合检索排序，并在响应元数据标记降级 |
| 向量库不可用 | 对低风险场景降级到本地 BM25；高风险场景停止回答 |
| 生成服务异常 | 熔断（暂时停止调用故障服务）、健康探测，切换备份实例或返回“稍后重试” |

---

## 五、工作忙时与闲时：让同一套算力更有效

本地设备不应该全天按同一种负载运行。更有效的方式是把任务分成三个优先级，再用“业务时段 + 实时资源水位”共同调度。

| 优先级 | 任务 | 忙时策略 | 闲时策略 |
| --- | --- | --- | --- |
| P0 在线交互 | 用户问答、检索、权限校验、流式生成 | 保证 TTFT 和 p95；预留推理槽位；必要时拒绝低优先级请求 | 正常服务，允许更长上下文或高质量模型 |
| P1 近线任务 | 报告生成、批量摘要、评测、低优先级 Agent | 限制并发、缩短上下文、进入队列或暂停 | 提高批量与并发，利用连续批处理吃满设备 |
| P2 后台任务 | 文档解析、Embedding、索引重建、压缩、备份 | 可抢占、可断点；只使用剩余资源 | 全速执行，完成索引优化、快照和质量回归 |

### 忙时：优先稳定响应

- 给 P0 预留固定生成槽位和 KV Cache，不让批量归档挤占在线问答。
- 文档导入、全量重嵌入、HNSW（向量搜索使用的近路地图）重建和大规模评测进入低优先级队列。
- 限制最大输入 / 输出 token、`top_k`、Rerank 候选数和活动序列数。
- 普通问答路由到较小模型或非思考模式；只有复杂任务才升级到大模型。
- 队列达到高水位后先暂停 P2，再压低 P1；不要牺牲 P0 后仍继续接收无限请求。
- 对本地统一内存设备，Embedding、Rerank 和 LLM 不要同时抢满内存带宽。

### 闲时：把空闲算力转换成可复用资产

- 批量解析新文档、补 OCR、生成 Embedding，并使用更大的 batch 提高吞吐。
- 构建影子索引（在旁边先建一套新版），跑完评测后再切换 alias（正式知识库使用的快捷名称），不在原索引上边改边用。
- 运行量化前后回归测试、召回评测、坏例聚类和提示词评测。
- 做向量库压缩 / 优化、快照、原文校验、去重和过期数据清理。
- 预热次日需要的模型与常用 Prompt Cache，避免早高峰冷启动。
- 下载模型或重建大索引应设置带宽、磁盘 IOPS 和温度 / 功耗上限，不能只追求 GPU 100%。

### 不只看时间，还要看实时水位

```text
进入忙时保护：
  在线队列最老等待 > 2s
  OR TTFT p95 连续 3 个窗口超标
  OR KV / VRAM > 80%
  OR 在线活动槽位使用率 > 75%

退出忙时保护：
  以上指标连续 10～15 分钟回落
  AND 无高优先级积压
```

阈值只是课堂起点，必须用目标设备压测校准。进入和退出条件要采用不同阈值与稳定窗口，避免任务在忙 / 闲模式之间反复抖动。

### 可抢占后台任务必须满足四个条件

1. **小批次**：每批文档或 Chunk 能在短时间内完成。
2. **有检查点**：记录 `doc_id`、版本、最后完成批次与索引目标。
3. **幂等**：同一批次重跑不会产生重复向量或破坏线上索引。
4. **可取消**：在线高水位出现时，能在当前小批结束后释放 GPU、CPU 和内存。

### 忙闲资源配额参考

| 资源 | 忙时 | 闲时 | 说明 |
| --- | ---: | ---: | --- |
| LLM 在线推理 | 60%～80% | 20%～60% | 忙时为交互保留，闲时可借给评测和批量生成 |
| Embedding / Rerank | 10%～25% | 40%～80% | 忙时小批低延迟，闲时大批高吞吐 |
| 文档解析 / OCR | 0%～15% | 50%～90% CPU | 在线拥堵时可完全暂停 |
| 索引构建 / 优化 | 仅增量 | 使用剩余 IOPS | 全量重建必须走影子索引 |
| 内存 / 显存余量 | 至少 20% | 至少 10%～15% | 闲时也必须为突发请求和运行时波动留空间 |

百分比表示容量规划目标，不是所有设备都能严格切分。macOS 统一内存应重点观察系统 memory pressure 与 swap；独立 GPU 应同时观察显存、KV Cache、功耗和温度。

> **生活比喻**：忙时像学校午餐时间，厨房优先出餐，不安排大扫除；闲时像放学以后，再集中清洗设备、盘点仓库和准备第二天的食材。算力也应该把重任务安排到空闲时间。

---

## 六、当前向量化、归档与可本地化模型参考

> **更新日期：2026-07-22。** 模型版本、推理框架兼容性和许可条款会变化，部署前必须复核官方模型卡，并用自己的中文业务评测集比较。

### 1. 向量化 / Embedding 模型

| 模型 | 规模与上下文 | 向量维度 | 中文与能力特点 | 本地设备起点 | 推荐场景与注意点 |
| --- | --- | ---: | --- | --- | --- |
| `Qwen/Qwen3-Embedding-0.6B` | 0.6B；32K | 32～1024，支持 MRL（可缩短向量长度） | 100+ 语言、长文本、代码、指令感知 | 16 GB RAM / 统一内存可作为测试起点；GPU 更适合批量 | 当前中文本地 RAG 的优先候选；先用 512 / 768 / 1024 维做质量与存储对照 |
| `Qwen/Qwen3-Embedding-4B` | 4B；32K | 最高 2560，支持 MRL | 更高质量档，支持任务指令 | 建议 32 GB+ 或独立 GPU，从低并发开始 | 高价值知识库、代码与跨语言检索；不要只因维度高就直接全量使用 |
| `Qwen/Qwen3-Embedding-8B` | 8B；32K | 最高 4096，支持 MRL | 系列质量优先档 | 建议服务器 GPU 或 64 GB 级设备评测 | 适合质量收益能够覆盖成本的项目；向量体积和重建时间显著增加 |
| `BAAI/bge-m3` | 约 0.6B；8192 | 1024 | 多语言；统一 Dense、Sparse、ColBERT 多向量能力 | 16 GB 级设备可测试，批量生产优先 GPU | 需要一套模型同时实验稠密、稀疏与多向量检索时很实用 |
| `Alibaba-NLP/gte-multilingual-base` | 305M；8192 | 128～768 | 70+ 语言；Encoder-only；支持弹性 Dense 与 Sparse | CPU / 16 GB 设备的轻量候选 | 资源有限、需要较高 Embedding 吞吐时优先对照；使用自定义代码前做安全审查 |

#### 维度怎么选

- 同一模型先用 256 / 512 / 768 / 1024 等受支持维度跑 Recall@K 和业务问答通过率。
- 维度减半通常近似减少一半原始向量存储，但实际索引还包含图结构、payload 和元数据。
- 变更模型、维度、归一化方式或指令模板，都应创建新 collection（一套独立向量资料）并全量重嵌入，不能把新旧向量混在同一空间。

### 2. Reranker 模型

| 模型 | 规模与上下文 | 本地化特点 | 推荐用法 |
| --- | --- | --- | --- |
| `Qwen/Qwen3-Reranker-0.6B` | 0.6B；32K；100+ 语言 | Apache-2.0；可本地部署；支持任务指令 | 中文 / 代码 / 长文本优先候选；先将混合检索 Top-20～50 重排到 Top-5～10 |
| `Qwen/Qwen3-Reranker-4B/8B` | 4B / 8B；32K | 质量档更高，计算和显存成本明显增加 | 只用于高价值或困难查询，忙时可路由回 0.6B |
| `BAAI/bge-reranker-v2-m3` | 约 0.6B；最长约 8192 | Apache-2.0；多语言；成熟轻量 | 资源有限或已有 BGE-M3 管线时的稳健候选 |

Reranker（重新排序模型）不负责生成向量归档，而是对“查询—候选文档对”直接打相关性分。它通常比继续扩大向量 `top_k`（多取更多条）更有效，但候选数会直接影响耗时，因此很适合忙闲动态路由。

### 3. 可本地化生成模型

| 模型 | 规模 / 上下文 | 本地格式与授权 | 设备起点（Q4 仅作估算起点） | 适合角色 |
| --- | --- | --- | --- | --- |
| `Qwen/Qwen3-4B` | 4B；原生 32K | Apache-2.0；可用 GGUF 等本地格式 | 16 GB 设备先测 1～2 活动槽位 | 忙时默认问答、摘要、轻量 Agent |
| `Qwen/Qwen3-8B` | 8.2B；原生 32K | Apache-2.0；官方有 GGUF / FP8 等版本 | 16～32 GB 设备从 Q4、短上下文、单并发开始 | 中文 RAG 主模型；质量与本地成本较平衡 |
| `Qwen/Qwen3-14B` | 14.8B；原生 32K | Apache-2.0；支持本地推理框架 | 32～64 GB 或服务器 GPU 起步 | 闲时高质量报告、复杂推理和重要任务升级路由 |
| `openbmb/MiniCPM4-8B` | 8B；面向端侧效率 | Apache-2.0；官方提供 GGUF、vLLM / SGLang 路径 | 16～32 GB 设备做 GGUF Q4 实测 | 中文端侧与高效率备选，适合与 Qwen3-8B 对照 |
| `google/gemma-3-4b-it` | 4B；128K；多模态 | 可本地运行，但需接受并复核 Gemma 使用条款 | 16 GB 设备从短上下文开始 | 需要图文输入、多语言和轻量生成时对照；中文专项必须实测 |

设备起点不是保证值。实际占用由量化格式、上下文、KV 类型、batch、并发和推理框架共同决定；即使模型支持 32K / 128K，也不代表本地生产应默认开放最大上下文。

### 4. 向量归档不是只保存向量

| 层级 | 保存内容 | 存储位置 | 何时使用 | 恢复方式 |
| --- | --- | --- | --- | --- |
| 热数据 | 当前原文、Chunk、向量、Sparse、payload（跟随资料保存的附加信息）、ACL（访问权限名单） | 在线向量库 SSD / 内存缓存 | 日常在线检索 | 直接查询，保持副本与快照 |
| 温数据 | 上一版本 collection、量化向量、索引快照、评测结果 | 本地大盘 / NAS / 对象存储 | 回滚、低频历史查询 | 恢复快照或临时挂载只读实例 |
| 冷数据 | 原始文件、解析结果、Chunk 清单、内容 hash、模型与指令版本 | 版本化对象存储 + 离线 / 异地备份 | 审计、灾备、重新建库 | 重新解析或从中间产物重建向量 |

必须归档的版本字段：

```yaml
embedding_model:
model_revision:
embedding_dimension:
normalize_embeddings:
query_instruction_version:
chunker_version:
corpus_version:
vector_quantization:
collection_or_alias:
created_at:
content_hash:
```

> **原则**：原文、结构化 Chunk 和版本配置是主资产；向量与 HNSW 等索引是可重建派生物（可以根据原文重新制作的内容）。只备份向量、不备份原文和模型版本，不能算可恢复的归档。

> **生活比喻**：原文像课本原件，Chunk 和向量像你做的目录卡与索引。目录卡丢了还能根据课本重做；如果只留下目录卡、把课本丢了，就无法真正恢复知识库。

### 5. 一套适合课程演示的默认组合

| 档位 | Embedding | Reranker | 生成模型 | 适用设备与策略 |
| --- | --- | --- | --- | --- |
| 轻量个人版 | `gte-multilingual-base` 或 `Qwen3-Embedding-0.6B` | 可先不启用 / `bge-reranker-v2-m3` | `Qwen3-4B` Q4 | 16 GB；生成并发 1；归档放闲时 |
| 中文质量平衡版 | `Qwen3-Embedding-0.6B` 768 / 1024 维 | `Qwen3-Reranker-0.6B` | `Qwen3-8B` Q4 / Q5 | 32 GB 或单 GPU；忙时小模型路由，闲时批量重排评测 |
| 部门生产版 | `Qwen3-Embedding-0.6B/4B` 对照后定型 | 0.6B 默认，4B 只处理困难查询 | `Qwen3-8B` 主池 + `Qwen3-14B` 高质量池 | 服务池分离；在线和归档队列隔离；影子索引切换 |

---

## 七、普通用户场景：从批量文档到知识库的完整 AI 工作流程

真实业务通常不是“准备好一份干净 Markdown”，而是一次丢入多个 PDF、Word、扫描件和历史版本。学员需要理解：文件进入系统后，不是立刻“喂给大模型”，而是经过一条可检查、可评测、可回退的工程链路。

```text
批量拖入文件
  → 安全扫描 / OCR / 版面解析
  → AI 建议分类、标签、知识库和权限
  → 人工确认低置信度与敏感资料
  → Chunk 预览与解析质量抽查
  → 构建影子索引
  → 用真实问题做 A/B 召回实验
  → 反馈相关 / 不相关
  → 达到门槛后切换生产 alias
```

### 1. 六个必须理解的处理阶段

| 阶段 | AI / 系统做什么 | 人负责什么 | 必须阻止什么 |
| --- | --- | --- | --- |
| 1. 文件接收 | 登记文件、去重、病毒扫描、识别格式和语言 | 确认资料来源、所有者和允许用途 | 加密、损坏、恶意或来源不明文件直接进入知识库 |
| 2. 分类与权限 | 建议分类、标签、目标知识库、ACL（谁可以查看）、保留期限和置信度 | 确认低置信度、敏感资料、跨部门资料和历史版本 | AI 单独决定财务、人事、合同等资料权限 |
| 3. 解析与清洗 | PDF / DOCX 解析、OCR、表格恢复、页眉页脚清理 | 抽查原文与解析结果，处理乱码、漏页和表格错位 | 解析质量未通过就继续向量化 |
| 4. Chunk 与向量化 | 按结构切块、补元数据、生成 Dense / Sparse 向量 | 选择拆分规则，检查标题路径、页码和上下文是否保留 | 新旧模型、维度或 Chunk 版本混入同一向量空间 |
| 5. 检索与生成 | ACL 过滤、召回、融合、Rerank、上下文装配、生成与引用 | 用真实问题判断证据是否正确，确认高风险回答 | 只看最终答案、不检查原始召回证据 |
| 6. 评测与发布 | 比较基线和候选、构建影子索引、记录版本和指标 | 决定发布、继续优化或回滚 | 未通过质量、权限和恢复测试就覆盖生产索引 |

### 2. 分类不是让 AI 自己决定

推荐使用“建议 + 置信度 + 人工确认”：

- 高置信度、低敏感、规则明确的文件可以批量确认。
- 文件名模糊、跨多个主题、合同 / 财务 / 人事、权限不清的资料必须逐项确认。
- AI 同时建议 `category`、`tags`、`target_kb`、`acl`、`retention`，但每个字段都应可编辑。
- 同一文档检测到旧版本时，界面应显示 diff、来源和更新时间，让用户选择替换、并存或暂存。
- 分类规则和人工修改要留下审计记录，后续可用于优化分类提示词或训练轻量分类器。

### 3. 召回优化必须做 A/B 对照

```text
固定：同一批文档 + 同一组问题 + 同一权限身份
改变：每轮只改一个变量
比较：Recall@K（有没有漏掉正确资料）、MRR/nDCG（正确资料排得够不够靠前）、p95（大多数人的最慢体验）、Top-K 证据、最终回答
决定：保存为候选 / 设为新基线 / 放弃并记录原因
```

评测中每条召回结果都应记录“相关 / 不相关 / 应排更高 / 权限错误 / 版本过期”。反馈不能只变成主观评价，而要形成带 `query_id`、`chunk_id`、配置版本和评测人的测试记录。

### 4. 一次问答背后的完整 AI 协作链

| 工作层 | 典型输入 | 典型输出 | 失败时先查什么 |
| --- | --- |
| 资料层 | PDF、Word、扫描件、Markdown | 可追溯原文、解析文本、文档元数据 | 来源、版本、权限、OCR / 解析质量 |
| 检索层 | 用户问题、身份、过滤条件 | Top-K Chunk、相关分数、来源和版本 | ACL、Chunk、Embedding、Sparse、融合与 Rerank |
| 生成层 | 问题与检索上下文 | 带引用的回答、拒答或人工确认请求 | 上下文是否正确、提示词、生成模型与引用验证 |
| 评测层 | 问题集、相关文档、预期行为 | Recall@K、MRR、Groundedness（回答是否真的有资料依据）、坏例清单 | 测试集是否覆盖真实问题和风险场景 |
| 运维层 | 日志、指标、版本、快照 | 更新、告警、回滚、容量和审计记录 | 队列、资源水位、索引健康、模型版本和恢复流程 |

### 5. 学员应该记住的完整闭环

```text
业务资料进入
  → AI 辅助分类与解析
  → 人确认知识边界和权限
  → 系统切块、向量化并建立索引
  → 用户问题触发检索、重排和生成
  → 人用真实问题反馈召回质量
  → 系统形成评测集并优化参数
  → 候选索引通过验收后发布
  → 持续监控、增量更新和必要时回滚
```

这条链路的核心不是“让 AI 自动做完”，而是让 AI 负责高频处理，让人负责资料边界、权限、坏例判断和发布决策。

> **生活比喻**：AI 像认真但经验不足的图书助理，擅长搬书、分类和初步查找；人像负责老师，决定哪些书能公开、判断资料是否正确，并在正式发布前签字。

---

## 八、单机方案：一台设备也要避免进程级单点

### 推荐结构

```text
客户端
  → API Gateway（鉴权、限流、请求 ID）
  → 有界任务队列
  → RAG Orchestrator
       ├─ Embedding 微批处理器
       ├─ 本地向量库 + BM25
       ├─ Reranker（可降级）
       └─ LLM Server（连续批处理 / slots）
  → 日志、指标、追踪

文档原件 → 解析队列 → 影子索引 → 验收 → 索引别名切换
```

### 单机最小实现方案

1. **进程隔离**：入口、RAG 编排、模型服务、向量库分进程运行；一个组件崩溃不应把全部数据带走。
2. **固定资源配额**：推理服务固定活动槽位；Embedding 与索引任务设置线程上限。
3. **有界队列**：明确最大等待数和最大等待时长。
4. **健康检查**：分别检测进程存活、模型是否可推理、向量库是否可查询。
5. **自动拉起**：macOS 可用 `launchd`，Linux 可用 `systemd` 或 Docker restart policy。
6. **数据可恢复**：原始文档、索引配置、Embedding 模型版本、Chunk 版本和评测集独立备份；向量索引可重建。
7. **降级路径**：Rerank → Hybrid → BM25 → 明确停止，按业务风险配置。

### llama.cpp 单机起步示例

```bash
llama-server \
  -m /models/model-Q4_K_M.gguf \
  -c 8192 \
  -np 2 \
  --host 127.0.0.1 \
  --port 8080 \
  --metrics
```

`-np 2` 只应作为两个并行 slots 的压测起点。上下文总预算、模型结构和版本参数应以当前 `llama-server --help` 为准。先测 `np=1`，再逐级增加，并记录 TTFT、单用户 tokens/s、总吞吐和峰值内存。

> **生活比喻**：增加 slots 就像增加服务窗口。窗口太少会排长队；窗口太多又会让工作人员争抢同一间厨房。最合适的数量不是越多越好，而是要通过高峰测试找到。

---

## 九、企业级方案：本地化模型的并发与去单点

### 目标架构

```text
                    ┌─ 身份认证 / 租户配额
用户 → 双入口 LB/WAF ├─ API Gateway × 2+
                    └─ 请求队列 / 优先级 / 熔断
                              │
                 RAG Orchestrator × 2+
                    ├─ Embedding 服务池
                    ├─ Rerank 服务池
                    ├─ LLM 推理池（小/中/大模型路由）
                    └─ Prompt / Response Cache
                              │
      ┌───────────────────────┴───────────────────────┐
  向量数据库集群        元数据数据库主从/集群       对象存储/文档原件
  分片 + 副本 + LB        版本、权限、审计            版本化 + 异地备份
      └───────────────────────┬───────────────────────┘
          Metrics + Logs + Traces + Alert + Audit
```

### 各层去单点清单

| 层 | 企业级做法 | 不能只做什么 |
| --- | --- | --- |
| 入口 | 至少两个网关副本，负载均衡与健康探测 | 只给单台推理机绑一个固定 IP |
| 编排 | 无状态副本；会话与任务状态放外部存储 | 把会话只放某进程内存 |
| 推理 | 按模型建独立池；至少两个可用副本；滚动 / 金丝雀发布 | 一套大模型承担所有任务且无备用 |
| 队列 | 高可用消息队列或可恢复任务表；幂等键和死信队列 | 请求失败后无限自动重试 |
| 向量库 | 分片 + 副本，所有节点前放负载均衡；定期快照演练 | 有副本但所有流量仍进入一个节点 |
| 文档原件 | 对象存储版本化、校验和、异地或离线备份 | 只备份不可解释的向量索引 |
| 配置与密钥 | 集中密钥管理、最小权限、轮换与审计 | 把密钥写进镜像或课程代码 |
| 监控 | 指标、日志、Trace 统一关联 request ID | 只看 GPU 利用率 |

> **生活比喻**：企业级部署像连锁图书馆。负载均衡负责把读者分到不同分馆，副本保证某个分馆关门时还有书可看，分片把大量图书分开存放，监控则像总馆的值班大屏。

### 推理池的三种并发扩展方式

| 方式 | 解决什么 | 适用条件 | 注意点 |
| --- | --- | --- | --- |
| 单实例连续批处理 | 同一模型服务更多并发序列 | 单 GPU 已能容纳模型与 KV | 优先调好批处理，再决定是否复制实例 |
| 模型并行（Tensor / Pipeline Parallel） | 一个模型放不进单卡 | 多 GPU、互联带宽足够 | 它解决“模型装不下”，不自动等于高并发 |
| 数据并行 / 多副本 | 横向增加请求吞吐和容错 | 单副本可独立服务，请求可路由 | 需要负载均衡、健康探测、模型版本一致性 |

### 自动扩缩容不要只看 GPU 利用率

适合进入扩缩容决策的指标包括：

- 等待队列长度与最老请求等待时间。
- 活动序列数、KV Cache 使用率、正在处理的 input / output tokens。
- TTFT p95、总延迟 p95、超时率和 429 / 503 比例。
- Embedding / Rerank 批次填充率和服务耗时。
- 向量检索 p95、节点本地命中率、分片副本健康度。

Kubernetes HPA 可使用 CPU、内存或自定义指标扩展无状态服务；LLM 实例启动和模型加载通常较慢，应配置预热、最小副本数、缩容稳定窗口和就绪探针，避免流量过早打到尚未加载完模型的 Pod。

---

## 十、从个人版到企业版的四阶段实现

| 阶段 | 用户量与目标 | 推荐实现 | 通过门槛 |
| --- | --- | --- | --- |
| P0：离线个人版 | 1 人，资料不出设备 | llama.cpp / 本地推理 + 本地向量库 + CLI / Web UI | 50 道业务题质量达标；无并发也不崩溃 |
| P1：单机服务版 | 2～10 人，低并发 | API 网关 + 有界队列 + 2～4 活动 slots + 监控 + 自动拉起 | 峰值压测 30 分钟，无 OOM；p95 与拒绝策略达标 |
| P2：部门高可用版 | 10～100 人，业务时段使用 | 双网关、双编排副本、推理池、向量副本、集中日志 | 任意一个无状态实例下线仍能服务；恢复目标演练通过 |
| P3：企业多租户版 | 多部门、分级权限与审计 | K8s / 调度平台、模型路由、租户配额、分片副本、灾备 | 容量、隔离、安全、审计、RPO / RTO 与 SLO 全部验收 |

不要从 P0 直接跳到 P3。先让业务测试集、容量模型和故障演练在小规模成立，再扩展基础设施。

---

## 十一、压测与验收：怎样找到“安全并发上限”

### 固定测试矩阵

每轮只改变一个变量：

- 量化格式：FP16 / Q8 / Q6 / Q5 / Q4 或目标硬件支持格式。
- 输入长度：短 512、中 2K、长 8K（按真实业务调整）。
- 输出长度：短答、标准答、长报告。
- 并发：1 → 2 → 4 → 8，直到触碰延迟或内存门槛。
- RAG：纯向量、Hybrid、Hybrid + Rerank。

### 必记指标

| 类别 | 指标 |
| --- | --- |
| 质量 | Answer pass rate、Groundedness、Citation correctness、Recall@K、MRR / nDCG |
| 体验 | TTFT p50 / p95、TPOT、总延迟 p95 / p99、流式中断率 |
| 吞吐 | 请求/分钟、输入 token/s、输出 token/s、Embedding 条目/s |
| 资源 | RAM / VRAM 峰值、KV Cache 使用率、CPU / GPU 利用率、磁盘 IOPS |
| 稳定性 | OOM、超时、429 / 503、队列最老等待时间、错误重试次数 |

### 示例验收线（需改成自己的业务目标）

```yaml
quality:
  answer_pass_rate: ">= 90%"
  retrieval_recall_at_10: ">= baseline - 2pp"
performance:
  ttft_p95: "<= 3s"
  total_latency_p95: "<= 20s"
stability:
  error_rate: "< 1%"
  oom: 0
  sustained_test: "30min"
capacity:
  max_active_generation: 4
  max_queue: 20
  queue_timeout: "15s"
```

安全并发上限应取以下条件中最先触发的那个：质量跌破门槛、TTFT / p95 超标、单用户生成速度不可接受、内存越过高水位、或错误率升高。生产配置再从该上限保留 20%～30% 余量。

---

## 十二、故障演练与企业验收题

上线前至少演练：

1. 关闭一个推理副本，进行中的请求怎样失败，下一次请求是否自动转移。
2. 关闭一个向量节点，检索是否仍可用，延迟增加多少。
3. Reranker 超时，是否按规则降级且可在日志中追踪。
4. 队列满时，系统是否快速拒绝并返回可理解的重试提示。
5. 新模型质量不合格，是否能在分钟级回滚到旧版本。
6. 索引构建失败，线上旧索引是否不受影响。
7. 删除向量索引后，能否由原始文档、版本化配置和 Embedding 模型重建。
8. 一个租户达到配额，是否不会拖慢其他租户。

### 必须写清的 RPO / RTO

- **RPO（可接受的数据丢失窗口）**：例如最多丢 15 分钟内的索引增量。
- **RTO（可接受的恢复时间）**：例如核心问答服务 30 分钟内恢复。

RPO / RTO 不是技术团队单方面决定，应由业务风险、合规要求和成本共同确定。

> **生活比喻**：如果游戏每 15 分钟自动存档一次，机器坏掉时最多损失 15 分钟进度，这接近 RPO；从故障发生到重新打开游戏用了 30 分钟，这接近 RTO。

---

## 十三、课堂作业：交付一页容量与架构决策

请填写：

```markdown
# 本地 RAG 容量与并发决策

- 业务场景：
- 使用人数 / 峰值请求：
- 设备：CPU / GPU / RAM / VRAM：
- 生成模型与量化：
- Embedding / Reranker 与量化：
- 向量数据库与向量量化：
- 最大输入 / 输出 token：
- 活动生成槽位 / 等待队列：
- TTFT p95 / 总延迟 p95 目标：
- 质量门槛：
- 降级顺序：
- 单点清单与消除方案：
- 备份、RPO、RTO：
- 压测结果与最终安全并发：
```

## 十四、实施检查清单

- [ ] 量化前后使用同一套业务题评测。
- [ ] 单独记录模型权重、KV Cache、向量索引和系统预留。
- [ ] 在线问答与文档导入使用不同队列和资源配额。
- [ ] 忙时保护由时段和实时水位共同触发，后台任务可抢占、可断点、可幂等恢复。
- [ ] 批量 PDF / Word 先经过解析检查、分类建议和人工确认，再进入影子索引。
- [ ] 召回评测保存 Top-K 原始证据、基线 / 候选对照和相关性判断，不只评估生成答案。
- [ ] 设置最大输入 token、最大输出 token、最大 `top_k` 和 Rerank 候选数。
- [ ] 设置活动槽位、有界队列、超时、熔断和 429 / 503。
- [ ] 监控 TTFT、TPOT、p95、队列、KV Cache、OOM 和拒绝率。
- [ ] 有健康检查、就绪检查、自动拉起和模型预热。
- [ ] 企业版入口、编排、推理和数据层均已排查单点。
- [ ] 原始文档、配置、模型版本、索引版本和评测集可追溯。
- [ ] 做过实例下线、索引失败、超时、队列满和回滚演练。

---

## 十五、官方参考资料

以下链接用于课后核对当前版本参数，部署前应再次阅读目标版本文档：

- [vLLM Quantization：量化格式与硬件兼容表](https://docs.vllm.ai/en/stable/features/quantization/index.html)
- [llama.cpp Server：并行 slots、指标、健康检查与 Router](https://github.com/ggml-org/llama.cpp/blob/master/tools/server/README.md)
- [Qdrant Quantization：向量量化的精度、内存与速度权衡](https://qdrant.tech/documentation/quantization/)
- [Qdrant Distributed Deployment：分片、副本、迁移与负载均衡](https://qdrant.tech/documentation/scaling/distributed_deployment/)
- [NVIDIA Triton Optimization：动态批处理、模型实例与压测](https://docs.nvidia.com/deeplearning/triton-inference-server/user-guide/docs/user_guide/optimization.html)
- [NVIDIA Triton Rate Limiter：跨模型资源限制与优先级](https://docs.nvidia.com/deeplearning/triton-inference-server/user-guide/docs/user_guide/rate_limiter.html)
- [Kubernetes HPA：基于资源或自定义指标的水平扩缩容](https://kubernetes.io/docs/concepts/workloads/autoscaling/horizontal-pod-autoscale/)
- [Qwen3 Embedding 0.6B：32K、可变维度与本地服务示例](https://huggingface.co/Qwen/Qwen3-Embedding-0.6B)
- [Qwen3 Reranker 0.6B：模型规格与系列对照](https://huggingface.co/Qwen/Qwen3-Reranker-0.6B)
- [BAAI BGE-M3：Dense、Sparse、Multi-vector 与 8192 上下文](https://huggingface.co/BAAI/bge-m3)
- [Alibaba GTE Multilingual Base：305M、弹性向量与本地使用](https://huggingface.co/Alibaba-NLP/gte-multilingual-base)
- [Qwen3-8B：本地框架、上下文和 Apache-2.0 模型卡](https://huggingface.co/Qwen/Qwen3-8B)
- [MiniCPM4-8B：端侧效率与本地部署路径](https://huggingface.co/openbmb/MiniCPM4-8B)
- [Gemma 3 4B：多模态、本地部署与使用条款](https://huggingface.co/google/gemma-3-4b-it)

> **版本提醒**：量化内核、硬件兼容性和服务参数更新较快。本课给出的是决策方法和架构边界，命令行参数必须以部署当天使用版本的官方文档和 `--help` 输出为准。