让一个微调过的GPT模型在Android手机上离线跑起来，需要微调、量化、部署三个环节无缝接力，任何一步选型失误，最终都会以内存溢出或者每秒一两个token的龟速收场。这篇文章把整条链路拆开讲透：从训练侧的LoRA低成本微调，到模型侧的GGUF格式转换与压缩，再到端侧推理框架的集成代码，最后给出一份实测有效的性能调优清单，你可以按顺序照做，也可以直接跳到自己关心的环节。

一、为什么要把推理搬到手机端

先回答一个前提问题：云端API明明够用，为什么还要折腾本地推理。第一是隐私，聊天记录、病历、备忘录这类数据一旦出了设备，合规成本和用户信任风险都会陡增，而本地推理天然满足数据不出域的要求。第二是延迟，云端请求要经历网络往返、排队、流式回传，弱网环境体验极差，本地推理首token延迟可以压到几百毫秒以内。第三是成本，API按token计费，高频调用场景下账单会失控，本地运行只有一次性的模型下发成本。

但端侧的约束同样真实。一部8GB内存的中端机，系统和其他应用常驻后留给你的可用内存往往只有2GB左右；SoC的大核数量有限，长时间满载推理还会触发温控降频。这意味着模型规模必须控制在0.5B到2B参数之间，且权重要经过激进量化。经验上，1.5B参数的模型量化到4比特后体积约1GB，运行时总内存占用在1.5GB上下，是中端机可以稳定承载的上限。超过这个规模，闪退和被系统杀进程会成为常态。

还有一点容易被忽视：端侧模型不需要追求数据面上的全能。它只需要在你的垂直场景里表现好，这正是微调的价值所在，用一个通用小模型加少量领域数据，换一个离线可用的专属助手。

二、微调环节：LoRA让消费级显卡也能训练专属模型

直接全参数微调一个1.5B的GPT模型，显存需求轻松超过30GB，消费级设备根本扛不住。LoRA的思路是冻结基座模型的所有权重，只在注意力层旁边插入两个低秩矩阵做训练，可训练参数量通常只占整体的百分之一以下，一张12GB显存的显卡就能完成训练，训练产物是一个几十MB的适配器文件。

基座模型的选择很关键。手机端优先考虑Qwen2.5-0.5B、Qwen2.5-1.5B、TinyLlama这类小尺寸模型，它们在中文语料上的表现和量化友好度都不错。下面是一段基于transformers和peft的完整微调代码：

from transformers import AutoModelForCausalLM, AutoTokenizer, TrainingArguments
from peft import LoraConfig, get_peft_model
from trl import SFTTrainer
base_model = "Qwen/Qwen2.5-1.5B"  # 手机端建议选1.5B以下的小模型
tokenizer = AutoTokenizer.from_pretrained(base_model)
model = AutoModelForCausalLM.from_pretrained(
    base_model,
    torch_dtype="float16",
    device_map="cuda"
)
# 配置LoRA适配器，只训练注意力投影层的低秩矩阵
lora_config = LoraConfig(
    r=16,
    lora_alpha=32,
    target_modules=["q_proj", "k_proj", "v_proj", "o_proj"],
    lora_dropout=0.05,
    task_type="CAUSAL_LM"
)
model = get_peft_model(model, lora_config)
model.print_trainable_parameters()  # 观察可训练参数占比
trainer = SFTTrainer(
    model=model,
    train_dataset=dataset,  # 格式为包含instruction和output字段的对话数据
    args=TrainingArguments(
        per_device_train_batch_size=4,
        gradient_accumulation_steps=8,
        learning_rate=2e-4,
        num_train_epochs=3,
        output_dir="./lora_output",
        bf16=True
    )
)
trainer.train()
trainer.save_model("./lora_output")

几个实操细节值得强调。数据集格式建议统一成instruction、input、output三字段结构，几千条高质量样本就足以让模型学会你的业务话术，盲目堆量反而会让小模型过拟合。学习率对LoRA来说2e-4是稳妥起点，调到1e-3容易把适配器训崩。秩r的取值不必贪大，r取16到32之间的效果差异很小，但文件体积和训练耗时差别明显。训练完成后先用print_trainable_parameters确认可训练参数占比确实在1%以下，否则说明配置有误。

三、量化与格式转换：体积和精度的平衡术

训练得到的LoRA适配器不能直接在手机上跑，需要先合并回基座模型，再转换成端侧框架能识别的格式。目前Android生态的事实标准是GGUF格式，配套的量化工具链也最成熟。整个转换流程如下：

# 第一步：把LoRA适配器合并回基座模型
python merge_lora.py \
    --base_model Qwen/Qwen2.5-1.5B \
    --adapter ./lora_output \
    --output ./merged_model
