手里有一块算能1684x加速卡一直想把它真正用起来而不是跑个demo就吃灰。前段时间看到腾讯开源了weknora这个RAG知识库项目主打知识图谱和向量检索混着用的路子正好qwen3-vl也出了本地可跑的版本就琢磨着干脆把三样东西串一条完整的链路1684x做本地推理qwen3-vl做文本和视觉理解weknora做带图谱能力的RAG知识库。折腾了几天踩了不少坑但最终跑通的体验是值得的——上传文档或图片之后系统会自动构建知识库问问题的时候既走向量召回也走图谱多跳检索最后由qwen3-vl生成带着依据的回答。这篇文章就把整个部署和连接过程完整捋一遍适合手里有国产算力卡、正在纠结RAG知识库选型、或者想给知识库加图片理解能力的人参考。这套组合的价值在于传统RAG靠向量相似度召回遇到多实体间的关系问答基本会翻车weknora用知识图谱把实体和关系单独建模天然支持关系链推理而qwen3-vl的视觉能力让知识库不再局限于纯文本架构图、流程图、截图都能变成可检索、可追问的知识。放1684x上跑靠的是国产卡本地推理数据不用出内网。1. 先盘清楚这套组合解决什么问题1.1 传统RAG的瓶颈到底卡在哪先说说为什么要用weknora而不是继续用向量数据库embedding那套传统的RAG方案。我在之前一个文档问答项目里用的是常规RAGPDF切块、向量化、召回top-k拼进prompt。表面看挺好用但实际一拷问就露馅。最典型的是多跳问题。比如知识库里有一份系统架构说明、一份接口文档、一份故障记录你问一句A服务调用了B服务B服务最近一次故障会影响哪些下游传统RAG的做法是拿这个问题去做向量检索embedding会把B服务故障相关的段落召回但A服务调用B服务这条关系可能分散在另一篇文档里各自独立的文本块根本没法串联。结果就是答非所问或者干脆说知识库中没有相关信息。另一个问题是分块粒度。切小了丢上下文切大了混进大量噪声向量检索召回的片段经常是看起来相关但信息密度极低。这就是热词里大家常说的rag瓶颈——不是模型不够强是检索阶段就把路走窄了。1.2 weknora的解法把知识图谱焊进RAGweknora的思路和传统RAG有明显区别。它不只用embedding做向量召回而是会在文档入库时额外做一层实体和关系的抽取把谁依赖谁谁属于谁这类结构化关系写进知识图谱。检索的时候用户的问题会被拆成两道工序并行处理一道走语义向量检索找话术上相似的文本块一道走图谱查询找结构上相关的实体和关系路径。两条路的结果汇合、重排之后再一起交给大模型生成答案。这个设计解决了我前面说的多跳问题A调用B、B有故障、B影响下游这些实体关系在图谱里本来就是连着的一跳就能拿到完整路径不需要语义搜索去猜。1.3 为什么这个场景里非要有qwen3-vl和1684xqwen3-vl在这个链路里承担两个角色。第一是常规的文本生成weknora把检索到的上下文拼好之后需要一个大模型来组织语言生成答案这个活儿qwen3-vl能干。第二是视觉理解weknora自己只能对图片做基础的OCR和高层属性识别但要让知识库真正看懂架构图、流程图、产品截图里的细节必须有一个视觉语言模型来做深度描述和问答。1684x则负责让这两件事跑在本地。算能这颗卡的INT8算力约32TOPS、FP16约16TFLOPS在边缘卡里属于相当能打的水平跑2B/4B级别的qwen3-vl量化模型没有问题而且功耗控制在几十瓦级别对机房改造、供电、散热的要求都很宽松。我用它主要是图个数据不出内网文档、图片、问答记录全都在自己机房流转。2. qwen3-vl登上1684X模型选型与转换部署2.1 先认清1684X的能力边界1684X的内存和算力决定了它不是所有尺寸的qwen3-vl都能随便带。qwen3-vl系列我梳理过大致有2B、4B、8B、30B这几档具体以官方发布为准。在1684X上我的经验和建议是模型尺寸是否推荐原因Qwen3-VL-2B强烈推荐显存占用低推理速度快视觉能力够用最稳Qwen3-VL-4B推荐质量好一档量化后可在1684X跑需要控制并发Qwen3-VL-8B及以上不建议即使量化后体积也偏大推理延迟明显适合更大算力卡个人建议先上2B把链路跑通确认weknora的调用、图谱检索、图片理解全都没问题再决定要不要换4B模型。别一上来就想跑大尺寸部署调试的成本会翻倍。2.2 权重准备与ONNX导出qwen3-vl是典型的VLM结构由视觉编码器Vision Transformer语言模型两段组成。部署到1684X上需要把这两段分别转成算能支持的bmodel格式。第一步是先拿到官方权重。从ModelScope或HuggingFace下载注意选择对应的版本比如Qwen3-VL-2B-Instruct。权重目录里能看到config.json区分视觉塔和语言模型部分转换的时候要分开处理。第二步是把模型导出成ONNX。由于视觉塔和语言模型的导出方式不同我是分成两步做的视觉塔直接用transformers的forward逻辑转成静态shape的ONNX语言模型部分按自回归的方式导出输入是token序列输出是logits。这个阶段最需要留意的是prefill和decode两种阶段的动态shape问题建议在导出时锁定max_seq_len例如设为8192避免后续batch处理时shape对不上。2.3 TPU-MLIR转换与bmodel生成算能的工具链TPU-MLIR负责把ONNX转成1684X能跑的bmodel。环境准备比较简单用官方提供的docker镜像即可。核心命令流程# 在TPU-MLIR docker环境中 # 将ONNX模型转换为MLIR中间表示 model_transform.py \ --model_name qwen3_vl_vit \ --model_def qwen3_vl_vit.onnx \ --input_shapes [[1,3,384,384]] \ --mlir qwen3_vl_vit.mlir # 编译为bmodel指定目标芯片BM1684X model_deploy.py \ --mlir qwen3_vl_vit.mlir \ --chip bm1684x \ --quantize BF16 \ --output qwen3_vl_vit.bmodel语言模型部分因为包含大量Attention计算我使用的是混合量化大部分线性层用W8A8的INT8量化关键层如输出层、部分attention层保留BF16以保证回答质量。实际测试下来这种混合方式在1684X上能将模型体积压到可接受范围内推理速度比纯BF16快不少生成质量也没有明显劣化。转换完成后需要写一个加载bmodel并对外提供服务的推理引擎。算能的sophon runtime提供了Python接口参考社区里的LLM服务代码把视觉塔的输出接上语言模型的输入就得到了一个完整的qwen3-vl推理进程。2.4 起一个兼容OpenAI的推理服务weknora对接大模型走的基本都是OpenAI兼容协议。我在1684X所在的机器上跑了一个Python服务暴露/v1/chat/completions接口内部调用sophon推理对外形态和OpenAI官方API一致。这样做的好处是weknora那边的配置成本几乎为零把base_url指过来就行。验证服务的标准动作是先文本后图片# 文本问答验证 curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d {model:qwen3-vl-2b,messages:[{role:user,content:你好}]} # 图片理解验证content中传入图片url或base64 curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d {model:qwen3-vl-2b,messages:[{role:user,content:[{type:text,text:图中有什么},{type:image_url,image_url:{url:file:///path/to/arch.png}}]}]}注意这里model字段写的qwen3-vl-2b这个名字在weknora里也要用一模一样的否则配对不上。3. weknora本地部署一个长图谱的RAG知识库3.1 它和普通RAG知识库的本质区别很多人在热搜词里问kg知识库、rag知识库和结构知识库区分以及应用场景正好借weknora说透这三者的区别。结构化知识库的代表是关系型数据库数据组织在表里查询靠SQL优点是精确、事务性强但前提是数据必须能提前建模成整齐的字段文档类、图片类内容根本塞不进去。RAG知识库狭义上的向量RAG把非结构文本切块、嵌入为向量靠语义相似度召回。好处是部署快什么文档都能扔进去但缺点就是对关系、因果、依赖这类非相似性信息无能为力且答案难以溯源。知识图谱知识库则把内容抽象成实体、属性、关系三元组保存的是网络结构而非文本片段。它非常适合做多跳推理、关系问答、依赖分析但单独使用的时候对口语化问题的适配性差用户随便问一句大白话图谱查询语句很难命中。weknora要做的不是选边而是把RAG和图谱焊在一起向量负责理解问的是什么图谱负责给出关系怎么连最后统一交给大模型生成答案。实际项目中招聘系统里候选人经历与技能的关系、运维平台里服务与主机的依赖关系、研发项目里需求到代码的追踪关系这类关系密集型的知识场景是最能体现它价值的地方。3.2 docker compose一键拉起基础环境weknora的部署相当省心官方提供docker compose方式。我部署时用的核心服务包括weknora主服务API Web UIPostgreSQL保存元数据、图谱结构向量索引服务对接嵌入模型做向量召回Redis缓存和任务队列我的本地部署步骤很简单拉到代码后在项目根目录修改环境变量文件把之前部署的qwen3-vl服务地址填进去然后docker compose up -d拉起所有服务。首次启动会执行数据库初始化自动建好图谱、知识库、文档集相关表结构。前端界面会提供一个知识库管理页面文档上传、分块浏览、图谱可视化都在这里操作。3.3 关键配置项解读weknora的配置集中在环境变量和YAML文件里。我重点关心四个部分嵌入模型配置决定向量召回的质量。默认可以对接本地bge-m3这类国产嵌入模型。如果你和我一样不想再跑一个嵌入服务也可以配置对接外部嵌入API但要注意保证weknora所在机器到嵌入服务之间的网络连通性。LLM配置就是核心的大脑位置也是后面要连接qwen3-vl的地方。基础格式llm: provider: openai_compatible base_url: http://192.168.1.100:8000/v1 model: qwen3-vl-2b api_key: local-dummy-key temperature: 0.3 max_tokens: 2048OIDC配置对应热词里的weknora oidc。它支持用OIDC做身份认证可以对接内部已有的企业统一登录。如果你只是内网自用可以先关闭OIDC或者用客户端模式等真正接入企业环境再开启。存储配置里最需要注意的是向量索引的容量。如果知识库数据量大默认参数可能不够需要提前调整分片大小。我第一次没注意入库三千个文本块之后检索延迟明显上升后来把分片参数改大了一档才恢复正常。3.4 上传文档建库的完整链路weknora的建库过程是这样的上传文件后系统先做格式解析PDF、Word、Markdown、纯文本都支持我测试过一份带多级标题的Markdown和一个混合了图文表格的Word报告然后切分为语义相对完整的文本块。下一步进入图谱抽取阶段这是weknora最出彩的地方每个文本块通过底层语言模型识别出实体如网关服务MySQL订单模块和关系如依赖部署于调用一组三元组写入图谱。与此同时文本块向量化写入索引。文档入库后在Web UI上可以看到图谱节点和连接关系。我第一次导入一份微服务架构文档图谱里自动生成了服务、数据库、消息队列之间的依赖关系整体结构一目了然这还只是文本抽取的结果没用到图片。4. 让qwen3-vl成为weknora的推理大脑4.1 改配置对接把base_url指向1684xweknora对接LLM改的就是上一节的YAML。把base_url改成部署了qwen3-vl服务的那台机器的IP和端口。需要注意三点第一weknora所在容器里访问1684X宿主机的地址不要写localhost要写宿主机在Docker网络中的IP或者直接配置为宿主机内网IP。我第一次就栽在这里容器里访问localhost:8000一直超时。第二model必须和qwen3-vl服务暴露的模型名完全一致。我们在推理服务里注册的名字是qwen3-vl-2bYAML里也写这个字符串大小写和连字符都不能错。第三api_key选填但建议随便填一个非空字符串。部分OpenAI兼容客户端在api_key为空时会直接拒绝请求留一个local-dummy-key能省事很多。改完配置重启weknora服务在UI里发起一轮新的问答尝试。看到回答输出稳定、格式正常就说明连接已经打通。4.2 图片入库回答RAG知识库能存储图片嘛热词里有人问rag知识库能存储图片嘛普通纯文本RAG是存不了图片的但weknora配合qwen3-vl之后可以。做法是双通道第一通道是图片切到文本。上传一张架构图或者流程图weknora先做OCR把图里的文字提取出来但OCR只能拿到字拿不到关系。这一步我让qwen3-vl介入调用它的视觉理解能力把图片翻译成一段结构化的文字描述该图展示订单服务调用支付服务支付服务依赖支付网关二者通过HTTP同步调用。这段描述再作为文本块进入图谱抽取流程实体和关系就自然落到图谱里了。第二通道是问答阶段的视觉追问。用户上传图片并提问这张图里哪个节点最可能是单点瓶颈weknora会把图片交给qwen3-vl做实时视觉推理同时把知识库里相关文档的检索结果作为上下文一起拼给模型。这样既用了图片的视觉特征又用了知识库里已有的历史知识回答比单纯裸调视觉模型可靠得多。这个能力落地后有实用价值。比如把运维架构图、网络拓扑图、产品原型截图都做成可检索的知识问这版改动会影响哪些模块系统会先从图里定位模块再顺着图谱关系把影响面列出来。4.3 混合检索与多跳问答的联动连接完成之后我最关心的是混合检索的实际效果。用我导入的架构文档做了一组测试问如果订单服务的数据库连接池被打满哪些服务的请求会受影响传统RAG可能会召回订单服务出问题的那段文字但说不出影响链。weknora的检索链路里这一步先去向量索引找语义相关的段落确认数据库连接池打满是已知状况然后去知识图谱里查订单服务的入边和出边发现它有入边来自API网关、出边指向消息队列和支付服务再沿着支付服务的出边找到下游的风控服务。最终返回的是API网关—订单服务—支付服务—风控服务这条完整链路。qwen3-vl拿到这些结构化路径后回答不是泛泛而谈而是照着链路把每一步的依赖关系和数据流向都讲清楚。如果你的场景里关系密集程度很高这个联动点就是整套部署的核心价值。向量检索保证知道该找什么代码段落图谱保证知道实体怎么连起来大模型负责把两路证据融合成一段能读、能追查的回答。5. 实测踩坑与调优清单5.1 连接过程中的四个坑坑一容器网络不通。weknora跑在Docker里访问1684X宿主机一定要确认地址可达。我在docker compose的日志里反复看Failed to connect to 8000 port这种报错最后把base_url从localhost改成宿主机的实际内网IP才解决。坑二模型名不匹配。OpenAI兼容协议里请求头发送的model字段要和服务端注册名完全一致。weknora默认的YAML模板里填的是别的模型名照着改就行但很多人会漏掉这一步表现为页面回答直接报错model not found。坑三图片base64体积过大。用qwen3-vl做视觉理解时上传的图片会被编码成base64塞进请求体。如果直接传一张手机拍的几MB照片请求体会膨胀三分之一部分HTTP服务默认限制请求体大小表现为请求直接被拒。建议在weknora的图片处理环节先做压缩统一把长边缩到1536像素以内再交给模型。坑四qwen3-vl服务端的内存清理。跑在1684X上的qwen3-vl服务如果长时间运行ChatGLM类模型常见的KV Cache累积问题也会出现表现是回答越来越慢。建议定时重启推理服务或者在没有官方方案的情况下顺手写个简单的调度脚本凌晨低峰期自动重启一次稳定很多。5.2 推理质量调优的几个方向如果你的知识库问答效果不如预期先别急着怪模型按这个顺序排查。先检查kknowledge库里图谱抽取是否正常。在weknora的图谱可视化页里看看实体和关系是否合理。如果图谱稀疏说明底层抽取模型在切换成qwen3-vl后提示词可能不太适配试着调整抽取阶段的prompt模板让它更贴近你行业术语的上下文。再调检索权重。weknora支持配置向量召回和图谱召回的权重比例。我的经验是文档类型偏技术规范、操作手册的向量权重可以高一些偏关系分析、依赖梳理的图谱权重拉高。通过在config里把两个召回源的top_k分别设置对比几组答案效果选一个合适的比例。最后看上下文拼装。qwen3-vl的上下文窗口有上限weknora默认会把多路检索结果都拼进去。如果发现模型回答时出现尾巴被截断或者只用了前面部分上下文就该降低单路top_k或者启用rerank模块让重排阶段先过滤掉低质量的片段再进prompt能省出宝贵的token空间。5.3 从单机到对外服务的扩展建议跑通基础链路后如果想往生产方向进化可以按热度顺序考虑三件事。第一件是接Dify。热词里不少人查weknora difyweknora本身提供了API接口Dify也有自定义工具能力可以把weknora的检索接口封装成Dify里的工具节点让工作流在Dify里编排。比如先调用weknora检索再让qwen3-vl生成日报摘要或者触发告警时自动去知识库查关联排障文档。这样等于把知识库变成了工作流里的一个可插拔环节。第二件是接OIDC统一认证。如果是要给团队用而不是自己一个人用建议把weknora的OIDC选项打开对接公司的统一身份认证。这一步纯配置工作但能省掉一堆你自己建个密码的管理精力。第三件是用ontology约束图谱。如果你的知识库领域非常固定比如就是设备运维、医疗术语或者法律条文可以用weknora的ontology功能预先定义实体类型和关系类型。约束的好处是图谱抽取会更规范不会出现订单服务依赖支付服务和支付服务被订单服务调用这种表达不统一导致检索漏召回的问题。这也是热词ontology rag的实际落地价值——预先建模领域本体让抽取往既定框架上靠检索阶段的关系路径会更规整。结尾的一点个人体会整套链路跑通的体验和之前单用RAG知识库完全不同。weknora的图谱让知识库从一堆可检索的段落变成了一张能走路的网络qwen3-vl的视觉能力又让这张网能把架构图、截图都织进来。我在实际使用中最大的体会是调试混合检索时先打开weknora的图谱可视化看实体抽取对不对如果实体本身就乱了后面调再多的向量权重也是白费。另外一个小技巧是第一次跑通后立即给整个docker compose目录做个快照备份后面怎么折腾都不会慌。这套组合后续还可以继续扩展比如把1684x再插一块卡做并行推理或者把weknora的检索能力封装成内部API供其他系统调用方向很多但基础就是本文这条链路先把骨架立起来后面每一步都是实打实的增量。