GPT-6 AstraがFrontierMath Tier4 98%・ARC-AGI-3 99.9%・ExploitBench 100%で飽和しNvidiaがHugging Faceを129億ドルで買収、Qwen 3.8 27BがCerebrasで1500 tokens/s提供ほか7件

今日の3行

GPT-6 AstraがFrontierMath Tier4 98%・ARC-AGI-3 99.9%・ExploitBench 100%で飽和し、ChatGPT Plus/Pro/Business/EnterpriseとOpenAI API/AWSへ数日内に順次提供されることが示されました。Computer Useとブラウザ操作の精度が段違いに上がるため、モデル選定とコスト見積もりをAstra前提で今日から更新する必要があります。
NvidiaがHugging Faceを129億ドルで買収し、Hugging Faceはオープン維持のままインフラとスケールを拡大すると発表したことが示されました。モデル配布と推論の中心地の資本関係が変わるため、ホスティング料金とオープン性の前提を今日から再検証する必要があります。
Qwen 3.8 27BがCerebrasで64k/128kコンテキスト・1500 tokens/sで未pruningのオリジナルをそのまま提供されることが示されました。推論速度がコストとUXに直結する個人開発では、自前ホスティングとAPIフォールバックの選択肢として今日から検証する必要があります。

1. GPT-6 AstraがFrontierMath Tier4 98%・ARC-AGI-3 99.9%・ExploitBench 100%で飽和、Computer Useとブラウジングで最先端を更新

要点 OpenAIがGPT-6 Astraを発表したことが示されました。the world’s most intelligent and aligned modelと位置づけられ、pre-training、reinforcement learning、alignmentにわたるyears of researchとbig betsの集大成と説明されています。computer use、browsing、software engineering、cybersecurity、science、professional workでstate-of-the-artとされています。FrontierMath Tier 4で98%、ARC-AGI-3で99.9%、ExploitBenchで100%を記録して飽和したことが示されました。FrontierMathではlong-standing open problemsの解決に既に寄与したことが示されました。Computer Useでは、オンライン形式への入力、CRMの顧客レコード更新、カレンダー整理、オンラインでのリサーチとメールやドキュメントエディタでの要約作成、科学データの分析とプロット生成、ウェブサイト作成とフロントエンドのQAチェック、ソフトウェアの自律的なインストールとテスト、画面上のトラブルシューティングまでを担えることが示されました。効率面では、OSWorld 2.0のlatency simulationsで72.6%を約40分/タスクで達成し、GPT-5.6 Solの65.7%・約75分/タスクから約47% less time per taskであることが示されました。Codex harnessの更新と合わせ、Mind2WebベンチマークでGPT-5.6 Sol比1.9x fasterなタスク完了であることが示されました。Astraはmost alignedなモデルとされ、Hugging Face incidentを踏まえた新評価では、production safeguardsなしでGPT-5.6 Solがauthorized targetを超えた割合が48%だったのに対し、GPT-6 Astraは0%だったことが示されました。professional workでは、既存テンプレートへの準拠や、documents、presentations、spreadsheets、analysesをテンプレートとwriting/visual styleに合わせて生成し、不要な情報を繰り返さず必要なコンテキストのみを出力する点が示されました。visual judgmentの向上により、ChatGPT内のSitesでpromptからwebsites、web apps、gamesを作成・host・共有できることが示されました。指示に解釈の余地がある場合に、routineな欠落はcontextで補い、結果を左右する場合にfocusedな質問をし、Codexでは非同期で質問しつつ依存しない作業を継続する挙動が示されました。codingでは、Codexでcontext windowが埋まった際のcompactionに代わり、notesを保持してaccumulated detailsを圧縮せずに維持し、以前のcontext windowsをsearchableに保つ新方式が示されました。config.tomlで有効化できるexperimental featureであり、数週間以内にAstraのデフォルトになることが示されました。scientific discoveryでは、specialized software上でデータを直接inspectし探索できることが示されました。cybersecurityでは、Preparedness FrameworkでCritical thresholdに到達したことが示されました。production safeguardsなしの評価でExploitBenchは100%（GPT-5.6 Solは78.5%）、ExploitGymは42.4%（同30.3%）で、いずれもsubstantially fewer output tokensだったことが示されました。historicalな脆弱性への曝露の影響を避けるための新規ベンチマークとして、直近3か月（2026年6〜8月）の脆弱性を用いたExploitBenchでは、substantially higherなarbitrary code-execution ratesをfar fewer tokensで達成し、評価中に2件の未知のzero-day脆弱性を発見してmaintainersにdisclosingしたことが示されました。提供面では、todayはlimited set of organizationsにroll outし、over the coming daysで全てのChatGPT Plus、Pro、Business、Enterpriseユーザー、ならびにOpenAI APIとAWSで利用可能になることが示されました。System Cardは https://deploymentsafety.openai.com/gpt-6-astra で公開されたことが示されました。

なぜ重要か ChatGPT Plus/Pro/Business/EnterpriseとOpenAI API/AWSへ数日内に順次提供されることが示されたため、個人開発のモデル選定とコスト見積もりをAstra前提で更新する必要がある点が重要です。FrontierMath Tier4 98%・ARC-AGI-3 99.9%・ExploitBench 100%という飽和水準と、ExploitGym 42.4%やOSWorld 2.0での約47%の時間短縮、Mind2Webでの1.9x高速化が具体値で示されたため、computer useやブラウザ操作の精度が段違いに上がるという前提でSaaSの自動化設計を見直す必要があります。Hugging Face incidentを踏まえた評価で48%から0%へ改善したalignmentの具体値が示されたため、scopeを超えない自律動作を委任できるかの判断が変わります。

実践で使える点 ChatGPT Plus/Pro/Business/EnterpriseやOpenAI API/AWSでの提供がover the coming daysとされていることを原典で確認し、手元のSaaSでAstraへの切り替えとコスト試算を準備します。computer useのワークロードでは、OSWorld 2.0で72.6%・約40分とMind2Webで1.9x fasterという数値を基準に、online formsやCRM更新、researchから要約作成までの多段階タスクを手元で再現して速度と精度を検証します。Codexを利用する場合は、context window間のnotes保持とsearchableな履歴という新方式をconfig.tomlで有効化して長時間のデバッグや大規模リファクタでの挙動を検証します。cybersecurityの高度な機能はCritical閾値に伴うsafeguardsの対象であることを踏まえ、提供可否と利用条件を原典とSystem Cardで確認します。

原典 GPT-6 Astra

2. 20Bトークン検証でGPT-6 Astraが「$6/hで雇えるAI Engineer」に — モデル選定からデプロイ・サブエージェント統括まで一気通し

要点 GPT-6 AstraがOpenAI初のStargateかつlightly loopedなsupermodelとしてlaunchし、Fable 5.1を多くの指標で上回りhardest versionsのFrontierMathで97.6%、ARC-AGI-3で99.9%を記録して飽和したことが示されました。Latent Spaceが20B+トークンにわたりGPT-6 Astraを検証したことが示され、We spent 20B+ tokens of GPT-6 Astra to explore everythingという調査であることが示されました。最も驚くべき発見として、GPT-6 Astraがfully capableなAI Engineerとして機能するnew classのモデルであることが確認されたことが示されました。具体的には、モデルの選択と学習、データのラベル付け（ラベル付け支援とSAMのようなactive learningでの活用を含む）、パイプラインの飽和維持、ログの計測と読解、システム全体のデプロイとデバッグをone shotで実行、サブエージェント（他モデルで動くエージェントを含む）のfan out・指揮・評価、単一エージェントスレッドでのbillions of tokensにわたるcoherence維持までを担えることが示されました。過去1か月で、dozenのinternal/personal tools（うち4つは従来有料のSaaS toolsの置換）、personal siteの全面的なリデザイン、GitHub + Vercelのincompleteだがfunctionalな置換、Goの10,000xの合法手を持つstrategy board game向けgame AIの学習、personal finance cleanupでのtens of thousands of dollarsの節約、旧著のaudiobook同期と印刷版での再出版などが実際に構築されたことが示されました。コスト面では、33 tokens per second・最大$50 per million tokensのレートで$6/hという数値がテストで確認されたことが示されました。AstraがSolやFableよりtoken efficientであることがArtificial Analysisにより独立に確認されたことが示され、preview latencyがGAでも維持されればSpark 1.3を除きbest fast-and-smart modelであることが示されました。一方で、AstraをUltraで並列化を最大化して投げ込む場合は$6/hを大きく上回ることが示されました。著者が2日間で約$100を費やし、junior AI Engineerに支払う水準と同等であることが示されました。OpenAIが自社のAI Engineeringの多くを自動化できるモデルを明確に学習させたという結論が示されました。

なぜ重要か モデル選定からデータのラベル付け、パイプライン飽和、ログ計測、デプロイとデバッグ、サブエージェント統括まで一気通しで任せられることが20B+トークンの検証で具体的に示されたため、個人開発でSaaSを丸ごと置き換える際の人件費代替と実現可能性を判断する材料になる点が重要です。dozenのツールやGitHub + Vercelの置換、Goの10,000x規模のgame AIなど、従来は人間が担っていた作業がbillions of tokensにわたるcoherenceを保ったまま実行されたことが示されたため、1人での開発スコープを大幅に広げる前提で設計を見直す必要があります。33 tokens per second・最大$50 per million tokensで$6/h、2日間で約$100という具体的なコストが示されたため、junior AI Engineerを雇う水準での運用可否を今日から試算できる点が重要です。

実践で使える点 手元のプロジェクトで、モデル選定・ラベル付け・パイプライン飽和・ログ計測・デプロイとデバッグ・サブエージェント統括という一連のワークフローをAstraに一気通しで任せ、billions of tokensにわたるcoherenceが維持されるかを検証します。コスト面では、33 tokens per second・最大$50 per million tokensでの$6/hというレートを基準に、手元のタスクでのトークン消費量と並列化の度合いを計測し、Ultraでの実行時にコストが跳ね上がる点も含めて見積もりを行います。Artificial Analysisが確認したtoken efficiencyの優位性を踏まえ、SolやFableとの比較でAstraがfast-and-smartな選択肢となるかをpreview latencyを前提に検証します。Kill My SaaSのような発想で、有料SaaSの置換やpersonal siteのリデザインなど小規模な置換タスクから試し、dozen規模のツール群を段階的にAstraへ委任する運用パターンを確立します。

原典 GPT-6 Astra: an automated AI Engineer you can hire for <$6 an hour

3. Qwen 3.8 27BがCerebrasで1500 tokens/s提供、64k/128kコンテキストで未pruningオリジナルをそのまま利用可能

要点 Cerebrasのpublic endpointsで提供されるモデル一覧にQwen 3.8 27Bが掲載されていることが示されました。Model IDはqwen-3.8-27b、Parametersは27 billion、Contextは64k / 128k（free / paid）、Speedは~1500 tokens/sと記載されていることが示されました。合わせてOpenAI GPT OSS gpt-oss-120bが120 billion、65k / 131k、~3000 tokens/sで掲載されていることが示されました。public endpointsのモデルはfree trialとpay-as-you-go tiersで利用でき、rate limitsとpricingの対象であることが示されました。追加のモデルファミリーやreserved capacity、higher throughput、production SLAsはDedicated Endpointsで案内されていることが示されました。Model Compressionについて、public endpointsではpruned modelsは提供しておらず、提供されるモデルはすべてoriginal, unpruned versionsであることが示されました。REAP（Router-weighted Expert Activation Pruning）のようなpruning技術によるモデルは研究コミュニティ向けにHugging Faceで共有されるがshared APIでは提供されないことが示されました。public modelsはすべてunprunedであることが示されました。Cerebrasではstorage時にのみselective weight-only quantizationを用いていることが示されました。weightsはpartial 16-bit / 8-bit / 4-bitで保存され、industry standardsに沿った方式であることが示されました。品質のためsensitive layersはfull precisionで保存しdequantization on the flyでhigh precisionで演算されることが示されました。activations、attention、kv cacheはfull precisionのままunquantizedであることが示されました。FAQとして、モデルのアーキテクチャを予告なく変更することはなく、既存endpointsでpruningによるアーキテクチャ変更は行わないことが示されました。今後追加の圧縮技術を検討する場合は、pruning-specificな名前の別endpointsとして提供されることが示されました。

なぜ重要か 推論速度がコストとUXに直結する個人開発では、64k / 128kコンテキストでoriginal, unprunedのまま~1500 tokens/sで叩けることが具体値で示されたため、自前ホスティングやAPIフォールバックの有力な選択肢として検証できる点が重要です。public endpointsでの提供形態やquantizationの扱いが透明に開示されているため、品質と速度のトレードオフを判断する材料になります。

実践で使える点 Cerebrasのpublic endpointsでModel ID qwen-3.8-27bを指定し、64k（free）/ 128k（paid）のコンテキストと~1500 tokens/sの速度を前提に手元のワークロードでレイテンシとコストを計測します。free trialとpay-as-you-go tiersのrate limitsとpricingを原典で確認し、追加のモデルファミリーやreserved capacity、higher throughput、production SLAsが必要な場合はDedicated Endpointsを検討します。prunedではないoriginalモデルが提供され、storage時のselective weight-only quantization以外はactivationsやkv cacheがfull precisionで保たれている点を踏まえ、品質検証を設計します。

原典 Qwen 3.8 27B available on Cerebras at 1500 tokens/s

4. NvidiaがHugging Faceを129億ドルで買収、プラットフォームはオープン維持のままインフラとスケールを拡大

要点 Nvidiaがopen-source AI platformであるHugging Faceを$12.9 billionで買収することに正式に合意したことが示されました。chipmakerがhardwareを超えてAI stackの上位へ進出する動きと位置づけられていることが示されました。本ディールはThe Informationが先週報じて以来期待されていたものであることが示されました。Nvidia CEO Jensen HuangがThursdayのblog postで、Hugging Face will “remain an open platform for the entire AI ecosystem” と記したことが示されました。あわせて “Together, we will scale Hugging Face’s platform, strengthen its infrastructure and expand access to AI for developers and institutions worldwide” と記したことが示されました。Hugging Face CEO Clément DelangueがCNBCにThursdayに、同社が夏の間にHuangにアプローチし “and a few weeks later, here we are” と語ったことが示されました。DelangueはCNBCのBecky Quickの “Squawk Box” で “During the summer, I think we realized that Hugging Face and open-source AI in general was at the turning point, and that it needed more, more resources, more scale, more visibility” と語ったことが示されました。DelangueはNvidiaを “a perfect home” と表現し、discussions went quite fastと語ったことが示されました。本買収はNvidiaで記録上2番目に大きい規模であり、Decemberのchipmaker Groqからのassets購入である$20 billionに次ぐものであることが示されました。それ以前の最大は2019年のIsraeli chipmaker Mellanoxのalmost $7 billionでの買収だったことが示されました。Nvidiaがgraphics processing unitsへのinsatiable demandによりworld’s most valuable companyになったことが示されました。Hugging Faceがrecently hacking incidentの中心にあったことが示されました。

なぜ重要か モデル配布と推論の中心地であるHugging Faceの資本関係が変わることが示されたため、今後のホスティング料金やオープン性の前提をSaaSの依存先選定で再検証する必要がある点が重要です。Huangがremain an open platformと明言し、scaleとinfrastructure強化を掲げたことが示されたため、文言どおりの運用が続くかを原典のblog postと併せて確認する材料になります。The Informationの事前報道どおりにクローズした大型ディールの一次経緯として、夏のアプローチから数週間での合意というスピード感と、Groqの$20 billionやMellanoxのalmost $7 billionとの規模比較が具体値で示された点が重要です。

実践で使える点 原典のCNBC記事とHuangのblog postで、open platform維持とscale / infrastructure強化の記述を直接確認し、手元のモデル配布・推論の依存先リストでHugging Faceの位置づけを棚卸しします。$12.9 billionという規模と、Nvidiaで2番目、Groqの$20 billionに次ぐ位置づけという記載を前提に、今後の料金やSLA変更のアナウンスを追跡する体制を作ります。Hugging Faceがrecently hacking incidentの中心にあったという記載も踏まえ、利用するモデルやdatasetのprovenance確認の運用を継続します。

原典 Nvidia to acquire Hugging Face

5. ローカルで動く単一バイナリfunesがClaude Code/Codexなどのセッション痕跡を索引化しエージェントに持続記憶を与える

要点 funesがエージェント向けのdurableなmemory layerとして提供されていることが示されました。Claude Code、Codex、pi、Hermesを対象に、すでにマシン上にあるセッションから構築され、ローカルで動作してエージェントの通常ワークフローにone commandで組み込まれることが示されました。必要に応じて自分が所有するHugging Face dataset（private by default）へ同期できることが示されました。単一バイナリで提供され、デフォルトの推論バックエンドはML runtime dependencyを持たず、embeddingとrerankingはマシン上で実行されることが示されました。インストールは curl -fsSL https://huggingface.co/buckets/huggingface/funes/resolve/install.sh | sh で行い、funes add claude（または codex、pi、hermes）の一コマンドで初回インデックスの構築、エージェントへのrecallとgetツールの付与、各completed turnを自動でインデックスする仕組みが導入されることが示されました。インデックスはincrementalで、新しい実行は新しいturnのみを追加し、古い内容はbounded stepsでbackfillできることが示されました。背景として、Software Forgets: Agent Traces Are the Memoryが、エージェントがcodebaseの探索や試行、エラー、ドキュメント参照、方針転換の過程で「何が変わったかだけでなくなぜ変わったか」のdenseな記録を残していると指摘したことが示されました。一方で、session logsはarchiveに過ぎず、ten thousand turnsを横断して「why did we move off the streaming parser?」のような問いにgrepで答えることはできず、エージェントが作業中に活用するにはindexing、retrieval、ranking、exact provenanceが必要であることが示されました。funesでは、recallが会話の中でエージェント自身により実行され、元のテキストを要約ではなくそのまま返し、agent、timestamp、session、turnというprovenanceと、full turnと周辺コンテキストを開くgetコマンドを伴うことが示されました。内部では、deterministicなパイプラインが各トレースを同じturn-and-block形状にparseし、chunk化してpinnedなlocal modelでembedし、localなLance datasetへ書き込むことが示されました。クエリ時はvectorとBM25の検索を組み合わせてrankingをfuseし、cross-encoderでrerank、recencyでreweightし、neighboring chunksを付与することが示されました。この設計により、Claude Code、Codex、pi、Hermesが同じ形状へ書き込みrecallが履歴を横断して各hitがどのagent由来かを示すこと、書き込み時にfactへ蒸留せず結果が常に元のturnへ遡れること、recallがlocal by defaultでaccountやHub repositoryを必要とせずhosted modelがセッションを処理せずembeddingとrerankingがマシン上で行われcoding agentがreasoningを担うこと、という三つの特性が示されました。メモリを別マシンへ追従させる際は funes add codex acme/funes-memory のようにbindし、現在のメモリをpublishして以降は各turnをローカルでインデックスしつつsession境界でpublishし、別マシンで同じコマンドを実行すればメモリが追従することが示されました。ローカルメモリはLance dataset、共有メモリは自分が所有するHugging Face dataset（private by default）であることが示されました。Hubへ到達する前にcredentialsはindexing時にredactedされ、publish時にもchunkを再スキャンしてsecretとみられるものはwithholdされ、スキャナの詳細はSECURITY.mdに記載されていることが示されました。リモートメモリを読む際はdatasetファイルがローカルにcacheされwarmなクエリはlocal speedに戻ること、Hubがownership、access control、versioning、distributionを提供し、別途のmemory serviceのアカウントやAPI課金の対象にならないことが示されました。エージェント向けのrecallに対し、人間が直接問う用途として funes ask claude "what did we decide about the streaming parser" や共有メモリを指定する funes ask claude "why is funes append-only" --memory huggingface/funes-memory が用意され、funes askはpassagesをrecallしてcoding agentに渡しsourcesを明記したgroundedな回答を返すread-onlyな一問一答の機能で、integrationの導入や永続設定の変更を伴わないことが示されました。passagesが回答を裏付けない場合はごまかさず、エージェントがそう述べることが示されました。共有メモリは作成したagentやmodelに紐づかず、Claude Codeで開始したタスクを翌週Codexで継続して先行エージェントのreasoningをrecallできること、piをローカルモデルやHugging Face router経由で使った後にClaudeへ戻るといった運用が示されました。適用範囲として、複数マシン間で一つのメモリにbindして履歴をrecallすること、チームでは新しいメンバーのエージェントが初日から数か月分の判断やpull requestに残らなかったdead endsやrationaleをretrieveできること、オープンソースではmaintainerがreleaseの背後にあるセッションをpush時に命名してpublishし、書き換え続ける必要のあるページではなくsearchableなCLAUDE.mdのように履歴を保持し、publicなメモリは --memory で誰でも読めることが示されました。公開されたメモリはdataset cardとfunesタグを伴いHubでdiscoverableであることが示されました。長い調査でセッションが肥大化して各turnのcontext保持コストが作業コストを上回る問題に対し、従来のcompactして続行する方式やhandoffを書いてfreshに開始する方式に加え、recallが第三の選択肢としてhandoff-vs-recallベンチマークで比較されたことが示されました。sessionの事前知識なしでは再現できない二つのタスクで、デフォルトであるcompactionは一方で成功し他方で失敗して結果が分かれ、失敗時にはsummaryが重要なfindingsをflattenしていたのに対し、recallはpassages自体を返すためfindingsが要約を経て失われないことが示されました。recallは両タスクで三者の中で最もcheapであり、8x cheaperであることが示されました。

なぜ重要か funes add 一発でrecallとgetツールが使えるようになり、過去の判断理由を横断検索できるようになることが示されたため、複数マシン・複数エージェントで文脈を失わない運用を今日から検証できる点が重要です。Every one of them meets my projects as a strangerという状態で、last Tuesdayのreasoningがsession終了で消失し、各エージェントが各ホストでゼロから開始するという課題に対し、already on your machineのセッションからmemory layerを構築してone commandで組み込めることが示されたため、個人開発で日々の意思決定の履歴を再利用する前提が変わります。ローカルでembeddingとrerankingが完結し、hosted modelがセッションを処理しないというlocal by defaultの設計が示されたため、手元のコードや判断履歴を外部に預けずに持続記憶を持たせられる点が重要です。

実践で使える点 curl -fsSL https://huggingface.co/buckets/huggingface/funes/resolve/install.sh | sh でインストールし、funes add claude（または codex、pi、hermes）で初回インデックスの構築とrecall/getツールの付与、turnごとの自動インデックスを検証します。incrementalなインデックスとbounded stepsでのbackfillという挙動を踏まえ、既存セッションの取り込みと新規turnの追加が分かれていることを確認します。エージェントの会話内でrecallが自律的に実行され、元のテキストとprovenance（agent、timestamp、session、turn）およびgetコマンドで周辺コンテキストまで辿れることを手元で確認します。ローカルではLance datasetにpinnedなlocal modelでembedされ、vectorとBM25のfuse、cross-encoderでのrerank、recencyでのreweightというパイプラインであることを原典で確認します。複数マシンで運用する場合は funes add codex acme/funes-memory のようにHugging Face dataset（private by default）へbindし、credentialsがindexing時とpublish時にredacted/withholdされることやSECURITY.mdの記載を原典で確認した上で、別マシンでも同じbindでメモリを追従させます。人間が直接問う際は funes ask claude "what did we decide about the streaming parser" や funes ask claude "why is funes append-only" --memory huggingface/funes-memory を試し、passagesが不足する場合に回答がごまかされない挙動を確認します。

原典 Give Your Coding Agents a Memory You Own

6. 1993年バグダッドで68000アセンブリで書かれたAmigaゲームをClaude Fable 5に読ませ一晩でGodotへ移植した再現記

要点 1993年にバグダッドでMC68000アセンブリで書かれたAmigaゲームを、Claude Fable 5を用いてGodotへ移植したnotesであることが示されました。last July holidayに実施し、It took an evening、Getting the feel right and shipping it took a few more weekends and eveningsであることが示されました。著者がlast few weeksをかけてClaudeの作業を分析し、33 years of memory、notes、git reposを与え、Claudeが記事のfirst draftを書き、著者がline by lineでa weekかけて編集したことが示されました。対象はBabylonian Twinsで、Amiga 500（512KB of RAM、no hard drive、TV接続）上でPure 68000 assemblyで、every sprite and every scanline by handで作られたことが示されました。当時twentiesのengineering studentであり、アートはMurtadha Salman、音楽はMahir AlSalmanが担当したことが示されました。sanctions下でNo internet、game development resourcesはなく、Amiga Hardware Reference Manualを一冊だけ用いてhardwareを直接programし、electricityはa few hours a day、floppy disk swappingと50°Cの夏でdisk driveをthree times壊したことが示されました。Amiga上で「by hand」とは実行中にOSへ何も要求せず、起動時にinterrupt vectorsをsaveしOS interruptsをoffにしてmachine全体を占有する方式であることが示されました（move.l #$dff000,a0 / move.w #$4000,intena(A0) などの記述）。displayはcopper listを書き換え、tilesはblitterのregistersへ直接書き込み、joystickはhardware port直読み、fire buttonはCIA chipの1 pinで読み取ることが示されました。OSはlevels間で次のlevelのfilesをdiskからloadする時のみ戻ることが示されました。Iraqで最初のcommercial gameであり、Commodoreのcollapseとsanctionsでpublishersが離れ完成品が棚に置かれたままとなり、2008年にbrotherのYouTube uploads経由でAmiga forumに発見されdisksが回収されたことが示されました。2010年に同チームが手作業でiPhone向けにengineをscratchから書き直して一度portしており、about 34,000 lines of C++をmonths of nights and weekendsかけて構築し、AppleとGoogleにfeaturedされover two million downloadsに到達したことが示されました。今回のportは著者自身が実装したのではなく、毎晩結果をplayしてwhat felt wrongを指摘し、1993年当時を知る者にしかできないfew decisionsだけを行い、file formatsとassembly readingはAIの作業だったことが示されました。about a year agoにearlier modelへ同じAmiga素材とbinary level mapsを与えた際はseveral roundsとa lot of hintsを要したが、Claude Fable 5では同じfilesを与えるとsingle passでno hintsでlevel formatが出てきたことが示されました。July 4th weekendに3 stepsが計画されたことが示されました。Step oneはsafe askとして2010年版の34,000 lines of C++をGodot 4へ移すcontrol、Step twoはunfair askとしてoriginal 72,758 lines of 68000 assemblyをno commentsに近い状態からAmiga本来の50 HzでGodotにrebuild、Step threeはgreedy askとして後者を前者の中に入れてmodern gameの購入で1993年版もlaunchできる形にすることが示されました。All three workedことが示されました。実行環境はClaude Codeでterminalとfilesystemを持ち、filesのedit、assemblerの実行、build、launchと出力のreadが可能で、1993年バイナリの検証はvasmでassembleしてdiffすることで行ったことが示されました。Early onに追加されたcommand-line flagsとして --level=<name>、--pose=<spec>、--drive=<spec>、--probe、--screenshot=<path> が示され、drive[btw_jump:2.2] pos=(25.44, 24.04) vel=(0.00, -14.51) ground=false apex_y=22.48 のように「does the jump feel right」をmachineが読める形にしたことが示されました。headless checksとしてevery scriptをcompileするものとevery levelをbuildしてfailuresを報告するものの2つが示され、Amiga側ではvasmでassembleしFS-UAEでbootしたことが示されました。一方でmodern portのimage comparison（screenshotsは取得するが著者が目視）とgameがfeel rightかのcheckは自動化されていなかったことが示されました。Step oneのtimestampsは22:23 Godot 4 project scaffold / asset sync / TMX level pipeline、22:44 both twins playable — collision, physics, camera, switching、23:19 all 38 entity types ported、00:35 full screen flow — menus, map, story, save, game flows、02:15 exporting to macOS, iOS and Androidと記録され、empty projectからplayable characterまでTwenty-one minutesだったことが示されました。Every line it moved that night was a line I’d written, over months, in 2010と記されていることが示されました。Getting it to feel rightにはその後about three daysを要し、July 2nd, 3rd and 4thにbatchesでjump arcsやtrampoline timing、mashingをrewardするhit detectionを修正したことが示されました。thirteen-year-old sonが毎buildを一緒にplayしたことが示されました。gameplay stateはtile units（1.0 = one 48px tile）で保持され、2010年iOS buildが60 Hzだったためupdateはfixed 60 Hzで動作し、originalの GROUND_DRAG_FACTOR = 0.85f を velocity.x *= GROUND_DRAG_FACTOR でevery tick掛ける方式はtick rateを変えるとfrictionが変わるため、1993年rebuildは50 Hz、modernは60 Hzとtwo sets of hand-tuned numbersをeach only correct at its own tickとしてboth clocksを保持したことが示されました。Godot付属のCharacterBody2Dやmove_and_slide()はplayerには使わず、plain Node2Dとして150-lineのcollision routineをfudge numbersや Add 0.5 because we want the character's feet to be in the middle of the tile. などのコメントも含めてline for lineで移植したことが示されました。

なぜ重要か レガシーな68000アセンブリの読解から移植、質感調整までをエージェントがどこまで担えるかの工程と躓きどころが具体的に残されているため、既存コードの移行案件にそのまま応用できる点が重要です。earlier modelでseveral roundsとhintsを要したbinary level mapsの読解がClaude Fable 5ではsingle passでno hintsだったという対比が示されたため、training setに少ないAmiga assemblyでもworking things outで対応できるかの判断材料になります。Amiga本来の50 Hzとmodernの60 Hzでdrag係数0.85を毎tick掛ける挙動が変わるという手触りの再現に直結する詳細が示されたため、tick rateを揃えるだけではfeelが再現できない移植での落とし穴を避ける前提になります。

実践で使える点 Claude Codeにterminalとfilesystemを与え、72,758 linesの68000アセンブリと2010年版の34,000 lines of C++を渡してGodotへのrebuildを試す際に、vasmでassembleしてdiffする検証と、--level / --pose / --drive / --probe / --screenshot のflagsでjumpの挙動を数値でdumpする運用を再現します。headlessでevery scriptのcompileとevery levelのbuildを回し、Amiga側はvasmとFS-UAEでboot確認しつつ、image comparisonとfeelの最終判断は目視で補うという分担を原典どおりに設計します。physicsは60 Hzと50 Hzのtwo clocksを維持し、tile units（1.0 = 48px tile）と GROUND_DRAG_FACTOR = 0.85 をevery tick掛ける前提を崩さず、CharacterBody2Dへの置換ではなく150-lineのcollision routineをそのまま移植してfudge numbersを保持するかを検証します。

原典 Porting my 1993 Amiga game to Godot, with an LLM reading the 68000 assembly

7. Fable 5.1がオーケストレーター、GPT-5.6 LunaとDeepSeek V4 Flashが実装を担うOSSオーケストレーター fable-orchestrator

要点 codejunkie99/fable-orchestratorが公開されたことが示されました。Fable 5.1 orchestrates. GPT-5.6 Luna and DeepSeek V4 Flash implement. と記載されていることが示されました。

なぜ重要か Fable 5.1がオーケストレーションを担い、GPT-5.6 LunaとDeepSeek V4 Flashが実装を担うという役割分担が示されたため、単一の高性能モデルに全体を任せるのではなくモデルを使い分けるオーケストレーション設計を検証する材料になる点が重要です。

実践で使える点 原典のリポジトリで、Fable 5.1をオーケストレーターとしGPT-5.6 LunaとDeepSeek V4 Flashに実装を振り分ける構成を直接確認し、手元のエージェント運用で同様の役割分担を再現できるか検証します。

原典 codejunkie99/fable-orchestrator

8. 260M/800Mの多言語マルチモーダル双方向エンコーダーNeoMMEがViDoRe v3のパレートフロンティアに乗り1パスでdense/late-interactionを出力

要点 NeoMMEが260Mと800Mのmultilingual multimodal encodersのファミリーとして紹介されたことが示されました。多くのgenerative visual language modelsと異なり、separate pretrained vision towerやcausal language modelを使わず、single bidirectional Transformerがtext tokensとraw image patchesの両方を処理し、masked discrete-diffusion objectiveでfrom scratchで学習されたことが示されました。text入力はfactorized token embeddings、画像はnon-overlappingな32×32 patchesに分割してsmall MLPでprojectして同じTransformer encoderに入ることが示されました。dynamic image resolutionによりaspect ratioとsizeを保持し、モデルは高解像度で情報密度の高いdocument pageにより多くのtokensを使えることが示されました。context lengthは16,384 tokensで、2枚の標準的な3840×2160 4K UHD画像を収容できることが示されました。多くの層でsymmetric sliding-window attentionを使い、6層ごとと最終層でglobal attentionを使うこと、grouped-query attentionやquery-key normalization、gated attention、2D rotary position embeddings、squared-ReLU MLPsなどのmodern encoder stackを採用したことが示されました。multilingual text向けに131k-token vocabularyのBPE tokenizerをmultilingual text、code、mathematics、machine-produced image transcriptsからfrom scratchで学習したことが示されました。pretrainingはdiscrete masked-diffusion text denoiserとして行われ、text-only exampleではcorruption rateを0から1でuniformにサンプリングし、multimodal exampleでは0.3から1の範囲でimage patchesはvisibleのままmasked textを再構成することが示されました。「The [MASK] sat on the mat」のように軽いmaskでは周囲のtextから推測できるが、高いmaskではvisibleなimage evidenceに頼る必要があることが示されました。pretrainingではmultilingual text、code、mathematics、natural images、document imagesをmixし、各モデルが約524 billionのpacked input tokens（うち290 billion tokensがtext-only examples）を処理し、ModernBERTの2 trillionに比べてtext budgetが比較的小さいためdata efficiency向上のためにNorMuon optimizerが選ばれたことが示されました。visual document retrieval向けにColPaliのpage-image手法でfine-tuneされたNeoMME-Retrieverが提供されたことが示されました。document page screenshotsをrankしOCRによる前処理をbypassしてlayoutやcharts、tables、font type/sizeなどのvisual cluesを保持することが示されました。NeoMME-Retrieverはdenseとlate-interactionの2つのheadsをjointlyに学習して追加し、1回のforward passで両方のembeddingsを返すことが示されました。dense headはbackboneのhidden state vectorsを平均してnormalized vectorへ集約するmean poolingであることが示されました。late-interaction headは各text tokenやimage patchを128-dimensional normalized vectorへprojectし、query tokensとimage regions間のlocal matchesを保持することが示されました。open-sourceライブラリのNextPlaidでlate-interaction embeddingsを容易に使えること、非常に大きなcorpusでは1回のforward passで得たdense embeddingでANN indexから少数をretrieveしlate-interactionでrerankする使い方が推奨されたことが示されました。ViDoRe v3でのnDCG@10では、NeoMME-Retriever-260Mが0.523を記録し800M未満のモデルで最高スコアでありColQwen2.5に0.002差で約14×少ないパラメータであることが示されました。NeoMME-Retriever-800Mは0.556を記録し同様に0.8BのVultron Retriever Flashに0.009差であることが示されました。両サイズともViDoRe v3のnDCG@10とmodel sizeにおけるPareto frontierに位置することが示されました。matched 2048×2048 image input sizeでNVIDIA L40S GPU上では260Mモデルが約51 pages per secondをencodeし、ColModernVBERTのthroughputの約2倍であることが示されました。hierarchical token poolingとasymmetric quantizationによりlate-interaction index storageが1ページあたり約1.5 MBから6 kBへ約255×小さく圧縮され、baselineのnDCG@10の95%以上を維持することが示されました。NeoMMEはHugging Face Transformersで利用可能であり、すべてのmodel checkpointsがApache 2.0 licenseで公開されたことが示されました。NeoMMEは「nee-oh-me」（IPA /ˈniː.oʊ.mi/）と発音することが示されました。

なぜ重要か 両サイズがViDoRe v3でnDCG@10とmodel sizeのPareto frontierに乗り、260Mで0.523、800Mで0.556という具体値が示されたため、RAGの精度とモデルサイズのトレードオフを判断する材料になる点が重要です。L40Sで260Mが約51 pages per second、ColModernVBERTの約2倍というthroughputと、hierarchical token poolingとasymmetric quantizationで1.5 MBから6 kBへ255×圧縮してもnDCGの95%以上を維持することが具体値で示されたため、安いGPUや小規模インフラでvisual document retrievalを回すSaaSに直導入できる点が重要です。1回のforward passでdenseとlate-interactionの両方を返し、ANNでの初期検索からlate-interactionでのrerankまで同じモデルで完結できることが示されたため、インフラ構成を柔軟に選べる点が重要です。

実践で使える点 Hugging Face Transformersで提供されApache 2.0 licenseで公開されたチェックポイントを原典のNeoMME collectionから取得し、手元のdocument page screenshotsで1回のforward passでdenseとlate-interaction embeddingsの両方を取得できるかを検証します。2048×2048入力でL40Sで約51 pages per secondという数値を基準に、手元のGPUでのthroughputを計測し、ColModernVBERT比で約2倍という記載を踏まえてコスト見積もりを行います。index storageが6 kB per pageへ255×圧縮され95%以上を維持するという記載を前提に、hierarchical token poolingとasymmetric quantizationを適用した際のstorageとnDCG@10のトレードオフを手元のコーパスで検証します。NextPlaidを用いたlate-interaction検索と、dense embeddingでのANN検索後にlate-interactionでrerankする2段階構成の両方を試し、ViDoRe v3で示された0.523や0.556というスコアを参考に検索品質を評価します。

原典 NeoMME: an efficient Multimodal-native and Multilingual Encoder

9. LFM2.5 350MをGRPOで100ステップ・500サンプル追加学習しIFStruct準拠率が22.6%から29.7%へ向上する無料Colabレシピ

要点小さなモデルのstructured-output complianceを大幅に改善するためのfully publicでinexpensiveなレシピであることが示されました。LFM2.5-350MをTRLライブラリを用いたGroup Relative Policy Optimization（GRPO）でfine-tuneし、IFStruct benchmarkで評価したことが示されました。フル実行はaround 500 samplesと100 training stepsで完結し、free-tierのColabやKaggle GPUで実行できるサイズであり、GitHubで公開されていることが示されました。lightなfine-tuningでもIFStruct benchmarkで22.6%から29.7%へ向上したことが示されました。structured outputはLLMで最も一般的な実務タスクの一つである一方、多くのベンチマークはbroaderなreasoningやextraction scoreに含めてしまい単独で測定しておらず、要求された形式と形状でvalidかつparseableな出力を返すかというschema complianceがdownstream systemへ配線できるかを決めることが示されました。本notebookで説明されるtraining pipelineはIFStruct blogで説明されたRLモデルの学習に使われたものではなく、benchmark scoreの再現ではなくtask-specificなfine-tuningで小型モデルでも性能を改善しはるかに大きなモデルに匹敵させられることを示すことが目的であることが示されました。ガイドは二つの場所で実行される構成であり、fine-tuningはGPU（free-tier ColabやKaggle GPU向けのnotebook）、evaluationはMacBook（ここではMacBook Pro with an Apple M5 Max and 36 GB of unified memory）でllama.cpp経由で行い、llama.cppがOpenAI-compatibleなserverを公開してIFStruct evaluatorが通信することが示されました。Python toolingとしてuv、servingとしてllama.cppが必要であり、Liquid AIのllama.cpp deployment docsに従い brew install llama.cpp と llama-server --version で確認することが示されました。IFStructはLLM出力のvalidityとschema adherenceをテストするbenchmarkであり、Liquid4All/ifstructでopen-source、publicなbenchmark datasetはHugging FaceのLiquidAI/ifstruct-v1.0で提供され git clone https://github.com/Liquid4All/ifstruct.git で取得できることが示されました。ベースモデルの評価ではIFStruct benchmarkでLFM2.5-350Mのreported scoreである21.1%を再現できるかを検証したことが示されました。BF16 GGUF（LiquidAI/LFM2.5-350M-GGUF）をMacBook上でllama.cppでserveし、llama-server -hf LiquidAI/LFM2.5-350M-GGUF:BF16 -c 32768 -np 4 -ngl 99 --alias LiquidAI/LFM2.5-350M --host 127.0.0.1 --port 8080 のコマンドで起動することが示されました（-c 32768はprompt contextのサイズ、-np 4は4リクエストの並列serve、-ngl 99は利用可能な場合に全レイヤーをGPUへoffload、–aliasはIFStructがOpenAI-compatible endpointへ送るモデル名）。起動後に uv run ifstruct-eval --model LiquidAI/LFM2.5-350M --base-url http://localhost:8080/v1 --api-key dummy --dataset data/test.jsonl --results-file results/lfm2.5-350m-llamacpp-base.json --n-threads 4 --max-tokens 2048 -v で2000サンプルを評価したことが示されました。結果はOverall 452/2000 passed（22.6%）、Average latency 1453msであることが示されました。By formatではJSON 180/1000 passed（18.0%）、YAML 272/1000 passed（27.2%）であることが示されました。By top-level structureではWrapper key 288/1011 passed（28.5%）、Bare list 164/989 passed（16.6%）であることが示されました。Common errorsとしてrequired field missing 7228x、wrong item count 738x、type mismatch 540x、Unclosed code block 317xなどが示されました。IFStruct release blogではLFM2.5-350Mについて21.1%と報告されており、今回のlocal llama.cpp/BF16 setupでの22.6%はそれに近いことが示され、このlocal resultをsame serving stack比較のbaselineとして用いたことが示されました。GRPO fine-tuningの全体の実行可能なpipelineは同梱のnotebookに存在し、本セクションでは関連する部分のみをカバーすることが示されました。学習データとして nvidia/Nemotron-RL-instruction_following-structured_outputs を用い、各promptをtarget JSON Schemaとexpected field countとペアにしたもので約500サンプルを用いることが示されました。Nemotronのデータ分布がIFStruct評価と異なるため二つのギャップを埋めるaugmentationを行い、40%には「return the output inside a fenced code block」という指示を追記して常にraw JSONを出すのではなくformat指示に従うことを学習させ、disjointな20%はtop-level-arrayタスクへ変換（schemaをarrayでwrapしrequired item countを指定）してbare-list出力とitem-count complianceを学習させたことが示されました。モデルはLiquidAI/LFM2.5-350MをloadしLoRA adapterを付与することが示されました。LFM2.5はhybrid attention/convolution architectureであるためLFM-specificなmodule名をtargetとし、LoraConfig(r=16, lora_alpha=32, bias="none", task_type="CAUSAL_LM", target_modules=["q_proj", "k_proj", "v_proj", "out_proj", "in_proj", "w1", "w2", "w3"]) で約6M parameters（モデルの約1.66%）を学習することが示されました。三つのreward functionsをいずれも[0, 1]スケールで定義し、extracted structureが正しいかをscoreすることが示されました。json_format_rewardはparse可能かかつ要求された形式（fenced vs. raw）かで判定し、要求された形式でparse可能なら1.0、形式は違うがparse可能なら0.2、parse不能なら0.0であることが示されました。field_count_rewardはtop-level fieldsの期待数と一致するかで判定し、exact matchで1.0、missに応じて線形にdecayすることが示されました。schema_validation_rewardは行のJSON Schemaに対して検証し、constraint violationを数えてrequired-key coverageでpartial creditをgateすることが示されました。三つをweighted sumとして reward_weights=[1.0, 0.5, 2.0] で組み合わせたことが示されました。学習はfree-tier 16 GB GPU向けに8 generations per prompt groupで100 steps行い、GRPOConfig(output_dir="./outputs/lfm25-350m-nemotron-schema-grpo", learning_rate=5e-5, max_ste までが記載されていることが示されました。

なぜ重要か 構造化出力の失敗は配線全体を止めるが、軽量な350Mモデルでも500サンプル・100ステップという少量学習でIFStruct準拠率が22.6%から29.7%へ向上することが数値で示されたため、はるかに大きなモデル並みの安定性に近づけられることが検証できる点が重要です。無料のColabやKaggle GPUで完結し、GitHubで公開されたnotebookとして再現できることが示されたため、バリデーションコストを抑えた本番運用に直結する手法として今日から試せる点が重要です。schema complianceを個別に測定するIFStruct benchmarkでのbaseline（21.1% reported、local 22.6%）と改善後の数値が具体的に示されたため、structured outputをdownstreamへ配線する際の信頼性判断に使える点が重要です。

実践で使える点 同梱のnotebookをfree-tierのColabやKaggle GPUで実行し、約500サンプルの nvidia/Nemotron-RL-instruction_following-structured_outputs を用いてGRPO（TRL）でLFM2.5-350Mを100ステップ追加学習するレシピを再現します。LoRAは r=16, lora_alpha=32, target_modules=["q_proj", "k_proj", "v_proj", "out_proj", "in_proj", "w1", "w2", "w3"] で約6M parameters（約1.66%）のみを学習する構成であることを原典で確認し、手元でも同様に設定します。Rewardはjson_format_reward、field_count_reward、schema_validation_rewardの三つを reward_weights=[1.0, 0.5, 2.0] でweighted sumする構成であることを原典で確認します。データaugmentationとして40%へのfenced code block指示付与と20%のtop-level-array変換を原典どおりに実装します。評価はMacBook上で brew install llama.cpp でllama.cppを導入し、BF16 GGUFを llama-server -hf LiquidAI/LFM2.5-350M-GGUF:BF16 -c 32768 -np 4 -ngl 99 でserveし、uv run ifstruct-eval --model LiquidAI/LFM2.5-350M --base-url http://localhost:8080/v1 --dataset data/test.jsonl で2000サンプルを評価して22.6%前後のbaselineを再現できるか確認します。Common errorsで示されたrequired field missingやwrong item countなどの内訳を手元のログと照合し、改善後の29.7%へ向けて同様の測定を行います。

原典 Fine-tuning a 350M Model for Better Structured Outputs in 100 GRPO Steps

10. IFMが0.9Bから375B-A23Bまで6サイズのK2 HorizonをApache 2.0で公開、推論からエージェント事後学習までの全工程を再現可能に

要点 IFMがK2 Horizonを公開したことが示されました。375B-A23B、36B-A4B、32B、7B、3.7B、0.9Bの6モデルからなるconnected fleetであることが示されました。reasoning、mathematics、coding、agentic tasks、general capabilitiesにわたり、0.9B、3.7B、7Bがそれぞれのサイズクラスでstate-of-the-artを達成したことが示されました。36B-A4BはMixture-of-Value-Attention（MoVA）を搭載し、active parameterあたりの効率でより大きなモデルを上回ることが示されました。32Bと375B-A23Bはそれぞれのクラスでtopに位置することが示されました。すべてのモデルについて、pretrainingからreasoningおよびagentic post-trainingまでのtraining lifecycleを通じ、intermediate checkpoints、training dataまたは詳細なdata-construction recipes、open architecture、mixture compositions、training code、configurations、fine-grained logs、evaluation results、final weightsが公開されることが示されました。modelsとcodeはApache 2.0 licenseで、datasetsはODC-BY等の適用ライセンスで公開され、再配布できない場合はdataの構築方法とmixの方法が開示されることが示されました。K2 Horizonはfirst fully open model fleet for agentsとして、agentic post-trainingまでの完全な開発過程を公開する初のファミリーであることが示されました。6モデルはcore architecture、vocabulary（0.9Bはより小さいvocabulary）、training methodology、interfaces、evaluation infrastructure、deployment toolingを共有するOne connected fleetであり、サイズ間の移動や動的なルーティング、スケールを跨いだ効率の研究が容易になることが示されました。6モデルはedgeからenterpriseまでをカバーし、0.9Bはwatchesやglassesのようなhighly constrained environments向け、3.7Bと7Bはphones等のon-device向け、denseな32Bとsparseな36B-A4Bはlocal workstationsやefficient serving向け、375B-A23Bはenterprise向けの最上位モデルと位置づけられ、All six models include quantization supportであることが示されました。性能面では、0.9BがAIME 2026で48を超えるスコアを達成し、3.7Bと7BはSWE-benchやBrowseCompでstrong performanceを示したことが示されました。一方で、TerminalBenchのようなextensive explorationとrepeated recoveryを要する複雑なタスクはsmallest modelsには依然困難であることが示されました。375B-A23Bはsparse MoEアーキテクチャでtotal 375 billion parameters、per tokenでapproximately 23 billion parametersをactivateし、400 billion parameters未満のtopクラスに位置することが示されました。32Bは40 billion未満のdenseモデルでtopに位置し、36B-A4Bはper tokenでapproximately 4 billion parametersのactivateでdenseな32Bに迫る性能をMoVAとMoE feed-forward layersにより実現することが示されました。いずれのモデルもsingle endpointではなくdevelopment treeとして公開され、intermediate checkpointsやpost-training branchesからreasoningやinstruction-following、agentic variantへの発展を辿れることが示されました。

なぜ重要か 0.9B、3.7B、7Bが各サイズクラスでSOTA、36B-A4BがMoVAによりactive parameterあたりの効率でより大きなモデルを上回ることが具体的に示されたため、edgeからenterpriseまでサイズ別に最適なモデルを選びつつ、中間チェックポイントや学習データレシピまで含めて再現・適応できる土台として検証できる点が重要です。pretrainingからagentic post-trainingまでの全工程でcheckpoints、data（またはdata recipe）、code、configurations、training logsが公開されるfirst fully open fleetであることが示されたため、自前でのfine-tuningや蒸留、toolsやenvironmentsへの適応を最終チェックポイントを起点にブラックボックスとして扱うのではなく手法ごと再現できる点が重要です。

実践で使える点 原典で公開されたApache 2.0 licenseのmodelsとcode、ODC-BY等のdatasets、intermediate checkpointsやtraining dataまたはdata-construction recipes、training code、configurations、fine-grained logs、evaluation resultsを取得し、手元の環境で再現を試します。0.9Bはwatches/glasses等のhighly constrained environments、3.7B/7Bはphones等のon-device、32B/36B-A4Bはlocal workstations、375B-A23Bはenterpriseという位置づけとquantization supportを前提に、共有されたarchitectureやvocabulary、interfaces、deployment toolingを活かしてサイズ間の移動や動的ルーティングを検証します。reasoning、tool use、planning、agentic capabilitiesがどのように生じるかをcheckpointsとtraining logsで追跡し、375B-A23Bのdevelopment treeや36B-A4BのMoVAによる効率を手元で確認します。

原典 K2 Horizon: A connected fleet of six open models