本文へスキップ

AI運用の判断と根拠を引く

トップへ戻る

サーバーレスAIアーキテクチャ

用語・参照用語・参照公式仕様のみ公式仕様のみ鮮度未確認鮮度を確定できない

記事状態: 公開 · 最終確認: 未確認

要点

「Serverless AIは、小規模・断続的・event-drivenなAI処理で常時稼働基盤を減らせる有力な実装形である。ただし実行時間、再試行、重複配送、利用枠、GPU/region、cold pathは提供元ごとに異なる。外部外部への変更・送信を伴う処理ではdurable 状態と重複実行を防ぐ性質を設計契約に含める。」

現在の判断

  • Serverless AIの適切なCoreは「LLMをfunction内へ必ず載せる」ではない。小さなorchestrator/functionがイベントを受け、durable queue/状態へ記録し、managed モデル APIまたは別推論 serviceを呼び、結果をdurable storeへcommitする形が最もportableである。
  • 実行 処理待ち時間の上限は提供元/契約プラン/実行環境で異なる。AWS Lambda標準functionは最大15分、Azure Functionsはhosting 契約プランで大きく異なりHTTP応答には別の230秒境界、Cloud 実行 Jobsは通常task最大7日だがGPU taskは1時間である。よって「serverlessだから短時間」も「container serverlessなら無制限」も一般化不可。
  • キューとイベントの統合は、重複が発生することを前提とする。AWS Lambda + SQS は「少なくとも1回の実行(at-least-once)」により重複処理が発生することを明記しているため、AI呼び出し、課金、メール送信、データベースの更新などの副作用に対しては、べき等性キー、重複排除レコード、アウトボックス/トランザクション境界が必要である。
  • GPU serverlessは実在するが利用条件の確認が強い。Cloud 実行 GPUはscale-to-zero可能で、L4/RTX PRO 6000 Blackwellをmanagedで提供する一方、GPU type、region、CPU/RAM minimum、one-GPU-per-instance等の制約がある。GPU 利用可能性をCPU serverlessと同等に扱わない。
  • コールドスタートだけでなく、モデルの初期化、重みのダウンロード、トークナイザー/ランタイムの初期化、ネットワークパス、アップストリームモデルのレート制限を個別に測定する必要があります。プラットフォームのインスタンス起動値を、エンドツーエンドのTTFT(最初のトークンまでの時間)保証へ外挿しないでください。

どこまで当てはまるか

エンタープライズAIコア / インフラストラクチャ / 実装 / 相互運用性 / ガバナンス / コスト / 運用性 / プロバイダー・マッピング

詳しく理解する

なぜ重要か

小規模なAI業務では、常時稼働するクラスターを持たず、イベント駆動型の関数、キュー、管理されたコンテナ、およびスケール・トゥ・ゼロの推論を組み合わせることで、運用負荷とアイドルコストを下げられます。一方で「サーバーレス」は、無制限、状態保持、正確に一度だけの実行(exactly-once)、GPUの常時即応を意味するものではありません。AI APIのレイテンシ、コールドスタート、モデルのロード、リトライ、重複配信、実行タイムアウト、GPUのリージョン/形状の可用性を設計契約に明示しないと、安価なPoCから本番環境へ移行する際に、失敗の範囲(失敗 envelope)が急激に拡大します。

対象範囲と前提

エンタープライズAIコア / インフラストラクチャ / 実装 / 相互運用性 / ガバナンス / コスト / 運用性 / プロバイダー・マッピング

検討ポイント

Serverless AIは、AI モデルそのものではなく「短命compute + durable queue/状態 + idempotent handler + 外部/managed モデル endpoint」を基本形にするとboundedに成立するか。GPU serverless/container serverlessを含め、どの制約を利用条件の確認として分離すべきか。

