AIの世界も「フリーランチは終わった」になってきてるのでは

去年くらいに作ったRAGなどAI関連のシステムを、単に今年4月のモデルに差し替えるだけで性能向上した、というのはいろいろなところであるように思います。
コーディングエージェントが、一部先進的な人だけではなく広く使われだしたのも、2月のClaude 3.7や5月にClaude 4による性能向上があってこそだと思います。

ただ、こういった、モデルを差し替えるだけでなんでも性能向上するというのは終わりつつある気がします。
2004年ごろまで続いたCPUのクロック向上が終わって、CPUを差し替えるだけで何でも性能向上する時代が終わったときに「フリーランチは終わった」と言われました。マルチコアによる並列化で性能を出すようになると、コードを並列対応に書きかえないと性能があがらなくなります。

同様に、AIも「フリーランチは終わった」になりつつあるんじゃないでしょうか。
「フリーランチは終わった」というのは元々数理最適化で万能の最適化アルゴリズムはないという話なので、AIに戻ってきたとも言えそう。
ノーフリーランチ定理 - Wikipedia

ここで、OpenAIのモデルを例に、AIの劇的進化を支えた技術をあげておきます。GPT4以降で公式な発表はないので、噂レベルで、だいたいこうなってるらしいというものになってますが、他社のモデルもだいたいこういう技術で性能向上してるようです。

モデル 技術 影響
GPT3 学習時スケーリング 金をかければ性能あがるんや、とがっつり金をかけたら性能があがった
GPT3.5 チャット対応とRLHF チャット対応したら普通の人に使えるように。人による評価で強化学習をすることでチャット対応のよさも向上
GPT4 MoE 比較的小さい たくさんのエキスパートモデルを選んで動かすことで、レスポンス向上、運用コスト低下。
つまり運用コストをおさえつつ性能があげれるように。
o1 Reasoning 「ステップバイステップで考えて」とすると問題解決力があがるというプロンプトテクニックをモデル自体に適用。
推論時スケーリングの始まり
o3 Agent Reasoningでのthinkingを並列で複数行って、判定モデルに選ばせた思考に基づいて出力を得る

o3の並列思考については噂レベルですが、Gemini 2.5 ProのDeep Thinkについてはこちらのレポートに。(P.9の最後)
https://storage.googleapis.com/deepmind-media/gemini/gemini_v2_5_report.pdf

ここで、o1やo3になると、問題解決力はあがるけど創作に弱くなるといった苦手が出てきています。
GPT4までのようにモデルの能力があがると基本的には全方面で性能があがっていたのと違ってきています。
reasoningも含め、エージェント的な動作が入ってくると、得意不得意が出てくるような気がしています。

ただ、思考力の高いモデルが出ると、データセットの作成や学習時の評価も高度化できます。おそらく、そういった面がGPT4.1や4.5などの性能向上につながってるんじゃないかと思います。
同様に、DeepSeekのようにデータセット作成に自由に使える高性能モデルが、比較的小規模なオープンウェイトモデルの性能につながってるようにも思います。

問題は、これ以降で性能向上につながるような大きな改善点がなかなか見当たらないことです。Agent動作での思考の並列化を増やしたり枝分かれ構造化したツリーにしたり(ToT: Tree of Thought)といった性能向上はあるけど、対応領域は狭まるように思います。

今後は、万能の性能向上のペースは落ちて、問題領域に特化した作りこみが必要になり、そういう意味で「フリーランチは終わった」なのではないでしょうか。

これは、逆にいうと、がんばって作っても高性能モデルで駆逐みたいなのでヤル気をなくしがちだったのが終わって、作りこみ勝負になってきてAIシステムの作り甲斐も出るんじゃないかと。

もちろん、CPUがクロック向上が終わっても地道な改善によりシングルスレッド性能があがったように、モデル単体の性能も地道にあがっていくとは思います。

AIでプログラマ不要になるというのは、プログラミング言語構文わかればプログラム組めるという誤解に基づくのでは

AIで日本語で指示をあたえればプログラムを作ってくれるようになって、プログラミング知識がなくても誰でもプログラムが組めるとか、プログラマが不要になるとかいう話が盛り上がってますね。
けど、実際にプログラマをやって、AIコーディングエージェントを使っていれば、プログラミング知識がなくても可能な領域というのはそんなに広くないことを感じていると思います。

