首页
/ MNN项目中Qwen-1.8B-Chat模型导出与Android部署问题解析

MNN项目中Qwen-1.8B-Chat模型导出与Android部署问题解析

2025-05-22 21:39:31作者:昌雅子Ethen

问题背景

在使用MNN框架部署Qwen-1.8B-Chat模型到Android平台时,开发者遇到了模型导出和运行的问题。具体表现为:导出的模型在Android应用中无法正常输出结果,甚至出现崩溃情况。

模型导出过程分析

初始导出尝试

开发者最初尝试使用分段导出方式,命令如下:

python llm_export.py \
        --path ../../modes/Qwen-1_8B-Chat \
        --type Qwen-1_8B-Chat \
        --export_split \
        --export_token \
        --export_mnn \
        --mnn_path ./qwen18b-chat-mnn \
        --onnx_path ./qwen18b-chat-onnx \
        --embed_bin \
        --embed_bf16

这种导出方式生成了多个block文件,但在Android应用中运行时没有任何输出。

问题诊断

  1. 配置文件缺失:分段模型需要额外的配置文件config.json,其中需要包含以下关键参数:

    {
        "is_single": false,
        "backend_type": "cpu",
        "thread_num": 4,
        "precision": "low",
        "memory": "low"
    }
    
  2. 资源文件不完整:MNN目录下缺少embeddings_bf16.bintokenizer.txt文件,需要从ONNX目录手动拷贝。

解决方案探索

非分段导出方式

仓库协作者建议使用非分段导出方式,命令调整为:

python llm_export.py \
        --path ../../modes/Qwen-1_8B-Chat \
        --type Qwen-1_8B-Chat \
        --export \
        --export_token \
        --export_mnn \
        --mnn_path ./qwen18b-chat-mnn \
        --onnx_path ./qwen18b-chat-onnx \
        --embed_bin \
        --embed_bf16 \
        --export_embed

关键变化:

  • 移除--export_split参数
  • 增加--export_embed参数确保嵌入文件生成

文件差异分析

使用不同仓库的导出工具会产生不同大小的权重文件:

  • llm-export仓库:llm.mnn.weight大小为768MB
  • MNN仓库:llm.mnn.weight大小为765MB

这种差异可能源于不同仓库的导出实现细节,建议优先使用MNN主仓库的导出工具。

Android部署问题

崩溃分析

部署到Android后出现SIGSEGV错误,可能原因包括:

  1. 模型文件不完整或损坏
  2. 内存不足
  3. 模型权重文件版本不匹配

解决建议

  1. 统一导出工具:使用MNN主仓库的导出工具
  2. 完整文件检查:确保包含以下文件:
    • llm.mnn
    • llm.mnn.weight
    • embeddings_bf16.bin
    • tokenizer.txt
  3. 内存管理:检查Android应用内存分配,大模型需要足够内存
  4. 日志分析:增加详细日志定位崩溃点

最佳实践总结

  1. 对于Qwen-1.8B-Chat模型,推荐使用非分段导出方式
  2. 导出命令应包含--export_embed参数
  3. 优先使用MNN主仓库的导出工具
  4. Android部署前验证模型文件的完整性和一致性
  5. 注意移动端设备的资源限制,适当调整线程数和内存参数

通过以上方法,开发者可以更稳定地将Qwen-1.8B-Chat模型部署到Android平台,并避免常见的导出和运行问题。

登录后查看全文
热门项目推荐
相关项目推荐

项目优选

收起
kernelkernel
deepin linux kernel
C
22
6
docsdocs
OpenHarmony documentation | OpenHarmony开发者文档
Dockerfile
164
2.05 K
nop-entropynop-entropy
Nop Platform 2.0是基于可逆计算理论实现的采用面向语言编程范式的新一代低代码开发平台,包含基于全新原理从零开始研发的GraphQL引擎、ORM引擎、工作流引擎、报表引擎、规则引擎、批处理引引擎等完整设计。nop-entropy是它的后端部分,采用java语言实现,可选择集成Spring框架或者Quarkus框架。中小企业可以免费商用
Java
8
0
leetcodeleetcode
🔥LeetCode solutions in any programming language | 多种编程语言实现 LeetCode、《剑指 Offer(第 2 版)》、《程序员面试金典(第 6 版)》题解
Java
60
16
RuoYi-Vue3RuoYi-Vue3
🎉 (RuoYi)官方仓库 基于SpringBoot,Spring Security,JWT,Vue3 & Vite、Element Plus 的前后端分离权限管理系统
Vue
952
560
apintoapinto
基于golang开发的网关。具有各种插件,可以自行扩展,即插即用。此外,它可以快速帮助企业管理API服务,提高API服务的稳定性和安全性。
Go
22
0
openHiTLSopenHiTLS
旨在打造算法先进、性能卓越、高效敏捷、安全可靠的密码套件,通过轻量级、可剪裁的软件技术架构满足各行业不同场景的多样化要求,让密码技术应用更简单,同时探索后量子等先进算法创新实践,构建密码前沿技术底座!
C
1.01 K
396
HarmonyOS-ExamplesHarmonyOS-Examples
本仓将收集和展示仓颉鸿蒙应用示例代码,欢迎大家投稿,在仓颉鸿蒙社区展现你的妙趣设计!
Cangjie
407
387
ohos_react_nativeohos_react_native
React Native鸿蒙化仓库
C++
199
279
giteagitea
喝着茶写代码!最易用的自托管一站式代码托管平台,包含Git托管,代码审查,团队协作,软件包和CI/CD。
Go
17
0