根拠資料の対応表

  • official spec/docs | AWS Lambda — Configure Lambda function 処理待ち時間の上限 | Amazon Web Services | https://docs.aws.amazon.com/lambda/latest/dg/configuration-timeout.html | 参照日 2026-09-16 | 現在の docs | 資料内の該当箇所: 処理待ち時間の上限 default 3s; standard function max 900s/15min; Managed Instances async/event-source mappingの一部は5400s/90min | VERIFIED_SPEC / PRODUCT_VOLATILE | 裏付け + limit
  • official spec/docs | Using Lambda with Amazon SQS | Amazon Web Services | https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html | 参照日 2026-09-16 | 現在の docs | 資料内の該当箇所: イベント 出典 mapping is at-least-once; duplicate processing can occur; idempotent function recommended | VERIFIED_SPEC | 裏付け + counter
  • official spec/docs | Cloud 実行 GPU 裏付け for services | Google Cloud | https://docs.cloud.google.com/run/docs/configuring/services/gpu | 参照日 2026-09-16 | 現在の docs | 資料内の該当箇所: RTX PRO 6000 Blackwell 96GB / L4 24GB; one GPU per instance; scale-to-zero; on-demand; GPU-equipped instance startup approx. 5s; supported regions enumerated | VERIFIED_SPEC / PRODUCT_VOLATILE | 裏付け + 利用可能性 limit
  • official spec/docs | Create jobs — Cloud 実行 | Google Cloud | https://cloud.google.com/run/docs/create-jobs | 参照日 2026-09-16 | 現在の docs | 資料内の該当箇所: task 処理待ち時間の上限 default 10min, configurable to 168h; GPU task max 1h; 再試行 configurable | VERIFIED_SPEC / PRODUCT_VOLATILE | 裏付け + limit
  • official spec/docs | Azure Functions Scale and Hosting | Microsoft | https://learn.microsoft.com/azure/azure-functions/functions-scale | 参照日 2026-09-16 | 現在の docs | 資料内の該当箇所: Flex/Premium/Dedicated/Container Apps 処理待ち時間の上限 differs; Consumption default 5min/max10min; HTTP-triggered response max 230s due load balancer; async pattern recommended for longer work | VERIFIED_SPEC / PRODUCT_VOLATILE | 文脈・入力情報 + limit

利用できる条件

提供元 / region / hosting 契約プラン / 実行環境 generation / trigger type / 処理待ち時間の上限 / 同時実行数 利用枠 / queue semantics / GPU type and inventory / CPU-memory minimum / VPC-network path / モデル endpoint region / 秘密情報 manager and IAM / payload size / retry-DLQ policy / pricing 改訂版。

実装・運用

VERIFIED_SPEC: Lambda+SQS、Cloud 実行のサービス/ジョブ/GPU、Azure Functionsで実装可能な構成要素を確認。提案: 将来的にCoreに SERVERLESS_AI_EXECUTION_CONTRACT を配置する。フィールド: event_id/idempotency_key(同じ要求の再送で処理を重複させない仕組み)、trigger/出典、queue/topic、payload hash/データ形式の定義、function/container image digest、実行環境 改訂版(改訂版)、処理待ち時間の上限、再試行/backoff、DLQ、モデル endpoint/モデル ID、request hash、response 成果物(成果物)、durable 途中状態の保存地点、side-effect commit key、region、同時実行数、cold/warm marker、latency breakdown、cost attribution、監査 trace(監査トレース)。

確認・評価方法

TEST_PROFILE(未実施): warm/cold、single/burst、duplicate イベント、upstream 429/5xx、処理待ち時間の上限直前response、poison message、partial batch 失敗、DLQ replay、モデル endpoint latency spike、GPU scale-from-zeroを固定fixture化。p50/p95/p99 end-to-end latency、cold-start contribution、duplicate side-effect rate、再試行 amplification、DLQ rate、成功 after 再試行、cost/request、idle cost、model-ready time、監査 completenessを分離計測する。

セキュリティとプライバシー

