はじめに：過去の技術「ActiveX」の記憶 日経クロステックに掲載された記事「このままだとMCPはAI時代のActiveXになるかもしれない」は、現代の技術者にとって示唆に富む警鐘を鳴らしています（注：元記事は有料のため、本稿はタイトルから着想を得た独自の論考です）。 かつて、Webにリッチな機能をもたらすと期待されたMicrosoftの「ActiveX」。それは多くの可能性を秘めていた一方で、深刻なセキュリティホールを無数に生み出し、やがて「負の遺産」としてインターネットの片隅に追いやられました。 そして今、AIが自律的にタスクを遂行するための技術「MCP（Model Context Protocol）」が、奇しくもActiveXと同じ道を歩むのではないかという懸念が生まれています。 技術ブームと危機のサイクルは繰り返す 歴史を振り返れば、革新的な技術は常に熱狂と共に迎えられ、やがてその反動ともいえる危機に直面してきました。 新たな可能性の登場: 新技術が、これまでにない利便性や機能性を約束します。MCPは、AIを私たちのデジタル世界にシームレスに統合する未来を提示しています。 熱狂的な採用: 「とにかく実現させよう」という熱意に後押しされ、開発者や企業はリスクを顧みず技術を導入します。長期的なセキュリティや倫理的な影響よりも、迅速な実装が優先されます。 警告の軽視: 専門家からの警告は「過度に慎重すぎる」と一蹴され、潜在的なリスクは目先の利益のために軽視されます。 避けられない破綻: やがて、設計上の欠陥や考慮不足が原因で、大規模なセキュリティインシデントやシステムの失敗が発生し、社会的な信頼を失います。 危機後の再調整: 甚大な被害が出た後、業界は初めて重い腰を上げ、堅牢な基準の構築を始めます。しかし、それは多くの信頼と資産が失われた後なのです。 現在のMCPへの期待は、かつてのActiveXやドットコムバブルの熱狂と酷似しています。輝かしい未来の可能性は、その根底にあるはずの根本的な欠陥から人々の目を逸らさせてしまうのです。 ActiveXより深刻？「非決定性」という最大のリスク ここで、ActiveXとMCPの決定的な違いを指摘しなければなりません。それは**「挙動が決定論的か、非決定論的か」**という点です。 ActiveXは、その動作がコードによって規定されていました。悪意のあるコードが実行されれば問題は起きますが、少なくともその動作は（理論上は）追跡可能で、決定論的でした。 しかし、MCPはAIを基盤としています。AIの動作は本質的に非決定論的です。つまり、同じ入力に対しても、常に同じ結果を返すとは限りません。開発者ですら、AIが次にどのような判断を下すかを100%予測することは不可能なのです。 例えば、海外と国内の価格を比較し、自動で商品を売買するAIエージェントを考えてみましょう。 もしAIが、急激な為替レートの変動を「一時的なノイズ」と誤学習したら？ もしAIが、競合のセール価格を「恒久的な市場価格」と誤解釈したら？ その結果生じる損失は、もはや誰にも想定できません。ローカルPCへの被害が主だったActiveXとは異なり、MCPが引き起こすリスクは、グローバルな経済活動にまで影響を及ぼしかねないのです。 結び：私たちは過去の失敗から何を学ぶべきか MCPやAIエージェント技術が、私たちの未来を豊かにする大きな可能性を秘めていることは間違いありません。しかし、その輝かしい側面だけを見て、リスクから目を背けるべきではありません。 ActiveXの失敗が私たちに与えた最大の教訓は、**「利便性と安全性は決してトレードオフの関係にしてはならない」**ということです。 「速く動いて、まず動くものを作れ」という開発思想は、時としてイノベーションを加速させます。しかし、その"破壊"の対象がユーザーの信頼や資産であるならば、話は全く別です。 私たちは今、歴史の岐路に立っています。開発者、企業、そして社会全体が、この新たな技術とどう向き合うべきか。過去の失敗から学び、慎重な議論と堅牢な設計思想を持つこと。それこそが、AIエージェントが真に人類の利益となる未来への唯一の道ではないでしょうか。

