検閲のない非公式LLM APIは経済的に実現するのか

はじめに

「検閲のないLLM」「uncensored AI」「no-refusal model」を掲げる非公式サービスは、公開重みモデルの普及とともに作りやすくなっています。前の記事では、高性能な公開重みモデルが増えるほど、拒否傾向を弱めた派生モデルと、そのAPI提供が地下・半地下インフラとして現れ得る構造的条件も強まると考えました。

この記事でいう検閲のない非公式LLM APIとは、モデル開発元とは別の運営者が、商用APIよりポリシー上の拒否や出力制限が少ないと称して提供するAPIです。「どんな入力にも必ず答える」「法律やホスティング事業者の制約も存在しない」という意味ではありません。再調整後にも拒否や能力不足は残り得ますし、API層で別の制限が加わる可能性もあります。

この検討の出発点は、Claude CodeでClaude Fable 5を使い、自分の個人プロジェクトに対してSecurity Reviewを行った経験です。正当な防御目的の作業でも安全チェックが反応し、既定設定による別モデルへの自動フォールバックが頻発しました。Anthropicも、Fable 5ではモデルが読むファイルやメモリを含めて判定し、通常のサイバーセキュリティ作業でも高いフォールバック率が見込まれると説明しています。自動切り替えは無効化できますが、その場合は該当リクエストが停止します。この体験から、こうした摩擦が少ないモデルを調べ始めました。

では、「検閲なし」を売りにする非公式APIは、単なるモデル配布ではなく、継続的なサービスとして経済的に成立するのでしょうか。最新の公開重みモデルを再調整し、自社保有のGPUサーバーからAPIを提供する場合に、どの程度の資金と需要が必要になるかを検討します。

今回は、2026年6月16日に公開されたGLM-5.2を、2026年7月10日時点の最新級の公開重みフロンティアモデルのケーススタディとして、初期費用、月間運用費、API価格、売上、損益分岐をシミュレーションします。GLM-5.2の開発元や公式APIが、この記事で想定する非公式サービスに関与しているという意味ではありません。

先に結論

GLM-5.2を使ったケーススタディから見える結論は、次の通りです。

試算の全体像。公式価格では36か月以内に初期投資を回収できず、2倍価格では月28に累積純キャッシュフローがプラスへ転じます。

主な数値は次の通りです。

• 1Mコンテキストまで扱う推論構成はB200 × 8基を基準とする
• 入力80%・出力20%へ換算したMTPなしの実験上限は約474億token/月。容量余力60%と可用性99%の感度分析を掛けた暫定上限は約281.6億token/月になる
• 重み更新用の学習GPUと、常時稼働する推論GPUは分けて計算する。モデル更新はクラウド、本番推論は自社保有機だけに一本化する
• 自社保有する推論ノードはB200 × 8基の1台で、固定ケースの月0実支出は459,500ドル、75,000ドルの運転資金を加えた必要初期資金は534,500ドルになる
• キャッシュアウトは通常月5,822ドル、3か月ごとの更新月60,822ドル、3か月平均で約24,155ドルになる
• サーバーと導入費を36か月へ配賦した正規化月次コストは約35,391ドルになる。この配賦額は当月のキャッシュアウトではない
• 暗号資産による前払いと残高上限を前提に、未払い、返金、チャージバック、後払い超過による信用損失は0%とする。決済・換金費も別の簡略化として0%に固定する
• 平均キャッシュ収支の均衡点は、GLM公式価格で月約120.8億token、2倍価格で月約60.4億tokenになる。減価償却を含む正規化月次損益の分岐点は、それぞれ約177.0億token、約88.5億tokenになる
• 月100億tokenを36か月販売する固定ケースでは、公式価格は初期投資を回収できず、2倍価格は月28に累積純キャッシュフローが正へ転じる
• より小さく高速な公開モデルへ移行でき、性能・価格・需要を維持できれば、同じ推論機の技術的な処理容量と利益率は改善し得る
• 単一ノードでは障害時にサービス全体が停止する。前払いは信用リスクを消せても、設備と可用性のリスクは消さない

要するに、「検閲なし」を掲げる非公式LLM APIは、GLM-5.2と今回の設備・料金仮定では技術的な構成案を作れ、表計算上は損益分岐へ到達できます。ただし、需要を確認した事業計画ではなく、個人の小規模プロジェクトと呼べる投資額でもありません。安定したAPI事業として継続するハードルも高いという結果です。

それでも、表面上の現金支出だけを見れば利益が出るように見える条件はあります。そのため、実際に試みる主体が現れる可能性は否定できません。

ケーススタディにGLM-5.2を選ぶ理由

Z.aiの発表によると、GLM-5.2は長時間のAgentタスクやコーディングを重視した最新フラッグシップモデルです。重みは公開され、MITライセンスで配布されています。非公式API全般がGLM-5.2を使うと予測しているのではなく、現在の公開フロンティアモデルを自社運用する費用の具体例として選びました。

vLLMの公式レシピでは、最大1Mコンテキストを使う構成として8基のB200が示されています。この記事は、このB200 × 8構成だけを試算対象にします。

