GPU、本当にイルカ？〜100頭のイルカの脳ミソでGPU作って機械学習！【Iruka AI】〜

https://github.com/HukuKaich0u/progate_aws_hackathon_dolphin

―

TypeScript

React

Python

Rust

EC2

100頭のイルカの脳ミソで機械学習！【Iruka AI】

Koki Aoyagi

Teba_eleven

Maaya

推しアイデア

イルカの人間（脳化指数1位）に次ぐ高い脳化指数と群れの習性を、LLMやAIなどの大規模計算に活用するイルカコンピューターの開発。128台のEC2（イルカ）を並列で動かし、超並列計算を実現！！

作った背景

AWS環境でEC2のGPUが使えないことが判明。イルカの超知能をAWS上に構築すれば、GPUが不要に。

推し技術

- CPUのみで大規模並列演算を実現する分散アーキテクチャ - EC2を並列活用するクラスタ設計 - 行列演算を複数ノードへ分配する独自アルゴリズム - Dockerによる再現性の高い実行環境 - インフラからアプリまでフルスクラッチで構築したMLOps基盤

プロジェクト詳細

100頭のイルカの脳ミソで機械学習！【Iruka AI】

タイトル

100頭のイルカの脳ミソで機械学習！【Iruka AI】

サービス概要

image image image

  • 126台のEC2インスタンス（CPU）のみで機械学習を実行する分散並列基盤
  • 1時間$3.6の格安でGPU不要で低コストな大規模計算を実現
  • 複数マシンを連携させて1つの計算資源として利用

推しアイデア
  • イルカの「知能＋群れの協調性」を設計に反映
  • イルカは人間の次に賢く、群れで活動する→GPU→CPUに
  • 高性能1台ではなく「多数の普通のPCを連携」
  • CPUクラスタで巨大コンピューターを構成
  • 128台のEC2で並列計算を実行

作った背景
  • イルカの知能を計算機として再解釈した発想
  • 元は音声AI（イルカ通信）の開発からスタート
  • GPU制約により開発方針を転換
  • GPU不要の分散基盤を自作する方向へ
  • インフラ〜UIまでフルスクラッチで構築
    image

ターゲット
  • 高価なGPU環境をすぐに用意できない個人開発者・学生
  • 限られた予算でAIや機械学習に挑戦したい小規模チーム
  • 分散処理や並列計算の仕組みそのものに興味があるエンジニア
  • 「普通の計算機をどう束ねれば大きな計算力になるか」を試したい人

技術構成・アーキテクチャ

image

  • GPUではなくCPUを大量利用
  • 処理を分割→配布→集約
  • 専用ハードに依存しない設計
  • インフラからUIまで自作
    image image

主な構成
  • EC2
    • 128台のインスタンスを並列で稼働させ、計算ノードとして活用
  • Docker
    • 実行環境をコンテナ化し、各ノードに同一の処理基盤を展開
  • 独自分散プロトコル
    • AI・機械学習に必要な行列演算をノード間で分割し、並列処理できるように設計
  • 独自オーケストレーション
    • SageMakerなどのマネージドサービスに頼らず、フルスクラッチでノード管理と処理実行を実装
  • UI / 可視化レイヤー
    • 分散された計算が群れとして動いている様子を確認できるインターフェースを構築

アーキテクチャのポイント
  • GPUではなくCPUを大量利用
  • 処理を分割→配布→集約
  • 専用ハードに依存しない設計
  • インフラからUIまで自作

推し技術

image image image

  • CPUのみで大規模並列演算を実現する分散アーキテクチャ
    • CPU：複雑なことができて遅い
    • GPU：シンプルなことしかできないけど早い
  • EC2を並列活用するクラスタ設計
  • 行列演算を複数ノードへ分配する独自アルゴリズム
  • Dockerによる再現性の高い実行環境
  • インフラからアプリまでフルスクラッチで構築したMLOps基盤
  • 耐障害性が126倍
  • Dockerを活用することで、FastAPIやLangChainを含むアプリケーションをGPU環境でも再現性高く実行できる。
  • 実測値55倍で理論値125倍
  • 同時リクエスト処理 image

ターゲットに刺さる機能
  • 普通のCPUマシンを束ねて巨大な計算資源として扱える
  • 高価なGPUに依存せず、AI開発の計算基盤を自前で構築できる
  • 分散された処理の流れを可視化し、システム全体の動きを把握しやすい
  • 将来的に音声認識やLLMなど、重いAIワークロードへの応用が可能

技術的遊び
  • AI・機械学習に必要な行列演算を、EC2群で並列処理できるよう独自プロトコルとして設計した
  • マネージドML基盤に頼らず、インフラ・サーバー・コンテナ・UIをフルスクラッチで組み上げた
  • 「イルカの群れ」を計算機アーキテクチャに見立てることで、技術コンセプトとプロダクト体験を統一した

