量子化12bは、パラメータあたり8ビットで12G（基本的にはロスレス）、4ビットで6G（一般的に受け入れられている「かなり近い」レベル）を意味する。悪くない？でも、量子化について考える前にベースモデルのパフォーマンスがどれくらいかはまだ不明だね。

一般的な意味では「エンコーディング」だと思うけど、彼らが言ってるのは「エンコーダー」ニューラルネットワークがないことを指してるんじゃないかな。

実際、エンコーダーとは違って、潜在空間がその初期層で訓練されてるから、まさにそのスパースな密度に対して「何をすべきか」を理解してるんだ。Gemma4-12bをFlux2で使ってるけど、視覚入力に対する推論能力はかなり良いよ。とはいえ、各モデルにはそれぞれの良さがあるから、使う人によって違うかもしれないけど、全体的にはQwenと同じくらいしっかりしてる。ただ、もっと進んだアーキテクチャを持ってるって感じ。

一つの副作用として、モデルをllama.cppなどで使うときに、別の.mmprojファイル（マルチモーダルプロジェクションエンコーダー）がもう必要なくなるんだ。

その開発者ページの中には、エンコーダーフリーアーキテクチャの良い説明があるよ。https://newsletter.maartengrootendorst.com/p/a-visual-guide-...

エンコーダーフリーは、SBCなどで動かすのに大きいね。VLMをオールマイティなビジョンモデルとして使う場合、エンコーディング時間が生成時間のかなりの部分を占めることが多いから。

オーディオの方がさらに面白いね。位置埋め込みを完全に取り除いて、LLMの入力次元に合わせるために単一の線形変換を行ってるだけみたい。 「オーディオ：オーディオ処理をさらに簡素化しました。オーディオエンコーダーを完全に取り除き、生のオーディオ信号をテキストトークンと同じ次元空間に投影しました。」

これは基本的に早期の融合って感じだね。FAIRは2年前にこれをやってたし。https://arxiv.org/abs/2405.09818 それ以来、こういうのが出るのを待ってたんだ。ちょっとイライラするのは、カメレオンも同じ原理に基づいてマルチモーダルだったのに、今回のモデルは入力だけなんだよね…（マルチモーダル出力なしで事前学習をどうやったのか気になるな。画像出力をサポートする代わりに切り捨てたのかな）。

エンコーダーなしのVLMには多くの前例があるよ。約2年前のEVEシリーズのモデルを特に覚えてる。https://github.com/baaivision/EVE

埋め込みモデルでできることはまだまだ底を打ってないと思うよ。これらの小さなモデルは、8ビット整数の最適化が施された現代のCPUでめちゃくちゃ速いからね。俺のアプリでは、普通のハードウェアで何億もの場所についてかなり明確なことが言えるんだ。

うーん、実際にFOSSリリースをしてる企業（Gemma 4はApache 2.0ライセンスでリリースされてる）と、FOSSリリースをしたことがない企業を比べるのはちょっと不公平な気がするな。ほとんどが「ダウンロード可能」の独自リリースをしてるだけだし。

このモデルリリースはちょっと残念だな。コミュニティは124ba4bモデルを待ち望んでたから。漏れた情報もあったけど、性能がGemini Flashに近すぎたからリリースされなかったんじゃないかって疑ってる人もいるね。

他のGoogleモデルは、qwenモデルに比べるとかなり弱く感じた。マルチモーダルに関してはあまり使い道がないから、もしかしたらこれは素晴らしいマルチモーダルモデルかもしれないね。

AIラボなら、この分野に研究チームを置きたいよね。ここが一番簡単に反復して改善できる場所だから、その成果を大きなフロンティアモデルに組み込めるし。問題は、モデルをリリースしたいのか、それとも純粋にR&Dのためだけに使いたいのかってこと。みんな似たようなクオリティのモデルをリリースしてるから、参加することが自分を苦しめるとは言えないよね。リリースによる競合の影響はほぼゼロだから、評判の向上を考えればやる価値はありそう。

競合の足場を壊して、Googleがあまり気にしていないセグメントでお金を稼がせないようにするためだね。でも、簡単に商品化できるから、あまり気にしなくてもいい。

これは商業的に実現可能な収益を生む代替品を置き換えるものではないけど、開発活動を促進して、このモデルから始めてもう少し進みたい企業との会話を始めることができる。今のところ、うちの会社はプラットフォーム製品に全力投球してる。あと、昨日Microsoftが「無制限のインテリジェンス」を目指してるって言ってたし。小さなローカルモデルで実現できることはたくさんあって、それらは他のレイヤーで収益を生むスタックの一部でもある。

OpenAIとAnthropicを無力化するのが私の予想だね。商品化されたLLMは、Googleにはあまり影響しないけど、LLM専業の会社には大きなダメージを与えるから、避けられないことを加速させることで、今Googleがたくさんお金を稼いでいる分野での将来の競争相手を排除するのに役立つ。

AndroidとChromeにはデバイス上のAI機能が必要だね。Googleはサーバー側のMLのように重みをロックできないから、誰かがどうせハックすることになるし、オープンソースとしてモデルをリリースして公式にする方が簡単だよ。

GoogleはAIの中で数少ない縦型の選択肢の一つだね。データ、モデル、クラウドサービス、低レベルのシリコン（TPU）、内部利用ケース、小売利用ケース、B2B利用、配信（ブラウザ＆モバイル）などがある。AIの普及と共に成長してるけど、人々がGoogleのソリューションを選ぶと、さらに地盤を固めることになる。Googleモデルに送られるトークン（無料でも有料でも）は、競合他社に大きな出費を強いることになるから、実質的に競争を妨げることになるんだ。