ここで重要なのは、MoEのアクティブパラメータが約40Bでも、すべての重みをメモリ上に保持する必要があることです。計算量は密な750Bモデルより軽くても、必要なGPUメモリは依然として大きくなります。

今回のシミュレーション条件

想定するのは、モデル開発元とは無関係な運営者が、ポリシー上の拒否を減らしたと称する派生モデルをOpenAI互換形式などのAPIで有料提供するケースです。この記事では、その主張が技術的に完全かどうかではなく、必要な設備と需要からサービスの経済性を検討します。

モデルの重みを更新する学習と、更新後のモデルをAPIで提供する推論は、必要なGPUの台数も稼働期間も異なります。同じ設備としてまとめず、次の二系統に分けます。

学習データ・評価仕様
        ↓
クラウド重み更新クラスタ：B200 × 16基、48〜336時間だけ利用
        ↓
更新済みチェックポイント
        ↓
自社保有推論ノード：B200 × 8基、月730時間稼働 → API

重み更新中に本番推論を兼用する想定ではありません。更新期間だけクラウド上の2ノードを確保し、完成したチェックポイントを自社保有の推論ノードへ移します。学習用GPUサーバーは購入しません。

モデル開発元と無関係な運営者が「検閲なし」を掲げるAPIは、利用規約違反や不正利用検知によってクラウド契約を停止される可能性が高く、継続的な本番推論をクラウドへ置く可能性は極めて低いと仮定します。そのため、推論は自社保有サーバーのみとします。一方、モデル更新は短期間で終了し、新モデルごとに必要なGPU構成も変わるため、学習・評価はクラウド利用だけに一本化します。これは、利用規約に適合し、更新時にB200枠を確保できた場合の条件付きシナリオです。契約を停止された場合は、本番推論は続けられても新しい再調整はできず、後述する「更新なし」の費用ケースへ移ります。

今回は、広告されている1Mコンテキストまで扱える構成として、GLM-5.2 FP8を8基のB200で動かす推論専用ノードを基準にします。

この構成は「安定した商用サービス」の完成形ではありません。推論ノードの障害、保守、更新済みモデルへの切り替え時にはサービスが止まり得ます。

SGLangは、8基B200のFP8版について8,192 input token、1,024 output tokenの合成負荷によるスループットを公開しています。後の節では、この実測値から月間処理tokenの上限を計算します。ただし、長い入力、出力比率、同時実行数、停止時間によって実トラフィックの処理量は変わるため、理論上限と需要予測は分けて扱います。

重み更新用の学習GPUにはいくらかかるのか

この記事では、検閲がないと称するモデルを作るために安全策を弱める具体的な学習方法には触れません。費用だけを把握するため、追加の事後学習と評価を複数回行う計算枠を仮定します。

GLM-5.2専用の再調整費用は公式には公開されていません。そのため、次はあくまでシナリオ入力です。学習用サーバーは購入せず、更新時だけクラウドの2ノードを確保します。

• B200を8基搭載した学習用ノードを2台使う
• 1回48〜336時間の実験枠を確保する
• データ作成、能力評価、品質劣化の確認を別途行う

AWS Capacity Blocksの公開価格では、8基のB200は1時間82.368ドルです。学習用の2ノード、合計16基を使う場合は1時間164.736ドルとなり、GPU計算費だけで次の範囲になります。

これは通常のオンデマンド利用料ではなく、期間を指定して容量を予約するCapacity Blocksの実効時間単価です。必要な期間にB200枠を確保できる保証はなく、OS、ストレージ、チェックポイント転送などの追加費用も表には含めません。

ここで想定している2ノードは、ベースモデルの大部分を固定するparameter-efficient fine-tuning（PEFT）など、更新対象を限定した追加学習のための経済試算上の仮置きです。GLM-5.2について、2ノードでこの学習を完了できるという公式実測値があるわけではありません。また、安全策を弱めるデータや学習手順は扱いません。

全パラメータ更新は別の規模になります。DeepSpeedのメモリ見積もりを約750Bパラメータへ機械的に当てはめると、標準的なAdamとZeRO-3で、activationを除くモデル状態だけでも約13.5TBです。B200を8基搭載したノードは合計HBMが1.44TBなので、容量だけでも約10ノードが下限となり、実際にはactivationと通信の余裕がさらに必要です。

10ノードを1〜2週間借りるだけでも、GPU料金は約13.8万〜27.7万ドルです。これは学習の成立を保証する見積もりではなく、「全パラメータ更新を2ノードの費用で扱ってはいけない」ことを示す下限側の感度分析です。今回の基本シナリオからは除外します。

PEFT側でも、実際にはデータ準備、失敗した実験、評価、人件費、保存領域が加わります。今回は初期費用の計算で、更新対象を限定した追加学習と評価の合計を2万〜10万ドルと置きます。

モデル更新の固定ケースでは、この範囲内から1回55,000ドルをシナリオ入力として採用します。この記事でいう1回の更新は、公開済みのベースモデルに対する派生モデルの再調整と評価です。次世代の別モデルへ移行する費用は同じとは限りません。55,000ドルは2万〜10万ドルの中央値ではなく、336時間分のGPU計算費約55,400ドルを丸めた水準です。長時間のGPU枠に加えてデータ作成や外部評価の費用が大きい場合は、10万ドル側へ寄るため、55,000ドルは保守的な上限見積もりではありません。

