Dr. KiWi に戻る

歷史週報 / Founder Weekly archive

計算も、電力も、スケジューリングする

著者が承認した過去の週報を転載しています。バッチ日は SNS での実際の公開日を示すものではありません。

研究開発の方向性:技術・協業の評価段階で、導入済みの機能や顧客への約束ではありません。

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

外部リンクは著者のプロフィールで、元投稿へのリンクではありません。