Gemma4 Japanese ASR output has excessive spaces; Q4NX audio artifacts may be based on older upstream revision

Bug Description

When using gemma4-it:e2b / gemma4-it:e4b through FastFlowLM on a Ryzen AI HX 370 system, Japanese audio transcription works, but the generated Japanese transcript contains excessive spaces between characters/segments, like unnatural word segmentation.

Image input works, and audio files are accepted successfully. The issue appears specific to Japanese ASR/transcription output formatting from Gemma4.

This resembles an early Gemma4 audio/transcription behavior, so I checked whether the FastFlowLM Gemma4 model artifacts may be based on an older upstream Gemma4 revision.

Steps to Reproduce

1. Install and run FastFlowLM on Windows with an AMD Ryzen AI XDNA2 NPU.
2. Run either:

flm run gemma4-it:e2b

or:

flm run gemma4-it:e4b

3. Attach a Japanese audio file in CLI mode:

/input "C:\path\to\japanese-audio.wav"
この音声を日本語で文字起こしして

4. Observe that the transcription is produced, but Japanese text contains many unnatural spaces / segmented output.

Expected Behavior

Japanese ASR/transcription should output normal Japanese text without excessive spaces or unnatural character/word segmentation.

Actual Behavior

Japanese audio is loaded and transcribed, but the output contains excessive spaces / unnatural segmentation in Japanese text.

Environment

• OS: Windows 11
• CPU: AMD Ryzen AI 9 HX 370 w/ Radeon 890M
• NPU: NPU Compute Accelerator Device, XDNA2, visible as active in Task Manager
• NPU driver observed: AMD 32.0.20102.3930
• RAM: 96 GB
• Models tested:
  • gemma4-it:e2b
  • gemma4-it:e4b
• Local FastFlowLM model cache path:
  • C:\Users\shuhe\.flm\models\Gemma4-E2B-IT-NPU2
  • C:\Users\shuhe\.flm\models\Gemma4-E4B-IT-NPU2

Related Investigation

FastFlowLM model list currently points Gemma4 to FastFlowLM-hosted Q4NX artifacts:

"gemma4-it": {
  "e2b": {
    "name": "Gemma4-E2B-IT-NPU2",
    "url": "https://huggingface.co/FastFlowLM/Gemma4-E2B-IT-NPU2/resolve/test_new_template",
    "file_url": "https://huggingface.co/api/models/FastFlowLM/Gemma4-E2B-IT-NPU2/tree/test_new_template",
    "flm_min_version": "0.9.43"
  },
  "e4b": {
    "name": "Gemma4-E4B-IT-NPU2",
    "url": "https://huggingface.co/FastFlowLM/Gemma4-E4B-IT-NPU2/resolve/test_new_template",
    "file_url": "https://huggingface.co/api/models/FastFlowLM/Gemma4-E4B-IT-NPU2/tree/test_new_template",
    "flm_min_version": "0.9.43"
  }
}

Hugging Face metadata observed:

• FastFlowLM/Gemma4-E2B-IT-NPU2: last modified 2026-04-15
• FastFlowLM/Gemma4-E4B-IT-NPU2: last modified 2026-04-28
• google/gemma-4-E2B-it: last modified 2026-06-03
• google/gemma-4-E4B-it: last modified 2026-06-03

For the FastFlowLM repos, model.q4nx and audio_weight.q4nx appear identical between main and test_new_template; test_new_template mainly updates files such as chat_template.jinja / config. This suggests the NPU Q4NX weights/audio weights may not include upstream Gemma4 fixes from the newer June Google release.

Request

Could you check whether the Gemma4 Q4NX/audio artifacts used by FastFlowLM are based on an older upstream Gemma4 revision?

If so, would it be possible to rebuild/update:

• FastFlowLM/Gemma4-E2B-IT-NPU2
• FastFlowLM/Gemma4-E4B-IT-NPU2

from the latest upstream google/gemma-4-E2B-it / google/gemma-4-E4B-it models, especially for Japanese audio transcription behavior?

Thanks for the great work on Ryzen AI NPU support. Gemma4 image/audio loading is working on HX 370, so this would make the local multimodal experience much more usable for Japanese ASR workflows.

Start by comparing the FastFlowLM model-list entries and the FastFlowLM/Gemma4-E2B-IT-NPU2 and Gemma4-E4B-IT-NPU2 Q4NX and audio artifacts with the corresponding June google/gemma-4 models. Reproduce Japanese transcription with both CLI models and determine whether the artifacts use an older upstream revision; done means the cause is confirmed and updated artifacts, if needed, are tested for normal Japanese spacing.