Tech

歌詞の下書きや、曲ごとの作業メモの整理に言語モデルを使いたいとき、気になるのは入力した文章の行き先だ。未発表の歌詞や、まだ誰にも聴かせていない曲の構想を外部のサービスに送るのは、少しためらいがある。Ollamaを使えば、モデルを一度ダウンロードしたあとは手元のPCだけで文章を生成でき、入力した内容が外に出ることはない。 ただ、ローカルで動かすとなると、次に気になるのは「自分のPCで、どの大きさのモデルまで動くのか」という点になる。7B、13B、70Bといったモデルの数字と、手元のグラフィックボードのVRAMや本体のメモリをどう突き合わせればいいのかは、意外と分かりにくい。この記事では、4bit量子化のモデルを前提に、必要なメモリを自分で見積もる方法を整理する。 4bit量子化なら「パラメータ数×0.6GB」が出発点 VRAM 24GBのGeForce RTX 3090。ローカルLLMでは、演算性能よりもこの容量のほうが効いてくるPhoto: PantheraLeo1359531 / CC BY 4.0 モデル名についている「8B」や「70B」は、パラメータ（重み）の数を表している。8Bなら80億個、70Bなら700億個だ。元の16bitの精度のまま読み込むと、1パラメータあたり2バイト必要なので、8Bのモデルでも16GB、70Bなら140GBになる。これでは一般的なPCには載らない。 そこで使われるのが量子化で、重みを4bit前後まで丸めてファイルを小さくする。Ollamaのライブラリでタグを指定せずに取得すると、多くのモデルはQ4_K_Mという4bit系の形式で配られている。この形式では1パラメータあたりおよそ4.5〜5bitになるので、ざっくり「パラメータ数（B）×0.6GB」と考えると、ダウンロードするファイルの大きさにかなり近い値になる。 ライブラリに表示されている既定のタグのサイズを並べると、この目安がよく当てはまることが分かる。Mistral 7Bが4.4GB、Llama 3.1 8Bが4.9GB、Qwen3 8Bが5.2GB、Qwen3 14Bが9.3GB、Qwen3 32Bが20GB、Llama 3.3 70Bが43GBだ。OpenAIが公開したgpt-oss 20Bは別の4bit形式を使っていて14GB、120Bは65GBになる。 ただし、このファイルサイズがそのまま必要なメモリになるわけではない。モデルを動かすには、重みのほかに「会話の文脈を覚えておく領域」と「計算用の作業領域」が要る。見積もりの式にすると、次のようになる。 必要なメモリ ≒ モデルのファイルサイズ ＋ コンテキスト分のKVキャッシュ ＋ 作業領域1〜2GB 重みの部分は上の目安でほぼ決まるので、差が出るのは真ん中のKVキャッシュだ。ここを見落とすと、ファイルサイズだけ見て「載るはず」と思ったモデルが、実際には収まらないということが起きる。 コンテキスト長がメモリを食う仕組み 32GBのDDR5モジュール。VRAMに収まらなかった分は、本体のメモリが受け持つことになるPhoto: ITEagle Europe - Sebastiaan Broekhoven / CC BY-SA 4.0 言語モデルは、文章を1トークン生成するたびに、それまでの文脈をすべて参照する。毎回最初から計算し直すと遅すぎるので、過去のトークンについての計算結果をKVキャッシュとして保存しておく。このキャッシュはトークン数に比例して大きくなる。つまり、一度に扱える文脈の長さ（コンテキスト長）を伸ばすほど、メモリが必要になる。 どのくらい増えるかは、モデルの層の数などの構造で決まる。Llama 3.1 8Bを例にすると、標準の16bitのキャッシュで1トークンあたり約128KBになる。コンテキスト長が4,096トークンなら約0.5GBで済むが、32,768トークンに伸ばすと約4GB、128,000トークンまで伸ばすと約16GBになり、重みの4.9GBを大きく上回ってしまう。Llama 3.3 70Bなら1トークンあたり約320KBで、32,768トークンでは約10GBが上乗せされる。 ここで注意したいのは、Ollamaのコンテキスト長の既定値が固定ではないことだ。現在のOllamaは使えるVRAMの量を見て、24GB未満なら4,096トークン、24〜48GBなら32,768トークン、48GB以上なら256,000トークンを自動的に選ぶ。VRAMの大きいGPUほど長い文脈が既定になるので、大きなGPUを積んでいるのに、思ったより小さいモデルしか載らないということが起こりうる。 コンテキスト長は、環境変数 OLLAMA_CONTEXT_LENGTH で全体の既定値を決められるほか、モデルごとに num_ctx で指定することもできる。歌詞の下書きや短いメモの整理なら、8,192トークンもあれば十分なことが多い。長い文書を丸ごと読ませる用途でなければ、まずコンテキスト長を控えめに固定しておくと、見積もりが立てやすくなる。 KVキャッシュそのものを小さくする方法もある。環境変数 OLLAMA_KV_CACHE_TYPE を q8_0 にすると、キャッシュの大きさはおよそ半分、q4_0 なら4分の1になる。これはFlash Attention（OLLAMA_FLASH_ATTENTION）が有効な状態で働く設定だ。q8_0 なら文章の質への影響は小さいと感じるので、VRAMが少し足りないときの最初の手として試しやすい。q4_0 まで下げると、長い文脈での精度が落ちやすくなる。 ...

