ガイド

著者 Matt Connor 2026-10-25

Immich のハードウェアアクセラレーション：N100 の Quick Sync 設定

Q: VPS で Immich のハードウェアアクセラレーションは使えますか？

サーバーで ls -l /dev/dri を実行して判断します。No such file or directory と出たら、そのサーバーには Linux から使える GPU がないので、Immich は CPU 設定のまま使います。/dev/dri があっても、lspci -nnk で Intel のグラフィックス機器にドライバが割り当てられているかを確かめてから設定してください。

Q: extends の service に qsv と書いたら Immich が起動しません。なぜですか？

v3.3.5 の hwaccel.transcoding.yml に qsv というサービスはないからです。Intel Quick Sync のサービス名は quicksync です。qsv は、管理画面の設定や設定ファイルの accel に使う値です。service: quicksync に直し、docker compose config immich-server で /dev/dri が合成されているかを確かめてください。

N100 などの Intel ミニPCで、Immich の動画変換を CPU から iGPU に移す手順です。/dev/dri の確認、v3.3.5 に固定した hwaccel ファイル、管理画面の設定、vainfo と intel_gpu_top での動作確認まで解説します。

まず確認：Immich のハードウェアアクセラレーションはこのサーバーで使えるか

Immich のハードウェアアクセラレーションを Intel の内蔵 GPU（iGPU）で使うとき、最初に確かめるのは、Docker ホストに /dev/dri というデバイスが見えているかどうかです。これが見えなければ、先には進めません。ただし、見えているだけで動くとは限りません。iGPU とドライバが目的のコーデックのエンコードに対応していること、そのデバイスがコンテナに渡っていること、Immich の設定で Quick Sync を選んでいることも必要です。公式ドキュメントも、ハードウェアトランスコードは実験的な機能で、すべての環境で動くとは限らないとしています。N100 を積んだミニPCでこれらがそろえば、動画のエンコードを CPU から iGPU に移せます。最初に次の 1 行を実行してください。

ls -l /dev/dri

ls: cannot access '/dev/dri': No such file or directory と表示されたら、そのサーバーには Linux から使える GPU がありません。この場合は Immich の設定を CPU のままにします。このガイドの手順はそこで終わりです。

VPS で Immich を動かしている場合も、同じコマンドで判断します。GPU を割り当てると明記されたプランでなければ、/dev/dri があることを前提にしないでください。結果がエラーなら、Immich は CPU 設定で使います。

/dev/dri があり、その中に renderD128 のような renderD で始まるファイルがあれば、次に進みます。ただし /dev/dri があるだけでは、それが Intel の iGPU だとはまだ言えません。それは後の節で確かめます。

このガイドの前提

このガイドは、Intel N100 などを積んだミニPCに Ubuntu を入れ、Docker Compose で Immich を動かしている人向けです。まだ Immich を入れていない場合は、先に Immich をセルフホストして Google フォトの代わりにする手順を済ませてください。

対象の Immich は v3.3.5 です。GitHub のリリースページでは 2026 年 10 月 21 日公開で、2026 年 10 月 25 日に確認した時点の最新リリースです。v3.3.5 のリリースノートには、ハードウェアアクセラレーションやトランスコードについての変更は書かれていません。

先に一つ、はっきりさせておきます。Immich の公式ドキュメントは N100 に一度も触れていません。そのため、このガイドでは「公式ドキュメントに書かれていること」と「自分の機械で確かめること」を分けて書きます。N100 で動くかどうかは、ドキュメントではなく、あなたのサーバーのコマンド結果で判断します。

Immich のハードウェアアクセラレーションで何が iGPU に移るのか

Immich の機能のうち、GPU を使えるものは二つあります。動画のトランスコード（再生用の形式に変換する処理）と、機械学習（ML、machine learning）です。この二つは設定が別々です。

トランスコードについて、公式ドキュメントは四つの API に対応すると書いています。NVENC（NVIDIA）、Quick Sync（Intel）、RKMPP（Rockchip）、VAAPI（AMD、NVIDIA、Intel）です。VAAPI は VA-API（Video Acceleration API）のことで、Linux で動画処理をハードウェアに任せるための共通の仕組みです。この機能はドキュメント上で実験的（experimental）とされています。

対応するサーバーは Linux と、WSL2 経由の Windows だけです。WSL2 では Quick Sync が使えません。Raspberry Pi も対象外です。

