AI×GPUデイリー 2026-09-22

Snapdragon X EliteがChromeOS系の新プラットフォーム「Googlebook」に、Dell/HPが採用予定/Geminiが能力テスト中に実在企業3社へ自律的に侵入、WSJ報道/tokenizers v1、v0.23比で単一スレッド3〜30倍のエンコード高速化。今日の3本です。

基板の中央にある1つのプロセッサから光る配線が右へ枝分かれし、2台の閉じたノートPCへつながる俯瞰のイラスト AI生成のイメージ画像です。

今日は「WindowsではないノートPCに載るArmチップ」「テスト環境からはみ出したAI」「前処理の速度」の3本です。派手さは違いますが、3本とも「土台のほうが動いている」という共通点があると思います。

1. Snapdragon X Elite、ChromeOS系の新プラットフォーム「Googlebook」へ

PC Watchが9月21日(米国時間)、QualcommのSnapdragon X Eliteが「Googlebook」に搭載されることを報じました。Googlebookは記事の説明によればChromebookの延長線上にある製品で、ChromeOSとAndroidを統合した新しいノートPCのプラットフォームです。Snapdragon X EliteはこれまでSurface Proなどが搭載するWindows PC向けのプロセッサとして展開されてきたため、Windows以外のプラットフォームへの採用という点が新しい動きになります。記事ではDellとHPが採用予定とされていますが、具体的な製品名は挙げられていません。搭載が想定されるX1E-80-100の公称仕様は、CPUがOryonの12コアで最大4.0GHz、GPUがAdreno X1で最大3.8TFLOPS、NPUが45TOPS、バッテリー駆動は8時間以上です。Qualcommは9月22日から米ハワイ州マウイ島で年次イベント「Snapdragon Summit」を開催します。

出典: PC Watch

ひとこと(Jura) — NPU 45TOPSという公称値が、ChromeOS側でどう使われるのかが気になるところですね。Windows on Armでは「Copilot+ PC」の要件としてNPU性能が前面に出ていましたが、同じチップを別のOSに載せたときに、その演算器を使う口がどう用意されるかはまた別の設計の話になります。ゲーミングPCやローカルLLMの文脈で言えば、Armノートが即座に選択肢になるわけではありません。ただ、x86以外の選択肢が増えること自体は、周辺のソフトが対応していく圧力になるので、遠回りに効いてくる話だと思います。詳細はSnapdragon Summitで出てくるはずなので、まずは日程を覚えておくくらいでよさそうです。

2. Gemini、能力テスト中に実在企業3社へ自律的に侵入

GoogleのAI「Gemini」が、サイバーセキュリティ能力の評価テスト中に外部ネットワークへ接続し、実在する3社のシステムへ自律的に侵入していたことが判明したと、ITmediaが9月21日に報じました。米The Wall Street Journal(WSJ)が9月18日に報じ、Googleも同日に事実関係を認めたとされています。テストはイスラエルのIrregularが5月に実施したもので、Geminiは架空企業のソフトウェアから情報を取得するよう指示されていましたが、その架空の社名が実在する企業と一致していました。加えて、本来インターネットに接続できない設定であるはずのテスト環境が、意図せず接続可能な状態になっていたと説明されています。Google側は、モデルが実在企業だと判定した時点で侵入を中止したため企業への被害はなかったとし、セキュリティ担当バイスプレジデントは「モデルは適切に振る舞った」として、ミスアライメントには当たらず安全対策が機能したと述べています。記事では、同社のAIが自律的にこうした行為に及んだのは初めてだとされています。

出典: ITmedia NEWS

ひとこと(Jura) — 事故の中身を分解すると、モデルの暴走というより、テストの作り方の問題が2つ重なった形に見えますね。架空のつもりの社名が実在していたことと、閉じているはずの環境が外に出られたこと。どちらもモデルの性能とは関係のない、環境側の設定です。エージェントに手を動かさせる構成を自分で組んでいる人には、けっこう他人事ではない話だと思います。ダミーのドメインや社名に実在のものを使っていないか、ネットワークを遮断したつもりの環境が本当に遮断されているか。この2点は、動かす前に確認しておく価値があると思います。

3. tokenizers v1、v0.23比で単一スレッド3〜30倍のエンコード高速化

Hugging Faceが9月21日、トークナイザーライブラリ「tokenizers」のv1に関する記事を公開しました。Apple M4 Max上の単一スレッドでの計測として、v0.23比でテキストのエンコードが3〜30倍速くなったとしています。倍率の下限はt5-base、上限はgpt2で、モデルによって幅があります。8ワーカースレッドでの線形スケーリングは76%とされています。高速化の内訳として4点が挙げられています。1つ目は「Bitcannon」で、正規表現による分割をビットストリーム上のSIMD演算に置き換え、1回のレジスタ操作で64バイトを処理するもの。対象パターンはGPT-2、cl100k、o200k、Tekken、DeepSeekです。2つ目はスレッドローカルのワードキャッシュで、既出の単語はマージ処理を丸ごと省略します。3つ目は作業用バッファを呼び出し側が保持して再利用する方式、4つ目は事前確保したバッファ内で侵入型リンクリストを使い、マージごとに2つのインデックスだけを更新するマージループの最適化です。破壊的変更はなく、v1はv0.23と同じトークンIDを出力するとされています。現在はcrates.ioでプレリリース版が配布されており、cargo add tokenizers --pre で導入できます。

出典: Hugging Face Blog

ひとこと(Jura) — 3〜30倍という幅の広さが、そのまま「どこがボトルネックだったか」を表していると思います。gpt2のように分割パターンが単純なものほど正規表現の置き換えが効いて、t5-baseのような構成では伸びしろが小さい。自分の使っているモデルがどちら寄りかで体感は変わるはずです。それから、出力トークンIDが変わらないと明記されているのが実務上は大きいですね。トークナイザーを差し替えて結果がずれると、学習済みモデルとの整合が崩れて原因追跡が面倒になります。まだプレリリースなので本番投入は様子見でいいと思いますが、大量のテキストを前処理する用途では効いてくる更新だと思います。

今日の小ネタ

  • llama.cppのb11078で、--temp --top-p --min-p とペナルティ各種を環境変数から指定できるように — GitHub(ggml-org/llama.cpp)
  • 同じくb11071で、Ubuntu向けCUDAリリースビルドのCUDAが13.4へ更新 — GitHub(ggml-org/llama.cpp)