インターネットを閲覧するための最も一般的なブラウザであるGoogle Chrome。その背後で、ユーザーが知らないうちに約4GBにもおよぶ巨大なAIモデル「Gemini Nano」が自動的にダウンロードされているという事実が、セキュリティ研究者や多くのユーザーの間で大きな話題となっている。 クラウド上のサーバーで処理を行うのではなく、手元のデバイス（ローカル環境）のハードウェア上で直接AIを動かす「オンデバイスAI」の波がブラウザにも押し寄せているわけだが、ストレージ容量の限られたノートPCや、制作系の重いデータを扱うクリエイターの環境においては、突如現れた4GBの巨大ファイルは無視できない問題だ。このオンデバイスAIが一体どのような目的で導入され、私たちのPC環境にどのような影響を与えているのか、その詳細と対処法を徹底的に見ていこう。 1. Google Chromeが裏側でダウンロードするGemini Nanoの正体 ブラウザのバックグラウンドで動作するAI機能 Photo: Megamanfan3 / Public domain Googleは近年、OSやブラウザ、さまざまなアプリケーションに自社のAIである「Gemini」シリーズを深く統合する戦略を強力に推進している。その中でも「Gemini Nano」は、クラウドサーバーへデータを送信することなく、スマートフォンやパソコンといった個人のデバイス（エンドポイント）上で直接軽量なAI処理を実行するために設計されたモデルである。 ChromeブラウザがこのGemini Nanoを自動ダウンロードする背景には、将来的にブラウザ上でリアルタイムのテキスト生成、自動翻訳、ページ要約、スペルチェック、さらにはプライバシーを保護した高度な補助機能を提供し、ネットサーフィンや作業の効率を劇的に向上させるという狙いがある。サーバーとの通信遅延（レイテンシ）をゼロにし、インターネット接続がない環境でもAI機能を利用できるようにするための先遣隊として、バックグラウンドでモデルファイルがダウンロードされているという仕組みだ。 しかし、ユーザーの明示的な同意や確認画面を経ることなく、ある日突然PCの隠しフォルダ内に数ギガバイトものファイルが生成される仕様になっている点に対しては、ストレージの空き容量を圧迫する「見えない肥大化」として懸念の声が上がっている。特に、SSDの容量が256GBや512GBと比較的小さいモバイルノートPCを使用しているユーザーや、動画編集・音楽制作などで常にストレージ容量と戦っているクリエイター層にとっては、許容しがたい動作になり得る。かつて軽量・高速を売りにしていたブラウザが、数GBのAIモデルを標準搭載するプラットフォームへ変貌していくことに対して戸惑いを覚える声も少なくない。こうしたバックグラウンドでの巨大データ通信は、定額制ではないモバイル回線やテザリング環境でブラウザを利用しているユーザーにとっても、意図しないパケット消費やコストの発生につながるリスクをはらんでいる。 2. オンデバイスAIがPCのストレージやリソースに与える影響 ブラウザの機能拡張とリソース消費 Photo: TealComet / CC0 オンデバイスAIの最大のメリットは、プライバシーの保護と応答速度の速さにある。入力したテキストや閲覧しているページのデータが外部のサーバーに送信されないため、機密性の高い情報や個人的な文章を扱う際にも安心してAIの恩恵を受けられる。また、ネットワークの混雑状況に左右されず、瞬時に結果が返ってくる点も大きな強みだ。 一方で、デメリットとして挙げられるのがハードウェアリソースの消費である。約4GBのモデルファイルがストレージを占有するだけでなく、ブラウザが起動している最中や特定のバックグラウンド処理が行われる際に、CPUやGPU、メモリ（RAM）を追加で消費する可能性がある。近年のハイスペックなPCであれば動作に支障を感じることは少ないかもしれないが、数年前の古いモデルやスペックを抑えたビジネス用ラップトップ、あるいはDAWや3Dレンダリングソフトと並行してChromeを立ち上げる制作環境においては、無視できない負荷になり得る。 さらに、AIモデルがバックグラウンドで頻繁にアップデートや検証を行うことで、バッテリーの消費が早まるといった副次的な影響も指摘されている。便利さの裏側で、目に見えない電力やストレージのコストを常に支払い続けている状態と言える。特にモバイル環境での作業において、予期せぬバッテリーの消耗は死活問題になりかねず、ユーザー自身がハードウェアの稼働状況を細かく把握・制御できる仕組みの必要性が改めて浮き彫りになっている。 3. ストレージ容量を圧迫しないための確認と無効化・削除手順 「クラウドのAIは便利かもしれないが、自分の手元のPCに勝手に4GBのAIモデルを置かれるのは困る」「ストレージの空き容量を1バイトでも多く確保したい」というユーザーのために、ChromeのオンデバイスAI機能を確認し、必要に応じて無効化または削除する手順が存在する。 まず、ChromeのバックグラウンドでAI関連のモデルやコンポーネントがダウンロードされているかどうかは、設定画面や内部のコンポーネント管理画面（chrome://components）から確認することができる。AI関連のモジュールが「Up-to-date」として存在している場合、ローカルにデータが保持されている証拠となる。 この機能を完全にオフにし、不要なAIモデルのダウンロードやリソース消費を防ぐには、Chromeの設定メニューからプライバシーおよびセキュリティの項目を掘り下げ、実験的なAI機能やオンデバイスでの最適化に関するトグルをオフに切り替える必要がある。また、より高度な制御を行うために chrome://flags から関連するフラグを明示的に無効化したり、エンタープライズポリシーを活用して組織全体でAIモデルのダウンロードをブロックする手法も存在する。関連するキャッシュやデータフォルダを手動でクリーンアップすることで、占有されていたストレージ領域を解放することが可能だ。設定を変更した後は、ブラウザを一度完全に再起動し、バックグラウンドプロセスがしっかりと停止していることをタスクマネージャー等で確認しておくとより確実である。こうした設定の個別変更を通じて、ユーザーが自身の環境に最適なリバランスを行うことが可能になる。 4. クラウドAIとオンデバイスAIの使い分け、今後のブラウザの行方 Google Chromeをはじめとするモダンブラウザの急速なAI化は、私たちがウェブと対話する方法を根本から変えつつある。検索窓にキーワードを入力してリンクを探す時代から、ブラウザがページ全体を理解し、要約や質問への回答をその場で生成してくれる時代へと移行しているのは紛れもない事実だ。 しかし、その進化のスピードが速すぎるあまり、「ユーザーへの透明性」や「コントロールのしやすさ」が置き去りにされている側面があることも否定できない。数GBのモデルを事前通知なしにダウンロードする仕様は、通信容量制限のあるモバイル回線を利用している環境や、ストレージ管理を厳密に行いたいユーザーとの間で摩擦を生む原因になりやすい。 今後は、AI機能を標準で押し付けるのではなく、初期設定の段階で「オンデバイスAIを利用するかどうか」をユーザーが明示的に選択できるオプトイン方式の採用や、モデルのサイズをより軽量に保つ最適化技術の進歩が強く求められることになるだろう。ブラウザが単なる閲覧ソフトから「AIの実行環境」へと変貌していく過渡期において、私たちユーザー側も、自身のPC環境に合わせて賢く機能を取捨選択するリテラシーが試されている。 まとめ Google ChromeによるGemini Nanoの自動ダウンロード問題は、ローカルAIの利便性と、PCのリソース管理・プライバシーへの配慮との間で揺れる現代のインターネット事情を象徴するトピックである。オンデバイスAIは強力な武器になり得る一方で、すべてのユーザーにとって常に不可欠な機能とは限らない。自身のストレージや用途に合わせて設定を見直し、ブラウザを快適な状態に保つための管理術をしっかりと身につけておこう。 関連記事 今夜はウイスキー・カルチャーの記事やDTM理論の記事も公開予定です → note はこちら GitHub Pages で技術・理論記事を読む はてなブログ版はこちら note版はこちら