こんにちは、AI開発スタートアップでエンジニアをしている明生です。前回sam3のご紹介をさせていただきました。今回はAMDでsam3を動かしたときの躓きポイントを紹介いたします。
私たちは日々、最新のAIモデルやハードウェアの検証を行っていますが、今私の手元にあるのは、AMDの技術の結晶とも言えるモンスターAPU 「Ryzen AI Max+ 395」 です。
このマシンのスペック、正直言って異常です。広帯域メモリと強力なiGPUを備え、本来であれば OpenAIの gpt-oss-120b のような超巨大LLMをローカルで動かすことにこそ真価を発揮する デバイスです。
しかし、今回私がやるのはそれではありません。
Meta社の最新画像セグメンテーションモデル 「SAM3（Segment Anything Model 3）」 です。
「え、SAM3？ あれって軽量だし、推論速度を求めるならNVIDIAのdGPUとか、もっと適した構成があるんじゃない？」
その通りです。おっしゃる通り。
Ryzen AI Max+ 395でSAM3を回すのは、ある意味で 頓珍漢な行為かもしれません。
でも、いいんです。理由はたった一つ。
「AMDの最新環境で、話題のSAM3を動かしてみたかったから」
これは、効率度外視のロマン駆動記事です。しかし、そこで直面したエラーと解決策は、AMDユーザーにとって普遍的な価値があるはずです。Ryzen AIユーザーが必ずと言っていいほど直面する rocBLAS error の完全攻略ガイドとして、この記録を残します。
直面した「絶望」：Webのどこにも答えがない
環境はWindows 11。AMDのAIスタックである ROCm（HIP SDK） を使用して、PyTorch上でSAM3を動かす構成です。
セットアップを順調に進め、いざ推論スクリプトを実行！……した瞬間に、非情なエラーログがターミナルを埋め尽くしました。
rocBLAS error: TensileLibrary.dat not found
出ました、AMD環境あるあるエラー。「TensileLibrary.dat not found」です。 要するに、「お前のGPU（gfx1151）用の計算辞書が見つからないから計算できないよ」 と言われているわけです。
Ryzen AI Max+ 395が採用する最新アーキテクチャゆえに、公式のライブラリ側がパスの対応をしきれていない……発売直後のハードウェアではよくある話です。
定石の「環境変数偽装」が効かない？
通常、AMD界隈ではこのエラーが出た場合、「環境変数を偽装する」 という裏技を使います。 gfx1151 はRadeon RX 7000シリーズ（gfx1100）と互換性が高いので、「私はgfx1100ですよ」とシステムに嘘をつくことで動かす手法です。
$env:HSA_OVERRIDE_GFX_VERSION = "11.0.0"
これを通せば万事解決……のはずでした。しかし、今回はこれが効きません。 エラーログは相変わらず「gfx1151用のファイルがない」と言い張り、指定したパス（site-packages_rocm_sdk_libraries_gfx1151\bin）を頑なに探しに行きます。
ネットの海を彷徨うも、成果はゼロ
生成aiでいろいろ解法を求めても、最終的には
🔴 現状：ローカル実行は技術的に不可能（2025年12月時点）
ローカル実行は、AMDが正式にgfx1151用Tensileライブラリをリリースするまで技術的に不可能です。
AI回答
と言われるしまつ。いやいやいや、絶対できるやろ～と諦めません。
「rocBLAS error gfx1151」「Ryzen AI 300 PyTorch」……あらゆるキーワードでGoogle検索をかけ、GitHubのIssueやRedditの深層まで潜りましたが、情報は驚くほど皆無。
Ryzen AI 300シリーズ（Strix Point）があまりに最新すぎるため、世界中でまだ誰もこのエラーの回避策を確立していないようでした。「やはりLLM専用機として生きるべきだったのか……」と諦めかけたその時、ふと原点に立ち返り、自分のPCの中にあるライブラリフォルダを直接漁ってみることにしました。
解決編：ファイルは「隠されていた」
Webに答えがないなら、ローカル（自分のPC）の中を探すしかない。 エラーログが指し示しているパスには、確かにフォルダすら存在しませんでした。 しかし、PyTorch（ROCm版）のインストールフォルダである site-packages をくまなく探してみると、見慣れないフォルダがあるのを発見しました。
_rocm_sdk_libraries_custom
「カスタム……？」 嫌な予感がして中を開いていくと、驚きの光景がありました。
gfx1151のTensileLibrary.dat
（ここに画像を挿入：_rocm_sdk_libraries_custom\bin\rocblas\library 内にgfx1151関連ファイルがある様子）
あるじゃないですか！ TensileLibrary_lazy_gfx1151.dat が！
そう、RDNA 3.5用のライブラリファイル自体は同梱されていたのです。 しかし、PyTorch側が 「_rocm_sdk_libraries_gfx1151 というフォルダ名を探しに行っている」 のに対し、実際のファイルは 「_rocm_sdk_libraries_custom という深い階層に隔離されている」 状態でした。これでは見つかるはずがありません。
ネット上に情報がないのも納得です。これは設定ミスではなく、フォルダ構成の不整合という、極めてアナログな罠だったのですから。
完全攻略手順：フォルダ移植手術
原因がわかれば、あとはファイルを「あるべき場所」に置いてあげるだけです。 世界中のRyzen AIユーザーのために、Web初公開（おそらく）の解決手順を記します。
手順1：隠し場所からファイルを救出する
エクスプローラーで以下のパスを開きます（Python環境の場所は各自の環境に合わせてください）。
...\site-packages\_rocm_sdk_libraries_custom\bin\rocblas\library
この中にある すべてのファイル （.datファイルや.hsacoファイル）をコピーします。
手順2：正しいフォルダを作成する
site-packages 直下に戻り、本来参照されるべき以下の階層構造でフォルダを新規作成します。
-
_rocm_sdk_libraries_gfx1151 というフォルダを作成。
-
その中に bin というフォルダを作成。
手順3：ファイルを配置＆リネーム
作成した bin フォルダの中に、手順1でコピーしたファイルをすべて貼り付けます。
さらに念のため、貼り付けた中の TensileLibrary_lazy_gfx1151.dat を複製し、 TensileLibrary.dat にリネームしておくと盤石です。
新規作成したフォルダへファイルを移動完了した様子
結果：SAM3、爆速で動作
フォルダ修正後、祈るような気持ちで再度スクリプトを実行しました。
実行成功log(使用デバイス：cudaとなっているのはPyTochのご愛敬、cuda以外の時もあるよ！)
動きました！ エラーは完全に消え、内蔵GPUが唸りを上げて推論を行っています。使用VRAMが7GB、１枚推論が約8秒、なかなか軽量動作だと思います。さすがにリアルタイム動画は無理ですが。(nvidaの高性能GPU欲しいなぁ・・・)
本来であればもっとヘビーなタスクをこなすべきRyzen AI Max+ 395ですが、こうして軽量なSAM3がサクサク動く様子を見るのもまた一興です。「AMD環境でも最新の画像モデルが動く」という事実確認ができただけで、今日のところは勝利と言っていいでしょう。
まとめ
今回のトラブルの教訓は 「エラーログだけでなく、フォルダの実体も疑え」 でした。基本ですよね。
Ryzen AI Max+ 395のような強力なハードウェアは、ソフトウェア環境（特にWindows版ROCm周り）がハードの進化に追いついていない過渡期にあります。しかし、今回のように「ファイル自体は用意されているが、パスが通っていないだけ」というケースも多いため、諦めずにディレクトリを掘ってみると解決の糸口が見つかるかもしれません。
同じエラーで困っているAMDユーザーの皆さん、ぜひこの「フォルダ移植手術」を試してみてください。快適な（そして少しオーバースペックな）ローカルAIライフを！
この記事に関するご意見や、Ryzen AI Max+ 395で検証してほしい「真に重たいモデル」のリクエストがあれば、ぜひコメント欄でお聞かせください！
次回はsam3とIoT的なカメラ(ESP32ベース)を組み合わた記事を載せますのでよろしくお願いいたします！
明生ライジングの実験室より。
https://www.akiorizing.com/