Security: least-privilege service 主体の識別、秘密情報 manager、非公開 egress/VPC要否、webhook/イベント authenticity、payload classificationを別管理。Privacy: queue/log/DLQにpromptやPIIが残る可能性を保持期間・保持方針対象化。監査: イベント→invocation→モデル request→外部への変更・送信をtrace/重複実行を防ぐ性質 keyで結ぶ。Cost: function/container computeだけでなくqueue、egress、モデル tokens、GPU startup/idle、再試行 amplificationを含める。Operability: DLQ replay、以前の状態へ戻す操作、利用枠 exhaustion、region failoverをrunbook化。

確認できていること

  • Serverless AIの適切なCoreは「LLMをfunction内へ必ず載せる」ではない。小さなorchestrator/functionがイベントを受け、durable queue/状態へ記録し、managed モデル APIまたは別推論 serviceを呼び、結果をdurable storeへcommitする形が最もportableである。

  • 実行 処理待ち時間の上限は提供元/契約プラン/実行環境で異なる。AWS Lambda標準functionは最大15分、Azure Functionsはhosting 契約プランで大きく異なりHTTP応答には別の230秒境界、Cloud 実行 Jobsは通常task最大7日だがGPU taskは1時間である。よって「serverlessだから短時間」も「container serverlessなら無制限」も一般化不可。

  • キューとイベントの統合は、重複が発生することを前提とする。AWS Lambda + SQS は「少なくとも1回の実行(at-least-once)」により重複処理が発生することを明記しているため、AI呼び出し、課金、メール送信、データベースの更新などの副作用に対しては、べき等性キー、重複排除レコード、アウトボックス/トランザクション境界が必要である。

  • GPU serverlessは実在するが利用条件の確認が強い。Cloud 実行 GPUはscale-to-zero可能で、L4/RTX PRO 6000 Blackwellをmanagedで提供する一方、GPU type、region、CPU/RAM minimum、one-GPU-per-instance等の制約がある。GPU 利用可能性をCPU serverlessと同等に扱わない。

  • コールドスタートだけでなく、モデルの初期化、重みのダウンロード、トークナイザー/ランタイムの初期化、ネットワークパス、アップストリームモデルのレート制限を個別に測定する必要があります。プラットフォームのインスタンス起動値を、エンドツーエンドのTTFT(最初のトークンまでの時間)保証へ外挿しないでください。

よくある失敗・反証

  • 関数のタイムアウト前にアップストリームモデルの呼び出しが長引いた場合、作業の一部が未完了のまま残ったり、重複した再試行が発生したりする可能性があります。

  • queue redeliveryは障害ではなくdelivery semanticsの一部。handler非idempotentなら二重課金・二重通知・二重mutationになり得る。

  • scale-to-zeroはidle costを下げる一方、cold path latencyを増やし得る。

  • GPUの起動が約5秒であるというCloud 実行の値は、コンテナ内のモデルの準備完了状態、重みのロード、または最初のトークン生成までの時間(TTFT)を保証するものではない。

  • serverless 提供元の利用枠、同時実行数、region、GPU inventory、network egress、秘密情報/IAM設定は組織の利用環境ごとに異なる。

  • long-running agentを単一request/function invocationへ閉じ込めると処理待ち時間の上限・再試行・途中状態の保存地点 lossが増える。durable 処理の流れ/状態 machineへ分解すべきケースがある。

