【geek-terminalニュース】4Bで3Dシーン生成？Qwen系の個人開発モデルとGGUF公開を追う

【事象の全貌と背景】
「4Bで3Dシーン生成」という、小型モデル好きには見逃せない開発報告がr/LocalLLaMAに登場した。投稿者は、汎用コーディングと3Dシーン生成向けに学習中のモデルを早期公開したと説明している。「Small models have been pretty rough at 3D in my tests.」――自分のテストでは小型モデルの3D生成は厳しかった、という出発点が生々しい。今回は、その壁を用途特化の追加学習で越えられるかという実験だ。[原本投稿](https://www.reddit.com/r/LocalLLaMA/comments/1xeuo7t/a_4b_coding_model_that_can_generate_3d_scenes/)

追加照合した配布先では、CCOREによる「Qwen3.5-4B-3D-Coder」と紹介されている。開発者の説明ではQwen3.5-4Bを基にした独立ファインチューニングで、まだプレビュー段階だという。Qwen公式の新製品として扱うべきではなく、性能についても開発者の自己申告と独立した検証を分けて読む必要がある。現時点で「4Bが大型モデルを倒した」と言える比較結果は、今回の資料から確認できていない。[開発者のモデルカード](https://huggingface.co/ccore/Qwen3.5-4B-3D-Coder)

【技術的ディープダイブ】
開発者が示す生成経路は、Three.jsのシーンをHTMLとJavaScriptで組み立てるものだという。注目点は、画面の美しさに加えて、その背後にあるコードが最後まで実行できるかだ。オブジェクトの配置、寸法、視点、アニメーションを一緒に成立させるには、構文の正しさと空間関係の整合性を両方見る必要がある。庭園の画像が一枚きれいでも、視点を回した瞬間に階段が宙へ浮くなら、実用性の評価は変わってくる。

モデルカードの指定は具体的だ。Three.jsは0.160.0のコアESモジュールを使い、アドオンを読み込まず、カメラ操作もHTML内で実装するよう指示している。推奨設定はTemperatureが0.6〜0.8、Top Pが0.90〜0.95、Top Kが20〜40、Repeat penaltyが1.0。配布欄にはQ4_K_Mが2.71GB、Q8_0が4.48GBと表示されている。ただし、これは配布ファイルの容量であり、必要VRAMや実行中の総メモリを意味しない。[配布仕様と生成設定](https://huggingface.co/ccore/Qwen3.5-4B-3D-Coder)

この構成からは、依存するAPIや出力形式を絞って、小型モデルが迷う範囲を減らす設計意図が読み取れる。ただし、これは指定プロンプトからの考察で、性能向上の原因が実証されたわけではない。学習データの内訳、学習率、LoRAの使用有無、同条件でのベースモデルとの差は今回確認できなかった。開発者は変数名の重複を既知の問題に挙げているが、エラー全体の頻度も不明だ。内部アーキテクチャの改変や新たな3D理解機構まで推測する根拠はない。[既知の問題](https://huggingface.co/ccore/Qwen3.5-4B-3D-Coder)

試すなら、まず同じ課題を複数回生成し、無修正で開ける割合、指定した物体の有無、配置の破綻、修正に必要な往復回数を記録したい。Q4とQ8を同じ条件で比べれば、容量の節約とコード品質の交換条件も探れる。これは本稿からの検証提案であり、実測結果ではない。「一発の傑作」を眺める段階から、失敗まで含めて再現する段階へ進めるかが肝になる。

【コミュニティの生々しい熱量と議論】
提供された検索結果ではコメントを取得できていなかったが、原本の再確認では具体的な応答を読めた。jacek2023氏は「Blender向けのファインチューニングを見たい人は多いが、これもサイズが非常にいい」と評価している。作者も、4Bでどこまで3Dシーンを押し上げられるかを探る概念実証だと返信した。読み取れるのは、小さなモデルを手元で試せることへの期待だ。大規模な支持や性能評価の合意まで示すものではない。[コメント欄](https://www.reddit.com/r/LocalLLaMA/comments/1xeuo7t/a_4b_coding_model_that_can_generate_3d_scenes/)

一方、feelspeaceman氏は、Blender向けの追加学習よりもMCPサーバーや、生成物を画像で確認して修正する反復処理が重要だという見方を示し、その方法はトークン効率が悪いとも指摘している。これは本モデルを測定した結論ではなく、コメント投稿者の技術的意見だ。それでも、モデル自体を鍛えるのか、周辺の実行・確認ループを鍛えるのかという争点は面白い。[同コメント欄](https://www.reddit.com/r/LocalLLaMA/comments/1xeuo7t/a_4b_coding_model_that_can_generate_3d_scenes/)

さらに、物理を理解できれば教材に使えるのでは、という質問や、2bit量子化への期待も出ていた。ここは混同禁物で、物理的正確性が検証されたわけでも、2bit版の動作が報告されたわけでもない。作者のRLへの言及も可能性の話であり、採用済みの学習手法を明かしたものではない。熱量の中心は、完成品への称賛だけでなく「この小ささなら次に何を試せるか」という実験欲にある。[原本の応答](https://www.reddit.com/r/LocalLLaMA/comments/1xeuo7t/a_4b_coding_model_that_can_generate_3d_scenes/)

【今後の展望とエコシステムへの影響】
作者は学習継続中と説明し、完了後に更新版や学習データを共有する予定だとしている。公開完了を確認した情報としては扱えない。もしデータと再現手順まで揃えば、興味の中心は見栄えのよいデモから、どの課題をどんなデータで改善できるかへ移るだろう。[開発者の予定](https://huggingface.co/ccore/Qwen3.5-4B-3D-Coder)

この一件だけでBlenderや大型コーディングモデルがオワコンになるとは言えない。変わる可能性があるのは、用途ごとに必要なモデルの大きさを選ぶ発想だ。教材のたたき台や簡単な空間プロトタイプなら、用途を絞った4Bで足りる場面があるのか。逆に複雑な制約では、修正の手間が容量の利点を食い潰すのか。GGUF配布の価値は、その問いを読者自身の環境へ持ち込める点にある。評価を決める次の材料は、再現可能な成功率と失敗例だ。