TextLLMRunner degenerates on an LFM2.5 export that steps correctly token by token
メンテナーはふだん 1 日以内に返信
@JakeStevens がすでに取り組んでいます。
2026年8月15日 から。
評価
この issue はまだ評価されていません。
説明
TextLLMRunner produces degenerate output for an LFM2.5 export that generates correctly when the same .pte is stepped token by token. Reproduces on macOS with the pip wheel and on Android through LlmModule, and does not depend on the export configuration.
Environment: executorch 1.4.0 (pip), torch 2.13.0, macOS arm64; also reproduced on a Pixel 8a with an AAR built from main.
What happens
Same .pte, same prompt, same machine, two ways of driving it:
token-by-token, explicit input_pos "Here are three colors:\n\n1. **Red**\n2. **Green**"
TextLLMRunner "s::::<|im_end|>"
Shorter prompts make the shape clearer — the runner repeats one token:
prompt "Hi" -> "HiHiHiHiHiHiHiHiHiHiHiHiHiHiHiHi"
prompt "Name three colours." -> "<|im_end|><|im_end|>"
Repro
from executorch.extension.llm.custom_ops import custom_ops # noqa
from executorch.kernels import quantized # noqa
from executorch.extension.llm.runner import TextLLMRunner, GenerationConfig
r = TextLLMRunner("lfm2_5_350m_xnnpack_8da4w.pte", "tokenizer.json")
out = []
r.generate("Hi", GenerationConfig(max_new_tokens=16, echo=False), lambda t: out.append(t))
print("".join(out)) # HiHiHiHiHiHiHiHiHiHiHiHiHiHiHiHi
The same file through a loop that steps one token at a time answers normally:
import torch
from executorch.extension.pybindings.portable_lib import _load_for_executorch
model = _load_for_executorch("lfm2_5_350m_xnnpack_8da4w.pte")
for i, tok in enumerate(prompt_tokens):
logits = model.forward((torch.tensor([[tok]]), torch.tensor([i])))[0]
# then greedy-decode from logits, advancing input_pos each step
The .pte is public: https://huggingface.co/mlboydaisuke/LFM2.5-350M-ExecuTorch — exported with
executorch.extension.llm.export.export_llm, qmode: 8da4w, embedding_quantize: "8,0",
XNNPACK.
What it is not
I re-exported the model to remove each candidate in turn and drove every build both ways:
| build | forward input |
enable_dynamic_shape |
token-by-token | TextLLMRunner |
|---|---|---|---|---|
shipped (use_sdpa_with_kv_cache: True) |
[1, 2047] |
True | correct | degenerate |
control (use_sdpa_with_kv_cache: False, enable_dynamic_shape: False) |
[1, 1] |
False | correct | degenerate |
So it is not the custom SDPA path, and not dynamic versus static shape — a static [1, 1] export,
which the runner should drive sequentially, fails the same way.
It is not the tokenizer either: the same tokenizer.json encodes the prompt to the expected ids
through a standalone HFTokenizer harness on the same machine, special tokens included, and the
.pte reports get_bos_id = 1, get_eos_ids = [7], matching the tokenizer.
And it is not the runner in general — Qwen3.5-0.8B exported the same way (8da4w,
embedding_quantize: "8,0", XNNPACK) generates correctly through TextLLMRunner on the same
build, so whatever this is interacts with something specific to LFM2.5.
A guess I could not confirm
LFM2.5 is a hybrid: short-convolution blocks interleaved with attention. Convolution blocks carry
state along the sequence, so anything that drives positions differently from a plain
one-token-at-a-time walk — a warmup pass, a re-prefill, a batched first step — would corrupt that
state while leaving a pure-attention model like Qwen unharmed. I could not confirm which of those
the runner does, so I am reporting the isolation rather than a diagnosis.
Happy to run further experiments against this model, or to test a patch.
This report was written with Claude.
cc @larryliu0820 @mergennachin @cccclai @helunwencser @jackzhxng @digantdesai
- 主要言語
- Python
- スター
- 5k
- フォーク
- 1.2k
- 平均マージ
- 2日 5時間
- マージ済み PR(30日)
- 491
環境構築
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
pytorch/executorch のほかの issue
-
enhancement triaged
難易度 2/5 半日 初心者へのやさしさ 68/100
pytorch/executorch#21640 ·
メンテナーはふだん 1 日以内に返信
-
[RFC] ExecuTorch Persisting Device Specialized Delegate Artifacts対応中かも @JacobSzwejbka が今日担当しました。 オープン
pytorch/executorch#23192 · コメント 1 件 · リアクション 1 件 · 担当者 1 名 ·
メンテナーはふだん 1 日以内に返信
-
[QNN] Enable ConvTranspose + BatchNorm fusion after #23170対応中かも @psiddh が今日担当しました。 オープンmodule: qnn partner: qualcomm
pytorch/executorch#23185 · 担当者 1 名 ·
メンテナーはふだん 1 日以内に返信
-
enhancement module: examples
難易度 5/5 1週間以上 初心者へのやさしさ 20/100
pytorch/executorch#23164 · コメント 7 件 · リアクション 2 件 ·
メンテナーはふだん 1 日以内に返信
-
Qualcomm: 8-bit per-channel weight scales are floored at the 16-bit eps, and the HTP miscomputes near-zero channels対応中かも @psiddh が 3 日前に担当しました。 オープンmodule: qnn module: quantization partner: qualcomm
pytorch/executorch#23160 · コメント 1 件 · 担当者 1 名 ·
メンテナーはふだん 1 日以内に返信
pytorch/executorch の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 86/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜2日 初心者へのやさしさ 70/100
-
FingerprintSplitter raises ZeroDivisionError when int(frac_train * len(dataset)) floors to zeroオープン
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
メンテナーはふだん 7 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
lmstudio-ai/mlx-engine#376 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
pyiron/bagofholding#166 ·