任务 ID: task-qwen3-further-72343 | 文件: session.md | 最后修改: 2026-02-27 17:09:55
Session Log — task-qwen3-further-72343 — Qwen3-Embedding 进阶调研
时间： 2026-02-27 执行者： 爱衣（Ai.Res session 无响应，由爱衣直接完成）
Q1：还有哪些可能加速 Qwen3-Embedding-0.6B 的方案？
已排除方案（上轮实测）
- 多线程：RS1000 实为 4vCPU VM，增加线程反而慢
- BF16：sentence_transformers 内部 cast 回 FP32，硬件加速未生效
- ONNX INT8：比 baseline 慢，ONNX Runtime 未充分利用 AVX-512
- fastembed：不支持 Qwen3-Embedding
待评估方案
🟡 torch.compile（预期收益：+10~30%，可行性：高）
- PyTorch 2.x 特性，JIT 编译前向传播，CPU 下对重复计算模式效果显著
- 用法：
model = torch.compile(model, backend='inductor')
- 首次调用有编译开销（30-60s），之后固定收益
- 对 embedding 推理（纯 forward pass，无 kv cache）效果相对稳定
- 建议优先测试，零依赖，代码改动一行
🟡 批量预计算 + 向量索引缓存（预期收益：实际查询延迟降至 <10ms，可行性：极高）
- 对 memory search 场景最有价值的"优化"
- 21,680 条语料一次性编码存入 usearch/faiss 索引，后续查询只需编码单条 query
- 实时查询路径：encode(query, 1条) ~60ms + usearch 检索 <5ms = <70ms 总延迟
- 完全消除实时 corpus encoding 的开销
- 已知计划（T043 部署后）：集成到 OpenClaw memory search
🔴 INT4 量化（GPTQ/AWQ/bitsandbytes）（预期收益：+20~40% 速度，风险：质量损失）
- 模型从 ~1.2GB 压缩至 ~400MB，内存减半
- 但 embedding 模型对量化更敏感（直接影响检索准确率），LLM 用 INT4 很常见，embedding 较少见
- Qwen3-Embedding 目前没有官方 GPTQ/AWQ 版本
- 暂不推荐，等社区验证质量影响后再考虑
🔴 llama.cpp / GGUF（预期收益：理论上 +20~50%，可行性：低）
- llama.cpp 支持 CPU 推理且有 AVX-512 优化路径
- 但 Qwen3-Embedding 作为 embedding 模型的 GGUF 支持尚未成熟（截至 2025 年）
- llama.cpp 的 embedding 功能主要面向 LLaMA 架构，Qwen3 适配需要额外工作
- 短期不可行，等 llama.cpp 社区支持
⚪ OpenVINO（预期收益：+10~30% on Intel CPU，可行性：低）
- 专为 Intel 优化，AMD EPYC 支持有限且效果不保证
- 不适用 RS1000
⚪ vLLM CPU 模式（预期收益：不确定，可行性：低）
- vLLM 主要面向 GPU 推理服务，CPU embedding 不是设计目标
- 内存占用大，部署复杂度高，收益不明
- 不推荐
小结
| 方案 |
优先级 |
预期收益 |
工作量 |
| 批量预计算索引缓存 |
⭐⭐⭐ 最高 |
查询延迟 -90% |
小（T043 部署时一并做） |
| torch.compile |
⭐⭐ 高 |
吞吐 +10~30% |
极小（一行代码） |
| INT4 量化 |
⭐ 低 |
+20~40%，有风险 |
中 |
| llama.cpp/GGUF |
⬇️ 暂不可行 |
— |
大 |
Q2：17.3 条/秒的速率是否足够？
使用场景分析
| 场景 |
计算 |
结论 |
| 初始全量建索引 |
21,680 ÷ 17.3 = 约 21 分钟 |
✅ 可接受，一次性操作 |
| 每日增量更新 |
50~100 条 ÷ 17.3 = 3~6 秒 |
✅ 完全足够 |
| 实时 query 编码 |
P50=163ms，P95=444ms |
✅ 完全满足 |
| 总查询延迟（有索引） |
~163ms + <5ms usearch = ~170ms |
✅ 远优于 LLM API 2~10s |
横向对比
- OpenAI text-embedding-3-small API 调用延迟：100~300ms（网络 RTT 为主）
- 本地 Qwen3 P50：163ms（无网络，本机推理）
- 两者在同一数量级，本地方案无延迟劣势
结论
17.3条/秒完全足够当前场景。瓶颈从来不是 embedding 速度，而是 LLM 推理时间。唯一值得优化的是通过预计算索引消除每次查询时的 corpus 重编码——这不需要提升 encoding 速率，只需要一次性建好索引。
Q3：免费/低成本在线 Embedding API 对比
主要候选
| 服务 |
模型 |
免费额度 |
价格 |
中文能力 |
| Jina AI |
jina-embeddings-v5-text(677M)/nano(239M) |
有免费 trial |
付费订阅 |
强，89+ 语言 |
| SiliconFlow |
BAAI/bge-m3, Qwen3-Embedding 等 |
有永久免费额度 |
¥0.7/M tokens |
强，支持中文模型 |
| 智谱 AI |
embedding-3 |
有免费额度 |
低价 |
专为中文优化 |
| 阿里云 |
text-embedding-v3 |
免费试用 |
~¥0.5/M tokens |
强中文 |
| Cohere |
embed-multilingual-v3 |
免费层（有限） |
$0.1/M tokens |
中等中文 |
| OpenAI |
text-embedding-3-small |
❌ 无免费 |
$0.02/M tokens |
中等中文 |
| Voyage AI |
voyage-3-large |
有试用 |
$0.18/M tokens |
英文为主 |
MTEB/CMTEB 准确率对比（中文检索任务，约略值）
| 模型 |
CMTEB 中文均分 |
备注 |
| Qwen3-Embedding-0.6B（本地） |
~71+ |
CMTEB SOTA 小模型 |
| Qwen3-Embedding-8B |
~74+ |
MTEB 多语言 #1 |
| BAAI/bge-m3 |
~65 |
SiliconFlow 上有 |
| jina-embeddings-v3 |
~62~64 |
多语言强 |
| text-embedding-3-small |
~60~62 |
英文偏强 |
| Cohere multilingual v3 |
~60~63 |
多语言均衡 |
重点：SiliconFlow 上的 Qwen3-Embedding
SiliconFlow 已托管 Qwen3 系列模型（包括 Qwen3-Embedding），提供与本地相同的模型质量，有永久免费额度（具体限额需确认）。这是"免费在线 API + 同等准确率"的最佳选项。
结论与推荐
是否值得切换到在线 API？
| 考量 |
本地 Qwen3 |
在线 API |
| 准确率 |
✅ 最高（CMTEB ~71+） |
🟡 SiliconFlow Qwen3 同等；其他低 5~10 分 |
| 延迟 |
✅ P50=163ms，无网络 RTT |
🟡 100~300ms，含网络 |
| 成本 |
✅ 电费极低（VM 已有） |
🟡 SiliconFlow 小量免费，大量按量 |
| 隐私 |
✅ 完全本地 |
⚠️ memory 内容上传到第三方 |
| 维护 |
🟡 需要自己管理 |
✅ 零维护 |
推荐：保持本地 Qwen3，T043 迁移后顺带实测 SiliconFlow Qwen3 API 作为备选。
主要理由：memory 内容属于私密数据，上传到第三方有隐私顾虑；本地方案准确率更高；延迟相当；当前成本可忽略。
综合建议
- 立即可做：
batch_size=8（已确认 +10%），测试 torch.compile（预期再 +10~30%）
- T043 迁移时一并做：建立 usearch 向量索引，实现预计算 → 查询延迟从 163ms 降至 <70ms
- 在线 API：若有隐私可接受的场景，SiliconFlow 上的 Qwen3-Embedding 可作为无维护备选
- 不需要做：更多线程、BF16、ONNX、llama.cpp（短期均无收益或不可行）