Dr. KiWi に戻る再設計した概念カバーで、元画像ではありません。
歷史週報 / Founder Weekly archive
計算も、電力も、スケジューリングする
著者が承認した過去の週報を転載しています。バッチ日は SNS での実際の公開日を示すものではありません。
研究開発の方向性:技術・協業の評価段階で、導入済みの機能や顧客への約束ではありません。
今週、AI-EDC の技術的な方向性を議論する中で、私はずっと考えていました。
計算能力のために電力を探すだけでなく、計算の側も電力の都合に合わせられないだろうか。
私たちは、異なるデータセンターの計算処理スケジュールとエネルギー運用を一緒に考える研究開発の方向性を評価しています。現在はまだ技術と協業の評価段階で、実際の検証は完了しておらず、顧客に約束できる機能でもありません。
しかし問題を分解してみると、取り組む価値があると感じます。
従来のデータセンターの議論では、必要な MW、契約できる PPA、設置する蓄電容量を先に尋ねるのが普通でした。実際のワークロードを見始めると、同じ電力使用でも、仕事ごとの条件は大きく異なると分かります。
リアルタイム推論には遅延要件があり、電気料金が高いからといって顧客を待たせるわけにはいきません。GPU 学習を延期できるかどうかは、タスクの期限、進捗の保存・復元コスト、機器の空き状況次第です。拠点間の移行には、データ移動やセキュリティの制約もあります。
緊急時のために確保した UPS の予備容量を、そのまま取引収益の計算に使うこともできません。
こうした条件が明確でなければ、モデルがどれほど見栄えのよい費用削減額を出しても、私は安心できません。
電気料金が下がっても顧客の仕事が期限を超えたなら、それは最適化ではなく、コストを別の場所へ移しただけです。
だから KiWi の次段階の AI-EDC への私の要求は明確です。まずサービス上の約束と動かせない負荷を定義し、その後で使える柔軟性がどれだけ残るかを確認すること。
エネルギー側は 15 分単位の電力使用、PPA 供給、蓄電状態を理解する必要があり、計算側はタスク期限、機器条件、サービス品質を把握する必要があります。別々に計算して、最後になって互いに実現できないと気づくわけにはいきません。
これから本当に時間をかけるべきなのは、データを取得できるか、誰が制御権を持つか、指令をどう実行するか、結果をどう検証するかです。
こうした作業は美しいプレゼン資料にはしにくいものですが、一つ省けば、現場で問題が一つ増えるかもしれません。
起業してここまで来て、私はこうした接点をますます重視しています。多くの機会は機能をもう一つ増やすことではなく、もともと別々に動いていた二つのシステムを、本当に連携できるようにつなぐことから生まれます。
計算も、電力も、スケジューリングする。
ただし順番を間違えてはいけません。まず計算サービスを守り、その後で系統の柔軟性を考える。
一つひとつの kWh を、もっと賢く。
Steve
#KiWiNewEnergy #AIEDC #AI計算センター #蓄電 #PPA #スマートエネルギー #エネルギー管理 #MakingEverykWhSmarter
外部リンクは著者のプロフィールで、元投稿へのリンクではありません。