たとえば、ほぼプロンプト一発で作ってもらった刺身タンポポゲームがあります。
このプロンプトはこんな感じです。

刺身にタンポポを乗せるゲームをJavaのSwingで作って。

刺身かネコが0.75秒ごとに表示されます。
刺身は、白い皿に、赤い板状の切り身が3枚のっています。
ネコは顔だけ表示されます。かわいくおねがいします。
表示のシーケンスは次のようになります。
共通の影が右から中央に0.1秒で移動します。
刺身かネコが0.5秒表示されて、0.1秒で左の画面外に移動します。0.05秒は何も表示されません。
タンポポは、黄色くて花びらが12枚ある花です。キーを押すと上から降りてきて置けます。

刺身が表示されているときにタンポポを置くと「成功」と表示して点になります。
なにもないときに置くと減点です。
ネコに置くと、にゃーと表示されてライフが減ります。
さしみにタンポポ置けなくてもミスで「失敗」と表示。
判定はキーを置いた時点で行います。
ライフは最初3つあり、0になるとゲームオーバー。
ゲームオーバー時に、成功、失敗、ねこの回数を表示して。

フォントはsans serifで。timerのあいまいな参照に気を付けて。

これは日本語での宣言的プログラミングですね。
表示の調整はコードをいじったけど、プロンプトでも可能だと思います。

ちゃんと実用にそった処理を行おうとすると、どんどんこういった宣言的プログラミングが大事になっていきます。

それにもかかわらず、プログラミング知識不要とかプログラマが不要になるとか言われるのは、世の中でいう「プログラミング知識」にそもそも誤解があるんではないかと思います。
プログラミング言語の文法を知ってればプログラムが書ける」という誤解です。
そういう誤解があるから「プログラミング言語の文法を知らなくていいのであれば誰でもプログラムが書ける」となっているんだと思います。

それは、世の「プログラミング入門書」を見るとわかります。
ほとんどの「プログラミング入門書」が、単にプログラミング言語の文法とライブラリを解説したものになっています。
けれども、多くの人が「入門書が終わったのにプログラムが組めるようにならない」と悩んでいます。
実際のところ、文法を勉強しただけではプログラムが組めるようにはならないですね。

プログラミングというのは知識があればできるものではなく技能です。
AIは、プログラミング知識がなくてもプログラムを作れるかもしれないけど、プログラミング技能は必要です。
プログラミングの勉強をしてなくても他の職能の転用で、ある程度のプログラミング技能がある人はいますが、プログラミング技能を得るための近道はプログラミングを学ぶことです。

プログラミング技能とは何かと一言でいうのは難しいですが、大事なところは「書くこととコンピュータの振る舞いを結び付ける」ということです。 そのためには、どのように書けばどのようにコンピュータが動くか、コンピュータにはどのような制約があるか、どのような処理が可能かといったことを実感する必要があります。
プログラミング言語は最初の入り口というだけで、書いたことと動きの対応の実感、そもそもプログラムとして書ける処理、書けるけど動かせない処理の把握が重要です。

なので「プロになるJava」では最初にJava用シェルであるJShellを使って、一行入力して実行結果を見せて、入力とコンピュータ動作の対応を実感することから始めています。 また、アルゴリズムや計算複雑性という話をとりこんで、「言語の文法を知っただけでプログラムが組めるわけではない」ということを伝えるようにしています。

以前に、「必要なのはプログラミング知識ではなくコンピューティング知識」と書いたのですけど、プログラミング知識の大部分は「コンピューティング知識」なんですよね。
AI時代に必要なのはプログラミング能力ではなくコンピューティング能力 - きしだのHatena

「コンピューティング知識」を身につける近道もプログラミングを勉強することです。

ということで、「AIでだれでもプログラムを組める」「AIでプログラマが不要になる」というのは、「プログラムというのはプログラミング言語の文法しってれば書ける」という誤解に基づいて「プログラミング言語の文法を知らなくていいならだれでもプログラムを組める」となっていて、そんなことはないって話でした。

Tool Useが効かないDevstralでコーディングエージェントを作る

Mistal.aiからMistral 3.1 Smallをベースにしたコーディング専用モデルDevstralが出ていたので、これを使ってエージェントを作ろうと思ったのです。
Devstral | Mistral AI

