当前位置：首页 > news >正文

移动端本地AI助手开发实战：从LLM集成到性能优化

news 2026/5/2 22:41:08

1. 项目概述：当AI助手“住进”你的手机

最近在GitHub上看到一个挺有意思的项目，叫“maid”。光看名字，你可能会联想到“女仆”或者“助手”，没错，它的定位就是一个运行在你个人设备上的AI助手。但和那些需要联网、把数据传到云端处理的AI不同，maid的核心思路是“本地化”和“移动优先”。简单说，它试图把大语言模型（LLM）的能力，塞进你的手机或者电脑里，让你在完全离线、保护隐私的前提下，也能拥有一个能对话、能处理文档、能执行简单任务的智能伙伴。

这个想法其实戳中了很多人的痛点。一方面，我们对AI助手的需求是真实存在的，比如快速总结一篇长文章、翻译一段外文、或者根据几个关键词生成一段文案。另一方面，我们又对隐私和数据安全有着天然的担忧，谁也不想自己的聊天记录、工作文档被上传到某个未知的服务器。maid项目正是瞄准了这个缝隙市场：它不追求媲美GPT-4的顶级智商，而是追求在有限资源（比如手机算力）下的可用性、响应速度和绝对的数据私密性。

我自己折腾过不少本地部署的AI项目，从早期的聊天机器人到现在的各种LLM应用。maid给我的第一印象是，它非常“务实”。它没有一上来就堆砌最前沿的模型，而是围绕“如何在移动设备或普通电脑上流畅运行”这个核心问题来设计整个架构。这意味着它在模型选择、推理优化、交互设计上，都做出了一系列有针对性的取舍。对于开发者、隐私敏感用户，或者单纯想学习移动端AI应用开发的朋友来说，这个项目就像一个精心设计的“样板间”，里面包含了从模型加载、对话管理到前端交互的一整套可参考方案。接下来，我就结合自己的实践经验，带你深入拆解一下maid项目的设计思路、技术实现以及那些值得注意的“坑”。

2. 核心架构与设计哲学解析

2.1 为什么是“移动AI”？

在深入代码之前，我们得先理解maid项目诞生的背景，也就是“移动AI”这个场景的特殊性。这直接决定了它的技术选型与普通服务器端AI应用截然不同。

核心约束是资源。一部旗舰手机的算力，可能还不及一台中端笔记本电脑，更不用说和动辄配备多张A100/H100的云服务器相比了。这里的资源包括：

计算能力（CPU/GPU/NPU）：移动端芯片虽然性能突飞猛进，但用于浮点密集型的LLM推理，依然捉襟见肘。
内存（RAM）：这是最大的瓶颈之一。一个7B（70亿）参数的模型，以FP16精度加载就需要大约14GB内存，这已经超过了绝大多数手机的物理内存上限。
存储空间：模型文件动辄几个GB，对于手机存储是个不小的负担。
功耗与发热：持续高强度的AI推理会快速消耗电量并导致设备发烫，影响体验和设备寿命。

因此，maid的设计哲学必然是“在有限资源下追求极致体验”。它不能简单地套用云端AI的那套架构，而是需要做一系列“减法”和“优化”：

模型小型化：优先选择参数量更小（如3B、7B）、但经过精调（Fine-tuned）效果不错的模型。模型格式上，会倾向于使用GGUF这种支持量化、便于在CPU上高效推理的格式。
推理效率优化：利用移动设备的异构计算能力，比如苹果的Core ML、安卓的NNAPI，或者跨平台的ONNX Runtime，来加速模型推理。同时，在代码层面进行内存使用的精细控制。
功能聚焦：不像云端助手那样追求“万能”，而是聚焦于几个核心、高频的场景，如文本对话、文档摘要、翻译等，把单点体验做深做透。
离线优先：整个应用的数据流闭环在设计上就避免了对网络的依赖，所有数据处理都在设备本地完成。

2.2 技术栈选型背后的逻辑

maid项目通常会采用一套混合技术栈，以适应跨平台（iOS、Android、桌面）的需求，并平衡开发效率与运行时性能。

