本記事にはアフィリエイト広告（Amazon アソシエイト）が含まれます。
実測日: Mon Oct 12 2026 09:00:00 GMT+0900 (Japan Standard Time)
Hailo-10H は、LLM を載せられるとされる数少ないエッジ向けアクセラレータである。
ただし「載る」と「使える速さで動く」は別の話で、どちらなのかは実際に測らないと判らない。
本記事では、ASUS UGen300（Hailo-10H を USB で外付けにした製品）に 2B 級の LLM を載せ、1 token の生成に何秒かかるかを測った結果を示す。
2B 級のモデルは 1 本の HEF に収まらない
Hailo のコンパイラは、ネットワークを HEF という実行形式に変換する。
2B 級のモデルは重みだけで 1 GB を超え、1 本の HEF には収まらなかった。
そこで、ネットワークを 30 本の区間に分け、区間ごとに HEF を作って順に実行する形にした。
分けた HEF を順に動かすには、すべての HEF をデバイスに保持したまま token ごとに回すのが理想である。
ところが、実際にはそれができない。
同時に保てる HEF は 8 本まで
31 本の HEF を順に configure して保持し続けるプログラムを書いて試したところ、9 本目で HAILO_EVENT_CREATE_FAIL(34) が返った。
ファイルディスクリプタの上限が原因ではない。
soft と hard の上限を 1048576 にしても 65536 にしても、同じ 9 本目で落ちたからである。
デバイスかドライバの側に、同時に保持できる数の上限があると見るのが自然である。
つまり 30 本の鎖は常駐させられず、token を 1 つ生成するたびに HEF を載せ替える必要がある。
この載せ替えが、後で示す速さの大半を占める。
1 token あたりの内訳
6 token の prefill（入力をすべて読み込む段階）を 29 本の鎖で流した時間は、全体で 80.4 秒だった。
内訳は次のとおりである。
| 項目 | 時間 |
|---|---|
| 入口の埋め込みをホストで作る | 1.7 秒 |
| 入口の値を別の機械から運ぶ（足場の都合で、本質ではない） | 22.0 秒 |
| 区間 30 本を順に実行 | 55.4 秒 |
| うち、デバイスの計算だけ | 1 token あたり 653 ms |
| HEF の読込（ディスクからホスト RAM、31 本 1.25 GB） | 12.96 秒 |
| configure（ホストからデバイス、USB で約 156 MB/s） | 7.95 秒 |
デバイスの計算 653 ms の正体は、コンテキストの遷移である。
1 token あたり約 296 回の遷移が起き、1 回が約 2.2 ms かかる。
行列計算そのものではなく、区間の継ぎ目で重みを入れ替える時間が支配している。
逐次生成の速さ
生成段階では token ごとに 30 本の HEF を載せ替えるので、1 token に約 8.7 秒かかる。
tok/s に直すと 0.115 で、対話の用途には使えない。
仮に 1 本の HEF に収まって常駐できたとしても、653 ms なので 1.5 tok/s にとどまる。
重みを USB 越しに流し込む下限（1.25 GB を約 2.5 GB/s で）から見積もると 100〜200 ms、つまり 5〜10 tok/s が理論上の上限になる。
| 形 | 1 token | tok/s |
|---|---|---|
| 30 本の鎖を token ごとに載せ替え（実測） | 約 8.7 秒 | 0.115 |
| 1 本に収まり常駐できた場合（計算値） | 653 ms | 1.5 |
| 重みの流し込みの下限（見積もり） | 100〜200 ms | 5〜10 |
prefill は事情が違う。
入力の token はすべて判っているので、区間ごとに全 token をまとめて通せる。
N token の prefill にかかる時間は 21 秒 + N × 0.653 秒で、128 token なら約 105 秒である。
要するに、まとめて処理する埋め込みや要約には使えるが、1 token ずつ返す対話には使えない。
非自己回帰のモデルなら桁が変わる
同じデバイスでも、1 回の推論で答えが出るモデルなら話は逆になる。
78 層ほどの小さい区間（26〜30 MB）は 1 回 10〜11 ms で回った。
常駐できる 1 本のネットワークなら、所要時間は「重みの MB ÷ 2500」秒に計算時間を足した程度と見積もれる。
たとえば 234M パラメータ（8 bit で 234 MB）なら約 94 ms である。
この見積もりを用途ごとに当てはめると、次のようになる。
- 音声認識：SenseVoiceSmall（234M パラメータ、CTC、非自己回帰）は 1 回で 6 秒分の音声を処理する。見込みは 150〜300 ms で、実時間の 20〜40 倍速になる。このデバイスに最も合う用途である。
- 音声区間検出：Silero 級なら CPU で足りる。デバイスに載せる利点はない。
- 音声合成：自己回帰の codec LM 型（XTTS-v2、Fish-Speech、CosyVoice）は音声 1 秒に codec token を 25〜75 本生成するので、LLM と同じ壁に当たる。非自己回帰型（VITS、StyleTTS2、Matcha-TTS）なら 1 発話 1 回で済み、デバイスに合う。
購入前に知っておきたいこと
Hailo-10H を「エッジで LLM を動かす」目的で買うなら、1 本の HEF に収まる小さなモデルに限ること、そして対話ではなくまとめ処理に使うことが前提になる。
一方で、音声認識や画像認識のような非自己回帰のモデルには向いており、USB 給電で動く 8 GB のデバイスとしては貴重である。
なお、Raspberry Pi AI HAT+ に載る Hailo-8 系は外付けメモリを持たず、LLM は最初から対象外である。
この記事で扱った機材
ASUS UGen300（Hailo-10H USB AI アクセラレータ）
Hailo-10H を USB 3.1 Gen2 で外付けにした製品。8 GB の LPDDR4 を載せる。本サイトの Hailo-10H の実測はすべてこの個体で行った。
Raspberry Pi AI HAT+（Hailo-8L / Hailo-8）
Hailo 系で最も入手しやすい製品。LLM には向かないが、非自己回帰の視覚モデルや音声認識には合う。