5c21a485
 tangwang
qwen3-reranker-0....
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
|
# Qwen3-Reranker-0.6B GGUF 安装与调优
本文档覆盖 `qwen3_gguf_06b` 后端，对应模型：
- Hugging Face: `ggml-org/Qwen3-Reranker-0.6B-Q8_0-GGUF`
- 文件: `qwen3-reranker-0.6b-q8_0.gguf`
- 本地目录: `./models/reranker/qwen3-reranker-0.6b-q8_0-gguf`
## 结论先看
这个后端已经接入完成，也能正常使用 GPU offload，但不适合当前项目的在线主链路场景。
目标场景是：
- 1 个 query
- 400 个商品标题
- 追求最短响应时间
实测最优配置下：
- GPU 显存占用约 `894 MiB`
- 400 titles 单请求延迟约 `265318 ms`
因此它更适合作为：
- 低显存 fallback
- 功能验证
- 本地离线实验
不建议作为在线低延迟 reranker 主 backend。
## 独立环境
`qwen3_gguf_06b` 使用独立 venv：
- backend: `qwen3_gguf_06b`
- venv: `.venv-reranker-gguf-06b`
- requirements: `requirements_reranker_qwen3_gguf_06b.txt`
安装：
```bash
./scripts/setup_reranker_venv.sh qwen3_gguf_06b
```
如果需要确认是 CUDA 版 `llama-cpp-python`：
```bash
./.venv-reranker-gguf-06b/bin/python - <<'PY'
import llama_cpp
print(llama_cpp.llama_supports_gpu_offload())
PY
```
预期输出：
```python
True
```
## 模型下载
推荐预先下载到本地，避免首次服务启动时在线拉取：
```bash
mkdir -p models/reranker/qwen3-reranker-0.6b-q8_0-gguf
curl -L --fail -C - \
-o models/reranker/qwen3-reranker-0.6b-q8_0-gguf/qwen3-reranker-0.6b-q8_0.gguf \
'https://huggingface.co/ggml-org/Qwen3-Reranker-0.6B-Q8_0-GGUF/resolve/main/qwen3-reranker-0.6b-q8_0.gguf?download=true'
```
当前实测文件大小：
- `639153184` bytes
## 推荐配置
`config/config.yaml` 中建议保留：
```yaml
qwen3_gguf_06b:
repo_id: "ggml-org/Qwen3-Reranker-0.6B-Q8_0-GGUF"
filename: "qwen3-reranker-0.6b-q8_0.gguf"
local_dir: "./models/reranker/qwen3-reranker-0.6b-q8_0-gguf"
cache_dir: "./model_cache"
instruction: "Rank products by query with category & style match prioritized"
n_ctx: 256
n_batch: 256
n_ubatch: 256
n_gpu_layers: 999
main_gpu: 0
n_threads: 2
n_threads_batch: 4
flash_attn: true
offload_kqv: true
use_mmap: true
use_mlock: false
infer_batch_size: 32
sort_by_doc_length: true
length_sort_mode: "char"
reuse_query_state: false
enable_warmup: true
verbose: false
```
## 调优结果
在当前机器上做了同机实测。标题文件来自 `/home/ubuntu/rerank_test/titles.1.8w`，查询为 `白色oversized T-shirt`。
80 titles：
- `n_ctx=256, reuse_query_state=true` -> `60108 ms`
- `n_ctx=256, reuse_query_state=false` -> `53383~56893 ms`
- `n_ctx=320, reuse_query_state=true` -> `60961 ms`
- `n_ctx=384, reuse_query_state=true` -> `56578 ms`
- `n_ctx=384, reuse_query_state=false` -> `57272 ms`
- `n_ctx=512, reuse_query_state=false` -> `60542 ms`
- `n_ctx=256, reuse_query_state=false, n_threads=4, n_threads_batch=8` -> `61228 ms`
400 titles：
- `n_ctx=256, n_batch=256, n_ubatch=256, n_gpu_layers=999, reuse_query_state=false`
-> `265318 ms`
## 经验沉淀
这次接入最重要的结论不是“哪个小参数更快”，而是：
1. 这个 0.6B GGUF 权重虽然小，但当前后端实现仍是逐 doc 顺序打分。
2. 对在线 400-title 请求来说，串行打分本身就是主瓶颈。
3. `reuse_query_state` 在这个模型上没有带来收益，反而更慢。
4. `n_ctx` 拉大到 `384/512` 也没有带来实质收益，反而更慢或持平。
5. 这个 backend 的优势是低显存，不是低延迟。
如果目标是在线最短响应时间，优先级建议是：
1. `qwen3_vllm`
2. 其他真正支持高吞吐批处理的后端
3. `qwen3_gguf_06b` 仅作为低显存 fallback
## 验证命令
本地直连 backend 调优：
```bash
PYTHONPATH=/data/saas-search ./.venv-reranker-gguf/bin/python \
scripts/benchmark_reranker_gguf_local.py --backend-name qwen3_gguf_06b --docs 400
```
按服务方式启动：
```bash
RERANK_BACKEND=qwen3_gguf_06b ./scripts/start_reranker.sh
```
|