Devstralは、24Bというサイズで他の大きなオープンウェイトモデルも凌駕するコーディング性能を出しています。

ベンチマークは当てにならないことも多いですが、使い比べた実感としても確かにQwen3 235B-A22BやDeepSeekよりもコードを書くという印象です。

これを、以前作った、Tool Use(Function Calling)を使った雑なコーディングエージェントで使ってみようと思ったわけです。
LangChain4Jで雑なAIコーディングエージェントを作る - きしだのHatena

けど、DevstralがTool Useに対応してないようで、うまく動きませんでした。 でもRoo Codeは動いてるな、とシステムプロンプトを見てると、独自にXML形式を定義して出力させています。
ということで、XML形式を指定して自力でパースするのを試してみました。

システムプロンプトはこんな感じ。CDATA使うなというのはGemma3のために書いてるんですが、ここまで書いてもGemma3はCDATAを使うので、ちょっとあきらめ。

you are coding agent.
generate source codes following user instruction.
you must generate whole code to run the user intended system including configuration and build script.
you must make readme.md file including the feature, file structure, how to build, how to run.

all generated source codes including readme.md must be in the xml format below.
code tag start and end must be separated line.
<source>
<filename>path of code</filename>
<code>
the code that must use entity reference. not use use CDATA tag.
</code>
</source>

そうするとだいたいこんな出力になります。

出てきた出力を、こんな感じのパーサーで解析します。

    void consume(char ch) {
        buf.append(ch);
        if (state == State.PLAIN) {
            handler.plain(ch);
        }
        if (ch != RET) {
            return;
        }
        String str = buf.toString();
        buf.setLength(0);
        switch (state) {
            case PLAIN -> {
                if (str.startsWith("```")) {
                    formatted = !formatted;
                } else if (str.trim().equals("<source>")) {
                    state = State.IN_XML;
                    handler.sourceStarted();
                }
            }
            case IN_XML -> {
                if (str.startsWith("<filename>")) {
                    String name = str.substring("<filename>".length(), 
                            str.length() - "</filename>\n".length());
                    handler.filename(name);
                } else if (str.trim().equals("<code>")) {
                    state = State.IN_CODE;
                } else if (str.trim().equals("</source>")) {
                    state = State.PLAIN;
                    handler.sourceEnded();
                }else {
                    System.out.println(str);
                }
            }
            case IN_CODE -> {
                if (str.trim().equals("</code>")) {
                    state = State.IN_XML;
                } else {
                    String code = str.replaceAll("&lt;", "<").replaceAll("&gt;", ">"
                            .replaceAll("&quot;", "\"").replaceAll("&amp;", "&"));
                    handler.code(code);
                }
            }
        }            
    }

なんか いい感じに動きました。6倍速で、実際は3分くらいで生成が終わってます。

ここではcreate tableしてなくてエラーになるので「テーブル定義のSQLがないよ」と指示してあげると、schema.sqlを作ってくれました。

エラーが出たときにエラーログを渡すと修正してくれたりもします。
簡単なコードだけど、想像以上にちゃんと動いてくれました。

完全なコードはこちら。
https://gist.github.com/kishida/bc7cec2d036c906111a5be93f1159870

OuteTTSでテキストの音声化を試す

OuteTTSというののv1.0が出てたので試してみました。

前回のブログ内の文章を適当に読ませてみました。
風邪ひいてるときに読んだマンガ - きしだのHatena

「勇者」「美女」を読めなかったり「平和」が「ピンフ」になったりするので、書き換えています。あと、英語女性話者のプロファイルしかないので、英語訛りになってますね。

ということで、「勇者を暗殺するために・・・」の一文を読み上げて食わせてみたら、なんか訛りが入りつつそれっぽく話しています。

gradioとoutettsが必要です。

pip install gradio outetts
import gradio as gr
import tempfile
import os

from outetts import Interface, ModelConfig, GenerationConfig, Backend, InterfaceVersion, Models, GenerationType
from outetts import LlamaCppQuantization

interface = Interface(
    ModelConfig.auto_config(
        model=Models.VERSION_1_0_SIZE_1B,
        # backend=Backend.HF,
        backend=Backend.LLAMACPP,
        quantization=LlamaCppQuantization.Q4_K_S,
    )
)

speaker = interface.load_default_speaker("EN-FEMALE-1-NEUTRAL")