学習が終わればクラウドの2ノードを解約します。推論ノードは別の自社保有機なので、本番APIはクラウド学習の終了後も動き続けます。一方、公開モデルの更新へ追随するたびにクラウド学習費が再発します。後の損益表では3か月更新を基本とし、6か月更新も比較しますが、この頻度も実績値ではなくシナリオ入力です。

この幅の広さ自体が重要です。拒否率だけを下げても、一般性能、コード品質、長文性能、ツール利用能力が壊れれば商品になりません。改変モデルを作ることと、安定して使えるモデルを作ることの間には追加コストがあります。

必要初期資金と月0のキャッシュアウト

Exxactの8基B200搭載サーバーの公開販売価格は約352,000ドルからです。実際の見積価格はCPU、メモリ、ストレージ、保守契約で変わります。購入するGPUサーバーは本番推論用の1台だけです。

本番推論サーバーは自社保有し、学習用2ノードは更新時だけ48〜336時間クラウドで借ります。本番推論をクラウドへ置く費用は含みません。

352,000ドルは公開販売価格です。導入費52,500ドルはラック、ネットワーク、予備部品、設置をまとめた固定シナリオ入力、初回クラウド費55,000ドルは後続の1回当たり更新費と同額にそろえました。75,000ドルの運転資金は、無売上の3か月分の継続運用費17,466ドルと、月3のモデル更新費55,000ドル、合計72,466ドルを賄うための手元流動性です。開始時に消費する費用ではないため、月0の実支出には含めません。

日本円では、月0の実支出が約7,352万円、必要初期資金が約8,552万円です。学習GPUを保有しないため設備投資と遊休資産を抑えられますが、学習途中での契約停止、GPU枠の不足、次回更新時に同じ環境を確保できないリスクは残ります。ここでのクラウド費用は、適法かつ利用規約に沿って利用できた場合の価格基準です。

月間運用コストとキャッシュフロー

購入価格の基準はExxactのHGX B200サーバーですが、同ページにはシステム全体の最大入力電力が掲載されていません。そこで電力計算だけは、同じ8基のB200を搭載するNVIDIA DGX B200の最大消費電力14.3kWを代理値として使います。シャーシ、CPU、メモリ構成が異なるため、これは購入対象の実測値ではありません。電源、冷却、余裕を含む20kW級という値も、施設契約を検討するための記事上の設備枠です。

自社保有するのは推論ノード1台だけです。電力単価を0.05ドル/kWhへ固定し、以下の運用費を使って項目別に計算します。固定した初期導入費52,500ドルは36か月で償却します。データセンター、回線、人件費、DDoS防御の月額も市場平均ではなく、この記事で固定するシミュレーション入力です。

基本シナリオは3か月更新とし、正規化した月次損益では月35,391ドルを費用として使います。一方、キャッシュフローでは平準化しません。通常月は5,822ドル、月3・6・9・12……の更新月は60,822ドルを、その支払月に計上します。クラウド推論の費用は含みません。保守・人件費には違法な支払いや賄賂を含めず、通常の保守契約と人件費だけを計上します。

稼働開始後12か月のキャッシュアウトは、現金運用費69,864ドルと4回のモデル更新費220,000ドルを合わせた289,864ドルです。月平均24,155ドルは比較用の平準化値であり、実際の支払いは通常月と更新月で大きく異なります。

暗号資産の前払いが確定してからAPI残高を付与し、残高が尽きた時点でリクエストを止めると仮定します。このため、未払い、返金、チャージバック、後払い超過による信用損失は基本試算から除外します。決済・換金費も別の簡略化として0%に固定するため、売上控除率は合計0%です。

初期費用表は、購入時に必要なキャッシュを示しています。正規化月次損益では、推論サーバー代と初期導入費を36か月の減価償却として費用化します。キャッシュフロー図では、IAS 7の考え方に沿って非現金の減価償却を入れず、購入額を月0へ一度だけ計上します。初回のクラウド学習費は月0へ、後続のモデル更新費は実際の更新月へ計上します。保険、税務・法務、設備故障による逸失利益、施設ごとの追加受電工事などは含めていないため、一般的な意味での完全原価ではありません。

サーバー所在地はどのように考えるべきか

具体的な国や高リスク事業者を選ぶことは、この記事の目的ではありません。所在地は次の4類型で考えます。

今回の費用表は、自社保有の推論機1台をコロケーション施設へ置く構成を基準にしています。20kW級の受電・冷却設備を含む専用施設そのものを新設する費用は含めません。「自社運用」はクラウドの仮想マシンを借りるという意味ではなく、運営者が推論用GPUサーバーを所有し、OS、モデル、APIを管理するという意味です。

海賊版サイトでは、ドメインと配信先を移すことで再出現できる場合があります。しかし、GLM-5.2級の推論サーバーは100kgを超える機材、20kW級の電源、冷却、高速回線を必要とします。

モデル重みは複製できても、推論能力を支える物理設備は簡単には複製・移転できません。

