Radeon 780M 向けローカル LLM on 山村商店

【780M向け】llama.cpp Vulkan更新：RDNA2のFlash Attention速度改善と780M向け最適化

Tue, 20 Oct 2026 11:35:21 +0000

llama.cpp は ggml-org が開発する C/C++ の LLM 推論エンジン。Vulkan バックエンドで AMD iGPU でも動く。

今回の要点

RDNA2 (RX 6600 XT等) の Flash Attention が大幅に高速化：共有メモリの制限チェックを回避し、Wave32 実行を有効化。
Radeon 780M 等の帯域幅制限 GPU で推論速度が向上：RMS Norm の処理を共有メモリ経由に変更し、メモリトラフィックを削減。
長文コンテキスト (YaRN) が Vulkan で利用可能に：切り捨て設定 (truncation config) のサポートが追加され、コンテキスト長の有効活用が可能に。
マルチGPU構成時の注意：GPU の接続順序や優先度設定が、プロンプト処理速度 (PP) に深刻な影響を与える不具合が報告されている。

Vulkan RDNA2 Flash Attentionの重大なボトルネック解消とWave32有効化

前提

Flash Attention は、Attention 機構の計算効率を高める手法だが、GPU の共有メモリ (shmem) やレジスタ使用量に厳しい制約がある。特に AMD RDNA2 アーキテクチャでは、ドライバーの仕様チェックが最適化を阻害し、速度低下を招く場合があった。

何が変わったか

llama.cpp において、RDNA2 デバイスにおける Flash Attention のボトルネックを解消する修正が行われた。具体的には、共有メモリのサイズ制限チェックを回避し、ネイティブな Wave32 サブグループ実行を有効化する変更が適用された。これにより、レジスタ圧力の軽減とメモリスパイリングの削減が図られている。

なぜ重要か

RX 6600 XT などの RDNA2 アーキテクチャを搭載する AMD GPU ユーザーにとって、特にシーケンスコンテキストが長い場合 (n ≥ 4500 など) に顕著だった速度低下が解消される。これにより、iGPU でもより長いコンテキストを扱えるようになる。

根拠のリンク

利用者の報告

logankidd315-design 氏は、Windows 環境上の RX 6600 XT (RDNA2) で、Vulkan バックエンド使用時に Yue2 3b などのモデルで大きなコンテキスト処理時の深刻なパフォーマンス低下を報告し、本修正がその原因である特定と解決策を提示した。同氏は、厳格なドライバープロパティチェックの失敗によるキャッシュスラッシングと、大規模コンテキストでのレジスタ圧力による VGPR メモリスパイリングが主要因だと指摘している。

Vulkan RMS Normの共有メモリ最適化でiGPU帯域幅ボトルネックを緩和

前提

RMS Norm (Root Mean Square Layer Normalization) は LLM における正規化処理の一つ。通常、グローバルメモリ (VRAM) とのアクセスが発生するが、共有メモリ (高速だが容量が限られる) を経由することで処理効率を上げられる。

何が変わったか

RMS Norm の部分和計算 (partial sums) を、グローバルメモリではなく共有メモリを通じて行う最適化が Vulkan バックエンドに導入された。これにより、GPU 間のメモリトラフィックが削減される。

なぜ重要か

Radeon 780M などの iGPU は、独立型 GPU に比べてメモリ帯域幅が制限されている。この最適化により、帯域幅がボトルネックになりやすい環境でも、推論速度の向上が期待できる。

根拠のリンク

