Gemma 4 VL (Vulkan, v0.11.0 export) is killed by lmkd during load on an 8 GB phone; the v0.9.0 export loads there through the legacy runner

オープン
  • 何か問題がありますか？
#1,613 コメント 0 件 リアクション 0 件 担当者 1 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

@barhanc がすでに取り組んでいます。

2026年11月5日 から。

評価

この issue はまだ評価されていません。

説明

model

Description

On a Samsung Galaxy S24 (8 GB), loading Gemma 4 VL E2B through the new multimodal LLM API gets the app killed by the Android low-memory killer before generation starts. The app is in the foreground (oom_score_adj 0). On the same phone, our previous release loads the v0.9.0 Vulkan export of the same model through react-native-executorch/legacy and answers normally.

The XNNPACK v0.11.0 export of the same model loads fine on the new API on this phone, using about 2.7 GB PSS with a 7.8 s load. The problem looks specific to the Vulkan path.

Environment

  • react-native-executorch 0.11.0 in both builds.
  • Device: Samsung Galaxy S24, SM-S921B (Exynos 2400, Xclipse 940 GPU), 8 GB RAM (MemTotal 7.05 GiB), Android API 37.
  • Context window: 2048 in both builds. That is the export's max_context_len; the app does not raise it.
Works Killed
API react-native-executorch/legacy LLM new multimodal LLM API
Model file [email protected]/e2b/vulkan/gemma_4_e2b_vulkan_8da4w.pte (4.37 GB) [email protected]/e2b/vulkan/gemma_4_e2b_vulkan_8da4w.pte (3.81 GB)
Result Loads and answers. Memory after load: GL mtrack 3.07 GiB, TOTAL PSS 4.8 GiB (of which 1.7 GiB swapped), MemAvailable 0.65 GiB lmkd reclaims the app about 15 s after the first message, during load

Steps to reproduce

  1. On an 8 GB Android phone (we used the S24 above), download gemma-4-E2B-it-ExecuTorch v0.11.0 e2b/vulkan/gemma_4_e2b_vulkan_8da4w.pte with its tokenizer.
  2. Load it with the multimodal LLM API from 0.11.0 and send a short text prompt (we sent "And of Germany?" in an existing chat).
  3. The process is killed during load. No JS or native error is logged before the kill.

Log

13:01:46.126 I/PMTEST: gemma-vl-new-build-start
13:01:57.149 I/GSC (23633): SID[119] ...            <- Vulkan shader compilation in the app process
13:02:01.396 D/io_stats: Read_top(KB): privatemind.ver(23633) 1217384
13:02:01.472 I/lmkd (602): Reclaim 'com.swmansion.privatemind.ver' (23633), uid 10481, oom_score_adj 0, state 2(8)
             to free 308kB rss, 0kB anon rss, 248220kB swap, 13525kB dmabuf_pss, 40576kB dmabuf_rss;
             reason: min2x watermark is breached even after kill; level: 3

Before reclaiming the app, lmkd killed dozens of background processes in the preceding seconds, so memory runs out during load, not during generation.

What we did not isolate

Two things changed between the working and the failing run: the runner (legacy vs. new multimodal API) and the export (v0.9.0 vs. v0.11.0). We have not yet run the v0.9.0 file through the new API, or the v0.11.0 file through the legacy runner, in a clean app. Two questions:

  • Does the Vulkan path in the new runner hold more at load, for example keeping the mmapped weights and a GPU copy at the same time?
  • Is there a load option that lowers the peak?

The XNNPACK export works as a workaround, running on the CPU instead of the GPU.

主要言語
TypeScript
スター
1.8k
フォーク
101
平均マージ
2日 4時間
マージ済み PR（30日）
58

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

software-mansion/react-native-executorch のほかの issue

software-mansion/react-native-executorch の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。