鳴り物入りで登場したGPT-5が、一部のユーザーから「退化した」との厳しい評価を受けている。最高峰の性能を期待されたはずの次世代モデルは、なぜこのような事態を招いたのか。その謎を解く鍵は、GPT-5が採用した MoE（Mixture of Experts） アーキテクチャと、OpenAIが近年辿ってきた戦略的な変遷、そして外部からもたらされたある「衝撃」にある。 「おバカな博士」はなぜ生まれたか 多くの指摘が、GPT-5に新たに搭載された「自動ルーティング機能」の問題に集約される。東洋経済オンラインの記事は、この問題の本質を的確に捉えている。 この問題の本質は、ChatGPTに新しく組み込まれた自動ルーティングにある。この機能は質問の複雑さや期待精度を推定し、内部で最適な“脳”を選択し、どの程度、深く考えるべきかを判別する仕組みだ。…（中略）…ところが発表直後、このルーターは軽い脳を選びすぎていた。…（中略）…速度や省電力、コスト効率を重視した最適化の結果、深く考えるべき問いにも浅い処理で応じてしまい、結果として間抜けなおバカ博士が生まれたのだ。 この「自動ルーティング」の正体が、MoEアーキテクチャの中核をなす ゲーティングネットワーク（Gating Network） だ。 MoE（Mixture of Experts）アーキテクチャの光と影 MoEは、単一の巨大なAIが全問題を解くのではなく、特定分野を得意とする複数の小規模な「専門家（Expert）」モデルを連携させる仕組みだ。入力された質問をルーターが分析し、最適な専門家のみを活性化させる**スパース活性化（Sparse Activation）**により、計算コストを劇的に抑えつつ高い性能を引き出すことを目的としている。 しかし、この先進的なアーキテクチャには固有の課題が存在する。 ルーティングの複雑性: 質問の意図を正確に汲み取り、最適な専門家へ割り振るルーターの学習は極めて難しい。GPT-5の初期バージョンでは、このルーターがコスト効率を過度に重視した結果、複雑な問題にも低能力な専門家を割り当て、「浅い回答」を連発してしまった。 負荷の不均衡: 処理が特定の専門家に集中し、モデル全体のポテンシャルを活かせない問題。 膨大なメモリ消費: 計算は効率的でも、全専門家をメモリ上に展開する必要があるため、推論時のメモリ消費量は巨大になる。 GPT-5の「退化」騒動は、このMoEという理想的なアーキテクチャの、実装の難しさという現実が露呈した結果と言える。OpenAIが「効率化」の切り札として採用した技術は、諸刃の剣でもあったのだ。 この諸刃の剣は厄介で、簡単にユーザに脳梁切断術のような印象を与えることになる。特に初期のユーザのレビューにあった、ロボトミー手術を受けたかのようだという、コメントの正体はこのMoEの宿命により、キャラクターが破綻したためではないかと考えている。 GPT-5へ至る道：巨大モデルの行き詰まり なぜOpenAIは、このようなリスクを冒してまでMoEを採用したのか。その背景を理解するには、GPT-5に至るまでのOpenAIの戦略的な模索を振り返る必要がある。 GPT-4o (Omni): 2024年5月、テキスト・音声・画像を統合処理する初の本格的なマルチモーダルモデルとして登場。性能はGPT-4 Turbo級を維持しつつ、コストと速度を劇的に改善し、「効率化」時代の幕開けを告げた。 o1 / o3 (推論モデル): 2024年9月以降、即時応答よりも「思考時間」をかけて論理的思考を深める推論特化モデルをリリース。AIの能力を「知識の広さ」から「思考の深さ」へとシフトさせる試みだった。 OpenAIは「効率化（GPT-4o）」と「高度な推論（o1, o3）」という二つの路線を並行して追求していた。そして、この二つの路線を統合せざるを得ない決定的な出来事が、あるモデルの商業的な失敗である。 一つの時代の終わり：GPT-4.5 (Orion) の教訓 2025年2月、OpenAIは GPT-4.5（コードネーム: Orion） をリリースした。これは、巨大な単一モデル（Denseモデル）の性能的な到達点と目されたが、その圧倒的な性能と引き換えに、商業的には容認しがたいほどの高コストという問題を抱えていた。 API料金は100万入力トークンあたり75ドルと、GPT-4oの実に30倍。この「目が飛び出るような」コストは、多くのユーザーを遠ざけた。ニューヨーク・タイムズが「一つの時代の終わり」と評したように、このモデルは商業的に成功せず、リリースからわずか数ヶ月でサービス終了に追い込まれる。 GPT-4.5の失敗は、AIの進化が「単にパラメータを増やせば性能が上がる」という “フリーランチの時代”の終わり を象徴していた。ベンチマーク上の性能は高くとも、コストに見合わなければ市場は受け入れない。この手痛い教訓が、OpenAIをGPT-5でのMoE採用へと突き動かしたのだ。 AI業界の「スプートニク・ショック」 OpenAIの戦略転換を後押ししたもう一つの要因が、外部からもたらされた「DeepSeekショック」だ。 1957年のスプートニク・ショックが米国に宇宙開発への危機感を抱かせたように、中国のスタートアップDeepSeekが開発したオープンソースのMoEモデル「DeepSeek-R1」は、西側のAI業界に衝撃を与えた。 巨大企業ではない組織が、GPT-4に匹敵する高性能モデルを、はるかに優れたコスト効率で実現できることを証明したからだ。これは、AI開発の競争軸が、もはや巨大資本による物量作戦だけではないことを示唆していた。 GPT-4.5の失敗で高コストな巨大モデル路線に見切りをつけつつあったOpenAIにとって、DeepSeekの成功は、MoEこそが進むべき道であると確信させる決定的な一撃となっただろう。 これからの展望：賢いルーターとユーザーの協調 GPT-5の初期のつまずきは、AI開発が新たな段階に入ったことの証左である。問題は山積みだが、解決策もまた模索されている。 ユーザー側では、プロンプトに「ステップバイステップで深く考えて」といった指示を加えることで、ルーターを高性能な専門家へ誘導する「ルーターハッキング」が当面の対策となる。 しかし、本質的な解決は、ルーター自体の進化にかかっている。よりユーザーの意図を正確に汲み取るアルゴリズムの開発や、ユーザーが「速度優先」「品質優先」といったモードを選択できる機能、そしてどの専門家が選択されたかを可視化する透明性の向上が、今後の重要な開発目標となるだろう。 GPT-5の苦いデビューは、「効率化」という名のフリーランチは存在しないことを示した。しかしこの失敗は、AIが単一の巨大な知能を目指す時代から、多様な専門家が協調し、それを賢く使いこなすアーキテクチャの時代へと移行するための、避けては通れない重要なステップなのである。 そして、これは、AIの評価が単に、ベンチマークで測れる賢さからユーザの受ける印象と言うもっと高度なところにシフトしつつある現実を表していると思う。

