LiteRT-LM 搭上 Gemma 4 多 token 预测，端侧推理提速 2.2 倍

端侧跑大模型，瓶颈从来不是模型有多聪明，而是 token 一个一个往外蹦的速度够不够用。Google 最新发布的 LiteRT-LM 把 Gemma 4 的 Multi-Token Prediction（MTP）drafter 原生接进推理引擎，实测推理速度最高提升 2.2 倍——不是靠砍精度，而是靠更聪明的投机解码策略。同时，框架的 API 版图也在扩张：新增了 Swift 和 JavaScript 绑定，不再只绑在 Kotlin 和 C++ 上。

投机解码的旧问题与新解法

投机解码（speculative decoding）的核心思路很简单：用一个轻量"草稿模型"快速猜出多个后续 token，再让大模型一次性验证，猜对的直接采纳，猜错的回退重算。理论上加速比取决于草稿模型的命中率——命中率越高，大模型需要重新计算的次数越少。

现实中的老问题是：草稿模型和主模型是两个独立模型，部署时要打包两套权重，命中率也受限于草稿模型与主模型的分布差异，实际加速往往在 1.3–1.5x 左右就卡住了。

Gemma 4 的 MTP drafter 换了一条路：草稿能力不是外挂的，而是主模型自带的辅助头。训练时就已经学会一次预测多个后续 token，推理时直接复用主模型权重中的 drafter 头。好处是——分布天然对齐，命中率更高；部署时只带一套权重，没有额外的存储开销。

LiteRT-LM 这次做的，就是把这套 MTP drafter 的推理流程原生集成进端侧引擎，不需要开发者手动拼两个模型的调用逻辑。

2.2 倍加速从哪来

加速比不是固定值，取决于几个因素：

• drafter 的猜测长度：MTP 一次能预测多少个后续 token。Gemma 4 的 drafter 头支持多步预测，每步多一个候选 token。
• 验证接受率：主模型对草稿 token 的接受比例。分布对齐时，接受率可以到 80–90% 以上。
• 硬件并行度：验证阶段是否能在 GPU/NPU 上高效并行执行。

在 Google 给出的基准中，Gemma 4 配合 MTP 在端侧设备上达到最高 2.2x 的 token 生成加速。这个数字的前提是 drafter 命令率足够高、验证并行度足够好。在更保守的场景（长上下文、低接受率），加速比会回落，但仍然显著优于单 token 串行推理。

关键点：2.2x 是生成阶段的加速，不影响模型的理解能力或输出质量——验证机制保证最终输出和标准推理完全一致。

实战：用 LiteRT-LM 跑 Gemma 4 MTP 推理

下面是一个 Kotlin 示例，展示如何在 Android 端侧用 LiteRT-LM 加载带 MTP drafter 的 Gemma 4 模型并执行推理。这是目前最成熟的 API 路径。

// build.gradle.kts 中添加依赖
// dependencies {
//     implementation("com.google.ai.litert:litert-lm:0.3.0")
// }

import com.google.ai.litert.lm.LiteRTLM
import com.google.ai.litert.lm.LiteRTLMConfig

fun runGemma4MTP() {
    // 1. 配置推理引擎，启用 MTP 投机解码
    val config = LiteRTLMConfig(
        modelPath = "/data/local/tmp/gemma4-2b-it-litert.task",  // LiteRT 任务包路径
        enableMTPDrafting = true,   // 关键开关：启用 Gemma 4 MTP drafter
        maxDraftTokens = 5,         // drafter 每次最多猜测 5 个后续 token
        temperature = 0.7f,
        topK = 40,
    )

    // 2. 创建引擎实例
    val engine = LiteRTLM.create(config)

    // 3. 发起推理
    val prompt = "用三句话解释什么是投机解码。"
    val result = engine.generate(prompt, maxTokens = 256)

    // 4. 输出结果与统计
    println("输出: ${result.text}")
    println("生成 token 数: ${result.tokenCount}")
    println("MTP 接受率: ${result.draftAcceptRate}")  // 观察实际命中率
    println("推理耗时: ${result.latencyMs} ms")

    // 5. 释放资源
    engine.close()
}

运行前需要准备：

1. 从 Google 的模型分发渠道下载 Gemma 4 的 LiteRT 格式任务包（.task 文件），该包内已包含 MTP drafter 头的权重。
2. 将 .task 文件推到设备的 /data/local/tmp/ 目录，或放在 app 的私有存储中。
3. maxDraftTokens 可根据设备算力调整——NPU 并行度高的设备可以设到 5 甚至更高；算力有限的设备建议从 3 开始，避免验证阶段成为新瓶颈。

新语言 API：Swift 和 JavaScript 入场

LiteRT-LM 此前的 API 只覆盖 Kotlin（Android）和 C++（跨平台底层），这次新增了 Swift 和 JavaScript 绑定，意味着 iOS 端和 Web/Node.js 端也能直接调用。

一个 Swift 的最小调用示例：

// Package.swift 中添加依赖
// .package(url: "https://github.com/google/litert-lm-swift", from: "0.3.0")

import LiteRTLM

func runGemma4MTP() {
    let config = LiteRTLMConfig(
        modelPath: Bundle.main.path(forResource: "gemma4-2b-it-litert", ofType: "task")!,
        enableMTPDrafting: true,
        maxDraftTokens: 5,
        temperature: 0.7,
        topK: 40
    )

    let engine = try! LiteRTLM.create(config)
    let result = try! engine.generate(prompt: "Explain speculative decoding in three sentences.", maxTokens: 256)

    print("Output: \(result.text)")
    print("Draft accept rate: \(result.draftAcceptRate)")
    print("Latency: \(result.latencyMs) ms")

    engine.close()
}

JavaScript API 适合在 Node.js 服务端或浏览器 WebGPU 场景使用，具体包名和调用方式以 Google 官方 npm 包发布为准。核心参数结构与 Kotlin/Swift 一致：enableMTPDrafting + maxDraftTokens 是加速的关键配置项。

落地前想清楚这几件事

MTP 投机解码不是万能加速器，实际收益取决于场景和硬件：

建议的接入路径：

1. 先量基线：用不带 MTP 的 LiteRT-LM 跑一遍目标场景，记录 token/s 和延迟。
2. 开 MTP 对比：同一模型、同一硬件，开启 enableMTPDrafting，从 maxDraftTokens=3 开始，观察 draftAcceptRate。
3. 调参数：接受率 > 80% 时，可以逐步提高 maxDraftTokens；接受率 < 60% 时，降低猜测长度或检查模型版本是否包含 MTP 头。
4. 选平台：Android 用 Kotlin，iOS 用 Swift，服务端/Web 用 JavaScript——API 结构一致，迁移成本很低。

最后一点：MTP drafter 的权重是训练时绑定的，不是事后外挂。这意味着你只能用在已经训练了 MTP 头的 Gemma 4 模型上，不能随便拿一个第三方模型加 drafter。如果你用的是自训模型，需要自己在训练阶段加入 MTP 辅助头，LiteRT-LM 的推理侧才能接上。