# speaker = interface.create_speaker("yusha.wav")
# interface.save_speaker(speaker, "yusha.json")

# speaker = interface.load_speaker("yusha.json")

def text_to_speech(text):
    output = interface.generate(
        GenerationConfig(
            text= text,
            speaker=speaker,
        )
    )
    with tempfile.NamedTemporaryFile(delete=False, suffix=".wav") as fp:
        output.save(fp.name)

        return fp.name

# Gradioインターフェース
iface = gr.Interface(
    fn=text_to_speech,
    inputs=gr.Textbox(label="テキストを入力"),
    outputs=gr.Audio(label="生成された音声"),
    title="OuteTTS",
    description="テキストを入力すると音声(WAV)を生成して再生します"
)

iface.launch()

風邪ひいてるときに読んだマンガ

風邪ひいて土日は寝てたりして、だいぶマンガを雑に読んでたので面白かったののメモ。
異世界多し。

気絶勇者と暗殺姫

勇者を暗殺するために美女3人がパーティーを組んで暗殺を狙うという話だけど、裏切りとかもなく平和。
6/14まで2巻まで無料で読める。

凶乱令嬢ニア・リストン

死にかけ病弱令嬢に転移して、最強令嬢で悪い人をのしていくやつ。
強すぎていい。

ところで、異世界に生まれなおすのが転生で、異世界にそのまま若返ったりしつつ移動するのが転移なんだけど、死んだ人の肉体に魂だけ入るのなんていうんだろう?今回は転移と書いてます。

黒岩メダカに私の可愛いが通じない

話もかわいいけど、絵がかわいい。
表紙でわかるけど、チェックが手書きで、衣服の立体感がすごい。
6/5まで3巻まで無料で読める

最強で最速の無限レベルアップ

俺ツエーものなんだけど、話が平和でよい。
6/10まで2巻まで無料で読める。

あたしメリーさん。いま異世界にいるの……。

捨てた人形から電話がかかってくるやつ。
なぜかメリーさんは異世界に飛ばされて、魔王をたおして元の世界にもどって主人公の後ろにたつことを目指して戦う。

偽聖女クソオブザイヤー

これも悪役聖女に転移して、悪い人をのしていくやつ。
強すぎていい。
6/10まで2巻まで無料でよめる

ずっと青春ぽいですよ

アイドル研究部でわちゃわちゃするやつ。平和でよい。 キラキラしてない「2.5次元の誘惑」という感じ。それかドタバタしてない「究極超人あ~る」、つまり地味部活青春コメディ。

念願の悪役令嬢の身体を手に入れたぞ!

病弱だった女の子が、名前のとおり悪役令嬢に転生して、魔物とかをのしていくやつ。
つよすぎるし、かわいくていい。
6/3まで1巻が無料で読める

追放された転生重騎士はゲーム知識で無双する

不遇職である重騎士にゲーム内転生して成果をあげていくやつ。

モブ高生の俺でも冒険者になればリア充になれますか?

現代にダンジョンができて、冒険者になると高校のクラス内カーストで上位になれる、という世界。 で、冒険者になるけど、クラス内カーストとか関係なく仲間と強くなっていく。
6/5まで2巻まで無料で読める

MIX

親が再婚して兄弟になったピッチャーキャッチャーと妹の話。
あだち充のよくあるやつ。
そしてやっぱり人が死ぬ・・・

魔術ギルド総帥

暗殺された魔術ギルド総帥が自殺したいじめられっこに転移して、俺ツエーやるやつ。
教科書通りの俺ツエーをやっててよい。

母という呪縛 娘という牢獄

教育虐待から抜け出すため、母を殺した娘の、その母を殺すまでの過程。
平和ではない。

AIエージェントの流れはAGI(汎用人口知能)から一旦離れる流れ

AIコーディングエージェントが流行りだしてますね。 AIコーディングエージェントでは、いろいろなロジカルな処理でLLMを制御することで、プログラミングの計画をたて実装してテスト、修正といった流れを実行します。

このAIコーディングエージェントを病院の診察室に持っていっても、うまく診療したりしませんね。 診療のためのエージェントは診療エージェントとして特別に実装する必要があります。

つまり、AIエージェントって独自実装で専門家していきます。

エージェントの核になるLLMは、どのような要件にも使える汎用の知能部品です。LLMが賢くなる流れは、AGI(汎用知能)に近づくものだったと思います。