先日公開されたGoogleの軽量大規模言語モデル「Gemma 3 270M」は、そのコンパクトさからエッジデバイスでの活用が期待されています。 前回の記事では、llama.cppを利用してRaspberry Pi 400で直接モデルを動かす方法を確認しました。 今回は、より手軽にLLMを管理・実行できるプラットフォームであるollamaをRaspberry Pi 400に導入し、Gemma 3 270Mを動作させる手順をまとめます。 なぜollamaを使うのか？ ollamaは、モデルのダウンロード、管理、実行をシンプルなコマンドで完結させてくれるツールです。APIサーバーも内蔵しているため、他のアプリケーションとの連携も容易になります。Raspberry PiのようなデバイスでLLMを「サービス」として動かしたい場合に非常に便利です。 ollamaのインストール ollamaのインストールは、公式が提供しているスクリプトを実行するだけです。非常に簡単です。 curl -fsSL https://ollama.com/install.sh | sh インストール後、以下のコマンドでバージョン情報が表示されれば成功です。 ollama --version ollamaサービスの有効化 インストールしただけでは手動で起動する必要があります。マシンの起動時に自動でollamaが起動するように、systemdサービスを有効化しておきましょう。 sudo systemctl enable --now ollama 以下のコマンドでサービスが正常に動作しているか確認できます。 systemctl status ollama Active: active (running)と表示されていれば問題ありません。 Gemma 3 270Mモデルの実行 ollamaでモデルを実行するにはollama runコマンドを使用します。今回は、Hugging Face Hubで公開されているunslothによるGGUF形式のモデルを利用します。 ollama run hf.co/unsloth/gemma-3-270m-it-GGUF:Q2_K モデルの選択について hf.co/unsloth/gemma-3-270m-it-GGUF: Hugging Face Hub上のモデルリポジトリを指定しています。ollamaは直接Hugging Face Hubからモデルをダウンロードできます。 Q2_K: モデルの量子化レベルを指定しています。Q2_Kは2ビット量子化されており、ファイルサイズとメモリ使用量を大幅に削減できるため、Raspberry Pi 400のようなメモリが限られたデバイス（4GB）に最適です。 初回実行時には、モデルファイルのダウンロードと展開が行われます。完了すると、プロンプトが入力可能な状態になります。 まとめ ollamaを利用することで、Raspberry Pi 400という手軽な環境に、非常に簡単にローカルLLM環境を構築できました。モデルの切り替えや管理も容易なため、様々な軽量モデルを試すのに最適なプラットフォームと言えるでしょう。 常時起動させておけば、家庭内LANからAPI経由でアクセスするAIアシスタントとして活用したり、IoTデバイスの制御に自然言語インターフェースを追加したりと、様々な応用が考えられます。皆さんもぜひ、手元のRaspberry PiでローカルLLMの世界に触れてみてください。

