Flyingon的博客

LiteRT-LM 在 iOS 上跑 Gemma 4：一次从 GPU 到回滚的工程复盘

Fri, 08 May 2026 00:00:00 +0800

这篇记录一次很具体的工程排查：在 iOS App 里集成 LiteRT-LM，跑 Gemma-4-E2B-it.litertlm 做本地 Vision LLM。目标不是证明某条路线一定正确，而是把当天踩到的坑、判断依据和最后保留下来的实现写清楚。

结论先放前面：

当前公开 LiteRT-LM iOS 路线下，Gemma 4 可以作为本地模型继续保留。
稳定配置是 Main executor 走 GPU，Vision executor 走 CPU。
不要把 Vision executor 强行切到 GPU；当前会在 STABLEHLO_COMPOSITE prepare、Metal texture 分配或内存压力处失败。
不切 Gemma-3n。Gemma-3n 的 Vision 子图要求 GPU，但公开 runtime 路径下 vision=gpu 创建 engine 失败，没有可用 CPU fallback。
最终代码回到单模型 Gemma 4 路线，并保留下载、多源 fallback、运行时动态加载、耗时日志和降内存参数。

一、背景：为什么选 LiteRT-LM 和 Gemma 4

AppScanFlow 原本已经有一条稳定的识别链路：

Vision OCR
  -> 规则分类
  -> 字段提取
  -> 摘要
  -> 保存结果

这条链路的优点是稳定、轻、快；缺点也明显：遇到非标准票据、跨语言字段、版式复杂图片时，需要大量规则兜底。

所以本地 LLM 的目标不是替代所有逻辑，而是增加两种可选能力：

模式	作用
OCR + Text LLM	先 OCR，再让本地 LLM 做分类、字段复核、摘要
Vision LLM	直接把图片交给本地多模态模型，返回结构化 JSON

模型侧选择 Gemma-4-E2B-it.litertlm 的原因很现实：

.litertlm 模型约 2.59GB，移动端还能接受。
GGUF 视觉路线通常还需要主模型 + mmproj，体积更大，当前不适合作为默认 App 内模型。
LiteRT-LM 是 Google 官方边缘端 LLM runtime，理论上和 Gemma 4 edge variants 配套。
Google AI Edge Gallery 宣传里已经把 Gemma 4 E2B/E4B 放到了移动端场景里。

但是“Gallery 能跑”不等于“第三方 iOS App 用公开 dylib/C API 路线也能同样跑”。这正是这次排查的核心。

二、最初现象：GPU 不像想象中那么简单

真机环境：

Device: iPhone14,3
iOS: 26.3.1
Xcode: 26.4
Model: gemma-4-E2B-it.litertlm
Runtime: LiteRT-LM v0.11.x C API bridge

一开始最自然的想法是：既然要提速，那就把 GPU 开起来。

LiteRT-LM 的 engine settings 里有两个 backend 概念：

main backend
vision backend

也就是说，Gemma 4 多模态模型不是一个整体 backend 开关，而是至少拆成两段：

Main executor：文本主模型、prefill/decode。
Vision executor：图像 encoder / adapter / patch 处理。

试下来以后，真正稳定的是：

main=gpu
vision=cpu

而不是：

main=gpu
vision=gpu

Vision GPU 路线的典型失败日志是：

Node number 905 (STABLEHLO_COMPOSITE) failed to prepare.
ERROR: Node number 905 (STABLEHLO_COMPOSITE) failed to prepare.
RunPrefillAsync status: INTERNAL:
  runtime/executor/vision_litert_compiled_model_executor.cc
  external/litert/litert/cc/litert_compiled_model.cc

后来在更高 token、patch 或 speculative decoding 配置下，还遇到 iOS 直接杀进程：

The process has been terminated by the operating system because it is using too much memory.
Domain: IDEDebugSessionErrorDomain
Code: 11
Failure Reason: Debug session ended with code 9: Terminated due to memory issue.

这个时候就能把问题分成两类：

问题	本质
`STABLEHLO_COMPOSITE failed to prepare`	图编译 / delegate prepare 阶段失败，还没真正开始识别
iOS memory issue / jetsam	模型、vision patch、KV cache、Metal resource 累积超过系统可承受范围

三、STABLEHLO_COMPOSITE prepare 失败到底是什么

STABLEHLO_COMPOSITE 不是普通业务报错，也不是 JSON 解析问题。

它大致发生在这条链路：

.litertlm 模型
  -> LiteRT-LM 拆出 vision encoder / adapter / main decoder
  -> LiteRT 创建 vision compiled model
  -> GPU delegate 尝试 prepare 某个 StableHLO composite 节点
  -> Metal backend 无法完成 lowering / kernel binding / tensor allocation
  -> engine 创建或 image prefill 失败

