Windows

歌詞の下書きや、曲ごとの作業メモの整理に言語モデルを使いたいとき、気になるのは入力した文章の行き先だ。未発表の歌詞や、まだ誰にも聴かせていない曲の構想を外部のサービスに送るのは、少しためらいがある。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 まで下げると、長い文脈での精度が落ちやすくなる。 ...

タスクスケジューラから毎朝動かしているPowerShellスクリプトが、ある日いきなり構文エラーで止まった。前日に直したのは、日本語のメッセージを1行足しただけだ。エディタで開くと文字化けもなく、どこにも問題は見えない。原因は文字コードで、Windows PowerShell 5.1が、BOM(バイト順マーク)の付いていないUTF-8のファイルをUTF-8として読んでくれないことにあった。 同じことで二度つまずかないように、仕組みと対策をまとめておく。手元のWindows 11に入っているWindows PowerShell 5.1(5.1.26100)で症状を再現し、どの文字列で壊れ、どの文字列なら通るのかも確かめた。対策は3つある。ファイルにBOMを付ける、スクリプトをASCII文字だけで書く、PowerShell 7へ移る、の3つで、それぞれの手順と向き不向きを最後に表にしている。 何が起きているのか、5.1はBOMが無ければShift_JISで読む 文字コードを取り違えると、日本語は意味のない記号の列になる。これはUTF-8を西欧向けの文字コードで読んだ例Photo: My own work as derivative of text available under CC 3.0 attrib / CC BY 3.0 テキストファイルには、自分がどの文字コードで書かれているかを示す欄がない。読む側が推測するしかなく、その手がかりになるのがファイル先頭のBOMだ。UTF-8なら先頭3バイトがEF BB BF、UTF-16LEならFF FEになっていて、これがあればどの文字コードかは迷わずに決まる。 問題はBOMが無いときの扱いだ。Windows PowerShell 5.1は、BOMの無いスクリプトをシステムの既定の文字コード(ANSIコードページ)で読む。日本語版Windowsでは、これがコードページ932、いわゆるShift_JISになる。手元の環境で[Text.Encoding]::Defaultを確かめると、shift_jis、コードページ932と返ってきた。 一方、いまのエディタの多くは、新しく作ったファイルをBOMなしのUTF-8で保存する。Visual Studio Codeの既定もそうだし、GitやLinux由来の道具もBOMなしを前提にしている。英数字だけのスクリプトなら、UTF-8とShift_JISはどちらも同じバイトになるので何も起きない。日本語のコメントや文字列を1つ入れた瞬間に、書いた側はUTF-8、読む側はShift_JISというすれ違いが表に出てくる。エディタ上では正しく見えるのに実行すると壊れる、という分かりにくさは、ここから来ている。 閉じ引用符が消える仕組みを、バイト単位で追う 文字化けだけなら、表示がおかしくなるだけで済みそうに思える。実際には構文エラーになるのは、Shift_JISとして読み直す途中で、日本語の直後にある半角の記号まで巻き込まれることがあるからだ。 UTF-8の日本語は、ひらがな・カタカナ・漢字のほとんどが1文字3バイトになる。Shift_JISは日本語を2バイトで表し、1バイト目(先行バイト)に使う範囲が81〜9FとE0〜FCと決まっている。さらにA1〜DFは1バイトの半角カナとして読まれる。UTF-8の3バイトの並びを、この規則で頭から2バイトずつ、ときどき1バイトずつ切っていくと、文字の切れ目がずれていく。そして日本語の最後のバイトが「先行バイト」として余ったとき、その次にある半角の"が2バイト文字の後半として飲み込まれてしまう。 手元でいくつかの言葉を、UTF-8のバイト列のままコードページ932で文字列に戻し、直後に置いた"が残るかどうかを見た。 文字列 UTF-8のバイト数 末尾の数バイト 直後の"は ログを保存しました 27 E3 81 9F 残る 表示 6 E7 A4 BA 残る 次の行 9 E8 A1 8C 消える 完了 6 E4 BA 86 消える 「次の行」の場合、E6 ACで1文字、A1が半角カナで1文字、E3 81で1文字、AEが半角カナ、E8 A1で1文字と切れていき、最後の8Cが余る。8Cは先行バイトの範囲に入るので、次の22(つまり")と組にされ、どちらも正しい文字にならないまま「・」のような代わりの文字に化ける。文字列を閉じるはずの引用符がここで消えるので、PowerShellは文字列が最後まで閉じていないと判断する。 ...