概要 scipy.stats.f.ppf（F分布のパーセント点関数）が、特定の条件下で不正確な結果を返す可能性があるという問題についての報告です。具体的には、確率が1に非常に近い値（裾の領域）と大きな自由度の組み合わせにおいて、ppf関数の結果と、累積分布関数（cdf）を最適化して得られる結果との間に大きな乖離が見られます。 この問題は2021年頃に発見されましたが、最近のバージョンでも同様の現象が確認されたため、改めて報告するものです。 なお、本件は、既に、https://github.com/scipy/scipy/issues/20835 で報告されており、恐らく、scipy 1,17で対策はマージされると思います。 ENH: special: boostify F distribution functions 問題の詳細 scipy.stats.f.ppf に欠陥がある可能性が疑われます。最適化関数と累積分布関数（cdf）の組み合わせで得られる結果が、ppf関数の戻り値と一致しません。 再現コード 以下のコードは、sps.f.ppf を直接呼び出した場合と、spo.brentq を使って sps.f.cdf から逆関数を求めた場合の結果を比較します。 import scipy.stats as sps import scipy.optimize as spo # ppf関数を直接呼び出す print(sps.f.ppf(0.99999995, 1, 50000, loc=0, scale=1)) # cdfと最適化関数brentqを使って逆関数を求める print(spo.brentq(lambda x: sps.f.cdf(x, 1, 50000) - 0.99999995, 1, 1e10)) コードの出力 3333.8385803475894 29.725915444860586 出力結果からわかるように、2つの計算結果は大きく異なっています。 エラーメッセージ この問題では、エラーメッセージは出力されません。コードは正常に終了しますが、得られる結果の信頼性に疑問があります。 原因の考察 このPythonコードと出力は、F分布のパーセント点関数（ppf）と、それを最適化関数（brentq）を使って求めるアプローチとの間の数値的な不安定性を示唆しています。 sps.f.ppf(0.99999995, 1, 50000) これはF分布のパーセント点関数（ppf）を直接呼び出し、累積確率が0.99999995となるF値を求めます。この計算では、F値が 3333.83… という非常に大きな値になっています。 spo.brentq(lambda x: sps.f.cdf(x, 1, 50000) - 0.99999995, 1, 1e10) こちらはscipy.optimizeモジュールのbrentq関数を使い、同じ問題を数値的に解いています。brentqは、与えられた関数の値が0になる点（根）を見つけるための堅牢なアルゴリズムです。ここでは、「sps.f.cdf(x, 1, 50000) - 0.99999995」という式が0になるx、つまり累積確率が0.99999995になるF値を探索しています。 この計算では、F値が 29.72… という、ppfの直接呼び出しとは全く異なる、より妥当と思われる値が得られます。 この乖離は、scipy.stats.f.ppfが特定の条件下で正確な答えを返さない可能性があることを示しています。 F分布のような統計分布の逆関数（ppf）を、極端な確率値（この例では1に非常に近い0.99999995）で計算する場合、数値的な精度の問題が発生しやすくなります。特に自由度が大きい場合、分布の裾（テール）の部分が非常に平坦になるため、計算過程でのわずかな丸め誤差などが、結果として得られるF値の大きな違いにつながることがあります。 一方、brentqは指定された範囲内で根を探索する、より頑健な数値計算アルゴリズムです。関数の振る舞いをより正確に追跡できるため、このようなケースではより信頼性の高い結果を生成すると考えられます。 問題の可視化 この問題は、以下のコードでscipy.special.fdtri（F分布の逆関数）の挙動をプロットすることで、より明確に可視化できます。自由度d2が50000と大きい場合に、確率pが0に近づく（つまり累積確率が1に近づく）領域で、関数の値が急激に変動していることがわかります。 import numpy as np from scipy import special import matplotlib.pyplot as plt d1, d2, p = 1, 50000, np.logspace(-16, -1) # fdtriは1-pを引数に取るため、pが0に近づくと累積確率が1に近づく fdtri = special.fdtri(d1, d2, 1-p) plt.semilogx(p, fdtri) plt.xlabel("p (1 - Cumulative Probability)") plt.ylabel("F-value (fdtri)") plt.title("fdtri behavior for extreme probabilities (d1=1, d2=50000)") plt.grid(True) plt.show() ...

