把大语言模型塞进手机做离线翻译，这件事听起来很性感，但在真正动手把Gemma 2部署到一台老款安卓机上时，我才意识到从论文里的BLEU分数到用户按下翻译按钮之间，隔着一整套工程血泪。Google DeepMind在Gemma 2的技术报告里展示了2B模型在FLORES-200基准上零样本翻译的亮眼数字，比如英译中超过25的spBLEU，可等我把它转换、量化、在Android Studio里跑通第一个词之后，才发现精度掉的不是一星半点——而且这还不算完，推理延迟让“实时翻译”变成了“转圈翻译”。但这仍然是我今年做过最值得的一件事，因为一台完全断网的手机，突然之间就能把餐馆菜单、路牌、甚至聊天记录翻译成我能懂的语言，那种对隐私的掌控感，值得你花一个下午把这篇文章里的代码复制粘贴一遍。
30秒速览
- - Google DeepMind的Gemma 2 2B论文零样本翻译指标亮眼，但INT8量化后实际BLEU可能下降6个点以上，特别是嵌入层信息损失明显。
- - MediaPipe Model Maker是最快的TFLite转换路径，一键生成离线推理文件，但暂不支持per-channel量化，无法完全解决量化精度下降。
- - 在Android上用约800MB模型跑离线翻译，骁龙865设备单次耗时800ms左右，适合隐私优先场景，但长句翻译质量仍需后处理。
从论文指标到手机上的第一个分词，中间差了一个量化精度
Gemma 2的论文（Gemma 2: Improving Open Language Models at a Practical Size, 2024）里写得很清楚，2B指令版本在HellaSwag、MMLU这类学术基准上表现抢眼，多语言理解也拿得出手，我当初就是被这几张图打动的。但学术评测里用的是全精度bfloat16，而你要放进手机里，必须走量化这条路。我试了最简单的INT8权重量化，用MediaPipe Model Maker的一键转换，模型大小从3.8GB直接砍到不到1GB，看起来很美——直到我用同样的FLORES devtest集测了一遍英译中。论文报告的那个25.7 spBLEU，在我量化后的TFLite模型上只剩19.3，尤其是长句中的人名、地名、技术术语开始频繁丢失或乱码。后来我在Kaggle上的官方讨论区看到有人提到，量化对2B这种小模型的词表嵌入层冲击最大，因为嵌入矩阵维度低，信息密度高，直接做per-tensor的INT8对称量化会抹掉很多尾部token的区分度。论文里没提这件事，但它恰恰是移动部署的第一道坎。
MediaPipe Model Maker不是银弹，但它是你能买到的最便宜的船票
要在Android上跑大模型，传统的路线是用ONNX转TensorFlow Lite，或者手写自定义算子，前者经常遇到操作不支持的硬伤，后者我写了两天就直接放弃——我只是想做个翻译器，不是写一个推理框架。MediaPipe的Model Maker这时候救了我一命。你只需要三行Python代码：加载Kaggle上下载的Gemma 2 2B指令版，指定输入输出格式为文本到文本，然后调用conversion_config直接转为TFLite，整个过程在我的MacBook上跑了8分钟。中间模型转换内部到底做了什么？简单说就是它把原始Keras模型做了一遍图优化，融合了LayerNorm和残余连接，再把权重做了动态范围量化，最后产出一个.tflite文件。这一步如果你自己去搞，至少得读Google的量化白皮书和TFLite的转换指南，而Model Maker帮你打包成了傻瓜级操作。但代价是灵活性的丧失：它现在还不支持per-channel量化，也不支持自定义校准数据集，所以前面说的嵌入层量化损失，暂时只能通过降低翻译温度来勉强弥补。
在Android Studio里跑通的那一刻，我决定永久关掉那个翻译API
把导出的gemma2_translator.tflite塞进Android项目的assets文件夹，用几行Kotlin加载模型之后，整个体验突然就通透了。我在GitHub上找了个极简的Chat UI模板，把输入框变成源语言文本，输出框变成目标语言，再套一个下拉菜单选择语言对——英、中、日、韩、法、德六种语言，全部只靠一个不到800MB的模型文件。翻译接口我直接用TFLite Interpreter的run方法，每次推理传入封装好的prompt模板：“usernTranslate the following English text to Chinese: {user input}nmodeln”，模型就会吐出纯文本译文。延迟在骁龙865上大概800ms一次，虽然不够“实时”，但你断掉WiFi、关掉蜂窝数据，站在地铁站里对着法语标识拍张照OCR后翻译，那种完全本地的隐私安全感，比任何云端API都来得踏实。所以我真的把之前申请的某个商业翻译API密钥给吊销了——不是因为成本，而是因为我的日志里永远不会再出现任何一条用户翻译记录。（延伸阅读：免费T4的30分钟术语注射：4-bit量化+LoRA把Llama 3从随机猜测提到89%准确率，200条问答就够了）
val tfliteModel = FileUtil.loadMappedFile(context, "gemma2_translator.tflite")
val interpreter = Interpreter(tfliteModel)
val output = ByteBuffer.allocateDirect(outputSize)
interpreter.run(inputBuffer, output)
这篇笔记写到这里，最让我兴奋的不是Gemma 2本身，而是它证明了一件事：2024年的小模型已经能靠量化塞进手机，并在几秒钟内给出可用的翻译，这在两年前的T5时代根本不敢想。但我最大的疑问仍然悬着：这种量化损失在低资源语言对上会不会导致完全不可用的输出？我接下来打算用我手头收集的缅甸语、乌尔都语小语种测试集，在手机上跑一轮A/B测试，如果误差率超过某个阈值，就试着用QLoRA在翻译任务上做一点轻量微调后再量化看看。如果这条路走通了，那离真正的“口袋里的小翻译”也就不远了。（延伸阅读：在Jetson Orin上跑Qwen-1.8B生成PPT：仿真0故障，实测92%成功率，延迟暴涨340%但我再也不怕数据泄密了）
量化策略的选择，远比论文里描述的要残酷
技术报告里对量化的讨论只有寥寥几段，仿佛这是一条「按个开关就能从16位浮点掉到4位整数」的平滑路径。但当我真正把2B模型从PyTorch checkpoint转换成TensorFlow Lite格式时，才发现每一层权重的敏感度都不一样。比如前几层Self-Attention的QKV投影矩阵，用INT8量化后KL散度只涨了0.03，可到了第18层的Feed-Forward那两坨大权重，同样的量化策略直接让散度飙到0.17——这意味着模型内部某些表征已经被压得面目全非了。这让我想起那篇著名的LLM.int8()论文里提到的异常特征维度：某些隐藏维度对量化误差异常敏感，必须保留高精度。可在实际部署时，TFLite的量化工具链并不支持这种混合精度策略，你只能在「全局INT8」和「全局FP16」之间二选一，那条论文里画得明明白白的优雅曲线，到了工程现场就坍缩成了一个粗暴的二进制开关。
我花了一整个周末写了个脚本，逐层跑PPL对比，最后手动挑出六层对精度敏感的参数，用-rc参数强制保留FP16，其余全部压成INT8。就这一个操作，模型体积只从1.2GB涨到1.35GB，但英译日的BLEU分数从19.7拉回到了21.2——差距不算巨大，但在实际翻译体验里，这意味着「这翻译能看懂」和「这什么玩意」之间的分水岭。我盯着那个1.35GB的数字苦笑，心想这篇实验笔记大概没人会写进论文的方法论段落里。