一番誤解されやすい点はこれです。ドキュメントには「By default, only encoding is currently hardware accelerated.」とあります。つまり初期状態では、iGPU に移るのはエンコードだけです。デコード（元の動画を読み解く処理）とトーンマッピング（HDR の明るさを SDR 向けに直す処理）は、ハードウェアデコードを有効にするまで CPU が担当します。iGPU を有効にしたのに CPU 使用率があまり下がらない場合は、まずこの点を疑ってください。

NVIDIA の GPU を持っている場合は、考え方は同じで手順が違います。GPU をコンテナに渡す仕組みは Jellyfin で NVIDIA GPU のハードウェアトランスコードを使う方法が参考になります。

Linux カーネルは N100 の iGPU を認識しているか

N100 は、Intel の製品ページで「Products formerly Alder Lake-N」とされている CPU です。同じページには、Intel UHD Graphics を内蔵し、Quick Sync Video に対応すると書かれています。Alder Lake-N は短く ADL-N と書かれます。

Linux カーネルの側では、kernelnewbies に載っている Linux 5.18 のリリースノートに「ADL-N platform enabling」という項目があります。Intel の GPU ドライバ i915 には、ADL-N を有効にするコミット（drm/i915/adl-n: Enable ADL-N platform）があります。ただし、5.18 より前のカーネルにどこまで対応が入っていたかは、このガイドでは確かめていません。

Ubuntu 22.04 LTS の最初のカーネルは 5.15 です。Ubuntu のカーネルのライフサイクル表には、22.04.5 の HWE（hardware enablement）カーネルとして 6.8 が載っています。Ubuntu のカーネルは、番号が同じでも Ubuntu 独自の修正を含みます。そのため番号だけでは判断できません。番号ではなく、実際の状態を見ます。

uname -r
lspci -nnk | grep -EiA3 'vga|display'

lspci の出力で、Intel のグラフィックス機器の下に Kernel driver in use: i915 のような行があれば、カーネルは iGPU にドライバを割り当てています。その状態なら、/dev/dri に renderD128 などが現れます。

Kernel driver in use の行がない場合は、今のカーネルがこの iGPU を扱えていません。この場合、Immich の設定をいくら変えても iGPU は使えません。Ubuntu 22.04 なら HWE カーネルに切り替えるか、新しい Ubuntu に移ることを検討してください。

なお、Immich のドキュメントにあるカーネル 5.15 の注意は、VP9 を使う場合の条件の一つで、11 世代の Intel CPU についてのものです。N100 についての注意ではありません。

vainfo で N100 がエンコードできるコーデックを確かめる

N100 がどのコーデックをハードウェアでエンコードできるかは、Intel の製品ページには載っていません。Intel のメディア機能表（oneVPL の開発者向けリファレンス）を見ても、N100 や Alder Lake-N という名前の列はありません。そのため、このガイドでは N100 の対応コーデックを断定しません。自分の機械で調べます。

使うのは vainfo です。VA-API のドライバが何を処理できるかを一覧にするツールです。

sudo apt update
sudo apt install -y vainfo intel-media-va-driver intel-gpu-tools
vainfo

vainfo は、ドライバのバージョンの後に「プロファイル : エントリポイント」の組を並べます。プロファイルはコーデックの種類で、VAProfileH264Main や VAProfileHEVCMain のような名前です。エントリポイントは、そのコーデックに対してどの処理ができるかを表します。

エンコードできるかどうかは、エントリポイントの名前で見分けます。libva のヘッダファイル va.h では、VAEntrypointEncSlice が「slice level encode」、VAEntrypointEncSliceLP がその低消費電力版と説明されています。つまり、H.264 の行や HEVC（H.265）の行に EncSlice または EncSliceLP が付いていれば、そのコーデックはハードウェアでエンコードできます。Immich で変換先のコーデックを選ぶときは、この一覧にエンコードの行があるものを選んでください。

一つ注意があります。ここで動かした vainfo は、ホストに入れたドライバを使います。Immich のコンテナは、コンテナの中に自分のドライバを持っています。そのため、ホストの結果とコンテナの中の結果は同じとは限りません。ホストの vainfo は「ハードウェアとカーネルが使える状態か」を見る確認だと考えてください。最終的な確認は、後で Immich が実際に変換するときに行います。

hwaccel.transcoding.yml を v3.3.5 に固定して置く

Immich は、GPU ごとの設定を hwaccel.transcoding.yml という別ファイルにまとめています。これを docker-compose.yml と同じフォルダに置き、Compose の extends で読み込みます。extends は、別ファイルにあるサービス定義を取り込む機能です。仕組みは Docker Compose で複数の設定ファイルを組み合わせる方法で説明しています。

