这块算能1684x落地了一个挺让我有成就感的事儿把腾讯开源的RAG知识库weknora在本地跑起来再让它调用部署在1684x推理卡上的qwen3-vl多模态大模型最终形成一个既能问答文档、又能“看懂”图片的私有知识库系统。整套链路从硬件适配、模型转换到平台对接踩了不少坑也理清了不少之前被自媒体含糊带过的概念比如RAG知识库和结构化知识库KG到底什么关系、知识库能不能存图片、weknora和dify这类平台有什么区别。这篇文章就把我的完整实施过程拆开来讲适合手里有算能1684x设备、想把多模态模型和RAG平台串起来用的朋友也适合只想本地快速搭一套weknora试水的初学者。1. 项目整体拆解三个组件分别扮演什么角色1.1 这个组合到底在解决什么问题先说一个很常见的痛点企业内部有一大堆产品手册、技术文档、合同扫描件甚至还有大量带截图的培训材料。传统RAG方案只能给文本做向量化和检索遇到图、表格、产品外观图这类信息要么直接丢掉要么塞一个OCR结果体验非常割裂。这个问题在行业里经常被拿来讨论尤其是“RAG知识库能存储图片嘛”这个疑问很多平台文档里根本没有讲清楚。我这次做的方案本质上就是三条线叠加算能1684x提供本地推理算力qwen3-vl负责把图像信息变成模型真正能理解的内容weknora则承担知识库管理、检索和对话编排。最终效果是你上传一份带截图的运维手册问“第三页那张拓扑图里标注了哪几个端口”系统能真的找到那张图并让qwen3-vl看图回答而不是只靠文件名猜。从架构上说weknora是整个系统的“大脑皮层”负责调度检索、历史会话和权限而1684x上的qwen3-vl服务是“神经元”专门处理生成和理解。把两者连起来之后后续新增知识、调整检索策略、配OIDC账号体系都只操作weknora一个入口就行不太需要动到底层模型服务。1.2 组件的角色分工与整体架构把三个组件放在一起看结构其实很清晰算能1684x推理硬件底座。它是一颗AI推理加速处理器跑在PCIe插槽上一般配备16GB显存。我们没有用NVIDIA卡主要是考虑国产化环境、整机功耗和成本。qwen3-vl视觉语言模型。它接收文本和图像两种输入输出文本。在我们场景里它既要回答纯文本问题也要根据图片内容做描述、分析和推理。weknora腾讯开源的RAG知识库平台。负责文档解析、分块、向量入库、检索召回、上下文组装以及对外提供对话API和Web管理界面。整个数据链路走起来是这样用户通过weknora界面提问weknora先对问题做处理和向量化在知识库中检索最相关的文本块或图片描述再把命中内容连同原图一起打包传给qwen3-vl生成答案。生成完的答案回到weknora界面展示同时保留引用来源。整体架构也可以理解为“前后端分离”前端体验和知识管理完全交给weknora模型能力全部走1684x内部的推理服务。后续如果模型升级只需要替换1684x上的bmodel和tokenizer不牵扯知识库重装。1.3 为什么选算能1684x而不是普通服务器有人会问qwen3-vl这种模型为什么不直接跑在CPU上或者干脆买张消费级显卡我个人的看法是1684x的优势不在“绝对算力”而在于“可控的本地化部署形态”。它的板卡功耗比同级别GPU低一截在机架式服务器里散热压力小适合长年7x24小时跑知识库推理。更重要的是国产化硬件在部分行业里是硬性要求算能1684x已经有不少成熟的部署工具链尤其是TPU-MLIR这套编译器能把Hugging Face上的开源模型转换成1684x专用的bmodel格式。虽然转换过程比NVIDIA的TensorRT要折腾一些但做过一遍之后后续换模型会顺畅很多。当然也要正视1684x的瓶颈它毕竟不是为超大模型设计的Qwen3-VL如果是7B以上模型建议做INT8或低比特量化否则16GB显存会非常紧张。这一点我会在模型适配部分详细展开。2. 1684x硬件与环境初始化2.1 硬件形态与规格确认先确认你手里的板卡形态。算能1684x最常见的是标准PCIe卡有些一体机也会做成BOX形态但无论哪种核心都是BM1684X这颗芯片。部署前我建议先看清楚三个信息板卡内存容量、SDK版本、散热方式。以我用的PCIe卡为例标称16GB内存双槽位。安装时要注意服务器PCIe供电是否足够部分老主板给PCIe插槽的供电上限不高满载推理时可能触发降频。如果你手头是带外置电源的版本记得把辅助供电插上不然跑大模型时容易莫名其妙掉卡。系统方面我用的是Ubuntu 20.04内核5.4以上。算能官方对CentOS也有适配但社区样例更多基于Ubuntu建议非特殊要求直接上Ubuntu。另外整个环境建议放在独立宿主机或专门虚拟机里避免和业务容器抢占内存。2.2 驱动、运行库与工具链准备1684x不像NVIDIA那样装个驱动就有CUDA它需要一套完整的软件栈包括内核模块、用户态运行库、Python绑定和编译器。我安装时按下面这个顺序来备齐安装PCIe驱动确认/dev/bm-soct节点出现。安装BMNNSDK通常会包含libbmrt、libsail、bmminer等组件。安装Python绑定推荐在虚拟环境里装sail和bmruntime避免污染系统Python。获取TPU-MLIR工具链后续模型转换要用。具体安装命令各版本差异较大我不建议直接复制网上的某条命令而是从算能官网下载对应SDK包解压后看install.sh里的说明。装完后第一件事就是把bm-smi跑起来确认卡的状态是正常、利用率是0、温度不超过警戒值。启动模型前还有一件容易被忽略的事检查系统大页内存配置。1684x推理时对内存连续性有一定要求我建议把/etc/sysctl.conf里的vm.max_map_count调大到65530同时给Docker设置--shm-size8g否则容器内加载bmodel会报内存映射失败。2.3 用 bm-smi 验证硬件状态bm-smi相当于NVIDIA的nvidia-smi但输出维度比较精简。我习惯跑起来之后看三列芯片温度、内存占用、以及当前算力利用率。bm-smi如果第一行显示的芯片型号是BM1684X、内存是16GB说明硬件识别正常。再看驱动版本和TPU-MLIR版本是否匹配通常要求驱动版本尽量新。如果驱动和编译器版本相差太多后续转出来的bmodel可能加载失败报错多数是“unsupported bmodel version”。还有一个细节1684x支持多卡如果服务器插了两张卡bm-smi会显示两个设备ID。weknora对接模型服务时要注意你的推理服务到底绑定了哪张卡最好在服务启动参数里显式指定设备ID否则可能所有请求都堆到第一张卡上。3. Qwen3-VL模型适配与部署3.1 模型选择与量化位宽判断Qwen3-VL系列有很多尺寸从2B到几十B不等。1684x的16GB显存跑FP16的8B模型基本到极限而且还要给KV Cache留空间所以我在实际项目中优先选了量化方案。简单算一笔账8B模型FP16权重约16GBINT8约8GBINT4约4GB。考虑到知识库场景需要较长上下文和多轮对话KV Cache和图像token还会额外占用内存INT8是比较稳妥的折中。如果你是第一次试我甚至建议先拿Qwen3-VL-2B或4B的量化版跑通全链路确认weknora对接无误后再换大模型。因为模型转换和推理服务出问题时排查成本会随着模型体积直线上升先用小模型验证逻辑能省大量时间。另外要留意模型权重来源。最好从模型官方仓库下载不要随便用第三方转换过的版本。官方权重结构清晰导出ONNX时不容易踩坑。下载后先核对md5再自己转一遍确保bmodel来源可信。3.2 用TPU-MLIR完成ONNX到bmodel的转换这个环节是1684x部署中最容易让人劝退的部分。整个链路是PyTorch权重 - ONNX - MLIR - bmodel。我们既可以用官方或社区给出的ONNX导出脚本也可以自己导出。转换过程中有几个关键参数必须根据实际情况设置--model_name自定义名称影响输出文件名。--model_def输入ONNX文件路径。--input_shapes必须显式声明输入shape视觉模型通常包含图像输入和文本输入。--chip固定为bm1684x。--quantize选INT8或FP16不能不做量化直接上板。我用的示意命令如下model_transform.py \ --model_name qwen3vl_8b \ --model_def qwen3vl_8b.onnx \ --input_shapes images:1,3,448,448;input_ids:1,2048;attention_mask:1,2048 \ --mlir qwen3vl_8b.mlir model_deploy.py \ --mlir qwen3vl_8b.mlir \ --quantize INT8 \ --chip bm1684x \ --model qwen3vl_8b_bm1684x_int8.bmodel这里有个非常关键的直觉input_shapes里的最大序列长度本质上是“内存上限的约束”。如果你把2048改成8192bmodel文件会大很多甚至可能编译失败。知识库场景常见单轮上下文在2000 token以内我建议先把上限压到2048跑通实测若出现长度不够的报错再逐步放宽。图像尺寸同理qwen3-vl默认支持448分辨率强行上更高分辨率会成倍增加视觉token数量内存压力很大。转换过程有点像一个重型编译任务非常吃CPU和内存。我第一次转7B模型时用了24核32GB内存的机器编译了将近四十分钟。中间有几个告警大意是“某些算子被拆分成子图”只要不报ERROR一般都能用。3.3 推理服务化提供OpenAI兼容接口转换出bmodel只是第一步真正给weknora用还得把模型封装成一个服务。weknora这类RAG平台大多兼容OpenAI接口格式所以我直接给qwen3-vl推理服务包装成POST /v1/chat/completions的HTTP接口内部再根据messages里的文本和图片URL去做多模态拼接。服务实现的核心逻辑不复杂但对细节要求高接收请求后判断消息中是否包含image_url字段。如果有图片底层加载图片并按qwen3-vl要求做预处理和视觉token编码。将文本token与视觉token拼接成完整输入序列。循环调用BMRuntime做自回归生成直到遇到结束符或达到max_tokens。返回OpenAI格式的choices[0].message.content。我提供一个简化版启动命令示意python -m qwen3vl_server \ --bmodel qwen3vl_8b_bm1684x_int8.bmodel \ --tokenizer qwen3vl_tokenizer \ --port 8080 \ --device_id 0 \ --max_tokens 2048 \ --temperature 0.7这里temperature不要设置太高。知识库问答讲究准确和稳定温度太高容易让模型编造内容也就是RAG场景常说的“幻觉”。我实际调到0.2到0.3之间真实感和约束力都比较好。另外一点实践经验服务端显式加载bmodel需要几秒到几十秒不等不要用简单的liveness探针过早杀掉服务。对外服务时我加了一个GET /health只在模型真正load完成后返回200。4. WeKNORA知识库平台本地部署4.1 克隆项目与基础组件准备腾讯开源的weknora主打“开箱即用 私有化部署”和dify、fastgpt这类平台定位类似但更强调RAG链路的可控性。它支持文档型RAG知识库也预留了结构化知识库的扩展点这在后面4.4节细说。我拿到项目后第一步是拉代码并查看目录结构。git clone https://github.com/your-repo/weknora.git cd weknora仓库里一般会带docker、config、frontend、backend等目录。我最关注的是docker下的编排文件和配置模板因为它决定了整套平台用哪些中间件。weknora依赖的组件主要包括应用后端、Web前端、对象存储MinIO、MySQL/PostgreSQL以及一个向量数据库。向量数据库可选方案很多从ElasticSearch到Milvus、pgvector都有对应支持。考虑到1684x主机上资源有限我会把向量库和对象存储都放在同一台机器上跑但容器之间做网络隔离和资源限制。这里顺便回答一个很多人关心的点weknora本地部署是不是一定要GPU并不是。平台本身跑的是RAG流程管理模型调用走外部API所以用一台普通Linux服务器甚至Mac上的Docker都能启动。真正吃GPU的是1684x上的qwen3-vl服务但那是独立组件不需要和weknora共享显卡。4.2 编辑 docker-compose 与配置管理部署前最重要的动作是检查配置模板。我建议先把.env文件复制出来然后逐个变量理解用途。常见的配置项有数据库连接信息和账号密码。向量数据库的地址和集合名称。MinIO的AccessKey和SecretKey。模型Provider配置包括base_url、api_key、model_name。OIDC相关的issuer、client_id、client_secret。对于首次部署我的建议是所有密码先用默认值等启动成功后再统一修改。因为如果一上来就改一堆变量很难判断是哪个配置导致启动失败。我第一次部署时把密码改得很复杂结果数据库容器反复重启排查了半天才发现是特殊字符被解释器转义了。docker-compose启动命令一般是cd docker docker compose up -d启动后观察日志。重点关注应用后端是否成功连接MySQL、向量库是否创建索引、MinIO是否初始化桶。如果某个服务一直处在restarting状态就用docker compose logs -f service查看具体报错而不是盲目重装。4.3 启动与初始化所有容器都起来之后访问Web管理界面通常是http://localhost:8080或配置里指定的端口。首次进入一般会要求创建管理员账号或者用默认账号登录。这一步做完后先别急着建知识库我建议先做两件事在“系统设置”里确认模型Provider是否显示为已连接可以发起一个测试对话。在“知识库管理”里创建第一个测试知识库上传一两篇文档验证解析和向量化是否正常。如果测试对话走不通后续建再多知识库也是白费。这个阶段我一般会把模型服务端的temperature临时调成0输出完全确定性结果方便判断到底是检索问题还是生成问题。4.4 RAG知识库 vs 结构化知识库的配置思路这是一个值得专门聊透的话题。很多人把RAG知识库等同于“所有知识”但严格来说RAG知识库处理的是非结构化文档比如PDF、Word、Markdown内部以文本块为单位做向量化。而结构化知识库也就是常说的知识图谱KG处理的是实体、属性、关系比如“A公司持有B公司60%股份”这样的三元组存储和检索逻辑完全不同。weknora在这块做了区分设计普通文档走RAG流程快速但缺乏严格的逻辑关系如果需要处理强关系的业务数据建议创建KG知识库用本体Ontology约束实体类型和关系类型再通过图查询或混合检索来召回。我在项目里就是这么分工的产品手册、操作说明书走RAG知识库企业架构和权限关系走结构化知识库。qwen3-vl只负责最终答案生成中间检索逻辑则由weknora根据知识库类型分别调度。从“应用场景”角度我把两者的适合场景整理成一个表方便你快速对号入座对比维度RAG知识库结构化/KG知识库数据形态PDF、Word、图片、网页等非结构化内容三元组、图谱、表格等结构化数据检索方式向量相似度检索 关键词召回图遍历、关系查询、混合检索适合场景知识手册、FAQ、公告、多模态资料组织架构、因果链条、产业链关系建设成本门槛低上传即可用需要设计本体、实体抽取、关系清洗回答准确度依赖分块和文本质量对逻辑关系回答更严谨如果预算充足实际生产环境往往是两者结合先用RAG做初步召回再根据问题意图走KG校验关系链。但这个项目第一步我建议先把RAG跑顺再逐步引入结构化知识库。5. 连接WeKNORA与Qwen3-VL多模态问答链路打通5.1 模型接入配置weknora里的模型配置是整个对接的钥匙。在平台的后台配置中新增一个自定义模型Provider选择OpenAI兼容协议填三个关键字段Base URL填http://1684x所在IP:8080/v1。API Key本地服务可随意填比如sk-local但字段不能空。Model Name填服务启动时定义的模型名称比如qwen3vl_8b。这里最容易出错的是“多模态能力的声明”。weknora如果只把这个模型当作纯文本模型就永远不会把图片传给qwen3-vl。需要在模型配置里勾选或声明vision/multimodal能力。不同版本的weknora入口可能不同但本质上都是给模型打一个“支持图片输入”的标签。配置完成后我建议直接在weknora的对话页面发一条纯文本消息测试连通性比如“你好介绍一下你自己”。如果返回正常再发一条带图片的消息。5.2 创建多模态知识库并上传文档/图片接下来进入重点场景让知识库支持图片存储与检索。weknora本身是一个知识管理平台文件会落到MinIO对象存储里所以“RAG知识库能不能存图片”这个问题答案是能而且这正是多模态RAG的关键。但“存储”只是第一步。知识库真正要解决的是“检索到相关图片”。纯文本向量库无法直接把图片像素变成可检索向量除非你配了图片向量嵌入模型。我用qwen3-vl的方案是在上传图片时先调用qwen3-vl为每张图片生成一段详细描述把描述文本存入RAG索引原始图片文件存到MinIO并建立文件名与文本块的关联关系。实际操作中上传一个PDF文件可能包含内嵌截图。weknora解析PDF时会先提取页面文本再把图片区域分离出来送入多模态模型。分离出的图片如果清晰度较高qwen3-vl能提取出图中关键文字和结构。这一步耗时较长通常一张图需要1到3秒上传大量图片时建议用异步任务队列不要在前端页面干等。5.3 复杂问答链路检索、重排、生成链路打通后真实问答效果取决于三个环节的质量。第一个环节是“召回”。weknora默认对用户问题做向量化后在知识库内检索TopK我建议先用TopK5起步。召回质量低通常表现为明明知识库里有答案却答不到点上。这时候优先看分块粒度而不是急着换embedding模型。第二个环节是“重排”。如果召回结果太杂可以在weknora里开启重排序功能让模型或专用重排模型对候选结果重新打分。我用了关键词向量混合召回再交给qwen3-vl做最终判断效果比纯向量召回要好很多。第三个环节是“上下文组装”。对于多模态RAG命中文本块可能对应一张图片。weknora在组装上下文时会把图片的临时URL或文件路径一并传给qwen3-vl。qwen3-vl看图后给出的答案会明显比只看图片描述更准确因为它能直接读取图中细节。这里有一个RAG问答常见的瓶颈上下文窗口有限被检索出来的图片不能无限塞进去。一次性给模型传3张高清图就会超出token预算。我在项目中做了个策略先用描述文本召回图片再按相关度最多传入2张原图其余图片只保留描述文字。实测效果稳定也不会撑爆KV Cache。5.4 可选接入OIDC与多人协作知识库做出来不只是一个人用想在公司内部多人协作建议直接对接OIDC。weknora对OIDC支持比较完整配置时重点确认三处WELL_KNOWN_URL指向身份提供方的配置地址。CLIENT_ID和CLIENT_SECRET在身份平台申请。回调地址需要填weknora的实际访问地址。布尔逻辑上OIDC登录和本地账号可以并行。实际部署时我给内部人员开了OIDC管理员保留本地密码方便紧急情况下直接登录。OIDC配置出问题最典型的现象是“登录页跳转循环”绝大多数是回调地址没填对或者身份平台不允许该回调域。建议先用本地模式把全流程跑通再切OIDC可以把排查范围缩小一半。6. 实施过程中的高频问题与排障6.1 常见问题速查表写代码跑服务踩坑是必然的。我把这次实施中遇到的典型问题统一整理成速查表方便大家按图索骥现象可能原因解决办法bm-smi看不到设备驱动未加载或PCIe识别异常重新安装驱动确认板卡供电bmodel加载失败bmodel与驱动版本不匹配升级SDK/驱动重新编译bmodel模型服务启动慢bmodel文件大初始化耗时增加health检查超时时间weknora容器反复重启数据库连接串错误检查.env中的密码特殊字符测试对话无响应base_url漏了/v1核对Provider地址上传图片后检索不到图片未走多模态描述流程确认模型已声明vision能力回答丢内容上下文窗口长度不足降低TopK减小传入图片数登录页循环跳转OIDC回调地址错误核对身份平台回调配置6.2 1684x模型转换时间/内存异常模型转换是最容易让人心态炸裂的环节。我第一次转Qwen3-VL-8B时直接爆了内存编译器进程被系统OOM Kill。后来我老老实实把机器内存加到32GB才稳定。如果你机器内存有限可以把input_shapes里的序列长度调小或者改用4B模型。这不算退让部署本来就要根据硬件底座的规格来匹配模型。另一个坑是转换临时目录空间不足。bmodel编译过程中会产生大量中间文件建议磁盘预留至少模型本身大小的3到5倍空间。我第一次没注意结果编译到90%时磁盘写满前功尽弃。如果你对转换流程不够熟悉还有一个取巧路径相关技术社区和模型广场偶尔会有别人编译好的1684x版本bmodel可以省掉编译环节。但请务必确认bmodel的来源和预期行为并且尽量复现一次编译避免被后门或恶意改动的模型坑到。6.3 知识库回答不准确/检索不到图片知识库回答不准先别怀疑模型智商大概率是检索链路有问题。常见是分块过小导致上下文切断或者分块过大导致语义混杂。对于图文场景我的经验是图片的描述文本要和图片文件本身强关联建议把“图片文件名描述文本所属章节标题”放进同一个文本块检索时相关性更高。如果检索结果明明有描述但答案还是不行那多半是上下文组装时图片URL没传到底层模型。这时可以在weknora的后端日志里看发给模型的payload确认image_url是否出现在请求体内。这一步排查能快速判断问题在编排层还是模型层。6.4 我个人在实操之后的体会老实说做完这个项目最深的体会是技术链路的难点不在某一环而在“打通”本身。1684x的模型转换有门槛但只要有耐心读官方文档基本能跑通weknora的部署难度并不高难的是理解RAG和KG的区别以及知道自己需要哪一种知识库qwen3-vl的接入看似只是填个URL但多模态能力是否被真正启用直接决定了系统是“图库”还是“知识库”。如果你也想照着做一遍我建议按“先小后大、先文本后图片、先本地后OIDC”的顺序来。先用Qwen3-VL-2B量化版配合weknora跑通纯文本问答再切到8B并开启图片描述等全部稳定后再接入OIDC和多人协作。这样每个阶段的排障半径都很小不会一上来就被各种问题淹没。最后再分享一个小技巧把weknora和1684x模型服务的运行日志都接到同一个集中日志目录按时间戳排好。排障时先看模型服务日志再看weknora编排日志基本能在两轮日志翻找内定位绝大多数问题。这套组合我已经实际跑了几周稳定性和效果都能接受希望这篇文章能帮你少走那些我已经替你蹚过的弯路。