Session Log — task-embed-further-b1f87d — Qwen3-Embedding 进阶调研

时间： 2026-02-27 执行者： Ai.Res

背景已知条件（来自背景文件）

• 硬件： RS1000，4 vCPU 虚拟机，AMD EPYC 9634（支持 AVX-512+BF16）
• 当前最优： batch=8, threads=4, FP32, sentence_transformers → 17.3 条/秒
• 已测并排除的方案： 线程调优（越多越慢）、batch_size 调优（batch=8最优）、BF16（无效）、fastembed（不支持Qwen3）、ONNX FP32（-62%）、ONNX INT8（-15%，仍低于baseline）
• 全量建索引场景： 21,680 条，约 18.7 分钟（一次性操作）
• 查询延迟： P50=59ms，P95=784ms

Q1 调研：还有哪些可能加速 Qwen3-0.6B 的方案？

Q1 调研结果摘要

搜索范围： sbert.net 官方文档、PyTorch 官方 blog、AMD ZenDNN/zentorch 文档、Hugging Face 博客

方案F：torch.compile（最值得尝试）

原理： PyTorch 2.x 引入的 JIT 编译，将模型计算图转为优化内核，减少 Python 开销和内存读写。

预期收益：
- Hugging Face 官方文档标注：CPU 上 +10~30%（具体取决于模型和硬件）
- PyTorch 官方 blog（AWS Graviton3，同为 ARM 服务器 CPU）：embedding 模型 +1.7x（70%加速）
- 注意：Graviton3 有专门 torch.compile 优化路径，AMD EPYC 效果可能不同

针对 AMD EPYC 的特殊加速路径：zentorch
- AMD 官方 PyTorch 插件（zentorch），专为 EPYC Zen4/Zen5 架构优化
- 与 torch.compile 集成，提供图级别融合优化（matmul、embedding kernel）
- Hugging Face + AMD 联测：Genoa→Turin 跨代提升约 2x，zentorch 是主要推手
- RS1000（EPYC 9634 = Zen4）已在 zentorch 支持列表内
- 安装：pip install zentorch，与 torch.compile 无缝集成

使用方法：

import zentorch  # 自动注册优化算子
model = SentenceTransformer("Qwen/Qwen3-Embedding-0.6B")
model = torch.compile(model, backend="zentorch")  # 或 backend="inductor"

风险：
- 首次 compile 预热时间：分钟级（一次性开销）
- 虚拟机环境下 zentorch 效果可能低于裸金属（RS1000 是 4 vCPU 虚机）
- 需要实测验证

方案G：sentence_transformers 内置 ONNX backend（正确路径，区别于已测方案E）

背景： 已测方案E 使用的是 optimum 命令行导出 + 手动 ONNX 推理，结论是慢。
新发现： sbert.net 官方文档描述的是 backend="onnx" 参数直接在 SentenceTransformer 里切换，优化器已内置，比手动导出更规范。

model = SentenceTransformer("Qwen/Qwen3-Embedding-0.6B", backend="onnx")
# 支持 model_kwargs={"provider": "CPUExecutionProvider"}

实测前景： 官方文档标注 CPU 上有提速潜力，但基于方案E 的失败经验（ONNX Runtime 在 AMD EPYC 上未充分利用 AVX-512），预期提速可能性较低，不建议优先尝试。

方案H：ONNX + Optimum 图优化（O2/O3 优化级别）

原理： 导出 ONNX 后用 optimum 做图优化（算子融合、冗余节点消除），比原始 ONNX 快。

from sentence_transformers.backend import export_optimized_onnx_model
export_optimized_onnx_model(model, "avx512", model_name_or_path, onnx_model_name="model_avx512")
# 支持 "avx2", "avx512", "avx512_vnni" 配置

官方数据： 各量化配置（arm64/avx2/avx512/avx512_vnni）在 CPU 上结果"大致相当"的提速，具体数字未公布。
判断： 基于方案E 底线数据（ONNX INT8 仅 13.3 条/秒），优化后可能提到 15-16 条/秒，但仍可能低于当前 17.3 条/秒的 PyTorch 路径。风险高，收益不确定。

方案I：向量缓存策略（工程加速，非模型加速）

原理： 对相同/相似的查询缓存 embedding 结果，跳过推理计算。