けど、LLMの性能は上限が見えてきて、例えばthinkingの過程を入れて性能向上するようになってきています。

LLMの性能が頭打ちしてくる中で、このままLLMの性能をあげるだけではタスクを実行完了できるようにならないということで、ロジックでLLMを制御して全体処理の制御をやるというのがエージェントのひとつの形です。 こういって細分化専門家したAIエージェントを統合というのは難しいとおもうので、これはAGIから一旦離れる流れだと思います。

AGIも、ロジックをもったゲートキーバーが専門のAIエージェントに処理を振り分ける仕組みになるかもしれないですが、それはそれで作りこみが必要そうです。ただ、その場合に必要とされるAIエージェントは多岐にわたりそう。

ということで、まあしばらくは、ひとつの人口知能がなんでもできるというものから、作りこまれた専用エージェントが特定タスクをこなすという、AGIから少し離れていくのですね。

そうやってそれぞれの分野について専門家して適応が進む裏で、なにかTransformerに手がはいって、今と違うDiffusion LLMだったりRWKVだったりが進化してAGIに近づいてた、ってなるんですかね。

関係ないけどお話がかわいいので

LLMの日本知識を測るのに山口県について聞くのがよかった

山口県の特徴は?」でLLMの日本語知識が割と測れる気がしたので16GB VRAMで動く範囲でいくつかオープンモデルを試しました。

結論としては、日本語でのチャットなど日本語表現力が必要なら、オープンモデルではGemma3一択。
法律や商慣習に関わる処理や観光地での案内に使うなど、確実な日本知識が必要な場合、また1GB程度のサイズで日本語応対する場合などはLLM-jp-3がおすすめです。

Gemma3、Qwen3、ABEMA Qwen2.5 32B Japanese、LLM-jp-3、Sarashina2.2を試していきます。

Gemma3

まずGemma3。27Bで見てみます。
石見銀山」「津和野の石州和紙」と、島根がちょっと混じっていますが、どちらも「萩・石見空港」だったり「萩・津和野」と山口県萩市知名度を借りたマーケティングが行われがちなので、ちょっと仕方ない。

他は変なところはないのと、津和野の和紙を「津和野和紙」と呼ばず「石州和紙」と呼ぶなど知識あることも示されていて、普通に日本に関して対話するくらいだと問題なさそうな知識をもっていそうです。

あと、表現力を見るために「山口県の特徴をギャルっぽく紹介して」とやってみます。

性格よさそう。これはきっとオタクにやさしいギャル。
そういった感じで、言葉遣いが変わるだけじゃなくポジティブさも出てたり、すごく表現力あります。
ただし「まじ卍」が好きすぎるので、実際に使うときにはシステムプロンプトで禁止したほうがよさそう。 12Bでも結構使えます。

ただ、4Bになると知識はかなり怪しいので、知識が問われる用途は避けたほうがいいです。

Qwen3

一般的な常識やコーディングに強いQwen3は、日本固有の知識には弱いです。
最大のモデルであるQwen3-235B-A22Bでも次のようになりました。

津和野町が入ってますが、これはまあヨシ。

阿武火山群国定公園・・・そんな国定公園は ない・・・
しかし、阿武火山群というのがあるというのは、これで初めて知りました。ということで国定公園ではないものの実在は している。
https://www.data.jma.go.jp/vois/data/fukuoka/512_Abu/512_index.html

しかし、長崎の軍艦島を大島郡上関町というところに持ってきたり(上関町は熊毛郡)、石川県の日本酒「白山」があったり。

碧城という酒はなさそうなんだけど、Googleさんもしっかりだましてくれました。福岡に小野酒造なさそう。

ついでに「山口県の特徴をギャルっぽく紹介して」をやってみます。

それっぽくはあるけど、語尾を「~」で伸ばせばギャルになると思っている節がある。

ということで、もっと小さいモデルについては推して知るべしという感じで、知識は間違いだらけになっていきます。
日本固有のあまり世界的に有名ではない情報を扱うときにはQwen3は避けたほうがよさそう。
また、「角島大桥」のような漢字が出てしまうので、日本語での自然な対話を目的とするときには避けたほうがいいですね。

ABEJA Qwen-2.5 32B Japanese v1.0