所以它的本质是：模型里的 Vision 子图和当前 iOS LiteRT GPU delegate 能力不匹配。

从 App 层能调的参数其实很有限：

降低输入图像尺寸。
降低 vision patch 数。
降低输出 token 数。
关闭 speculative decoding / MTP。
避免先尝试失败的 GPU Vision 路线，防止失败后内存资源更糟。

但如果某个 composite op 没有被当前 Metal delegate 支持，或者官方 Gallery 用了我们公开包里没有的 kernel / accelerator / 静态链接路径，那 App 层没有办法真正修复。

底层要修，大概只有三条路：

补 LiteRT Metal backend
- dump 出失败节点对应的 composite op。
- 在 LiteRT GPU delegate 里补 lowering 或 kernel。
- 重新构建 iOS runtime。
换成和 Gallery 一致的 runtime artifact
- Gallery 可能静态链接了 Metal accelerator。
- 也可能用了不同版本的 runtime、模型包、allowlist 或编译缓存。
重新转换模型
- 让 Vision 子图避开当前 public runtime 不支持的 composite。
- 这条最重，而且需要官方转换链路足够透明。

四、为什么试过 Gemma-3n，最后又放弃

中间尝试过一个方案 B：保留 Gemma 4 的现状，同时新增 Gemma-3n，看看它是不是更接近 iOS Gallery 的公开 allowlist。

这个方向很快也被证伪了。

Gemma-3n 的 Vision 子图明确要求 GPU：

INVALID_ARGUMENT: Vision backend constraint mismatch.
Model requires one of [gpu] but Vision backend is CPU

也就是说它不像 Gemma 4 那样可以走：

main=gpu
vision=cpu

对 Gemma-3n 来说，vision=cpu 不是慢一点，而是模型 metadata 直接拒绝。

可是切到：

main=gpu
vision=gpu

又会失败：

Node number 32 (STABLEHLO_COMPOSITE) failed to prepare.
Failed to create engine:
  runtime/executor/vision_litert_compiled_model_executor.cc
  external/litert/litert/cc/litert_compiled_model.h

这说明 Gemma-3n 在当前公开 iOS runtime 路径下没有有效 fallback：Vision CPU 不允许，Vision GPU 又 prepare 失败。

所以最后回滚这个分支是正确选择。工程上最怕“为了验证官方说法，把主线拖成一团泥”。Gemma-3n 这条路可以记为证据，但不应该进入产品实现。

五、最终保留的实现

最后保留下来的实现很克制：只支持 Gemma-4-E2B-it，且只让 Main executor 使用 GPU。

5.1 模型管理

当前模型目录只保留一个模型：

static let gemma4E2B = LocalAIModel(
    id: "gemma-4-E2B-it",
    displayName: "Gemma-4-E2B-it",
    fileName: "gemma-4-E2B-it.litertlm",
    downloadURL: URL(string: "https://huggingface.co/litert-community/gemma-4-E2B-it-litert-lm/resolve/main/gemma-4-E2B-it.litertlm")!,
    mirrorDownloadURLs: [
        URL(string: "https://hf-mirror.com/litert-community/gemma-4-E2B-it-litert-lm/resolve/main/gemma-4-E2B-it.litertlm")!
    ],
    expectedSizeBytes: 2_588_147_712
)

下载保留多源 fallback：

Hugging Face official repo
  -> hf-mirror

并保留基本完整性校验，避免下载到半截文件后直接进入运行时。

5.2 Runtime bridge

Swift 侧不依赖尚未稳定的 Swift SDK，而是走 C API bridge：

Swift
  -> LiteRTGemmaRuntime
  -> LiteRTLMRuntimeBridge
  -> dlopen / dlsym
  -> libLiteRtLm.dylib
  -> libLiteRt.dylib / Metal accelerator / TopK sampler

动态加载时会先加载 Gemma constraint provider：

libGemmaModelConstraintProvider.dylib
libLiteRtLm.dylib

其他 accelerator / sampler dylib 交给 LiteRT-LM 自己按名称加载，不在 Swift 侧手动乱 preload，避免 Objective-C duplicate class warning 和插件注册顺序问题。

5.3 Backend 策略

最终策略非常明确：

private func selectedBackendPlan() -> BackendPlan {
    let key = "settings.models.mainGPUAcceleration"
    let isMainGPUEnabled = UserDefaults.standard.object(forKey: key) as? Bool ?? true
    return BackendPlan(main: isMainGPUEnabled ? "gpu" : "cpu", vision: "cpu")
}

也就是：

设置	main	vision
Main GPU 开	GPU	CPU
Main GPU 关	CPU	CPU

不再尝试 Vision GPU。

5.4 内存控制

Vision LLM 入口先压图：

