開放模型與視覺生成
SenseNova-U1.5正式版の重みは実際には約175億パラメータ、Hubのクイックロード経路には依然として必要なコードが欠落
SenseNova-U1.5-8B-MoT正式版は、同一のバックボーンで視覚理解、ネイティブ画像生成、画像編集をサポートし、モデルカードには実際の規模が18Bと記載されている。第三者によるONNX移植の検証では、Hugging Faceの`trust_remote_code`設定が、重みとともに公開されていないファイルを参照していることが判明しており、現時点でデプロイするにはGitHubのリファレンス実装を併用する必要がある。
SenseNovaは、U1.5-8B-MoT正式版の重みとApache 2.0ライセンスのリファレンス実装を公開した。このモデルは、独立した言語モデル、ビジョンエンコーダー、拡散モデルを連結したものではない。42層のQwen3デコーダー内に、理解用と画像生成用の2系統の重みを保持している。テキストと参照画像は、まず理解ブランチを通ってKV cacheを構築し、その後、生成ブランチがflow matchingの各ステップでこのプレフィックスを読み取り、ピクセルを直接予測する。公式によると、新版ではネイティブ4K生成、中国語・英語のテキスト、複雑なレイアウト、局所編集、複数参照画像を用いた編集が改善されている。
「8B」という名称は、デプロイ時の判断を誤らせやすい。現在、モデルカードには18Bと記載されている。Microsoft Mobiusチームがtensor単位で調査したところ、パラメータ数は17,532,854,464、重みの容量は約50.2GBで、内訳は理解ブランチが約9.35B、生成ブランチが約8.12Bだった。また、この2つのブランチはtoken単位のMoE routingを行うのではなく、forwardごとにブランチ全体を切り替える。生成中は理解側のKV cacheを固定し、もう一方のデコーダーを繰り返し実行する。
さらに直接的な互換性上の問題は、パッケージングにある。Hugging Faceの設定では、`AutoModel`が`modeling_neo_chat.py`を介してロードされることになっているが、このファイルと対応するconfigurationファイルはモデルリポジトリに含まれていない。そのため、モデルページに掲載されている`trust_remote_code=True`を使った1行のサンプルは、単独では動作しない。公式の完全なquick startでも、実際には先にGitHubリポジトリをcloneし、その中の`sensenova_u1`パッケージから重みをロードするよう求めている。
Mobiusによる変換テストでは、理解用の重みがBF16である一方、生成ブランチの大部分はFP32で保存されていることも判明した。後者をそのままFP16に変換すると、20ステップのsamplingでは約15ステップ目にoverflowとNaNが発生した。同チームによるH200上のONNXテストではピーク時に約91GBを使用したが、これは特定のexport経路での結果であり、公式の最小要件ではないため、LightX2Vや量子化版に一般化することはできない。デプロイ担当者は、本番利用を評価する前に、Hubのパッケージ修正、独立した品質評価、正式なGGUF／低メモリ対応ソリューションを待つべきだ。