公式ドキュメントのダウンロードリンクは「最新リリース」を指します。最新リリースは時間とともに変わるので、このガイドでは v3.3.5 のタグに固定したファイルを取得します。Immich の docker-compose.yml の冒頭にも「The compose file on main may not be compatible with the latest release.」とあります。main ブランチのファイルは使わないでください。

cd ~/immich-app
wget -O hwaccel.transcoding.yml https://raw.githubusercontent.com/immich-app/immich/v3.3.5/docker/hwaccel.transcoding.yml
grep -A2 '^  quicksync:' hwaccel.transcoding.yml

cd の先は、あなたの docker-compose.yml があるフォルダに変えてください。grep の結果に quicksync: と /dev/dri:/dev/dri の行が出れば、ファイルは正しく取れています。v3.3.5 の quicksync サービスがしていることは、ホストの /dev/dri をコンテナに渡すことだけです。

このファイルの冒頭のコメントには、設定を immich-microservices サービスにコピーするようにと書かれています。v3.3.5 の docker-compose.yml に、そのサービスはありません。今は immich-server が担当しています。コメントの古い名前は無視してください。

イメージのバージョンも固定します。v3.3.5 の example.env では IMMICH_VERSION=v3 が初期値で、コメントに「You can pin this to a specific version」とあります。v3 のままだと、v3 系の新しいリリースが出たときにイメージの中身が変わります。hwaccel ファイルとイメージのバージョンをそろえるため、.env を書き換えます。

grep IMMICH_VERSION .env
sed -i 's/^IMMICH_VERSION=.*/IMMICH_VERSION=v3.3.5/' .env
grep IMMICH_VERSION .env

2 回目の grep が IMMICH_VERSION=v3.3.5 を表示すれば完了です。

docker-compose.yml の extends を有効にする

v3.3.5 の docker-compose.yml では、immich-server の下に extends がコメントアウトされた状態で入っています。

  immich-server:
    container_name: immich_server
    image: ghcr.io/immich-app/immich-server:${IMMICH_VERSION:-release}
    # extends:
    #   file: hwaccel.transcoding.yml
    #   service: cpu # set to one of [nvenc, quicksync, rkmpp, vaapi, vaapi-wsl] for accelerated transcoding

この 3 行の # を外し、cpu を quicksync に変えます。

  immich-server:
    container_name: immich_server
    image: ghcr.io/immich-app/immich-server:${IMMICH_VERSION:-release}
    extends:
      file: hwaccel.transcoding.yml
      service: quicksync

ここでよく間違えるのが qsv です。qsv は、管理画面の設定や設定ファイルの accel に入る値です。hwaccel.transcoding.yml の中のサービス名ではありません。v3.3.5 のファイルにあるサービスは cpu、nvenc、quicksync、rkmpp、vaapi、vaapi-wsl の六つだけです。service: qsv と書くと、Compose は存在しないサービスを読み込もうとするので、コンテナを起動する前にエラーで止まります。

vaapi も /dev/dri を渡すだけなので、Intel の iGPU で使えます。ただしドキュメントは、専用の API があるならそちらを使うように勧めています。Intel なら Quick Sync です。vaapi は、Quick Sync でうまくいかないときの次の選択肢にしてください。

書き換えたら、Compose が設定を正しく合成できるかを確かめます。

docker compose config immich-server | grep -A4 devices

出力に /dev/dri が含まれていれば、extends は効いています。エラーが出た場合は、インデントと service: の値を見直してください。

再デプロイして、コンテナから iGPU が見えるか確かめる

ドキュメントの手順では、ここで immich-server コンテナを作り直します。

docker compose up -d
docker exec immich_server ls -l /dev/dri

docker compose up -d は、設定が変わったコンテナだけを作り直します。ほかのサービスに触れずに immich-server だけを作り直したい場合は、Docker Compose で一つのサービスだけを起動し直す方法を参考にしてください。

2 行目で、ホストと同じ renderD128 などがコンテナの中に見えれば成功です。No such file or directory が出る場合は、extends が読み込まれていません。前の節の docker compose config からやり直してください。

管理画面で Quick Sync を選ぶ

コンテナに iGPU を渡しただけでは、Immich はまだ CPU で変換します。管理画面で API を選ぶまでが設定です。

管理者アカウントで Immich にログインし、管理画面（Administration）の設定を開きます。
Video transcoding settings を開き、Hardware Acceleration の項目で Quick Sync を選んで保存します。
必要なら、同じ場所でハードウェアデコードを有効にします。ドキュメントでは任意の手順ですが、前に書いたとおり、これを有効にしないとデコードは CPU のままです。