前端/界面层：
- Flutter：这是一个非常可能的选择。Flutter的优势在于一套代码可以编译成iOS、Android、Web甚至桌面端的原生应用，极大地降低了跨平台开发的成本。对于maid这类工具型应用，快速的UI开发和一致的体验是关键，Flutter的响应式框架和丰富组件很合适。
- React Native / 原生开发：如果团队对特定平台有深度优化需求，也可能会选择React Native或直接使用Swift（iOS）、Kotlin（Android）开发。但考虑到项目规模和效率，Flutter的性价比通常更高。
AI推理引擎层：
- llama.cpp / whisper.cpp：这几乎是当前移动端本地运行LLM和语音识别模型的事实标准。它们用C++编写，效率极高，并且最重要的特性是对GGUF模型格式的完美支持。GGUF格式支持多种量化级别（如Q4_K_M, Q5_K_S），可以在大幅减小模型体积（有时减少70%以上）和内存占用的同时，保持可接受的质量损失。llama.cpp还提供了良好的C接口，方便被其他语言（如Dart via FFI）调用。
- ML Kit (Firebase) / Core ML：如果只想集成一些轻量级的预置AI功能（如文本识别、图像标注），而不运行完整的LLM，那么直接使用谷歌的ML Kit或苹果的Core ML会是更简单、功耗更低的选择。但maid项目的核心是通用LLM，所以大概率还是以llama.cpp为主力。
模型管理与本地存储：
- 模型文件：通常以GGUF格式存在应用的文档目录中。应用需要实现模型的下载、版本管理和缓存清理功能。
- 对话历史与配置：使用轻量级本地数据库，如SQLite，或者直接序列化为JSON文件存储。这里的关键是数据结构设计要便于快速检索和上下文加载。

注意：技术选型不是一成不变的。例如，如果目标平台是苹果全家桶（iOS/macOS），那么直接使用llama.cpp的Metal后端可以获得最佳的GPU加速。如果是安卓平台，则需要关注其对ARM NEON指令集的优化程度。

2.3 典型工作流剖析

一个完整的“用户提问-助手回答”流程在maid内部是如何运作的呢？我们可以拆解成以下几个步骤：

输入捕获：用户通过文本输入框或语音输入（集成whisper.cpp）提交问题。
上下文组装：应用从本地数据库中取出最近几轮的对话历史（例如最近10轮），将它们按照模型要求的提示词（Prompt）模板组装成一个完整的上下文序列。例如，常见的[INST]、<<SYS>>等标签会被插入，以区分系统指令、用户消息和助手回复。
推理请求：将组装好的上下文文本，通过FFI（外部函数接口）调用，传递给后台运行的llama.cpp推理引擎。同时传递生成参数，如最大生成长度（max_tokens）、温度（temperature）、重复惩罚（repeat_penalty）等。
流式解码与显示：llama.cpp开始推理。为了提升用户体验，不会等整个回答生成完再返回，而是采用流式输出。每生成一个token（词元）或一小段文本，就立即通过回调函数返回给前端界面，实现“一个字一个字打出来”的效果。
结果处理与存储：当推理结束（达到最大长度或遇到停止符），完整的助手回复会被保存到本地数据库的对话记录中，完成本轮交互。

这个流程看似简单，但每个环节都有优化点。比如在上下文组装环节，如何高效地从数据库读取和拼接历史消息？在流式解码环节，如何保证前端UI不卡顿？这些细节决定了应用的流畅度。

3. 关键实现细节与实操要点

3.1 模型的选择、下载与量化

模型是maid项目的灵魂。选错了模型，要么跑不起来，要么效果太差，体验直接归零。

第一步：模型选择对于移动端，我们几乎不会考虑超过13B参数的模型，7B及以下是主流选择，3B甚至1.5B的模型在低端设备上更有优势。除了参数量，还要看模型类型：

基础模型 vs. 对话模型：一定要选择经过对话指令精调（Instruction-tuned）的模型，例如Mistral-7B-Instruct-v0.3、Llama-3.2-3B-Instruct、Qwen2.5-7B-Instruct等。基础模型（如Llama-3.2-3B）没有经过对话训练，你问它问题，它可能会继续写一段散文，而不是回答问题。
多语言支持：如果你的用户需要中文，就必须选择在中文语料上训练过或精调过的模型，如Qwen系列、Yi系列或DeepSeek系列。纯英文模型的中文能力通常很弱。

