はじめに
サーバレスといえば、多くの人がまず思い浮かべるのは AWS Lambda だと思います。
私自身、AWS認定ソリューションアーキテクト – プロフェッショナルを取得し、AWSのマネージドサービスの強さも理解しているつもりです。
AWSについては、未経験の状態からAWS認定資格に取り組み、Cloud Practitioner、Solutions Architect – Associate、Solutions Architect – Professionalまで学習した経験を以下の記事にまとめています。
また、Kubernetesやクラウドネイティブ技術については、CloudNative Days Summer 2025でも登壇しました。
そのうえで、最近改めて感じているのが、
AI時代のサーバレス基盤は、Lambdaだけで考えると少し狭いのではないか
ということです。
Lambdaは非常に完成度の高いサービスです。
イベントを受けて処理を実行し、使った分だけ課金され、インフラ運用の多くをAWSに任せることができます。
一方で、生成AI、LLM、画像処理、音声認識、Embedding生成のようなワークロードでは、従来のFaaSとは少し違う要件が出てきます。
- GPUを使いたい
- CUDA/cuDNN/TensorRTなどを使いたい
- 大きなモデルをロードしたい
- コンテナ単位で柔軟に実行したい
- 必要な時だけGPUノードを起動したい
- AWSだけでなくオンプレ/マルチクラウドでも同じ考え方を使いたい
- KubernetesネイティブにAI基盤を作りたい
そこで本記事では、AWS Lambda と Knative + Kubernetes を、料金モデル・運用責任・GPU利用・AI基盤適性の観点で比較します。
結論から言うと、
LambdaはCPU中心のイベント処理には非常に強い。
しかし、GPUを含むAIワークロードでは、Knative + Kubernetes + Karpenter のようなクラウドネイティブ基盤に可能性がある。
という話です。
LambdaとKnativeはそもそも何が違うのか
まず、LambdaとKnativeは似ているようで、立ち位置が違います。
| 観点 | AWS Lambda | Knative |
|---|---|---|
| 位置づけ | AWSのマネージドFaaS | Kubernetes上のサーバレス基盤 |
| 実行単位 | Function | Container / Function |
| 実行基盤 | AWS管理 | 自分たちのKubernetesクラスタ |
| スケール to zero | 対応 | 対応 |
| GPU利用 | 基本的に不可 | KubernetesのGPUリソースとして利用可能 |
| 課金 | リクエスト数 + GB秒 | クラスタ/ノード/周辺リソース課金 |
| 運用負荷 | 低い | 高い |
| 自由度 | 低め | 高い |
| Kubernetes連携 | 弱い | 強い |
| AI基盤適性 | 軽量CPU推論向き | GPU推論/独自モデル運用向き |
Lambdaは「完成されたサーバレスサービス」です。
Knativeは「Kubernetes上にサーバレス実行基盤を作るための仕組み」です。
つまり、かなり単純化すると以下のように整理できます。
Lambda = すぐ使える完成品
Knative = Kubernetes上に作るサーバレス基盤
この違いを理解したうえで比較しないと、単純に「Lambdaが上」「Knativeが上」という話になってしまいます。
Lambdaの強み
Lambdaの強みは、何と言っても 運用負荷の低さ です。
例えば、以下のような構成は非常に作りやすいです。
API Gateway → Lambda → DynamoDB
S3 Event → Lambda
EventBridge → Lambda
SQS → Lambda
自分でKubernetesクラスタ、Ingress、Pod、Autoscaler、Controllerを管理する必要がありません。
アプリケーション開発者は、基本的には「どのイベントを受けて、どの処理を実行するか」に集中できます。
これは非常に大きなメリットです。
また、AWSの各サービスとの統合も強力です。
- API Gateway
- S3
- SQS
- SNS
- EventBridge
- DynamoDB
- Step Functions
- CloudWatch Logs
- IAM
これらと自然に連携できるため、AWS上で完結するシステムであれば、Lambdaはかなり強い選択肢になります。
特に、CPU中心の軽量なイベント処理では、Lambdaは今でも非常に優秀です。
Lambdaの料金モデル
Lambdaの料金モデルは分かりやすく、主に以下で決まります。
- リクエスト数
- 実行時間
- 割り当てメモリ
- 必要に応じてProvisioned Concurrency
- 必要に応じて追加エフェメラルストレージ
基本的には、以下の考え方です。
Lambdaの料金 = リクエスト課金 + 実行時間課金
AWS公式のLambda料金では、リクエスト課金とGB秒単位の実行時間課金が設定されています。
Lambdaは無料枠も強力です。
100万リクエスト/月
400,000 GB秒/月
そのため、小さなAPIやイベント処理であれば、ほとんど費用がかからないケースもあります。
Lambdaの料金をざっくり計算する
ここでは単純化して、以下の前提で計算します。
月間リクエスト数: 1,000,000回
実行時間: 1秒/回
メモリ: 2GB
Lambda実行時間単価: 0.0000166667 USD / GB秒
リクエスト単価: 0.20 USD / 100万リクエスト
無料枠: 考慮しない
計算式は以下です。
GB秒 = リクエスト数 × 実行時間 × メモリGB
= 1,000,000 × 1秒 × 2GB
= 2,000,000 GB秒
実行時間料金 = 2,000,000 × 0.0000166667
= 約 33.33 USD
リクエスト料金 = 1 × 0.20
= 0.20 USD
合計 = 約 33.53 USD/月
無料枠を考慮しない場合でも、100万回実行して約33.53 USDです。
この金額だけ見ると、Lambdaはかなり安いです。
CPU中心の軽量処理であれば、非常にコストパフォーマンスが高いと言えます。
LambdaがAI基盤で苦しくなるところ
一方で、AI基盤として考えると、Lambdaには制約があります。
Lambdaは便利ですが、GPUを前提にした実行基盤ではありません。
AWS Lambdaのメモリは128MB〜10,240MBで設定でき、CPUはメモリ量に比例して割り当てられます。
AWS公式ドキュメントでは、1,769MBで約1vCPU相当とされています。
参考: Configure Lambda function memory
これは通常のイベント処理には十分ですが、以下のようなAIワークロードでは厳しくなります。
- GPUを使うLLM推論
- 画像生成
- 音声認識
- 大きなEmbeddingモデル
- CUDA/cuDNN/TensorRTなどに依存する処理
- 大きなモデルロードを伴う処理
- 長時間動かしたい推論API
例えば、軽量なテキスト整形や小さな推論処理であればLambdaでも十分なケースがあります。
しかし、GPUを使う大きめのAIワークロードを動かす基盤としては、Lambda単体では限界があります。
ここで候補になるのが、Knative + Kubernetes です。
Knativeとは何か
Knativeは、Kubernetes上でサーバレスなワークロードを実行するための仕組みです。
代表的には、以下のような機能を持っています。
- リクエスト駆動のスケーリング
- scale to zero
- Revision管理
- Traffic splitting
- Eventing
- KubernetesネイティブなAPI
- Knative Functions
LambdaがAWS上のマネージドFaaSであるのに対して、KnativeはKubernetes上にサーバレス実行基盤を構築するためのOSSです。
つまり、Knativeを使うことで、Kubernetes上に以下のような実行基盤を作ることができます。
リクエストが来た時だけPodを起動する
使われていない時はPod数を0にする
Revision単位でバージョン管理する
トラフィックを段階的に切り替える
イベント駆動で処理を起動する
この考え方は、Lambdaに近い部分があります。
ただし、KnativeはAWSのマネージドサービスではありません。
あくまで、自分たちのKubernetesクラスタ上に構築するサーバレス基盤です。
そのため、自由度は高い一方で、運用責任も大きくなります。
Knative Serviceのイメージ
Knativeでは、アプリケーションを Service として定義します。
例えば、以下のようなYAMLでKnative Serviceを作成できます。
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
name: hello
spec:
template:
spec:
containers:
- image: ghcr.io/example/hello:latest
ports:
- containerPort: 8080
このYAMLを適用すると、Knativeは裏側で以下のようなリソースを管理します。
Knative Service
↓
Configuration
↓
Revision
↓
Route
↓
Kubernetes Deployment / Pod
↓
Kubernetes Service
↓
Ingress / Gateway
利用者はシンプルにKnative Serviceを作成するだけです。
しかし、裏側ではRevision管理、Route管理、Podのスケーリングなどが行われます。
この抽象化がKnativeの面白いところです。
kn CLIを使うとさらに簡単になる
KnativeはYAMLで操作することもできますが、kn CLIを使うとより簡単に扱えます。
例えば、Knative Serviceの作成は以下のように実行できます。
kn service create hello \
--image ghcr.io/example/hello:latest \
--port 8080
Serviceの一覧確認もできます。
kn service list
Serviceの更新もできます。
kn service update hello \
--image ghcr.io/example/hello:v2
削除も簡単です。
kn service delete hello
このように、kn CLIを使うと、KubernetesやKnativeのYAMLを細かく書かなくても、サーバレスなアプリケーションを作成・更新・削除できます。
この点は、開発者体験としてLambdaに近い部分があります。
Knative Functionsを使うとLambdaにさらに近づく
Knativeには、Knative Functionsという仕組みもあります。
Knative Functionsを使うと、関数コードからコンテナイメージを作成し、Knative Serviceとしてデプロイできます。
例えば、Pythonの関数を作る場合は以下のような流れになります。
kn func create hello-func --runtime python
cd hello-func
kn func deploy
kn func invoke
開発者の体験としては、かなりFaaSに近くなります。
関数を書く
↓
ビルドする
↓
デプロイする
↓
URLで呼び出す
↓
必要な時だけスケールする
つまり、Knative Functionsを使えば、Kubernetes上にLambdaのような関数実行体験を作ることができます。
ただし、ここでも重要なのは、実行基盤はあくまでKubernetesであるという点です。
Lambda:
AWSが実行基盤を管理する
Knative Functions:
自分たちのKubernetesクラスタ上で関数を動かす
そのため、Lambdaのような使いやすさに近づけることはできますが、運用責任までLambdaと同じになるわけではありません。
KnativeがAI基盤として面白い理由
KnativeがAI基盤として面白いのは、KubernetesのGPUリソースと組み合わせられる点です。
Kubernetesでは、Podに対してGPUリソースを要求できます。
例えば、以下のように nvidia.com/gpu を指定できます。
resources:
limits:
nvidia.com/gpu: 1
Knative Serviceも最終的にはKubernetes上のPodとして動作します。
そのため、GPUを要求するKnative Serviceを作成し、GPUノード上で実行する構成が考えられます。
例えば、AI推論用のKnative Serviceは以下のようなイメージです。
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
name: ai-inference
spec:
template:
metadata:
annotations:
autoscaling.knative.dev/min-scale: "0"
autoscaling.knative.dev/max-scale: "5"
spec:
containers:
- image: ghcr.io/example/ai-inference:latest
resources:
limits:
nvidia.com/gpu: 1
この構成により、以下のような動きが期待できます。
リクエストが来る
↓
Knative Serviceがscale from zeroする
↓
GPUを要求するPodが作成される
↓
GPUノード上にスケジューリングされる
↓
AI推論を実行する
↓
一定時間リクエストがなければPod数が0になる
これは、AI推論基盤としてかなり面白い構成です。
ただし、KnativeだけではGPUノードの課金は止まらない
ここはかなり重要です。
KnativeはPodをscale to zeroできます。
しかし、Podが0になっても、GPUノードが起動したままであればEC2料金は発生します。
つまり、
KnativeでPodを0にする
だけでは不十分です。
GPUコストを本当に抑えたい場合は、
GPU Podが不要になったら、GPUノードも削除する
必要があります。
ここで登場するのが、KarpenterやCluster AutoscalerのようなNode Autoscalerです。
特にEKSでは、Karpenterを使うことで、ワークロードに応じて必要なEC2インスタンスを起動し、不要になったノードを削除する構成が取れます。
参考: Scale cluster compute with Karpenter and Cluster Autoscaler
つまり、AI基盤として本当に面白くなるのは、以下の構成です。
Knative + Kubernetes + Karpenter + GPU Node
この組み合わせにより、
使う時だけGPU Podを起動する
必要な時だけGPUノードを起動する
使わない時はPodもNodeも落とす
というクラウドネイティブなGPU利用が見えてきます。
Knative + Karpenter + GPUの動き
構成イメージは以下です。
HTTP Request / Event
↓
Knative Service が scale from zero
↓
GPU Pod が Pending
↓
Karpenter が GPU Node を起動
↓
GPU Node に Pod がスケジューリングされる
↓
モデルをロードする
↓
推論を実行する
↓
一定時間リクエストがなければ Pod が 0 になる
↓
不要になった GPU Node が削除される
この構成により、GPUを常時起動するのではなく、必要な時だけ利用する設計が可能になります。
AI基盤ではGPUコストが大きくなりやすいため、この考え方は非常に重要です。
特に、以下のような用途では相性が良いと思います。
- 社内向けAI推論基盤
- PoC環境
- バッチ型のAI処理
- 画像処理
- 音声処理
- Embedding生成
- 利用頻度に波がある推論API
- 開発者向けのGPU実行環境
常時高トラフィックな推論APIであれば、GPUノードを常時起動した方がよいケースもあります。
しかし、利用頻度に波があるワークロードでは、Knative + Karpenterの構成がかなり効いてきます。
「GPUを好きな時に好きなだけ使える」は正確か
Knative + Kubernetesを使うと、GPUワークロードをかなり柔軟に扱えます。
ただし、「GPUを好きな時に好きなだけ使える」と言い切るのは少し危険です。
実際には、以下のような制約があります。
- AWSアカウントのService Quotas
- GPUインスタンスの在庫
- リージョンごとのGPUインスタンス提供状況
- GPUノードの起動時間
- コンテナイメージのPull時間
- モデルロード時間
- 初回リクエストのCold Start
- GPUの共有方式
- コスト上限管理
- セキュリティ設計
- テナント分離
そのため、より正確には以下の表現が近いです。
Knative + Karpenterを使えば、GPUワークロードを必要な時だけ起動し、
不要な時はPod/Nodeを落とすクラウドネイティブなAI基盤を構成できる。
「好きなだけ使える」というより、
必要な時だけGPUを使う設計ができる という表現の方が正確です。
この正確さを押さえておくと、記事としても信頼性が上がると思います。
EKS + Knative + GPUの料金モデル
Knative自体には、LambdaのようなGB秒課金はありません。
EKS上にKnativeを構築する場合、料金は主に以下になります。
月額 = EKSクラスタ料金 + Worker Node料金 + LB/NAT/EBS/通信費など
EKSのクラスタ料金は、標準サポート中のKubernetesバージョンで1クラスタあたり0.10 USD/時です。
月730時間で計算すると、以下のようになります。
EKS管理プレーン = 0.10 USD × 730時間
= 73 USD/月
ここにGPUノード料金が乗ります。
GPUインスタンスの料金はリージョンや時期で変わるため、ここでは例として以下の仮定を置きます。
GPUノード単価: 0.80 USD/時
月間時間: 730時間
実際に設計や見積もりで使う場合は、AWS Pricing CalculatorやEC2料金表で最新価格を確認してください。
GPUノードを常時起動した場合
まず、GPUノードを1台ずっと起動している場合です。
EKS管理プレーン = 73 USD/月
GPUノード = 0.80 USD × 730時間
= 584 USD/月
合計 = 657 USD/月
GPUノードを常時起動すると、普通に高いです。
これはLambdaと比較すると高く見えます。
ただし、LambdaではGPUが使えないため、単純な優劣比較はできません。
GPUノードを月100時間だけ使う場合
次に、Knative + KarpenterでGPUノードを必要な時だけ起動し、月100時間だけ使うケースです。
EKS管理プレーン = 73 USD/月
GPUノード = 0.80 USD × 100時間
= 80 USD/月
合計 = 153 USD/月
このあたりから、AI推論基盤としてかなり現実的になってきます。
GPUを常時起動するのではなく、必要な時だけ起動することでコストを抑えられます。
GPUノードを月10時間だけ使う場合
PoCや社内検証のように、GPU利用が月10時間程度の場合です。
EKS管理プレーン = 73 USD/月
GPUノード = 0.80 USD × 10時間
= 8 USD/月
合計 = 81 USD/月
このケースでは、GPU利用分よりもEKS管理プレーン費用の方が支配的になります。
そのため、小規模な検証では以下も検討対象になります。
- 既存EKSクラスタにKnativeを載せる
- k3s/kindなどでローカル検証する
- マネージドKubernetes以外の選択肢を使う
- GPUノードは必要時のみ起動する
- Spot Instanceを活用する
LambdaとKnative + GPUの料金比較
ここまでの計算をまとめると、以下のようになります。
前提は以下です。
Lambda:
- 100万リクエスト/月
- 1秒/回
- 2GB
- 無料枠は考慮しない
EKS + Knative:
- EKS管理プレーン 0.10 USD/時
- GPUノード 0.80 USD/時と仮定
- 月730時間
| 構成 | 月額概算 | コメント |
|---|---|---|
| Lambda 2GB・1秒・100万回 | 約33.53 USD | CPU処理なら非常に安い |
| EKS + Knative + GPU月10時間 | 約81 USD | PoC/検証向き |
| EKS + Knative + GPU月100時間 | 約153 USD | AI推論基盤として現実的 |
| EKS + Knative + GPU常時起動 | 約657 USD | 常時GPUは高い |
| 大規模GPU常時利用 | 数千〜数万USD以上 | 学習/大規模推論向き |
この表だけ見るとLambdaが安く見えます。
しかし、重要なのはここです。
Lambdaは安いが、GPUが使えない。
Knative + GPUは高く見えるが、AIワークロードに必要な自由度がある。
つまり、比較すべき軸は単純な料金だけではありません。
AI基盤では何が重要になるのか
AI時代の基盤では、以下のような要件が重要になります。
- GPUを使えること
- モデルごとに実行環境を変えられること
- コンテナ単位で依存関係を管理できること
- 必要な時だけGPUを起動できること
- 推論APIとして公開できること
- イベント駆動で処理できること
- CI/CDと統合できること
- Kubernetesのエコシステムを使えること
- 監視・ログ・メトリクスを統一できること
- 将来的にオンプレ/マルチクラウドへ展開できること
この観点では、Knative + Kubernetesはかなり面白いです。
Lambdaのようなイベント駆動・scale to zeroの考え方を持ちながら、Kubernetesの柔軟性も活かせます。
Knative + GPU基盤のアーキテクチャ例
構成イメージは以下です。
User / App
↓
API Gateway / Ingress / Gateway API
↓
Knative Service
↓
Revision
↓
Pod
↓
GPU Node
↓
Model Runtime
周辺コンポーネントとしては、以下が考えられます。
Kubernetes
Knative Serving
Knative Eventing
Karpenter
NVIDIA Device Plugin / GPU Operator
Container Registry
Prometheus / Grafana
Loki / OpenSearch
Istio / Kourier / Gateway API
Argo CD / Tekton / GitHub Actions
例えば、AI推論APIをKnative Serviceとして公開します。
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
name: ai-inference
spec:
template:
metadata:
annotations:
autoscaling.knative.dev/min-scale: "0"
autoscaling.knative.dev/max-scale: "5"
spec:
containers:
- image: ghcr.io/example/ai-inference:latest
resources:
limits:
nvidia.com/gpu: 1
このServiceにリクエストが来た時だけPodを起動し、GPUノードがなければKarpenterがノードを起動する、という構成が考えられます。
Knative API開発という観点
個人的に面白いと思っているのは、Knativeを単に使うだけではなく、Knativeを利用者向けのAPIとして抽象化することです。
例えば、利用者には以下のようなAPIを提供します。
POST /v1/functions
GET /v1/functions
GET /v1/functions/{id}
PATCH /v1/functions/{id}
DELETE /v1/functions/{id}
POST /v1/functions/{id}/invoke
POST /v1/functions/{id}/traffic
リクエスト例は以下です。
{
"name": "image-classifier",
"image": "ghcr.io/example/image-classifier:latest",
"gpu": {
"enabled": true,
"count": 1
},
"scale": {
"min": 0,
"max": 5
},
"env": {
"MODEL_NAME": "resnet50"
}
}
このAPIの裏側でKnative Serviceを作成します。
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
name: image-classifier
spec:
template:
metadata:
annotations:
autoscaling.knative.dev/min-scale: "0"
autoscaling.knative.dev/max-scale: "5"
spec:
containers:
- image: ghcr.io/example/image-classifier:latest
env:
- name: MODEL_NAME
value: resnet50
resources:
limits:
nvidia.com/gpu: 1
この考え方は、クラウドネイティブ基盤をサービス化するうえでかなり重要だと思います。
ユーザーにKubernetesやKnativeの詳細を意識させず、APIとして簡単に使えるようにする。
しかし裏側ではKubernetes/Knativeの柔軟性を活かす。
これは、今後のAI基盤においてかなり面白いテーマです。
ただし銀の弾丸ではない
Knative + GPU基盤は面白いですが、当然ながら課題もあります。
Cold Startが重い
Knativeのscale to zeroは便利ですが、AI推論ではCold Startが問題になります。
特にGPUワークロードでは、以下の時間がかかります。
- GPUノード起動
- コンテナイメージPull
- NVIDIA Device Pluginの認識
- Podスケジューリング
- モデルロード
- 初回推論のウォームアップ
そのため、リアルタイム性が求められるAPIでは、完全なscale to zeroが向かない場合もあります。
モデルロード時間が大きい
LLMや画像生成モデルでは、モデルロードに数十秒〜数分かかることがあります。
その場合、以下のような工夫が必要です。
- min-scaleを1にする
- モデルを軽量化する
- モデルを事前にノードへ配置する
- EBS/FSx/S3キャッシュを工夫する
- Warm Poolを用意する
- 低レイテンシが必要なモデルは常時起動する
GPU共有が難しい
GPUはCPUやメモリのように細かく共有しづらいリソースです。
最近はGPU分割やMIG、fractional GPUのような選択肢もありますが、設計は簡単ではありません。
考えるべきことは多いです。
- 1 Pod 1 GPUにするのか
- 複数PodでGPUを共有するのか
- モデルごとにGPUを分けるのか
- テナントごとにQuotaを設けるのか
- Spotを使うのか
- 中断時のリトライをどうするのか
運用責任が重い
LambdaであればAWSに任せられる部分も、Knativeでは自分たちで見る必要があります。
- クラスタの安定性
- ノードの起動失敗
- GPUドライバ
- Knativeのバージョンアップ
- Karpenterの設定
- Ingress/Gateway
- 認証認可
- 監視
- ログ
- セキュリティ
- コスト管理
この運用を持てない場合、Knativeは重く感じると思います。
LambdaとKnativeの使い分け
個人的には、以下の使い分けがよいと思います。
Lambdaが向いているケース
- CPU中心の軽量処理
- イベント駆動の小さな処理
- S3/SQS/EventBridge/API Gateway連携
- 運用負荷を極力下げたい
- AWS内で完結する
- GPUが不要
- 実行時間が短い
- マネージドサービス中心で作りたい
Knativeが向いているケース
- Kubernetes上でサーバレス基盤を作りたい
- GPUを使いたい
- コンテナ単位で自由に実行環境を作りたい
- 独自モデルを動かしたい
- オンプレ/マルチクラウドも視野に入れたい
- AI推論基盤を社内サービスとして提供したい
- 利用者向けAPI/CLIを自作したい
- Kubernetesエコシステムと統合したい
つまり、以下のような使い分けです。
Lambda:
AWSマネージドで楽にサーバレスを使う
Knative:
Kubernetes上に自分たちのサーバレス/AI実行基盤を作る
AWSのプロフェッショナル資格を取ったうえで思うこと
AWS認定ソリューションアーキテクト – プロフェッショナルを取ると、AWSのマネージドサービスの完成度の高さをかなり実感します。
Lambda、API Gateway、DynamoDB、SQS、EventBridge、Step Functionsなどを組み合わせると、多くの業務システムはかなり綺麗に作れます。
そのため、単純に「Knativeの方が上」と言いたいわけではありません。
むしろ、通常のサーバレスアプリケーションであればLambdaは非常に強いです。
運用負荷、可用性、セキュリティ、周辺サービスとの統合を考えると、Lambdaを選ぶのはかなり合理的です。
ただし、AI時代のワークロードでは、GPU、モデル管理、独自ランタイム、コンテナ実行、Kubernetes連携が重要になります。
この領域では、Lambdaだけでなく、Knative + Kubernetesのような選択肢も真剣に考える価値があると思っています。
まとめ
Lambdaは、今でも非常に強いサーバレス基盤です。
特に、CPU中心のイベント処理やAWS内で完結するアプリケーションでは、運用負荷・料金・信頼性のバランスが非常に優れています。
一方で、AI時代のワークロードでは、以下のような要件が増えてきます。
- GPUを使いたい
- 大きなモデルを動かしたい
- 独自ランタイムを使いたい
- コンテナ単位で柔軟に実行したい
- 必要な時だけGPUノードを起動したい
- Kubernetesネイティブに運用したい
- 将来的にオンプレ/マルチクラウドにも広げたい
このような背景を考えると、Knative + Kubernetes + Karpenter + GPU Node は、AI基盤としてかなり面白い選択肢です。
重要なのは、Lambdaを否定することではありません。
Lambdaは完成されたマネージドサーバレス。
KnativeはクラウドネイティブなAI実行基盤を作るための選択肢。
この違いを理解したうえで、ワークロードに応じて選ぶのがよいと思います。
これからのAI基盤では、単に「関数を実行する」だけではなく、GPUを含む計算資源を、必要な時だけ、コンテナ単位で、クラウドネイティブに扱うことが重要になっていくはずです。
その意味で、Knativeは今後かなり面白い技術だと感じています。