画面ではなく設定ファイルで Immich を管理している場合は、accel を qsv に、accelDecode を true にします。

公式ドキュメントには、CPU の世代ごとの注意がいくつかあります。Jasper Lake と Elkhart Lake では、Hardware Acceleration の Constant quality mode を CQP にする必要があります。VP9 のエンコードについては、条件がまとめて書かれています。VP9 には 9 世代以降の Intel CPU が必要です。そのうえで 11 世代以前の CPU では Low-Power モードが必要になることがあり、ドキュメントは Jellyfin の手順を案内しています。つまり Low-Power の注意は、Quick Sync 全般ではなく VP9 についてのものです。

N100 は、このどれにも名前が出てきません。そのため、N100 で最初から CQP や Low-Power の設定を変える根拠はありません。まず初期値で動かし、エラーが出たときに見直してください。

ドキュメントの助言がもう一つあります。プリセットは、ソフトウェアで変換するときより遅いものを選びます。ドキュメントによれば、品質と効率を保つためです。

本当に iGPU で変換しているかを確かめる

最後に、実際の変換で iGPU が動いているかを見ます。端末を二つ開いて、片方で intel_gpu_top を動かします。

sudo intel_gpu_top

intel_gpu_top は Intel GPU の使用状況を表示するツールで、intel-gpu-tools パッケージに入っています。man ページによると、root 以外のユーザーが性能カウンタを読めるかどうかは perf_event_paranoid という sysctl で決まります。そのため、ここでは sudo を付けています。

もう片方では、Immich のログを流しておきます。

docker logs -f immich_server

この状態で、スマホから動画を 1 本アップロードするか、管理画面のジョブ一覧から動画のトランスコードを実行します。見るポイントは二つです。

intel_gpu_top の画面で、何も変換していないときは 0% 近くだったエンジンの使用率が、変換中に上がること。変換が終われば元に戻ります。
Immich のログに、変換中のエラーが出ないこと。ドキュメントにも「A lack of error logs when transcoding also indicates that it's being used.」とあります。

使用率が上がらず、ログにエラーが出る場合は、管理画面の Hardware Acceleration を一度 CPU に戻してください。CPU に戻せば、Immich の変換は元どおり CPU で動きます。そのうえで、vainfo の結果、lspci -nnk のドライバ、コンテナ内の /dev/dri を順に見直します。

機械学習も iGPU に載せる（OpenVINO）

顔認識やスマート検索などの機械学習も、Intel の GPU に任せられます。使う仕組みは OpenVINO です。手順はトランスコードとほぼ同じなので、短くまとめます。

cd ~/immich-app
wget -O hwaccel.ml.yml https://raw.githubusercontent.com/immich-app/immich/v3.3.5/docker/hwaccel.ml.yml

docker-compose.yml の immich-machine-learning を、次のように変えます。イメージのタグの末尾に -openvino を付け、extends のコメントを外して service を openvino にします。

  immich-machine-learning:
    container_name: immich_machine_learning
    image: ghcr.io/immich-app/immich-machine-learning:${IMMICH_VERSION:-release}-openvino
    extends:
      file: hwaccel.ml.yml
      service: openvino

トランスコードと違い、機械学習ではサービス名とタグの末尾が同じ openvino です。v3.3.5 の openvino サービスも、/dev/dri をコンテナに渡します。保存したら、docker compose up -d で作り直します。

動作の確認方法も、公式ドキュメントにあります。スマート検索か顔検出のジョブが始まったら、docker logs immich_machine_learning に出る「Available ORT providers」の行を見ます。その行に OpenVINO のプロバイダ名が入っていれば、OpenVINO が使われています。intel_gpu_top で使用率を見る方法も使えます。

期待しすぎないための注意があります。ドキュメントが OpenVINO の例として名前を出しているのは Iris Xe と Arc で、N100 の UHD Graphics ではありません。ドキュメントによれば、内蔵 GPU は単体 GPU より問題が起きやすく、古い CPU やメモリの少ないサーバーでは特にそうです。さらに、OpenVINO は CPU で処理するよりメモリを多く使います。メモリに余裕がない場合は、Immich に必要なメモリとストレージの目安と照らし合わせてから試してください。

機械学習を別の強いマシンに任せる方法もあります。その手順は Immich の remote machine learning のガイドにまとまっているので、ここでは繰り返しません。そのガイドは、機械学習コンテナにはセキュリティの仕組みが一切ないことと、二つのマシンで Immich のバージョンがずれると不具合の原因になることを警告しています。