第二步：获取GGUF格式文件Hugging Face是模型仓库的首选。你需要找到目标模型的GGUF版本。通常，社区用户会上传他们量化好的GGUF文件。例如，在TheBloke这个用户的仓库下，你能找到几乎所有流行模型的多种量化版本。

量化等级解读：GGUF文件名中会包含量化信息，如Q4_K_M、Q5_K_S、Q8_0等。
- Q后面的数字表示权重量化到多少位（bit）。Q4就是4比特，Q5是5比特，Q8是8比特（接近FP16）。位数越低，模型越小、推理越快，但精度损失越大。
- K表示使用了K-quant方法，这是一种更先进的量化技术，能在低比特下保持更好质量。
- _M、_S等后缀表示该量化配置中的子类型（如_M代表中等，_S代表小）。通常Q4_K_M是体积、速度和质量的较好平衡点，非常适合移动端。

实操建议：在应用内集成一个简单的模型下载器。提供一个列表，让用户选择他们想下载的模型（给出清晰的参数和大小说明）。下载时一定要显示进度，并做好断点续传和校验（检查文件的SHA256哈希值），因为模型文件很大，下载失败是常事。

3.2 与llama.cpp的高效集成

这是整个项目的技术核心。你不可能自己去重写一个高效的LLM推理引擎，所以集成llama.cpp是必由之路。

对于Flutter应用：

编译llama.cpp库：你需要为每个目标平台（iOS的arm64、Android的arm64-v8a/x86_64）交叉编译llama.cpp，生成静态库（.a）或动态库（.so/.dylib）。这个过程需要配置好CMake和对应平台的工具链，是第一个小门槛。
通过FFI调用：Flutter使用Dart语言，需要通过dart:ffi库来调用C语言编写的llama.cppAPI。你需要编写大量的绑定代码，将C函数签名映射为Dart函数。例如，llama_model_load,llama_tokenize,llama_decode,llama_token_to_piece等关键函数都需要绑定。
管理模型生命周期：在Dart侧，你需要封装一个Model类，在其initState中调用llama_model_load加载模型文件，在dispose中调用llama_free释放资源。加载模型是阻塞操作，一定要放在异步线程（Isolate）中，避免卡死UI。
实现流式推理：llama.cpp的推理通常在一个循环中完成。你调用llama_decode处理当前token，然后从logits中采样得到下一个token，再将其解码为文本片段返回。这个循环需要在一个单独的Isolate中运行，并通过SendPort将生成的文本片段流式地发送回主Isolate，更新UI。

一个简化版的Dart侧调用流程伪代码：

// 在后台Isolate中 void runInference(List<int> inputTokens) { // 1. 创建上下文 var ctx = llama_init_from_model(model, params); // 2. 评估初始prompt llama_decode(ctx, inputTokens); // 3. 循环生成 int newToken; do { // 采样下一个token newToken = llama_sample(ctx); // 将token解码为文本字符串 String piece = llama_token_to_piece(ctx, newToken); // 将文本片段发送回主线程更新UI sendPort.send(piece); // 将新token加入上下文并继续解码 llama_decode(ctx, [newToken]); } while (newToken != endOfTextToken && 生成长度未超限); llama_free(ctx); }

踩坑记录：

内存管理：C库的内存必须由C库自己释放，Dart的GC管不了。务必确保每个llama_model_load都有对应的llama_free，每个llama_context都被正确释放，否则会导致内存泄漏，最终应用崩溃。
线程安全：llama.cpp的上下文（llama_context）不是线程安全的。不要试图在多个Isolate中共享同一个上下文进行推理。正确的做法是为每个需要并行处理的会话（如果支持的话）创建独立的上下文，或者严格序列化所有推理请求。
提示词模板：不同的模型使用不同的提示词格式。Llama 3的格式和Mistral、ChatML格式都不一样。你必须严格按照模型要求的格式组装上下文，否则模型会“理解错题意”，输出乱码或胡言乱语。这部分逻辑应该抽象成一个PromptFormatter类，根据加载的模型类型自动切换模板。

3.3 对话上下文的高效管理

LLM之所以能进行连贯的多轮对话，是因为它在生成每个回复时，都能“看到”之前的对话历史。如何高效地管理和使用这些历史记录，直接影响对话质量和性能。

1. 存储设计：在SQLite中，你至少需要两张表：

