もしダウングレードが禁止された主な理由がセキュリティ修正とファームウェアアップグレードのインストールを分離できないことなのであれば、これらのインストールを分けることはできないでしょうか。そうすれば、ファームウェアをダウングレードしつつ必要なセキュリティ修正をインストールすることができます。
素晴らしい説明をありがとう、Sam。コンプライアンスの観点からも納得できました。ロールバックがサポートチームで有効なオプションかどうか確認したかっただけで、ロールバックを実行できる技術者にたどり着くために「レベル5」サポートまで何週間もかけて進む必要がないことを願っています。ロールバックが滅多に必要にならないことを祈りますし、説明してくれて本当に感謝しています。
QTS 6がいつようやく登場するのか、誰か知ってますか？
説明してくれてありがとう、Sam。でも、ロールバックのためにサポートに連絡する選択肢が説明されていたら良かったのに――説明されていませんでした。
全員がEUにいるわけではありませんので、サイバーセキュリティ規制はすべての顧客に適用されるわけではありません。他の国でも今後そのようなシナリオになる可能性は高いと思うので、決定の理由は理解できます。
貴社のサポートチームの対応速度にはかなり課題がありますが、利用可能なチャンネルはメールのみです。多くの組織では、メールへの返答のサービスレベルは通常12～24時間以内です。しかし、コンピュータの技術サポートの場合、他のサポートチャンネルが存在することが一般的です。QNAPではそれがありません。週のうちに運良く問題が発生した場合、初回の返答までに6～8時間かかることもありますが、金曜日の遅い時間や週末だと望み薄です。顧客が返信した後のフォローアップ返答も同じくらい時間がかかる場合があります。これは多くの人にとって現実的ではありません。私が7月14日に起票したチケット？今日（7月21日）、やっとHelpDeskを通じてシステムへのアクセスを依頼されました。幸い、自分で問題を解決できていましたが、さらに調査したいとのことでした。
顧客層がQuTS Hero 6へ移行し、トラブルを経験し始めれば、この不満はさらに広がっていく予感があります。
これは、その業界に関わっていない人たちによって作られた法律によくあることです。ロールバックできないことで、人々は動いているファームウェアを長く使い続けたくなります。その結果、最新のセキュリティ修正を受け取れなくなります。もし、金曜の夜や週末に本番機にファームウェアアップデートを入れて何かが壊れてしまったら、月曜日にスタッフに何て説明するんですか？
正直に言うと、たぶんいろいろと言うと思いますが、そのどれも褒め言葉ではないでしょう！
電源設定にはEUスリープモードの設定があります。その設定をリバート（元に戻す）機能と紐付けてはどうでしょうか。EUのユーザーは、そのチェックボックスを必ず選択しなければならないでしょう。もし選択しなければ、それはQNAP（キューナップ）の問題ではありません。あるいは、世界の他の地域がリバートを義務付ける法律を制定することもできます。
あるいは、NAS をセットアップする際に、中国やその他の国ではなく、EU を選択肢として追加してください。
ちょっと気になって、このEUスリープモードを探してみましたが、QuTS Heroの電源設定には見当たりませんでした。もしかしたらQTS専用なのか、あるいは私のハードウェアが対応していないのかもしれません。TS-h1887XU-RPなので、ラックマウント型だから対応していない可能性が高そうです。
「コントロールパネル」、「電源」、「Eupモード」（Eup mode）は、QTSとQuTSの両方で利用できます。
おそらく、あなたのデバイスはパワーダウンモードでは常に1ワット未満しか消費しないという意味です。
TVS-AIH1688ATXをQuTS Hero h6.0.0.3500からQuTS Hero 6.0.1.3550に問題なくアップグレードしました。
Nvidia 4000 Blackwell GPU
QXP-800S
192 GB Ram
コントロールパネルからアップグレードしました。事前に新しいOSファームウェア、Nvidiaカーネル、Advanced NetworkファイルをDLしておきました。コントロールパネルのファームウェアアップデートからアップグレードを開始し、QNAPからDLしたファームウェアファイルを使用してアップグレードを実施。問題なくインストールが完了し、その後ボックスが2回再起動、Nvidiaインストール失敗とネットワークアダプターの問題が発生しました。
既存のNVIDIAドライバー（カーネルではなく）をアンインストールし、新しいカーネルドライバーとAdvanced Networkドライバーをインストール。その後再起動し、ボックスが再起動してきたら、ストアからNVIDIAドライバーを再インストールし、再度再起動しました。ボックスが立ち上がると全て正常に動作していました。QWEN、Plex、JellyFinなどもすべて正常に動作しており、4000を従来通り使用できています。
こんにちは、それでAIを作っているのですか？まだ判断できませんが、Gemma 4（量子化済み）やQwen3.6（量子化済み、RTX Pro 4000で17GBのRAM使用）のようなモデルは、以前GPUでロードできていたのに、今はもうできなくなっています（Ollama上で）。
Ollamaを0.30.8まで戻しましたが、問題は同じままです。
こんにちは、
ご回答ありがとうございます。
私は、Nvidiaドライバーのアンインストール→QNAPサイトからカーネルドライバーの更新→ドライバー再インストールという方法を試しました。
この手順の後、GPU上でOllamaを少し使えるようになりました。しかし、ここ数日間はまったく使えず、CPUのみで実行（コマンド：ollama ps）、コンテナ内にカードが認識されているのに（nvidia-smiで確認）ダメです。
現在エラーになっているハードディスクのチェックが終了するまで、メンテナンス作業（再度ドライバーをアンインストールするなど）はできません。
さらに別の問題ですが、OS内部で同期されるはずのいくつかのパラメーターが正しく同期されておらず（そのせいでRCloneの新しいバージョンをqpkgでインストールできません）：QNAP - [RClone] The system volume is missing | Forum des NAS : Synology, Qnap, Asustor...
ただ、この話題は最初のテーマから逸れてしまっています。
こんにちは、
ご回答ありがとうございます。
私はNvidiaドライバーのアンインストール→QNAPサイトからカーネルドライバーを更新→ドライバーを再インストールする方法を試しました。
その後、少しOllamaをGPUで利用できました。しかしここ数日間はまったくダメで、CPUのみ（コマンド：ollama ps）、コンテナ内にカードは存在しているのに（nvidia-smiでも確認）動作しません。
現在、エラー状態のハードディスクのチェックが終わるまでメンテナンス作業（再度ドライバーをアンインストールなど）ができずにいます。
また、別の問題として、OS内部で同期されるはずのいくつかのパラメーターが正常に同期されていません（そのため、qpkgでRCloneの新しいバージョンのインストールができません）：QNAP - [RClone] The system volume is missing | Forum des NAS : Synology, Qnap, Asustor...
ただ、この話題は当初のテーマから逸れてしまいます。
こんにちは。
詳細をありがとうございます。とても参考になりました。ドライバー自体の問題ではないことが分かります。
あなたのメッセージの重要なポイントは次の通りです：nvidia-smi が コンテナ内 でカードを認識していますが、ollama ps はCPUを報告しています。この組み合わせは、ドライバーとコンテナランタイムが正常に動作していることを示しています。ドライバーやNVIDIAコンテナランタイムに問題がある場合、nvidia-smi はコンテナ内で失敗します。しかし失敗していません。カードは認識され、正しくパススルーされています。
失敗しているのは、Ollamaがモデルを読み込む際のCUDA初期化です。これはよく知られた問題で、私の環境でも発生しています。GPUがしばらくアイドル状態になると、CUDA初期化に失敗し、Ollamaは何のメッセージも出さずにCPUへ切り替えます。エラーメッセージはありません。モデルの応答はありますが、約20倍遅くなります。
ディスクチェックを待つ必要はありません。 ドライバーを再アンインストールする必要もありません。修正方法はOllamaコンテナのみ再起動することです。数秒で終わります。あなたのドライバーやパッケージ、ストレージには何も影響しません：
docker restart ollama
docker exec ollama ollama ps
再起動後、モデルを読み込み、再度 ollama ps を確認してください。PROCESSOR列がGPUを表示するようになれば、私と同じ問題であり、この方法がワークアラウンドとなります。もしまだCPU表示の場合は、異なる問題なので、その情報も重要です。
タイムラインもこのことを示しています。ドライバー再インストール後は動作し、その数日後に問題が発生しています。ドライバーのインストールが壊れていれば、すぐに、そして毎回失敗します。最初は正常で後から劣化することはありません。
この問題を予防するには、Ollamaコンテナの環境変数に OLLAMA_KEEP_ALIVE=24h を設定してください。これによってモデルがVRAMに常駐し、アイドル状態での失敗を防げます。
最後に一点、敬意をもって申し上げます。ハードディスクにエラーやシステムボリュームの消失があるとのことですが、それはGPUの問題よりも深刻です。まずディスクとシステムボリュームの修復をおすすめします。NVIDIAドライバーはQPKGパッケージとしてインストールされており、システムボリュームの破損はパッケージシステムにも影響します。ストレージ層が不健康な状態ではGPU問題の診断も困難になります。
コンテナ再起動後の ollama ps の結果をぜひお知らせください。
Container Stationからコンテナを何度も再起動しましたが、最適な動作（CPUではなくGPUだけ）が戻ることはありませんでした。多くの場合、NASを再起動することでモデルが再びGPUで動作するようになりました。
いずれにしても、その後、これらの累積的な問題（QuTS hero 6ベータ版の使用や、サポートと一緒にシステムプールをホットランニング状態で再作成したことに関連している可能性があります）を解決するために、NASのリセットとファームウェアの適切な再インストールを検討しています。
achimede333さん、
この件で問題が発生しているとのこと、申し訳ありません。実はあなたがRAGと4000 Blackwellについて最初に投稿されたのがきっかけで、自分でもローカルでRAGを試してみようと思いました。まだQwenを細かく調整中ですが、今のところトレードオフは想像以上に遅いものの、プライバシーは保たれています。
サーバー監視に使っているダッシュボードは自作です。すべてのコンテナやサービスの状態も監視できるし、管理（起動・停止・ステータス・無視（特殊用途））もできます。container stationは使っていません。自分でDocker Composeファイルを全部作成して、それでコンテナを立ち上げています。
下のスナップショットは全ウィジェットを表示した状態です。見えないですが、組み込んだエラー報告機能もたくさんあります。NASを購入してからずっとメモリ問題（MCEエラー）に悩まされてきましたが、ついにマザーボードのメモリコントローラーが原因だと特定されました。明日修理に出す予定です。この問題による予期しない再起動が頻発したため、NASの状態を一目で把握できる方法を開発しなければなりませんでした。それがダッシュボードを作った経緯ですが、今では毎日NASの監視やコンテナ・ネットワーク障害の早期発見に使っています。
もう一つ学んだことですが、TVS-AIH1688ATXで使われているatlanticチップのNICドライバーは、alantic社からMarvell社に引き継がれ、元のgitHubリポジトリは放棄されてしまいました。現在誰がドライバーを保守しているのか分かりませんが、メモリ問題とは無関係な再起動を2回引き起こした問題にも遭遇しています。
経験則：重要な作業中にNICドライバー設定を変更しないこと。自分の場合、再起動のリスクは五分五分でした。Ring-resize（リングサイズ変更）は毎回再起動につながります。NICがパケットを落とす現象も追跡しています。Network欄をよく見ると、自分のトラッカーで192個のパケットドロップが表示されています。これが現時点での基準値で、増え始めたらネットワーク接続をリセットする必要があります。マザーボードを冷却すると効果があるようなので、ケースファンは常に55%、CPUファンは50%で回しています。
発見したことはその都度報告していますし、QNAPがバグ修正に取り組んでいると信じていますが、時々大変です。ベータ版ファームウェア運用の醍醐味でもありますね 
はい、あなたが他の会話に参加していたことに気づいていましたし、RTX Pro 4000をお持ちなのも知っていたので、私みたいに飛び込んでみたのかなって思ってました 
私はOllamaをOpen WebUIをインターフェースとしてテスト中で、Gemma 4からQwen3.6に切り替えて試しています。
要素を細かく調整するのには時間がかかりますし、そのうえ他にも管理しなきゃいけないことがたくさんあります。だからパイロット版の不便さが本当にイライラして、時間を無駄にしちゃうんですよね（llama.cppに切り替えようか迷ってますが、さらに時間がかかるし…でもパフォーマンスは良くなるはず）。
あなたのインターフェース、すごく良いですね。それと、NASのメモリ問題を突き止められたのも素晴らしいです。
今はSeagateの28Tを使っていて、SMARTがアラートを出してます…あまり古くないので、とりあえずスキャン結果を待ってみて、新しいファームウェアで何か変わるか見て、それでもダメならRMAですね…
ネットワークインターフェースに関するフィードバックもありがとうございます。あなたが報告している問題、確かに厄介ですね。
今のところ、私のNASには特に問題は感じていません。ただ、RAMのスロット全部は使っていません（高すぎる :P、今は必要ないので）。