在 Dify 里跑 Qwen3-Embedding 召回测试，最怕的不是没结果，而是不知道模型到底有没有被调用。TaoToken（ https://taotoken.net/?utm_source=taotoken_aicg_blog_end ）提供一个更直接的验证方式：让 Dify 的 Embedding 模型走在线 API 通道，用控制台的 Token 消耗来确认调用真的发生了。原文的路径是先部署 GPUStack，再在 Dify 里装插件、建知识库、做召回测试，操作没问题，但缺少一个关键环节——计量。这次我们保留原来的知识库和分段策略，只把 Dify 的 Embedding 模型指向 TaoToken，然后用同一批文档重跑召回，最后去控制台对用量。链路通不通，跑完就知道。
1. Qwen3-Embedding 很强，但本地部署后有一件事始终不确定
1.1 从 GPUStack 到 Dify 的经典方案
原文选了 qwen3-embedding-8b 的 Q8_0 量化版部署到 GPUStack，然后在 Dify 插件市场安装 GPUStack 插件，把模型配给 Embedding 用。Qwen3 Embedding 系列有 8B、4B、0.6B 三个尺寸，其中 8B 的上下文做到 32K，和 BGE-M3 比有代差，所以用它做知识库召回是顺理成章的选择。GPUStack 的好处是能自动检测硬件并推荐量化版本，下载完成后模型显示 running，就能在 Dify 里当本地 Embedding 服务用了。
1.2 痛点：召回成功不等于模型真的被调用了
问题出在验证环节。本地模型没有请求日志，Dify 端显示「召回成功」，你其实分不清这个结果来自 Qwen3-Embedding 的向量计算，还是 Dify 的缓存，或者模型加载失败后插件自动降级。我见过有人改了分段策略后召回结果没变化，排了半天才发现模型 ID 填错，Dify 静默用了另一个 Embedding。本地部署的 Q8_0 量化版又没有 Token 计数，你甚至不知道一次召回测试到底传了多少字符进去。
这个痛点不解决，后面调知识库的分块大小、文档解析规则都会像蒙眼开车。所以我们需要一个能明确看到「谁被调用了、消耗了多少 Token」的验证通道。
2. 与其在 GPUStack 里拖模型，不如先去 TaoToken 创建一把 Key
2.1 打开官网完成注册和建 Key
原文这一步是「在 GPUStack 的模型界面点击部署模型」。换成 TaoToken 之后，动作简化成两步：打开 TaoToken 注册登录，进入 API Keys 页面创建一个 Key，把生成的密钥保存为YOUR_API_KEY。整个过程不需要下载模型，也不用关心显存。官网控制台还会显示这个 Key 的调用记录，这正是后面验证要用的。
注意，官网地址和接口地址是两回事。官网落地页用来注册、创建 Key、看模型广场、看用量；填进 Dify 的 Base URL 是https://taotoken.net/api，末尾不要加/v1。别把 API 地址填到浏览器里，也别在 Dify 里把官网地址当成接口地址。
2.2 从模型广场确认 Embedding 模型 ID
Dify 配置里需要填「模型名称」，这个名称会直接作为请求的模型 ID 传给 TaoToken。不要凭印象写，去 https://taotoken.net/?utm_source=taotoken_aicg_blog_end 的模型广场，搜索 Qwen3-Embedding，复制你需要的那个模型 ID。如果你的业务就是复现原文的 8B 效果，那大概率是qwen3-embedding-8b，但以模型广场当前列表为准。本地量化版的选择权在硬盘上，在线版的选择权在模型 ID 里，先确认再填。
3. 在 Dify 里添加 OpenAI-API-compatible 供应商
3.1 新增一个 Text Embedding 模型
进入 Dify 控制台的「设置」→「模型供应商」，找到OpenAI-API-compatible，点击「添加模型」。不同版本的 Dify 字段名稍有差异，核心填写项如下：
- 模型名称：
qwen3-embedding-8b（以模型广场复制为准） - 模型类型：Text Embedding
- API Endpoint URL：
https://taotoken.net/api - API Key：
YOUR_API_KEY - Context Size：
32768
保存后，这个模型会出现在 Dify 的 Embedding 模型列表里。注意qwen3-embedding-8b只是示例 ID，不要在没看模型广场的情况下照抄，否则请求会返回模型不存在。
3.2 为什么选 OpenAI-API-compatible 而不是 GPUStack 插件
GPUStack 插件适合连接你本地已经在跑的服务，但它只负责把请求转发到 GPUStack，不会给你任何调用计量。OpenAI-API-compatible 是一种更通用的接入方式，Dify 对这类供应商支持得最久，报错信息也更直白。更重要的是，TaoToken 在服务端记录了每次调用的模型、时间和 Token 数，Dify 这边填好 Base URL 后，调用链路变成了：
Dify 知识库 →https://taotoken.net/api→ TaoToken 路由到 Qwen3-Embedding → 返回向量 → Dify 写入索引。
这条链路的每一环都能对照控制台的日志验证。填完保存后，建议先做一次「立即测试」让 Dify 发一条请求，确认返回正常，再进知识库操作。
4. 用同一批文档重跑召回测试
4.1 新建知识库，选择刚配置的 Embedding 模型
为了和原来的 GPUStack 测试区分开，建议新建一个知识库，而不是直接改旧知识库。Dify 创建知识库时，「Embedding 模型」下拉框里选中刚添加的qwen3-embedding-8b。如果之前已经建过知识库，也可以在知识库设置里切换 Embedding 模型，但切换后需要重新索引，这正好可以观察 Token 消耗。
文档上传后，Dify 会先做文本解析，再按你选择的分段策略切块，最后逐块调用 Embedding 模型生成向量。这一步会真实消耗 Token，所以控制台的记录会从这里有第一条。
4.2 父子分段 + “#”分隔符
把公众号历史文章的 markdown 文件拖进去。分段设置选择「父子分段」，父分段的分隔符填#。这样每个#开头的大节会作为父块，父块里面的段落再拆成子块。召回命中子块时，Dify 会把父块内容一起带出来，回答上下文更完整。原文用这套配置跑了一遍，我们原样保留，只换模型通道，这样结果差异完全归因于 TaoToken 接入是否正确。
如果你上传的文章里用的是一级标题##或者###，可以尝试把分段符写成##或###，让父块切得更细。原文用#是因为公众号历史文章的 markdown 大多是#开头的大章节，这要根据自己的文档结构调整。
4.3 召回测试怎么判读
索引完成后，点进知识库的「召回测试」页面，输入一个和文章内容强相关的问题。比如文章里有「Qwen3-Embedding」「GPUStack」这类词，就搜一个原文里出现过的技术词。如果返回结果里出现对应段落，说明 Embedding 模型已经成功把文档转成了向量，召回链路是通的。但先别高兴，真正的验证在下一步。
5. 打开 TaoToken 控制台核对用量：这才是真正的验证
5.1 看调用记录和 Token 增量
回到 https://taotoken.net/?utm_source=taotoken_aicg_blog_end 的控制台，找到用量或调用日志页面。正常情况下，你应该能看到刚才 Dify 建知识库和召回测试产生的 Embedding 调用记录。重点看两件事：一是调用时间是否和 Dify 操作时间吻合，二是 Token 数是否增加。如果 Dify 上传了 5 篇 markdown 文档并做了召回测试，那至少会有几条qwen3-embedding-8b的记录，每条对应一批文本的向量化请求。
这一步补上了原文缺失的「模型是否真的被调用」的确认手段。本地 GPUStack 没有计量能力，TaoToken 控制台给了明确证据。Token 增加了，就说明 Dify 确实把文本发送到了 TaoToken，模型也真的做了推理。如果你只看到一条记录而 Dify 上传了很多文档，可能是 Dify 把文本分批合并后调用了，但变量是 Token 数，不是请求次数。
5.2 如果用量没变，按这个顺序排查
控制台没有任何记录时，从下面几个点逐个检查：
- 知识库的 Embedding 模型是不是选成了旧的 GPUStack 模型？新建知识库时容易手滑。
- API Key 是否填对？重新去 TaoToken 控制台复制，注意不要有多余空格。
- 模型 ID 与模型广场是否一致？多一个
-8b或少一个-0.6b，请求都会失败。 - API Endpoint URL 是不是写成了
https://taotoken.net/api/v1？TaoToken 的接口地址是https://taotoken.net/api，末尾不要加/v1。
排查完一般就能解决。如果 Dify 报 401，基本是 Key 的问题；报 404 或 model not found，基本是模型 ID 或 Base URL 的问题。还有一个小概率情况：Dify 版本较老，OpenAI-API-compatible 的字段名叫API Endpoint而不是API Endpoint URL，字段位置变了但含义一样。
6. 跑通之后，再看本地 GPUStack 要用哪种用法
6.1 在线通道的价值：可观测、可计量
这次测试最大的收获，不是把 Embedding 模型从本地换到云端，而是终于有了一个可以信任的观测点。知识库召回出了问题，你可以先看 TaoToken 控制台有没有调用记录，有记录说明 Dify 配置没错，问题出在分段或查询改写；没记录说明模型根本没被调起来，直接去查 Dify 的模型配置。这种排查顺序比在 GPUStack 日志里翻半天高效得多。
如果你只是做一次性验证，用在线通道跑完就可以停掉；如果打算长期跑知识库，在线通道还能省掉 GPU 占用的运维成本。本地 GPUStack 继续保留也完全合理，两者不冲突。关键是现在你手里有了量化依据，不会再对着一个「召回成功」的绿色勾发呆。
6.2 下一步：去控制台看这次调用的明细
如果你也想验证自己手里的 Dify 项目，先打开 TaoToken 模型对话，用同一把YOUR_API_KEY发一条测试消息，确认 Key 本身没问题。然后回到 TaoToken 控制台 API Keys 管理密钥。如果准备把知识库正式切到在线通道，可以打开 TaoToken Coding Plan 看看套餐与量级是否匹配。愿意保留 GPUStack 做离线备选也没问题，在线通道和本地部署不冲突，各管各的场景。