conversations：记录会话元信息，如id、标题（可用首句自动生成）、创建时间。
messages：记录每条消息，包含id、所属会话id、角色（user/assistant/system）、内容、时间戳。

2. 上下文窗口与截断：模型有一个固定的上下文长度（如Llama 3.2 3B是128K，但实际能有效利用的短很多）。你不可能把上百条历史记录都塞进去。

策略：通常采用“滑动窗口”策略。只加载最近N条消息（例如10条），或者更智能地，优先保留最近的消息和那些被标记为重要的消息（比如用户手动固定的消息）。
实现：每次推理前，从数据库中查询出当前会话的最近N条消息，按时间顺序排列，然后调用PromptFormatter将它们格式化成模型所需的完整Prompt字符串。

3. Token计数与优化： Prompt字符串在送给模型前，会被转换成一系列的token。你需要知道当前Prompt的token数量，以确保它不超过模型的上下文限制。

使用llama_tokenize：在真正推理前，可以先用llama_tokenize函数将Prompt字符串转换成token列表，并获取列表长度。如果长度超限，就需要触发截断策略，比如从最旧的消息开始删除，直到token数在限制内。
缓存Token化结果：对于不变的系统指令和较长的历史消息，可以缓存其token化后的结果，避免每次推理都重复进行tokenize计算，提升性能。

4. 性能优化与内存管理实战

在资源受限的移动设备上，性能优化不是可选项，而是生存法则。优化得好，7B模型也能流畅对话；优化得差，3B模型都可能卡成幻灯片。

4.1 推理速度优化技巧

量化是最大的加速器：如前所述，使用Q4_K_M或Q5_K_S量化模型，相比FP16原模型，推理速度能有数倍提升，同时内存占用大幅减少。这是提升速度最有效的一步。
批处理与缓存：
- Prompt缓存：如果系统指令很长且固定，可以预先将其token化并缓存，每次推理时直接拼接，省去重复处理的时间。
- KV缓存：llama.cpp内部会维护一个Key-Value（KV）缓存，用于存储之前所有token的注意力计算结果。在流式生成过程中，这个缓存会被复用和更新。你需要确保在连续生成时，正确地复用同一个上下文（llama_context），而不是每次生成新token都从头开始计算。
生成参数调优：
- 温度（Temperature）：控制输出的随机性。设为0会使输出完全确定（贪婪解码），速度最快，但可能枯燥重复。设为0.7~0.9是创造性和稳定性的平衡点。在移动端，为了响应速度，可以适当调低（如0.5）。
- top-p (nucleus sampling)和top-k：这些采样策略会影响生成每个token时的计算量。top-k=40和top-p=0.9是常见设置。在极端追求速度时，可以尝试更小的k值或禁用top-p。
利用硬件加速：
- iOS/macOS：确保编译llama.cpp时开启了Metal支持。Metal可以利用苹果设备的GPU进行大规模并行计算，对于解码器层的矩阵运算加速效果显著。
- Android：关注llama.cpp对ARM NEON（SIMD指令集）的优化，这是CPU层面的加速。对于有NPU的设备，可以探索通过Android NNAPI来调用，但这需要llama.cpp或自定义内核的支持，目前还不成熟。

4.2 内存使用的精细控制

内存崩溃是移动端AI应用最常见的死因。必须像管理自家水缸一样管理内存。

模型加载阶段：
- 使用mmap：llama.cpp在加载GGUF模型时，默认会使用内存映射（mmap）。这意味着模型文件并不是被全部读入物理内存，而是按需将部分数据映射到内存地址空间。这大大降低了初始内存压力。你需要确保这个特性被开启。
- 控制线程数：llama.cpp在推理时会使用多线程。更多的线程可能加快速度，但每个线程都会创建自己的中间缓冲区，增加内存开销。在内存紧张的设备上，可能需要将线程数（n_threads）设置为2或4，而不是CPU核心数。
推理过程中的内存：
- 上下文长度是内存杀手：KV缓存的大小与上下文长度（Prompt token数 + 已生成token数）成正比。一个很长的上下文会消耗巨量内存。务必严格限制最大上下文长度。对于7B模型，将上下文限制在2048或4096个token是安全的；对于3B模型，可以适当放宽，但也不要超过8192。
- 及时清理：当一次对话会话结束或用户开始新话题时，应该释放当前的llama_context，然后重新创建一个。长期不释放，KV缓存会一直增长。
应用层内存管理：
- 监控内存警告：iOS和Android都有内存压力回调机制。当系统发出低内存警告时，你的应用必须快速响应：可以主动释放一些缓存（如已结束会话的模型上下文），甚至提示用户当前会话过长，建议开始新会话以释放内存。
- 图片、音频等资源：如果应用还涉及多模态（如图片理解），那么图片解码后的Bitmap数据也是内存大户。务必在使用后及时回收，避免内存累积。

