**摘要**：給 RAG 鏈路配重排序模型，第一反應(yīng)是上 HuggingFace 官方的 TEI（Text Embeddings Inference）——一個容器、一條命令、自帶批處理。但在這條鏈路里它沒有用上，最后是我自己寫了約 40 行的 `transformers + FastAPI` 服務(wù)頂上的。放棄 TEI 的原因不是它不好用，而是這個模型從架構(gòu)上就不在它的支持名單里：它不是常見的分類式 cross-encoder，而是一個用"下一個 token 是 yes 還是 no"來打分的 CausalLM。本文記錄這條決策鏈上的每一步判斷，以及落地后實際踩到的三個依賴坑。適合正在搭 RAG、糾結(jié)重排序模型怎么部署的工程同學(xué)。一、背景：RAG 里最容易被低估的一個組件一條標(biāo)準(zhǔn)的兩階段 RAG 鏈路長這樣：文檔解析 → 分塊向量化 → 向量庫召回 topK → 重排序 → 取 topN 送給大模型向量召回解決"找到一批可能相關(guān)的"，重排序（Reranker）解決"在這一批里挑出真正最相關(guān)的"。它是召回和生成之間的最后一道把關(guān)：召回錯了還能靠 Reranker 挽救一部分，Reranker 選錯了，生成模型拿到的上下文就是錯的，后面什么都白搭。這次要部署的是一個4B 級別的 cross-encoder 重排序模型，官方推薦的數(shù)據(jù)格式是 yes/no 判別式。二、決策鏈：三條路，兩條走不通2.1 路線一：vLLM 的 `/v1/rerank` —— 環(huán)境卡死vLLM 從某個版本起原生支持重排序接口，這是最省心的一條路。但當(dāng)時的部署環(huán)境是Windows 原生——vLLM 官方不支持（這正是上一篇《Windows 上跑推理服務(wù)的三個硬限制》講的那件事）。這條路在動手前就排除了。2.2 路線二：TEI —— 架構(gòu)不支持TEI 是 HuggingFace 官方的推理服務(wù)，一條 Docker 命令起來，自帶批處理和量化，看起來是標(biāo)準(zhǔn)答案：docker run --gpus all -p 8080:80 ghcr.io/huggingface/text-embeddings-inference:1.5 \ --model-id reranker-model但它的支持模型名單是按架構(gòu)白名單的——只接受能被它當(dāng)作"特征提取模型"來加載的架構(gòu)。而我們要部署的這個模型，在 HuggingFace 上注冊的架構(gòu)是CausalLM，不在 TEI 的支持列表里。強行指定會得到一個加載失敗。2.3 路線三：sentence-transformers —— 也不對口對純 cross-encoder（比如 bge-reranker 系列），`sentence-transformers` 的 `CrossEncoder` 是標(biāo)準(zhǔn)用法。但這個模型不是那種結(jié)構(gòu)，它根本沒有一個能輸出分?jǐn)?shù)的分類頭。2.4 所以最后走了第四條路