xiaonan.dev / open-source / llama-cpp

llama.cpp への貢献

画像・音声の入力をモデルが扱える chunk に変換するマルチモーダル層を持つ、クロスプラットフォームの C/C++ 推論プロジェクトです。

Issue と Pull Request は公開された根拠です。状態は時点スナップショットであり、リリース済みという意味ではありません。

貢献記録を見る

このリポジトリの貢献記録

01 / 01
下の記録から一件を選びます。同じリポジトリの貢献が増えると横方向に拡張され、読む領域は常に一件の case study に集中します。

tools/mtmd · libmtmd audio tokenization

貢献上の役割調査への参加者(主担当ではない・実装は未提出)

one-sample 音声を回復可能に扱う境界の調査

libmtmd の音声境界に対する暫定かつ非主要の調査です。構造上は正しい one-sample PCM bitmap がプロセスレベルの assertion に到達し、異常な request を server の可用性障害にしてしまいます。

上流での進捗DRAFT / PROVISIONAL。Issue は Open で PR はまだありません。静的な根因証拠と候補境界は記録していますが、これは非主要の調査です。runtime reproduction、実装、test、review、採用はすべて open のままです。
Issue
#27693
Pull Request
未作成
対象モジュール
tools/mtmd · libmtmd audio tokenization

システムの背景

llama.cpp はモデル loading、ローカル/server 推論、CPU/GPU backend、マルチモーダル入力を含むクロスプラットフォームの C/C++ 推論プロジェクトです。問題は backend kernel や text generation loop ではなく、media をモデルへ渡す前に準備する libmtmd にあります。

音声パスでは llama-server が OpenAI-compatible な input_audio ファイルを受け、mtmd_helper が miniaudio で WAV/MP3/FLAC を mono F32 PCM に decode し、libmtmd が audio bitmap を作成します。次に mtmd_tokenize が model-specific preprocessor を選び、media を multimodal chunks と audio tokens に変換します。

音声入力は experimental のままで、共有 tokenizer は複数の preprocessor を選べます。あるモデルが超短い signal を padding できるからといって、共有境界が全ての音声モデルの受理域を黙って広げてはいけません。

発生条件と影響

Issue report は Voxtral パスで、decode 後にちょうど一つの sample だけを持つ 16 kHz mono WAV を示しています。mono F32 の一 sample は正しい四 byte buffer です。nx == 1、buf.size() == sizeof(float) であり、buffer の alignment も正しいままです。

現在の tokenizer は nx == 0 を回復可能な empty-input error として扱いますが、その後で buf.size() > sizeof(float) を要求します。一 sample では 4 > 4 が false となるため、GGML_ASSERT は request error ではなく ggml_abort に到達します。

CLI が終了し server が一 request 後に /health を失うという結果は上流の報告であり、私のローカル再現ではありません。現在の参加範囲は静的パスと残る acceptance gate の確認で、Windows での再現や修正済みを主張するものではありません。

根本原因

下位の bitmap は壊れていません。byte size は nx * sizeof(float) なので、one-sample object は表現と alignment の不変条件を満たします。問題は user-controlled な最小長の問いを、プロセス全体を終わらせる内部 memory assertion として書いていることです。

> を単に >= に変えればこの assertion は避けられますが、one-sample signal が全ての model-specific preprocessor に入ります。Whisper-style path は padding するかもしれませんが、Conformer、Parakeet、Granite Speech、Qwen3 TTS などは frame、normalisation、最小長の意味が異なります。静的証拠だけで全体を受理してはいけません。

error boundary は /input_tokens が使う placeholder bitmap も考慮する必要があります。real buffer だけに基づく修正では、同じ sample count で token-count と通常 completion の挙動が食い違う可能性があります。

修正と境界

現在は source change をしていません。暫定方針は、real-buffer と placeholder が分かれる前の共有 audio-tokenization 境界で、既存の LOG_ERR + return-error 契約を使って nx < 2 を拒否することです。異常入力を abort まで到達させず、回復可能な request failure にします。

既存の alignment assertion は内部不変条件として残します。通常の nx >= 2 audio は同じ preprocessor path に入り続け、この案は全音声モデルに one-sample の数値的振る舞いを定義することも避けます。

これは設計候補であり、実装完了の主張ではありません。コードの前に baseline reproduction、zero-sample error wording の選択、real-buffer と placeholder の確認、修正前に失敗し修正後に通る regression test が必要です。

この境界を選んだ理由

この記録は意図的に非主要貢献としています。主要な contribution candidate は Issue #27697 に移り、#27693 は調査と計画への参加を記録するもので、bug や将来の patch を主導したとは主張しません。

共有境界が意味の異なる複数の preprocessor に使われるため、提案を一文字の >= 変更にはしていません。安全な scope は異常な外部 request を回復可能にすることであり、全モデルに未検証の最小音声 policy を主張することではありません。

ページでは report、静的 source evidence、open の runtime gate を区別します。この段階で implementation、local commit、PR、CI result、maintainer review、merge を主張できるものはありません。

検証結果

  1. 01

    2026-08-27 11:40 AEST 時点で、上流 Issue は Open、bug-unconfirmed ラベルで、関連する Development branch や PR はありませんでした。macOS の abort は Issue 作者による source report であり、私のローカル再現ではありません。

  2. 02

    ローカル baseline 11cd988 の静的 source review は到達可能な path を確認しました。decode 済み mono F32 PCM は audio bitmap になり、nx == 1 は四 byte を作り、tools/mtmd/mtmd.cpp は回復可能な nx == 0 branch の後にも厳密な > sizeof(float) assertion を使っています。

  3. 03

    この記録について fetch、build、model run、source edit、regression test、commit、push、PR、CI run はしていません。Windows baseline reproduction、server survival check、placeholder coverage、完全な 0/1/2/normal-audio matrix はすべて open gate のままです。

上流での進捗

  1. 静的 source path

    ローカル baseline 11cd988 で確認

  2. ローカル再現

    未実行

  3. 実装と回帰テスト

    候補設計のみ

  4. Pull Request

    未作成