vulkan: reduce rms_norm partial sums through shared memory (#30826)

Vulkan Adreno互換コンパイル不具合修正とRADVへの波及

前提

llama.cpp の Vulkan バックエンドは、Qualcomm Adreno GPU 向けのコンパイル最適化を含んでいる。一部の Adreno GPU では、特定のビット幅のベクターパック/アンパック処理でコンパイル不具合 (miscompile) が発生していた。

何が変わったか

Adreno GPU でのコンパイル不具合を回避するため、大規模なヘッドを持つ場合のスカラー Flash Attention の行数制限 (8行まで) や、8-bit ベクターパック/アンパック処理の回避といった修正が行われた。

なぜ重要か

本来は Adreno 向けの修正だが、同様のコンパイラの問題が AMD の RADV ドライバー環境でも発生する可能性がある。この修正により、RADV 環境における安定性や互換性も間接的に改善する可能性がある。

根拠のリンク

VulkanバックエンドでYaRN切り捨て設定をサポートし長文コンテキスト対応

前提

YaRN (Yet another RoPE extensioN) は、LLM のコンテキスト長を拡張する技術。ただし、無限にコンテキストを延ばすと計算コストが増大するため、重要な情報を保持しつつ不要な部分を切り捨てる (truncation) 設定が有用な場合がある。

何が変わったか

Vulkan、OpenVINO、SYCL、WebGPU、RPC などのバックエンドにおいて、YaRN の切り捨て設定 (truncation config) のサポートが追加された。これにより、Vulkan 環境でもコンテキストの切り捨て制御が可能になった。

なぜ重要か

Radeon 780M などの iGPU ユーザーにとって、長文コンテキストを有効活用しつつ、メモリや計算リソースの制約を管理できるようになる。特に、VRAM が限られる環境での長文処理の柔軟性が向上する。

根拠のリンク

ggml: support YaRN truncation config on openvino, sycl, vulkan, webgpu, rpc (#30802)

Vulkan環境でのGPUデバイス順序が推論性能に影響する不具合

前提

複数の GPU を搭載した PC では、どの GPU を推論に使用するかを指定する必要がある。Vulkan バックエンドでは、システム内の GPU デバイスの順序や優先度設定が、推論パフォーマンスに影響を与える可能性がある。

何が変わったか

GPU デバイスの順序が、プロンプト処理 (PP: Prompt Processing) のパフォーマンスに深刻な影響を与える不具合が報告されている。特に、メインの GPU 以外をディスプレイ出力用に設定した場合など、意図しない順序でデバイスが選択されると速度が大幅に低下する。

なぜ重要か

マルチ GPU 構成や、統合 GPU と独立 GPU を併用する環境において、意図した GPU が正しく選択されないまま推論が実行されると、パフォーマンスが著しく低下する可能性がある。ユーザーは、デバイス順序や指定方法に注意する必要がある。

根拠のリンク

Vulkan GPU device ordering affects PP performance (#30841)

利用者の報告

AlexGidarakos 氏は、Debian 13 環境で、メインの GPU 以外をプライマリディスプレイアダプタとして設定したところ、Vulkan を使用した Qwen MoE モデルの推論速度が深刻な低下を示したと報告している。この現象は、最新のビルド (b11738) および旧ビルド (v0.2.0) の両方で再現しており、明示的に強い GPU を指定しても、デバイス順序の影響でパフォーマンスが損なわれる可能性がある。

出典

【780M向け】Mesa 26.2.5のRADVクラッシュ修正と、780MでのVulkan GDNハング回避・Qwen4exp最適化

Mon, 19 Oct 2026 11:34:33 +0000

今回の要点

Mesa 26.2.5でRADVの既知のクラッシュ（nir_opt_varyings）とレイトレーシング不具合が修正された。
gfx1103（780M）でVulkan GDNモデル使用時、CPU 100%ハングする不具合が報告されている。
Qwen4expモデル向けにシェーダーディスパッチを削減するFused Kernelが統合された。
常時稼働環境向けに、アイドル時にVulkanデバイスが消失する問題を防ぐKeepalive機能が追加された。

Mesa 26.2.5によるRADVクラッシュと780Mへの影響

Linuxのグラフィックスライブラリ「Mesa」は、VulkanドライバーRADVを通じてAMD内蔵GPU（iGPU）の性能を制御している。最新のMesa 26.2系では、最適化処理の過程でRADVがクラッシュする既知のバグが存在し、RDNA3以降のアーキテクチャを含むAMD iGPU環境に影響が及んでいた。

2026年10月19日にリリースされたMesa 26.2.5では、このクラッシュの原因となる「nir_opt_varyings」最適化パスに関連する問題への対策が含まれている。これにより、RADV搭載のRadeon 780Mなどでも、推論エンジン起動時の安定性が向上する可能性がある。また、同リリースではレイトレーシングの信頼性向上や浮動小数点精度の修正も実施されており、Vulkanドライバー全体の安定性が改善されている。

この変更は、Vulkan経由でローカルLLMを動作させるユーザーにとって、ドライバーレベルでの予期せぬクラッシュリスクを低減する重要な修正である。

出典: Mesa 26.2.5 released TODAY (Oct 19)
出典: RADV nir_opt_varyings crash on Mesa 26.2+
出典: Mesa 26.2.5: RADV ray-tracing/FP/race condition fixes

gfx1103 (780M) でのVulkan GDNパイプラインハング

llama.cppのVulkanバックエンドを使用する際、特定のモデルアーキテクチャ（GDN: Gated Delta Network）において、gfx1103（Radeon 780M）上で処理が完全に停止する現象が報告されている。

この不具合は、モデル読み込み時（load_model）にCPU使用率が100%になり、その後も処理が進まない状態（ハング）を引き起こす。具体的には、ヘッドサイズ128のGDNパイプラインがgfx1103のVulkanドライバーと互換性を持たないことが原因と推測されている。ただし、同じ780M環境でも、より小さなGDNモデル（Qwen3.6-35B-A3Bなど）を使用する場合は正常に動作するため、モデルの特定のパラメータや構造に起因する問題である。

この問題は、780M搭載機でGDNアーキテクチャのモデルをVulkan経由で実行するユーザーに影響する。回避策としては、異なるモデルサイズの使用や、ドライバー/エンジン側の修正待ちが考えられる。

出典: llama.cpp #27998: Vulkan GDN pipeline hang on gfx1103 (RADV 780M)

Vulkan Qwen4exp用Fused Kernel統合による性能向上

llama.cppでは、Qwen4expアーキテクチャのモデル推論を最適化するFused Kernelの統合が進められている。これは、複数の計算ステップ（SCALE→SIGMOID→SCALE→hc_post）を単一のVulkanカーネルに統合し、シェーダーディスパッチのオーバーヘッドを削減する技術である。

2026年9月28日にマージされたPR#29520、および2026年10月19日時点でのPR#30602により、この最適化が適用された。これにより、AMD iGPU上でもメモリ転送の削減と推論レイテンシの低下が期待できる。特にQwen3.8-Flash-NextなどのQwen4exp系モデルを使用する場合、Vulkanバックエンドでのパフォーマンス向上に寄与する。

Vulkanデバイス保持機能でアイドル時消失を防ぐ

常時稼働するAMD iGPUサーバー（ミニPCなど）において、アイドル状態時にVulkanデバイスが「消失（device lost）」する問題への対策がllama.cppに追加された。これは、GPUが省電力モードなどに遷移した際、ドライバーがデバイスを無効化してしまうことが原因で、推論セッションが予期せず終了する要因となっていた。

PR#29267およびPR#30664により、Vulkanデバイスを保持するオプション機能が導入された。これにより、アイドル時でもデバイスが消失せず、常時稼働環境での推論ノードとしての安定性が向上する。mini-PCなどで24時間稼働させるユーザーにとって、重要な安定化修正である。

出典: ggml-vulkan: add optional device keepalive
出典: llama.cpp #30664: Vulkan keepalive device

Vulkan量子化K/V用スパースFlash Attention

llama.cppのVulkanバックエンドにおいて、量子化されたK/V（Key/Value）キャッシュを用いたスパースFlash Attentionの実装が進められている。これは、単一ヘッドで量子化されたKデータを用い、Vulkan上でMMQ（Multi-Matrix Multiplication）演算を最適化する技術である。

この最適化（コミットb3daa07）により、メモリ帯域の効率的な利用と推論速度の向上が期待できる。特に、VRAMが限られるAMD iGPU環境において、長文コンテキストの処理効率を高める可能性がある。

出典: llama.cpp: Vulkan sparse flash attention for quantized K/V (Baked commit)

出典

【780M向け】llama.cpp Vulkanバックエンドの重大な性能劣化と780M環境での必須設定

Sun, 18 Oct 2026 11:33:58 +0000

今回の要点

Vulkan draft-MTP推論の大幅性能劣化: 最新のVulkanバックエンド変更により、推論速度が最大6倍低下する回帰（regression）が報告されている。
780M環境での必須ワークアラウンド: AMD Radeon 780M (gfx1103) ユーザーは、ROCmの代わりにVulkan (RADV PHOENIX) を使用し、VRAM認識を回避する設定が推奨される。
MoE推論時のクラッシュ対策: MoE（Mixture of Experts）モデルのVulkan推論では、キャッシュ設定の調整が必要であり、未調整だとロード時にクラッシュする。
Qwenモデルの最適化: Qwen系モデル利用時のVulkan推論速度を改善する高速化パッチが進行中。

Vulkan draft-MTP推論の大幅性能劣化とMellum2/Vulkan崩壊

今回の話題を理解するには、llama.cppにおける「draft-MTP（Multi-Token Prediction）」という推論モードの仕組みを知る必要がある。これは、モデルが生成した複数の候補トークンを一度に検証することで推論速度を向上させる技術であり、AMD iGPUユーザーにとって高速化の要となる機能だ。

しかし、最近のVulkanバックエンド変更により、このdraft-MTP推論において深刻な性能劣化が発生している。具体的には、デコード処理が約4倍、プリフィル処理が約6倍も遅くなったという報告が上がっている。これは、ターゲット計算バッファがGTT（Graphics Translation Table）に再割り当てされたことが原因とみられている。

この問題は、Vulkanを使用するすべてのAMDユーザーに影響する。特に、複数のGPUデバイスがシステムに存在する環境や、大きなコンテキストサイズ（例: 196608）を指定して推論を行う場合、スループットがメモリの帯域幅レベルまで低下する。ただし、コンテキストサイズを小さく（例: 8192）設定すれば、この劣化は発生しないという特性も確認されている。

この問題の根拠は、以下のGitHub Issueで報告されている。

利用者の報告

この性能劣化は、複数の環境で再現・検証されている。

snick525 による報告: AMD Radeon AI PRO R9700 (RDNA4) 2枚構成、Linux 7.2.5、Mesa RADV 26.2.2の環境で、v0.7.0のVulkanバックエンド使用時にdraft-MTP推論が大幅に遅くなったと報告。Issue #30688
cennac による報告: 複数のVulkanデバイスが_visible_ なシステムで、大きなコンテキスト（-c 196608）と推論デコード（ngram-map + draft-mtp）を使用すると、スループットが約3倍低下すると報告。_GGML_VK_VISIBLE_DEVICES_ で計算用GPUのみを指定することで回復を確認。Issue #30695
tczank による報告: AMD RX 7900 XTX (RDNA3) 環境で、masterブランチと9月26日のビルドを比較し、draft-MTPパスが約10〜13%遅くなったと報告。キャッシュ再利用（_--cache-reuse_）を有効にすると、さらに受容率の不安定さも確認。Issue #30638

780M必須設定：mmap回避とMoE/Vulkanクラッシュ対策

AMD Ryzen 内蔵GPU（Radeon 780M / gfx1103）を使用する場合、ROCmバックエンドは正式サポート外であり、クラッシュやパフォーマンス問題を引き起こしやすい。そのため、Vulkanバックエンド（Mesa RADV PHOENIX）への切り替えが推奨される。これにより、VRAM認識の問題を回避し、より安定した動作が期待できる。

また、MoE（Mixture of Experts）モデルをVulkanで推論する場合、_--moe-cache-mib_ などのキャッシュ設定を誤ると、モデルロード時にクラッシュする可能性がある。これは、キャッシュスロットのサイズ計算がバックエンドの制限を超えてしまい、GPUメモリ割り当てに失敗することが原因とみられている。

この問題は、以下のGitHub Issueで報告されている。

利用者の報告

MoE推論時のクラッシュは、以下の環境で報告されている。

TheColetrain による報告: Windows 11、AMD Radeon RX 6900 XT (gfx1030)、公式Windows x64 Vulkanリリースzip使用。_--moe-cache-mib 8000_ を指定してQwen3.6-35B-A3Bモデルをロードしようとすると、_pre-allocated tensor_ に関するエラーでクラッシュ。Issue #30697
qiyuhuating による報告: 上記クラッシュの原因として、MoEキャッシュスロットのサイズ計算がバックエンドの制限を超えている可能性を指摘。キャッシュ容量を保守的に減らすことで解決する可能性がある。Issue #30697 Comment

Vulkan Q4_0高速化とQwenモデル用Tiled-Transpose最適化

Qwen系モデル（Qwen 3.5/4など）をVulkanで推論する場合、Tiled-Transpose Concatシェーダーの最適化により、推論速度が改善される可能性がある。また、Q4_0量子化KVキャッシュに対する高速なデクアンタイズ・トランスポーズパスも追加されており、特に古いGPU（GCN1など）でのパフォーマンス向上が期待できる。

これらの改善は、以下のGitHub Pull Requestで進行中。

780M実測ベンチ：Qwen3.6 35B 19.7t/s、Gemma 4 26B 25t/s

2026年10月15日時点での780M（Vulkanバックエンド）の実測ベンチマークによると、Qwen3.6 35B A3B（Q8_0）で約19.7 t/s、Gemma 4 26B-A4B（Q4_K_M）で約25 t/sの生成速度が記録されている。また、MoEモデルをCPUで推論する場合、DenseモデルをGPUで推論するよりも高速になる場合があるため、環境に応じた最適な設定が求められる。

詳細なベンチマークデータは、以下のサイトで確認できる。

Vulkanデバッグラベル追加とGPUメモリ関連バグ修正

Vulkanバックエンドのプロファイリング環境が改善されている。コマンドバッファにデバッグラベルが追加され、GPUプロファイリングツールでの解析が容易になった。また、整数Dot Productのバグ修正や、スクラッチバッファシステムの導入により、デクアンタイズ処理の速度向上が期待できる。

関連するPull Requestは以下の通り。

出典

【780M向け】Radeon 780Mの推論速度を左右するVulkan最適化2件とStrix Haloの速度低下不具合

Thu, 15 Oct 2026 20:38:07 +0000

この記事はAIによって編集・作成されています。

【780M向け】Radeon 780MのVulkan推論を安定・高速化するメモリ整合性修正とRDNA3最適化

Wed, 14 Oct 2026 20:39:04 +0000

この記事はAIによって編集・作成されています。

【780M向け】Strix Halo での推論崩れ修正と RDNA3/4 向け最適化：llama.cpp Vulkan 更新

Mon, 12 Oct 2026 20:34:22 +0000

この記事はAIによって編集・作成されています。

【780M向け】Radeon 780M実測: Vulkanバックエンドの高速化、性能回帰の回避策、Ollamaの検出不具合

Sun, 11 Oct 2026 20:36:55 +0000

この記事はAIによって編集・作成されています。

【780M向け】llama.cpp Vulkanバックエンドの修正：ワークグループオーバーフロー回避とFlash Attentionの最適化

Sat, 10 Oct 2026 20:35:53 +0000

この記事はAIによって編集・作成されています。

【780M向け】llama.cpp Vulkan: Intel WindowsのVRAM認識不具合修正とCM2/デルタネット対応

Fri, 09 Oct 2026 20:36:38 +0000

この記事はAIによって編集・作成されています。

【780M向け】Radeon 780M向けVulkan最適化：VRAMリーク修正、Sparse FlashAttention対応、MoE処理の高速化

Thu, 08 Oct 2026 20:39:02 +0000

この記事はAIによって編集・作成されています。

llama.cppはggml-orgが開発するC/C++のLLM推論エンジンで、VulkanバックエンドによりAMD iGPUでも動作します。今回の更新では、Radeon 780M (gfx1103) を含むAMD iGPU環境における推論速度の向上、VRAMリークの修正、および長文コンテキストやMoEモデルでの処理効率化が複数行われています。

今回の要点

VRAMリーク修正: 1万トークン以上の生成後にGPUがアイドル状態になる不具合が修正されました。
Sparse FlashAttention対応: 長文コンテキスト推論時のコスト削減のため、coopmat2経由でSparse FAが利用可能になりました。
MoE処理の最適化: 不要な計算を削減するため、MUL_MAT_IDの重複処理と密度ゲートが最適化されました。
小規模行列演算の効率化: ワークグループリソースの使用を削減し、iGPUでの競合を緩和する最適化が行われました。
ワークグループ制限の回避: maxComputeWorkGroupCount超過時の行列演算分割により、起動失敗が防止されました。

780M向けVulkan最適化と不具合修正

Radeon 780M (gfx1103) などのAMD iGPU向けに、RMSNormの融合、GET_ROWSの型アライメント、f16アキュムレータベクトルパスの導入など、推論速度向上のための最適化が行われました。また、RDNA4におけるプレフィルの回帰問題も修正されています。

特に重要なのは、VRAMリークの修正です。従来、780M環境で1万トークン以上の生成を行うとGPUが90〜92°Cまで加熱し、その後にアイドル状態になるという不具合が発生していましたが、これが解消されました。これにより、長時間の推論における安定性が大幅に向上します。

さらに、AMD iGPUにおけるチェックポイント読み込みの低速化も修正されました https://github.com/ggml-org/llama.cpp/commit/4d756bc7。MUL_MAT_IDにおけるFP32ソース精度の尊重も修正されており、精度面での改善が期待できます https://github.com/ggml-org/llama.cpp/pull/30105。

利用者の報告

Skimmenthal13 氏は、Radeon 780M (gfx1103)、RADVドライバー、Mesa 26.2.4、CachyOS (kernel 7.2.8) の環境で、GLM-4.7-Flash Q4_K_Mモデルを用いたテストを行っています。コンテキストが長くなるにつれてトークン生成速度が低下する問題（Issue #19081）を報告しており、Flash Attentionの最適化による改善が期待されています https://github.com/ggml-org/llama.cpp/issues/29965。

Paco1960 氏は、Linux Mint 22.3、Radeon 780M Graphics (Phoenix / gfx1103)、Vulkan / Mesa RADV、Mesa 25.2.8、Vulkan API 1.3.275の環境で、Unsloth Studioを用いたGGUF推論テストを行っています。VulkanはGPUを正しく検出しますが、VRAM割り当て時に ErrorOutOfDeviceMemory で失敗するという報告があります https://github.com/unslothai/unsloth/issues/12695。

thevaprroomops-cmyk 氏は、Windows 11、AMD Radeon RX 9070 XT (RDNA4) および統合GPU (AMD Radeon(TM) Graphics) の環境で、Hermes Agent v0.21.5+3903 におけるVulkanビルドの性能比較を行っています。LM StudioのVulkanビルドが約30.5 tok/sであるのに対し、Hermesのビルドは約7.4–8.0 tok/sと約4倍の差があり、GPUオフロードが速度向上に繋がっていないという報告があります https://github.com/NousResearch/hermes-agent/issues/133259。

VulkanバックエンドにSparse FlashAttention（coopmat2）対応

長文コンテキスト推論におけるコスト削減のため、VulkanバックエンドにSparse FlashAttentionのサポートが追加されました。特にgfx1103 (RDNA3) iGPUにとって有効な最適化です。

この機能は、coopmat2経由でSparse FAのサポートが拡張される形で実装されています https://github.com/ggml-org/llama.cpp/pull/30003。これにより、長いコンテキストを扱う際の計算コストを削減し、推論効率を改善することが可能になります。

MoE推論のMUL_MAT_ID重複処理と密度ゲート最適化

MoE (Mixture of Experts) モデルにおける推論効率の改善のため、MUL_MAT_IDの重複処理と密度ゲートの最適化が行われました。従来、ループ処理されていたMoE expertの重複処理がprepassに移行され、不要な計算が削減されました https://github.com/ggml-org/llama.cpp/pull/29998。

また、MUL_MAT_VEC_IDパスにおいて密度ゲートが使用されるようになり、AMD Vulkan環境でのMoE expert選択が最適化されました https://github.com/ggml-org/llama.cpp/pull/27332。これらの変更により、iGPUにおけるMoEモデルの推論パフォーマンスが向上することが期待されます。

利用者の報告

小規模行列演算のWarp最適化でiGPUリソース競合を緩和

計算ユニットが限られるiGPU向けに、小規模行列演算 (small matmul) のワークグループリソース使用量が削減されました。具体的には、小規模な行列演算タイルにおいて、1つのサブグループにつき1つのwarpタイルを使用するよう最適化されています https://github.com/ggml-org/llama.cpp/pull/30106。

AMD iGPUはワークグループ数が比較的小さいため、この最適化によりリソース競合を緩和し、推論効率を改善することが期待されます。

利用者の報告

maxComputeWorkGroupCount超過時の行列演算分割対応

ワークグループ制限の小さいiGPUにおいて、行列演算ディスパッチが maxComputeWorkGroupCount を超過する場合、演算を分割する対応が行われました https://github.com/ggml-org/llama.cpp/pull/29533。

これにより、ワークグループ数の制限が小さいiGPU環境での起動失敗が防止され、推論の安定性が向上します。

利用者の報告

出典

【780M向け】Radeon 780MのTTFTを数倍改善、長文推論のクラッシュも修正されたllama.cpp Vulkanバックエンドの最新動向

Wed, 07 Oct 2026 20:38:32 +0000

この記事はAIによって編集・作成されています。