private static let maxVisionInputDimension: CGFloat = 640
private static let maxVisionPatches = 768
private static let maxVisionOutputTokens = 1536

生成时写临时 JPEG，quality 为 0.88。这样能控制 vision patch 数和输入 tensor 压力。

Engine settings 里也做了限制：

api.settingsSetMaxTokens(settings, isVision ? 3072 : 4096)
api.settingsSetMaxImages?(settings, isVision ? 1 : 0)
api.settingsSetSpeculativeDecoding?(settings, false)

speculative decoding / MTP 理论上能提速，但当天真机验证发现它会扩大内存压力。当前先关掉，等上游 runtime 更稳定后再单独测。

5.5 耗时日志

为了判断 GPU 到底有没有收益，最终实现里加了关键阶段耗时：

[LiteRT-LM][time] engine settings=...
[LiteRT-LM][time] engine create=...
[LiteRT-LM][time] text generateContent elapsed=...
[LiteRT-LM][time] vision temp image write elapsed=...
[LiteRT-LM][time] vision sendMessage elapsed=...
[LiteRT-LM][time] vision total elapsed=...

这个比“感觉快不快”可靠很多。尤其在移动端，首轮 engine 创建、模型 mmap、Metal shader 初始化、prefill、decode 是完全不同的性能阶段，混在一起看很容易误判。

六、返回 JSON 不完整的问题

有一次 CPU 路径返回了半截 JSON：