4.3 功耗与发热应对策略

用户不会容忍一个让手机在十分钟内变成“暖手宝”的应用。

推理强度控制：提供“省电模式”或“快速回复模式”。在此模式下，使用更小的量化模型（如从Q4切换到Q3），降低生成的最大token数，或者降低温度以减少计算复杂度。
后台策略：当应用进入后台时，应立即暂停任何正在进行的推理任务，并释放模型上下文。可以在应用即将回到前台时再重新加载。这能有效减少不必要的耗电。
用户提示：在长时间、高强度的生成任务开始前，可以友好地提示用户：“即将进行较长文本生成，可能会增加设备发热和耗电，是否继续？” 给予用户控制权。
性能监控与降级：实现一个简单的性能监控器。如果检测到连续多次推理帧率过低或设备温度过高，可以自动触发降级策略，比如切换到更轻量的模型或限制生成速度。

5. 进阶功能与扩展思路

一个基础的本地对话助手实现后，可以考虑为其增加更多实用功能，提升其价值。

5.1 多模态能力初探

让maid不仅能读文字，还能“看”图片和“听”声音，会大大扩展其应用场景。

视觉模型集成：可以集成一个轻量级的视觉语言模型（VLM），如Moondream、LLaVA或Qwen-VL的移动端版本。流程是：用户上传图片 -> 使用VLM将图片内容转换为详细的文本描述 -> 将该描述作为上下文的一部分，连同用户的问题一起送给文本LLM进行回答。这里的关键同样是找到足够小、足够快的VLM，并且处理好图片预处理（缩放、归一化）的流程。
语音输入输出：
- 输入：集成whisper.cpp，这是一个专为移动端优化的语音识别引擎。用户说话后，语音被识别为文字，再送入LLM。这需要处理音频录制、降噪、以及whisper.cpp模型的加载和推理。
- 输出：集成一个本地TTS（文本转语音）引擎，如Piper或Coqui TTS的移动端版本，将LLM生成的文字朗读出来。这能打造一个完全离线的、语音交互的AI助手体验。

实操心得：多模态功能的添加会显著增加应用的复杂度和体积（因为要额外加载视觉或语音模型）。建议将其设计为可选的插件或模块，让用户按需下载启用，而不是一股脑全打包进安装包。

5.2 工具调用与自动化

让AI助手不仅能说，还能“做”。通过工具调用（Function Calling），maid可以连接设备本地的其他能力。

核心思想：定义一套工具（函数）列表，例如search_contacts(名字),create_calendar_event(标题, 时间),read_file(路径)等。当LLM认为用户请求需要调用工具时，它会在回复中输出一个结构化的工具调用请求。应用解析这个请求，执行对应的本地函数，将执行结果再返回给LLM，由LLM总结后回复给用户。
实现难点：
1. 提示词工程：需要在系统指令中清晰地描述每个工具的功能、参数格式，并训练（或引导）模型学会在合适的时候使用它们。这通常需要精心设计的示例对话（few-shot examples）。
2. 输出解析：需要可靠地解析模型输出的结构化文本（通常是JSON），并处理解析失败的情况。
3. 安全边界：工具调用权限必须严格控制。文件读取工具可能只能访问应用沙箱内的特定目录，绝不能允许模型直接执行系统命令或访问敏感数据。

5.3 数据持久化与知识库

让助手记住更多关于“你”的信息，提供个性化服务。

向量数据库本地集成：可以集成一个轻量级的本地向量数据库，如Chroma（有移动端移植版）或LanceDB。将用户的重要文档、笔记、聊天记录中的关键信息，通过一个小型的嵌入模型（Embedding Model）转换成向量，存储起来。
检索增强生成（RAG）：当用户提问时，先从本地向量数据库中检索出相关的信息片段，然后将这些片段作为“参考材料”和用户问题一起送给LLM。这样，LLM就能基于你的个人资料和历史信息来回答，实现“个性化记忆”。例如，你可以问：“我上周提到的那个项目进展如何了？”，助手能从你的会议纪要向量库中检索出相关信息来回答。
隐私考量：所有向量化和检索过程都在本地完成，这是与云端方案最本质的区别，也是最大的优势。