适用场景：
- 爱衣的记忆搜索场景：查询频繁重复（例如固定时段的关键词）→ 缓存命中率高
- 新增 session 建索引：每条只算一次，不需要重复计算 → 天然无重复

实现方案：

from functools import lru_cache
import hashlib

@lru_cache(maxsize=1000)
def cached_embed(text_hash):
    return model.encode([text])

def embed_with_cache(text):
    h = hashlib.md5(text.encode()).hexdigest()
    return cached_embed(h)

收益估算： 若查询重复率 20%，每秒等效吞吐 +20%（无额外硬件需求）。

方案J：FlashAttention

可行性： ❌ 不适用本场景
- FlashAttention 是 GPU 专属优化，CPU 无对应实现
- RS1000 无 GPU，排除

方案K：GPTQ/AWQ 量化

可行性： ⚠️ 高风险，收益不确定
- GPTQ/AWQ 专为 GPU 设计，CPU 推理用 bitsandbytes INT4 可行但性能差
- 本地无 GPU，量化通常不会在 CPU 上带来加速（内存节省有限，计算路径反而复杂）
- 方案E（INT8）已验证 CPU 量化路径不划算，INT4 更差

方案L：模型蒸馏/剪枝

可行性： ❌ 工程成本极高，不适合当前场景
- 蒸馏需要重新训练，维护成本高
- 0.6B 已是 Qwen3-Embedding 最小尺寸，Qwen 团队无更小版本
- 若真要更快更小，换 BGE-M3 或 bge-small（但质量下降）

Q1 小结：可行性排序

Q2 分析：17.3 条/秒是否足够？

建索引场景分析

基础数据：
- 全量 21,680 条 session 记录 → 建索引耗时 ~18.7 分钟（一次性操作）
- 这是一次性冷启动成本，之后每次查询不需要重算

新增记录频率估算：
- 爱衣日常对话场景：假设每天产生 50~200 条新 session 记录（活跃使用日）
- 增量建索引耗时：50 条 / 17.3条/秒 ≈ 3 秒；200 条 ≈ 12 秒
- 结论：增量索引完全可以后台异步完成，用户无感知

查询延迟分析：
- 单查询（1条 query embedding）P50 = 59ms，P95 = 784ms
- 爱衣的使用场景：记忆搜索发生在 LLM 调用之前，LLM API 本身耗时 2~10 秒
- 59ms 中位延迟相对于 2~10s 的 LLM 延迟 = <3% 的额外开销，几乎无感知
- P95 = 784ms 的突刺：每 20 次查询出现 1 次，在 LLM 响应流程中仍被掩盖

潜在瓶颈场景：
1. 批量建索引（冷启动）： 18.7 分钟可接受，属于运维操作而非用户操作
2. 内存竞争： embedding 模型占 ~2GB RSS，若同时运行大型 LLM 可能引起内存压力（RS1000 需确认总内存）
3. P95 突刺（784ms）： 若未来需要实时流式对话（latency-sensitive），可能需要处理；当前 LLM 场景不是问题

结论：17.3 条/秒已经够用

理由：
- 建索引：一次性 18.7 分钟 → 可接受（线下运维时段执行）
- 增量索引：<15 秒/批次 → 完全后台静默处理
- 查询延迟：P50=59ms 在 LLM 调用链中不构成瓶颈
- 不需要进一步提速来解决实际使用瓶颈

什么情况下才需要提速：
- session 记录增���速度极快（日增 >1000 条），且需要实时同步索引 → 届时实测 torch.compile
- 查询延迟需要 P95 < 200ms（例如独立实时搜索 UI）→ 届时考虑缓存策略

Q3 调研：免费线上 Embedding API

候选 API 汇总

A. SiliconFlow（硅基流动）

模型可用： Qwen/Qwen3-Embedding-0.6B、4B、8B（全系列），BAAI/bge-m3
token 上限： Qwen3-Embedding 系列最大 32,768 tokens/次
免费方案：
- 注册赠送 2000万 token 免费额度（一次性）
- Qwen3-Embedding-0.6B 是免费模型（调用费用 = 0，不消耗额度）
- 速率限制：免费版固定 RPM（Requests Per Minute），具体数值未公布，但开发测试够用