# 第二步：转换为GGUF格式（fp16精度）
python convert_hf_to_gguf.py ./merged_model --outfile qwen-ft-f16.gguf
# 第三步：量化为Q4_K_M，体积压缩到原来的四分之一左右
llama-quantize qwen-ft-f16.gguf qwen-ft-q4km.gguf Q4_K_M

量化等级的选择直接决定最终体验，不同等级的实测数据可以参考下表（以1.5B模型为例）：

一个常见误区是盲目追求更小的量化等级。Q3以下的小模型经常出现指令遵循能力崩坏的情况，表现为答非所问或者循环输出同一段话，这类问题排查起来非常耗时。建议先用Q4_K_M做基线，在目标机型上跑通全流程后，再根据内存压力逐步下调。另外，量化会放大微调数据里的噪声，如果发现量化后效果下降明显，优先回头清洗训练数据，而不是调整量化参数。

四、Android端集成：llama.cpp与MediaPipe两条路线

端侧推理目前有两条主流路线。第一条是llama.cpp，用NDK交叉编译出各CPU架构的动态库，通过JNI调用，自由度最高，支持GGUF格式的全部量化等级，还能开启NEON指令加速。第二条是Google的MediaPipe LLM Inference API，封装程度高，几行代码就能接入，但模型需要转成它自己的task格式，且对模型架构的支持范围相对有限。先看llama.cpp路线的JNI封装：

class LlamaInference(context: Context) {
    private var modelPath: String = ""
    init {
        System.loadLibrary("llama")
        val modelFile = File(context.filesDir, "qwen-ft-q4km.gguf")
        if (!modelFile.exists()) {
            copyAssetToFile("qwen-ft-q4km.gguf", modelFile)
        }
        modelPath = modelFile.absolutePath
    }
    fun generate(prompt: String, maxTokens: Int = 256): String {
        // 上下文窗口建议控制在2048以内，过大直接挤爆内存
        val handle = loadModel(modelPath, nCtx = 2048, nThreads = 4)
        val result = StringBuilder()
        var token = complete(handle, prompt)
        var count = 0
        while (token != null && count < maxTokens) {
            result.append(token)
            token = complete(handle, "")
            count++
        }
        freeHandle(handle)
        return result.toString()
    }
    private external fun loadModel(path: String, nCtx: Int, nThreads: Int): Long
    private external fun complete(handle: Long, prompt: String): String?
    private external fun freeHandle(handle: Long)
}

如果不想维护C++层的JNI代码，MediaPipe的接入方式要省心得多，模型文件放到设备存储后直接调用即可：

val options = LlmInferenceOptions.builder()
    .setModelPath("/data/local/tmp/gemma-finetuned.task")
    .setMaxTokens(1024)
    .setTemperature(0.7f)
    .setTopK(40)
    .build()
val llm = LlmInference.createFromOptions(context, options)
val reply = llm.generateResponse("帮我用一句话总结这段会议纪要的结论：")
llm.close()

两条路线怎么选，取决于你的团队构成和性能要求。追求极致生成速度、需要支持各类开源模型架构、团队里有人能维护C++代码，选llama.cpp；希望快速上线、目标机型以新旗舰为主、对模型格式没有执念，选MediaPipe。实测数据上，llama.cpp在开启NEON和线程绑核后，1.5B的Q4_K_M模型在中端SoC上能达到每秒8到12个token，MediaPipe的差距通常在两成以内，两者都远超实时对话的流畅门槛。

五、性能调优与高频踩坑清单

集成跑通只是第一步，真正决定上线品质的是细节调优。线程数不要简单等于CPU核心总数，绑定到两个大核的效果往往好于分散到全部八个核，因为小核的拖累会抵消并行收益，这个数值建议在目标机型上实测确定。上下文窗口能砍就砍，2048够用就别开4096，KV缓存的内存占用随窗口长度线性增长，是隐性内存杀手。模型加载务必使用内存映射方式，避免把整个权重文件一次性读进堆内存。

几个高频问题的排查思路也整理如下。App启动即闪退，九成是内存不足，先换Q4甚至Q3量化，同时检查是否在主线程加载模型，加载耗时数秒会触发ANR。生成速度断崖式下降，大概率是温控降频，给推理线程降低优先级、在连续生成间隙插入短暂休眠都能缓解。输出内容混乱重复，先怀疑量化等级过低，其次检查微调数据里是否存在大量重复样本。推理过程中App被系统回收，需要把推理放到前台服务里执行，并在onTrimMemory回调中及时释放模型句柄。

最后提醒一点工程层面的经验：模型文件不要打进APK，而是放在首次启动后从CDN下发，或者随应用更新增量下载。这样模型迭代可以独立于App发版，线上出问题时也能快速回滚到旧版本权重，这在实际运营中会救命。