EuropolによるLolekHostedの摘発では、運営者の逮捕と全サーバーの押収が行われ、暗号資産の追跡も捜査に使われました。米国司法省のOperation Novaでも、複数国にまたがるサーバーとドメインが同時に停止されています。

このため「法執行の弱い場所に置けば終わり」という単純な問題ではありません。上流回線、機材調達、運営者の居住地、顧客、決済、換金など、複数の法域との接点ができます。

実在国の情報から分かること、分からないこと

脅威モデルを具体化するため、追加されたパラグアイ、カンボジア、カザフスタンの情報を公開資料で確認します。ただし、国全体の発電量や気候から、20kW級ラックの契約価格、停電率、国際回線品質、B200の適法な輸入可否、法執行リスクまで一括して推定することはできません。

この比較から言えるのは、「安い電力がある国」と「GLM-5.2級APIを安定運用できるサイト」は同義ではない、という点です。今回の0.05ドル/kWh、コロケーション1,500ドル、1Gbps回線800ドルは特定国の実勢見積もりではなく、固定したシミュレーション入力です。実装段階では、同じ国でも施設ごとに受電容量、冷却方式、PUE、SLA、保守、回線経路、輸出管理・制裁適合性を個別に確認する必要があります。

また、犯罪拠点が報告されていることは、その国で高密度GPU APIを長期間運用できる証拠にはなりません。防御側が見るべきなのは国名のランキングではなく、20kW級の継続負荷、10U級の筐体、回線、機材輸送、決済といった観測可能な集中点です。なお、約142kgという重量は購入対象そのものではなく、電力計算にも使ったDGX B200参照機の仕様値です。

暗号資産決済を前提にすると何が変わるか

今回のシミュレーションでは、利用料金を暗号資産で全額前払いし、入金確認後にだけAPI残高を付与する前提にします。残高がゼロになれば推論を停止し、負の残高や後払いを認めません。ただし、特定の通貨、ウォレット、交換業者は想定しません。

この方式では、次の信用リスクを基本試算から外せます。

• 未払いと貸倒れ
• カードのチャージバック
• 利用後の返金
• API keyの過剰利用による後払い超過

価格は入金確認時の米ドル相当額でAPI残高へ反映します。暗号資産の価格変動、換金手数料、スプレッド、交換業者による留保も今回の損益計算では0と仮定しますが、これは前払いによって自動的に消えるリスクではなく、試算を単純化するための独立した前提です。したがって、利益表の売上控除率は合計0%です。

FATFのTravel Ruleは、仮想資産を含む送金の透明性を高める方向にあります。また、米国財務省はサイバー犯罪を支援した暗号資産交換網に対して、制裁と資産凍結を実施しています。

したがって、前払いは信用リスクを除けますが、匿名性や法的な安全性を保証するものではありません。オンチェーン追跡、制裁、資産凍結、税務は法務・運用上の論点として残ります。ただし、本記事の利益表では経済的な売上控除へ換算しません。

「検閲なし」への需要は一種類ではない

検閲や拒否が少ないモデルを求める利用者を、すべて不正利用者とみなすのは正確ではありません。Fable 5で経験したSecurity Reviewのように、正当な作業が誤検知で中断されることへの不満も需要になります。一方、公式サービスでは拒否される高リスク用途を求める利用者も混ざります。

顧客層によって法務、濫用対策、可用性の負担は変わり得ます。ただし、暗号資産による前払いと残高上限を徹底する限り、顧客属性による未払い・返金リスクは発生しません。そのため、顧客構成は売上控除へ反映せず、法務・運用上の問題として分けて扱います。

ケーススタディの料金仮定：GLM-5.2公式価格と2倍価格

非公式APIは、公式サービスと同じ信用、サポート、可用性を提供できない一方、小規模なGPU設備の固定費を少ない顧客で回収する必要があります。そこで、価格競争をしない公式価格と、「検閲なし」を掲げることへの上乗せを含む2倍価格を比較します。これは、その価格で実需要が存在するという予測ではありません。

Z.aiの公式価格は、100万tokenあたり次の通りです。

1ドル160円で換算すると、出力は100万tokenあたり公式価格で704円、2倍価格で約1,410円です。

今回の売上計算では、入力80%、出力20%とします。この比率なら、入力と出力を合計した100万tokenあたりの平均価格は次のようになります。

2倍価格を払う利用者には、公式サービスでは得られない価値が必要です。しかし、「検閲がない」「拒否が少ない」と称することだけでは、品質、可用性、データ保護、運営者への信用を補えません。公式価格でも運営者の信用が公式APIより低ければ需要は保証されず、2倍価格ではさらに限定される可能性があります。

スループットから月間token上限を計算する

SGLangのGLM-5.2ベンチマークには、FP8版をB200 × 8基の単一ノードで動かした結果があります。負荷はすべて8,192 input token、1,024 output tokenの合成リクエストで、各ベンチマーク実行前にprefix cacheを消去しています。

SGLangの指標定義では、tokens_per_sec_per_gpuは入力と出力を合計したtoken数の毎秒・GPUあたりの値です。

