Hailo-8 / Hailo-8L（＝Raspberry Pi AI HAT+ SC1785/SC1775 系に搭載されているNPU）が、**LLM（大規模言語モデル）用途に向かない／高速化が難しい設計上の理由**を、ハードウェア構造・アーキテクチャ・ソフトウェアの観点から具体的に列記します。
---
# 🔧 Hailo-8 / 8L が LLM に不向きな設計上の理由（詳細列挙）
## ① 処理構造が「CNN最適化設計」であり、Transformer 向けではない
* Hailo-8 シリーズは、**畳み込みニューラルネット（CNN）や画像推論タスク**を対象として設計されている。
* そのため内部の計算グラフ最適化・演算ユニット構成が、
* 2D畳み込み (Conv2D)
* BatchNorm / ReLU
* Pooling / Upsampling
などの**画像処理パターン**に特化している。
* 一方 LLM は主に
* 行列積（GEMM）
* Attention（softmax + matmul）
* Embedding lookup
といった**系列データ・高次元テンソルの線形代数演算**が中心であり、Hailo-8 の演算パイプラインでは非効率。
→ 結果として、モデルを NPU にオフロードしても、Attention 部分が実行できず CPU 側に戻され、速度向上が得られない。
---
## ② オンチップメモリが小さく、外部DRAMインタフェースを持たない
* Hailo-8/8L は、**内部 SRAM（数MBクラス）**しか持たず、外部DDRメモリを直接制御できない。
* 一方、LLM では**重みとKVキャッシュが数百MB〜数GB規模**に達するため、オンチップSRAMでは保持不可能。
* 重み・中間テンソルの転送が頻発し、PCIe経由でホストメモリを参照せざるを得ない。
* PCIe経由のデータ転送はレイテンシが大きく、NPU演算ユニットの稼働率が低下する。
→ **メモリ帯域・容量がボトルネック**となり、トークン生成時のストールが発生。
---
## ③ データフローモデルが静的最適化前提で、動的系列長に非対応
* Hailo の推論アーキテクチャは「**コンパイル時に演算グラフを静的に最適化**」する方式。
* Transformer のような LLM は「入力トークン長が動的」「自己注意のマスク形状が可変」といった**ランタイム依存**の構造を持つ。
* そのため、Hailo コンパイラ（Dataflow Compiler）では系列長を固定できず、Attention 部分を展開できない。
* 実際、コミュニティで distil-whisper や BERT 変換を試みた例では、attention層で「Unsupported operator」エラーが発生している。
→ 「固定的な畳み込みネット」以外は最適化しにくく、Transformerモデルではコンパイル不可／部分的実行しかできない。
---
## ④ Attention／Softmax／LayerNorm／Embedding 等の演算ユニットが存在しない
* Hailo-8 は、Conv / FC / Elementwise など基本的な演算ブロックのみ実装。
* LLMで頻出する以下の演算をハードウェア的にサポートしていない：
* **Softmax**（Attention のスコア正規化）
* **Layer Normalization**
* **Embedding Lookup**
* **GELU / SwiGLU 等の非線形活性**
* **KVキャッシュ参照／更新**
* これらはCPU上で逐次処理されるため、実質的にアクセラレータがアイドル状態になる。
→ 結果：**「NPUは一部しか動かない」ため、全体性能はCPU実行と大差なし。**
---
## ⑤ マルチヘッドAttentionや長系列のストリーム処理構造を持たない
* LLMでは「マルチヘッドAttention」による大量の並列行列積を扱う。
* しかし Hailo-8 のアーキテクチャは「多チャネルCNN」の並列化構造であり、**系列方向（時間軸）での並列処理を想定していない**。
* また、LLM生成ではトークンごとに前回の出力（KVキャッシュ）を逐次参照する必要があるが、Hailo-8 にはそのような逐次ストリーム最適化回路がない。
→ **再帰的／逐次的処理に弱い構造**のため、生成型LLMを継続動作させると効率が著しく低下。
---
## ⑥ 演算精度と量子化スキームが LLM に最適化されていない
* Hailo-8 の内部精度は主に INT8 / UINT8 固定点演算。
* LLM は微妙な重み分布とsoftmax正規化を扱うため、**INT8単精度では出力品質が著しく劣化**するケースが多い。
* 通常、LLM量子化は 4bit/5bit/8bit + 専用スケーリングや非線形補正を行う（例：GPTQ、AWQ）。
* Hailo のINT8エンジンではこのような**非線形量子化を扱えず**、精度劣化・不安定な出力が発生する。
→ 実質的に「動作しても結果が破綻」するケースが多い。
---
## ⑦ I/Oとホスト制御が分離され、逐次制御がオーバーヘッドに
* LLM推論は「1トークンごとに逐次推論」する必要がある（1ステップ生成→再入力→次ステップ）。
* Hailo-8 のPCIe経由実行では、毎ステップで NPU呼び出し／メモリ転送／結果取得を繰り返す必要がある。
* これは CNN の「1回入力→1回推論→完結」型と違い、非常にオーバーヘッドが大きい。
* 実行回数が数千トークン規模になると、PCIeレイテンシが支配的になる。
→ **インタフェース設計が逐次生成に不向き。**
---
## ⑧ ソフトウェアスタックが LLM未対応
* Hailo-RT / Hailo-SDK / Hailo-Dataflow-Compiler は TensorFlow Lite / ONNX などを介して CNN/DNN推論をサポートするが、
* HuggingFace Transformers
* llama.cpp / ggml
* MLC LLM / vLLM
等のLLMフレームワーク統合は行われていない。
* 結果として、LLMのトークン生成パイプラインをNPUに統合することが困難。
* 一部レイヤーごとの推論はできても「生成全体を通して高速化」できない。
---
## ⑨ Hailo-10/Hailo-10H で初めて LLM向けアーキテクチャを導入
* Hailo社自身が、Hailo-10シリーズで**外部メモリ接続・Transformers最適化・長系列処理**に対応すると発表。
* つまり、メーカー自身も「Hailo-8世代では LLM は難しい」と認識していることを示唆。
* Hailo-10H はエッジLLM（小型GPT・Whisper等）の運用を公式にサポート予定。
---