{
  "documentType": "invoice",
  "detectedCategory": "financial_transaction",
  "categoryConfidence": 0.95,
  "title": "Transaction Record",
  "language": "ko",
  "fields": [
    {
      "name": "Merchant",
      "value": "신용카드",
      "confidence": 0.90
    },
    {
      "name": "Buyer",
      "va

这不是“模型完全识别错了”，更像是输出被截断。常见原因有：

maxOutputTokens 太小。
prompt 要求 JSON 太长。
模型在低速 CPU 路径上被提前取消。
session / conversation API 返回内容没有完整拼接。

因此错误信息里保留 raw response prefix 是必要的。它能区分：

现象	判断
完全空	runtime / conversation 失败
半截 JSON	token 限制、截断或取消
非 JSON 文本	prompt / sampling / 模型服从性问题
字段错但 JSON 完整	识别质量问题

七、这次搜索到值得关注的官方 issue

后续如果继续跟 LiteRT-LM iOS / Gemma 4 GPU 路线，最值得关注这几个：

7.1 Gallery #692

google-ai-edge/gallery #692

这个 issue 和当前问题最贴近：Gemma 4 LiteRT-LM 在 iOS 第三方 App 里初始化失败，而且 public iOS allowlist 没列 Gemma 4。

它问的其实就是我们最关心的问题：

Gemma 4 .litertlm 在 iOS 第三方 App 里到底是不是官方支持？如果支持，公开 runtime/API 路径是什么？

7.2 LiteRT #6745

google-ai-edge/LiteRT #6745

这个 issue 提到 iOS arm64 libLiteRtMetalAccelerator.dylib 在 prebuilt 包里的问题，还指出 Gallery iOS 可能把 Metal accelerator 静态链接进了 binary。

这和我们的判断高度一致：Gallery 能跑，不代表公开 dylib 路线完整等价。

7.3 LiteRT-LM #2151

google-ai-edge/LiteRT-LM #2151

这个关注 iOS Mach-O bundling、companion dylibs、dlopen by basename 和 .framework 打包问题。只要官方后续修 public iOS dylib 路线，这类 issue 很可能会出现相关信号。

7.4 LiteRT-LM #2154

google-ai-edge/LiteRT-LM #2154

这个要求官方提供 public shared-library build target。当前 C API + dylib wrapper 路线，本质上也卡在这里。

7.5 LiteRT-LM #2187

google-ai-edge/LiteRT-LM #2187

这是 Gemma-4-E2B vision 部分性能慢的问题，不是 iOS，但可以观察官方怎么解释 vision pipeline 性能、backend 支持和调优方向。

八、工程上的判断

这一天最大的收获不是“GPU 能不能开”，而是几个边界判断。

8.1 不要把模型支持理解成 App 集成支持

官方说 Gemma 4 支持移动端，可能指的是：

Gallery App 支持。
Android Kotlin 路线支持。
特定 prebuilt / static linked runtime 支持。
特定设备和系统版本支持。

但我们真正需要的是：

第三方 iOS App
  + public LiteRT-LM C API
  + public iOS arm64 dylibs
  + App Store 可打包方式
  + Gemma-4-E2B-it.litertlm
  + Vision LLM

这是一条更窄、更具体的路线。只要其中一个组件不完整，就会出现“官方 demo 很快，我们这里很慢或跑不起来”的落差。

8.2 GPU 不一定整体更快

移动端 LLM 不是简单的“开 GPU = 快”。

GPU 可能加速 decode，但也可能增加：

engine 初始化成本
shader 编译成本
tensor upload 成本
Metal resource 压力
Vision encoder prepare 风险
内存峰值

所以必须分阶段打点：

image prepare
engine create
prefill
first token
decode
total

只看总耗时，很难判断到底哪一段在拖后腿。

8.3 fallback 要尊重模型 metadata

Gemma 4 可以 vision=cpu，Gemma-3n 不行。后者 metadata 明确要求 Vision backend 是 GPU。

因此 fallback 不是 App 想怎么 fallback 就怎么 fallback，而要看模型包里的 backend constraint。

8.4 先保主线，再保探索

Gemma-3n 双模型方案作为探索是有价值的，但不应该为了探索把主线复杂化。

最终回到：

Gemma 4 单模型
main GPU 可开关
vision 固定 CPU
Vision LLM 限制输入和输出
保留耗时日志
保留 OCR 默认兜底

这是当前最稳的工程点。

九、后续策略

短期不再继续硬怼 vision=gpu。继续做三件事：

保留 Gemma 4 当前实现
- 单模型。
- Main GPU 可开关。
- Vision CPU。
- 降低 patch / token / speculative decoding 内存风险。
关注官方 issue
- 特别是 Gallery #692 和 LiteRT #6745。
- 等官方明确 Gemma 4 iOS public runtime 支持路径。
如果要继续底层排查，先准备 upstream issue
- 设备型号、iOS、Xcode、LiteRT-LM tag。
- 模型 URL 和 size。
- backend 配置。
- 完整 STABLEHLO_COMPOSITE failed to prepare 日志。
- 说明 Gallery 能跑但 public dylib route 不等价。

在官方给出更清晰的 iOS runtime 之前，当前实现已经足够务实：能用、能测、能回退，也不会把 App 绑死在一个不稳定的 GPU Vision 假设上。

Transformer 架构：从零开始理解每一步

Wed, 08 Apr 2026 00:00:00 +0800

本文用一张架构图把 Transformer 的每一步拆开讲清楚，适合没有深度学习基础的读者。

一、全局视角：Transformer 在做什么

一句话：把一段输入序列变成一段输出序列。

翻译任务举例：输入「I love you」→ 输出「我爱你」。Transformer 通过 编码器（Encoder） 理解输入，再通过 解码器（Decoder） 逐步生成输出。

整个流程可以拆成四大块：

阶段	做什么	对应图中位置
输入处理	文本 → 数字向量	左侧绿色区域
编码器	理解输入的完整语义	上方红色框
解码器	逐个生成输出 token	下方粉色框
输出预测	向量 → 概率 → 选词	右下角黄/蓝色框

二、输入处理：让机器「读懂」文字

2.1 分词 / Token 化

机器不认识汉字和单词，需要先把文本切成最小单元——token。

"I love you" → ["I", "love", "you"]
"我爱你"     → ["我", "爱", "你"]

每个 token 对应词表里的一个编号（整数），比如 love → 3421。

2.2 词嵌入（Embedding）

一个整数编号信息量太少。词嵌入把每个编号映射成一个高维向量（比如 512 维的浮点数组），让语义相近的词在向量空间里距离更近。

"love" → [0.12, -0.34, 0.56, ...]   (512 个数)
"like" → [0.11, -0.31, 0.55, ...]   ← 和 love 很接近
"car"  → [-0.78, 0.22, 0.01, ...]   ← 和 love 差很远

这个映射表是模型训练出来的，不是人工设定的。

2.3 位置编码（Positional Encoding）

为什么需要？ Transformer 不像 RNN 那样逐个读入单词，它是一次性看到所有 token 的。这意味着它天生分不清「狗咬人」和「人咬狗」——词是一样的，只是顺序不同。

位置编码给每个位置生成一个独特的向量，和词嵌入相加，让模型知道谁在前、谁在后。

输入表示 = 词嵌入 + 位置编码

补充： 原始论文用 sin/cos 函数生成固定位置编码；后来的模型（如 RoPE）改用了更灵活的旋转位置编码。

处理完毕后，每个 token 变成了一个既包含语义、又包含位置的向量，这组向量就是编码器的输入。

三、编码器（Encoder）：理解输入

编码器堆叠 N 层（原始论文 N=6），每层结构完全相同，包含两个子模块：多头自注意力 和 前馈网络。

3.1 线性投影到 Q / K / V

进入注意力之前，先把每个 token 的向量用三个不同的线性变换，分别投影成三个新向量：

向量	全称	直觉含义
Q（Query，查询）	「我想找什么信息？」	当前 token 发出的搜索请求
K（Key，键）	「我能提供什么信息？」	每个 token 公开的标签
V（Value，值）	「我的实际内容是什么」	真正会被取走的信息

为什么要分成三个？如果 Q 和 K 直接用同一个向量，模型只能做「我和你像不像」的比较；分开后可以实现「我想找的」和「你能提供的」是不同维度的匹配，表达能力更强。

3.2 多头自注意力（Multi-Head Self-Attention）

核心公式：

\[\text{Attention}(Q, K, V) = \text{softmax}\!\left(\frac{QK^T}{\sqrt{d_k}}\right) V\]

拆解步骤：

打分： 用 Q 和所有 K 做点积 → 得到每对 token 之间的”相关度分数”
缩放： 除以 \(\sqrt{d_k}\)（向量维度的平方根），防止分数过大导致 softmax 梯度消失
归一化： softmax 把分数变成 0~1 之间的权重，所有权重加起来等于 1
加权求和： 用权重对 V 做加权求和 → 每个 token 得到了一个融合了其他 token 信息的新向量

自注意力的意义： 每个 token 可以”关注”输入中所有位置的其他 token。比如在「The cat sat on the mat because it was tired」中，自注意力让 “it” 知道自己指的是 “cat” 而不是 “mat”。

为什么是”多头”？ 把 Q/K/V 分成多组（比如 8 组），每组独立计算注意力，最后拼接。不同的”头”可以关注不同方面：

某个头关注语法结构（主谓宾）
某个头关注指代关系（it → cat）
某个头关注相邻词的搭配
某个头关注长距离依赖

3.3 残差连接 + 层归一化

输出 = LayerNorm(x + SubLayer(x))

残差连接（x + …）： 把子层的输入直接加到输出上。好处是让梯度能”走捷径”传回去，避免深层网络训练困难。
层归一化（LayerNorm）： 把每个向量的数值范围拉回稳定区间，加速训练收敛。

每个子模块（注意力、FFN）之后都有这一对操作，图中共出现 2 次。

3.4 前馈网络（FFN）

FFN(x) = W₂ · GELU(W₁ · x + b₁) + b₂

两个线性层夹一个激活函数（GELU）。可以理解为：注意力负责”在 token 之间交换信息”，FFN 负责”对每个 token 自己的信息做深加工”。

通常 FFN 的中间维度是输入的 4 倍（比如 512 → 2048 → 512），让模型有更大的”思考空间”。

3.5 编码器输出

经过 N 层堆叠后，输出的向量组称为上下文化表示（Context）。每个 token 的向量现在不再只代表自己，而是融合了整段输入的完整语义。这组向量会被送到解码器使用。

四、解码器（Decoder）：逐步生成输出

解码器同样堆叠 N 层，但比编码器多一个子模块（交叉注意力），共三个子模块。

4.1 右移的目标序列

解码器的输入是已经生成的部分结果（推理时）或右移的正确答案（训练时）。

正确答案：  "我"  "爱"  "你"  "<EOS>"
右移后：  "<BOS>"  "我"  "爱"  "你"

这样，每个位置的任务就是根据左边已有的内容，预测下一个 token。

4.2 Masked 多头自注意力

和编码器的自注意力几乎一样，区别在于加了遮罩（Mask）：每个 token 只能看到自己和左边的 token，看不到右边（未来的 token）。

为什么要遮罩？因为生成是从左到右的，生成第 3 个词时，第 4 个词还不存在。训练时虽然能看到完整答案，但必须用 mask 模拟这种”看不到未来”的真实推理场景，否则模型会”作弊”。

4.3 交叉注意力（Cross-Attention）

这是解码器独有的模块：

Q 来自解码器（当前正在生成的 token）
K 和 V 来自编码器输出（输入句子的完整语义）

作用：让解码器在生成每个词时，能够”回头看”输入句子。比如翻译「I love you」时，生成「爱」这个字需要关注输入中的「love」。

4.4 FFN + 残差连接 + 层归一化

和编码器完全一样，不再赘述。每个子模块之后都有残差连接和层归一化。

4.5 解码器层的堆叠

解码器同样堆叠 N 层，上一层的输出作为下一层的输入，逐层精炼。

五、输出预测：从向量到文字

解码器最后一层的输出是一组向量，还需要转回文字：

线性层： 把向量映射到词表大小的维度（比如 50000 维，对应词表中每个词一个分数）
Softmax： 把分数转成概率分布（所有词的概率之和 = 1）
选词： 取概率最高的那个 token 作为输出（贪心策略），或用 beam search / 采样等策略

然后把这个新 token 拼到解码器输入的末尾，重复整个解码过程，直到生成 <EOS>（结束符）。

六、训练 vs 推理的区别

	训练	推理
编码器	运行一次	运行一次
解码器输入	右移后的完整正确答案（Teacher Forcing）	已生成的部分序列，逐步增长
解码器运行	一次并行处理所有位置（靠 mask 防作弊）	一步步循环，每步多生成一个 token
目标	缩小预测和正确答案的差距，更新参数	用训练好的参数直接生成

Teacher Forcing（教师强制）： 训练时不等模型自己生成上一个词再喂下一个，而是直接把正确答案喂给解码器。这样训练更稳定、收敛更快。

七、主要变体

原始 Transformer 是 Encoder-Decoder 结构，后来衍生出三大家族：

变体	结构	代表模型	擅长
仅编码器	只用 Encoder	BERT	理解型任务（分类、抽取、问答）
仅解码器	只用 Decoder	GPT、LLaMA、Qwen	生成型任务（对话、写作、代码）
编码器-解码器	完整结构	T5、原始 Transformer	序列到序列（翻译、摘要）

现在最流行的大语言模型（ChatGPT、Claude、Qwen 等）大多是仅解码器架构——去掉了编码器和交叉注意力，只保留带 mask 的自注意力和 FFN，靠超大规模数据和参数量实现强大的生成能力。

八、总结：一张图的完整信息流

输入文本
  ↓ 分词 / Token 化
  ↓ 词嵌入 + 位置编码
  ↓
┌─────────── 编码器 × N 层 ──────────┐
│  线性投影 → Q / K / V              │
│  多头自注意力（看所有位置）          │
│  残差连接 + 层归一化                │
│  前馈网络（FFN）                    │
│  残差连接 + 层归一化                │
└───────────────────────────────────┘
  ↓ 上下文化表示（Context）
  ↓ K, V 传入解码器的交叉注意力
┌─────────── 解码器 × N 层 ──────────┐
│  Masked 多头自注意力（只看左边）     │
│  残差连接 + 层归一化                │
│  交叉注意力（Q 来自解码器，KV 来自编码器）│
│  残差连接 + 层归一化                │
│  前馈网络（FFN）                    │
│  残差连接 + 层归一化                │
└───────────────────────────────────┘
  ↓
  线性层 → Softmax → 预测下一个 token

参考

Vaswani et al., Attention Is All You Need, 2017
Jay Alammar, The Illustrated Transformer

一起来学习 tauri

Tue, 22 Oct 2024 00:00:00 +0800

安装

1. Mac 安装 rust:

执行：

curl --proto '=https' --tlsv1.2 https://sh.rustup.rs -sSf | sh

安装路径：

RUSTUP_HOME: ~/.rustup
CARGO_HOME: ~/.cargo
The cargo, rustc, rustup and other commands: ~/.cargo/bin
This path will then be added to your PATH environment variable by
modifying the profile files located at:
  ~/.profile
  ~/.bash_profile
  ~/.zshenv

结果：

Rust is installed now. Great!

To get started you may need to restart your current shell.
This would reload your PATH environment variable to include
Cargo's bin directory ($HOME/.cargo/bin).

To configure your current shell, you need to source
the corresponding env file under $HOME/.cargo.

This is usually done by running one of the following (note the leading DOT):
. "$HOME/.cargo/env"            # For sh/bash/zsh/ash/dash/pdksh
source "$HOME/.cargo/env.fish"  # For fish

卸载：

rustup self uninstall

浏览器

Tue, 05 Dec 2023 00:00:00 +0800

chromium

V8

代理

Tue, 05 Dec 2023 00:00:00 +0800

不错的网站

q1cloud

Mermaid

Tue, 05 Dec 2023 00:00:00 +0800

网址

vulkan

Mon, 18 Sep 2023 00:00:00 +0800

Doc

vulkan sdk

编译相关

Sun, 27 Aug 2023 00:00:00 +0800

文件查看

objdump 关键命令

反汇编

objdump -d xxx.o

显示头文件信息

objdump -f xxx.o

查看文件有哪些符号，包括数据段、导出的函数、引用其他库的函数

objdump -tT xxx.so
objdump -x xxx.so

查看依赖

objdump -x xxx.so | grep "NEEDED"

lipo

lipo源于mac系统要制作兼容powerpc平台和intel平台的程序，lipo 是一个在 Mac OS X 中处理通用程序（Universal Binaries）的工具，主要用于查看，修改Mac OS X 中的通用程序。

（a）查看frameWork支持架构 lipo -info xxx.framework/xxx 输出结果：Architectures in the fat file: xxx.framework/xxx are: i386 x86_64 armv7 arm64

（b）合并framework lipo -create xxx(i386).framework/xxx xxx(armv7).framework/xxx -output xxx.framework.xxx 说明：通过编译产生的动态库/静态库，均为单一架构支持（模拟器/真机），其中i386和x86_64均为模拟器架构，armv7和arm64为真机架构，通过合并产生的framework才是全架构支持

（c）拆分framework lipo xxx.framework/xxx -thin i386 xxx.i386 说明：次操作将单独分离出仅支持i386的动态库/静态库文件， x86_64 armv7 arm64可同理分离，可以配合合并操作去除不需要的架构支持，用于动态库/静态库瘦身。

简述ar操作

ar是linux提供的维护链接编辑器使用的索引库

要创建一个库，请输入： ar -v -q lib.a strlen.o strcpy.o 如果 lib.a 库不存在，则此命令创建它，并将文件 strlen.o 和 strcpy.o 的副本输入其中。如果 lib.a 库存在，则此命令在不检查相同成员的情况下，将新的成员添加到末尾。v 标志设置详细方式，在此方式中 ar 命令在其进行时显示进程报告。
要显示库的目录，请输入： ar -v -t lib.a 此命令列出了 lib.a 库的目录，显示类似于 ls -l 命令的输出的长列表。要只列出成员文件名称，则省略 -v 标志。
要替换或添加新成员到库中，请输入： ar -v -r lib.a strlen.o strcat.o 此命令替换成员 strlen.o 和 strcat.o。如果 lib.a 如示例 1 中显示的那样创建，则替换 strlen.o 成员。因为不存在名为 strcat.o 的成员，所以它被添加到库的末尾。
要指定在何处插入新成员，请输入： ar -v -r -b strlen.o lib.a strcmp.o 此命令添加 strcmp.o 文件，并将该新成员置于 strlen.o 成员之前。
要更新一个已经更改过的成员，请输入： ar -v -r -u lib.a strcpy.o 此命令替换现有 strcpy.o 成员，但仅当文件 strcpy.o 自从最后一次添加到库后已经修改时才替换它。
要更改库成员的顺序，请输入： ar -v -m -a strcmp.o lib.a strcat.o strcpy.o 此命令将成员 strcat.o 和 strcpy.o 移动到紧跟在 strcmp.o 成员之后的位置。保留 strcat.o 和 strcpy.o 成员的相对顺序。换句话说，如果在移动之前 strcpy.o 成员在 strcat.o 成员之前，那么（移动后）它依旧如此。
要解压缩库成员，请输入： ar -v -x lib.a strcat.o strcpy.o 此命令将成员 strcat.o 和 strcpy.o 分别复制到名为 strcat.o 和 strcpy.o 的文件。
要解压缩并重命名一个成员，请输入： ar -p lib.a strcpy.o >stringcopy.o 此命令将成员 strcpy.o 复制到一个名为 stringcopy.o 的文件。
要删除一个成员，请输入： ar -v -d lib.a strlen.o 此命令从 lib.a 库中删除成员 strlen.o。
要从多个用 ld 命令创建的共享模块中创建一个压缩文档库，请输入： ar -r -v libshr.a shrsub.o shrsub2.o shrsub3.o … 此命令从名为 shrsub.o、shrsub2.o、shrsub3.o 等等的共享模块中创建名为 libshr.a 的压缩文档库。要编译并链接使用 libshr.a 压缩文档库的 main 程序，请使用以下命令：

cc -o main main.c -L/u/sharedlib -lshr main 程序现在是可执行的。main 程序引用的任何符号（包含在libshr.a 压缩文档库中）已经因延迟分辨率而作了标记。-l 标志指定应在 libshr.a 库中搜索这些符号。
要列出 lib.a 的内容（忽略任何 32 位目标文件），请输入： ar -X64 -t -v lib.a
要从 lib.a 解压缩所有 32 位的目标文件，请输入： ar -X32 -x lib.a
要列出 lib.a 中的所有文件，无论是 32 位、64 位或非对象，请输入： ar -X32_64 -t -v lib.a
简述nm操作

nm 命令被用于显示二进制目标文件的符号表

语法 nm(选项)(参数) 举例： nm View.o>View.m nm -A View.o 说明：选项：[-A：每个符号前显示文件名；-D：显示动态符号；-g：仅显示外部符号；-r：反序显示符号表。] 参数：目标文件，二进制目标文件，通常是库文件和可执行文件

opengl

Tue, 15 Aug 2023 00:00:00 +0800

Doc

Getting Started Window_Toolkits

GLFW

OpenGL examples

MACOS

Thu, 25 May 2023 00:00:00 +0800

打不开软件

sudo spctl  --master-disable

sudo xattr -r -d com.apple.quarantine /Applications/ILSpy.app

如何清理 macOS 图标缓存

sudo find /private/var/folders/ \( -name com.apple.dock.iconcache -or -name com.apple.iconservices \) -exec rm -rfv {} \;
sudo rm -rf /Library/Caches/com.apple.iconservices.store;
killall Dock
killall Finder

date 命令

Mac下的date命令是BSD（Berkeley Software Distribution）系的，Linux下date命令是GNU（GNU’s Not Unix）系，二者用法有一些区别。

BSD并不特指任何一个BSD衍生版本，而是类UNIX操作系统中的一个分支的总称。

Mac OS X和iOS实际上基于Darwin，Darwin是BSD其中一个分支

共同点

基本的时间格式的缩写是相同的，规则如下：

%Y:四位数形式的年份，如2018 %y:两位数形式的年份，如18 %m:表示前导0的月份，如01，12 %d:表示前导0的日期，如02，28 %h:三位的英文月份 %H:表示前导0的24小时(0~23) %M:表示前导为0的分钟数(0~60) %S:表示前导为0的描述秒数(0~60) %s:表示距离格林尼治时间（1970年1月1日0点）的秒数

不同点

获取前一天和获取后一天的写法不同：

Mac，通过-v参数，-v-1d代表前一天，-v-1y代表上一年 Linux，通过–date参数实现，–date=’-1 day’代表前一天，–date=’-1 year’代表上一年

mac date命令用法详解

usage: date [-jnRu] [-d dst] [-r seconds] [-t west] [-v[+|-]val[ymwdHMS]] ...
            [-f fmt date | [[[mm]dd]HH]MM[[cc]yy][.ss]] [+format]

参数解析：

-j:使用-j才能使用-f

-n:默认情况下，如果定时进程正在运行，date命令会在本地组的所有机器设置时间。-n可以禁止这种行为，表示只设置当前计算机。

-u:显示或者设置日期为UTC（世界协调时钟）时间

-d:设置内核的时区，一般不使用

-r:秒转换时间

-t:(time zone)时区设置（GMT时区）

-v:根据参数调整时间

不使用+|-，更改对应的时间
使用+：增加对应的时间
使用-：减少对应的时间
-f:根据格式调整时间

+:+号引导的一些格式，和正常的Linux格式一致。

使用示例：

（1）查看当前时间戳（即转换成秒）：

➜  ~ date +%s
1545705798

（2）当前时间转换指定格式

➜  ~ date +%Y-%m-%d-%H:%M:%S
2018-12-25-10:46:04

(3)时间戳转时间

➜  ~ date -r 1545705922
Tue Dec 25 10:45:22 CST 2018

Flyingon的博客

LiteRT-LM 在 iOS 上跑 Gemma 4：一次从 GPU 到回滚的工程复盘

一、背景：为什么选 LiteRT-LM 和 Gemma 4

二、最初现象：GPU 不像想象中那么简单

三、STABLEHLO_COMPOSITE prepare 失败到底是什么

四、为什么试过 Gemma-3n，最后又放弃

五、最终保留的实现

5.1 模型管理

5.2 Runtime bridge

5.3 Backend 策略

5.4 内存控制

5.5 耗时日志

六、返回 JSON 不完整的问题

七、这次搜索到值得关注的官方 issue

7.1 Gallery #692

7.2 LiteRT #6745

7.3 LiteRT-LM #2151

7.4 LiteRT-LM #2154

7.5 LiteRT-LM #2187

八、工程上的判断

8.1 不要把模型支持理解成 App 集成支持

8.2 GPU 不一定整体更快

8.3 fallback 要尊重模型 metadata

8.4 先保主线，再保探索

九、后续策略

Transformer 架构：从零开始理解每一步

一、全局视角：Transformer 在做什么

二、输入处理：让机器「读懂」文字

2.1 分词 / Token 化

2.2 词嵌入（Embedding）

2.3 位置编码（Positional Encoding）

三、编码器（Encoder）：理解输入

3.1 线性投影到 Q / K / V

3.2 多头自注意力（Multi-Head Self-Attention）

3.3 残差连接 + 层归一化

3.4 前馈网络（FFN）

3.5 编码器输出

四、解码器（Decoder）：逐步生成输出

4.1 右移的目标序列

4.2 Masked 多头自注意力

4.3 交叉注意力（Cross-Attention）

4.4 FFN + 残差连接 + 层归一化

4.5 解码器层的堆叠

五、输出预测：从向量到文字

六、训练 vs 推理的区别

七、主要变体

八、总结：一张图的完整信息流

参考

一起来学习 tauri

安装

1. Mac 安装 rust:

浏览器

chromium

V8

代理

不错的网站

Mermaid

网址

vulkan

Doc

编译相关

文件查看

objdump 关键命令

lipo

简述ar操作

简述nm操作

opengl

Doc

MACOS

打不开软件

如何清理 macOS 图标缓存

date 命令

共同点

不同点

mac date命令用法详解

参数解析：

使用示例：