実務での使い方

  • 提供元 / region / hosting 契約プラン / 実行環境 generation / trigger type / 処理待ち時間の上限 / 同時実行数 利用枠 / queue semantics / GPU type and inventory / CPU-memory minimum / VPC-network path / モデル endpoint region / 秘密情報 manager and IAM / payload size / retry-DLQ policy / pricing 改訂版。

  • VERIFIED_SPEC: Lambda+SQS、Cloud 実行のサービス/ジョブ/GPU、Azure Functionsで実装可能な構成要素を確認。提案: 将来的にCoreに SERVERLESS_AI_EXECUTION_CONTRACT を配置する。フィールド: event_id/idempotency_key(同じ要求の再送で処理を重複させない仕組み)、trigger/出典、queue/topic、payload hash/データ形式の定義、function/container image digest、実行環境 改訂版(改訂版)、処理待ち時間の上限、再試行/backoff、DLQ、モデル endpoint/モデル ID、request hash、response 成果物(成果物)、durable 途中状態の保存地点、side-effect commit key、region、同時実行数、cold/warm marker、latency breakdown、cost attribution、監査 trace(監査トレース)。

  • TEST_PROFILE(未実施): warm/cold、single/burst、duplicate イベント、upstream 429/5xx、処理待ち時間の上限直前response、poison message、partial batch 失敗、DLQ replay、モデル endpoint latency spike、GPU scale-from-zeroを固定fixture化。p50/p95/p99 end-to-end latency、cold-start contribution、duplicate side-effect rate、再試行 amplification、DLQ rate、成功 after 再試行、cost/request、idle cost、model-ready time、監査 completenessを分離計測する。

  • Security: least-privilege service 主体の識別、秘密情報 manager、非公開 egress/VPC要否、webhook/イベント authenticity、payload classificationを別管理。Privacy: queue/log/DLQにpromptやPIIが残る可能性を保持期間・保持方針対象化。監査: イベント→invocation→モデル request→外部への変更・送信をtrace/重複実行を防ぐ性質 keyで結ぶ。Cost: function/container computeだけでなくqueue、egress、モデル tokens、GPU startup/idle、再試行 amplificationを含める。Operability: DLQ replay、以前の状態へ戻す操作、利用枠 exhaustion、region failoverをrunbook化。

  • 製品への対応付け時にAWS Lambda/SQS、Google Cloud 実行/Tasks/Pub/Sub、Azure Functions/Service Bus等を同一比較軸へmapする。

  • pricing・利用枠・GPU region/typeは公開後更新時に再pinする。

  • EA-085 Event-driven AIのEVENT_TO_ACTION_CONTRACTと重複統合せず、EA-086は実行 substrate/cost/処理待ち時間の上限/cold pathを担当する。

  • 長時間実行されるエージェントや一連の処理(処理の流れ)については、Durable Functions、Step Functions、Workflowsなどの、永続的なオーケストレーションについて別のサブセクションで追加調査を行う。

まだ確認できていないこと

  • EA-086-UNKNOWN-01

    2026-09-16時点の各提供元 exact price/同時実行数 利用枠、Cloud 実行 GPUの全region inventory、Azure Flex Consumptionの組織の利用環境別利用可能性、AWS Lambda Managed Instancesの全適用条件。STOP_CONDITION: 実行 semantics、duplicate/再試行 適用限界、GPU serverless 利用条件の確認、safe architecture 条件・契約が一次資料で確立したためEA-086の初回bounded packetは完了。価格/region/利用枠は公開後Workで再確認する。

    ---

    ---

  • EA-086-UNKNOWN-CURRENTNESS

    外部根拠の再確認日が正式な本文・公開管理情報で確定していないため、現行性は未確認のまま保持する。確認日を推測して補わない。

根拠資料

出典ID・検証情報・機械可読データ

根拠の種類と情報の鮮度は、ラベルとアイコンで確認できます。

記事ID
EA-086
最終確認日
—
提供元・モデル・プラン・利用環境
—
対象地域
—
元資料の全文と収録照合記録
WHY_THIS_MATTERS_TO_UPDATE

小規模AI業務では常時稼働clusterを持たず、event-triggered function、queue、managed container、scale-to-zero inferenceを組み合わせることで運用負荷とidle costを下げられる。一方「serverless」は無制限・状態保持・exactly-once・GPU常時即応を意味しない。AI API latency、cold start、model load、retry、duplicate delivery、execution timeout、GPU region/shape availabilityを設計契約へ明示しないと、安価なPoCから本番へ移る際にfailure envelopeが急拡大する。