そんなことを書いているところにちょうどABEJAから日本語継続学習を行ったモデルが出ていたので試してみます。
https://huggingface.co/abeja/ABEJA-Qwen2.5-32b-Japanese-v1.0

観光はちょっと怪しく、周防大島青海苔は特に有名ではなく、安芸の島は実在しなさそう。大筋あってる、というところ。

2bit量子化モデルで試しているので、8bitや4bitだともう少しマシかもと思うと、悪くもなさそう。

そして「山口県の特徴をギャルっぽく紹介して」

これはいいですね。Gemma3よりはおとなしい。

知識に関してはそこまで期待しないほうがいいけど、表現力はかなりあるのがわかります。
これは、開発が日本語読解や要約など日本語操作力をあげるという方向性だったことも現れているように思います。
ただ、回答が短くまとまる傾向がありそう。

ちなみに、ベースになったQwen2.5 32B Instructの2bit量子化で見てみると未知の情報にあふれているので、かなり日本語知識も改善されていることがわかります。

ギャルというより、ふつうのフレンドリーな若い人って感じですね。

LLM-jp-3

日本知識や日本語能力となれば、最初から日本語情報を学習したLLMが強いはず。 ということで、大規模言語モデル研究開発センターが開発したLLM-jp-3を試してみます。
LLM-jp-3 172B: オープンかつ日本語に強いGPT-3級大規模言語モデル | 国立情報学研究所 大規模言語モデル研究開発センター
LLM-jp-3 MoE シリーズ の公開 | 国立情報学研究所 大規模言語モデル研究開発センター
LLM-jp-3 1.8B・3.7B・13B の公開 | 国立情報学研究所 大規模言語モデル研究開発センター

大規模言語モデル研究開発センターは昨年4月に国立情報学研究所が解説した研究所です。
国立情報学研究所に「大規模言語モデル研究開発センター」新設~国産LLMを構築し、生成AIモデルの透明性・信頼性を確保する研究開発を加速〜 - 国立情報学研究所 / National Institute of Informatics

13B

13Bを4bit量子化で試してみます。
香月泰男、知らなかったけど山口県出身。宇部科学技術館は違いそう。だけど、かなり詳しく具体的な記述。

ギャルかな?回天記念館は渋い。

3.7Bの4bit量子化もかなりまとも。マツダ工場があるのは防府市で、山陽小野田市マツダの部品を作ってる会社の工場、という細かい指摘くらい。

そして方言ギャルか

MoE 8x1.8B

次にMoEモデルの8x1.8Bを試します。
内容に誤りなし。毛利氏庭園のようなマイナーどころも。

「ギャルっぽく」はちょっとガラが悪いかな。「日本三名 bridge 」はちょっと残念。1.8Bベースなので4bit化の悪影響が強いかも。

980m

980m(0.98B)でここまで答えるのはすごい。200tok/s出るし。
宮島(広島)が入ったりするのはご愛敬。

まとめ

ただ、絵文字はかなり苦手そう。ちょっと山口弁使ってるのはいいとこ。

山口弁で試すと、大きく外れてはなくて、山口弁っぽい表現もあるけど、「ぶち」とかは使われていないな。

全体に見て、日本知識はかなり高く、表現はそこまで得意ではない感じ。

ただ、コーディングには使えないですね。あまりコーディング能力は高くない。

1.8Bはちょっとバグ?

あと、8x1.8Bは、こんな感じで指示を突っぱねられることが割とありました。

と思ったら、ベースになってる1.8Bがよくわからない理由で弾いてきたりするので、この挙動を引き継いでるみたい。

1.8Bは「ギャルっぽく」も弾かれたりしているので、無用にリクエスト却下しがちかもしれない。

Sarashina 2.2

もうひとつ最初から日本語で学習したモデルとして、Sarashina 2.2 Instructを。
Sarashina2.2-Instruct:コンパクトかつ性能の高い日本語Instructモデル - SB Intuitions TECH BLOG

日本語表現力としては、英語入りがちということがあって期待できないですけど、日本語知識はかなり高そうです。

3B

内容かなりしっかりしてます。

でもなんか英語使いすぎ。

1B

これも問題なし。

やはり英語使いたがりですね。

0.5B

ちょっと怪しいですが、モデルサイズ500MBでここまで答えるのすごい。

怪しい風習が英語まじりで紹介されています。