遊びごころポイント
  • 普通のGPU 1台に比べると圧倒的に遅いのに、むしろ大規模なインフラを必要とするところ
  • GPUを使わずに、CPUだけでGPU的な超並列処理の世界観を再現しようとしたところ
  • 技術的には真面目に難しいのに、発想の入口が「イルカは頭が良すぎる」なところ

アプリ画面
  • スクリーンショット差し込み予定
  • デモ動画差し込み予定

挑戦したこと・成長したこと

チームとしての挑戦
  • GPUが使えないという制約を前提に、発想を転換して独自の分散計算基盤を設計した
  • 限られた時間の中で、アイデア出しからインフラ、バックエンド、UIまで一気通貫で形にした
  • 単なるネタにせず、CPUクラスタ・Docker・AWSを使った技術的実装に落とし込んだ

青柳

selfmade_docker x iruka_cnn

[https://github.com/HukuKaich0u/selfmade_docker/tree/main]

Docker の「上位管理レイヤ」を Rust で切り出し、その上に CNN 推論 API を載せた

今回やったことは、Docker をブラックボックスとして使うのではなく、Docker が内部で担っている責務のうち「コンテナを管理する上位レイヤ」だけを明示的に抜き出して、自分で実装することです。mydocker は単なる CLI ではなく、docker run の背後で Docker Engine が本来やっている「OCI bundle を受け取る」「bundle が実行可能か検証する」「container ID を払い出す」「状態を永続化する」「runtime に create/start/delete を指示する」といったオーケストレーションを持っています。つまり、コンテナを動かすための low-level な仕組みそのものではなく、その上でワークロードを安全に受け止めるための管理面を Rust で組み立てた、というのがこのプロジェクトの核です。

今回はその mydocker の上に iruka_cnn の FastAPI worker を載せました。アプリ側は WAV を受け取り、log-mel 特徴量に変換し、2D CNN で登録済みの日本語定型文を分類して返します。つまり、ローカルでしか動かない ML 実験コードを作ったのではなく、自作したコンテナ管理レイヤの上に推論 API という実ワークロードを載せて、EC2 上で外部から叩ける状態まで到達させた、というのが今回やったことです。

ここで強調したいのは、作ったものが「Docker を呼ぶラッパスクリプト」ではないことです。mydocker は、コンテナ実行に必要な入力を受理し、実行単位として識別し、ライフサイクルを状態として持ち、失敗も含めて管理できるようにしています。これは実際には、コンテナを単発で起動するだけの道具ではなく、「あとから image 管理、network、volume、複数 worker 配置へ拡張できる engine の芯」を先に作った、という意味です。短い開発期間であっても、アーキテクチャの重心を正しく置いたことで、単なるデモ実装より一段上の土台を用意できています。

mydocker は Docker のどこを実装したか

Docker 全体を再実装したわけではなく、mydocker が担うのは Docker のうち「コンテナを管理する上位レイヤ」です。namespace / cgroup / mount のような low-level runtime の責務は youki に委譲し、その代わりに bundle 検証、container ID 管理、状態遷移、CLI、実行オーケストレーションを自分で持っています。Docker でいうと、CLI から受けた要求を runtime に落とし込む daemon / engine の薄い中核を実装しているイメージです。重要なのは、mydocker は「コンテナを作る・動かす・消す」という操作を単に外部コマンドへ横流ししているだけではなく、その前後で bundle の正当性確認、container の識別、状態保存、失敗時のロールバックまで担っていることです。

この責務分離は、単に実装量を減らすためではありません。Docker の難しさは「コンテナを起動すること」そのものだけでなく、「どの入力をどう扱い、実行中の単位をどう識別し、失敗時にどう整合性を保つか」という管理面にあります。mydocker はまさにその管理面をコードとして持ち、実行対象が増えても破綻しない形に整理しています。だからこそ、今回の成果は 1 本のコマンドを通しただけではなく、「管理プレーンを設計して実装した」と言える内容になっています。

  • cli.rs: run/create/start/delete/state を受ける入口
  • bundle.rs: config.json と rootfs/ を検証して OCI bundle を受理
  • state.rs: /run/mydocker に container_id, bundle_path, status を保存
  • runtime.rs: youki create/start/delete を組み立てて実行
  • lib.rs: run = create + start、失敗時 rollback、状態遷移を統括

この構造によって、mydocker は「どの bundle を、どの ID で、どういう状態として、どの runtime 呼び出しで扱うか」は知っていますが、「Linux namespace をどう張るか」「cgroup をどう切るか」といった low-level 実装詳細までは持ちません。ここが Docker 全部を真似するのではなく、Docker の責務を分解したうえで管理面だけを引き剥がして実装した、という技術的なポイントです。

その中で youki が重要なのは、runtime 層を信頼できる OCI 実装に委譲することで、自分の実装の焦点を orchestration に絞れるからです。もし namespace / cgroup / mount まで全部自作しようとすると、今回のように「実際のアプリを載せて価値を検証する」前に runtime 実装だけで時間を使い切ります。youki を使うことで、mydocker は low-level 実装の代替品ではなく、「runtime を使って実ワークロードを運ぶための管理基盤」として前に進めます。つまり youki は妥協ではなく、責務分離を成立させるための戦略的な選択です。

さらに youki を使う価値は、OCI 準拠の runtime という標準的な足場の上に、自分の engine 層を載せられることです。これによって mydocker は Linux コンテナ技術をゼロから再発明するのではなく、既存の runtime ecosystem に接続しながら、自分が差別化したい管理責務に集中できます。言い換えると、youki があるからこそ mydocker は「実験的な一発ネタ」ではなく、「標準 runtime の上で独自の engine を育てる」方向へ進めます。この設計判断があるので、今回の実装は小さく見えても、技術的にはかなり筋が良いです。

その結果、今の mydocker でできることは明確です。create で OCI bundle を受け付けて container を登録し、start で実行し、state で状態を確認し、delete で後始末できます。さらに run は create + start をまとめて扱い、失敗時は state を runtime_failed に更新したうえで rollback まで行います。つまり、単発のデモ用スクリプトではなく、最低限の lifecycle を持った管理プレーンとして振る舞えるところまで来ています。

しかもこの lifecycle は、単にコマンドが存在するというだけではありません。bundle の妥当性確認から runtime 呼び出し、状態遷移、エラー処理までが一つの流れとしてまとまっているので、実際にワークロードを載せたときに「何が起きているか」を追跡できます。コンテナ管理の難所は、正常系よりも失敗系と状態整合性にあります。そこまで含めて最初から押さえているので、mydocker はミニマルでも設計としてかなり本格的です。

image

その上で ML 推論ワークロードを載せた

今回はこの管理レイヤの上に、iruka_cnn の推論 worker を載せました。アプリ側は FastAPI で /healthz と /infer を提供し、/infer では受け取った WAV を decode して mono 化し、log-mel 特徴量へ変換し、2D CNN に通して label / confidence / unknown を返します。ここでのポイントは、ML モデルそのものの精度だけを見せたのではなく、その推論処理を HTTP API として包み、さらにその API を mydocker が container として受け止めて起動できることを確認した点です。つまり「モデルがある」から一段進んで、「モデルをワークロードとして運べる管理基盤がある」という段階まで進めています。

この差はかなり大きいです。モデルをローカルで推論できることと、モデルをサービスとして配置できることの間には、実行環境のパッケージング、起動責務、状態管理、外部からの到達性というギャップがあります。今回はそのギャップを mydocker + youki + OCI bundle で埋めています。つまり、ML のデモを作ったのではなく、ML ワークロードを載せられるコンテナ基盤の最小実証をやった、という見方ができます。

image

結果として、CNN モデル込みの FastAPI worker を bundle 化し、mydocker run <bundle> で EC2 上に起動し、/healthz と /infer の疎通まで確認できました。言い換えると、自作したのは「おもちゃの CLI」ではなく、実際の ML 推論 API を受け止められる Docker 風の管理基盤です。low-level runtime をスクラッチせず youki に委譲したことで、実装の重心を orchestration に置き、短期間でも bundle 受理、状態管理、runtime 連携、実アプリ搭載まで一気に進められました。ここが今回の技術的な価値であり、次に image 入力、network、複数 worker へ伸ばしていくための土台にもなっています。

言い換えると、今回の成果は「Rust で Docker っぽいコマンドを作ってみた」ではありません。OCI bundle、runtime orchestration、lifecycle 管理、推論 API 搭載、EC2 配備という複数の層をつなぎ、コンテナ管理レイヤとして成立する最小コアを作ったことに価値があります。しかもそれを、抽象的な設計だけで終わらせず、実際の CNN ワークロードを通して検証しているので、アーキテクチャの妥当性がコードと実行結果の両方で裏付けられています。だからこそ、このプロジェクトは小さく見えても、技術的にはかなり密度の高いことをしています。

秋穂

〇挑戦した点・成長した点

  • 入力は音声を画像のように変換した「ログメルスペクトログラム（1チャンネル）」
  • CNN構成
    • 4層の畳み込みブロックを使用
    • 各ブロック：Conv → 正規化 → ReLU → プーリング
    • チャネル数：1 → 32 → 64 → 128 → 128
    • 最後に平均プーリング → 全結合層
    • 出力は2つ
      • 26クラス分類（定型文 + unknown + silence）
      • 128次元の特徴ベクトル（L2正規化）
  • 特徴・こだわり
    • 特徴ベクトルも出力できるため、類似音検索や拡張が可能
    • unknownとsilenceを学習に含めている
    • confidenceとmarginの二段階でunknown判定
    • Apple Silicon（MPS）で高速処理
    • 音声は事前に特徴量（.npy）へ変換してキャッシュ
    • データ拡張あり（ノイズ・音量・周波数変化など）
  • データ量
    • クラス数：26（定型文24 + unknown + silence）
    • 合計：約12,000音声
      • train：約8,160
      • val：約2,016
      • test：約2,016
  • 音声処理の流れ
    • WAV読み込み
    • モノラル化・リサンプリング
    • 音量正規化
    • 2.5秒に切り出し
    • ログメル変換（画像化）
    • .npyで保存
  • 学習高速化の工夫
    • 学習時はWAVを読まず.npyのみ使用
    • STFTをスキップして高速化
    • DataLoaderで並列・先読みを活用
  • まとめ
    • 音声を画像として扱うCNNで、高速かつ拡張性の高い設計

中町

〇物理限界を書き換える「DIY GPU」の構築

image image

  • 数の暴力で勝負: 使用可能なvCPU枠を限界まで使い切り、t3.small 125台を並列起動して1つの巨大な推論クラスタを構築。
  • 擬似CUDAコアアーキテクチャ: 125台のCPUを「GPUの演算コア」に見立て、asyncioによる非同期制御を「カーネル発行」として再定義。インフラ操作力によって物理的な制約を「仕様」として上書きした。

〇あえて「CPU 125台」を選んだ理論的正当性

  • この挑戦は単なる代用ではなく、モデル特性を見抜いた極めて合理的な選択である。
  • GPUに匹敵する処理能力: 125台の分散により、GPU 1枚（推定 3,000 req/s）と遜色ない秒間 2,464件のスループットを実証した。
  • 単発推論での圧倒的コスパ: 今回のような軽量モデルの単発推論では、GPUよりもCPUの方が効率が良く、コストを7倍抑えることが可能である。（バッチ処理を行わない場合）。
  • 並列化による耐障害性: 1台の巨大サーバーではなく125台に分散させることで、一部の故障が全体に影響しない、フォールトアイソレーション（障害隔離）の効いた強固なシステムを実現した。

〇結論：証明された技術者の意地

  • 精度 100%の達成: 125台のどこにリクエストが飛んでも完璧な正解を返す、寸分狂わぬ分散モデル配布と推論精度を完遂。
  • 制約を力に変えるエンジニアリング: 「環境がない」ことを言い訳にせず、手持ちのカード（CPU枠）をどう組み合わせて最強の回答を出すか。既存の枠組みを技術でハックする、まさにエンジニアの本質を体現した挑戦となった。

三繩

挑戦したこと

  • Linux / Ubuntu 環境のセットアップ
  • ユースケース図、画面遷移図の作成
  • イルカの生態に関するアイデア出し
  • backend/python の API 土台作り image

成長したこと

  • Linux環境を自力で構築できるようになった
  • アイデアを抽象化・具体化する過程で、新しい発想を広げられるようになった
  • イルカの知能や生態に関する知識が深まった
  • バイブコーディングの流れを理解し、AIに対して前提やスタックを明示する重要性を学んだ

新藤

挑戦したこと

  • Docker、VS Code、WSL2 を短時間で導入し、開発環境を整えた
  • イルカの生態を活かしたアプリのアイデアを多数発想した
  • ユースケース図の考え方や CRUD の整理方法を学び、実践した
  • Markdown や Figma を使って、アイデアを具体的な形に落とし込んだ
  • Topa'zをわかりやすく、論理的に作成した image image

成長したこと

  • イルカの生態について集中的に調べ、知識を自分の言葉で説明できるレベルまで理解を深めた
  • プログラミングや開発に関する専門用語を吸収し、チーム内で共有できるようになった
  • 自分の考えや進路の話をチームに伝える中で、説明力をブラッシュアップできた

チームワーク・チーム開発で工夫したところ
  • イルカの生態という共通テーマを置くことで、アイデア出しと技術設計の方向性を揃えた
  • それぞれのメンバーが、環境構築、発想、設計、実装など異なる役割からチームに貢献した
  • 制約にぶつかったときに諦めず、GPUが使えないならCPUクラスタを作るという方向転換を行えた
  • ネタの面白さだけで終わらせず、実際にAWS・Docker・分散処理という技術スタックへ落とし込んだ

まとめ
  • CPUクラスタによる分散計算基盤
  • GPU不要の新しいアーキテクチャ
  • イルカの群れをモチーフに設計
  • 制約から生まれた技術的挑戦が価値

Koki Aoyagi

@kokiaoyagi