# Stochastic Reproducibility／Nondeterminism Budget CURRENT_STATUS: CURRENT OBSERVATION: SPEC_ONLY FRESHNESS: CURRENT PAGE_TYPE: reference CANONICAL_URL: /tools/ea-684-stochastic-reproducibility-nondeterminism-budget CLAIM_IDS: none EVIDENCE_IDS: EVD-EA-684-URL-FC849E8674F9, EVD-EA-684-URL-CFB60CCD1A9B, EVD-EA-684-URL-5FFDE80BD139, EVD-EA-684-URL-7A3BE6A2F53E, EA-684-CURRENT-APPROVAL, EA-684-CURRENT-BODY-READBACK UNKNOWN_IDS: EA-684-UNKNOWN-01 OPS_IDS: none ## Summary 「seed固定により再現可能」と一般化しない。「特定runtime・version・hardware・scheduler等の前提を固定した範囲で再現性を高められる」「完全一致が契約できない系では反復分布と許容差を管理する」と記述する。 ## Current judgment 「seed固定により再現可能」と一般化しない。「特定runtime・version・hardware・scheduler等の前提を固定した範囲で再現性を高められる」「完全一致が契約できない系では反復分布と許容差を管理する」と記述する。 ## Scope Stochastic Reproducibility／Nondeterminism Budget ## Confirmed ## UNKNOWN - EA-684-UNKNOWN-01: 外部managed LLM providerでは、同一model名・同一request・同一seed相当パラメータでもbackend更新や非公開実行条件を完全には固定できない場合がある。provider固有の保証範囲は、その時点の公式仕様で個別確認する必要がある。 ## Evidence - EVD-EA-684-URL-FC849E8674F9 (RESEARCH): vLLM Reproducibility (current docs): — https://docs.vllm.ai/en/latest/usage/reproducibility/ - EVD-EA-684-URL-CFB60CCD1A9B (RESEARCH): vLLM Batch Invariance (current docs): — https://docs.vllm.ai/en/latest/features/batch_invariance/ - EVD-EA-684-URL-5FFDE80BD139 (RESEARCH): PyTorch torch.use_deterministic_algorithms (current docs): — https://docs.pytorch.org/docs/stable/generated/torch.use_deterministic_algorithms.html - EVD-EA-684-URL-7A3BE6A2F53E (RESEARCH): CANDIDATE_DOC_URL= — https://docs.google.com/document/d/1wXwrvTDzQei_Ptij8kRN6-EctEFvoalZCrGvHZrqE7Y/edit - EA-684-CURRENT-APPROVAL (RESEARCH): 現行本文の監査・revision対応 - EA-684-CURRENT-BODY-READBACK (IMPL): 現行本文の収録照合 ## Failure / limits 第一の失敗はseedの過信である。seedは乱数系列の一部を制御しても、実行順序、並列計算、batching、hardware差、version差まで固定しない。vLLMは再現性をデフォルトでは保証せず、現行ドキュメントではofflineでmultiprocessingを無効化して決定的schedulerにする方法、またはbatch invarianceを有効化する方法を示している。さらに、設定後も同一hardware・同一vLLM versionという条件を明示している。 第二は「temperature=0なら決定的」という扱いである。sampling randomnessを抑えても、数値演算や実行系の非決定性が残れば、logitの微小差がargmax境界や後続token列へ波及し得る。PyTorchのdeterministic algorithms設定も、同一入力・同一software/hardware条件で決定的algorithmを選ぶ仕組みであり、設定単独でapplication全体の再現性を保証しない。 第三はオンライン負荷を無視した試験である。単発offline試験だけが安定していても、実サービスではbatch size、request order、concurrency、tensor parallelism等が変わる。vLLMのbatch invarianceはまさにbatch sizeやrequest orderから出力を独立させることを目的としており、決定的kernelや固定reduction order等を使う一方、性能影響を明示している。再現性向上にはコストがあるため、SLOと同時に評価する必要がある。 ## Failure / limits 決定性を強めるほど常に品質が上がるわけではない。生成タスクでは意図的な多様性が価値になる場合があり、再現性のためにsamplingを過度に固定すると探索幅を失う。また、deterministic kernelやbatch invarianceは性能最適化とトレードオフになり得る。したがってnondeterminism budgetは「揺らぎをゼロにする予算」ではなく、「必要な多様性を残しながら、監査・回帰・安全性に影響する揺らぎを上限管理する契約」と解釈する。 ## 要点と前提 LLM・生成AIシステムの再現性は、「seedを固定すれば同じ出力になる」という単純な性質ではない。実運用では、サンプリング乱数、推論ランタイムのスケジューリング、バッチ構成、並列reduction、カーネル選択、ハードウェア、ライブラリ／モデル／provider側の更新など、複数の変動源が出力へ影響する。そのため再現性は二値の属性ではなく、どの条件を固定し、どの程度の差異を許容し、差異がどこから生じたかを追跡できるかという運用上の「nondeterminism budget」として扱うべきである。 ## 運用上の意味 再現性要求は用途別に分ける必要がある。デバッグや回帰試験では同一入力から同一または十分近い結果を再取得できることが重要である。一方、本番のオンライン推論では並行要求や動的batchingが入り、完全なbitwise再現性が性能・スループットと衝突し得る。したがって「完全一致」を全系統へ要求するのではなく、①入力・prompt・tool state・model/version・sampling parametersを再構成できること、②実行環境の主要fingerprintを記録すること、③同一条件での反復分布を測定すること、④許容差を越えた変動を変更・障害として検出すること、を分離して設計する。 ## failure / limitation 第一の失敗はseedの過信である。seedは乱数系列の一部を制御しても、実行順序、並列計算、batching、hardware差、version差まで固定しない。vLLMは再現性をデフォルトでは保証せず、現行ドキュメントではofflineでmultiprocessingを無効化して決定的schedulerにする方法、またはbatch invarianceを有効化する方法を示している。さらに、設定後も同一hardware・同一vLLM versionという条件を明示している。 第二は「temperature=0なら決定的」という扱いである。sampling randomnessを抑えても、数値演算や実行系の非決定性が残れば、logitの微小差がargmax境界や後続token列へ波及し得る。PyTorchのdeterministic algorithms設定も、同一入力・同一software/hardware条件で決定的algorithmを選ぶ仕組みであり、設定単独でapplication全体の再現性を保証しない。 第三はオンライン負荷を無視した試験である。単発offline試験だけが安定していても、実サービスではbatch size、request order、concurrency、tensor parallelism等が変わる。vLLMのbatch invarianceはまさにbatch sizeやrequest orderから出力を独立させることを目的としており、決定的kernelや固定reduction order等を使う一方、性能影響を明示している。再現性向上にはコストがあるため、SLOと同時に評価する必要がある。 ## control / implementation implication 1. Replay envelopeを保存する。最低限、request body、prompt/template revision、system/developer instruction revision、retrieval/tool inputsの識別子、model/provider identifier、sampling parameters、seed（利用可能な場合）、runtime/library version、hardware class、時刻、response、重要なprovider/runtime fingerprintを同一traceへ束ねる。秘密情報や個人情報は直接保存せず、必要に応じてredactionまたは参照ID化する。 2. 再現性を階層化する。例として、R0=監査用replay情報が不足、R1=入力と設定を再構成可能、R2=同一環境で統計的に安定、R3=同一環境でtoken/output一致、R4=許容された異環境でも規定差以内、といった内部契約を定義する。重要なのは名称ではなく、各workflowがどの水準を必要とするかを事前に固定することである。 3. Nondeterminism budgetを測る。golden promptを一度だけ実行して合否を決めず、同一条件で複数回実行し、task success、structured-output validity、tool-call sequence、semantic score、token-level divergence、latency/cost等の分布を取得する。budgetは「完全一致率100%」だけでなく、業務上のfailure率上限や分位点で定義できる。高リスク処理ではsemantic similarityだけでなく、禁止動作・tool side effect・schema違反を別軸で監視する。 4. Change boundaryを記録する。model alias、provider backend、serving runtime、driver、GPU、quantization、kernel、prompt、retrieval corpusの変更前後で同じreplay setを走らせる。差異がbudgetを越えた場合、単に「LLMは確率的」として受容せず、変更点と変動源を切り分ける。 5. Deterministic modeは限定適用する。self-hosted runtimeで再現性が必要な検証系では、runtimeが提供するdeterministic scheduling／batch invariance／deterministic algorithmを利用できる。ただし性能低下や対応hardware制約があり得るため、本番設定へ無条件に持ち込まない。検証系と本番系で設定が異なる場合、その差自体をreplay metadataへ残す。 ## 適用境界 完全なbitwise reproducibilityは、外部providerの内部backendが利用者から固定できない場合や、hardware／runtime更新を跨ぐ場合には契約できないことがある。その場合の安全な表現は「同一出力を保証する」ではなく、「観測可能な入力・設定・version/fingerprintを保存し、反復評価で許容変動を管理する」である。逆に、自前推論基盤でhardware、runtime、schedulerまで管理できる場合は、より強い再現性契約を設定できる。 ## Counterevidence / limitations 決定性を強めるほど常に品質が上がるわけではない。生成タスクでは意図的な多様性が価値になる場合があり、再現性のためにsamplingを過度に固定すると探索幅を失う。また、deterministic kernelやbatch invarianceは性能最適化とトレードオフになり得る。したがってnondeterminism budgetは「揺らぎをゼロにする予算」ではなく、「必要な多様性を残しながら、監査・回帰・安全性に影響する揺らぎを上限管理する契約」と解釈する。 ## OPEN_UNKNOWN 外部managed LLM providerでは、同一model名・同一request・同一seed相当パラメータでもbackend更新や非公開実行条件を完全には固定できない場合がある。provider固有の保証範囲は、その時点の公式仕様で個別確認する必要がある。 ## SAFE_WORDING 「seed固定により再現可能」と一般化しない。「特定runtime・version・hardware・scheduler等の前提を固定した範囲で再現性を高められる」「完全一致が契約できない系では反復分布と許容差を管理する」と記述する。 ## Provenance / source locators - vLLM Reproducibility (current docs): https://docs.vllm.ai/en/latest/usage/reproducibility/ — defaultでは再現性非保証、offlineのdeterministic schedulingまたはbatch invariance、同一hardware/version条件。 - vLLM Batch Invariance (current docs): https://docs.vllm.ai/en/latest/features/batch_invariance/ — batch size/request orderに依存しない出力、deterministic kernels・固定reduction order等、性能trade-off、機能制約。 - PyTorch torch.use_deterministic_algorithms (current docs): https://docs.pytorch.org/docs/stable/generated/torch.use_deterministic_algorithms.html — 同一software/hardware条件でdeterministic algorithmを選択し、設定単独ではapplication reproducibilityを保証しない。 - Canonical proposal provenance: Enterprise AI運用辞典_発展・拡張構想_公開後アップデート原案台帳, EA-684. AUDIT_HANDOFF TARGET_ID=EA-684 CANDIDATE_ID=ORPHAN-RESCUE-EA684-20261019-C1 CANONICAL_TOPIC=Stochastic Reproducibility／Nondeterminism Budget CANDIDATE_DOC_ID=1wXwrvTDzQei_Ptij8kRN6-EctEFvoalZCrGvHZrqE7Y CANDIDATE_DOC_URL=https://docs.google.com/document/d/1wXwrvTDzQei_Ptij8kRN6-EctEFvoalZCrGvHZrqE7Y/edit SOURCE_LOCATORS=vLLM Reproducibility; vLLM Batch Invariance; PyTorch deterministic algorithms; canonical EA-684 proposal AUDIT_HANDOFF=YES NEXT: /agent/start.json STOP: This is a knowledge projection, not an execution order.