在移动设备上运行能够同时理解图像和生成文本的多模态模型，已经成为不少应用差异化竞争的关键能力。所谓Android多模态模型图文生成，是指将一个接收图片与提示词、输出自然语言描述的模型完整部署到Android客户端，并借助端侧算力完成推理。相比依赖远程接口，这种做法能显著降低响应延迟，也能在弱网环境下保持功能可用。本文将从模型选型、工程集成以及性能优化三个层面，拆解在Android平台落地图文生成能力的核心路径。
多模态模型在Android上的选型与格式转换
目前适合端侧运行的多模态模型主要分为两类：一类是统一结构的视觉语言模型，例如将图像编码器与轻量语言模型融合后的VLM；另一类是通过桥接方式组合图像特征提取与文本生成模块的流水线方案。对于Android开发者而言，第一步往往是把训练框架导出的模型转换成移动端推理引擎支持的格式。TensorFlow Lite、ONNX Runtime Mobile以及MediaPipe Model Maker都提供了对应的转换工具，但各自的算子支持和量化策略并不完全一致。
以PyTorch训练的模型为例，通常先导出为ONNX，再使用对应工具做量化压缩。下面是一个将浮点模型转换为INT8 ONNX的简化脚本示例，实际项目中还需要准备校准数据集：
import torch
import torchvision.models as models
from torch.onnx import export
# 假设有一个图文联合模型
class DummyVLM(torch.nn.Module):
def forward(self, image, text_ids):
# 仅作结构演示
return torch.rand(1, 20, 30522)
model = DummyVLM()
image = torch.rand(1, 3, 224, 224)
text_ids = torch.randint(0, 30522, (1, 16))
export(
model,
(image, text_ids),
"vlm_float.onnx",
input_names=["image", "text_ids"],
output_names=["logits"],
dynamic_axes={"text_ids": {1: "seq"}, "logits": {1: "seq"}}
)
print("已导出浮点ONNX模型")
转换为移动格式后，需要重点检查算子覆盖率。部分多模态模型使用的自定义注意力算子，在TFLite中可能没有原生支持，此时要么改写网络结构，要么借助Delegate机制调用NNAPI或GPU后端。如果选择ONNX Runtime，则可以利用其内置的算子库减少兼容问题，但包体积会略大。量化方面，INT8在多数中端机上表现稳定，而INT4能进一步压缩模型，却可能让生成文本的流畅度下降，需要结合业务容忍度权衡。
Android工程中的推理集成与线程调度
将模型放入Android工程后，真正的挑战在于如何让图文生成既快又稳。图像输入一般来自相机或相册，需先缩放到模型要求的尺寸，并做归一化处理。文本提示则要先分词，再构造输入张量。建议把图像解码、预处理与模型推理分布在不同线程，避免阻塞UI。对于语言解码部分，应采用自回归生成并配合KV缓存，防止每一步都重复计算历史隐藏状态。
下面展示一个使用Kotlin调用ONNX Runtime进行推理的骨架代码，其中省略了具体的分词与后处理细节：
import ai.onnxruntime.*
import android.graphics.Bitmap
fun runVlm(bitmap: Bitmap, prompt: String, ort: OrtEnvironment): String {
val resized = Bitmap.createScaledBitmap(bitmap, 224, 224, true)
val inputTensor = preProcess(resized) // 返回 FloatBuffer
val promptIds = tokenize(prompt) // 返回 LongArray
val imageT = OnnxTensor.createTensor(ort, inputTensor, longArrayOf(1, 3, 224, 224))
val textT = OnnxTensor.createTensor(ort, promptIds, longArrayOf(1, promptIds.size.toLong()))
val results = ort.createSession("vlm_int8.onnx").run(
mapOf("image" to imageT, "text_ids" to textT)
)
val logits = results[0].value as Array<FloatArray>
return decode(logits)
}
在工程实践中，不少团队会引入MediaPipe的Task API来搭建图文流水线，这样能把图像特征提取、张量传递与文本解码封装成标准节点。它的优势在于节点调度由底层统一管理，开发者只需关心输入输出。但若模型结构特殊，MediaPipe的预置任务可能不够用，这时直接基于ONNX Runtime写推理逻辑反而更灵活。无论哪种方式，都应在Application初始化时加载推理引擎，并在低内存设备上限制并发生成长度，以防系统杀掉进程。
端侧图文生成的性能优化与避坑要点
端侧多模态推理最容易踩的坑是内存峰值过高。图像编码与语言模型解码若共用同一块大内存，在生成较长描述时极易触发OOM。优化思路包括：将图像编码阶段放在native堆处理、限制最大生成token数、以及使用内存映射方式读取模型权重。另一个常见问题是NNAPI delegate在某些芯片上加速效果反而不如CPU，因此在发布前应在目标机型上做实测，而不是默认开启硬件代理。
针对推理延迟，可以借鉴以下对比策略。下表列出三种部署方式的典型表现：
| 方案 | 包体积增量 | 首字延迟 | 适用场景 |
|---|---|---|---|
| TFLite INT8 | 约40MB | 300ms左右 | 对体积敏感的工具类应用 |
| ONNX Runtime INT4 | 约90MB | 500ms左右 | 需跨平台复用的复杂逻辑 |
| MediaPipe流水线 | 约70MB | 400ms左右 | 快速搭建标准多模态任务 |
除了上述手段，输入图像的预处理也值得细化。如果原始图片分辨率很高，先使用Bitmap采样到模型输入尺寸，再转RGB通道顺序，能省去大量不必要的像素运算。文本侧则可以对提示词做模板裁剪，避免超长上下文拖慢解码。最后，发布前务必在Android 8到Android 14的多台设备上验证，因为不同系统版本对神经网络API的支持差异，会直接影响图文生成功能的稳定性。