当前位置: 首页 > article >正文

Docke启动Ktransformers部署Qwen3MOE模型实战与性能测试

docker运行Ktransformers部署Qwen3MOE模型实战及 性能测试

最开始拉取ktransformers:v0.3.1-AVX512版本,发现无论如何都启动不了大模型,后来发现是cpu不支持avx512指令集。

由于本地cpu不支持amx指令集,因此下载avx2版本镜像:

1.下载docker镜像并运行


docker pull approachingai/ktransformers:v0.3.1-AVX2
docker run -it --gpus all --privileged --shm-size 64g --name ktrans --network=host -v /home/xugq/models/:/models approachingai/ktransformers:v0.3.1-AVX512 /bin/bash

2.确定挂载卷并进入容器

通过该命令查看挂载卷:

docker inspect ktrans | grep -A 10 "Mounts"

执行结果:

 "Mounts": [{"Type": "bind","Source": "/home/xugq/models/Qwen3-30B-A3B-GGUF","Destination": "/Qwen3-30B-A3B-GGUF","Mode": "","RW": true,"Propagation": "rprivate"}],"Config": {

执行以下命令进入容器内部:

docker exec -it ktrans bash

3.启动qwen3-moe模型

执行以下代码启动Qwen 3 MoE :(注意model_path文件路径是容器内部的挂载路径,因为是在容器内部启动命令)

#普通指令集
python ktransformers/server/main.py --architectures Qwen3MoeForCausalLM --model_path /Qwen3-30B-A3B-GGUF --gguf_path /Qwen3-30B-A3B-GGUF/Qwen3-30B-A3B-Q4_K_M.gguf --optimize_config_path ktransformers/optimize/optimize_rules/Qwen3Moe-serve.yaml --backend_type balance_serve --port 8999
#支持amx指令集
python ktransformers/server/main.py --architectures Qwen3MoeForCausalLM --model_path <model_dir> --gguf_path <gguf_dir> --optimize_config_path ktransformers/optimize/optimize_rules/Qwen3Moe-serve-amx.yaml --backend_type balance_serve

一些可添加的额外参数参数:

  • --chunk_size: Maximum number of tokens processed in a single run by the engine.
    --chunk_size:引擎在一次运行中处理的最大令牌数。
  • --cache_lens: Total length of kvcache allocated by the scheduler. All requests share a kvcache space corresponding to 32768 tokens, and the space occupied will be released after the requests are completed.
    --cache_透镜 :调度程序分配的 kvcache 的总长度。所有请求共享一个 kvcache 空间,对应 32768 个 token,请求完成后释放所占用的空间。
  • --backend_type: balance_serve is a multi-concurrency backend engine introduced in version v0.2.4. The original single-concurrency engine is ktransformers.
    --backend_typebalance_serve 是 v0.2.4 中引入的多并发后端引擎。最初的单并发引擎是 ktransformers
  • --max_batch_size: Maximum number of requests (prefill + decode) processed in a single run by the engine. (Supported only by balance_serve)
    --max_batch_size:引擎在一次运行中处理的最大请求数(预填充+解码)。(仅支持 balance_serve

4.调用模型测试性能

访问服务器测试响应速度:

curl -X POST http://localhost:8999/v1/chat/completions \-H "accept: application/json" \-H "Content-Type: application/json" \-d '{"messages": [{"role": "user", "content": " <no_think>贵阳市有什么美丽的景点可以去旅游?"}],"model": "Qwen3-30B-A3B","temperature": 0.3,"top_p": 1.0,"stream": false
}'

收到回复:
请添加图片描述

查看服务器后台日志:
请添加图片描述

分析关键性能指标:

Performance(T/s): prefill 58.34309968405152, decode 19.089551765073455. Time(s): tokenize 0.023163557052612305, prefill 0.37707972526550293, decode 26.035184383392334

  1. Prefill(预填充)阶段
    • 速度:58.34 tokens/s
    • 耗时:0.38 秒
    • 说明:处理用户输入提示词(prompt)的速度,该阶段并行计算能力强,吞吐量高。
  2. Decode(解码)阶段
    • 速度:19.09 tokens/s
    • 耗时:26.04 秒
    • 说明:逐token生成回复内容的速度,受自回归生成特性限制,吞吐量较低。
  3. Tokenizer(分词)阶段
    • 耗时:0.023 秒
    • 耗时:26.04 秒
    • 说明:逐token生成回复内容的速度,受自回归生成特性限制,吞吐量较低。
  4. Tokenizer(分词)阶段
    • 耗时:0.023 秒
    • 说明:将文本转换为模型输入token的时间,通常不是瓶颈。
http://www.lryc.cn/news/2404794.html

相关文章:

  • 应用分享 | 精准生成和时序控制!AWG在确定性三量子比特纠缠光子源中的应用
  • 相机--相机标定实操
  • 深入理解汇编语言中的顺序与分支结构
  • DAY43 复习日
  • 【仿生机器人】仿生机器人智能架构:从感知到个性的完整设计
  • 【业务框架】3C-相机-Cinemachine
  • 【Auto.js例程】华为备忘录导出到其他手机
  • 单片机的低功耗模式
  • 架构师级考验!飞算 JavaAI 炫技赛:AI 辅助编程解决老项目难题
  • 手机端抓包大麦网抢票协议:实现自动抢票与支付
  • 使用阿里云百炼embeddings+langchain+Milvus实现简单RAG
  • C#合并CAN ASC文件:实现与优化
  • [TIP] Ubuntu 22.04 配置多个版本的 GCC 环境
  • 如何思考?分析篇
  • Redis:Hash数据类型
  • 抗辐照MCU在卫星载荷电机控制器中的实践探索
  • 快捷键的记录
  • Python读取阿里法拍网的html+解决登录cookie
  • electron-vite串口通信
  • 中山大学美团港科大提出首个音频驱动多人对话视频生成MultiTalk,输入一个音频和提示,即可生成对应唇部、音频交互视频。
  • Maven的配置与运行
  • MySQL 迁移至 Docker ,删除本地 mysql
  • redis分片集群架构
  • 关于物联网的基础知识(一)
  • 浏览器后台服务 vs 在线教育:QPS、并发模型与架构剖析
  • 电脑商城--用户注册登录
  • Riverpod与GetX的优缺点对比
  • Three.js怎么工作的?
  • LangChain面试内容整理-知识点1:LangChain架构与核心理念
  • 双面沉金线路板制作流程解析:高可靠性PCB的核心工艺