Balancedの5,022 token/秒/GPUが、公開されているFP8測定点の最大値です。ただし、MTPの受理長を2tokenに固定して模擬した値です。High-Throughputの4,059 token/秒/GPUはMTPを使っていないため、この記事では後者を再現性を重視した基準にします。

ただし、High-Throughput測定のTTFTは約178秒です。これは最大処理量を狙うbatch型の上限であり、対話APIとして許容できる応答時間を維持するなら処理上限は下がります。

ベンチマークと同じ入力8：出力1の比率なら、730時間連続稼働時の単純な上限は次の通りです。

しかし、売上試算では入力80%、出力20%、つまり入力4：出力1を仮定しています。出力tokenは逐次decodeが必要なので、入力8：出力1の総token値をそのまま使うと上限を過大評価します。

MTPなしの測定点では、ノード全体のoutput throughputは32,472 ÷ 9 = 3,608 token/秒です。これを売上試算の出力比率20%へ合わせると、総token throughputは3,608 ÷ 20% = 18,040 token/秒となります。

18,040 token/秒 × 730時間 × 3,600秒
= 47,409,120,000 token/月
= 約474.1億token/月

同じ計算をMTPありの公開最高値へ適用すると、約586.6億token/月です。これは公式の8：1ベンチマークから、output throughputを一定と仮定して4：1へ換算した推論であり、4：1負荷を直接測定した結果ではありません。

ここまでの約474.1億tokenは、合成負荷を止めずに流す実験上の容量です。実際のAPIでは、需要の時間変動、長文リクエスト、rate limit、障害、保守に加え、応答時間を守るための余力が必要です。そこで、最大値とは別に、サービスとして持続できる出力上限を決めます。

一般的なサービス事業者は最大容量の何割で運用するのか

まず、次の三つは別の指標です。

今回確認した大手LLM API事業者の一次資料では、実際の平均GPU設備利用率や、最大token処理量に対する平均出力率を確認できませんでした。99.9%というSLAから、GPUを99.9%使っていると逆算することもできません。

そこで、公開された一般的なオンラインサービスの容量設計値を代理指標にします。

これらはLLM用GPUの実測平均ではなく、CPUやVM群を含む一般サービスの容量設計値です。ただし、平常時から100%近くを販売しないという考え方の根拠にはなります。AWSのtarget trackingも、平均50%の目標が突発的な負荷を処理する余力になると説明しています。

LLMではGPU使用率だけでなく、許容時間内に返せたリクエストの量を見る必要があります。NVIDIA AIPerfも、TTFT、TPOT、end-to-end latencyのSLOを満たしたgoodputを最大化する測定方法を用意しています。今回のSGLang High-Throughput測定はTTFTが約178秒なので、474.1億tokenをそのまま対話APIの販売可能容量とみなすのは不適切です。

この記事では、40〜70%の中間にあり、Googleの既定値でもある60%を暫定的な持続出力上限として採用します。70%はコスト優先の参考値であり、基本試算の上限にはしません。しかも今回の単一ノードは、負荷が増えてから短時間でGPUノードを自動追加できません。したがって60%は期待平均ではなく試算上の上限であり、可用性を優先する運営なら40〜50%側へ下げる必要があります。

99%と99.9%は処理容量ではなく可用性

大手の公称SLAを見ると、単一系と冗長構成の違いが分かります。

APIサービスSLAと基盤VM SLAは同じ層ではありません。後者には、モデルプロセス、API gateway、ロードバランサー、アプリケーションの障害は含まれないため、エンドツーエンドの可用性はさらに別に測る必要があります。

OpenAI Scale Tierも、99.9%のuptime SLAと、モデル別の出力速度を対象とするlatency SLAを別々に表示しています。latency SLAの注記では、5分区間ごとのp50 request latencyで計算するとされており、「個々の全リクエストの99%が閾値を満たす」という意味ではありません。利用可能であることと、混雑時にも所定の速度で返せることは別の指標です。

可用性の定義も同一ではありません。たとえばBedrockは5分区間のHTTP 500を基準とし、リクエストがない区間を100%利用可能とみなします。Vertex AIは、500または503のエラー率が5%を超えた時間を停止として数えます。高負荷時の遅延悪化や、すべてのrate limitが必ず停止時間に含まれるわけではありません。

730時間の月に換算した停止時間は次の通りです。

今回の構成は推論ノードが1台しかないため、99.9〜99.99%を保証できる構成ではありません。大手クラウドの単一VM公称値は、事業者が管理する基盤全体に対する値であり、自社保有の単一GPUノードへそのまま移せません。そこで、収益計算では月間可用性99%を感度分析用の計画値として置きます。この数字はGPUサーバーの故障統計から推定したものでも、掲げられるSLAでもありません。

474.0912億token × 持続的な出力上限60% × 可用性の感度分析値99%
= 281.6102億token/月

この計算は、需要が時間的にほぼ均一であるか、強いrate limitとqueueによってburstを平滑化でき、停止時間と需要発生が独立していると仮定しています。その条件で、1か月全体の平均出力は合成ベンチマーク換算値の59.4% が暫定上限です。対話需要が特定時間に集中し、待ち時間も増やせない場合の月平均上限は、さらに低くなります。

