NOIA AI System Watch 日次｜2026-10-14（保存版）
AIモデル・知能 エージェント・データ基盤 AI半導体 メモリ 電力・冷却 AIインフラ・産業
出典・更新履歴・検証情報
この保存版のデータを照合するための情報です。元記事の初公開日とは区別しています。
- データセットの版
- 2026.10.21.2
- 記事内容のSHA-256
3e0a52e157ad5ee1ca40d78f110c9db51a42476e246f3066e4598cb486fcea4e- 保存版のSHA-256
ebf3fb1723af14b803d86e049a8aa277906408d1ffe678164494e2847b83cba5
外部証明の最終検査結果は詳細を開くと表示します。
NOIA AI System Watch 日次｜2026-10-14（保存版）
#NOIA AI System Watch
#Daily Intelligence and 09JST Delta
#2026年10月14日 09時 JST
#対象期間：2026年10月13日09時から14日09時JST（13日00時から14日00時UTC）。比較基準は10月13日09時の日次号。期間内に伝えた速報を統合し、その後の確認と、今回初めて加える過去公表資料を区別する。
#結論：新しい運用報告では、engine死亡を避けるためのguard導入後にもrequest失敗が残った。別のmemory会計修正では、小容量条件の速度は大きく変わる一方、容量が十分な条件では変わらなかった。どちらも、AIの実効能力を、同品質と遅延条件で完了する仕事で測る理由になる。
#この24時間には、host状態の復元、KV転送順序、CUDA graphが参照するkernelの寿命という別々の不成立点が具体化した。改善の限定結果はあるが、release、本番品質、SLO、全資源費用のどこまで確認したかを分ける。
#初めて日次に加えるMETRの監視費用分析は9月27日公表の予備結果。著者の費用増85%、壁時計時間増43%には人の承認待ちが含まれず、GPU時間への換算はできない。安全対策も、検知から承認・遮断・回復までの境界で評価する。
#観測範囲：選択資料の確認であり、全分野・全期間の連続監視ではない。07時JSTの確認は部分的で、検証できた範囲は電力関係の5資料。同時点のruntime、security、供給分野の結果は新しい確証に使わず、その後の独立した確認を資料別に記す。前報を継承し今回原文を再取得していない箇所は明示する。最終観測締切は発行時刻と別で、末尾に記す。
#判定語：Confirmedは資料や状態を確認したという意味で、著者の実験を独立再現したという意味ではない。Actualは報告された実施・運用、Guidance／Targetは計画・目標、Estimatedは推計、Unknownは判定に必要な証拠が不足する状態を指す。
#01 Critical Changes
#05時以降のDelta
#- vLLM #61499／#61500の著者運用報告では、engine死亡の抑制とrequest／peer回復が分かれた。#61499のguard後も、2engineは生存しながら101requestが失敗。#61500はpeer解放と再handshakeの記録を示すが、その後の成功requestや長期回復は未確認。fleetの失敗率や追加能力に変換せず、運用指標の更新として採用する。KV失敗の局所化、peer回復の提案 [R07]
- #61509の起動時memory会計修正では、L4の限定実験で40.5→113.2 token/s。しかし十分なmemory設定では110.6→110.1 token/sで、この差にはprefixを保持できる閾値が関係する。2.8倍という見出しを一般的な演算能力増とせず、資源配置と実workloadの境界として追う。起動時のKV割当会計 [R08]
- #44118に別の4GPU構成のAgentX比較が追加された。throughput増は0.3～2.7%、mean ITLは2～6%低下。96sessionのoff反復間には1.8%の幅もある。少ないrunと未計測の品質・joint SLOを踏まえ、広い高速化の主張を弱める材料とする。queue-sharingの追加比較 [R09]
24時間の統合
#- #61242の未公開最適化、#43935のB300試験、host復元の#43998、KV転送guardの#44081、kernel寿命の#61465には、それぞれ前進を示す限定結果がある。公開code、実験revision、判定分母、releaseと本番を接ぎ合わせない。[R01 R02 R03 R04 R05]
- METRの監視費用を今回追加。人の承認待ちと独立したpaired対照が閉じていないため、安全computeの総需要推計には進めない。METRの予備分析 [S01]
- 制御下の自己複製研究は、実環境の自律的拡散事案ではない。actor推論、payload、別の低速な物理デモを分ける。Anthropicの自己複製評価 [S02]
14需給gradeはすべてUnknown。新しい同仕様・同地域・同期間の数量証拠で品種別需給を更新できていないためで、物理的な無変化の結論ではない。
#02 AI Research Frontier
#engineの生存と仕事の回復
##61499の著者は、GLM-5.3のP/D、H100、decode TP8／HiSparse、NIXL 1.5.0、main d6aca837c3に三つの別PRを組み合わせた運用を報告する。修正前の4時間に15 decode engineが死亡したとし、15:56 UTC以降に起動したengineへguardを適用、20:15までに36engineすべてへ展開したという。ただしengine時間、総request数、観測終了時刻、raw運用logは未確認で、15/36を失敗率としない。[R07]
#同じ報告で18:46～19:33 UTCには2engineが生存しながら101requestが失敗した。#61500の別patchは17:17以降の起動へ適用され、20:16の1request失敗後、50ms後のpeer解放、その5秒後の再handshakeを著者が記す。別の2peerの観測は18:24～18:26の2分間に限られる。cohort、revision、観測窓が揃わず、#61499も併用されるため、単独の因果効果や持続的なrequest回復は確定しない。[R07]
#exact-headの静的codeでは、#61499は非HMAかつKV cache groupが一つの場合だけfailed block IDを報告し、複数groupではrequest単位の失敗処理へ限定する。#61500のcleanupはpullのみでin-flight transferを待ち、backoffを含む。pushは対象外で、繰返し失敗時には最大60秒のbackoffもある。静的codeは著者の運用件数を独立検証せず、再接続だけでは次の回答の成功・SLOも確認できない。KV失敗処理、pull peer cleanup [R07]
#memoryの閾値と性能の条件
##61509はadaptive-verification profilingの後にallocatorの予約cacheを解放し、起動時のfree-memory計測を補正するdraft。L4、Qwen2.5-1.5B target＋0.5B draft、max sequences 3、約24Kのwarm prefixという著者実験で、12prompt、各条件1run、greedy、出力上限256 tokenを使う。memory利用設定0.36ではKV枠64,688→86,960token、prefix hit 37.8→50%、出力40.5→113.2 token/s。約24.3Kの3requestを保持する閾値を跨いだという条件が重要である。[R08]
#利用設定0.9ではKV枠376,432→398,912tokenでも出力110.6→110.1 token/s。起動会計の改善は演算kernelの一般的高速化ではない。全benchmark revision、反復性、paired品質、tail SLO、起動費用、deploymentは未確認。別の7B例は別PRを含むためこの群へ合算しない。起動時memory会計の実験 [R08]
##44118のqueue-sharing提案の既存P/D比較では、2本目のbaseline 611.3 token/s/GPUに対しonは625.4で、差は約2.3%。著者は利得を約2～3%とする。P90 TTFTは15.81→17.61秒だが、一回のon runとの表の差で、因果的な悪化量とはしない。[R09]
#13日23:17:38 UTCの追記は別のaggregated構成。MI355X 4GPU、router下のTP2／EP2 replica二つ、rank当たり180GBのHiCache、ROCm 7.2.4を用い、64／96／128sessionで各1run、96だけoffを追加反復した。著者集計のthroughput増0.3～2.7%、mean ITL低下2～6%に対し、96のoff反復間の幅は1.8%。この2runの差は信頼区間ではなく、他のsession数にも一般化しない。追加構成のTTFT表はなく、先のP90を転用しない。両比較は合成acceptance 2.99、off-main複合codeで、accuracy未計測、joint SLO未提示。現在headのdraft／unmergedも変わらない。queue-sharingの比較 [R09]
#同じ成功仕事を測る条件
##61242の未公開修正版は、TTFT≤2.93秒かつTPOT≤21.74msという同時判定でgoodput 2.02／2.09／2.10 req/sを著者が報告した。旧baselineは2.02／1.98／2.01、現在公開されている変更側は1.52／1.62／1.69 req/s。公開head 8b79b87dに修正版はなく、異なるnode・日付の比較である。追加の出力screenも、pairedな意味・task品質の同等性を確立していない。容量割当の改善、現行公開codeの遅延不利、未公開修正版の著者結果を三つに分ける。DCPとjoint SLO [R01]
#host復元の#43997／#43998は、v0.5.21、GLM-5.3-Flash-FP8、B300 4基、TP4、speculative decodeなしの著者試験。host復元では必要情報を欠く／誤る判定が18/20、cold・device hit・修正版では0/20と報告した。ただし四つのsubstringをreasoningとfinal全体で探す狭い判定で、stock側の10/20は900tokenの上限に達した。包括的な意味品質や同じ生成長の比較ではない。[R03]
#修正版はINDEXER状態のhost mirrorを持ち、著者説明では、この98,368-tokenのhost tierで追加host memory約0.14 GB／rankと追加転送を要する。PRはclosed／unmergedで、著者の「mainで修正済み」「次release予定」はclean buildの独立検証ではない。overlay、共有top-kの旧経路、実SLOという留保を残す。制約がGPUだけからhost memoryと復元経路へ移る可能性はあるが、移動量の全体推計はできない。host復元の報告、修正提案 [R03]
##44081はGB300の1P1D、NIXL、Qwen3-4B-Instruct-2507、HiCache write_back、約100Kの共通host-only prefixと2並列requestを用いた著者試験。nightlyへ2ファイルを重ねた条件で、host load前の早いKV送信をguardし、checksum不一致29/30→0/30を報告した。回答の誤り29/30→0/30ではない。約54msは著者のKV送信遅延で、TTFT／TPOTの実測差ではなく、CPU／mock試験もGPU raceの独立再現ではない。KV送信guard [R04]
##61465の著者比較はRTX PRO 6000 Blackwell Server Editionで、graph作成、workload、cache、owner寿命などを変えたfrontend修正前後それぞれ96構成cellを扱う。22/96→0/96は構成cellの結果であり、96回の同一独立試行や本番request率ではない。所有者を保持する対照armが両側で成立するという機構の証拠と、特定modelの本番修復を分ける。frontendの対処はexecution planを保持するため、追加保持memoryは未計測。公開wheelによるend-to-end serving、品質、tail SLOのbefore／afterも未提示である。kernel寿命の対処 [R05]
#Security
##61488はKV checksumの収集とfail-closedによる使用拒否を別flagにしたdraft。確認したheadでは両方default offで、検証失敗・未検証のloadでも遮断を有効にしなければ利用やprefix cacheへの保存へ進み得る。checksumがあることと、全経路で不正な状態を使わないことは同義ではない。[R06]
#著者はQwen3-8Bの3回のfresh-server runで、各pairの200出力を照合しtoken一致を報告する。一方、31件のlease切れloadは一つのstall episodeでありfleet率ではない。MiniMaxのpaired差の区間だけで同等性を宣言せず、end-to-endのon／off性能が未提示であることも残す。誤りの検知、request失敗、再計算、成功回答までの資源を同じ測定で閉じる必要がある。KV checksumとfail-closed [R06]
#Alignment
#Anthropicの10月12日公表研究は、簡略化した8node評価でactorの推論を別serverに置く。別の15台×4GB物理装置上のGemma 4-26B-A4Bについては、著者が0.39 token/sを報告した。これらを結合して、評価に用いたactor自体が現実的な条件で自律複製し続けたとしない。13日21時の前報を継承し、今回原文は再取得していない。[S02]
#能力試験で経路が成立すること、モデルが自律的にそれを望むこと、現実の権限・資源・検知を越えて拡散することは異なる主張である。評価結果だけから意図や現在の実害を推定しない。次の判断は、actor／payload／harness、外部推論、権限、資源、停止条件を揃えた研究の独立確認に依存する。
#Assurance
#10月13日16時42分JSTに共有したsecurity基準資料との継続比較では、Anthropicは内部評価のlive-internet制限を拡張する判断と、既知caseのreplay遮断を説明する。全対象でshutdownが完了した独立証拠や未知caseでの有効性までは確認していない。内部評価の制限に関する説明 [S03]
#英国の10月12日発表はcyber defenceやagent事故対応の拡充、法的・報告措置の検討という段階。ECのcodeへの参加はvoluntaryで、既存Article 50の義務とは区別する。今回の選択資料から新しい発効義務は確認していない。英国の方針、ECのcode [S06]
#AISIの技術実務agendaはvoluntaryで、評価・controlから将来行動を保証することにも限界を置く。OpenShellのsecurity文書も、接続先の許可とmethod／pathなどrequest単位の制限、auditでの記録・転送とenforceでの遮断を分ける。文書上の機能、設定、実際に通る全経路、継続運用の証拠を分離する。[S04 S05]
#Safety Compute
#METRの9月27日noteのAppendix Cは、4,313 transcript、648 task instanceのbootstrapを用いた予備推計。monitorはgpt-5.5／opus-5、agentはgpt-5.4／opus-4.7、maximum reasoningという条件で、著者は費用85%増、壁時計時間43%増を記す。人の承認待ちは除外される。transcriptが少数のtaskへ集中している点も、一般化と不確実性の評価に重要である。[S01]
#図注のmonitor shareは費用46%、時間30%。増分率と総量に占めるshareは分母が違うため、同じ尺度として並べない。独立したpairedな監視なし対照による推定かは未確認。人の承認待ちを含む総review時間は未提示。ドルやelapsed timeからGPU時間、電力、業界全体の安全computeを算出しない。[S01]
#著者の実装記述では、人だけによる承認の認証・強制が備わっていない。全actionの可視性と推論費用の完全な集計にも留保がある。これは著者が開示した限界で、独立監査の結果ではない。承認者の真正性、遮断、再試行、logging、評価、事故対応まで含む会計が必要というのが分析上の含意である。防御の一般的有効性を確認したという主張ではない。[S01 S05]
#03 Physical AI Frontier
#新しい実機の成功作業率、介入率、継続稼働、顧客受入れ数量を更新する確証は、採用資料の範囲では未確認。
#評価単位は受け入れられた実作業とし、機上推論、通信、再試行、reset、人の介入、保守を同じ分母へ含める。simulationや映像、modelの論理的能力からrobot出荷数やedge／cloud半導体のBOMへ変換しない。次の判断材料は同fixture・同環境の実機対照と、介入込みの成功仕事／時である。
#04 Compute Demand Update
#需要の更新に必要なのは、品質とjoint SLOを満たす成功仕事当たりのGPU時間、host時間、network転送、storage、電力、失敗・再試行を含む総費用である。#61242の論理的なKV配置、#43998のhost mirror、#44081の送信guard、#61465のplan保持は、異なる場所へ資源や待ち時間を移す可能性を示す。[R01 R03 R04 R05]
#安全対策の追加computeも別建ての無条件倍率にしない。METRの費用／時間にはmodel・reasoning・task構成と除外範囲がある。利用率、価格、GPU型、batching、human waitが不明なまま、費用増85%をGPU需要増85%へ移せない。[S01]
#条件付きの需要連鎖は、同品質・同SLOで単位仕事の全費用が下がり、利用価格や待ち時間へ反映され、利用量が変わり、その変化が設備投資へ伝わる場合に成立する。本号は各段階の必要証拠を示すもので、需要弾力性や将来購入台数を数値設定したscenarioではない。
#05 Semiconductor Demand
#B300、GB300、RTX PRO 6000などの限定構成で得たruntime結果を、同じ製品全体の性能・需要へ外挿しない。HBMのweight、KV、workspace、通信bufferという用途を分け、host退避でGPU側の使用量が減った場合も、復元の正しさと費用を含めて評価する。[R02 R03 R04 R05]
#前号のMaia 200本番利用説明とMaia 300／multi-GW計画は継続contextであり、この24時間の新規供給として加算しない。本号で新たな顧客受入れ量や採用率を確認していないため、GPUとcustom ASICの置換率、HBM世代別bit需要、rack当たりBOMは更新しない。
#06 Packaging
#同方式・面積・HBM構成の認定良品／月と未充足需要を結ぶ新数量は未確認。次の判断点は、設備の投入能力から、接続・反り・熱・multi-die testを通った顧客受入れへ進む速度である。CoWoS、CoPoS、EMIB、glass packageは別々に、歩留まり・再work・納期を追う。
#07 Materials
#ABF、CCL、低CTE／低Dk glass cloth、銅箔、樹脂、薬液は、同gradeの認定量と実需要の新しい対照がない。制約移動の候補は原材料から加工・顧客認定・下流歩留まりへ。代替品が実際に認定され、納期と未充足注文が改善するかが、増設発表よりも判断に近い証拠になる。
#08 Passive Timing
#server用MLCC／inductorとQuartz／XO／TCXO／OCXO／Timing ICの品番別需給はUnknown。耐圧・容量、電流、jitter、温度、信頼性を揃えた認定良品、用途別消費、在庫、納期が必要である。広い市況推計の中でも高容量と低容量、serverと民生の差が、次の検証単位となる。
#09 Analog Power
#PMIC、ADC／DAC、AFE、driver、VRM、MOSFET／GaN／SiCの新しいOEM認定良品量は未確認。制約候補は素子特性から、変換段、保護、配線、熱、冗長性を含むrack認定へ。効率と供給の評価には同負荷・温度・信頼性のsystem損失と、実装の受入れ量を対にする。
#10 Optical
#800G／1.6T、CPO／NPO、SiPh、USFPの新しい認定出荷・現場受入れ数量は未確認。速度・距離・光源・温度だけでなく、test時間、修理性、現場linkの継続稼働が有効供給を決める。
#KV配置やdisaggregationが通信byteとtopologyを変えても、光module需要は実fabricのlink利用率、距離、接続数、故障時動作を経て判断する。#61242と#44081は、その接続を調べるsoftware側の手掛かりである。[R01 R04]
#11 Test
##43935はB300 8基でGSM8K 200問、90.5%という著者／公開jobの結果を13時速報で確認した。閾値85%を上回る一つの実model試験である。要求・実行revisionとlogの対応は既報の範囲に留め、#43921とはsystem全体・version・modelが一致しないため、原因を一つのpatchへ帰属しない。[R02]
#その後にmergeされた#43948は8-B300 PD／CP／DSparkのaccuracy testを外す変更。後続CIのgreenは、外したaccuracy testの新しい成功を意味しない。一つのpass、merge、test範囲の縮小、release、productionは別の証拠である。B300 test結果、test範囲の変更 [R02]
#半導体・package・光のtestでも、装置台数ではなく、同screening品質の良品／時間、再試験、socket／probe、熱条件、downstream受入れを評価する。softwareの限定cellやchecksum成功を、製造testの数量能力へ換算しない。
#12 Manufacturing Capacity
#TeraWulfの10月5日Muskie発表を今回追加確認した。契約電力を500MWから1GWへ拡張し、初めの500MWを2028年、次の500MWを2030年から2029年へ前倒しする目標。Kentucky PSCの承認とutilityの建設が条件であり、10月13日の新規commissioningではない。契約、認可、建設、使用可能な電力を分ける具体例である。Muskieの計画 [P01]
#AI hardwareの新しい認定良品・実受入れ量による能力更新は未確認。設備発表から、設置、sample、認定、量産、出荷、顧客acceptanceへ進む時計を追う。供給分野の確認は部分的である。
#有効供給を更新するには、稼働時間、availability、歩留まり、認定、実受入れの数量を接続する。既に歩留まり込みの良品へ歩留まりをもう一度掛けず、wafer、bit、package、rack、装置売上を無条件に換算しない。
#13 China
#中国向けGPU、HBM、先端package、国産代替の認定出荷と実workloadを更新する確証は未確認。製品revision、software stack、同品質・同SLO、顧客受入れ、販売・利用可能地域をそろえ、研究から量産・shipmentまでの段階を追う。政策や数量の無変化を確認したという意味ではない。
#14 Infrastructure
#DOE Order 202-26-50の法的発行は前号で確認済み。今回の選択確認でも10月13～16日の条件付き権限という範囲を維持する。署名済み文書そのものを読み直した時計ではなく、landing／一覧の取得である。実際のdispatch、backup稼働、増分MW、AI workloadへの効果はUnknownのまま。DOE 202-26-50 [I01]
#PJM #105555は許可取得と事前調整、#105557はEEA1等のalertと計画停止設備の早期復帰見込みの提出要請を記す。早期復帰を求めることは、発電機が戻った観測ではない。EEA1からEEA3やbackupの実起動を推定せず、個別noticeの非drill区分や実dispatchも未確認として扱う。[I02]
##105556の最後の確認は10月14日05:35:12.801 JST。06時の締め確認は技術的に失敗し、closing comparisonはUnknown。ERCOTの最新選択rowはnative 10月13日00:48:11、timezone未開示で、10月12日の450MW超の突発的な発電損失がなかったという閾値付き報告。小さい損失なし、供給追加、AI能力増の意味ではない。[I03 I04]
#CoreWeaveの以前のprovider解決宣言は既報。今回の現況や顧客workloadの独立回復は更新していない。GCS、Azureなど未確認の状態を推測せず、取得失敗をservice障害・撤回としない。電力もstorageも、許可・事業者表示・顧客の成功仕事を別々に追う。
#15 Actual Deployment
#| 対象 | 確認した段階 | 次の段階に必要な証拠 |
|---|---|---|
| #61499と#61500 | 著者による段階的なstartup patch展開報告。PRはunmerged | 対象revision、exposureを揃えたrequest成功とSLO、持続回復 |
| #61509 | 起動会計のdraftと容量閾値依存の著者実験 | 反復・同品質・tail SLO、配布と運用 |
| #61242最適化 | 未公開codeによる著者実験 | exact revisionの公開、matched品質とjoint SLO、採用環境 |
| #43998と#44081 | overlayによる限定結果。既報時点で前者closed unmerged、後者unmerged | clean build、対象経路のreal serving、releaseとdeployment |
| #61465 | 上流release公開とvLLM採用PR。著者の構成cell試験 | 配布wheel、対象modelの長時間serving、保持memoryとSLO |
| #61488 | draftのchecksum／遮断実装と著者試験 | 全経路の設定・遮断確認、性能、配布と本番利用 |
| 自己複製研究 | 制御された評価と別の物理デモ | 独立した評価境界・全資源の確認。実拡散を推定しない |
| DOEとPJM | 法的権限とoperator notice | 実dispatch、持続出力、顧客のAI成果 |
stageを進めるのは対応する証拠が増えた場合だけである。releaseがあっても顧客採用とは限らず、採用されても全model・全構成の成功とは限らない。[R01 R03 R04 R05 R06 S02 I01 I02]
#16 New Hidden Bottlenecks
#新たに、processを生かすことと仕事を完了させることの間に回復制約が見える。failed peerの再接続やbackoffはengine死亡を避けても、request失敗や待ち時間を残し得る。[R07]
#第一に状態の完全性。weightやKV本体だけでなく、INDEXER、prefix、lease、配置・転送順序を含めなければ、保存できる容量が回答の有用性へつながらない。[R03 R04 R06]
#第二に非同期の寿命。CUDA graph、cache eviction、execution plan、kernel codeの所有関係が切れると、同じhardwareでも正しく実行できない。修復のための保持memoryとwarmup／capture費用も測定対象になる。[R05]
#第三に検証範囲。testの削除、旧revisionの結果、単一episode、未公開patch、出力screenを取り違えると、実際には閉じていない問題を解決済みと誤判定する。[R01 R02 R03 R06]
#第四に監督の完全性。検知modelの精度に加え、見えていないaction、承認者の真正性、遮断設定、人のqueueと再試行が支配的になり得る。これはMETRとOpenShellの限定観測からの仮説であり、市場全体の最大制約を同定した結果ではない。[S01 S05]
#17 Bottleneck Map
#評価期間は対象24時間、将来計画はその別期間。次表の地域は評価すべき範囲であり、今回その地域すべてを調査したという表示ではない。Unknownはデータ不足の分類で、不足率ゼロやBalancedを意味しない。
#| 分類 | 品種と地域の評価単位 | gradeと不足する証拠 |
|---|---|---|
| Compute | 記載されたB300／GB300／RTX PRO 6000等の構成。試験所在地未開示 | Unknown。同品質・joint SLOの成功仕事、全資源、実利用と価格 |
| HBM | HBM3E／4／4Eの世代・stack別。韓国・台湾・米国等 | Unknown。認定bit供給、消費、在庫と実納期 |
| Packaging | AI先端packageの方式・面積・HBM構成別。台湾・韓国・米国等 | Unknown。認定良品／月、受入れ、未充足注文 |
| Substrate | ABF／大型FCBGAの同仕様。日本・台湾・韓国等 | Unknown。良品面積、顧客認定、歩留まりと需要 |
| CCL | AI server用の低損失・高多層grade。日本・台湾・中国等 | Unknown。grade別の受入れ量、在庫と納期 |
| Glass Cloth | 低CTE／低Dk／石英grade。日本・東アジア | Unknown。同gradeの認定量、代替可能性と需要 |
| MLCC | server同品番の耐圧・容量別。日本・韓国・台湾 | Unknown。認定良品個数、用途別消費と納期 |
| Quartz | XO／TCXO／OCXO／Timing IC。同jitter・信頼性。日本・米国・東アジア | Unknown。同仕様の出荷、在庫と未充足需要 |
| Optics | DC 800G／1.6T、CPO／NPO。米国・東アジア | Unknown。検査済みmodule、現場link受入れ、再試験と納期 |
| InP | 基板／epi／laserの径・grade・工程別。米国・日本・東アジア | Unknown。認定良品、実消費、下流歩留まり |
| Test | AI processor／package／光のtest。米国・日本・台湾・韓国等 | Unknown。同screening品質の良品／時間、再試験と受入れ |
| Analog | AI rack用PMIC／VRM／power device。同負荷・温度。米国・日本・欧州・東アジア | Unknown。OEM認定、出荷、実納期と未充足需要 |
| Power | 米PJM／ERCOTと対象DC。DOEの法的期間は10月13～16日 | Unknown。dispatch、地域別firm供給、持続IT MWと実影響 |
| Cooling | 対象の高密度AI rack／液冷設備。北米等 | Unknown。同水温・密度・冗長性での持続排熱と現場受入れ |
18 Constraint Migration
##61499／#61500からは、障害の影響をengine全体へ広げない処理の次に、peer回復と成功仕事が課題になるという仮説が得られる。#61509の著者実験は、起動時の会計差に対して0.36設定ではthroughputが大幅増、0.9設定ではほぼ不変。cache保持の閾値と結び付けて読むことで、どの条件で能力を改善し得るかが具体化する。[R07 R08]
#確認したのは局所的な機構と条件付きの結果である。#61242ではKVの重複保持を減らす配置が通信と遅延の条件を変えた。#43998ではhostへ置いた状態を正しく復元するために別のstateと転送が要る。#44081では早い送信を待たせるguard、#61465では参照寿命を保つ保持が必要になる。メモリーの余地を得ても、その先で待ち時間、host容量、同期、実行の正しさが律速になり得る。[R01 R03 R04 R05]
#安全対策では、modelによる検知から遮断経路、人の承認、監査へ条件が移る可能性がある。監視の高いscoreだけでは、未観測のactionや誤った承認を閉じられない。physical supplyでは製造量から認定・test・受入れ、DCでは法的許可から接続・dispatch・持続運用へ進む。これらは段階ごとの検証仮説で、全産業の制約順位を確定したものではない。[S01 S05 I01 I02]
#同品質・同SLOのmatched比較で追加のhost・転送・待ち時間負担が見られなければ、制約移動仮説を弱める。改善自体が再現しなければ、実効能力改善の仮説を弱める。認定出荷と納期が改善し未充足注文が減れば、その品種・地域の供給制約仮説を弱める。
#19 Company Relationships
#vLLM、FlashInfer、cuDNN frontend／backendには依存境界がある。#61465のfrontend更新はそのconsumer経路を対象とし、上流のrelease公開がすべてのcuDNN利用者の更新を意味しない。torch側を含め、実際に解決されるbinaryと経路、誰が配布し誰が採用したかを追う。[R05]
#SGLangのauthor、reviewer、merge、release、運用者も別の責任主体である。METRのagentとmonitorのmodel、承認者、実行環境も同じように分ける。企業の提携・同じGPU名・隣接componentというだけでは、試験条件や運用結果の同一性を保証しない。[R02 R03 S01]
#DOEの法的権限、PJMのoperator要請、設備保有者の起動、AI事業者の成功仕事は証拠の主体が異なる。関係が存在することと、その時点で供給が流れたことを混同しない。[I01 I02]
#20 Feedback Loops
#効率改善から利用増・再投資へ進む循環は条件付き。単位仕事費用が下がっても品質・tail SLOが悪化すれば利用者の価値は下がり得る。逆に検証や監視の費用が増えても、失敗・再試行・事故による損失が減れば成功仕事の総費用は下がり得る。今回の資料だけでは差し引きの符号も規模も確定しない。
#実験で発見した不具合がtestへ入り、releaseに届き、productionから新たな失敗が戻るという改善循環も、testが残り同じ問題を観測し続けることが条件になる。#43948の範囲変更は、CIの見え方自体が変わる例である。green率をそのまま能力や品質の時系列にしない。[R02]
#21 Structural Change
#今日の構造仮説は、AI能力の評価対象がchip単体のpeakから、状態を保存・転送・更新し、正しく実行し、許された操作で完了した仕事へ広がることにある。これは本号の評価枠組みであり、市場全体が既に同じ指標で取引されているという観測ではない。
#22 Previous Thesis Update
#- Strengthened：実効能力は成功仕事で測るという仮説。engine生存と101request失敗の併存、#61509の0.9設定ではthroughputがほぼ不変という結果が、新しい具体例になった。著者報告の範囲で強まり、独立検証の完了ではない。[R07 R08]
- Strengthened：状態の復元・転送・参照寿命が能力を左右するという仮説。host mirror、送信guard、kernel保持という機構が具体化した。clean build、配布、本番SLOは別に残る。[R03 R04 R05]
- Weakened：#44118を広い高速化として扱う見方。P/Dは追加baselineで約2.3%へ狭まり、別のaggregated構成も0.3～2.7%増にとどまる。96sessionのoff反復間にも1.8%の幅があり、反復性と品質・joint SLO込みの利得はUnknown。[R09]
- Confirmed：#43935の限定されたB300 test成功と、後の#43948によるtest除外というrepository／test上の観測。前号の失敗から一般修復へ進んだという確認ではない。今回は前報を継承する。[R02]
- Unchanged：今回の選択比較で、DOE／PJMの権限・調整の記述、METRの予備推計、既知security anchorの該当記述は実質的に同じ。業界や未確認sourceの無変化を意味しない。[I01 I02 S01 S03 S04 S05]
- Unknown：14需給grade、本番全体のrepair、GPU時間で測ったSafety Compute、現在の実dispatch・AI効果。観測不足をUnchangedへ移さない。
Invalidatedに分類する、以前の主要仮説を覆す確証は本号の採用範囲では得られていない。狭い成功や反例は、対応する構成・条件の仮説だけを更新する。
#23 What To Watch Next
#24時間：#61499／#61500のengine生存、次requestの成功、再発とbackoffを分けた運用記録。#61509の十分なmemory対照を含む反復・品質・SLO。#61242の修正版exact revisionと同品質のmatched joint SLO、#44081のclean buildによるGPU race検証とTTFT／TPOT、#61465の採用・配布状態と実wheelによるserving結果を確認する。#61488はchecksum収集とfail-closedの全経路、on／offの性能を分ける。#44118は構成ごとの反復、accuracyとjoint SLOを確認する。queueやCI commandだけでは終端成功へ進めない。[R01 R04 R05 R06 R07 R08 R09]
#7日：host復元の改善が上流のどのreleaseに入り、同model・同設定で再現するか。削除されたaccuracy testを含め、検証範囲が復元・置換されたか。監視では人だけの承認、見えていないaction、既知case以外の有効性、待ち時間込みの費用を確認する。これらは公開される証拠の観察条件であり、本号で試験を実行したものではない。[R02 R03 S01 S03 S05]
#1～6か月：製品・地域・期間を固定した認定良品、顧客受入れ、在庫、未充足注文とlead timeが揃うか。HBM世代、package方式・面積、基板grade、光速度、test品質、rack電力・冷却条件を固定する。安全対策もproductionでのcoverage、失敗・再試行、人の時間、compute・storage・networkを同じ成功仕事へ配賦する。
#6～36か月：設計・設備・電源計画が、認定、接続、commissioningを経てproduction workloadへ進むか。効率と監督の改善が単位仕事費用、価格、実需要、再投資へどう伝わったかを観測する。計画MWを稼働IT MWへ、費用倍率をGPU需要倍率へ先に変換しない。
#反証：監視を迂回する経路や非人間の承認が残るなら、全経路の保証は成立しない。認定出荷と納期の改善で未充足注文が減れば、その品種の制約を弱める。新証拠は該当するmodel・品種・地域に限って適用する。
#資料と観測時計
#日付は特記以外2026年。取得時計は資料を読めた時刻で、実験・稼働・go-liveの時刻ではない。GitHub更新表示、code revision、merge、release、実験、deploymentを区別する。以前の速報は、今回の原文再取得がない場合に前報の観測として継承する。以下のURLは資料を特定するものであり、本文で示した範囲を超える新規取得を意味しない。
#[R01] vLLM #61242。10月13日13時JSTの既報観測。PR公開12日16:13:26 UTC。13日00:20:45 UTCのbody更新で未公開最適化の集計が加わったという記録を継承。公開head 8b79b87d。実験の正確な開始・終了、matched node、修正版SHAはUnknown。現在の原文再取得はしていない。 https://github.com/vllm-project/vllm/pull/61242
#[R02] SGLang #43935と#43948。13時速報の既報観測。#43935の公開logはbfc2b18e97aを実行、log内時刻13日01:24:07 UTC、merge 01:36:12 UTC。#43948は02:31:11 UTCにmerge。今回、元logやimmutable codeを再検証していない。実験全区間と現行productionはUnknown。 https://github.com/sgl-project/sglang/pull/43935 https://github.com/sgl-project/sglang/actions/runs/38322945648/job/115055080029 https://github.com/sgl-project/sglang/pull/43948
#[R03] SGLang #43997／#43998。13日17時JSTの既報観測。PRは13日07:34:04 UTCにclosed unmerged、issueは07:34:33 UTCにclosedと当時確認。14日09:03 JST頃、数値訂正のためPR本文の追加host memory記述を再確認した（取得の秒精度は未確認）。表示更新は13日07:34:04 UTC。著者実験の正確な時計、clean buildとdeploymentはUnknown。訂正確認は独立した実験再実行ではない。 https://github.com/sgl-project/sglang/issues/43997 https://github.com/sgl-project/sglang/pull/43998
#[R04] SGLang #44081。14日01時JSTの既報観測。head 8017ebaef820e76cbc1a202c5a80b803043799ac、当時unmerged。nightly overlayの著者実験とCPU／mock検証を分離。実験日時、current deploymentはUnknown。今回の原文再取得なし。 https://github.com/sgl-project/sglang/pull/44081
#[R05] vLLM #61465とcuDNN frontend 1.31.0。PR公開13日17:21:37 UTC。body／head取得23:45:28.119 UTC、discussion 23:45:33.994 UTC。open unmerged、head 3c4f80fdを維持し、retry／queue記述から終端CI成功は確認していない。上流releaseは10月8日公表という05時既報を継承。上流release／source自体の取得時計はUnknownで、PRの時計を代用しない。著者実験日時、実wheelのend-to-end serving、保持memory、deploymentはUnknown。 https://github.com/vllm-project/vllm/pull/61465 https://github.com/NVIDIA/cudnn-frontend/releases/tag/v1.31.0
#[R06] vLLM #61488。PR公開13日19:18:51 UTC、native更新20:21:55 UTC。body／head取得23:45:29.672 UTC、discussion 23:45:35.122 UTC。draft／open／unmerged、head 5522721a。default flagのcodeは20:38:10.918 UTC、schedulerは20:37:44.224 UTCの取得で、後のPR確認がcodeや実行の時計を進めることはない。著者実験日時とdeploymentはUnknown。 https://github.com/vllm-project/vllm/pull/61488 https://github.com/vllm-project/vllm/blob/5522721ae2f08f8753d755e557c48169f5ff59a4/vllm/config/kv_transfer.py https://github.com/vllm-project/vllm/blob/5522721ae2f08f8753d755e557c48169f5ff59a4/vllm/distributed/kv_transfer/kv_checksum/scheduler.py
#[R07] vLLM #61499／#61500。公開13日21:14:23／21:14:31 UTC、native更新21:41:03／21:42:02 UTC。body取得23:45:22.759／23:45:24.071 UTC。各head aab2cd2f／df2c1c91の静的code取得は22:37:45.463／22:37:46.686 UTC。15:56、17:17、20:15、20:16等の運用時計は著者記述。過去startup patchと現在headの同一性、raw運用log、exposure分母は未確認。 https://github.com/vllm-project/vllm/pull/61499 https://github.com/vllm-project/vllm/pull/61500 https://github.com/vllm-project/vllm/blob/aab2cd2fc2eec392820724160576f24ab651d1bc/vllm/distributed/kv_transfer/kv_connector/v1/nixl/base_worker.py#L2890-L2945 https://github.com/vllm-project/vllm/blob/df2c1c917223f1f35a846357abee70afbc889dfc/vllm/distributed/kv_transfer/kv_connector/v1/nixl/base_worker.py#L3605-L3680
#[R08] vLLM #61509。公開13日22:30:23 UTC、native更新22:50:33 UTC。body取得23:45:25.469 UTC、head baf35360のcode取得22:37:44.173 UTC。draft／unmerged。08時確認の本文差はlint関連comment削除で、新実験ではない。今回の選択比較は同じ。著者benchmark日時、全revision、quality／SLOとdeploymentはUnknown。 https://github.com/vllm-project/vllm/pull/61509 https://github.com/vllm-project/vllm/blob/baf35360b39419ff2370a199741152d7f437aa8b/vllm/v1/worker/gpu/model_runner.py#L1060-L1130
#[R09] SGLang #44118。公開13日20:28:59 UTC、P/D追加baselineのnative更新21:14:45 UTC、aggregated比較の追記23:17:38 UTC。body取得23:45:26.891 UTC、comments取得23:45:33.068 UTC。head bf292ffe、draft／unmerged。以前のcode取得時計は更新していない。実験のexact時計はUnknown。 https://github.com/sgl-project/sglang/pull/44118
#[S01] METRのblocking action monitor note。公開9月27日、実験日時Unknown。Appendix Cの選択確認13日23:45:31.117 UTC。実装・human-only承認・coverageの選択確認は23:27:35.959 UTCで、費用の再確認により全実装を再検証したとはしない。予備的な著者推計で、独立対照やGPU時間の実績ではない。 https://metr.org/notes/2026-09-27-implementing-a-basic-blocking-action-monitor/
#[S02] Anthropicの自己複製研究。公開10月12日、詳細実験日時Unknown。13日21時JSTの速報で採用、当時のarticle取得は13日11:54:15.946 UTC。既報の観測を継承し、今回の原文再取得なし。制御評価と別の物理実機デモを区別する。 https://www.anthropic.com/research/self-replicating-ai
#[S03] Anthropicのunintended model actionsに関する説明。公開10月9日、表示訂正10月12日。選択記述の取得13日23:45:31.265 UTC。事業者の判断・既知case報告と、独立した完了・有効性を区別する。 https://www.anthropic.com/news/investigating-unintended-model-actions
#[S04] AISIのfrontier AI技術実務agenda。選択取得13日23:45:32.279 UTC。公開の正確な時計は今回未確認。voluntary agendaであり、全将来行動の保証や新しい法的義務ではない。 https://www.aisi.gov.uk/blog/towards-technical-best-practice-for-frontier-ai-development
#[S05] NVIDIA OpenShellのsecurity best practices。選択取得13日23:45:32.762 UTC。公開・更新・実導入時計はUnknown。request制限とaudit／enforceの説明に範囲を限定する。 https://docs.nvidia.com/openshell/latest/security/best-practices
#[S06] 英国のAI risk防御方針とECのAI generated content code。英国公表10月12日、EC表示更新10月12日。選択取得13日23:45:31.212／23:45:31.062 UTC。英国の具体的義務の採択・発効は未確認。ECの既存法的義務と任意codeを分離する。 https://www.gov.uk/government/news/britain-steps-up-national-defences-against-growing-ai-risks https://digital-strategy.ec.europa.eu/en/policies/code-practice-ai-generated-content
#[P01] TeraWulf Muskie拡張のSEC exhibit。公開10月5日、取得13日22:36:12.502 UTC。2028／2029年の目標と承認・建設条件を確認。実commissioning、利用可能なIT MW、workload開始日はUnknown。 https://investors.terawulf.com/sec-filings/all-sec-filings/content/0001628280-26-064757/muskieexpansionpr.htm
#[I01] DOEの202(c) orders一覧と202-26-50 landing。署名日10月12日、operative日付10月13～16日。最終の一覧取得13日23:45:31.064 UTC、landing取得23:45:31.175 UTC。署名済み文書とExhibit Aは本号で再取得していない。実dispatch、増分MW、運用開始時計はUnknown。 https://www.energy.gov/ceser/2026-doe-202c-orders https://www.energy.gov/ceser/federal-power-act-section-202c-pjm-interconnection-llc-pjm-order-no-202-26-50
#[I02] PJM #105555／#105557。選択取得13日23:45:31.263／23:45:31.044 UTC。表示effective startはそれぞれ10月12日14:49／15:49で、表示timezoneは今回未確認。公表時計、非drill区分、実起動・発電量はUnknown。 https://emergencyprocedures.pjm.com/ep/pages/viewposting.jsf?id=105555 https://emergencyprocedures.pjm.com/ep/pages/viewposting.jsf?id=105557
#[I03] PJM #105556。最後の確認13日20:35:12.801 UTC。20:54:20.126～20:54:20.739 UTCの締め確認は技術的失敗で、origin HTTP／access状態は未開示。無変化・停止・撤回の証拠ではない。 https://emergencyprocedures.pjm.com/ep/pages/viewposting.jsf?id=105556
#[I04] ERCOT October operations。最新選択rowのnative表示は13日00:48:11、timezone未開示。取得13日23:45:31.406 UTC。10月12日の450MW超の突発的発電損失についての閾値付き報告で、他の障害や供給追加は示さない。 https://www.ercot.com/services/comm/mkt_notices/opsmessages/index.html?m=10&y=2026
#観測範囲の留保
#締切前の最終選択確認は14日08:45:35.122 JST（13日23:45:35.122 UTC）まで。最後はvLLM #61488のdiscussionだけに対応し、本文・code・運用の一括確認時刻ではない。発行時刻09時まで14分24.878秒の観測間隔が残る。METRの実装確認は08:27:35.959 JST、Appendix Cは08:45:31.117 JSTであり、資料ごとの時計を用いる。最終選択比較で追加の実質変更は確認していない。
#取得できなかった資料、今回未選択の資料、元の記録を再検証できない以前の観測から、不存在・無変化・撤回・稼働停止を推定しない。本文中の因果関係と需要への含意は、事実そのものではなく明示した条件に依存する分析である。
#数値訂正
#訂正（10月14日09:03 JST）：#43998の追加host memoryを約14 GB／rankとしたが、正しくは、この98,368-tokenのhost tierで著者報告約0.14 GB／rank。100倍の過大記載を訂正した。PR本文の訂正確認は本号の対象期間・通常の観測締切後に行ったもので、実験の独立再実行ではない。訂正に用いたPR本文 [R03]
#