Frontier Labsが推論で80%の粗利を取れるのは、フロンティアモデルという独占リソースがあるからだね。その推論が人気になって、企業が何十億ドルも利益を上げるようになったら、その利益を使って代替製品やプラットフォームの構築に資金を回せる。Googleはすでに80%の粗利を出してるビジネスを持ってるし、世界で一番大きい。みんなその一部が欲しいんだよね。フロンティア推論をコストに近い形で提供して、サブフロンティアのものをオープンソースにすることで、フロンティアラボのモデルを商品化してるから、推論で高い粗利を持続的に得る能力を妨げてる。これは戦略的な動きだね。

中国の企業が良いオープンモデルを出し続ける限り、Googleが「無料」スペースで競争するために最先端の小型モデルを出すことに大きなデメリットはないと思う。

デバイス上で、例えば Android みたいに。

MLXはまさにmacOS専用の技術だよ。他のプラットフォームではMLXじゃない方がいいと思う。最初は「MLX」が「Metal-なんとか」だと思ってたけど、どうしてもその参照が見つからないな。まあ、「Metal」はAppleのプラットフォームでのハードウェアアクセラレーションされたグラフィックスってことは知ってる。追記：Ollamaの実際のリリースについてだけど、Apple以外のハードウェアを使ってるなら、最近アップロードされた「gemma4:12b-nvfp4」バリアントがいいと思うよ。特に最近のnvidia GPUを使ってるならね。

MLXはAppleの独自の機械学習フレームワークで、Apple Silicon向けに設計されてるよ。https://opensource.apple.com/projects/mlx/

今、MLX用のCUDAバックエンドがあるよ。成熟度についてはよくわからないけど。

こんな質問にちゃんとした、有用な回答をしてる人をまだ見たことがないな。

「小さい」モデルは、自分のペースで動かせるやつだね。LLMは、16GB VRAMのGPUに何百ユーロも使う価値がないから、他のデスクトップパーツが余ってるとしてもね。前にチェックしたとき（RAMの価格が上がる前）、これらのモデルは4-8GBのものと大して変わらなかったし、SaaSバージョンに近いものを得るには24GBや32GBのトップクラスのカードが必要だったと思うけど、それは完全に予算オーバーだった。状況が変わっても、ハードウェアの価格も変わってるから、結局同じ結果になるだろうね。

小さなモデルは特定のタスクにすごくいいニッチがあると思う。私は、約3.5GBのRAM（VRAMじゃなくて）に収まる微調整されたPhi-4モデルを使ってるんだけど、これは私が開発しているデスクトップアプリのドキュメント処理に使ってるんだ（ちょっと宣伝になっちゃうけど - whistle-enterprise.com）。ローカルモデルを使う具体的なアイデアがあれば、すごくうまく機能させる方法が見つかるよ。グラフィックカードやNPUチップも必要ないし。ただ、使い方にはすごく制約があるけどね。一般的なチャットボットとしてはあまり良くないと思うから、ホスティングされたSOTAモデルを使うかな。私自身、ローカルLLMの大ファンだし。

自作のディクテーションアプリがあって、ローカルモデルを使ってテキストを整理したり文法を直したりしてるんだ。作るのはすごく簡単だったよ。今は会議のメモを取ったり要約したりする機能も追加してる。全部デバイス内で完結してる。最近、誰かがここに投稿してた小さなアプリを見たんだけど、スクリーンショットを見てファイルの内容に基づいてファイル名を変更するやつだった。こういう小さな例がたくさんあるよ。多くのユースケースでは、最先端のモデルは本当に必要ないと思う。

私は地下のLinuxマシンでvLLMを動かしてて、Tailscaleで接続してる。小さなモデルを使ってこんなタスクをやってるよ： - スキャンした文書をフォーマットされたテキストに書き起こす - 画像にキャプションを付けたり説明したりして、観客に適したものに分類する（スパム対策も含む） - 文書を関連するWikipediaページとマッチさせてタグ付けする これらは最先端モデルのようには使ってないんだ。一つの明確な目標のためにマイクロタスクに分けてる。全体のフローを動かすためにたくさんのグルーソフトウェアを書いてるよ。LLMが登場する前からこれらのタスクに取り組んでたんだ。LLMのおかげで、複雑なコードを少ないコードとモデルで置き換えられて、より良い結果が得られるようになった。コストとコントロールの理由からローカルモデルを使ってる。ワークステーションとGPUはすでに持ってたし。唯一の運用コストは電気代だけ。これらのタスクにはOpenAIやGoogleのプロプライエタリモデルも使ったけど、ツールを作ったモデルが引退したときに困ったこともあった。でも、ローカルにウェイトを保存しておけば心配しないよ。

理論的には、ローカルでは音声の書き起こしや画像のラベリングに対して許容できる損失のあるところでこれを使うことになると思う（単純な例として）。実際には、主にテキスト生成機能を使ってるから、マルチモーダリティに基づく何かを作る時間がまだ取れてないんだ。

Ollamaはllama.cppから分岐したから、マルチモーダリティのサポートにはちょっと時間がかかるだろうね。普通のllama.cppを使ってるなら、このモデルにビジョンとオーディオのサポートが統合されたPRがもうマージされてるみたいだよ：https://github.com/ggml-org/llama.cpp/pull/24077

もう llama.cpp か Unsloth Studio を使えばいいんじゃない？なんでまだ Ollama を使ってる人がいるのか分からないよ。

クロードは入力はマルチモーダルだけど出力はそうじゃないよね。これもそうなってもおかしくないんじゃない？