SCOPE_ROUTING

Enterprise AI Core / infrastructure / implementation / interoperability / governance / cost / operability / provider mapping

CLAIM_OR_RESEARCH_QUESTION

Serverless AIは、AI modelそのものではなく「短命compute + durable queue/state + idempotent handler + external/managed model endpoint」を基本形にするとboundedに成立するか。GPU serverless/container serverlessを含め、どの制約をavailability gateとして分離すべきか。

EVIDENCE TABLE
  • official spec/docs | AWS Lambda — Configure Lambda function timeout | Amazon Web Services | https://docs.aws.amazon.com/lambda/latest/dg/configuration-timeout.html | accessed 2026-09-16 | current docs | locator: timeout default 3s; standard function max 900s/15min; Managed Instances async/event-source mappingの一部は5400s/90min | VERIFIED_SPEC / PRODUCT_VOLATILE | support + limit
  • official spec/docs | Using Lambda with Amazon SQS | Amazon Web Services | https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html | accessed 2026-09-16 | current docs | locator: event source mapping is at-least-once; duplicate processing can occur; idempotent function recommended | VERIFIED_SPEC | support + counter
  • official spec/docs | Cloud Run GPU support for services | Google Cloud | https://docs.cloud.google.com/run/docs/configuring/services/gpu | accessed 2026-09-16 | current docs | locator: RTX PRO 6000 Blackwell 96GB / L4 24GB; one GPU per instance; scale-to-zero; on-demand; GPU-equipped instance startup approx. 5s; supported regions enumerated | VERIFIED_SPEC / PRODUCT_VOLATILE | support + availability limit
  • official spec/docs | Create jobs — Cloud Run | Google Cloud | https://cloud.google.com/run/docs/create-jobs | accessed 2026-09-16 | current docs | locator: task timeout default 10min, configurable to 168h; GPU task max 1h; retry configurable | VERIFIED_SPEC / PRODUCT_VOLATILE | support + limit
  • official spec/docs | Azure Functions Scale and Hosting | Microsoft | https://learn.microsoft.com/azure/azure-functions/functions-scale | accessed 2026-09-16 | current docs | locator: Flex/Premium/Dedicated/Container Apps timeout differs; Consumption default 5min/max10min; HTTP-triggered response max 230s due load balancer; async pattern recommended for longer work | VERIFIED_SPEC / PRODUCT_VOLATILE | context + limit
FINDINGS
  • Serverless AIの適切なCoreは「LLMをfunction内へ必ず載せる」ではない。小さなorchestrator/functionがeventを受け、durable queue/stateへ記録し、managed model APIまたは別inference serviceを呼び、結果をdurable storeへcommitする形が最もportableである。
  • execution timeoutはprovider/plan/runtimeで異なる。AWS Lambda標準functionは最大15分、Azure Functionsはhosting planで大きく異なりHTTP応答には別の230秒境界、Cloud Run Jobsは通常task最大7日だがGPU taskは1時間である。よって「serverlessだから短時間」も「container serverlessなら無制限」も一般化不可。
  • queue/event integrationはduplicateを前提にする。AWS Lambda+SQSはat-least-onceでduplicate processingを明記しているため、AI call・billing・email送信・DB mutation等のside effectはidempotency key、deduplication record、outbox/transaction boundaryが必要。
  • GPU serverlessは実在するがavailability gateが強い。Cloud Run GPUはscale-to-zero可能で、L4/RTX PRO 6000 Blackwellをmanagedで提供する一方、GPU type、region、CPU/RAM minimum、one-GPU-per-instance等の制約がある。GPU availabilityをCPU serverlessと同等に扱わない。
  • cold startだけでなくmodel initialization、weight download、tokenizer/runtime initialization、network path、upstream model rate limitを別々に測る必要がある。platform instance startup値をend-to-end TTFT保証へ外挿しない。
