Workers AI の Clef が音声・動画入力に対応し、Clef-flash は58%値下げ — ただしホスト版の窓が 64K から 24K へ縮小
Cloudflare が decision model 群 Clef について3件を同時発表した。(1) Clef-omni（@cf/cloudflare/clef-omni）が新規提供され、テキスト・画像・音声（WAV / MP3）・動画（MP4 / WebM）を1リクエストで同時に読む。30B の MoE でアクティブ 3B、$0.150 / 100万入力トークン、窓 64K。(2) Clef-flash が $0.090 から $0.038 / 100万入力トークンへ値下げされた一方、ホスト版のコンテキスト窓が 64K から 24K へ縮小した。公式は「24K を超えるのは 0.24%」とし、64K が必要なら Clef を使うよう案内している。Hugging Face の self-host 用ウェイトは変更なしで 256K まで対応。(3) Clef がウェイト変更なしで最大2倍高速化し、配信基盤が SGLang へ移った。値下げと窓の縮小が同じ発表に同梱されているため、単価だけ見て移行すると 24K 超の入力で失敗する。
ニュース原文を読む ↗要約
Cloudflare が Workers AI の decision model 群 Clef について、3件を同じ日にまとめて発表しました。
まず decision model とは何かを押さえてください。 Clef はテキストを生成しません。許可された回答候補にスコアを付ける方式のモデルです。「このメールはスパムか」「この問い合わせはどのカテゴリか」「この内容は公開してよいか」——答えの選択肢があらかじめ決まっている判定に特化しています。生成しないぶん速く、安い。これが Clef の立ち位置です。
1つ目は Clef-omni の新規提供です。 モデル ID は @cf/cloudflare/clef-omni。テキスト・画像・音声（WAV / MP3）・動画（MP4 / WebM）を1リクエストで同時に読みます。 30B パラメータの MoE で、アクティブは 3B。$0.150 / 100万入力トークン、コンテキスト窓 64K。メディアは images / audio / videos フィールドへ base64 data URL で渡します。
レイテンシの公式数値が具体的です。 テキスト約20ms、画像または音声で100ms未満、音声付き21秒の動画で約300ms。動画を300msで判定するというのは、従来の「文字起こし→テキストモデル」構成では出せない数字です。
2つ目は Clef-flash の値下げです。$0.090 から $0.038 / 100万入力トークンへ。 約58%の値下げで、公式は「Jev より安くなった」と述べています。
ただし、ここに同梱されている条件を見てください。ホスト版のコンテキスト窓が 64K から 24K へ縮小しました。 公式の説明は「24K を超えるリクエストは 0.24%」。つまり「ほとんど影響しない」という前提での縮小です。 64K が必要なら Clef を使うよう案内されています。なお Hugging Face の self-host 用ウェイトは変更なしで、最大 256K まで対応します。
3つ目は Clef 本体の高速化です。ウェイトは変更せず、最大2倍。 中央値レイテンシは約800トークンで 262ms → 152ms（1.7倍）、約3,400トークンで 616ms → 305ms（2.0倍）、約16,000トークンで 2,721ms → 1,635ms（1.7倍）。配信基盤を SGLang へ移したことによる改善で、SGLang 0.5.22 で Clef サポートが入る予定とされています。
この発表の読みどころは、値下げと制約縮小が同じ記事に同梱されている点です。 「58%安くなった」だけを見て移行すると、24K を超える入力だけが静かに失敗します。 0.24% は「無視できる」とも読めますが、自分の実装での分布が 0.24% かどうかは、公式には分かりません。
何が変わったか
- Clef-omni が新規提供（
@cf/cloudflare/clef-omni、modelセレクタはclef-omni）- 入力: テキスト・画像・音声（WAV / MP3）・動画（MP4 / WebM）を1リクエストで
- アーキテクチャ: 30B MoE / アクティブ 3B。生成せずスコアリング
- レイテンシ: テキスト約20ms、画像・音声100ms未満、音声付き21秒動画で約300ms
- 価格: $0.150 / 100万入力トークン、窓 64K
- 渡し方:
images/audio/videosへ base64 data URL
- Clef-flash の価格が $0.090 → $0.038 / 100万入力トークン（約58%値下げ）
- ホスト版のコンテキスト窓が 64K → 24K へ縮小
- 公式の根拠: 「24K を超えるリクエストは 0.24%」
- Hugging Face の self-host 用ウェイトは変更なし・最大 256K 対応
- Clef が最大2倍高速化（ウェイト変更なし）
- 約800トークン: 262ms → 152ms（1.7倍）
- 約3,400トークン: 616ms → 305ms（2.0倍）
- 約16,000トークン: 2,721ms → 1,635ms（1.7倍）
- 配信基盤が SGLang へ移行。SGLang 0.5.22 で Clef サポート予定
- Clef の価格は $0.240 / 100万入力トークン、窓 64K
業務インパクト（一般企業向け）
最初にやることは、Clef-flash へ投げている入力長の実測です。
値下げは自動で効きますが、窓の縮小も自動で効きます。 「24K を超えるのは 0.24%」という公式の数字は、Cloudflare 全体の分布です。自社の実装がどうかは別の話です。長い文書を丸ごと判定に投げている処理があれば、そこが 0.24% の側に入ります。
確認の仕方は単純です。 直近のログから、Clef-flash へ渡している入力のトークン長の分布を出してください。24K 超が1件でも出るなら、その経路は Clef（窓 64K、$0.240）へ振り分けるか、入力を切る設計に変えます。単価は Clef-flash の約6.3倍になりますが、24K 超のリクエストだけなら総額への影響は限定的です。
判定が静かに失敗する種類のエラーなので、監視を先に入れてください。 decision model の呼び出しは、多くの場合「判定できたら使う、できなければ既定値」という扱いになっています。窓超過で失敗したとき、既定値にフォールバックして何も起きない実装だと、判定の品質だけが落ちて誰も気づきません。 窓超過のエラー率を単独で見られるようにしてから切り替えてください。
Clef-omni は、文字起こし段を外せるかの検討材料になります。 音声や動画を判定に使っている処理は、ほぼ例外なく「文字起こし→テキストモデル」の多段構成になっています。この構成は、文字起こしの誤りがそのまま判定に伝播するうえ、段数ぶんのレイテンシと単価が乗ります。Clef-omni は1リクエストで済みます。
ただし「スコアリング方式である」という制約を忘れないでください。 Clef-omni は回答候補が決まっている判定にしか使えません。「この動画の内容を要約して」はできません。「この動画は規約違反か」「この問い合わせ音声はどのカテゴリか」——選択肢を列挙できる問いだけです。多段構成を畳めるのは、判定が最終目的である処理に限られます。
コールセンターの音声、投稿動画の審査、会議録の自動分類あたりが、現実的な適用先です。21秒の動画を300msで判定できるなら、投稿時のリアルタイム審査が成立します。従来は非同期バッチに回すしかなかった処理です。
既存の運用ドキュメントの単価表は、この日付で古くなりました。 Clef-flash を $0.090 として見積もっている資料があれば直してください。同時に窓の記述も直す必要があります。 価格だけ更新して窓を放置すると、次に見た人が「安い方を使えばいい」と判断して壊します。
副業・個人活用視点
この発表は「値下げの裏に制約が付いてくる」典型例として、そのまま記事になります。
58%値下げはニュースになりますが、窓の 64K → 24K はなりません。 公式の changelog でも blog でも、値下げと並列に1文で書かれているだけです。「安くなった」で終わる記事と、「安くなったが窓が3分の1になった。自分のログで分布を確認する手順はこうだ」と書く記事では、読者にとっての価値が違います。 後者は検索されて読まれ続けます。
実測の手順を書けるなら、それが一番価値のある部分です。 入力トークン長の分布をどう出すか、24K 超をどう振り分けるか、窓超過のエラーをどう監視に出すか。公式はどれも書いていません。 自分の実装で一度やれば書けます。
decision model という考え方自体が、個人開発で効きます。 「LLM に判定させる」とき、多くの人は生成モデルへプロンプトを投げて出力をパースします。これは遅く、高く、壊れやすい。 選択肢が決まっているなら、スコアリング専用のモデルを使うほうが素直です。$0.038 / 100万トークンという単価は、個人の趣味プロジェクトでも気にせず回せる水準です。
Clef-omni は、個人で作る「審査つき投稿サービス」のハードルを下げます。 音声や動画の投稿を受け付けるサービスを個人で作るとき、審査が最大の障壁でした。人手は無理、文字起こし多段は遅くて高い。1リクエスト300msで判定できるなら、投稿フローの中に同期で入れられます。
注意点として、self-host 用ウェイトは窓が変わっていないことを押さえてください。 Hugging Face 版は 256K まで対応し、今回の縮小の対象外です。長い入力を扱う必要があって単価も抑えたいなら、self-host が選択肢に残っています。 ホスト版の制約を self-host の制約と混同して「Clef-flash は 24K しか使えない」と書くと、間違いになります。
SGLang への移行は、技術記事の切り口として単独で成立します。 「ウェイトを変えずに配信基盤を替えるだけで1.7〜2.0倍」という事例は、推論サーバーの選択がどれだけ効くかを示す具体的な数字です。自分のモデルを動かしている人には、確実に刺さります。