ハクソク

世界を動かす技術を、日本語で。

より小型化、高速化、安全化：KimiとGLMを大規模に運用する

2026年8月4日原文(blog.cloudflare.com)

概要

Cloudflare Workers AIは、Kimi KシリーズやGLMなど大規模モデルの推論を効率的に提供。 メモリ制約を克服するため、KVキャッシュの量子化やモデル重みの圧縮など三つの最適化を実施。 パフォーマンス維持とコスト削減を両立しつつ、モデル精度は損なわないことを実証。 SGLangフレームワークを活用し、最先端のベンチマークで高い性能を確認。 今後も最適化を進めつつ、さらなるユーザー拡大を目指す。

Workers AIによる大規模モデルの効率的推論

  • Workers AI は、CloudflareデータセンターのGPU上で Moonshot Kimi Kシリーズ や Z.ai GLM などの大規模オープンモデルを提供
  • これらのモデルは 長文コンテキスト や Mixture-of-Experts 構造により高性能だが、 メモリ消費量が非常に大きい
  • 従来の最適化（prefillとdecodeの分離）に加え、 KVキャッシュ量子化 ・ モデル重み圧縮 ・ KVキャッシュ保護 の三つの技術を導入

KVキャッシュの量子化

  • モデルが生成するテキストの各トークンについて、 アテンションキー（K）とバリュー（V） を KVキャッシュ に保存
  • 通常は 16ビット精度（BF16） だが、 8ビット浮動小数点（FP8, e4m3） にすることでキャッシュサイズを半分に圧縮
  • 例：Kimi K2.6で 約68万→約137万トークン までメモリ内保持が可能
  • FP8化 により同時リクエスト数が倍増し、 最大トークン処理速度は約41%向上、コストは約30%削減
  • モデルの 精度（各種ベンチマーク）に影響なし を検証済み

モデル重みの圧縮

  • モデル重み もGPUメモリ消費の主因
  • 例： GLM 5.2 の重みを 8ビット（FP8）→4ビット整数（INT4） へ圧縮
  • チェックポイントサイズが 705GB→421GB（約40%削減）、1GPUあたりのメモリ消費も大幅減
  • INT4圧縮でも 精度はFP8とほぼ同等 （各種ベンチマークで0.8ポイント以内の差異）
  • decodeフェーズ ではデータ転送量減少により 速度向上、 prefillフェーズ は若干遅くなるが分離設計で最適化可能

共有KVキャッシュの保護

  • 上記最適化により 1GPUで多数リクエストが同時にKVキャッシュを共有
  • キャッシュ整合性チェック を実装し、ページタグで再割当てを管理
  • 不整合検出時は該当リクエストを中断し、誤ったデータ返却を防止
  • パフォーマンス影響は1%未満 に抑制、デフォルトはno-opでオーバーヘッドなし

SGLangフレームワークの活用

  • SGLang はオープンソースの高性能推論サービング基盤
  • Cloudflareは SGLangチームと協力 し、パッチや新機能をコミュニティに還元
  • 実験・本番トラフィックともに SGLangでベンチマーク、最高水準の性能を実現

今後の展望

  • FP8 KVキャッシュ の更なる普及
  • Blackwell（NVIDIA新GPUアーキテクチャ） での NVFP4重み の検証
  • キャッシュ整合性チェック の全展開と低コスト化
  • コスト削減と高精度を両立しつつ、より多くのユーザーへのサービス拡大を目指す

採用案内

  • 大規模オープンモデルをGPUに最適化し、数百万開発者に届ける課題 に興味がある方は、Cloudflareでの活躍を歓迎

Hackerたちの意見

この文章を読むのに興味があったんだけど、「どこから利益が来るのかを正確にする価値がある。なぜなら、生のスピードではないから。」って段落でスロップセンサーが反応しちゃった。AIは好きだけど、読むのは本当に苦手なんだよね。

└

これについてコメントするのをやめざるを得なかった。ここにある投稿の50%に関わることになっちゃうから。ここでAI生成の文章にフラグを立てて、フィルタリングできたらいいのにって思ってる。

└

Cloudflareのブログは人間が読むためのものじゃないと思うよ、私の知る限りでは。エージェントにフィルタリングさせるための生の素材なんだ。内容はほとんど読まないけど、通常はThe Atlanticの記事よりも言葉が拡張されすぎてるから。

└

ちょっと複雑な気持ちになってきた。フォローしているTwitterアカウントが素晴らしい意見や深い個人的な投稿をしてるんだけど… でも、彼は明らかにどこかでLLMを使ってる。AI的な表現が散りばめられすぎてて無視できない。あまり嬉しくはないけど、彼は明らかに全体的に自分の文章を改善するために使ってるんだよね。個人的で関連性のある素晴らしいアイデアを伝えるために。あまりにも融通が利かないのは誰にも得にならないって決めた。もし本当にスロップなら、今後その作家を再訪しないけど、AIを使って独自の声を磨いているなら、それを受け入れて共存することにするよ…

└

これについてコメントしに来た。

└

「どこから利益が来るのかを正確にする価値がある。なぜなら、それは単なるスピードではないから。」面白いのは、AIが英語を「学んだ」かのように見えるけど、実際にはそうじゃないこと。人々はそんな変な構文で話さない。あの文章は、まるで「カレン」が主張しようとしてるみたい。私がAIを使う開発者として怖いのは、LLMもコードに対して同じことをすること。見た目はちゃんとしたコードに見えるけど、ちょっと掘り下げると実際はそうじゃない。冗長で、何も追加してない。ただの無限の言葉遊び/雑なパスタ。驚くことに、2026年なのに、開発者たちは自分の雑なLLM風のコードをブログ投稿の前に整理することすら面倒くさがってる。

└

それを乗り越えられるといいね。もうすぐ、実際にすべてがAIによって書かれるようになるから。毎日何百万人もがこれを使って書いてるよ。

KVキャッシュの量子化について透明性を持っているプロバイダーを見るのはいいね。いくつかのプロバイダーが、量子化されていない重みを大々的に宣伝しながら、静かにこれを行っているんじゃないかと疑ってた。KV量子化は重みの量子化よりも品質を劣化させることがあるからね。でも、彼らのテストがもっと詳細だったら良かったな。まず、モデルファミリーによってKV量子化に対する感度が違うし（Kimi K2.6だけがテストされた）。次に、FP8 KV量子化が区別できないと主張するために使っている評価スイートには、コーディングベンチマークが明らかに不足している。長時間のタスクでは、ちょっとしたツール呼び出しエラーが時間とともに積み重なっていくからね。

└

vLLMの研究も「FP8は小さな、または無視できる精度損失で意味のあるレイテンシとキャパシティの向上を提供できる」と結論づけている。彼らのベンチマークにはLiveCodeBench 6が含まれてる。 https://vllm-project.github.io/2026/04/22/fp8-kvcache.html

└

彼らは非常に強い主張をしたね。> モデルの回答が変わらなければ、これらは全く重要ではない。もし彼らが回答が変わらないと主張したいなら、トークン確率出力の統計的距離を計算するべきだと思う。結果が合理的な解釈で回答が変わらないことを示すとは思えないけど、結果がまだ十分良いかもしれないね。

Cloudflareダッシュボードで価格を見る ↗ なんで… Cloudflareのエンドポイントを使う価値があるか見たかったのに、価格すら見れない。

└

これがどれくらい正確かは分からないけど、ここに価格があるよ: https://openrouter.ai/provider/cloudflare

Hacker Newsで議論の続きを見る