LIMITS / COUNTEREVIDENCE / FAILURE ENVELOPE
  • function timeout前にupstream model callが長引けばpartial work/duplicate retryが起こり得る。
  • queue redeliveryは障害ではなくdelivery semanticsの一部。handler非idempotentなら二重課金・二重通知・二重mutationになり得る。
  • scale-to-zeroはidle costを下げる一方、cold path latencyを増やし得る。
  • GPU startup約5秒というCloud Run値はcontainer内model readiness/weight load/TTFTを保証しない。
  • serverless providerのquota、concurrency、region、GPU inventory、network egress、secret/IAM設定はtenantごとに異なる。
  • long-running agentを単一request/function invocationへ閉じ込めるとtimeout・retry・checkpoint lossが増える。durable workflow/state machineへ分解すべきケースがある。
AVAILABILITY_GATES

provider / region / hosting plan / runtime generation / trigger type / timeout / concurrency quota / queue semantics / GPU type and inventory / CPU-memory minimum / VPC-network path / model endpoint region / secret manager and IAM / payload size / retry-DLQ policy / pricing revision。

IMPLEMENTATION_STATE

VERIFIED_SPEC: Lambda+SQS、Cloud Run services/jobs/GPU、Azure Functionsで実装可能な構成要素を確認。PROPOSAL: 将来Coreに SERVERLESS_AI_EXECUTION_CONTRACT を置く。fields: event_id/idempotency_key, trigger/source, queue/topic, payload hash/schema, function/container image digest, runtime revision, timeout, retry/backoff, DLQ, model endpoint/model ID, request hash, response artifact, durable checkpoint, side-effect commit key, region, concurrency, cold/warm marker, latency breakdown, cost attribution, audit trace。

BENCHMARK_OR_EVAL

TEST_PROFILE(未実施): warm/cold、single/burst、duplicate event、upstream 429/5xx、timeout直前response、poison message、partial batch failure、DLQ replay、model endpoint latency spike、GPU scale-from-zeroを固定fixture化。p50/p95/p99 end-to-end latency、cold-start contribution、duplicate side-effect rate、retry amplification、DLQ rate、success after retry、cost/request、idle cost、model-ready time、audit completenessを分離計測する。

SECURITY / PRIVACY / AUDIT / COST / OPERABILITY

Security: least-privilege service identity、secret manager、private egress/VPC要否、webhook/event authenticity、payload classificationを別管理。Privacy: queue/log/DLQにpromptやPIIが残る可能性をretention対象化。Audit: event→invocation→model request→side effectをtrace/idempotency keyで結ぶ。Cost: function/container computeだけでなくqueue、egress、model tokens、GPU startup/idle、retry amplificationを含める。Operability: DLQ replay、rollback、quota exhaustion、region failoverをrunbook化。

SAFE_WORDING_FOR_FUTURE_BOOK

「Serverless AIは、小規模・断続的・event-drivenなAI処理で常時稼働基盤を減らせる有力な実装形である。ただし実行時間、再試行、重複配送、quota、GPU/region、cold pathはproviderごとに異なる。外部side effectを伴う処理ではdurable stateとidempotencyを設計契約に含める。」

UPDATE_WORK_HANDOFF
  • provider mapping時にAWS Lambda/SQS、Google Cloud Run/Tasks/Pub/Sub、Azure Functions/Service Bus等を同一比較軸へmapする。
  • pricing・quota・GPU region/typeは公開後更新時に再pinする。
  • EA-085 Event-driven AIのEVENT_TO_ACTION_CONTRACTと重複統合せず、EA-086はexecution substrate/cost/timeout/cold pathを担当する。
  • long-running agent/workflowはDurable Functions/Step Functions/Workflows等のdurable orchestrationを別subsectionで追加採集する。
OPEN_UNKNOWN

