SenseNova という名前を、日本ではあまり聞きません。気になって、何者なのかと、手元の機械で動くのかを調べました。調べると、中国の SenseTime（センスタイム）が公開している基盤モデル群で、画像の理解と生成を 1 つのモデルで行う SenseNova-U1.5 が、日本語の文字もそれなりに描けることが分かりました。この記事は、その調査と実験の記録です。
調査と実験は、Claude Code と一緒に行いました。画像の生成条件と測定値は、実行の記録から書いています。作業は 2026 年 11 月 2 日に行いました。
この記事で分かること
- SenseNova と SenseTime の関係
- SenseNova の公開モデルのうち、RTX 4080 2 枚（合計 32 GB）で動かせそうなもの
- SenseNova-U1.5-8B-MoT を、元の重み（bf16）のまま 2 枚の RTX 4080 で動かす方法
- 同じプロンプトで、量子化した重みと元の重みを並べたときの画質の差
- 日本語の文字が、どこまで正確に描けるか
用語
| 語 | 意味 |
|---|---|
| bf16 | 16 ビットで数を表す形式（bfloat16）。公開されている元の重みは、この形式 |
| 量子化 | 重みを少ないビット数で表して、サイズを縮める処理。画質や精度が落ちることがある |
| GGUF | 量子化した重みを 1 つのファイルにまとめる形式 |
| Q3_K_M | GGUF の量子化の水準の 1 つ。重みを約 3 ビットで表す |
| MoT | 理解用と生成用の 2 組の変換器を、1 つのモデルに持つ構成（Mixture of Transformers） |
SenseNova と SenseTime の関係
SenseNova は、SenseTime が出している基盤モデルのシリーズです。次の 3 つの点から、そう読み取れます。
- GitHub の組織 OpenSenseNova の説明文が、「SenseTime Foundation Model Sets」（SenseTime の基盤モデル群）になっている。リポジトリは 29 個ある
- Hugging Face にも、同名の組織があり、公開モデルは 40 個ある
- 報道でも、SenseNova は SenseTime の基盤モデル群として扱われている。たとえば 2026 年 7 月の SenseNova-Vision の公開の記事は、これを SenseTime の基盤モデル群の 1 つと説明している
SenseNova という名前自体は、2023 年 4 月に、SenseTime が基盤モデル群と AI の計算基盤として発表したものです。その後、2024 年に 5.0、2025 年に V6 と更新されたと報じられています（5.0、V6）。これらの上位のモデルについて、重みの公開は、私が確認した範囲では見当たりません。重みが公開されているのは、2026 年に GitHub と Hugging Face に出てきた、U1 などの一部のモデルです。
SenseTime は、2014 年に設立された、顔認識などの画像認識で知られる中国の AI 企業です。2021 年 12 月には、米国の財務省が、投資を禁じる中国の「軍事・産業複合体企業」のリストに加え、同社は予定していた香港での上場を延期しました（Fortune の報道）。2019 年 10 月にも、商務省のエンティティ・リストに載っています。これらは当時の報道で、現在の扱いは確認していません。モデルを使う前に、組織のポリシーや規約を確認するのは、読み手の判断になります。
日本で名前を聞かない理由は、調べた範囲では分かりません。Qiita で SenseNova を検索すると、2026 年 11 月 2 日の時点で 3 件ありましたが、いずれも SenseNova を主題にした記事ではありませんでした。Zenn と note は確認していません。
公開されているモデルの種類
SenseNova の公開モデルは、画像、動画、ロボット、言語と、幅広い分野にわたります。2 枚の RTX 4080（合計 32 GB）で動かせるかを、重みのサイズから見積もりました。実際に動かしたのは、表の中で「実行した」とあるものだけです。
| モデル | パラメータ数 | 重みの大きさ（bf16） | 2 枚の 4080 で | 内容 |
|---|---|---|---|---|
| SenseNova-U1.5-8B-MoT | 約 175 億 | 約 35 GB | 実行した（CPU も併用） | 画像の理解と生成、編集を 1 つで行う |
| SenseNova-U1-A3B-MoT | 約 387 億 | 約 78 GB | 収まらない見積り | 同じ系統の、専門家混合版 |
| SenseNova-6.8-Code2Video | 約 274 億 | 約 55 GB | 収まらない見積り | コードで動画を作るモデル |
| SenseNova-Loop-9B-Preview | 約 97 億 | 約 19 GB（bf16 に変換して） | 収まる見積り | 層の一部を 2 回通す言語モデル |
| InteractiveOmni-8B | 約 101 億 | 約 20 GB | 収まる見積り | 画像、音声、動画を入力し、文章と音声で答える |
| SenseNova-MARS-8B | 約 88 億 | 約 18 GB | 収まる見積り | 検索を使う推論をする画像言語モデル |
| Looped-DiT（B/16、B/32） | 小さい（重み約 1 GB） | 約 1 GB | 余裕で収まる見積り | 層の一部を繰り返す、画像生成の拡散トランスフォーマー |
パラメータ数と重みの大きさは、Hugging Face の記載です。「収まる」「収まらない」は、サイズからの見積りで、動かして確かめていません。
SenseNova-Loop-9B-Preview は、32 層のうち 24 層を、同じ重みで 2 回続けて通します。1 回の計算で 56 層ぶんの計算をして、保持する重みは 32 層ぶんです。設定ファイルと実装コードを読んで確かめました。ループの回数は固定で、入力に応じて変わりません。動かしてはいません。
動かしたモデルの SenseNova-U1.5
SenseNova-U1 は、画像の理解と生成を 1 つのモデルで行う、SenseNova の主力のシリーズです。公式の説明では、画像を扱う前処理の 2 つの部品（視覚の符号化器と、画像を圧縮する VAE）を持たず、画素から言葉までを 1 つにつなげる構成（NEO-unify）だとされています。ライセンスは Apache-2.0 で、GitHub のリポジトリの星は、確認した時点で約 6,900 でした。
U1.5-8B-MoT は、2026 年 8 月 20 日に公開された、最新の版です。名前の 8B は、理解側が約 80 億、生成側が約 80 億のパラメータを持つ、という意味です。合計は約 175 億で、bf16 の重みは約 35 GB になります。インフォグラフィックの文字描画、画像の編集、4K の生成が、売りとして挙げられています。対応言語は、公式の説明では中国語と英語です。
手元の環境で動かす
機械は、RTX 4080（16 GB）が 2 枚の、共有のワークステーションです。公式の手順どおりに、リポジトリを取得し、仮想環境を作りました（Python 3.11、PyTorch 2.8、CUDA 12.8）。
公式 FAQ の想定
公式の FAQ には、次のようなやり取りがあります。2K の画像の生成に、H100 で 35〜37 GB のメモリが要る。合計 32 GB の 2 枚の GPU で、同居の配置（--tp 2）にすると、メモリ不足で止まる。メモリが足りないときは、GGUF の量子化と、層を入れ替える設定（--vram_mode）を勧める、とあります。
方法 1 量子化した重みを 1 枚の GPU に載せる
最初に、コミュニティが作った GGUF の Q3_K_M（約 10.9 GB）を、GPU 1 枚に載せました。設定や文字の読み込みに必要な小さなファイルだけを公式から取り、重みは GGUF から読みます。
大きい量子化（Q6_K、約 17 GB）は、先に試して失敗しました。重みを CPU のメモリにいったん全部読む実装で、共有の機械では、空きメモリが少なくなると、使用量の大きい処理が自動で終了される仕組みがあります。ここで終了されました。この仕組みは迂回せず、重みを 1 つずつ GPU に移す形に、手元の複製のコードを数行直しました。さらに、量子化された小さな層の型が公式のコードと合わず、エラーが出たので、1 行直しました。どちらも、公式のリポジトリではなく、作業用の複製での変更です。
この条件で、GPU のメモリは最大で約 13.6 GiB（nvidia-smi の表示で 13,898 MiB）、1 枚あたり約 2.2〜2.6 分（50 ステップ）で生成できました。
方法 2 元の bf16 を 2 枚の GPU に分けて載せる
次に、元の bf16（約 35 GB）を、--device_map auto で 2 枚に分け、足りない分を CPU に置きました。
python examples/t2i/inference.py \
--model_path <bf16 の重みの場所> \
--device_map auto \
--max_memory "0=12GiB,1=12GiB,cpu=9GiB" \
--jsonl prompts.jsonl --output_dir out
1 枚あたり 12 GiB ずつを GPU に、約 9 GiB を CPU に置く設定です。公式 FAQ の想定とは違い、この設定で動きました。GPU のメモリは、1 枚あたり約 13.2〜13.7 GiB（nvidia-smi の表示で約 13,500〜14,000 MiB）で、1 枚の生成に約 3.5 分（3.3〜3.7 分）かかりました。量子化版（約 2.3 分）の 1.5 倍ほどの時間です。CPU のメモリは、共有の機械の制限の範囲に収まりました。
生成の結果
同じプロンプト、同じ画像の大きさ、同じ乱数、50 ステップで、量子化版（Q3_K_M）と元の bf16 を比べました。以下の画像は、すべて日本語のプロンプトです。乱数は、スクリプトの既定のままで、両方で同じです。
日本語の見出しの描画
「秋の京都」のポスターです。左が Q3_K_M、右が bf16 です。
どちらも、見出しの「秋の京都」と、「紅葉ライトアップ」、日付の「11月1日〜30日」が正確です。プロンプトでは「古い寺の門」と指定しましたが、Q3_K_M は鳥居（神社の門）を描き、bf16 は寺の門を描きました。Q3_K_M は、画面全体に粒状のざらつきがあります。
日本語の図解
「Muse と GitHub の連携」という題の図解です。上が Q3_K_M、下が bf16 です。
見出しは、どちらも正確です。説明文は、Q3_K_M で「テキスト」が崩れ、下の説明は崩れて「成功」が欠けました。bf16 は、3 つの説明文がすべて正確でした。
高密度の広告
百貨店のクリスマスセールの広告です。美少女のキャラクター、バナー、価格の札を詰め込んだ、高密度のイラスト調のお題です。左が Q3_K_M、右が bf16 です。
大きな見出し、日付、価格は、どちらも読めます。差が出たのは、小さな文字と質感です。Q3_K_M は、チラシの札の「限定ケーキ」「ブランドバッグ」が崩れ、下の見出しの「クリスマスセール」が「クラスス」に崩れ、価格が重複しました。bf16 は、価格の 4 つがすべて正確で、「クリスマスセール」も正確でした。ただし、bf16 にも誤りが残ります。縦書きのバナーの「ファッション」「スイーツ」と、札の「限定ケーチ」「ブラランドバッグ」の 1 文字ずつの誤り、下のリボンの意味のない文字です。
写真風の高密度の画像
写真のように写実的で、日本語の看板がびっしり写る画像です。
渋谷のスクランブル交差点の夜景です。上が Q3_K_M、下が bf16 です。
Q3_K_M は、画面全体に強いざらつきがあり、構図も街路の低い位置からのものになりました。bf16 は、交差点を高い位置から見た構図で、傘の人々、濡れた路面の反射、ネオンが、細かく描かれました。看板の「ラーメン」「カラオケ」「ドラッグストア」「居酒屋」は、bf16 では読めます。Q3_K_M でも読めますが、「ラーオケ」のような崩れが混じります。
早朝の魚市場の店先です。上が Q3_K_M、下が bf16 です。
bf16 は、手書き風の札の「本日のおすすめ ぶり ¥1,200 あじ 3尾 ¥500」が、すべて正確に描かれました。氷の上の魚、エビ、貝、湯気、長靴の店主と、要素も多く、写真として破綻が少ない出来です。Q3_K_M は、大きな札は読めますが、荒い質感になり、発泡スチロールの箱の文字が崩れました。
夜の居酒屋の店先です。左が Q3_K_M、右が bf16 です。
プロンプトでは、赤提灯に「居酒屋 まる」と指定しました。どちらも正確には描けず、Q3_K_M は「居酒る」に、bf16 は「居酒屋る」に崩れました。看板の「本日のおすすめ 焼き鳥盛り合わせ」は、Q3_K_M ではほぼ正確で、bf16 では「鳥」が「島」に似た形になりました。
分かったことと限界
- 2 枚の RTX 4080 で、SenseNova-U1.5-8B-MoT を bf16 のまま動かせた。公式 FAQ が OOM としていた条件でも、CPU に一部を置く設定で動いた
- 量子化（Q3_K_M）は、簡単なお題では差が小さいが、高密度の広告や写真風の画像では、ざらつきと文字の崩れが目立つ。bf16 のほうが、画質も文字の正確さも上だった
- 日本語の短い見出し、価格、日付は、bf16 ではほぼ正確に描けた。長い説明文、縦書き、小さな札の文字には、誤りが残る。公式の説明にある「小さく長い文字の弱点」は、bf16 でも出た
- 比較は、少数のプロンプトを、乱数 1 つずつで行っただけで、統計的な評価ではない。画質の評価は、目で見たものである
- 公式のベンチマークの値は、この記事では確かめていない
- 手元の複製のコードを数行直して動かしているので、公式の実装そのままの結果ではない