60%の容量目標を固定すると、可用性だけを99%から99.9%へ変えた算術値も、月281.6億tokenから284.2億tokenへ増えるだけです。収益上限を左右するのは、SLAの小数点以下よりも、応答時間と突発負荷のためにどれだけ容量を空けるかです。

入力4：出力1の正確な最大値とgoodputは、同じ比率でP95・P99のTTFTとTPOTを含めて直接測定しない限り確定できません。その測定結果が281.6億tokenを下回る場合は、実測値を新しい上限にする必要があります。

月間売上のシミュレーション

検閲がないと称する非公式APIの実需要は分かりません。そこで、月間の課金token量を10億tokenから、60%の容量目標と99%の感度分析値を掛けた暫定上限281.6億tokenまで具体的に置きます。

入力80%、出力20%なので、売上の計算式は次の通りです。

公式価格の月間売上 = 月間総token ÷ 100万 × 2ドル
2倍価格の月間売上 = 月間総token ÷ 100万 × 4ドル

日本円へ換算する場合は、表の金額に160円を掛けます。たとえば月100億tokenでは、公式価格の売上が約320万円、2倍価格では約640万円です。

上限比は、MTPなしの合成ベンチマークから機械換算した474.1億tokenそのものではなく、容量余力と停止時間を差し引いた281.6億tokenに対する割合です。入力長、出力長、batching、同時実行数によって実際の処理量は変わります。

正規化月次損益のシミュレーション

正規化月次損益では、自社保有の推論ノードに月17,058ドル、3か月ごとのクラウド更新費の月平均額として18,333ドルを計上します。暗号資産の前払いによる信用損失と、独立に0%と置いた決済・換金費は売上から差し引きません。

ここで示す値は、税金と未計上費用を差し引く前の、明示した仮定に基づく月次損益です。一般的な会計上の最終利益や、需要を検証した収益予測ではありません。

正規化月次損益 = 月間売上 - 35,391ドル

更新頻度による違いを、月100億tokenで比較すると次のようになります。どの行でも推論は自社保有機で行い、更新時だけクラウドを使います。更新費は月平均へ直した管理会計上の比較であり、実際の支払時点は後のキャッシュフロー図で別に示します。

基本シナリオである3か月更新の正規化月次損益表は次の通りです。

正規化月次損益の分岐点は、公式価格で約177.0億token、2倍価格で約88.5億tokenです。これは今回の暫定上限に対して、それぞれ約62.8%と約31.4%に当たります。減価償却を除き、3か月ごとの更新費を月平均にしたキャッシュ収支の均衡点は、公式価格で約120.8億token、2倍価格で約60.4億tokenです。

月次支出と投資回収点を同じ時間軸で見る

上のtoken量による分岐点は、更新費を月平均にした比較です。実際の資金繰りと初期投資の回収時期を見るため、月100億tokenを36か月販売する固定ケースを、支払月どおりに計算します。

棒は各月の実際のキャッシュアウトです。月0にサーバー、導入、初回クラウド学習を計上し、月1以降は5,822ドルの現金運用費、月3・6・9……には55,000ドルのモデル更新費を追加しています。折れ線は累積キャッシュアウトと累積利用売上で、その差が累積純キャッシュフローです。「先に結論」で示した図を、ここで計算の内訳とともに再掲します。

「先に結論」の試算図を再掲。ここまで説明した費用、料金、需要の前提を36か月の同じ時間軸で比較しています。

公式価格では、月100億tokenを販売しても3か月平均の現金収支が赤字なので、36か月後の累積純キャッシュフローは -609,092ドルとなり、初期投資を回収できません。2倍価格では月28に累積利用売上が累積キャッシュアウトを上回り、36か月後は +110,908ドルです。これは税金、未計上費用、設備故障を含まない固定需要シナリオであり、実際の回収予測ではありません。暗号資産の前払い額とtoken利用が同じ月に発生すると簡略化しています。

学習クラウドが契約停止になっても、すでに自社推論機へ配置したモデルは動き続けます。ただし、次の公開モデルへの追随と再調整は止まります。設備更新とモデル更新を分離できる一方、更新能力はクラウド事業者へ依存する構成です。

小型モデルによって同じ推論機の処理容量が100億tokenから150億、200億tokenへ増え、販売単価を維持したまま同じ比率で需要も確保できるなら、上の表の該当行へ移ります。新しいモデルで281.6億tokenを超える場合は、そのモデルの実測throughput、SLO、需要分布を使って暫定上限を更新します。この条件を満たす場合に限り、設備固定費を増やさず利益を拡大でき、価格競争力が改善します。

なぜ「検閲なし」を掲げる非公式APIを試みる主体が出るのか

本試算で計上した費用をすべて見ると厳しい結果ですが、運営者が次の費用を無視すると見え方が変わります。

• GPUサーバーの減価償却
• 自分自身の人件費
• 将来、既存GPUでは動かないモデルが必要になった場合の推論機更新費
• 重大障害の損失
• 法務、税務、制裁対応
• セキュリティ事故への備え

たとえば、すでにGPUを保有し、減価償却をゼロとみなせば、月75億token・2倍価格の月間売上3万ドルでも、3か月平均の現金支出24,155ドルだけを基準に黒字へ見せられます。