2026-09-16時点の各provider exact price/concurrency quota、Cloud Run GPUの全region inventory、Azure Flex Consumptionのtenant別availability、AWS Lambda Managed Instancesの全適用条件。STOP_CONDITION: execution semantics、duplicate/retry boundary、GPU serverless availability gate、safe architecture contractが一次資料で確立したためEA-086の初回bounded packetは完了。価格/region/quotaは公開後Workで再確認する。

---

---

  • EVD-EA-086-URL-44B5D8B4F201研究資料研究資料根拠の出所: SOURCE_PACKET_REFERENCE

    1. official spec/docs | AWS Lambda — Configure Lambda function timeout | Amazon Web Services |

    裏付ける内容
    —
    確認日
    —
    出典・実験ID
    SRC-EA-086-URL-44B5D8B4F201
    検証箇所
    EVIDENCE TABLE · 1. official spec/docs | AWS Lambda — Configure Lambda function timeout | Amazon Web Services | https://docs.aws.amazon.com/lambda/latest/dg/configuration-timeout.html
    適用範囲
    EVIDENCE TABLE
    出典・来歴
    SOURCE_PACKET_REFERENCE_PROJECTED
    限界
    元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。
  • EVD-EA-086-URL-C784C5865F16研究資料研究資料根拠の出所: SOURCE_PACKET_REFERENCE

    2. official spec/docs | Using Lambda with Amazon SQS | Amazon Web Services |

    裏付ける内容
    —
    確認日
    —
    出典・実験ID
    SRC-EA-086-URL-C784C5865F16
    検証箇所
    EVIDENCE TABLE · 2. official spec/docs | Using Lambda with Amazon SQS | Amazon Web Services | https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html
    適用範囲
    EVIDENCE TABLE
    出典・来歴
    SOURCE_PACKET_REFERENCE_PROJECTED
    限界
    元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。
  • EVD-EA-086-URL-8CCB457B5EA0研究資料研究資料根拠の出所: SOURCE_PACKET_REFERENCE

    3. official spec/docs | Cloud Run GPU support for services | Google Cloud |

    裏付ける内容
    —
    確認日
    —
    出典・実験ID
    SRC-EA-086-URL-8CCB457B5EA0
    検証箇所
    EVIDENCE TABLE · 3. official spec/docs | Cloud Run GPU support for services | Google Cloud | https://docs.cloud.google.com/run/docs/configuring/services/gpu
    適用範囲
    EVIDENCE TABLE
    出典・来歴
    SOURCE_PACKET_REFERENCE_PROJECTED
    限界
    元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。
  • EVD-EA-086-URL-16F9BE23F7EC研究資料研究資料根拠の出所: SOURCE_PACKET_REFERENCE

    4. official spec/docs | Create jobs — Cloud Run | Google Cloud |

    裏付ける内容
    —
    確認日
    —
    出典・実験ID
    SRC-EA-086-URL-16F9BE23F7EC
    検証箇所
    EVIDENCE TABLE · 4. official spec/docs | Create jobs — Cloud Run | Google Cloud | https://cloud.google.com/run/docs/create-jobs
    適用範囲
    EVIDENCE TABLE
    出典・来歴
    SOURCE_PACKET_REFERENCE_PROJECTED
    限界
    元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。
  • EVD-EA-086-URL-728ABC12B871研究資料研究資料根拠の出所: SOURCE_PACKET_REFERENCE

    5. official spec/docs | Azure Functions Scale and Hosting | Microsoft |

    裏付ける内容
    —
    確認日
    —
    出典・実験ID
    SRC-EA-086-URL-728ABC12B871
    検証箇所
    EVIDENCE TABLE · 5. official spec/docs | Azure Functions Scale and Hosting | Microsoft | https://learn.microsoft.com/azure/azure-functions/functions-scale
    適用範囲
    EVIDENCE TABLE
    出典・来歴
    SOURCE_PACKET_REFERENCE_PROJECTED
    限界
    元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。
  • EA-086-R11-RESEARCH研究資料研究資料根拠の出所: AUDITED_CANONICAL_RESEARCH_PACKET

    EA-086 監査済みresearch / canonical revision binding

    裏付ける内容
    1. Serverless AIの適切なCoreは「LLMをfunction内へ必ず載せる」ではない。小さなorchestrator/functionがeventを受け、durable queue/stateへ記録し、managed model APIまたは別inference serviceを呼び、結果をdurable storeへcommitする形が最もportableである。 2. execution timeoutはprovider/plan/runtimeで異なる。AWS Lambda標準functionは最大15分、Azure Functionsはhosting planで大きく異なりHTTP応答には別の230秒境界、Cloud Run Jobsは通常task最大7日だがGPU taskは1時間である。よって「serverlessだから短時間」も「container serverlessなら無制限」も一般化不可。 3. queue/event integrationはduplicateを前提にする。AWS Lambda+SQSはat-least-onceでduplicate processingを明記しているため、AI call・billing・email送信・DB mutation等のside effectはidempotency key、deduplication record、outbox/transaction boundaryが必要。 4. GPU serverlessは実在するがavailability gateが強い。Cloud Run GPUはscale-to-zero可能で、L4/RTX PRO 6000 Blackwellをmanagedで提供する一方、GPU type、region、CPU/RAM minimum、one-GPU-per-instance等の制約がある。GPU availabilityをCPU serverlessと同等に扱わない。 5. cold startだけでなくmodel initialization、weight download、tokenizer/runtime initialization、network path、upstream model rate limitを別々に測る必要がある。platform instance startup値をend-to-end TTFT保証へ外挿しない。
    確認日
    —
    出典・実験ID
    COMM-079-EA0086
    検証箇所
    COMM-079-EA0086 · EA-086-R5-LEGACY-MIGRATION-20261008-R1 · content/staging/EA-086.md
    適用範囲
    監査済みEA本文・canonical revision・既存Source Graph relationの範囲。欠損currentnessは推測で閉じない。
    出典・来歴
    AUDIT_PASS_CANONICAL_BINDING
    限界
    canonical監査・revision bindingの存在を示す。外部ソースcurrentnessが本文またはcontrol-planeで確定していない場合は、currentnessをUNKNOWNのまま保持する。
  • EA-086-R11-WEB-READBACK実装資料実装資料根拠の出所: IMPLEMENTATION_READBACK

    EA-086 Web body identity / canonical readback

    裏付ける内容
    canonical staging bodyのSHA-256一致とR9 canonical ledger readbackをProduction projectionの入力として検証する。
    確認日
    —
    出典・実験ID
    WEBBODY-EA0086-R8-4F392BAB
    検証箇所
    WEBBODY-EA0086-R8-4F392BAB · content/staging/EA-086.md · EA-086-R5-LEGACY-MIGRATION-20261008-R1
    適用範囲
    R9/R10 canonical readback後のProduction生成時body identity。
    出典・来歴
    CANONICAL_READBACK_BODY_HASH_MATCH
    限界
    body identity/readbackは本文claim自体の真偽や外部ソースの最新性を追加保証しない。
出典ID
COMM-079-EA0086, SRC-EA-086-URL-44B5D8B4F201, SRC-EA-086-URL-C784C5865F16, SRC-EA-086-URL-8CCB457B5EA0, SRC-EA-086-URL-16F9BE23F7EC, SRC-EA-086-URL-728ABC12B871, WEBBODY-EA0086-R8-4F392BAB
追跡中のUNKNOWN ID
EA-086-UNKNOWN-01, EA-086-UNKNOWN-CURRENTNESS
再確認のきっかけ
正式な 改訂版/publication 状態 change · 本文 成果物 hash change · 出典 現行性 change · new contradiction or 実装 結果の照合

機械検査: 通過 — 機械検査の結果です。情報の正確性や実行の承認を保証するものではありません。

    同じ記事IDの機械可読データです。