48 小时完成企业级 RAG 生产升级：cross-encoder 重排、vLLM 迁移与 v1.0.0
2026-07-24 到 07-25 的 48 小时内，我们在一台 DGX Spark 上完成了一次完整的生产 RAG 升级：接入 cross-encoder 重排、将推理引擎迁移到 vLLM、建成 17 道黄金问题集作为 CI 阻断门槛。单流 TTFT 下降 72%，c=2 聚合吞吐翻倍，升级全程主链路零中断。
目录
目标：把 cross-encoder 重排接进生产聊天链路
这次升级的第一项工程目标，是让聊天链路的检索从向量召回进入两阶段精排：新增重排门控、候选池从 8 扩到 24 再精排回 8、REST 接口同步扩宽，并配套编写 SSE 并发压测脚本[1]。
第一个需要绕开的外部约束来自硬件架构：HuggingFace TEI 没有 linux/arm64 镜像，在 DGX Spark（GB10，ARM64）上无法启动。我们改用已在运行的 llama.cpp 镜像的 --reranking 模式承载 cross-encoder，省掉一个额外组件的同时也少了一份运维面（细节见另一篇文章）[1]。
引擎瓶颈的量化定位
重排接好后测得单槽位 llama.cpp 并发基线：c=1 TTFT p50 12.3s、c=2 33.8s、c=4 51.2s，聚合吞吐平坦卡在 2.4–2.7 tok/s——引擎串行化就是瓶颈本身。先切到 4 槽位（-np 4）取得阶段性收益：c=4 TTFT 降到约 21s，聚合吞吐从 2.7 提到 4.6 tok/s（+70%），单流解码无回退[1]。
闭环压测：把问题挡在上线之前
我们不依赖代码评审来判断"能不能上"，而是用带真实认证、真实并发的闭环压测做准入。这一轮压测在集成阶段定位并修复了 5 项问题，全部在面向用户之前解决[1]：
- MCP stdio 子进程只继承
HOME/PATH，RERANKER_HOST静默丢失——改为透传完整环境； - MCP 日志写入 stdout 污染 JSONRPC 通道（392 次解析错误）——改路由到 stderr；
- 用户断连时 agent 请求上下文重置在跨上下文场景抛
ValueError——增加守卫； - 首轮基线的"全挂"实为访客限流正确拦截了裸压测请求——改用正式会员 JWT 复测；
- reranker 对约 1K token 分片返回 500（默认批大小 512 不足）——
ubatch调至 4096。
同期还捕获一个上游变更：新版 llama.cpp 已移除 --cache-prompt 标志，继续传参会触发崩溃重启循环，随即从启动参数中剔除[1]。修复合入主干后，完整测试套件 2743 个用例全绿。
维护窗口的回滚预案实测
-np 4 是阶段性方案，第二阶段目标是迁移到 vLLM，取得自动前缀缓存与 chunked prefill 的收益。
第一个维护窗口（2026-07-25 01:31–01:35）在 4.5 分钟内按预案完成受控回滚：vLLM 启动报 SafetensorError，15 个权重分片中有 4 个是此前中断下载留下的残片。正面信号是所有计划参数（mxfp4、Marlin 后端、fp8 KV、前缀缓存、chunked prefill）均被完整接受。回滚于 01:35:57 验证完成，llama.cpp 全程对外保持 200，主链路零中断[2]。
这次窗口直接产出了一条固化到流程里的准入检查：开窗前不只校验权重分片是否存在，还要做头部完整性解析 + 大小偏移交叉核对。补齐校验后才申请第二个窗口——能在 4.5 分钟内判定并安全退出，本身就是预案设计的目标。
第二个窗口：迁移完成，指标全面改善
第二窗口（02:39–02:58）冷启动仅约 10 分钟（预算 30–40）。B 侧真实聊天链路压测结果[2]：
| 并发 | TTFT p50（A→B） | 聚合吞吐（A→B） |
|---|---|---|
| c=1 | 14.0s → 3.96s（−72%） | 3.1 → 3.7 tok/s |
| c=2 | 28.0s → 11.27s（−60%） | 2.5 → 5.0 tok/s |
| c=4 | 21.0s → 14.74s（−30%） | 4.6 → 5.5 tok/s |
18/18 请求成功、0 错误。两项列入后续优化路线：单流解码 34.3 tok/s（社区宣称的 59 依赖本次构建未包含的 FlashInfer 后端）；忠实度分项因当时样本量为 1 且受查询缓存影响，不具统计意义，随黄金集扩容后重新基准。判定保留 vLLM——每一项用户可感知的指标都在改善。
NGC 头对头与稳定性复查
03:59–04:35 拉取 NVIDIA 官方 NGC 镜像做头对头：单流解码两边一致（34.3，同为 TRITON_ATTN 上限），c=1 TTFT p50 自建镜像 3.96s、NGC 9.83s，c=4 基本打平，NGC 聚合吞吐略高 9%——保留自建镜像，2.5 倍的单用户 TTFT 优势比 9% 的聚合吞吐更值钱[2]。
05:47 复查确认 0 重启、0 错误，内存稳定 89–91GB；c=6/8 探测显示 c=6 聚合吞吐 8.6 tok/s（+56%），c=8 已饱和，据此将并发闸设为 6（全局）/4（单租户）[1][3]。
护栏与数字总览
CI 阻断门槛的黄金问题集建成 17 条，覆盖源召回、关键词召回、反捏造负样本、引用正确性、忠实度五个维度，全部来自真实流量与知识库覆盖度分析；每日 03:10 定时任务用同一套框架对线上做一次生产体检[3]。48 小时内在栈的各层定位并修复 13 项集成问题；收尾时后端测试 2,810 个、前端 842 个，全部绿灯[3]。
工程方法
支撑这 48 小时的不是加班，是三条固化的工程纪律：闭环压测做准入（真实认证、真实并发，不靠代码评审拍板）、受控维护窗口（每次变更都有明确的回滚判据和时间预算）、黄金问题集作为 CI 阻断门槛（质量回归由机器把关，不依赖人工抽查）。第一个窗口 4.5 分钟安全退出，正是这套纪律的实测结果。
常见问题
Q: 升级期间线上服务受影响吗？ A: 主链路零中断。第一个维护窗口触发回滚预案，llama.cpp 全程对外保持 200；第二个窗口冷启动约 10 分钟，18/18 请求成功、0 错误。
Q: 为什么选择自建 vLLM 镜像而不是官方 NGC 镜像？ A: 头对头实测：c=1 TTFT p50 自建 3.96s vs NGC 9.83s，NGC 仅在聚合吞吐上高 9%。对话式产品里单用户首字延迟的权重远高于聚合吞吐，因此保留自建镜像。
Q: 黄金问题集测什么？ A: 17 道题覆盖源召回、关键词召回、反捏造负样本、引用正确性、忠实度，来自真实用户提问与知识库覆盖分析，既是 CI 阻断门槛，也是每日 03:10 的生产体检。
关于 HTZL.AI
HTZL.AI 是四川慧途智联科技有限公司旗下的企业级私有 AI 品牌，专注于"数据不出企业、模型不进云端"的私有化部署路径，是 NVIDIA Inception 会员企业。本文所有数据均来自我们在真实 DGX Spark 生产环境上的工程记录。