简介面向国产化大模型应用落地场景这份资源提供基于华为昇腾推理服务器和Atlas300IPro加速卡部署Dify平台的完整可运行源码。压缩包共2个文件主要包含inscode工程配置与html说明文档整体仅4KB却精炼覆盖环境准备、MindIE推理引擎部署、Embedding与Rerank接口验证、Dify v0.8.2安装配置等核心要点。inscode文件便于快速导入运行工程html页面则直观展示部署过程和运行效果二者配合可大幅缩短复现路径。已有86人浏览学习适合正在做昇腾适配、Dify私有化部署或信创AI平台验证的开发者直接参考。借助源码与说明读者可快速掌握Dify部署全流程中的关键操作与常见排错思路了解Qwen2.5-7B在双卡环境下的实际运行表现和显存占用情况从而减少从零摸索带来的试错成本加速国产化硬件上大模型应用的落地进程。 我接手的那台 Atlas 800 推理服务器在机房里吃灰了整整两周。驱动、固件、CANN 都装好了MindIE 也能把 Qwen 跑起来但业务方一直在问应用工作台在哪总不能每次让前端直接对着裸模型接口写代码。于是我把 Dify 平台接到昇腾底座上整理出一套可以直接跑的完整方案。这篇不写虚的把可运行源码、核心配置、踩坑记录全部摊开给同样手里握着 Atlas 机器、想快速落地 LLMOps 的同学一条能直接照抄的路。先说结论Dify 本身不需要跑在 NPU 上昇腾算力通过“模型推理服务”这一层喂给 Dify。看懂这句话后面所有配置都好理解了。1. 昇腾环境里跑 Dify先想清楚算力在哪一层1.1 Dify 究竟是什么角色Dify 是开源 LLMOps 平台聊天助手、Agent、工作流、RAG、数据分析这些能力做得非常顺手模型接入、提示词管理、知识库、工具调用、日志观测都被集成在一个可视化界面里。用我自己的话说Dify 是“模型之上的应用层”它负责编排和调度不负责大模型前向推理。这一点非常关键因为很多人一听“昇腾部署 Dify”第一反应是给 Dify 容器装 CANN、改 PyTorch 代码让 Dify 的 Python 服务在 NPU 上跑。方向一开始就错了。Dify 的前端、API、Worker、Sandbox、数据库服务全是常规容器负载它只需要通过网络去调用一个模型接口至于这个接口背后是 NVIDIA 显卡还是昇腾 NPUDify 根本感知不到。1.2 昇腾算力的正确位置真实请求链路是这样的链路层组件昇腾上的角色应用编排层Dify Web / API / Worker / Sandbox普通容器不碰 NPU模型接入层OpenAI-API-compatible桥把昇腾推理服务伪装成 OpenAI API推理引擎层vLLM-Ascend / MindIE在 NPU 上做真正的模型推理芯片层Atlas 300I Duo / Atlas 800T A2算力来源Dify 的模型供应商机制支持任何 OpenAI 兼容接口。昇腾上的 vLLM-Ascend 或者 MindIE 都对外暴露/v1/chat/completions对 Dify 来说这就是一个“换了底座和地址的 OpenAI”。你只需要在 Dify 控制台把 Base URL 指向昇腾推理服务API Key 填任意占位字符串模型名称填昇腾上部署的模型名整条链路就通了。1.3 正确部署顺序先起 Dify 本体包括 PostgreSQL、Redis、API、Worker、Web、Sandbox再在 Atlas 机器上起模型服务最后在 Dify 控制台把 Base URL 指过去。这个顺序有讲究。如果先配模型再接平台一旦出问题你根本分不清是 Dify 配置错了还是推理服务没起来。先把两头各自验证通再接中间一次成功的概率会高很多。我自己第一次做的时候就是先在一个裸容器里把 vLLM-Ascend 跑通curl 验证完模型接口才开始碰 Dify。2. 环境准备驱动、CANN、容器运行时版本和挂载一步都不能错2.1 先认清手里是哪一类昇腾硬件“昇腾系列有哪些 GPU”这个问题被问过太多次。先纠正叫法昇腾的算力芯片不叫 GPU叫 NPU。常见型号差别很大直接影响你能跑什么规模的模型。型号形态显存适合场景Atlas 300I Duo半高推理卡16GB / 48GB 版本7B~13B 模型推理Atlas 300V Pro视频/视觉推理卡较小视频解码、CV 场景不适合长文本 LLMAtlas 800 推理服务器型号 9000整机插多张 300I Duo按卡累计企业级并发推理Atlas 800T A2 训练服务器训练整机单卡 64GB 级别大模型训练也适合 14B 以上推理我实测用的是 Atlas 800 推理服务器两张 300I Duo 48GB。跑 Qwen2.5-7B-Instruct 非常从容max-model-len 给到 8192 也不紧张单卡并发处理 20 个左右请求问题不大。2.2 版本配套宁可多查一遍昇腾软件栈的版本要求比 NVIDIA 严格得多。驱动、固件、CANN、torch_npu、容器运行时必须在一个配套表里面否则装出来会非常诡异有时驱动能看见卡但 CANN 一申请显存就报错有时 CANN 版本没问题但 docke 容器里挂载设备路径不对又浪费半天。我用的组合是驱动/固件 23.0.6 CANN 8.0.RC1。拿到机器先验证npu-smi info cat /usr/local/Ascend/ascend-toolkit/latest/version.cfgnpu-smi info能看到卡的状态和显存总量version.cfg能看到 CANN 版本。新机器开箱后第一件事就是去昇腾社区官网查“驱动-固件-CANN 配套表”别嫌麻烦这一步帮你省下后面至少两天的排查时间。2.3 容器里必须能看到 NPU否则后面全白搭Docker 默认不会把 NPU 设备映射进容器。华为提供了 ascend-docker-runtime装好之后执行docker info | grep -i runtime能看到一个叫ascend的 runtime。如果没有这个 runtime就必须在docker run时手动带设备和目录docker run --rm \ --device/dev/davinci0 \ --device/dev/davinci_manager \ --device/dev/hisi_hdc \ --device/dev/devmm_svm \ -v /usr/local/Ascend/driver:/usr/local/Ascend/driver \ -v /usr/local/dcmi:/usr/local/dcmi \ -v /usr/local/bin/npu-smi:/usr/local/bin/npu-smi \ ascend/vllm-ascend:latest \ npu-smi info先跑通这条最小命令再进下一步。如果容器里看不到davinci0说明设备挂载或 runtime 有问题这时候去排查 Dify 没有任何意义。提示宿主机上npu-smi正常不代表容器里正常。容器缺设备映射时最常见的报错是No such file or directory或Cant open device。3. 模型服务层用 vLLM-Ascend 拉起 OpenAI 兼容接口3.1 为什么选 vLLM-Ascend而不是 MindIEMindIE 是华为原生的推理引擎性能和昇腾硬件贴合度都很高但配置流程明显更重权重要转换、版本要严格对应、文档相对分散。vLLM-Ascend 是社区在标准 vLLM 上加的 Ascend 后端使用习惯和 NVIDIA 生态几乎一致出了问题也更容易在社区里找到答案。如果目标是“赶紧把 Dify 跑起来”vLLM-Ascend 是更顺的路。MindIE 更适合在生产环境做极致性能优化。不过两者对 Dify 来说没有任何区别都是 OpenAI 兼容 API后面 Base URL 的端口不一样而已。3.2 装环境、下模型、起服务准备一个 Python 3.10 环境conda create -n vllm-ascend python3.10 -y conda activate vllm-ascend pip install vllm0.8.4 vllm-ascend0.8.4注意vllm-ascend 对 CANN 版本有要求装之前先看它的 release 说明。我这边 CANN 8.0.RC1 配合这两个版本没有问题。模型用 ModelScope 下载内网服务器拉取速度快pip install modelscope modelscope download --model Qwen/Qwen2.5-7B-Instruct --local_dir /data/models/Qwen2.5-7B-Instruct然后启动推理服务export ASCEND_RT_VISIBLE_DEVICES0 vllm serve /data/models/Qwen2.5-7B-Instruct \ --host 0.0.0.0 \ --port 8000 \ --dtype bfloat16 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --tensor-parallel-size 1参数解读ASCEND_RT_VISIBLE_DEVICES0指定进程用哪张卡作用类似CUDA_VISIBLE_DEVICES。--dtype bfloat16昇腾对 BF16 支持依赖 CANN 版本老版本或部分边缘推理卡不支持时就改成float16。--gpu-memory-utilization 0.9默认就是 0.9。7B 模型 BF16 权重约 14GB48GB 卡上模型加 KV Cache 完全够。16GB 小卡要往下调同时缩短--max-model-len。--tensor-parallel-size 1单卡先跑通多卡并行要处理 HCCL 通信排障顺序不要反。3.3 验证模型服务curl http://localhost:8000/v1/models curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: Qwen2.5-7B-Instruct, messages: [{role: user, content: 你好}] }返回正常的 completion 结果说明模型服务已经能对外服务了。到这一步昇腾侧的核心链路就通了接下来可以安心部署 Dify。4. Dify 平台部署裁剪后的最小可运行 compose4.1 为什么裁剪官方 compose官方 docker compose 里服务非常多API、Worker、Web、PostgreSQL、Redis、Sandbox、SSRF 代理、Plugin Daemon、向量库样样都有。新手直接照搬容易出现某个服务版本冲突或者一堆根本用不上的组件占用资源。我这边裁剪出一套最小闭环PostgreSQL、Redis、Sandbox、SSRF Proxy、Plugin Daemon、Migration、API、Worker、Web。向量存储先用pgvector后续要接外部 Qdrant 再改配置。镜像版本以官方当前最新 release 为准这里用 1.10.1 作为示例。4.2 可运行 docker-composeversion: 3.9 x-common-env: common-env DB_HOST: postgres DB_PORT: 5432 DB_USERNAME: dify DB_PASSWORD: dify DB_DATABASE: dify REDIS_HOST: redis REDIS_PORT: 6379 SECRET_KEY: change-me-to-a-long-random-string VECTOR_STORE: pgvector CODE_EXECUTION_ENDPOINT: http://sandbox:8194 CODE_EXECUTION_API_KEY: dify-sandbox SSRF_PROXY_HTTP_URL: http://ssrf_proxy:3128 SSRF_PROXY_HTTPS_URL: http://ssrf_proxy:3128 PLUGIN_DAEMON_URL: http://plugin_daemon:5002 PLUGIN_DAEMON_KEY: change-me-plugin-key PLUGIN_DAEMON_REQUEST_TIMEOUT: 120 services: postgres: image: postgres:15-alpine environment: POSTGRES_USER: dify POSTGRES_PASSWORD: dify POSTGRES_DB: dify volumes: - pg_data:/var/lib/postgresql/data healthcheck: test: [CMD-SHELL, pg_isready -U dify] interval: 5s timeout: 5s retries: 10 restart: always redis: image: redis:7-alpine volumes: - redis_data:/data restart: always sandbox: image: langgenius/dify-sandbox:latest environment: API_KEY: dify-sandbox GIN_MODE: release restart: always ssrf_proxy: image: langgenius/dify-ssrf-proxy:latest restart: always plugin_daemon: image: langgenius/dify-plugin-daemon:0.0.9 environment: DB_PLUGIN_HOST: postgres DB_PLUGIN_PORT: 5432 DB_PLUGIN_USERNAME: dify DB_PLUGIN_PASSWORD: dify DB_PLUGIN_DATABASE: dify REDIS_PLUGIN_HOST: redis REDIS_PLUGIN_PORT: 6379 PLUGIN_DAEMON_KEY: change-me-plugin-key PLUGIN_DAEMON_PORT: 5002 ports: - 5002:5002 restart: always migration: image: langgenius/dify-api:1.10.1 depends_on: postgres: condition: service_healthy redis: condition: service_started environment: *common-env command: [flask, db, upgrade] restart: no api: image: langgenius/dify-api:1.10.1 depends_on: postgres: condition: service_healthy redis: condition: service_started migration: condition: service_completed_successfully environment: : *common-env MODE: api ports: - 5001:5001 volumes: - storage:/app/api/storage restart: always worker: image: langgenius/dify-api:1.10.1 depends_on: postgres: condition: service_healthy redis: condition: service_started migration: condition: service_completed_successfully environment: : *common-env MODE: worker volumes: - storage:/app/api/storage restart: always web: image: langgenius/dify-web:1.10.1 depends_on: - api ports: - 3000:3000 restart: always volumes: pg_data: redis_data: storage:启动命令很简单mkdir -p /opt/dify-ascend cd /opt/dify-ascend vim docker-compose.yml docker compose up -d docker compose ps如果本地 Docker Compose 版本比较老不支持condition: service_completed_successfully就先去掉 migration 依赖手动执行docker compose exec api flask db upgrade再启动 api 和 worker。4.3 Dify 和模型服务怎么通信Compose 里的 Dify 各服务在默认 bridge 网络里。vLLM-Ascend 如果在宿主机上直接跑Dify 容器访问宿主机局域网 IP 即可如果模型服务跑在另一台 Atlas 机器上Dify 容器访问那台机器的局域网 IP 即可。注意Base URL 千万别写localhost。容器里没有宿主机意义上的 localhost写了必挂。我见过太多人卡在这个问题上。5. 接入昇腾模型控制台配置 OpenAI-API-compatible5.1 添加模型供应商登录 Dify 控制台进入“设置 → 模型供应商”添加OpenAI-API-compatible类型的供应商。要填的字段如下字段值Base URLhttp://192.168.1.100:8000/v1API Key任意字符串例如 ascend-local模型类型LLM模型名称Qwen2.5-7B-Instruct填写之后点“测试”连接成功就可以保存。这个配置的本质就是让 Dify 把昇腾推理服务当成一个 OpenAI 兼容的第三方平台。API Key 填什么不重要因为 vLLM-Ascend 默认不校验但它要求这个字段非空所以给一个占位字符串即可。5.2 先跑通一个最小聊天应用创建一个“聊天助手”应用在提示词编排页面右上角把模型切到刚接入的昇腾模型发送消息。如果正常返回这条“昇腾推理 → Dify 编排 → 用户对话”的链路就算通了。到这里整个部署已经成功。但实际使用中你大概率不只是想要一个聊天框而是想基于昇腾模型的能力做一个真正能落地的应用。5.3 升级成数据分析 Agent很多人搜“dify 搭建数据分析平台”其实昇腾上的大模型完全能撑起这个场景。做法是在 Dify 创建一个 Agent 应用给 Agent 添加一个 SQL 执行工具把数据库连接信息配好然后用户用自然语言提问模型负责把问题转成 SQL、执行查询、总结结果。这套方案跑在 Atlas 上模型本地部署、数据不出内网对数据敏感场景很有价值。部署步骤不会因为加了 Agent 而变化模型还是那一个工具调用由 Dify 的 Agent 编排机制接管昇腾推理服务只负责生成 token不需要知道自己正在帮用户写 SQL。6. 实测踩坑从 NPU 设备映射到对话 400四个高频问题6.1 坑一Dify 容器里访问不到模型服务表现模型供应商测试失败但宿主机上 curl vLLM 接口完全正常。排查链路宿主机执行curl http://localhost:8000/v1/models返回正常。docker compose exec api curl http://127.0.0.1:8000/v1/models连接失败。意识到localhost和127.0.0.1在容器里只代表 Dify 容器自身不是宿主机。把 Base URL 改成http://宿主机局域网IP:8000/v1测试通过。这个坑跟昇腾关系不大但在异构部署里非常典型。记住一条规则容器里的localhost永远只代表容器自身。6.2 坑二容器里看不到 NPU 卡表现vLLM-Ascend 启动时报davinci0不存在或者容器内执行npu-smi info没有任何输出。排查链路宿主机执行npu-smi info正常显示卡信息说明驱动没问题。执行docker info | grep -i runtime发现没有 ascend runtime。安装 ascend-docker-runtime并在启动容器时指定--runtime ascend。容器内再执行npu-smi info一切正常。教训不要在容器启动参数上省时间。先跑一个最小验证镜像确认容器内能看到 NPU再去跑 vLLM、Dify 这些上层应用否则问题会被层层包装成各种莫名其妙的报错。6.3 坑三vLLM-Ascend 启动时显存不够表现启动时报No available memory for the cache或者模型起来了但对话一长就报超长。排查链路npu-smi info查看单卡 HBM 总量和当前占用。估算权重占用7B BF16 约 14GB14B BF16 约 28GB。如果 48GB 卡连一个 7B 都跑不起来检查ASCEND_RT_VISIBLE_DEVICES是否指向了一张已经被别的进程占用的卡。适当缩小--max-model-len比如从 8192 降到 4096KV Cache 占用会明显降低。经验是先保证模型服务自身有余量再谈并发。7B 模型在 48GB 单卡上开 8K context留 0.9 的显存利用率日常测试完全够用真要上生产再根据并发峰值做压测。6.4 坑四连接成功但对话报 400表现模型供应商测试通过应用内对话却报 400 或者一直转圈。排查链路执行docker compose logs -f api日志里大概率有上游推理服务返回的 4xx 信息。检查 Dify 里填的“模型名称”和 vLLM 端实际部署的模型名是否一致。检查请求 token 数是否超过 vLLM 的--max-model-len。在生产环境中建议给 vLLM 显式指定--served-model-name Qwen2.5-7B-InstructDify 里填同样的名称两个服务之间的模型名就永远对齐了。这四个坑基本覆盖了我第一次打通昇腾 Dify 链路时遇到的主要问题。解决之后整条链路稳了很多后面就是按团队加权限、接企业知识库、做更复杂的 Agent 编排这些业务层面的演进已经不属于部署链路的范畴。最后分享一个生产小技巧把 vLLM-Ascend 的启动命令封装成一个 systemd unit机器重启后自动拉起。Dify 那边只要 Base URL 不变模型供应商配置就完全不用动。昇腾 Dify 这套组合跑起来之后团队里不懂部署的人也能通过界面搭 Agent这才是平台化部署真正的价值。本文还有配套的精品资源点击获取