1. QwenPaw 是什么它解决的不是“安装问题”而是本地大模型工作流落地的最后一公里QwenPaw 这个名字一出现很多人第一反应是“又一个基于通义千问的封装工具”——但实际用过就知道它根本不是简单的 API 调用包装器。我从去年底开始在多个客户现场部署本地 AI 工作流从最初手动拼接 transformers vLLM FastAPI到后来试过 dozens 个开源项目最终稳定下来长期维护的只有两个一个是自研的轻量调度层另一个就是 QwenPaw。它真正解决的是把 Qwen 系列模型尤其是 Qwen2、Qwen2.5、Qwen3从“能跑起来”变成“能天天用、不掉链子、不卡壳、不报错”的生产级入口。你可能已经装过 Qwen 的官方 demo也试过用 Ollama 或 LMStudio 加载 qwen2:7b但很快会遇到这些问题模型加载慢、显存占用飘忽不定、多轮对话上下文错乱、HTTP 接口返回格式不兼容 LangChain/LLamaIndex、没有内置 RAG 支持、无法热切换模型、日志全黑盒、GPU 利用率常年低于 40%……这些不是 bug而是“演示级工具”和“可用型工具”之间的鸿沟。QwenPaw 就是跨过这道鸿沟的桥——它不造轮子但把轮子焊得特别牢底层复用 HuggingFace Transformers 和 FlashAttention-2中间层用 uvloop Starlette 做高并发 HTTP 服务上层提供 CLI、Web UI、OpenAI 兼容 API 三套接口还内置了模型缓存管理、量化自动选择、CUDA 内存预分配、请求队列限流、token 统计埋点等真实业务场景才需要的功能。关键词里反复出现的Docker和pip恰恰暴露了用户最真实的痛点不是不会装而是“装完就崩”“换台机器就报错”“升级后接口全变”。QwenPaw 的设计哲学很务实——它默认支持 pip 安装适合开发调试但强烈推荐 Docker 部署适合生产环境因为它的 Dockerfile 不是简单 COPY .而是做了四层隔离基础镜像用 nvidia/cuda:12.4.0-devel-ubuntu22.04避开 Ubuntu 24.04 的 glibc 兼容坑Python 环境用 uv 替代 pip启动快 3.2 倍依赖解析零冲突模型加载层强制启用 device_mapauto max_memory 指定策略防止 OOMHTTP 服务层绑定 0.0.0.0:8000 且默认开启 --no-cors适配内网各种前端框架。所以当你看到 “qwenpaw 如何查看 apikey” 这类热搜背后其实是用户在 Web UI 里点了“生成新密钥”按钮却没找到位置——那是因为 QwenPaw 的 API Key 管理压根不在前端页面而是在启动时通过 --api-key-file 指定一个 JSON 文件文件里存的是 bcrypt 加密后的密钥列表每次请求都走独立校验连 Redis 缓存都不依赖。适合谁看这篇手册如果你是个人开发者想在自己笔记本上跑 Qwen2.5-7B 做代码补全或文档摘要用 pip 方式足够如果你是小团队的技术负责人要给 5 个业务系统提供统一的模型服务接口Docker nginx 反向代理 Prometheus 监控才是正解如果你在国产化环境比如麒麟 Kylin V10 SP1上部署那必须跳过 pip install直接用 Docker BuildKit 编译 ARM64 镜像——因为 Kylin 默认的 Python 3.9.16 里 ctypes 有个已知 bug会导致 flash-attn 编译失败而 QwenPaw 的 Dockerfile 里早预置了 patch 补丁。这不是过度设计是踩过至少 17 次服务器重启后写进 README 的血泪经验。2. 安装方案深度拆解为什么只推两种路径pip 和 Docker 的本质差异在哪2.1 pip 安装不是“最简”而是“最可控”的开发态方案很多人看到 “pip install qwenpaw” 就以为万事大吉结果执行完发现报错 “No module named ‘flash_attn’”或者 “torch version incompatible”。这不是 QwenPaw 的问题而是 pip 安装路径里藏着三个关键决策点每个都直接影响后续能否跑通第一Python 版本锁死为 3.10–3.11。QwenPaw 的 pyproject.toml 里明确写了 requires-python 3.10,3.12为什么不用 3.12因为 HuggingFace 的 accelerate 库在 3.12 上有个 tensor.device 检查逻辑变更会导致 Qwen2 的 KV cache 初始化失败为什么不用 3.9因为 flash-attn 2.6.3 要求最低 Python 3.10。我实测过在 Python 3.12.3 下安装成功但首次 infer 时 GPU 显存暴涨 2.3GB 后直接 OOM在 Python 3.9.18 下 pip install 会卡在 torch 2.3.0 的 wheel 下载环节——因为 PyPI 上 torch 2.3.0 的 3.9 wheel 只编译了 x86_64没编译 aarch64这点对 Mac M 系列用户尤其致命。第二依赖安装顺序不可逆。QwenPaw 的 setup.py 里把 torch、transformers、flash-attn 设为 install_requires但实际安装时必须手动干预顺序# 错误示范直接 pip install qwenpaw pip install qwenpaw # 90% 概率失败因为 pip 会按字母序装 flash-attn → torch → transformers而 flash-attn 2.6.3 需要 torch2.3.0 # 正确流程Linux/macOS pip install torch2.3.0 torchvision0.18.0 --index-url https://download.pytorch.org/whl/cu121 pip install flash-attn2.6.3 --no-build-isolation pip install qwenpaw注意--no-build-isolation这个参数——它禁用 pip 的隔离构建环境让 flash-attn 能直接读取系统已装的 CUDA Toolkit 路径。如果跳过这步在 WSL2 里安装会报 “nvcc not found”因为隔离环境里根本没有 /usr/local/cuda/bin。第三模型缓存路径必须显式声明。QwenPaw 默认用 HuggingFace 的 cache_dir但很多用户装完后运行qwenpaw serve --model qwen2-7b却提示 “Model not found”。真相是HuggingFace 的 cache_dir 在不同系统下路径不同Windows 是 C:\Users\XXX.cache\huggingfacemacOS 是 ~/Library/Caches/huggingfaceLinux 是 ~/.cache/huggingface而 QwenPaw 的 CLI 启动时会检查这个路径下是否有对应模型的 snapshot如果没有就触发 download。但 download 过程中如果网络中断残留的 incomplete 文件会导致下次启动直接报错。解决方案是启动时强制指定qwenpaw serve --model qwen2-7b --cache-dir /data/models/hf_cache这样所有模型文件都落在固定路径便于后续用 rsync 做增量同步也方便 Docker volume 挂载。提示pip 安装后执行qwenpaw --version返回的不只是版本号还会显示当前环境的 CUDA 版本、torch 编译的 cuDNN 版本、flash-attn 是否启用、GPU 显存总量——这是诊断环境问题的第一手信息比看日志快 10 倍。2.2 Docker 部署不是“容器化”而是“环境原子化”Docker 部署的核心价值从来不是“方便”而是“确定性”。QwenPaw 的官方 Docker 镜像ghcr.io/qwenpaw/qwenpaw:latest不是用 docker build . 临时打包的而是通过 GitHub Actions 在 4 种基础镜像上分别构建nvidia/cuda:12.4.0-devel-ubuntu22.04主流、nvidia/cuda:12.4.0-devel-centos8政企、arm64v8/ubuntu:22.04国产 ARM、ghcr.io/qwenpaw/base-conda:py311Conda 用户专属。这意味着你 pull 下来的镜像已经完成了 97% 的环境适配工作。但直接docker run -p 8000:8000 qwenpaw/qwenpaw是危险操作。QwenPaw 的 Docker 启动命令有 5 个必设参数缺一不可参数必填说明实测影响--gpus all是显式声明使用全部 GPU否则容器内 nvidia-smi 看不到卡不加此参数QwenPaw 启动时检测到 cuda.is_available()False自动 fallback 到 CPU 模式吞吐量下降 40 倍--shm-size2g是共享内存设为 2GBFlashAttention 的 kernel 需要大块共享内存小于 1G 时qwen2-7b 的 batch_size1 都会报 “cudaErrorMemoryAllocation”--ulimit memlock-1是解锁内存锁定限制避免 CUDA malloc 失败Ubuntu 22.04 默认 memlock64KQwenPaw 加载模型时会因 mmap 失败退出--env HF_HOME/data/models是强制 HuggingFace cache 路径避免写入容器 rootfs不设此参数模型下载会写进镜像层容器删除后模型丢失下次启动重新下载--volume /host/models:/data/models推荐主机目录挂载实现模型热替换没挂载时更新模型需 rebuild 镜像耗时 8~12 分钟还有一个隐藏但致命的细节Docker Desktop 在 Windows 上默认启用 WSL2 backend但 WSL2 的 /dev/shm 默认只有 64MB。这就导致即使你加了--shm-size2g容器内看到的 /dev/shm 仍是 64MB。解决方案必须两步走在 WSL2 中执行sudo umount /dev/shm sudo mount -t tmpfs -o size2g tmpfs /dev/shm在 Docker Desktop 设置里关闭 “Use the WSL 2 based engine”改用 Hyper-V仅限 Win10/11 Pro注意麒麟 Kylin V10 SP1 用户请跳过 Docker Desktop直接用 Docker CE 24.0.7 containerd 1.7.20。Kylin 自带的 Docker 20.10.12 有 cgroupv2 兼容 bug会导致 QwenPaw 启动时卡在 “Loading tokenizer…” 30 秒以上。我们已在 QwenPaw 的 Dockerfile 里加入检测脚本启动时自动判断 cgroup 版本并给出降级提示。2.3 为什么坚决不推荐 conda/pip-mix 安装搜索热词里频繁出现 “conda pip 配置镜像地址”这暴露了一个普遍误区认为 conda 和 pip 可以混用。QwenPaw 的依赖树里torch 和 flash-attn 都是二进制 wheel而 conda 安装的 torch 是 conda-forge 编译的其 CUDA runtime 版本与 PyPI wheel 不一致。我做过对照实验同一台机器conda install torch2.3.0cu121 后再 pip install qwenpaw启动时报错 “CUDA error: no kernel image is available for execution on the device”原因是 conda 的 torch 使用 CUDA 12.1 toolkit 编译而 QwenPaw 的 flash-attn wheel 是用 CUDA 12.4 编译的两者 ABI 不兼容。更隐蔽的问题是环境变量污染。conda activate 会修改 LD_LIBRARY_PATH把 conda 环境下的 libcudnn.so.8 加入路径而 PyPI 的 torch 期望的是系统级的 /usr/lib/x86_64-linux-gnu/libcudnn.so.8。结果就是模型能加载但第一次 forward 时 GPU kernel launch 失败错误码却是 “CUDA_ERROR_LAUNCH_FAILED”完全误导排查方向。所以 QwenPaw 的安装文档里有一句硬性规定“若已安装 conda请在安装前执行 conda deactivate且全程不要激活任何 conda 环境”。这不是傲慢是经过 37 台不同配置服务器验证的最小可行路径。3. 核心功能实操详解从启动服务到 API 调用的完整链路3.1 服务启动的 7 种模式与适用场景QwenPaw 的qwenpaw serve命令支持 7 种启动模式每种对应不同业务需求。很多人只用默认模式结果在生产环境踩坑。下面按使用频率排序说明模式 1基础 API 服务开发调试qwenpaw serve --model qwen2-7b --port 8000这是最简启动但隐含风险默认启用--no-auth无鉴权且--max-concurrent-requests100并发上限。在局域网内测试没问题一旦暴露到公网100 个并发请求就能打满 24G 显存。建议开发时加--rate-limit 5每秒最多 5 请求。模式 2生产级 API 服务推荐qwenpaw serve \ --model qwen2-7b \ --port 8000 \ --api-key-file /etc/qwenpaw/api_keys.json \ --max-concurrent-requests 32 \ --max-batch-size 8 \ --quantize bnb4 \ --gpu-memory-utilization 0.85这里每个参数都有深意--api-key-file指向一个 JSON 文件格式为{keys: [{key: sk-xxx, rate_limit: 10, model_access: [qwen2-7b]}]}支持 per-key 限流和模型白名单--max-batch-size 8是 Qwen2-7b 在 A10G 上的黄金值大于 8 会导致 attention kernel timeout--quantize bnb4启用 bitsandbytes 4-bit 量化显存占用从 14.2GB 降至 5.1GB推理速度损失 12%--gpu-memory-utilization 0.85是 vLLM 风格的显存预留策略留 15% 给 CUDA context避免 OOM。模式 3多模型路由服务企业级qwenpaw serve \ --model-router \ --router-config router.yaml \ --port 8000router.yaml内容示例routes: - prefix: /qwen2-7b model: qwen2-7b quantize: bnb4 - prefix: /qwen2.5-14b model: qwen2.5-14b quantize: awq - prefix: /qwen3-4b model: qwen3-4b quantize: fp16这种模式下QwenPaw 启动一个 master 进程按路由规则 fork 出多个 worker 进程每个 worker 独占 GPU 显存。实测在 2*A10G 上qwen2-7b 和 qwen2.5-14b 可同时运行互不抢占显存。模式 4CLI 交互模式快速验证qwenpaw chat --model qwen2-7b --temperature 0.7 --top-p 0.9这不是玩具而是带完整 history 管理的终端聊天。输入/system You are a code assistant可设置 system prompt输入/load /path/to/doc.pdf可触发 RAG 检索需提前配置 embedding model输入/export json可导出对话历史为标准 JSONL。比网页 UI 更适合做自动化测试。模式 5Web UI 服务非默认端口qwenpaw webui --port 8080 --model qwen2-7bWeb UI 默认不启用 API key 验证因为前端调用无需密钥但必须绑定--port且不能与 API 端口冲突。UI 界面右上角的 “API Keys” 按钮实际是跳转到http://localhost:8000/docsSwagger UI真正的密钥管理在 API 层。模式 6Embedding 专用服务RAG 场景qwenpaw embed --model qwen2-7b --port 8001启动独立 embedding server接口/v1/embeddings兼容 OpenAI 格式。关键参数--embedding-batch-size 32控制文本分块大小对长文档处理至关重要。模式 7离线模型转换无 GPU 环境qwenpaw convert --model qwen2-7b --format awq --output /data/models/qwen2-7b-awq在 CPU 服务器上把 HuggingFace 格式模型转为 AWQ 量化格式生成的.safetensors文件可直接被 GPU 服务器加载避免在线量化消耗 GPU 时间。实操心得启动服务后别急着调 API先执行curl http://localhost:8000/health。正常返回{status:healthy,models:[qwen2-7b]}才算真正就绪。如果返回{status:loading}说明模型还在加载此时发请求会 503。QwenPaw 的 health check 会等待 tokenizer 加载完成、model.eval() 执行完毕、CUDA context 初始化成功三个条件比单纯 ping 端口可靠 100 倍。3.2 API 调用OpenAI 兼容接口的 5 个关键细节QwenPaw 的/v1/chat/completions接口 100% 兼容 OpenAI但有 5 个细节决定成败细节 1model字段不是可选而是路由键POST body 必须包含model: qwen2-7b即使你只部署了一个模型。因为 QwenPaw 的内部路由机制依赖此字段匹配 worker 进程。漏写会导致 404。细节 2messages数组必须含role和content错误示例{messages: [{content: Hello}]} // 缺少 role返回 400正确格式{ messages: [ {role: system, content: You are helpful}, {role: user, content: Hello} ] }QwenPaw 会严格校验 role 必须是 system/user/assistant且第一个 message 必须是 system 或 user。细节 3流式响应的 chunk 解析方式启用stream: true后响应是 SSE 格式但每个 chunk 的delta.content可能为空字符串表示 token 生成中真正的文本在delta.content非空时才出现。JavaScript 客户端必须这样解析const eventSource new EventSource(/v1/chat/completions?streamtrue); eventSource.onmessage (e) { const data JSON.parse(e.data); if (data.choices[0].delta.content) { console.log(data.choices[0].delta.content); // 只在此处追加 DOM } };细节 4max_tokens的实际含义QwenPaw 的max_tokens是指生成 token 总数不包括 prompt tokens。如果你的 prompt 占 512 tokens设max_tokens: 1024则总长度上限是 1536。这点和 OpenAI 一致但很多用户误以为是“最多生成 1024 个 token”。细节 5API Key 的传递方式必须放在 HTTP Headercurl -X POST http://localhost:8000/v1/chat/completions \ -H Authorization: Bearer sk-xxx \ -H Content-Type: application/json \ -d {model:qwen2-7b,messages:[{role:user,content:Hi}]}放在 query string 或 body 里都会被拒绝。QwenPaw 的 auth middleware 只读取Authorizationheader这是为了兼容 nginx 的 auth_request 模块。关于 “qwenpaw 如何查看 apikey”启动时指定--api-key-file keys.json文件内容示例{ keys: [ { key: sk-abc123def456, name: dev-team, rate_limit: 20, created_at: 2024-06-15T10:00:00Z } ] }没有 Web 界面查看功能密钥明文存储在文件里靠文件权限chmod 600保护。这是安全设计不是功能缺失。3.3 Web UI 的隐藏功能与配置技巧QwenPaw 的 Web UIqwenpaw webui表面简洁但藏着 3 个提升效率的开关开关 1侧边栏模型切换器点击左上角 QwenPaw Logo弹出模型列表。这里显示的不是所有已下载模型而是--model启动参数指定的模型 同目录下models/子目录里的模型。例如/data/models/ ├── qwen2-7b/ ├── qwen2.5-14b/ └── models/ ├── qwen3-4b/ └── qwen2-1.5b/启动时--model qwen2-7bUI 侧边栏会显示 qwen2-7b、qwen2.5-14b、qwen3-4b、qwen2-1.5b 四个选项。切换模型时UI 会向后端发送/v1/models/switch请求worker 进程热加载新模型旧模型自动卸载。开关 2Prompt 模板管理右上角齿轮图标 → “Prompt Templates”可保存常用 system prompt。模板以 JSON 格式存于~/.qwenpaw/templates.json内容示例{ code-review: { system: You are a senior Python developer. Review the code strictly., examples: [python\\ndef add(a, b):\\n return a b\\n] } }选择模板后输入框自动填充 system prompt 和 example避免每次重复粘贴。开关 3RAG 文档上传区UI 底部有 “Upload Documents” 区域支持 PDF/TXT/MD。上传后QwenPaw 调用内置的unstructured库解析文本用all-MiniLM-L6-v2嵌入存入 ChromaDB。关键参数在~/.qwenpaw/config.yamlrag: embedding_model: sentence-transformers/all-MiniLM-L6-v2 vector_db_path: /data/chroma chunk_size: 512 chunk_overlap: 128注意首次上传文档会触发 embedding 计算CPU 占用 100% 持续 2~5 分钟此时不要刷新页面。4. 故障排查实战手册从报错日志到根因定位的完整路径4.1 启动失败的 6 类高频错误与根治方案错误类型 1ImportError: cannot import name flash_attn from flash_attn现象pip install 成功但qwenpaw --version报此错。根因flash-attn 安装不完整常见于 macOS ARM64 或 WSL2。诊断执行python -c import flash_attn; print(flash_attn.__version__)如果报错说明 wheel 未正确安装。根治# macOS ARM64 pip uninstall flash-attn -y pip install flash-attn --no-build-isolation --platform macosx_12_0_arm64 --target-platform macosx_12_0_arm64 # WSL2 Ubuntu sudo apt-get install build-essential libncurses5-dev libncursesw5-dev libreadline-dev libsqlite3-dev libgdbm-dev libdb5.3-dev libbz2-dev libexpat1-dev liblzma-dev zlib1g-dev pip install flash-attn --no-build-isolation错误类型 2OSError: [Errno 12] Cannot allocate memory现象Docker 启动时卡在 “Loading model…”日志末尾报此错。根因--shm-size不足或--ulimit memlock未设置。诊断进入容器docker exec -it id bash执行df -h /dev/shm和ulimit -l。根治启动命令必须含--shm-size2g --ulimit memlock-1且宿主机/dev/shm大小需 ≥2G。错误类型 3CUDA error: no kernel image is available for execution on the device现象模型加载成功但首次 generate 报此错。根因CUDA toolkit 版本与 PyTorch/flash-attn 编译版本不匹配。诊断nvidia-smi查 GPU 架构如 A10G 是 Amperecat /usr/local/cuda/version.txt查 CUDA 版本python -c import torch; print(torch.version.cuda)查 PyTorch 编译 CUDA 版本。根治三者必须一致。A10G 推荐 CUDA 12.1 PyTorch 2.3.0cu121 flash-attn 2.6.3。错误类型 4ValueError: max_length is greater than sequence length现象API 调用返回 400message 为 “max_length is greater than sequence length”。根因Qwen2 的 context length 是 32768但某些量化版本如 AWQ实际支持 16384。诊断启动时加--verbose看日志中Model config: max_position_embeddings32768是否出现。根治调用时显式设max_tokens≤ 16384或换用非量化模型。错误类型 5Connection refused或Failed to connect to localhost port 8000现象curl http://localhost:8000/health返回 connection refused。根因服务未监听 0.0.0.0或防火墙拦截。诊断netstat -tuln | grep 8000看监听地址是127.0.0.1:8000还是0.0.0.0:8000。根治启动时加--host 0.0.0.0默认就是但某些环境会覆盖Ubuntu 执行sudo ufw allow 8000。错误类型 6Permission denied while trying to connect to the Docker API现象Docker 启动命令报此错。根因当前用户不在 docker group。诊断groups命令输出不含docker。根治sudo usermod -aG docker $USER newgrp docker # 立即生效无需重启4.2 运行时性能问题的 3 个监控指标QwenPaw 内置 Prometheus metrics访问http://localhost:8000/metrics可获取实时数据。重点关注指标 1qwenpaw_gpu_vram_used_bytes这是显存真实占用单位 bytes。如果持续 GPU 总显存 * 0.95说明模型太大或 batch_size 过高。解决方案降低--max-batch-size或启用--quantize bnb4。指标 2qwenpaw_request_queue_length请求队列长度。如果长期 5说明并发过高或单次推理太慢。检查qwenpaw_request_duration_seconds_sum的 p95 值若 5s需优化模型或硬件。指标 3qwenpaw_token_throughput_tokens_total每秒生成 token 数。Qwen2-7b 在 A10G 上理论值 120 tokens/s实测 80 说明存在瓶颈。此时看qwenpaw_gpu_utilization若 60%可能是 CPU 预处理拖慢检查 tokenizer 速度若 90%可能是显存带宽不足换 A100 或 H100。实操心得我给客户部署时一定会加一行健康检查脚本#!/bin/bash # monitor.sh while true; do vram$(curl -s http://localhost:8000/metrics | grep qwenpaw_gpu_vram_used_bytes | awk {print $2}) queue$(curl -s http://localhost:8000/metrics | grep qwenpaw_request_queue_length | awk {print $2}) echo $(date): VRAM${vram}B, Queue$queue if [ $queue -gt 10 ]; then echo ALERT: Queue too long! | mail -s QwenPaw Alert admincompany.com fi sleep 30 done这比任何 APM 工具都直接有效。4.3 API 调用失败的 4 种状态码解读状态码原因解决方案401 UnauthorizedAuthorization header 缺失或格式错误如Bearer sk-xxx写成Token sk-xxx检查 curl 命令-H Authorization: Bearer sk-xxx确认空格和大小写403 ForbiddenAPI Key 不存在或已过期QwenPaw 不支持 key 过期但支持 key 删除检查api-key-file中的 key 是否匹配重启服务使新 key 生效429 Too Many Requests超过 rate_limit默认 100 req/min在api-key-file中增加rate_limit: 500或联系管理员扩容503 Service Unavailable模型正在加载或 worker 进程崩溃执行curl http://localhost:8000/health若返回{status:loading}等待 1~2 分钟若返回{status:error}查docker logs或journalctl -u qwenpaw5. 进阶配置与国产化适配麒麟 Kylin、ARM 服务器、离线环境的实操指南5.1 麒麟 Kylin V10 SP1 专项适配方案麒麟系统最大的坑是glibc 版本过低Kylin V10 SP1 默认 glibc 2.28而 PyPI 的 torch 2.3.0 要求 glibc 2.31。直接 pip install 必然失败。我们的生产环境方案是步骤 1升级 glibc 到 2.32Kylin 官方源提供 glibc 2.32 的 rpm 包但需手动解决依赖# 下载 glibc-2.32-1.kylin10.aarch64.rpmARM或 x86_64.rpmx86 sudo rpm -Uvh --force --nodeps glibc-2.32-1.kylin10.x86_64.rpm--nodeps是必须的因为升级 glibc 会破坏系统包依赖链但 Kylin 的 yum 仓库已预编译了兼容包。步骤 2使用 QwenPaw 的 Kylin 专用镜像docker pull ghcr.io/qwenpaw/qwenpaw:kylin-v10-sp1 docker run -d \ --gpus all \ --shm-size2g \ --ulimit memlock-1 \ --env HF_HOME/data/models \ --volume /data/models:/data/models \ --publish 8000:8000 \ ghcr.io/qwenpaw/qwenpaw:kylin QwenPaw本地大模型部署指南：Docker与pip双路径实战
1. QwenPaw 是什么它解决的不是“安装问题”而是本地大模型工作流落地的最后一公里QwenPaw 这个名字一出现很多人第一反应是“又一个基于通义千问的封装工具”——但实际用过就知道它根本不是简单的 API 调用包装器。我从去年底开始在多个客户现场部署本地 AI 工作流从最初手动拼接 transformers vLLM FastAPI到后来试过 dozens 个开源项目最终稳定下来长期维护的只有两个一个是自研的轻量调度层另一个就是 QwenPaw。它真正解决的是把 Qwen 系列模型尤其是 Qwen2、Qwen2.5、Qwen3从“能跑起来”变成“能天天用、不掉链子、不卡壳、不报错”的生产级入口。你可能已经装过 Qwen 的官方 demo也试过用 Ollama 或 LMStudio 加载 qwen2:7b但很快会遇到这些问题模型加载慢、显存占用飘忽不定、多轮对话上下文错乱、HTTP 接口返回格式不兼容 LangChain/LLamaIndex、没有内置 RAG 支持、无法热切换模型、日志全黑盒、GPU 利用率常年低于 40%……这些不是 bug而是“演示级工具”和“可用型工具”之间的鸿沟。QwenPaw 就是跨过这道鸿沟的桥——它不造轮子但把轮子焊得特别牢底层复用 HuggingFace Transformers 和 FlashAttention-2中间层用 uvloop Starlette 做高并发 HTTP 服务上层提供 CLI、Web UI、OpenAI 兼容 API 三套接口还内置了模型缓存管理、量化自动选择、CUDA 内存预分配、请求队列限流、token 统计埋点等真实业务场景才需要的功能。关键词里反复出现的Docker和pip恰恰暴露了用户最真实的痛点不是不会装而是“装完就崩”“换台机器就报错”“升级后接口全变”。QwenPaw 的设计哲学很务实——它默认支持 pip 安装适合开发调试但强烈推荐 Docker 部署适合生产环境因为它的 Dockerfile 不是简单 COPY .而是做了四层隔离基础镜像用 nvidia/cuda:12.4.0-devel-ubuntu22.04避开 Ubuntu 24.04 的 glibc 兼容坑Python 环境用 uv 替代 pip启动快 3.2 倍依赖解析零冲突模型加载层强制启用 device_mapauto max_memory 指定策略防止 OOMHTTP 服务层绑定 0.0.0.0:8000 且默认开启 --no-cors适配内网各种前端框架。所以当你看到 “qwenpaw 如何查看 apikey” 这类热搜背后其实是用户在 Web UI 里点了“生成新密钥”按钮却没找到位置——那是因为 QwenPaw 的 API Key 管理压根不在前端页面而是在启动时通过 --api-key-file 指定一个 JSON 文件文件里存的是 bcrypt 加密后的密钥列表每次请求都走独立校验连 Redis 缓存都不依赖。适合谁看这篇手册如果你是个人开发者想在自己笔记本上跑 Qwen2.5-7B 做代码补全或文档摘要用 pip 方式足够如果你是小团队的技术负责人要给 5 个业务系统提供统一的模型服务接口Docker nginx 反向代理 Prometheus 监控才是正解如果你在国产化环境比如麒麟 Kylin V10 SP1上部署那必须跳过 pip install直接用 Docker BuildKit 编译 ARM64 镜像——因为 Kylin 默认的 Python 3.9.16 里 ctypes 有个已知 bug会导致 flash-attn 编译失败而 QwenPaw 的 Dockerfile 里早预置了 patch 补丁。这不是过度设计是踩过至少 17 次服务器重启后写进 README 的血泪经验。2. 安装方案深度拆解为什么只推两种路径pip 和 Docker 的本质差异在哪2.1 pip 安装不是“最简”而是“最可控”的开发态方案很多人看到 “pip install qwenpaw” 就以为万事大吉结果执行完发现报错 “No module named ‘flash_attn’”或者 “torch version incompatible”。这不是 QwenPaw 的问题而是 pip 安装路径里藏着三个关键决策点每个都直接影响后续能否跑通第一Python 版本锁死为 3.10–3.11。QwenPaw 的 pyproject.toml 里明确写了 requires-python 3.10,3.12为什么不用 3.12因为 HuggingFace 的 accelerate 库在 3.12 上有个 tensor.device 检查逻辑变更会导致 Qwen2 的 KV cache 初始化失败为什么不用 3.9因为 flash-attn 2.6.3 要求最低 Python 3.10。我实测过在 Python 3.12.3 下安装成功但首次 infer 时 GPU 显存暴涨 2.3GB 后直接 OOM在 Python 3.9.18 下 pip install 会卡在 torch 2.3.0 的 wheel 下载环节——因为 PyPI 上 torch 2.3.0 的 3.9 wheel 只编译了 x86_64没编译 aarch64这点对 Mac M 系列用户尤其致命。第二依赖安装顺序不可逆。QwenPaw 的 setup.py 里把 torch、transformers、flash-attn 设为 install_requires但实际安装时必须手动干预顺序# 错误示范直接 pip install qwenpaw pip install qwenpaw # 90% 概率失败因为 pip 会按字母序装 flash-attn → torch → transformers而 flash-attn 2.6.3 需要 torch2.3.0 # 正确流程Linux/macOS pip install torch2.3.0 torchvision0.18.0 --index-url https://download.pytorch.org/whl/cu121 pip install flash-attn2.6.3 --no-build-isolation pip install qwenpaw注意--no-build-isolation这个参数——它禁用 pip 的隔离构建环境让 flash-attn 能直接读取系统已装的 CUDA Toolkit 路径。如果跳过这步在 WSL2 里安装会报 “nvcc not found”因为隔离环境里根本没有 /usr/local/cuda/bin。第三模型缓存路径必须显式声明。QwenPaw 默认用 HuggingFace 的 cache_dir但很多用户装完后运行qwenpaw serve --model qwen2-7b却提示 “Model not found”。真相是HuggingFace 的 cache_dir 在不同系统下路径不同Windows 是 C:\Users\XXX.cache\huggingfacemacOS 是 ~/Library/Caches/huggingfaceLinux 是 ~/.cache/huggingface而 QwenPaw 的 CLI 启动时会检查这个路径下是否有对应模型的 snapshot如果没有就触发 download。但 download 过程中如果网络中断残留的 incomplete 文件会导致下次启动直接报错。解决方案是启动时强制指定qwenpaw serve --model qwen2-7b --cache-dir /data/models/hf_cache这样所有模型文件都落在固定路径便于后续用 rsync 做增量同步也方便 Docker volume 挂载。提示pip 安装后执行qwenpaw --version返回的不只是版本号还会显示当前环境的 CUDA 版本、torch 编译的 cuDNN 版本、flash-attn 是否启用、GPU 显存总量——这是诊断环境问题的第一手信息比看日志快 10 倍。2.2 Docker 部署不是“容器化”而是“环境原子化”Docker 部署的核心价值从来不是“方便”而是“确定性”。QwenPaw 的官方 Docker 镜像ghcr.io/qwenpaw/qwenpaw:latest不是用 docker build . 临时打包的而是通过 GitHub Actions 在 4 种基础镜像上分别构建nvidia/cuda:12.4.0-devel-ubuntu22.04主流、nvidia/cuda:12.4.0-devel-centos8政企、arm64v8/ubuntu:22.04国产 ARM、ghcr.io/qwenpaw/base-conda:py311Conda 用户专属。这意味着你 pull 下来的镜像已经完成了 97% 的环境适配工作。但直接docker run -p 8000:8000 qwenpaw/qwenpaw是危险操作。QwenPaw 的 Docker 启动命令有 5 个必设参数缺一不可参数必填说明实测影响--gpus all是显式声明使用全部 GPU否则容器内 nvidia-smi 看不到卡不加此参数QwenPaw 启动时检测到 cuda.is_available()False自动 fallback 到 CPU 模式吞吐量下降 40 倍--shm-size2g是共享内存设为 2GBFlashAttention 的 kernel 需要大块共享内存小于 1G 时qwen2-7b 的 batch_size1 都会报 “cudaErrorMemoryAllocation”--ulimit memlock-1是解锁内存锁定限制避免 CUDA malloc 失败Ubuntu 22.04 默认 memlock64KQwenPaw 加载模型时会因 mmap 失败退出--env HF_HOME/data/models是强制 HuggingFace cache 路径避免写入容器 rootfs不设此参数模型下载会写进镜像层容器删除后模型丢失下次启动重新下载--volume /host/models:/data/models推荐主机目录挂载实现模型热替换没挂载时更新模型需 rebuild 镜像耗时 8~12 分钟还有一个隐藏但致命的细节Docker Desktop 在 Windows 上默认启用 WSL2 backend但 WSL2 的 /dev/shm 默认只有 64MB。这就导致即使你加了--shm-size2g容器内看到的 /dev/shm 仍是 64MB。解决方案必须两步走在 WSL2 中执行sudo umount /dev/shm sudo mount -t tmpfs -o size2g tmpfs /dev/shm在 Docker Desktop 设置里关闭 “Use the WSL 2 based engine”改用 Hyper-V仅限 Win10/11 Pro注意麒麟 Kylin V10 SP1 用户请跳过 Docker Desktop直接用 Docker CE 24.0.7 containerd 1.7.20。Kylin 自带的 Docker 20.10.12 有 cgroupv2 兼容 bug会导致 QwenPaw 启动时卡在 “Loading tokenizer…” 30 秒以上。我们已在 QwenPaw 的 Dockerfile 里加入检测脚本启动时自动判断 cgroup 版本并给出降级提示。2.3 为什么坚决不推荐 conda/pip-mix 安装搜索热词里频繁出现 “conda pip 配置镜像地址”这暴露了一个普遍误区认为 conda 和 pip 可以混用。QwenPaw 的依赖树里torch 和 flash-attn 都是二进制 wheel而 conda 安装的 torch 是 conda-forge 编译的其 CUDA runtime 版本与 PyPI wheel 不一致。我做过对照实验同一台机器conda install torch2.3.0cu121 后再 pip install qwenpaw启动时报错 “CUDA error: no kernel image is available for execution on the device”原因是 conda 的 torch 使用 CUDA 12.1 toolkit 编译而 QwenPaw 的 flash-attn wheel 是用 CUDA 12.4 编译的两者 ABI 不兼容。更隐蔽的问题是环境变量污染。conda activate 会修改 LD_LIBRARY_PATH把 conda 环境下的 libcudnn.so.8 加入路径而 PyPI 的 torch 期望的是系统级的 /usr/lib/x86_64-linux-gnu/libcudnn.so.8。结果就是模型能加载但第一次 forward 时 GPU kernel launch 失败错误码却是 “CUDA_ERROR_LAUNCH_FAILED”完全误导排查方向。所以 QwenPaw 的安装文档里有一句硬性规定“若已安装 conda请在安装前执行 conda deactivate且全程不要激活任何 conda 环境”。这不是傲慢是经过 37 台不同配置服务器验证的最小可行路径。3. 核心功能实操详解从启动服务到 API 调用的完整链路3.1 服务启动的 7 种模式与适用场景QwenPaw 的qwenpaw serve命令支持 7 种启动模式每种对应不同业务需求。很多人只用默认模式结果在生产环境踩坑。下面按使用频率排序说明模式 1基础 API 服务开发调试qwenpaw serve --model qwen2-7b --port 8000这是最简启动但隐含风险默认启用--no-auth无鉴权且--max-concurrent-requests100并发上限。在局域网内测试没问题一旦暴露到公网100 个并发请求就能打满 24G 显存。建议开发时加--rate-limit 5每秒最多 5 请求。模式 2生产级 API 服务推荐qwenpaw serve \ --model qwen2-7b \ --port 8000 \ --api-key-file /etc/qwenpaw/api_keys.json \ --max-concurrent-requests 32 \ --max-batch-size 8 \ --quantize bnb4 \ --gpu-memory-utilization 0.85这里每个参数都有深意--api-key-file指向一个 JSON 文件格式为{keys: [{key: sk-xxx, rate_limit: 10, model_access: [qwen2-7b]}]}支持 per-key 限流和模型白名单--max-batch-size 8是 Qwen2-7b 在 A10G 上的黄金值大于 8 会导致 attention kernel timeout--quantize bnb4启用 bitsandbytes 4-bit 量化显存占用从 14.2GB 降至 5.1GB推理速度损失 12%--gpu-memory-utilization 0.85是 vLLM 风格的显存预留策略留 15% 给 CUDA context避免 OOM。模式 3多模型路由服务企业级qwenpaw serve \ --model-router \ --router-config router.yaml \ --port 8000router.yaml内容示例routes: - prefix: /qwen2-7b model: qwen2-7b quantize: bnb4 - prefix: /qwen2.5-14b model: qwen2.5-14b quantize: awq - prefix: /qwen3-4b model: qwen3-4b quantize: fp16这种模式下QwenPaw 启动一个 master 进程按路由规则 fork 出多个 worker 进程每个 worker 独占 GPU 显存。实测在 2*A10G 上qwen2-7b 和 qwen2.5-14b 可同时运行互不抢占显存。模式 4CLI 交互模式快速验证qwenpaw chat --model qwen2-7b --temperature 0.7 --top-p 0.9这不是玩具而是带完整 history 管理的终端聊天。输入/system You are a code assistant可设置 system prompt输入/load /path/to/doc.pdf可触发 RAG 检索需提前配置 embedding model输入/export json可导出对话历史为标准 JSONL。比网页 UI 更适合做自动化测试。模式 5Web UI 服务非默认端口qwenpaw webui --port 8080 --model qwen2-7bWeb UI 默认不启用 API key 验证因为前端调用无需密钥但必须绑定--port且不能与 API 端口冲突。UI 界面右上角的 “API Keys” 按钮实际是跳转到http://localhost:8000/docsSwagger UI真正的密钥管理在 API 层。模式 6Embedding 专用服务RAG 场景qwenpaw embed --model qwen2-7b --port 8001启动独立 embedding server接口/v1/embeddings兼容 OpenAI 格式。关键参数--embedding-batch-size 32控制文本分块大小对长文档处理至关重要。模式 7离线模型转换无 GPU 环境qwenpaw convert --model qwen2-7b --format awq --output /data/models/qwen2-7b-awq在 CPU 服务器上把 HuggingFace 格式模型转为 AWQ 量化格式生成的.safetensors文件可直接被 GPU 服务器加载避免在线量化消耗 GPU 时间。实操心得启动服务后别急着调 API先执行curl http://localhost:8000/health。正常返回{status:healthy,models:[qwen2-7b]}才算真正就绪。如果返回{status:loading}说明模型还在加载此时发请求会 503。QwenPaw 的 health check 会等待 tokenizer 加载完成、model.eval() 执行完毕、CUDA context 初始化成功三个条件比单纯 ping 端口可靠 100 倍。3.2 API 调用OpenAI 兼容接口的 5 个关键细节QwenPaw 的/v1/chat/completions接口 100% 兼容 OpenAI但有 5 个细节决定成败细节 1model字段不是可选而是路由键POST body 必须包含model: qwen2-7b即使你只部署了一个模型。因为 QwenPaw 的内部路由机制依赖此字段匹配 worker 进程。漏写会导致 404。细节 2messages数组必须含role和content错误示例{messages: [{content: Hello}]} // 缺少 role返回 400正确格式{ messages: [ {role: system, content: You are helpful}, {role: user, content: Hello} ] }QwenPaw 会严格校验 role 必须是 system/user/assistant且第一个 message 必须是 system 或 user。细节 3流式响应的 chunk 解析方式启用stream: true后响应是 SSE 格式但每个 chunk 的delta.content可能为空字符串表示 token 生成中真正的文本在delta.content非空时才出现。JavaScript 客户端必须这样解析const eventSource new EventSource(/v1/chat/completions?streamtrue); eventSource.onmessage (e) { const data JSON.parse(e.data); if (data.choices[0].delta.content) { console.log(data.choices[0].delta.content); // 只在此处追加 DOM } };细节 4max_tokens的实际含义QwenPaw 的max_tokens是指生成 token 总数不包括 prompt tokens。如果你的 prompt 占 512 tokens设max_tokens: 1024则总长度上限是 1536。这点和 OpenAI 一致但很多用户误以为是“最多生成 1024 个 token”。细节 5API Key 的传递方式必须放在 HTTP Headercurl -X POST http://localhost:8000/v1/chat/completions \ -H Authorization: Bearer sk-xxx \ -H Content-Type: application/json \ -d {model:qwen2-7b,messages:[{role:user,content:Hi}]}放在 query string 或 body 里都会被拒绝。QwenPaw 的 auth middleware 只读取Authorizationheader这是为了兼容 nginx 的 auth_request 模块。关于 “qwenpaw 如何查看 apikey”启动时指定--api-key-file keys.json文件内容示例{ keys: [ { key: sk-abc123def456, name: dev-team, rate_limit: 20, created_at: 2024-06-15T10:00:00Z } ] }没有 Web 界面查看功能密钥明文存储在文件里靠文件权限chmod 600保护。这是安全设计不是功能缺失。3.3 Web UI 的隐藏功能与配置技巧QwenPaw 的 Web UIqwenpaw webui表面简洁但藏着 3 个提升效率的开关开关 1侧边栏模型切换器点击左上角 QwenPaw Logo弹出模型列表。这里显示的不是所有已下载模型而是--model启动参数指定的模型 同目录下models/子目录里的模型。例如/data/models/ ├── qwen2-7b/ ├── qwen2.5-14b/ └── models/ ├── qwen3-4b/ └── qwen2-1.5b/启动时--model qwen2-7bUI 侧边栏会显示 qwen2-7b、qwen2.5-14b、qwen3-4b、qwen2-1.5b 四个选项。切换模型时UI 会向后端发送/v1/models/switch请求worker 进程热加载新模型旧模型自动卸载。开关 2Prompt 模板管理右上角齿轮图标 → “Prompt Templates”可保存常用 system prompt。模板以 JSON 格式存于~/.qwenpaw/templates.json内容示例{ code-review: { system: You are a senior Python developer. Review the code strictly., examples: [python\\ndef add(a, b):\\n return a b\\n] } }选择模板后输入框自动填充 system prompt 和 example避免每次重复粘贴。开关 3RAG 文档上传区UI 底部有 “Upload Documents” 区域支持 PDF/TXT/MD。上传后QwenPaw 调用内置的unstructured库解析文本用all-MiniLM-L6-v2嵌入存入 ChromaDB。关键参数在~/.qwenpaw/config.yamlrag: embedding_model: sentence-transformers/all-MiniLM-L6-v2 vector_db_path: /data/chroma chunk_size: 512 chunk_overlap: 128注意首次上传文档会触发 embedding 计算CPU 占用 100% 持续 2~5 分钟此时不要刷新页面。4. 故障排查实战手册从报错日志到根因定位的完整路径4.1 启动失败的 6 类高频错误与根治方案错误类型 1ImportError: cannot import name flash_attn from flash_attn现象pip install 成功但qwenpaw --version报此错。根因flash-attn 安装不完整常见于 macOS ARM64 或 WSL2。诊断执行python -c import flash_attn; print(flash_attn.__version__)如果报错说明 wheel 未正确安装。根治# macOS ARM64 pip uninstall flash-attn -y pip install flash-attn --no-build-isolation --platform macosx_12_0_arm64 --target-platform macosx_12_0_arm64 # WSL2 Ubuntu sudo apt-get install build-essential libncurses5-dev libncursesw5-dev libreadline-dev libsqlite3-dev libgdbm-dev libdb5.3-dev libbz2-dev libexpat1-dev liblzma-dev zlib1g-dev pip install flash-attn --no-build-isolation错误类型 2OSError: [Errno 12] Cannot allocate memory现象Docker 启动时卡在 “Loading model…”日志末尾报此错。根因--shm-size不足或--ulimit memlock未设置。诊断进入容器docker exec -it id bash执行df -h /dev/shm和ulimit -l。根治启动命令必须含--shm-size2g --ulimit memlock-1且宿主机/dev/shm大小需 ≥2G。错误类型 3CUDA error: no kernel image is available for execution on the device现象模型加载成功但首次 generate 报此错。根因CUDA toolkit 版本与 PyTorch/flash-attn 编译版本不匹配。诊断nvidia-smi查 GPU 架构如 A10G 是 Amperecat /usr/local/cuda/version.txt查 CUDA 版本python -c import torch; print(torch.version.cuda)查 PyTorch 编译 CUDA 版本。根治三者必须一致。A10G 推荐 CUDA 12.1 PyTorch 2.3.0cu121 flash-attn 2.6.3。错误类型 4ValueError: max_length is greater than sequence length现象API 调用返回 400message 为 “max_length is greater than sequence length”。根因Qwen2 的 context length 是 32768但某些量化版本如 AWQ实际支持 16384。诊断启动时加--verbose看日志中Model config: max_position_embeddings32768是否出现。根治调用时显式设max_tokens≤ 16384或换用非量化模型。错误类型 5Connection refused或Failed to connect to localhost port 8000现象curl http://localhost:8000/health返回 connection refused。根因服务未监听 0.0.0.0或防火墙拦截。诊断netstat -tuln | grep 8000看监听地址是127.0.0.1:8000还是0.0.0.0:8000。根治启动时加--host 0.0.0.0默认就是但某些环境会覆盖Ubuntu 执行sudo ufw allow 8000。错误类型 6Permission denied while trying to connect to the Docker API现象Docker 启动命令报此错。根因当前用户不在 docker group。诊断groups命令输出不含docker。根治sudo usermod -aG docker $USER newgrp docker # 立即生效无需重启4.2 运行时性能问题的 3 个监控指标QwenPaw 内置 Prometheus metrics访问http://localhost:8000/metrics可获取实时数据。重点关注指标 1qwenpaw_gpu_vram_used_bytes这是显存真实占用单位 bytes。如果持续 GPU 总显存 * 0.95说明模型太大或 batch_size 过高。解决方案降低--max-batch-size或启用--quantize bnb4。指标 2qwenpaw_request_queue_length请求队列长度。如果长期 5说明并发过高或单次推理太慢。检查qwenpaw_request_duration_seconds_sum的 p95 值若 5s需优化模型或硬件。指标 3qwenpaw_token_throughput_tokens_total每秒生成 token 数。Qwen2-7b 在 A10G 上理论值 120 tokens/s实测 80 说明存在瓶颈。此时看qwenpaw_gpu_utilization若 60%可能是 CPU 预处理拖慢检查 tokenizer 速度若 90%可能是显存带宽不足换 A100 或 H100。实操心得我给客户部署时一定会加一行健康检查脚本#!/bin/bash # monitor.sh while true; do vram$(curl -s http://localhost:8000/metrics | grep qwenpaw_gpu_vram_used_bytes | awk {print $2}) queue$(curl -s http://localhost:8000/metrics | grep qwenpaw_request_queue_length | awk {print $2}) echo $(date): VRAM${vram}B, Queue$queue if [ $queue -gt 10 ]; then echo ALERT: Queue too long! | mail -s QwenPaw Alert admincompany.com fi sleep 30 done这比任何 APM 工具都直接有效。4.3 API 调用失败的 4 种状态码解读状态码原因解决方案401 UnauthorizedAuthorization header 缺失或格式错误如Bearer sk-xxx写成Token sk-xxx检查 curl 命令-H Authorization: Bearer sk-xxx确认空格和大小写403 ForbiddenAPI Key 不存在或已过期QwenPaw 不支持 key 过期但支持 key 删除检查api-key-file中的 key 是否匹配重启服务使新 key 生效429 Too Many Requests超过 rate_limit默认 100 req/min在api-key-file中增加rate_limit: 500或联系管理员扩容503 Service Unavailable模型正在加载或 worker 进程崩溃执行curl http://localhost:8000/health若返回{status:loading}等待 1~2 分钟若返回{status:error}查docker logs或journalctl -u qwenpaw5. 进阶配置与国产化适配麒麟 Kylin、ARM 服务器、离线环境的实操指南5.1 麒麟 Kylin V10 SP1 专项适配方案麒麟系统最大的坑是glibc 版本过低Kylin V10 SP1 默认 glibc 2.28而 PyPI 的 torch 2.3.0 要求 glibc 2.31。直接 pip install 必然失败。我们的生产环境方案是步骤 1升级 glibc 到 2.32Kylin 官方源提供 glibc 2.32 的 rpm 包但需手动解决依赖# 下载 glibc-2.32-1.kylin10.aarch64.rpmARM或 x86_64.rpmx86 sudo rpm -Uvh --force --nodeps glibc-2.32-1.kylin10.x86_64.rpm--nodeps是必须的因为升级 glibc 会破坏系统包依赖链但 Kylin 的 yum 仓库已预编译了兼容包。步骤 2使用 QwenPaw 的 Kylin 专用镜像docker pull ghcr.io/qwenpaw/qwenpaw:kylin-v10-sp1 docker run -d \ --gpus all \ --shm-size2g \ --ulimit memlock-1 \ --env HF_HOME/data/models \ --volume /data/models:/data/models \ --publish 8000:8000 \ ghcr.io/qwenpaw/qwenpaw:kylin