Gemma 3 270MモデルがRaspberry Pi 400上で動作させることが確認されました。 ビルドと実行方法 ビルドコマンド 以下のコマンドを使用して、llama.cppをビルドします。 cmake -B build -DGGML_NATIVE=ON -DLLAMA_NEON=ON -DLLAMA_CURL=OFF cmake --build build --config Release -j4 ベンチマーク実行 ビルド後、ベンチマークを実行します。 ./llama.cpp/build/bin/llama-bench -m models/gemma-3-270m-it-Q2_K.gguf ベンチマーク結果は以下の通りです。 model size params backend threads test t/s gemma3 270M Q2_K - Medium 219.87 MiB 268.10 M CPU 4 pp512 47.36 ± 0.04 gemma3 270M Q2_K - Medium 219.87 MiB 268.10 M CPU 4 tg128 2.48 ± 0.00 対話モードの実行とテスト 以下のコマンドで対話モードを実行します。 ./llama.cpp/build/bin/llama-cli -m models/gemma-3-270m-it-Q2_K.gguf build: 6201 (9d262f4b) with cc (Debian 12.2.0-14+deb12u1) 12.2.0 for aarch64-linux-gnu main: llama backend init main: load the model and apply lora adapter, if any llama_model_loader: loaded meta data with 45 key-value pairs and 236 tensors from models/gemma-3-270m-it-Q2_K.gguf (version GGUF V3 (latest)) llama_model_loader: Dumping metadata keys/values. Note: KV overrides do not apply in this output. llama_model_loader: - kv 0: general.architecture str = gemma3 llama_model_loader: - kv 1: general.type str = model llama_model_loader: - kv 2: general.name str = Gemma-3-270M-It llama_model_loader: - kv 3: general.finetune str = it llama_model_loader: - kv 4: general.basename str = Gemma-3-270M-It llama_model_loader: - kv 5: general.quantized_by str = Unsloth llama_model_loader: - kv 6: general.size_label str = 270M llama_model_loader: - kv 7: general.license str = gemma llama_model_loader: - kv 8: general.repo_url str = https://huggingface.co/unsloth llama_model_loader: - kv 9: general.base_model.count u32 = 1 llama_model_loader: - kv 10: general.base_model.0.name str = Gemma 3 270m It llama_model_loader: - kv 11: general.base_model.0.organization str = Gg Hf Gm llama_model_loader: - kv 12: general.base_model.0.repo_url str = https://huggingface.co/gg-hf-gm/gemma… llama_model_loader: - kv 13: general.tags arr[str,5] = [“gemma3”, “unsloth”, “gemma”, “googl… llama_model_loader: - kv 14: gemma3.context_length u32 = 32768 llama_model_loader: - kv 15: gemma3.embedding_length u32 = 640 llama_model_loader: - kv 16: gemma3.block_count u32 = 18 llama_model_loader: - kv 17: gemma3.feed_forward_length u32 = 2048 llama_model_loader: - kv 18: gemma3.attention.head_count u32 = 4 llama_model_loader: - kv 19: gemma3.attention.layer_norm_rms_epsilon f32 = 0.000001 llama_model_loader: - kv 20: gemma3.attention.key_length u32 = 256 llama_model_loader: - kv 21: gemma3.attention.value_length u32 = 256 llama_model_loader: - kv 22: gemma3.rope.freq_base f32 = 1000000.000000 llama_model_loader: - kv 23: gemma3.attention.sliding_window u32 = 512 llama_model_loader: - kv 24: gemma3.attention.head_count_kv u32 = 1 llama_model_loader: - kv 25: tokenizer.ggml.model str = llama llama_model_loader: - kv 26: tokenizer.ggml.pre str = default llama_model_loader: - kv 27: tokenizer.ggml.tokens arr[str,262144] = ["”, “”, “”, “”, … llama_model_loader: - kv 28: tokenizer.ggml.scores arr[f32,262144] = [-1000.000000, -1000.000000, -1000.00… llama_model_loader: - kv 29: tokenizer.ggml.token_type arr[i32,262144] = [3, 3, 3, 3, 3, 4, 3, 3, 3, 3, 3, 3, … llama_model_loader: - kv 30: tokenizer.ggml.bos_token_id u32 = 2 llama_model_loader: - kv 31: tokenizer.ggml.eos_token_id u32 = 106 llama_model_loader: - kv 32: tokenizer.ggml.unknown_token_id u32 = 3 llama_model_loader: - kv 33: tokenizer.ggml.padding_token_id u32 = 0 llama_model_loader: - kv 34: tokenizer.ggml.add_bos_token bool = true llama_model_loader: - kv 35: tokenizer.ggml.add_sep_token bool = false llama_model_loader: - kv 36: tokenizer.ggml.add_eos_token bool = false llama_model_loader: - kv 37: tokenizer.chat_template str = {# Unsloth Chat template fixes #}\n{{ … llama_model_loader: - kv 38: tokenizer.ggml.add_space_prefix bool = false llama_model_loader: - kv 39: general.quantization_version u32 = 2 llama_model_loader: - kv 40: general.file_type u32 = 10 llama_model_loader: - kv 41: quantize.imatrix.file str = gemma-3-270m-it-GGUF/imatrix_unsloth…. llama_model_loader: - kv 42: quantize.imatrix.dataset str = unsloth_calibration_gemma-3-270m-it.txt llama_model_loader: - kv 43: quantize.imatrix.entries_count u32 = 126 llama_model_loader: - kv 44: quantize.imatrix.chunks_count u32 = 141 llama_model_loader: - type f32: 109 tensors llama_model_loader: - type q5_0: 18 tensors llama_model_loader: - type q8_0: 1 tensors llama_model_loader: - type q3_K: 36 tensors llama_model_loader: - type iq4_nl: 72 tensors print_info: file format = GGUF V3 (latest) print_info: file type = Q2_K - Medium print_info: file size = 219.87 MiB (6.88 BPW) load: printing all EOG tokens: load: - 106 (’<end_of_turn>’) load: special tokens cache size = 6414 load: token to piece cache size = 1.9446 MB print_info: arch = gemma3 print_info: vocab_only = 0 print_info: n_ctx_train = 32768 print_info: n_embd = 640 print_info: n_layer = 18 print_info: n_head = 4 print_info: n_head_kv = 1 print_info: n_rot = 256 print_info: n_swa = 512 print_info: is_swa_any = 1 print_info: n_embd_head_k = 256 print_info: n_embd_head_v = 256 print_info: n_gqa = 4 print_info: n_embd_k_gqa = 256 print_info: n_embd_v_gqa = 256 print_info: f_norm_eps = 0.0e+00 print_info: f_norm_rms_eps = 1.0e-06 print_info: f_clamp_kqv = 0.0e+00 print_info: f_max_alibi_bias = 0.0e+00 print_info: f_logit_scale = 0.0e+00 print_info: f_attn_scale = 6.2e-02 print_info: n_ff = 2048 print_info: n_expert = 0 print_info: n_expert_used = 0 print_info: causal attn = 1 print_info: pooling type = 0 print_info: rope type = 2 print_info: rope scaling = linear print_info: freq_base_train = 1000000.0 print_info: freq_scale_train = 1 print_info: n_ctx_orig_yarn = 32768 print_info: rope_finetuned = unknown print_info: model type = ?B print_info: model params = 268.10 M print_info: general.name = Gemma-3-270M-It print_info: vocab type = SPM print_info: n_vocab = 262144 print_info: n_merges = 0 print_info: BOS token = 2 ‘’ print_info: EOS token = 106 ‘<end_of_turn>’ print_info: EOT token = 106 ‘<end_of_turn>’ print_info: UNK token = 3 ‘’ print_info: PAD token = 0 ‘’ print_info: LF token = 248 ‘<0x0A>’ print_info: EOG token = 106 ‘<end_of_turn>’ print_info: max token length = 48 load_tensors: loading model tensors, this can take a while… (mmap = true) load_tensors: CPU_Mapped model buffer size = 219.87 MiB …………………… llama_context: constructing llama_context llama_context: n_seq_max = 1 llama_context: n_ctx = 4096 llama_context: n_ctx_per_seq = 4096 llama_context: n_batch = 2048 llama_context: n_ubatch = 512 llama_context: causal_attn = 1 llama_context: flash_attn = 0 llama_context: kv_unified = false llama_context: freq_base = 1000000.0 llama_context: freq_scale = 1 llama_context: n_ctx_per_seq (4096) < n_ctx_train (32768) – the full capacity of the model will not be utilized llama_context: CPU output buffer size = 1.00 MiB llama_kv_cache_unified_iswa: creating non-SWA KV cache, size = 4096 cells llama_kv_cache_unified: CPU KV buffer size = 12.00 MiB llama_kv_cache_unified: size = 12.00 MiB ( 4096 cells, 3 layers, 1/1 seqs), K (f16): 6.00 MiB, V (f16): 6.00 MiB llama_kv_cache_unified_iswa: creating SWA KV cache, size = 1024 cells llama_kv_cache_unified: CPU KV buffer size = 15.00 MiB llama_kv_cache_unified: size = 15.00 MiB ( 1024 cells, 15 layers, 1/1 seqs), K (f16): 7.50 MiB, V (f16): 7.50 MiB llama_context: CPU compute buffer size = 513.25 MiB llama_context: graph nodes = 799 llama_context: graph splits = 1 common_init_from_params: KV cache shifting is not supported for this context, disabling KV cache shifting common_init_from_params: added <end_of_turn> logit bias = -inf common_init_from_params: setting dry_penalty_last_n to ctx_size = 4096 common_init_from_params: warming up the model with an empty run - please wait … (–no-warmup to disable) main: llama threadpool init, n_threads = 4 main: chat template is available, enabling conversation mode (disable it with -no-cnv) main: chat template example: <start_of_turn>user You are a helpful assistant ...