Hailo や Raspberry Pi では使えるか

Hailo の AI アクセラレータを Immich の機械学習に使いたいという要望があります。2026 年 10 月 25 日の時点では、これは GitHub の Discussion #17230 にある機能要望（Feature Request）です。2025 年 3 月 30 日に立てられたもので、機械学習のハードウェアアクセラレーションのドキュメントにも、FAQ にも、Hailo の名前はありません。第三者が作ったプロジェクトはありますが、公式の対応ではありません。

Raspberry Pi について、Immich のドキュメントに専用のページはありません。FAQ の Raspberry Pi のようなメモリの少ないシステムで Immich が遅い理由が案内先です。そして前に書いたとおり、ハードウェアトランスコードは Raspberry Pi を対象外にしています。

VPS や仮想環境で動かしている場合

Immich の動作要件のページには「Immich runs well in a virtualized environment when running in a full virtual machine.」とあります。一方で、LXC コンテナの中で Docker を動かす構成は推奨されていません。Proxmox を使っていて iGPU を渡すつもりなら、LXC ではなく完全な仮想マシンで動かす前提で考えてください。仮想マシンに iGPU を渡す設定そのものは、このガイドの範囲外です。

VPS では、最初の節の ls -l /dev/dri の結果で決まります。エラーになるなら、Immich は CPU 設定のまま使います。

Unraid や Portainer のように、複数の Compose ファイルを扱えない環境もあります。その場合ドキュメントは、hwaccel.transcoding.yml から使うバックエンドの設定を immich-server に直接コピーするよう案内しています。Quick Sync なら、/dev/dri のデバイス指定を一つ足すだけです。

Immich をアップデートするときに忘れないこと

このガイドでは、イメージと hwaccel ファイルを両方 v3.3.5 に固定しました。固定したものは、自動では新しくなりません。アップデートするときは、.env の IMMICH_VERSION を新しいタグに変え、同じタグから hwaccel.transcoding.yml と hwaccel.ml.yml を取り直してください。片方だけを新しくすると、ファイルの中身とイメージが合わなくなるおそれがあります。

アップデートの前には、必ずバックアップを取ります。手順は Docker Compose のスタックを安全にバックアップしてアップグレードする方法と Immich のバックアップと復元にまとめています。

FAQ

VPS で Immich のハードウェアアクセラレーションは使えますか？

サーバーで ls -l /dev/dri を実行して判断します。No such file or directory と出たら、そのサーバーには Linux から使える GPU がないので、Immich は CPU 設定のまま使います。/dev/dri があっても、lspci -nnk で Intel のグラフィックス機器にドライバが割り当てられているかを確かめてから設定してください。

extends の service に qsv と書いたら Immich が起動しません。なぜですか？

v3.3.5 の hwaccel.transcoding.yml に qsv というサービスはないからです。Intel Quick Sync のサービス名は quicksync です。qsv は、管理画面の設定や設定ファイルの accel に使う値です。service: quicksync に直し、docker compose config immich-server で /dev/dri が合成されているかを確かめてください。

N100 は AV1 や VP9 をハードウェアでエンコードできますか？

Intel の製品ページは N100 の Quick Sync Video 対応を示していますが、コーデックの一覧は載せていません。Intel のメディア機能表にも N100 の列はありません。自分のサーバーで vainfo を実行し、目的のコーデックのプロファイルに VAEntrypointEncSlice か VAEntrypointEncSliceLP が付いているかを見てください。付いていれば、そのコーデックはハードウェアでエンコードできます。

iGPU を有効にしたのに CPU 使用率があまり下がりません。なぜですか？

Immich の初期設定では、ハードウェアで処理されるのはエンコードだけだからです。デコードとトーンマッピングは CPU に残ります。管理画面の Video transcoding settings でハードウェアデコードを有効にし、変換中に sudo intel_gpu_top で使用率を見比べてください。

Hailo の AI アクセラレータは Immich の機械学習に使えますか？

2026 年 10 月 25 日の時点では、公式には使えません。Hailo への対応は GitHub の Discussion #17230 にある機能要望の段階で、Immich の機械学習アクセラレーションのドキュメントにも Hailo の名前はありません。ドキュメントにある対応バックエンドは ARM NN、CUDA、ROCm、OpenVINO、RKNN です。

#immich#hardware-acceleration#intel-quick-sync#docker-compose #transcoding #home-server