また、公開重みを利用すれば、事前学習へ数千万〜数億ドルを投じる必要がありません。必要なのは追加学習のクラウド計算費、自社推論設備、API運用です。正規のフロンティアモデル開発企業と比べれば、参入資金は桁違いに小さくなります。

つまり、実際の長期採算が悪くても、次の条件が「試してみる価値がある」という錯覚や期待を生みます。

• モデル重みを無償で取得できる
• FP8なら本番推論は単一GPUノードに収まる
• 公式API価格が安く、市場価格の基準が分かる
• 2倍価格と月100億tokenを置けば、正規化月次損益も表計算上は黒字になる
• 一度設備を買えば、現金支出だけは小さく見える
• 学習・更新をクラウドへ限定することで、初期投資と遊休設備を抑えられる
• 地下市場では低いSLAが許容される可能性がある

この「楽観的な表計算」が、試みる主体を生む理由になると考えています。

非公式APIの実現時に見落としやすい問題

需要が最も大きな不確実性

公式価格で月177.0億token、または2倍価格で月88.5億tokenという正規化損益の分岐点まで需要を確保できるかは分かりません。平均キャッシュ収支だけを見る場合でも、それぞれ月120.8億token、月60.4億tokenが必要です。検閲がないと称するAPIを求める利用者は存在しても、信頼できない非公式運営者へコード、機密情報、攻撃対象を送ることには別のリスクがあります。

長いコンテキストほど同時実行数が下がる

1Mコンテキストはモデルの強みですが、KV cacheを大量に消費します。長時間のAgentタスクが増えるほど、同じノードで処理できる利用者数は減ります。

前払いでも不正利用は可用性を下げる

利用者がAPI keyを共有したり、自動化処理を暴走させたりしても、前払い残高を超えた推論を拒否すれば、未回収のGPU費用は発生しません。ただし、短時間の集中利用によるGPU待ち時間、他の顧客の遅延、サービス障害は残ります。これは信用損失ではなく、容量管理と可用性の問題です。

小型モデルは、同一設備の処理容量を増やし得る

より小さく、速く、同等以上に強い公開モデルが登場し、同じB200推論ノードで動くなら、同時実行数、batch size、月間処理token量を増やし、1tokenあたりの固定費を下げられる可能性があります。ただし、市場全体が同じモデルへ移ればAPI単価も下がり得るため、技術的な処理容量の増加が、そのまま利益や設備の市場価値の上昇を意味するわけではありません。

モデル更新と設備更新は、次のように分ける必要があります。

したがって、設備更新リスクが生じるのは、新しいモデルが既存GPUのメモリ容量、演算形式、ソフトウェア対応を超える場合です。小型化そのものは、性能、販売単価、需要を維持できる限り、自社運用の採算を改善する可能性があります。

API運営者自身が攻撃対象になる

検閲がないと称する非公式APIには、犯罪者、研究者、情報提供者、法執行機関、競合が混在し得ます。DDoS、未公開脆弱性、内部不正、顧客情報の窃取に耐える必要があります。

ライセンスが許しても、サービスが合法とは限らない

MITライセンスは、モデル重みの利用・改変・再配布に関する著作権上の許諾です。下流サービスの用途、顧客、出力、輸出管理、制裁、データ保護、税務、資金移動が合法であることまでは保証しません。

GLM-5.2級の非公式LLM APIは海賊版サイトより移転が難しい

海賊版サイトは、データを複製し、新しいドメインとサーバーへ移すことで再出現できます。GLM-5.2を使う非公式APIも、モデル重みとソフトウェア自体は複製できます。

しかし、次の点が異なります。

したがって、遮断後に別名で再出現する可能性はあっても、海賊版サイトと同じ速度・低コストで移転できるわけではありません。

防御側・政策側への含意

今回の試算から、対策の焦点も見えてきます。

重みだけでなく推論インフラを見る

公開された重みは回収できません。しかし、フロンティア級モデルをAPIとして大量提供するには、高密度GPU、電力、回線、保守が必要です。継続的な商用提供には観測可能な集中点があります。

価格と利用量をリスク指標にする

極端に高い価格でも利用量が伸びているなら、通常のチャット用途とは異なる需要がある可能性があります。モデル名だけでなく、料金、稼働率、トラフィックの増加を監視する価値があります。

暗号資産を匿名と決めつけない

オンチェーン分析、交換業者、換金、法定通貨支払いを含めて資金の流れを見る必要があります。Europolの事例でも暗号資産追跡が使われています。

正当な防御用途の受け皿を作る

Fable 5で体験したように、防御目的のSecurity Reviewまで誤検知で止めると、利用者は制約の少ないモデルを探します。検証済み研究者向けアクセス、監査可能なサンドボックス、用途別の権限制御がなければ、正当な需要まで非公式APIへ流れる可能性があります。

おわりに

GLM-5.2のケーススタディを見る限り、公開重みモデルを再調整し、「検閲がない」と称する非公式APIを自社保有GPUサーバーから提供する構成は技術的に検討でき、今回の仮定の下では会計上の損益分岐も計算できます。ただし、これは実需要を確認した事業性評価ではありません。