CMTEB 分数（Qwen3-Embedding-0.6B）：
根据 Qwen 官方论文（arXiv 2506.05176），CMTEB-R（中文检索子集）：
- Qwen3-Embedding-0.6B：64.64
- BGE-M3：约 54~56（参考 CMTEB 排行榜历史数据）
- 差距：Qwen3-Embedding-0.6B 在中文检索任务上比 BGE-M3 高约 8~10 分

延迟估算（API round-trip）：
SiliconFlow 服务器在国内，从 RS1000（海外 VPS）调用预计：
- 网络 round-trip：~50~200ms（跨国）+ 推理时间
- 远高于本地推理的 59ms P50

B. Jina AI

模型： jina-embeddings-v3（570M，8192 tokens）、jina-embeddings-v4（3.8B，多模态）
免费方案：
- 注册获得免费 token 额度（官网 2025年已改为 token top-up 付费模式，免费额度减少）
- jina-embeddings-v5 为最新（2 sizes: 677M small + 239M nano）
- 注意：2025年5月定价模型调整，"1M tokens/月免费"的说法已不准确，需要查看最新免费额度

CMTEB 分数： jina-embeddings-v3 在 CMTEB 表现中等（约 52~55），低于 Qwen3-Embedding-0.6B
延迟： 根据独立基准测试（nixiesearch，2025年3月，us-east-1测）：
- Jina AI 延迟���高，P90 约 500~3000ms（有明显波动和 spikes）
- Google Vertex AI 最稳定；Cohere 中等；OpenAI 有偶发 spikes

C. Cohere

模型： embed-v4.0（多模态，128k tokens），embed-multilingual-v3.0（1024d，512 tokens）
免费方案： 有免费试用层，但主要面向企业，免费额度较少且有明确速率限制
CMTEB 分数： Cohere embed-multilingual-v3.0 在 CMTEB 上约 48~52（中文表现一般）
隐私问题： 数据发往美国服务器，合规风险较高

D. HuggingFace Inference API

模型： 可调用任意已托管模型，包括 BGE-M3、Qwen3-Embedding-0.6B 等
免费方案： 免费账号有速率限制（免费 CPU 推理，共享资源，响应慢）
- 2025年7月后，HF inference 重点转向 CPU embedding 任务（小模型）
- 速率很低，适合测试，不适合生产
延迟： 共享资源，延迟不稳定，可能数百ms到数秒

CMTEB 基准分对比

本地推理 vs 云端 API：综合对比

Q3 结论：本地推理明显更优，不需要迁移到 API

核心理由：
1. 隐私是决定性因素： 爱衣的记忆搜索内容是主人的私密对话记录，发往任何云端 API 都存在数据泄露风险
2. 延迟本地更低： 本地 P50=59ms 优于任何跨网 API round-trip
3. 质量无差异： SiliconFlow 跑的是同一个 Qwen3-Embedding-0.6B 模型，质量一样
4. 成本： 本地已有硬件，API 虽然有免费额度，但量大后付费

SiliconFlow 的唯一适用场景： LE-B 上 Qwen3 不可用（1.5条/秒），若需要在 LE-B 上也能访问高质量中文 embedding，可考虑 SiliconFlow API 作为 LE-B 的临时 fallback（不含敏感数据时）。

综合结论与行动建议

三问汇总

Q1（还有哪些加速方案？）
→ 最推荐：torch.compile + zentorch（2行代码，预期 +10~30%，AMD EPYC 专属优化路径），需实测验证。向量缓存也值得加（工程成本低，场景匹配）。ONNX 路径已充分验证不划算，不再尝试。

Q2（17.3条/秒够用吗？）
→ 够用。 全量建索引 18.7 分钟是一次性操作，增量建索引 <15 秒/批，查询 P50=59ms 在 LLM 调用链中不构成瓶颈。暂无需进一步提速。

Q3（免费线上 API 比较）
→ 本地推理完胜。 最好的免费 API 选项是 SiliconFlow（Qwen3-Embedding-0.6B 免费，质量一致），但隐私问题（聊天记录外发）是硬伤。本地延迟更低、成本更低、完全可控。不建议迁移到 API。

如果要追求更快，优先级：

1. 先测 torch.compile（方案F）： model = torch.compile(model) 或加 zentorch 插件，实测一次看收益
2. 加向量缓存（方案I）： 对高频重复查询有效，工程简单
3. 暂时搁置其他方案： 17.3条/秒已经够用，不值得花时间优化到边际收益递减的程度

Reference Table