- ユーザーの近くでアプリを実行する Fly.io に GPU サポート が追加され、AI 推論を中央リージョンではなくエッジ近くに配置できるようになった
- アプリには Nvidia A100 を接続して CUDA と大容量 VRAM を活用でき、音声認識、テキスト分割、記事要約、画像生成、コード補助モデルの実行に使える
- Ollama ベースの GPU アプリは
fly.toml に vm.size = "a100-40gb" と ollama/ollama イメージを指定したうえで、fly apps create と fly deploy でデプロイできる
- GPU 対応リージョンでは同じプログラムを同じ公開 IP と TLS 証明書で実行でき、
fly scale count 2 --region ams のように Amsterdam リージョン へ拡張できる
- A100 40GB は 1 時間あたり $2.50、A100 80GB は $3.50、L40s は $2.50 で、自動起動・停止を設定すればリクエストがないときの GPU 時間課金 を避けられる
ユーザーの近くに配置する GPU 実行
- Fly.io は、フルスタックアプリや Fly Machines API ベースの開発プラットフォームをユーザーの近くで実行できるクラウドで、ここに GPU 実行 が追加された
- Fly.io GPU は Nvidia A100 をアプリに接続し、CUDA とローカルの 4090 より多い VRAM を活用できるようにする
- 適用できる AI/ML ワークロードは次のとおり
Ollama GPU アプリのデプロイ
- Fly.io は、ユーザーが好みのモデルと自作コードを Fly.io クラウドバックボーン上にデプロイする方式を目指している
- Ollama ベースの GPU アプリは
fly.toml の設定とデプロイコマンドだけで実行できる
app = "sandwich_ai"primary_region = "ord"vm.size = "a100-40gb"- ビルドイメージは
ollama/ollama
/root/.ollama に 100gb ボリュームをマウントする
- 実行コマンドは次のとおり
fly apps create sandwich_ai && fly deploy
リージョン近くで行う推論
- Fly.io が強調するポイントは、単なる GPU 提供ではなく エッジ推論 にある
- サンプルアプリは、ユーザーがキッチンにある材料を入力するとサンドイッチのレシピを受け取れる構成になっている
primary_region = "ord" でデプロイすると、Chicago 近郊のユーザーはすばやくサンドイッチのレシピを受け取れる- Chicago 以外のユーザー、たとえば Amsterdam のユーザーは、リクエストが大西洋を越える必要があるため時間がかかる場合がある
- GPU 対応リージョンでは、同じプログラムを同じ公開 IP アドレスと同じ TLS 証明書で実行できる
- Amsterdam への拡張は次のコマンドで行う
fly scale count 2 --region ams
リクエストがあるときだけ使う GPU
- GPU は強力な並列処理装置だが安価ではないため、小規模アプリではユーザーからのリクエスト時にだけコストが発生する構成が有利だ
fly.toml の services セクションで自動起動と自動停止を設定できる
[[services]]
internal_port = 8080
protocol = "tcp"
auto_stop_machines = true
auto_start_machines = true
min_machines_running = 0
auto_stop_machines = true と auto_start_machines = true は、リクエストがないときにマシンを停止し、必要なときに再起動する設定だmin_machines_running = 0 なら、サンドイッチのレシピ要求がないときは GPU 時間コスト が発生しない
提供される GPU と基本リソース
- GPU は米国および EU の複数リージョンと Sydney で利用できる
- デプロイ先と料金は次のとおり
- GPU にデプロイするアプリは、基本的に AMD EPYC CPU コア 8 基を使用する
- ボリュームは最大 500GB まで接続できる
- 予約インスタンスと専用ホスト向けの割引も提供される可能性がある
1件のコメント
Hacker News の意見
Fly が基本機能をきちんと備えているのか疑問。実際にプロダクションで使ってみると、サポートチームが内部プラットフォームの問題を確認できないレベルで、エラーメッセージは曖昧か、そもそも存在せず、がっかりした
Kubernetes が怖い、またはよく分からない人には魅力的に見えるかもしれないが、Fly を使っているうちに、むしろ Kubernetes が恋しくなった
watch -n 2 curlを回してみれば自分で確認できるし、ドキュメント化されている戦略は、ブルーグリーンを含め、どれを使っても同じだった最悪でも既存接続だけが早期終了し、新規接続は切れないことを期待していたし、理想は既存接続が終わるまで優雅に待つことだったが、実際には毎回完全なダウンタイムを伴う切り替えだった。ブログに出ていたネットワークトポロジを考えると、そもそも正しく実装できなかったのではないかという気がする
サービスに否定的なコメントを書くことはめったにないが、動画の証拠まで送ったのに、サポートチームがこちらがおかしいかのように対応したのは、インフラ企業としてはかなり気に障った。今ではおもちゃアプリ以外には勧めない
Kubernetes 向けにかなり大規模なデプロイシステムも作ったことがあるが、この問題は Kubernetes を知らないから言っているわけではない。きちんとしたHeroku 式デプロイへの余地は明らかにあるが、誰もうまくやっていないか、計算リソースがあり得ないほど薄いか高いかのどちらかだ
マネージド風に見せたアンマネージドDB、ランダムなダウンタイムなど、もっと言えることはあるが、プロダクション対応のサービスではなかったので数か月前に離れた
最初は Fly にとても期待していて、Fly Machines の上にオーケストレーター全体まで作ったが、数日規模の障害が起き、返答をもらうのにも数日かかった
Kubernetes は複雑かもしれないが、その複雑さは少なくとも制御可能で、すでに十分検証された道でもある
記事の筆者で、Fly.io の開発者リレーション担当者です。質問があれば答えられます。GPU は昨日正式リリースされ、詐欺防止アルゴリズムの神が許してくれるなら、自由に実験できます
むしろ「GPU」が実際に何なのかを書いた解説記事が、ここであまり受けなかったのが驚きです: https://fly.io/blog/what-are-these-gpus-really/
プロセスノード上の利点と SoC/HBM への優先的アクセスは、ソフトウェアが追いつくまで十分長く維持されるだろうか。高性能な Metal 機材は高そうに見えるが、64GB超クラスのかなり高いメモリ帯域幅と専用 FP ベクトルユニットを備えた NVIDIA と比べると、見え方が変わる
fly.ioのようなプラットフォームで推論ワークロードをデバイス内外に移せるなら、エッジ比重の大きいアプリケーションに多くの自由度を与えられそうだ医療画像セグメンテーションのワークフローでは、1ファイルあたり約5分かかる
知る限り、Fly は VM に Firecracker を使っている。Firecracker はしばらく追っていたし、プロジェクトでも使ってみたが、基本的に GPU をサポートしておらず、サポート計画もない [1]
Fly が Firecracker で独自の GPU サポートをどう解決したのか気になる。以前は特定機能をどう実装したかについて非常に詳しい技術記事を出していたので、GPU サポートについても後で記事が出るといいと思う
[1]: https://github.com/firecracker-microvm/firecracker/issues/11...
0 までスケールダウンできる点が素晴らしい。ユーザー数が少なく、小さなサーバー費用ですら正当化しにくい実験的なサイト作業には特に有用だ
1リクエストがどの程度の時間として課金されるのか、例があるとありがたい。もちろん変動するだろうが、2秒なのか、それとも「スピンアップごとに最低60秒」なのかが気になる
GPU マシンは、GPU メモリに入るデータサイズによっては、有用になるまでに30秒程度の実行時間が必要になる場合がある
Fly.ioを初期に導入したが、本番環境向けの準備ができていない。新機能を追加する前に、まず基本機能を直すべき
設定は少し余計に必要で、価格もかなり高いが、本番環境では安定性が必要。サービス停止で顧客に電話させるわけにはいかない
ソフトウェアは壊れ得るものだが、Flyのインシデント対応の姿勢は非専門的で未熟。基本的に見た目だけは「良い」不安定なサービスに10倍多く払っているようなもの
今はHetzner + Kamalで、はるかに良いハードウェアを4分の1のコストで使っており、安定して動き、価格も予測可能で、同じ使用量なのに翌月25%多く払うこともない
https://news.ycombinator.com/item?id=36808296
GPU発表とは別に、FlyにS3代替サービスがあるといい。今はGNU Afferoのプロジェクトを提案しているが、企業にとっては障害になる
ユーザー資産の保存のためにFlyの外へ出なければならないなら、次のプロジェクトでFlyを使うのは難しい。シンプルさ、コスパ、内蔵VPNは気に入っているので残念
https://benhoyt.com/writings/flyio-and-tigris/ ここでも議論されている: https://news.ycombinator.com/item?id=39360870
https://fly.io/docs/reference/tigris/
S3のようなサービスにHTTPS APIだけでアクセスするなら、そのためにコードがAGPLの適用対象になることはない
このサービスのターゲット市場が誰なのか気になる。何らかのAIモデルを動かす必要はあるが、オープンソースモデルのホスティングを提供する無数の価格競争スタートアップを使わない、あるいは使えない小さく検証されていないアプリなのか？
自分でモデルとハードウェアを多く運用してみると、ベアメタルまで制御したい気持ちは理解できる。ただ、誰を狙っているのか知りたい
実際には推論自体に時間がかかるため、その差はそれほど重要ではないかもしれない
GPU計算が同じデータセンター、または少なくとも同じクラウドプロバイダー内にあることは大きな利点になり得る。複数のプロバイダーでA100が枯渇することも珍しくなく、大手プロバイダーでも何度も経験した。特定のリージョンに縛られていなければ問題は小さい
すべてのプロバイダーが使えるオンデマンドの0スケールダウンモデルを提供しているわけではない。Flyで長期的にどれほど上手くいくかは分からないが、これも利点になり得る
価格競争型のスタートアップは長く持たない傾向があり、100社のうちごく少数だけが生き残る構造に近い
すでにFlyを使っていて、非公開の技術デモを何度か評価してもらう程度なら、Fly GPUはあまり悩まずに選べるデフォルトの選択肢になり得る。もちろんHugging Faceのサービスを使うほうが一般的かもしれない
さまざまな理由で自社ハードウェアを運用できない会社も多く、せいぜい別のデータセンターでラックを借りる程度だが、小さなユースケースでは必ずしも価値があるとは限らない。A100が必要だが、週次分析のようにまれにしか回さない場合もあり、週1時間未満なら価格競争サービスはそれほど魅力的ではないかもしれない
レシピ例やどんなLLMユースケースであっても、エッジ推論を強調するには非常に悪い例に見える。往復遅延が数百ms増えても大して問題にならないから
ただし悪用の可能性が高い領域なので、まだ誰も関わりたがっていないようだ。おそらく次の記事で扱うと思うし、そうなら自前のPerplexity風オンラインGPTを作る必要がある。今は意図的に平凡な紹介にして、別のアイデアが出てくるか見ているのだと思う
性能を実際に試した人がいるのか気になる。第一印象ではかなり高く見える。たとえば Hetzner の CPU マシンと比べるとそう感じる
さらに H100 も1時間あたり2.24ドルで、この価格より安く利用できる
なのでやや高く見えるが、顧客需要が高く供給が不足しているからかもしれない
Fly.io の無料ティアで Uptime Kuma を動かして稼働時間監視をしている。ものすごくよく動いていて、とても満足している