6. 常见问题、调试与避坑指南

开发过程中一定会遇到各种问题，这里记录一些典型场景和解决思路。

6.1 模型加载与推理失败

问题：应用启动时崩溃，或加载模型时闪退。
排查：
1. 检查模型文件：确认GGUF文件已完整下载，没有损坏。对比文件的SHA256哈希值。
2. 检查内存：在加载模型前和加载后，打印当前应用的内存占用。如果加载后内存暴增并接近设备物理内存上限，很可能会被系统杀死。解决方案是换用更小的模型或更高的量化等级。
3. 检查FFI绑定：确保llama.cpp的C函数签名与Dart侧的FFI绑定完全匹配，特别是指针和结构体类型。一个错误的绑定可能导致非法内存访问，立即崩溃。
4. 查看日志：llama.cpp在初始化时通常会输出一些日志到标准错误。在移动端，你需要将这些日志重定向到你可以查看的地方（如Android的Logcat，iOS的Console）。
问题：推理时输出乱码、胡言乱语或重复循环。
排查：
1. 首要怀疑提示词格式：这是最常见的原因。请百分之百确认你组装的Prompt字符串完全符合当前加载模型所要求的格式。去该模型的Hugging Face页面或官方文档，找到对话模板（Chat Template），逐字符核对。
2. 检查温度参数：如果温度（temperature）设置过高（如大于1.5），输出会非常随机，可能像乱码。尝试将其设为0（贪婪解码），如果输出变得连贯但重复，说明模型本身是好的，问题在采样策略。
3. 检查上下文：确认你传递给模型的完整上下文（历史+当前问题）没有错误，特别是角色标识符（如[INST],<<SYS>>,user:,assistant:）没有错位或缺失。

6.2 性能问题排查

问题：生成速度非常慢，每秒只能出1-2个token。
排查：
1. 确认量化等级：你加载的是Q8_0还是Q4_K_M？Q8_0的速度会慢很多。使用Q4_K_M或Q5_K_S。
2. 确认硬件加速：在iOS上，检查llama.cpp是否编译了Metal支持，并在初始化上下文时是否设置了gpu-layers参数（将部分模型层卸载到GPU）。可以尝试设置-ngl 20或更高（取决于你愿意让GPU内存占用多少）。
3. 检查线程数：确保推理线程数（n_threads）设置合理。可以设为设备CPU的大核数量（通常为2-4个）。设置过多的小核线程可能因调度开销反而变慢。
4. ** profiling**：如果可能，对推理循环进行简单的性能分析，看看时间主要花在llama_decode上还是采样上。

6.3 用户体验优化点

首次启动慢：模型加载需要时间。可以设计一个优雅的加载界面，显示进度和提示信息。甚至可以考虑在应用安装后，在后台空闲时预加载一个默认的小模型。
输入响应迟滞：用户点击发送后，到开始看到第一个字输出，这中间有时间间隔（用于tokenize和首次解码）。可以通过预加载对话上下文、优化tokenize缓存来缩短这个“首字延迟”。
生成中断：用户可能想在生成中途停止。必须提供一个显眼的“停止”按钮，点击后能立即中断后台的推理Isolate。
上下文管理透明化：用户可能不理解为什么助手“忘了”很久以前说的话。可以在UI上提供一个简单的指示，比如“正在使用最近10条对话作为上下文”，或者让用户手动选择将某条消息“固定”在上下文中不被滚动出去。

开发像maid这样的移动端本地AI应用，是一场在性能、效果和资源之间不断寻找平衡的旅程。它没有云端方案那种“暴力”的算力优势，但也因此逼着我们去深入理解模型、推理和系统优化的每一个细节。每解决一个崩溃，每优化一次速度，带来的成就感都是实实在在的。这个领域还在快速演进，新的轻量化模型、更高效的推理引擎不断出现，持续学习和实验，是保持项目活力的关键。

查看全文

http://www.jsqmd.com/news/740710/