学習・更新をクラウドへ一本化し、推論用B200ノード1台だけを保有する基本構成では、必要初期資金は約8,552万円です。学習用GPUを資産として抱えずに済み、フロンティアモデルをゼロから事前学習する費用と比べても小さい金額です。

将来、より小さく高速な公開モデルが出て、性能、販売単価、需要を維持したまま同じ推論機で動かせるなら、処理容量と同時実行数が増え、固定費をより多くのtokenへ配賦できます。更新用の学習をクラウドで行うなら、その費用は推論設備の更新とも切り離せます。

月100億tokenの場合、正規化月次損益は公式価格で15,391ドルの赤字、2倍価格で4,609ドルの黒字です。実支出を時系列で置くと、2倍価格でもモデル更新月の単月純キャッシュフローは20,822ドルの赤字になりますが、固定需要が続けば月28に初期投資を回収します。暗号資産の前払いと残高上限により、未払い、返金、チャージバックは基本試算から除外できます。一方、学習クラウドの契約を停止されればモデル更新が止まります。需要、設備故障、推論環境との互換性、DDoS、法執行という不確実性も残ります。

スループット上は、8基B200・FP8の公開最高値が入力8：出力1で約1,056億token/月です。記事の入力4：出力1へ換算したMTPなしの実験上限は約474.1億token/月ですが、一般サービスの公式容量設計を参考に、持続的な出力を60%、単一ノードの可用性を感度分析上99%と置きました。したがって、収益試算の暫定上限は約281.6億token/月です。この上限での正規化月次損益は、公式価格で約20,929ドル、2倍価格で約77,249ドルです。分岐点は公式価格で約177.0億token、2倍価格で約88.5億tokenとなり、暫定上限の約62.8%と約31.4%を使います。

大手が掲げる99.9〜99.99%の可用性は、平均GPU出力率ではありません。複数ノードや複数ゾーンによる冗長性を前提とする値も多く、今回の単一ノード構成では同じ保証を置けません。

したがって、今回の結論は次の通りです。

GLM-5.2と今回の設備・料金仮定では、「検閲なし」を掲げる非公式LLM APIの技術構成は可能であり、仮定した価格と需要を満たせば会計上の損益分岐へ到達する。学習・更新をクラウド、推論を自社保有1ノードへ分けると、必要初期資金は約8,552万円、暫定試算上限は約281.6億token/月となる。正規化月次損益の分岐点は公式価格で約177.0億token、2倍価格で約88.5億tokenだが、その需要が実在するかは未検証である。暗号資産の前払いを使えば信用損失を基本試算から外せるため、試みる主体が現れるシナリオは無視できない。

重要なのは、そのサービスが優良事業になるかではありません。一部の運営者が、短期的な利益や楽観的な見積もりを理由に参入できる程度まで、必要資金が下がっているかです。

「検閲のない非公式LLM APIは経済的に実現するのか」という問いに対し、GLM-5.2と今回の設備・料金仮定から言える答えは、技術構成は可能、表計算上の黒字化は条件付きで可能、市場としての成立は未検証、安定した大規模サービス化は難しいとなります。

参考資料

• GLM-5.2: Built for Long-Horizon Tasks — Z.ai
• Why Claude switched models in your conversation with Fable 5 — Anthropic
• Claude Codeの自動セキュリティレビュー — Anthropic
• IAS 7 Statement of Cash Flows — IFRS Foundation
• GLM-5.2 Model Card — Hugging Face
• GLM-5.2 FP8 — Hugging Face
• GLM-5.2 — vLLM Recipes
• GLM-5.2 — SGLang Documentation
• SGLang: GLM-5.2 B200ベンチマーク値
• SGLang: throughput per GPUの指標定義
• AWS Auto Scaling: scaling strategy
• AWS EC2 Auto Scaling: target tracking
• Google Compute Engine Autoscaler API
• AWS Builders' Library: Static stability using Availability Zones
• Google Kubernetes Engine: Horizontal Pod autoscaling
• Azure Architecture Center: Autoscaling Guidance
• NVIDIA AIPerf: Search Recipes
• OpenAI Scale Tier
• Amazon Bedrock Service Level Agreement
• Amazon Compute Service Level Agreement
• Vertex AI Platform Service Level Agreement
• Google Compute Engine Service Level Agreement
• Z.ai API Pricing
• Amazon EC2 Capacity Blocks for ML Pricing
• DeepSpeed: Memory Requirements
• Hugging Face Transformers: Parameter-efficient fine-tuning
• Exxact: 8×B200サーバーの公開販売価格
• NVIDIA DGX B200 User Guide
• ITAIPU: 2025年の発電・パラグアイ向け供給実績
• ANDE: Pliego de Tarifas No. 21
• World Bank: Cambodia Economic Update, June 2024
• UNODC: Strategic Infiltration of Vulnerable Jurisdictions through Criminal Foreign Direct Investments
• IEA: Kazakhstan 2022
• Europol: LolekHosted bulletproof hosting takedown
• U.S. Department of Justice: Operation Nova
• FATF: Recommendation 16 and payment transparency
• U.S. Treasury: Sanctions against cryptocurrency networks enabling cybercrime