[AINews] Good Friday｜【AIニュース】グッドフライデー | AIニュース最前線

昨日も取り上げましたが、Gemma に関する肯定的なレビューが次々と届いています。 Marc Andreesen のポッドキャストからの初期分析では、すでにこれが史上最高の Latent Space ポッドキャストの一つである可能性を示唆しています。来週ロンドンから、OpenClaw と Pi（およびその他多くの欧州発のトップ AI ツール）のクリエイターたちがライブで登壇します。AIE Europe 来週のライブストリームリンクは公開済みです。素晴らしい OpenClaw の楽曲も含まれています。アルゴリズムでのプロモーションを支援するため、ベルアイコンを押してフォローしてください。ありがとうございます！ 2026 年 4 月 3 日〜4 月 4 日の AI ニュース。12 のサブレッドと 544 件の Twitter を確認し、Discord はさらに調査しません。AINews のウェブサイトでは過去のすべての号を検索できます。念のため、AINews は現在 Latent Space のセクションの一部となっています。メール配信頻度の設定をオン/オフできます！ AI Twitter リキャップ Gemma 4 の Apache ライセンス付きリリース、ローカル推論パフォーマンス、および Day-0 エコシステムサポート Gemma 4 は今日の決定的なオープンモデルリリースです：Google は Gemma 4 を Apache 2.0 の下でリリースし、複数の投稿がその推論、エージェントワークフロー、マルチモーダル性、そしてオンデバイス利用に向けたポジショニングを強調しています。@fchollet はこれを Google がこれまでに出した中で最も強力なオープンモデルと呼び、KerasHub での JAX バックエンドの使用を推奨しました；@demishassabis は効率性を強調し、Gemma 4 が Google のチャート上で 10 倍大きいモデルよりも優れていると主張しました。コミュニティの反応はライセンス変更を中心に展開され、@ClementDelangue、@QuixiAI、@googlegemma はいずれも、これが広範な下流利用を可能にする「本物の」オープンウェイトリリースであると強調しました。 エコシステムは通常とは異なり、0 日目からすでに準備が整っていました：vLLM（GPU、TPU、XPU を同時にサポート）、llama.cpp (@ggerganov)、Ollama（新モデル利用可能）、Intel ハードウェア（Xeon、Xe GPU、Core Ultra）、Unsloth（ローカル実行/ファインチューニング対応）、Hugging Face Inference Endpoints（ワンクリックデプロイ）、そして AI Studio / Google AI Studio の資料（記事リンク）において、サポートが即座に提供されました。アーキテクチャ志向の読者向けには、@osanseviero と @MaartenGr が、MoE 設計、ビジョン/オーディオエンコーダー、層ごとの埋め込みを網羅した詳細なビジュアルガイドを共有しました。 ローカル推論ベンチマークが主要な実用的な話題となりました：複数のビルダーが、特に 26B A4B MoE に注目を集めながら、コンシューマー向けハードウェア上で Gemma 4 を実行している様子を示しました。@basecampbernie は単一の RTX 4090 で 19.5 GB の VRAM を使用し、デコード速度 162 tok/s、ネイティブコンテキスト 262K を達成したと報告しました。一方、@Prince_Canuma は TurboQuant KV キャッシュ（キャッシュ）により、31B モデルの 128K コンテキストでのメモリ使用量を 13.3 GB から 4.9 GB に削減しましたが、デコード速度に若干のペナルティが生じたと示しました。また、より性能の低いローカルデバイスでの例もありました：@measure_plan は 16 GB の Mac mini M4 で 26B-A4B を 34 tok/s で実行したと報告し、@kimmonismus は E4B タイプが有用な AI を直接スマートフォンやラップトップに持ち込むものだと主張しました。さらに @anemll は Swift MLX を用いてこのモデルを iPhone に搭載することに成功しました。 初期のベンチマークに関する議論は肯定的ではあったが、無批判なものではなかった：@arena は、同程度のパラメータ規模において Gemma 3 および 2 を大幅に上回るランキング向上を指摘し、単純なスケーリングを超えた進展を示唆した。その後、@arena は Gemma 4 31B が同価格帯のモデルに対してパレートフロンティア（最適解の集合）上に位置すると述べた。一部のユーザーは発表方法について異議を唱え、@stochasticchasm は比較がより明確に FLOP（浮動小数点演算回数）やアクティブパラメータで正規化されるべきだと主張し、@reach_vb は分野全体がデフォルトスコアとして Arena Elo から脱却するよう求めた。 Hermes Agent の急速な普及、メモリ・プラグインアーキテクチャ、そして「ハルネスの重要性」への転換 Hermes Agent は今日の注目すべきオープンソースエージェントハルネス（実装基盤）となっているようだ。多くの開発者の報告によると、OpenClaw/Openclaw から Hermes へ移行し、長期タスクにおいてより安定しているか、あるいはより能力が高いと評価されている。具体例として @Zeneca、@Everlier、@erick_lindberg_、@AnomalistG が挙げられる。@supernovajunn による詳細な韓国語のスレッドは、この議論を明確に要約した：優位性はモデルそのものだけでなく、ハルネスと学習ループの組み合わせにある。特に重要なのは、自律的なスキル作成、再利用可能な手続的メモリ（procedural memory）、そして実務タスクにおけるより高い信頼性の基盤である。 Nous は単なる hype ではなく、意味のあるインフラストラクチャを提供しました：@Teknium は、Honcho、mem0、Hindsight、RetainDB、Byterover、OpenVikingAI、Vectorize スタイルのバックエンドをサポートする再設計されたプラグ可能（pluggable）なメモリシステムを発表しました。続報ではアーキテクチャの整理が詳細に説明され、メモリプロバイダーは専用のプラグインタイプとなり、コア部分は保守性が向上し、ユーザーも独自のプロバイダーをより容易に追加できるようになりました（詳細）。Hermes ではまた、TUI におけるインライン差分表示（post）や、アカウント/キー間で切り替えるためのプロバイダー認証情報プールが追加されました（post）。 大きなテーマは、エージェントのパフォーマンスがもはやハーンエンジニアリングの問題になっているという点です：@Vtrivedy10 は「モデル・ハーン学習ループ」を説明し、チームがハーンエンジニアリング、トレース収集、分析、ファインチューニングを組み合わせてドメイン固有の最前線パフォーマンスを構築すると述べています。関連するツイートでは、彼は主要な原材料は大量のトレースデータであり、エージェントによって失敗モードが発見され、トレーニングやハーンの改善に転換されると主張しました（トレースループ）。これは Hermes の人気と相まって、オープンモデルがすでに「十分良い」状態にあるなら、より優れたメモリ、ツール、評価、自己改善ループがアプリケーションの品質を支配するようになる可能性があります。 また、クローズドな製品シェルではなくオープンなハーンへの明確な需要も存在します：@michael_chomsky は Anthropic が Claude Code をオープンソース化するべきだと主張し、その理由として 2025 年は「中途半端なハーンの年」だったと指摘しました。@hwchase17 はメモリの観点から明確に述べ、メモリは専有 API や専有ハーンに閉じ込められたままではいけないと強調しました。 コーディングエージェント、レート制限、そして並列エージェント作業における認知のボトルネック 最も強いユーザーの感情は、モデルの純粋な知能（IQ）に関するものではなく、運用上の摩擦についてのものでした。@gdb は Codex を職場で試す際のハードルを下げ、事前のコミットメントを不要にしたことで貢献し、その後、Codex アプリが非常に急速に成長していると述べています（投稿）。しかし同時に、Claude Code のレート制限に関する議論は激しくなっており、@theo は「Claude Code のレート制限について話し合う必要がある」と発言しました。これを受け、@kimmonismus や @cto_junior からのフォローアップユーザーの苦情により、ユーザーが予想よりも早く利用上限に達していることが示唆されています。 新たな傾向として、計算資源の不足だけでなく認知飽和（cognitive saturation）が問題視されています。最も反応の多かった技術的なツイートの一つは、@lennysan が @simonw を引用したもので、「コーディングエージェントを効果的に活用するには、シニアエンジニアとしての経験のすべてが必要であり、午前中のある時点で並列で 4 つのエージェントをオーケストレーションすることは精神的に疲弊する」という内容でした。この見解は他の場所でも示されており、@kylebrussell は検証作業のために多数のブラウザタブを駆動できる Claude Code の能力を称賛しましたが、その後、スケーリングが「奇妙な」状態になり、自分の脳にとって 2〜4 セッションが最適だと指摘しています（投稿）。 開発者たちは、コンテキストと観測可能性を外部化することで適応しています。@jerryjliu0 は、セッション間でコンテキストを保持するためにエージェントが .md/.html 形式の成果物を出力し、ローカルビューアとして Obsidian を使用し、複雑な文書からの抽出を改善するために汎用的な PDF パーサーに代わり LiteParse を使用する実用的なセットアップを紹介しました。観測可能性の側面では、LangChain が Claude Code → LangSmith 追跡プラグッシュをリリースし、サブエージェント、ツール呼び出し、コンパクション（圧縮）、トークン使用量をログ出力するとともに、組織レベルでの分析を可能にしました（発表）。 また、「十分良好なローカルフォールバック」の重要性を示す証拠が増えています。いくつかの投稿では、Gemma 4 と Hermes をホスト型製品の摩擦に対する保険として組み合わせて紹介しています。@gregisenberg は、この程度の能力を持つモデルが現在ローカルで動作し、Claude Code、Cursor、Hermes、OpenClaw に差し替えて使用できると強調しました。@kimmonismus も同様に、16 GB のメモリを搭載した MacBook Air M4 で完全なローカルアシスタントを動作させ、API キーを必要としない点を指摘しています。 研究のシグナル：時間軸、再帰的コンテキスト管理、自己蒸留 METR スタイルの「時間軸」に関する結果は引き続き上昇傾向にあります。@LyptusResearch は METR の時間軸手法を攻撃的なサイバーセキュリティに適用し、2019 年以降で能力が約 9.8 ヶ月ごとに倍増していること、あるいは 2024 年以降のデータでは約 5.7 ヶ月ごとに倍増していることを報告しました。また、Opus 4.6 と GPT-5.3 Codex は、人間のエキスパートに約 3 時間かかるタスクで 50% の成功率を達成しています。@scaling01 からの関連するコメントでは、継続的な発展を前提とした場合、現在の METR 時間軸は約 15.2 時間、年末には約 87 時間に達すると外挿されています。 技術用語：コンテキスト (context)、観測可能性 (observability)、成果物 (artifacts)、サブエージェント (subagents)、ツール呼び出し (tool calls)、コンパクション (compaction)、トークン使用量 (token usage)、ホスト型製品 (hosted-product)、ローカルフォールバック (local fallback)、時間軸 (time horizon)、再帰的コンテキスト管理 (recursive context management)、自己蒸留 (self-distillation) 長期コンテキストの処理は、依然として活発なシステム・研究課題です：@DeepLearningAI は、MIT の研究者である Alex Zhang 氏、Tim Kraska 氏、Omar Khattab 氏が提案した再帰型言語モデル（Recursive Language Models: RLMs）を紹介しました。これは、すべての情報を単一の巨大なプロンプトに詰め込むのではなく、システムがプロンプト管理を外部環境にオフロードし、プログラム的にコンテキストを管理するというアイデアです。この考え方は実務家にも共感を呼び、@raibaggy は「RLM にワークフローを移行した後では、『ハーネス（制御装置）』を『ハーネス』の中に組み込まなければならない」と冗談めかして述べています。 ラベルや検証器なしのポストトレーニングも注目を集めました：@BoWang87 は、コーディングモデル向けに Apple が発表した Simple Self-Distillation (SSD) の結果を要約しました。これは、正誤フィルタリング、強化学習（Reinforcement Learning: RL）、または検証器を用いずに、モデル自身の出力をサンプリングしてそれらで微調整を行う手法です。引用された最も顕著な改善は Qwen3-30B-Instruct で、LiveCodeBench における pass@1 が 42.4% から 55.3% に向上し、特に困難な問題において大きな進歩が見られました。この手法が堅牢であるならば、多くのコードモデルは中核的な能力の欠如ではなく、デコーディングやポストトレーニングのギャップにより、潜在的な能力を十分に発揮できていないことを示唆しています。 さらに注目すべき研究として：@jaseweston は、訓練データ、オンポリシー報酬モデル、オンポリシー推論手法にわたる数学的対象に関する推論について 70 ページに及ぶ論文を紹介しました。また、@AnthropicAI は、オープンウェイトモデル間の振る舞いの違いを浮き彫りにするための「diff」手法を発表し、@AndrewLampinen は、訓練データから潜在的な知識を引き出して利用する方法としてテスト時の思考（test-time thinking）について議論しています。 エンタープライズおよび本番環境における AI：音声、セキュリティ、アクセス制御、そして実世界での展開 Microsoft の MAI-Transcribe-1 は、音声認識（STT）において競争力のある性能を示しています。@ArtificialAnlys 氏によると、AA-WER で 3.0% を記録し、総合ランキングで第 4 位を獲得。リアルタイム処理速度は約 69 倍に達し、25 か国語に対応可能です。Azure Speech および Foundry を通じてプレビュー版が利用可能となっています。料金は 1,000 分あたり 6 ドルと発表されています（料金に関する投稿）。 セキュリティについては、複数の本番環境の文脈で課題が浮上しました。@simonw 氏は、Axios のサプライチェーン攻撃が、開発者に対する巧妙なソーシャルエンジニアリングから始まったことをメンテナーに警告しました。@gneubig 氏は、より強力な資格情報管理、身元確認、マルウェア検出といった実践的な教訓を提示しました。一方、@thinkshiv 氏と @jerryjliu0 氏は、認証（authorization）を事後の付加物としてではなく、検索プロセス内で構造的に組み込むための Auth0 FGA と LlamaIndex を組み合わせたアプローチを共同で強調しました。 推論インフラストラクチャおよび実世界での展開については、信頼性の高い事例が提示されました。Baseten と OpenEvidence はともに臨床現場における大規模な本番利用を主張しており、OpenEvidence によると米国の医師の 40% 以上がこのシステムに依存しているとしています。また、このワークロードの推論処理は Baseten が担っています（OpenEvidence, Baseten）。サービス耐性については、@vllm_project 氏が vLLM WideEP デプロイメントにおける Ray Serve LLM の DP グループ障害許容性を強調しました。これはエンジン層での Elastic EP を補完するものです。 主要なツイート（エンゲージメント数上位で技術的関連性にフィルタリング） エージェントワークフローの疲労が第 1 の問題となりつつあります：@lennysan が引用した @simonw の、並行して複数のコーディングエージェントを使用することによる精神的コストに関する投稿は、一連の中で最も共感を呼ぶ技術的な内容でした。 エージェント向けの個人知識ベースが確立されたパターンへと進化しています：@omarsar0 は、マークダウン形式で構築され、セマンティックインデックス（意味的索引）、エージェント駆動型キュレーション、インタラクティブな成果物を備えた、高度にカスタマイズされた研究論文用知識ベースを説明しました。その続報ではシステム図（diagram）が共有されました。 Gemma 4 は広範な注目を集めると同時に実用的な信頼性も獲得しました：関心が集中したのはリリース自体だけでなく、@fchollet や @demishassabis の発表に加え、@ClementDelangue、@gregisenberg、@kimmonismus による実際のローカル実行に関する主張にも向けられました。 Hermes Agent の採用曲線がオープンソース界隈で可視化され始めています：最も強力な証拠は公式投稿よりも、ユーザーの移行報告や利用事例、そして @Teknium によるメモリシステムの刷新から得られました。このパターンが注目すべき点は、ユーティリティの飛躍に対して、単にベースモデルだけでなく、メモリとハーン（基盤）設計を評価するユーザーが増えていることです。 AI Reddit まとめ /r/LocalLlama + /r/localLLM まとめ 1. Gemma 4 モデルのリリースと機能 Gemma 4 がリリースされました（アクティビティ数：3412）：Google DeepMind が開発した Gemma 4 は、テキスト、画像、音声を処理できるオープンなマルチモーダルモデルのファミリーであり、最大 256K トークンのコンテキストウィンドウを備えています。このモデルは E2B、E4B、26B A4B、31B の 4 つのサイズで提供され、140 以上の言語に対応する多言語機能を搭載しています。Dense（密結合）アーキテクチャと Mixture-of-Experts (MoE)（専門家混合）アーキテクチャの両方を採用しており、テキスト生成、コーディング、推論などのタスクに最適化されています。特筆すべきは、Gemma 4 がローカルスライディングウィンドウとグローバルアテンションを組み合わせたハイブリッドアテンション機構を導入し、長文コンテキスト処理における処理速度とメモリ効率を向上させた点です。また、ネイティブ関数呼び出し（native function-calling）と構造化ツール使用をサポートしており、エージェントワークフローやコーディングタスクの円滑な実行を可能にしています。詳細は Hugging Face リポジトリをご参照ください。あるコメントでは、Gemma-4 のネイティブ思考機能とツール呼び出し能力の重要性が強調され、そのマルチモーダル性が注目されています。別のコメントでは、温度パラメータ = 1.0、top_p = 0.95、top_k = 64 といった具体的な設定を含めたモデル実行の実践的なガイダンスが提供されており、Unsloth Studio との統合についても言及されています。 Gemma-4 は、ネイティブ思考機能、ツール呼び出し、マルチモーダル能力など、いくつかの高度な機能を導入しています。特定のパラメータで最適化されており、温度 = 1.0、top_p = 0.95、top_k = 64 を使用し、シーケンス終了トークンとして が用いられます。さらに、思考トレースには thought\n が使用され、認知処理能力が強化されています。詳細とガイドは Unsloth AI で確認できます。 Gemma-4 のリリースは、Unsloth Studio とシームレスに統合されている点で重要です。これにより、開発者向けに streamlined な環境が提供されます。Gemma-4 に関連するすべての GGUF ファイルは Hugging Face でアクセス可能であり、モデルの実装や実験を検討している方々にとって包括的なリソースとなっています。 Gemma-4 と Qwen3.5 などの他のモデルとの比較分析への期待が高まっており、AI モデル開発における競争環境が浮き彫りになっています。これは、各モデルの強みと弱みを実用的な応用において理解するために、ベンチマークとパフォーマンス評価に焦点を当てていることを示唆しています。 Google Gemma 4 をローカル環境で実行できるようになりました！（最小 RAM 5GB）（アクティビティ：415）: Google は、マルチモーダル機能を備えた 4 つのモデル（E2B, E4B, 26B-A4B, 31B）からなるオープンソースモデルファミリー「Gemma 4」をリリースしました。これらのモデルは、推論、コーディング、長文コンテキストワークフローにおいて卓越した性能を発揮します。31B モデルが最も高度な機能を持ち、MoE（Mixture of Experts：専門家混合）アーキテクチャを採用した 26B-A4B は速度最適化されています。Unsloth により、これらのモデルは最小 5GB の RAM を備えたデバイスでもローカル実行が可能になりました。Unsloth Studio を介してモデルを実行でき、推奨構成は小規模モデルで 6GB、最大規模のモデルで 35GB の RAM です。GPU は必須ではありませんが、性能を大幅に向上させることができます。インストールプロセスは各種 OS で簡素化されており、デスクトップアプリも近日公開予定です。詳細は Unsloth のドキュメントをご覧ください。コメント欄では、古いハードウェアでも Gemma 4 が利用可能になったことへの興奮や、2013 年製の Dell ラップトップ上で E2B モデルが驚異的なパフォーマンスを発揮したという報告が見られます。また、モデルの仕様やハードウェア要件を追いかけることの複雑さについても議論が行われています。 Google Gemma 4 をローカル環境で実行するための推奨構成は、異なるモデルサイズにおけるメモリとパフォーマンスのトレードオフを浮き彫りにしています。例えば、E2B および E4B バリアントは、約 6GB の RAM でほぼ完全精度において 1 秒あたり 10 トークン以上の処理速度を実現可能であり、一方 4 ビット版では 4〜5GB の RAM で動作します。より大規模なモデルである 26B-A4B は、同様のパフォーマンスを得るために約 30GB の RAM を必要とし、4 ビットバージョンでも 16GB が要求されます。さらに大規模な 31B モデルは、ほぼ完全精度で 1 秒あたり 15 トークン以上を処理するために約 35GB の RAM を要します。 あるユーザーは、Gemma4 E2B モデルが古いハードウェア、具体的には 2013 年製の Dell E6440（i5 4310 CPU および 8GB RAM）において驚くほど良好に動作すると報告しています。このシステムでは返信速度が 1 秒あたり 8 トークンに達しており、これは古いシステムでも Gemma 4 の小規模モデルを基本タスクに使用できることを示唆し、同モデルの効率性と低性能マシンへの適応能力を強調するものです。 Google Gemma 4 の 31B モデルは、KV Cache（Key-Value Cache）および Mixture of Experts (MoE) アーキテクチャによるもののため、メモリ要件が非常に大きく、メモリアップロードには最大 40GB の VRAM を必要とします。これは大規模モデルを実行する際に多大なリソースを要することを示しており、高性能ハードウェアへのアクセスがないユーザーにとっては制限要因となり得ます。 Gemma4 - Google の誰かが、"この地球上で最も能力の高いオープンウェイトをさりげなく公開する"というタイトルの PR をマージしました（アクティビティ数：471）: Google は HuggingFace Transformers リポジトリにおいて、新モデル「Gemma 4」に関する PR をマージしました。これは"この地球上で最も能力の高いオープンウェイト"と説明されています。同モデルには 4 つのサイズが含まれており、オンデバイス利用向けの約 2B および約 4B の密結合（dense）モデル、推論時に 4B のアクティブパラメータを持つ 26B のスパース MoE（Mixture of Experts）、そして 31B の密結合モデルです。特筆すべきは、26B/4B の MoE が、大規模モデル並みの品質を小規模モデルの推論コストで実現している点です。Gemma 4 はトリモーダルであり、テキスト・ビジョン・オーディオをネイティブにサポートします。オーディオにはコンフォーマー（conformer）アーキテクチャが、ビジョンには 2D 空間 RoPE（Rotary Positional Embedding）が採用されています。小規模モデルでは 128K のコンテキスト長、大規模モデルでは 256K をサポートし、ハイブリッドアテンション設計を採用しています。MoE バリアントは MLP とスパース MoE ブロックの両方を含み、その出力を合算するという、珍しい設計選択となっています。コードはマージ済みですが、重みとリリース日は未定です。コメント欄では、31B モデルや VRAM 制約環境における 26B/4B の MoE の可能性に対して興奮の声が上がっています。MoE モデルが VRAM 上でどのように重みを管理するかについての議論があり、推論効率に焦点が当てられています。また別のコメントでは、llama.cpp のサポートが準備されており、重みが公開されれば即座にローカル推論が可能であることが指摘されています。 エキスパートの混合（MoE）モデルアーキテクチャは、推論時にモデルのパラメータの一部のみを活性化することで、より大規模な密結合モデルのパフォーマンスを実現し、計算オーバーヘッドを抑えることができます。つまり、Gemma4 26B/4B モデルは 260 億個のパラメータを持っていますが、同時に活性化されるのは 40 億個に過ぎず、これにより VRAM（ビデオメモリ）の要件が潜在的に削減されます。ただし、モデル全体の重み（weights）へのアクセスが必要となる場合があり、これは VRAM に制約のある環境では課題となり得ます。なぜなら、許容可能な推論レイテンシを維持するために、モデルは動的に重みの読み込みとアンロードを管理する必要がある可能性があるからです。 llama.cpp リポジトリは、最近のプルリクエストによって Gemma4 モデルへのサポートが既に統合されていることが示されています。これは、Gemma4 の重みがリリースされた時点で、ユーザーが即座に GGUF 形式に変換し、追加のアップデートを待たずにローカル推論を実行できることを意味します。この迅速な統合は、コミュニティが新しいモデルリリースをサポートし、さまざまな環境でのデプロイを促進する準備ができていることを浮き彫りにしています。 DeepMind と Google による Gemma4 の発表には、詳細なブログ記事とモデルドキュメントが含まれており、これらは DeepMind の公式ページおよび Google のブログで確認できます。これらのリソースは、モデルの機能や潜在的な応用分野に関する洞察を提供し、利用可能なオープンウェイト（open weights）の中で最も能力が高いものの一つとしての地位を強調しています。 2. Gemma 4 のパフォーマンスと課題 Gemma 4 は良い（アクティビティ：429）：この投稿では、Mac Studio M1 Ultra 上での Gemma 26b a4b モデルのパフォーマンスが Qwen3.5 35b a3b と比較されており、ユーザーは Gemma がより高速で一貫性があり、視覚的理解や多言語能力に優れていると報告しています。ただし、KV キャッシュ（Key-Value Cache）のフットプリントが大きく、260K トークン @ fp16 で 22GB の VRAM を消費します。Q4_K_XL 量子化モデルではさらに約 18GB が必要となります。また、Google の AI Studio 版 Gemma におけるトークナイザーの問題についても言及されています。ユーザーは SWA（Sliding Window Attention）が KV キャッシュサイズの削減に一定の利点をもたらすと指摘し、特に医療文脈におけるモデルの回答における検閲への懸念を表明しています。あるコメントでは、元の投稿時点で llama.cpp の実装に既知の問題があり破損していたため、その結果に対する懐疑視が示されています。別のコメントでは、i 向けの Gemma 4 E2B モデルが称賛されています。

【AIニュース】グッドフライデー

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト