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

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

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

先想一个常见问题

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

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

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

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

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

RAG 的全名不用死记

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

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

一句话记忆：

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

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

① 提出问题说出真正想解决的事

② 查找资料从本地文档中找相关内容

③ 挑选证据把最有用的资料排在前面

④ 组织答案根据证据回答并给出来源

RAG 可以做什么

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

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

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

1. 上传资料负责人提交新制度、产品手册或项目复盘。
2. 整理入库RAG 像图书管理员一样分类、贴标签、建目录。
3. 员工提问直接说问题，不必记住文件名和文件夹。
4. 查证回答系统先找证据，再显示答案、文件名和页码。
5. 反馈改进员工标记是否有用，团队继续优化搜索效果。

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

本地 RAG 又是什么

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

它适合：

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

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

RAG 不是什么

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

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

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

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

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

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

本课技术词“人话翻译”

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

贯穿全课的比喻地图

二、先分清三种“量化”

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

量化选择的实用顺序

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

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

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

三、显存 / 内存怎样估算

1. 模型权重的粗估

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

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

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

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

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

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

3. 整机安全预算

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

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

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

4. 本地设备选型参考

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

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

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

1. 先定义四个指标

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

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

例如平均每秒 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. 背压（忙不过来就排队）与降级（高级功能失败就用简单方案）规则

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

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

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

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

忙时：先保在线问答排队、限流，后台任务暂缓

闲时：让空余算力干活批量入库、重建索引、评测和备份

忙时：优先稳定响应

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

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

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

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

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

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

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

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

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

忙闲资源配额参考

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

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

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

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

1. 向量化 / Embedding 模型

维度怎么选

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

2. Reranker 模型

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

3. 可本地化生成模型

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

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

必须归档的版本字段：

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. 一套适合课程演示的默认组合

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

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

① 接收文件PDF、Word、扫描件

② 扫描识别安全检查、OCR、解析版面

③ 建议分类AI 推荐标签和知识库

④ 人工确认检查低把握和敏感资料

⑤ 建立索引做成可以快速查找的目录

⑥ 检索回答带着证据回答真实问题

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

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

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

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

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

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

固定：同一批文档 + 同一组问题 + 同一权限身份
改变：每轮只改一个变量
比较：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. 学员应该记住的完整闭环

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

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

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

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

推荐结构

客户端
  → 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 单机起步示例

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 就像增加服务窗口。窗口太少会排长队；窗口太多又会让工作人员争抢同一间厨房。最合适的数量不是越多越好，而是要通过高峰测试找到。

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

① 双入口一个入口故障还能走另一个

② 双网关鉴权、限流不靠一个进程

③ 有界队列人多时排队，不无限挤入

④ 服务池检索、重排、生成分工协作

⑤ 模型池一台故障时把请求转给别台

⑥ 双份数据索引可切换，原文可恢复

目标架构

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

各层去单点清单

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

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

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

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

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

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

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

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

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

固定测试矩阵

每轮只改变一个变量：

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

必记指标

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

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。

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

请填写：

# 本地 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：量化格式与硬件兼容表
• llama.cpp Server：并行 slots、指标、健康检查与 Router
• Qdrant Quantization：向量量化的精度、内存与速度权衡
• Qdrant Distributed Deployment：分片、副本、迁移与负载均衡
• NVIDIA Triton Optimization：动态批处理、模型实例与压测
• NVIDIA Triton Rate Limiter：跨模型资源限制与优先级
• Kubernetes HPA：基于资源或自定义指标的水平扩缩容
• Qwen3 Embedding 0.6B：32K、可变维度与本地服务示例
• Qwen3 Reranker 0.6B：模型规格与系列对照
• BAAI BGE-M3：Dense、Sparse、Multi-vector 与 8192 上下文
• Alibaba GTE Multilingual Base：305M、弹性向量与本地使用
• Qwen3-8B：本地框架、上下文和 Apache-2.0 模型卡
• MiniCPM4-8B：端侧效率与本地部署路径
• Gemma 3 4B：多模态、本地部署与使用条款

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