OPEN-WEIGHT MODELS ON A PHONE?? Meet iPDF, my lazy research companion
This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady
What I Built
Open-weight models. On my phone. While I go for a walk.
The models run on hosted infrastructure. My phone is the reading, study and listening interface. No mobile GPU or model download required.
I like the idea of reading research papers. I like the part where I have to look up the same unfamiliar term, make my own study cards, and reconstruct the explanation from three different tabs considerably less.
So I built iPDF: research at your own pace.
It turns a PDF or arXiv paper into an interactive edition: the original text, with explanations and study tools around it. It is also an open, versioned JSON format, so the result can exist independently of the application that generated it. The name means “interactive PDF”; the portable formats are .ipdf.json and .ipdf.html, rather than a new binary PDF standard.
The workflow is straightforward:
1. Sign in with GitHub and upload a paper, or enter its arXiv ID.
2. Choose beginner, intermediate or expert, your background, and what you want to get out of it.
3. Let background jobs prepare the tools while you do something else.
4. Come back to read, study, ask questions or listen.
Tap an underlined term for a definition. Save it to your deck. Work through flashcards. Follow a prerequisite path and mark the concepts you already know. Ask about the current section and get an answer with a supporting quotation and page reference.
Or press play. Narration follows the sections, highlights the current one, and offers a simpler explanation. Walking mode gives the audio controls room to breathe. ElevenLabs provides optional hosted narration; browser speech is the fallback.
The paper stays the main content. A summary is not the main output. Students, developers entering a new field, and readers who prefer listening get to spend less effort assembling a study setup before they can start learning.
Demo
- Project site and browser reader — no account needed to try the authored interactive sample or open an exported JSON file locally.
- Full application — GitHub sign-in, PDF/arXiv preparation, private libraries, tutor and listening.
- Try the sample directly — working glossary terms, study cards and browser narration, clearly labelled as an authored format demonstration.
{% embed youtube.com %}
!iPDF project site with an interactive format preview
For a quick test, open the sample, tap “provenance,” save the term, answer the study card, then press Listen to paper. To test generation, open the full app and use the arXiv example or upload a text-based PDF. Choose browser voice to avoid ElevenLabs usage.
GitHub Pages hosts the reader; Python and generation run on Render. The free Render instance can take time to wake up and its temporary storage can reset. Export editions you want to keep. The prototype does not guarantee that an overnight upload will be ready in the morning.
Code
{% github spacenets7/ipdf %}
The repository is MIT licensed. It includes the format specification, Pydantic schema, generation plugins, viewer, mocked tests and deployment configuration.
How I Built It
The open-weight model used in the live generation checks was gpt-oss-120b, served through a hosted OpenAI-compatible endpoint. Its upstream project uses the Apache 2.0 license. No model runs on the reader’s laptop.
I separated the application into three layers:
PDF / arXiv
↓
ingest — PyMuPDF, page-tagged sections, tables and figures
↓
generate — glossary, flashcards, narration and table-derived charts
↓
iPDF 0.1 JSON — validated blocks with source references and provenance
↓
render — vanilla JavaScript reader, Chart.js and audio controls
FastAPI connects the workflow. SQLite stores accounts, jobs, caches and learning state. Background workers return a job ID quickly; the browser polls for progress. The renderer consumes completed JSON and never makes an LLM call.
The generation client takes its endpoint, API key and model from environment variables. Glossary depth, flashcard difficulty and narration style change with the reader’s level. Each generated block records its source page, model and prompt version. Invalid blocks get up to two retries before being dropped and logged.
Paper Instruments’ Ultramarine is the optional DEEP backend for table selection and claim grounding. Charts have an additional constraint: every plotted number must match a parsed cell in the source table. If extraction fails, there is no chart. The model does not get to fill the gap with plausible numbers.
The tutor builds on the same source discipline. Supported answers need an exact quotation from the selected section and a grounding check. Questions outside the available evidence receive a refusal. Familiarity and recent conversation help shape explanations; they do not retrain the model.
ElevenLabs turns narration into cached MP3 segments when selected. Browser speech keeps the reading and sample experience usable without an audio API key. Optional speech input uses the browser’s speech service; this is not an ElevenLabs realtime Agent integration.
Real usage mattered more to me than a “cheap per paper” claim without evidence. These are the recorded Ultramarine/DEEP cost components from bounded one-page checks:
| Check | Recorded DEEP cost |
| --- | ---: |
| Local personalized generation | $0.00601245 |
| Deployed upload → generation workflow | $0.00253510 |
Those figures are based on recorded usage and configured DEEP rates. They are not complete per-paper bills: FAST pricing was not configured, and audio is separate. The deployed audio check synthesized 2,379 characters and returned a playable MP3. I have not measured a full-paper cost benchmark.
The latest mocked suite has 51 passing tests, including schema validation, chart evidence, account isolation, OAuth and job recovery. Ingestion and table evidence were checked on Attention Is All You Need, BERT and ResNet. The complete authenticated generation/listening smoke check used one page; I am not presenting it as a full three-paper generation benchmark. Validation details record the scope and limitations.
The interface uses a dark, quiet workspace inspired by T3 Code. It is implemented in original HTML/CSS and vanilla JavaScript. The architecture uses FastAPI, Pydantic, PyMuPDF, Jinja2, SQLite and vendored Chart.js. The earlier digest module is preserved in the repository; iPDF is the research-paper workflow built around the open document format.
Why Does Open Innovation Matter?
The useful output of an AI tool should not disappear when I close its chat window.
For iPDF, openness has two concrete jobs. The first is model choice. An open-weight model such as gpt-oss gives other developers access to the weights and the ability to deploy or adapt the model under its license. A closed-model API does not provide those weights. This build uses hosted inference to keep the application lightweight, but it does not hardcode a provider or model into the document format.
The second is ownership of the result. Anyone can inspect the JSON, validate source references, write a different viewer, or add a generation plugin. A reader can keep a self-contained HTML edition rather than depend on an account to reopen it.
Endpoint compatibility alone is not unique to open models, and hosted inference still sends source excerpts to providers. I am not claiming that generation is offline or private from those providers. The practical benefit is that the model, pipeline and output are separate things that can evolve independently. The schema and page references stay useful when the model changes.
That makes iPDF something people can build on, rather than another destination their papers have to live inside.
My Agent Session
I built with assistance from Codex, using an iterative loop: implement a step, run mocked tests, inspect real output, then check the browser at phone width. The work included the pivot from a digest to an open document format, source-table validation, hosted audio, GitHub login and the mobile reader.
The commit history and validation log document the implementation and checks. A public agent-session transcript is not attached; those links are a build record, not a transcript.
The Lazy Payoff
In this week’s authenticated test, one upload produced five glossary entries, three flashcards and a narration segment. A separate preparation job produced nine source-linked concepts. A question about the Transformer returned a cited answer; familiarity and conversation history survived a reload. The portable HTML and JSON downloads worked, and anonymous requests could not open the private edition.
That is the payoff I can demonstrate today: I did not have to manually prompt for a glossary, copy questions into a separate deck, write a narration script, and then connect every result back to the page myself. The pipeline assembled those pieces once.
I have not run a timed study or measured learning gains. The saved effort is a demonstrated workflow reduction, not an invented “hours saved” statistic. My goal is modest: let the reader spend less time preparing to understand a paper, and more time actually understanding it—even if that happens one section at a time, on a slow walk.
Prize Categories
- Best Use of Render — the Dockerized FastAPI application runs on Render, including ingestion, hosted-generation jobs, private libraries and audio delivery.
- Best Use of Ultramarine — Paper Instruments’ Ultramarine is used as the optional DEEP backend for source grounding and table selection. Recorded run costs and their limits are reported above.
- Best Use of ElevenLabs — optional section narration is synthesized into cached MP3 audio, with browser speech available as a fallback.
- Best Use of GitHub Copilot — entering through the challenge’s listed GitHub Actions automation option: Actions runs the mocked tests and static-reader build on pushes and pull requests. The coding assistant used was Codex; I am not claiming Copilot usage.
Partner tags: #elevenlabs · #render · #ultramarine / Paper Instruments · #githubcopilot.
1 reaction · 3 comments
Mentions
so, ChatGPT released sample code for their web crawler. Guess what, it completley strips out all Schema. So let's put that myth to bed. H/T no twitter having Rodrigo Stockebrand for this github.com/openai/gpt-oss/blob/5681a6b6552635e7b2…
OPEN-WEIGHT MODELS ON A PHONE?? Meet iPDF, my lazy research companion This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady What I Built Open-weight models. On my phone. While I go for a walk. The models run on hosted infrastructure. My phone is the reading, study and listening interface. No mobile GPU or model download required. I like the idea of reading research papers. I like the part where I have to look up the same unfamiliar term, make my own study cards, and reconstruct the explanation from three different tabs considerably less. So I built iPDF: research at your own pace. It turns a PDF or arXiv paper into an interactive edition: the original text, with explanations and study tools around it. It is also an open, versioned JSON format, so the result can exist independently of the application that generated it. The name means “interactive PDF”; the portable formats are .ipdf.json and .ipdf.html, rather than a new binary PDF standard. The workflow is straightforward: 1. Sign in with GitHub and upload a paper, or enter its arXiv ID. 2. Choose beginner, intermediate or expert, your background, and what you want to get out of it. 3. Let background jobs prepare the tools while you do something else. 4. Come back to read, study, ask questions or listen. Tap an underlined term for a definition. Save it to your deck. Work through flashcards. Follow a prerequisite path and mark the concepts you already know. Ask about the current section and get an answer with a supporting quotation and page reference. Or press play. Narration follows the sections, highlights the current one, and offers a simpler explanation. Walking mode gives the audio controls room to breathe. ElevenLabs provides optional hosted narration; browser speech is the fallback. The paper stays the main content. A summary is not the main output. Students, developers entering a new field, and readers who prefer listening get to spend less effort assembling a study setup before they can start learning. Demo - Project site and browser reader — no account needed to try the authored interactive sample or open an exported JSON file locally. - Full application — GitHub sign-in, PDF/arXiv preparation, private libraries, tutor and listening. - Try the sample directly — working glossary terms, study cards and browser narration, clearly labelled as an authored format demonstration. {% embed youtube.com %} !iPDF project site with an interactive format preview For a quick test, open the sample, tap “provenance,” save the term, answer the study card, then press Listen to paper. To test generation, open the full app and use the arXiv example or upload a text-based PDF. Choose browser voice to avoid ElevenLabs usage. GitHub Pages hosts the reader; Python and generation run on Render. The free Render instance can take time to wake up and its temporary storage can reset. Export editions you want to keep. The prototype does not guarantee that an overnight upload will be ready in the morning. Code {% github spacenets7/ipdf %} The repository is MIT licensed. It includes the format specification, Pydantic schema, generation plugins, viewer, mocked tests and deployment configuration. How I Built It The open-weight model used in the live generation checks was gpt-oss-120b, served through a hosted OpenAI-compatible endpoint. Its upstream project uses the Apache 2.0 license. No model runs on the reader’s laptop. I separated the application into three layers: PDF / arXiv ↓ ingest — PyMuPDF, page-tagged sections, tables and figures ↓ generate — glossary, flashcards, narration and table-derived charts ↓ iPDF 0.1 JSON — validated blocks with source references and provenance ↓ render — vanilla JavaScript reader, Chart.js and audio controls FastAPI connects the workflow. SQLite stores accounts, jobs, caches and learning state. Background workers return a job ID quickly; the browser polls for progress. The renderer consumes completed JSON and never makes an LLM call. The generation client takes its endpoint, API key and model from environment variables. Glossary depth, flashcard difficulty and narration style change with the reader’s level. Each generated block records its source page, model and prompt version. Invalid blocks get up to two retries before being dropped and logged. Paper Instruments’ Ultramarine is the optional DEEP backend for table selection and claim grounding. Charts have an additional constraint: every plotted number must match a parsed cell in the source table. If extraction fails, there is no chart. The model does not get to fill the gap with plausible numbers. The tutor builds on the same source discipline. Supported answers need an exact quotation from the selected section and a grounding check. Questions outside the available evidence receive a refusal. Familiarity and recent conversation help shape explanations; they do not retrain the model. ElevenLabs turns narration into cached MP3 segments when selected. Browser speech keeps the reading and sample experience usable without an audio API key. Optional speech input uses the browser’s speech service; this is not an ElevenLabs realtime Agent integration. Real usage mattered more to me than a “cheap per paper” claim without evidence. These are the recorded Ultramarine/DEEP cost components from bounded one-page checks: | Check | Recorded DEEP cost | | --- | ---: | | Local personalized generation | $0.00601245 | | Deployed upload → generation workflow | $0.00253510 | Those figures are based on recorded usage and configured DEEP rates. They are not complete per-paper bills: FAST pricing was not configured, and audio is separate. The deployed audio check synthesized 2,379 characters and returned a playable MP3. I have not measured a full-paper cost benchmark. The latest mocked suite has 51 passing tests, including schema validation, chart evidence, account isolation, OAuth and job recovery. Ingestion and table evidence were checked on Attention Is All You Need, BERT and ResNet. The complete authenticated generation/listening smoke check used one page; I am not presenting it as a full three-paper generation benchmark. Validation details record the scope and limitations. The interface uses a dark, quiet workspace inspired by T3 Code. It is implemented in original HTML/CSS and vanilla JavaScript. The architecture uses FastAPI, Pydantic, PyMuPDF, Jinja2, SQLite and vendored Chart.js. The earlier digest module is preserved in the repository; iPDF is the research-paper workflow built around the open document format. Why Does Open Innovation Matter? The useful output of an AI tool should not disappear when I close its chat window. For iPDF, openness has two concrete jobs. The first is model choice. An open-weight model such as gpt-oss gives other developers access to the weights and the ability to deploy or adapt the model under its license. A closed-model API does not provide those weights. This build uses hosted inference to keep the application lightweight, but it does not hardcode a provider or model into the document format. The second is ownership of the result. Anyone can inspect the JSON, validate source references, write a different viewer, or add a generation plugin. A reader can keep a self-contained HTML edition rather than depend on an account to reopen it. Endpoint compatibility alone is not unique to open models, and hosted inference still sends source excerpts to providers. I am not claiming that generation is offline or private from those providers. The practical benefit is that the model, pipeline and output are separate things that can evolve independently. The schema and page references stay useful when the model changes. That makes iPDF something people can build on, rather than another destination their papers have to live inside. My Agent Session I built with assistance from Codex, using an iterative loop: implement a step, run mocked tests, inspect real output, then check the browser at phone width. The work included the pivot from a digest to an open document format, source-table validation, hosted audio, GitHub login and the mobile reader. The commit history and validation log document the implementation and checks. A public agent-session transcript is not attached; those links are a build record, not a transcript. The Lazy Payoff In this week’s authenticated test, one upload produced five glossary entries, three flashcards and a narration segment. A separate preparation job produced nine source-linked concepts. A question about the Transformer returned a cited answer; familiarity and conversation history survived a reload. The portable HTML and JSON downloads worked, and anonymous requests could not open the private edition. That is the payoff I can demonstrate today: I did not have to manually prompt for a glossary, copy questions into a separate deck, write a narration script, and then connect every result back to the page myself. The pipeline assembled those pieces once. I have not run a timed study or measured learning gains. The saved effort is a demonstrated workflow reduction, not an invented “hours saved” statistic. My goal is modest: let the reader spend less time preparing to understand a paper, and more time actually understanding it—even if that happens one section at a time, on a slow walk. Prize Categories - Best Use of Render — the Dockerized FastAPI application runs on Render, including ingestion, hosted-generation jobs, private libraries and audio delivery. - Best Use of Ultramarine — Paper Instruments’ Ultramarine is used as the optional DEEP backend for source grounding and table selection. Recorded run costs and their limits are reported above. - Best Use of ElevenLabs — optional section narration is synthesized into cached MP3 audio, with browser speech available as a fallback. - Best Use of GitHub Copilot — entering through the challenge’s listed GitHub Actions automation option: Actions runs the mocked tests and static-reader build on pushes and pull requests. The coding assistant used was Codex; I am not claiming Copilot usage. Partner tags: #elevenlabs · #render · #ultramarine / Paper Instruments · #githubcopilot.
推論基盤の「公開の境界」に地政学を読む — DeepSeek・OpenAI・Moonshot の結合の置き場所 DeepSeek の推論エンジン DeepInfer の公開をきっかけに、フロンティアモデルの推論エンジンと、それを取り巻くサービス基盤を調べました。すると、どれも純粋に性能や技術の理想形を追った形ではなく、想像以上に地政学を映した結果になっていそうだと感じるようになりました。 象徴的なのは、DeepSeek が KV キャッシュと負荷分散を「社内インフラと密結合している」として出さなかったことです。この記事では DeepSeek・OpenAI・Moonshot を「結合をどこに置いたか」という同じ物差しで並べ、各社の境界の引き方から、その読み方を探ります。次のリリースや技術ブログを見たときに、境界がどこにあり、なぜそこなのかを読むための手がかりになれば幸いです。 ! 本文は公開資料（リポジトリ、公式ブログ、論文、報道）だけを材料にしています。各社が明言していない読みには「推測」と書きました。報道の数字には媒体と日付を添えています。 DeepInfer が外した層は、コードに跡が残っている DeepInfer は 2026-10-20 に公開されました。対象は DeepSeek-V4.1-Flash のオフライン推論だけで、NVIDIA SM100（Blackwell 世代の GPU）と Huawei Ascend 950 に対応します。README は "not included in this release" として、KV キャッシュのシステム、P/D 分離（入力を読む段と出力を作る段を別の機械で動かす方式。エンジン側は大半が実装済み）、データ並列（DP）レプリカ間の負荷分散の 3 つを挙げています。 理由は同梱の Q&A 文書にあります。KV キャッシュ管理と負荷分散の部品が "tightly coupled to our internal infrastructure" なので、まだ全部は出せない、という説明です。 空の「仮想関数」として残る穴 外した層は、穴として残っています。deepinfer/engine/llm_engine.py の L800〜858 に、コメント「这里开始都是虚函数」（ここから仮想関数）で囲まれた空実装のメソッドが並びます。 llm_engine.py L800-858（本体はすべて空実装） init_pd_split() 初始化 PD 分离需要的数据结构 do_save_kvcache() 保存 kvcache, pre_sampler_sync 时调用 send_processed_prompts() 把已经处理完的 prompt sequence 发送给 completion engine ... 呼び出し側は公開コードにあり、decode・prefill・PROMPT エンジンの各段から呼ばれます。中身を書くのは社内のサブクラスだろう、というのが私の推測です。 ほかにも跡があります。 KV を保存・復元する関数（select_state_slice_to_store など）は tests からしか呼ばれない deep_cluster/ の中身は、ノード内のハード検出と NUMA バインド（CPU とメモリの割り当て）だけ KV の照合・取得・転送は、公開エンジンの外側にあります。 出したものと、出さなかったもの 出した部品 出さなかった層 FlashMLA / DeepEP / DeepGEMM（vendor/ に同梱） KV キャッシュのシステム（3FS の上で照合・TTL（保持期限）・削除を担う層） C++ スケジューラ、EPLB（自前実装） P/D 間の転送路と上位の振り分け TileLang カーネル（CUDA と Ascend の 2 系統） DP レプリカ間の負荷分散 3FS（2025-02 公開。コードからは参照しない） 自動伸縮・障害時の再構成 3FS は DeepSeek の分散ファイルシステム、EP はエキスパート並列（MoE のエキスパートを GPU に分けて置く方式）、EPLB はその負荷を均す配置の仕組みです。部品も社内と同一ではなく、公開版 FlashMLA は decode カーネルが社内版より 5〜10% 遅いと Q&A にあります。 2025 年に挙げた 3 つの理由 DeepSeek は 2025-04-14 にも、推論エンジン全体の公開を見送っていました。理由は次の 3 つです。 1 年以上前の vLLM フォークを元にしていて、乖離が大きい "including cluster management tools" を含む社内基盤と結合している 大きな OSS を保守する余力がない 2026 年版はエンジン単体に切り出して出しました。今回出せた理由の説明は見当たりません。境界は固定でもなく、Q&A は今後の推論コードも DeepInfer で継続して公開すると書いています。 外した層は、計算資源の不足を運用で吸収する層に見える DeepSeek は計算資源の制約への対策を運用層に集め、そこが社内インフラとの結合点になった、というのが私の読みです。 制約はチップの禁輸 制約の出どころは米国の輸出規制です。2022-10 の規制で NVIDIA は対中版の H800 を出しましたが、2023-10 の改定で H800 も対象になりました。2025-04 には H20 にも許可が要ると通知され（NVIDIA の 8-K）、2025-12 に H200 の販売を認める方針が出ています。 創業者も 2024-07 に、問題は資金ではなくチップの禁輸だと語っています（ChinaTalk の英訳）。 制約はモデルと運用の両方に出ている V3 の技術報告（2024-12）では、学習は H800 2,048 枚です。NVLink（160 GB/s）と IB（50 GB/s）の帯域差を踏まえ、各 token の送り先を最大 4 ノードに制限しました。 運用側にも似た発想が見えます（2025-03-01 の推論システム概要）。 全サービスが H800。昼は全ノードで推論し、夜は縮めて研究と学習に回す ピークは 278 ノード、平均は 226.75 ノード 24 時間の入力 token のうち 56.3% が、ディスク上の KV キャッシュに命中 文書は配分の理由を禁輸とは書いておらず、限られた台数を時間で使い回す工夫と読むのは私の推測です。 ディスクの KV は 2024-08 に料金表にも現れ、キャッシュ命中は最大 90% 安くなりました。 2026 年の Q&A では KV 専用の 3FS が約 100 PiB あり、冗長化は 10+2 の消失訂正符号（データ 10 に検査用 2 を足す方式）です。2024 年の論文のミラー構成（20 PiB 超）とは用途の違う別クラスタなので、単純には比べられません。 容量コストへの対策だろう、というのは推測です。 停止時の KV ごとの移送や故障時の再構成も、Q&A にはあってもコードにはありません。 部品は出し、運用層は残した カーネル、通信、EP、スケジューラ、3FS といった部品は公開され、その上で台数・配置・料金・TTL を決める運用層は残りました。 もう一つの仮説です。DeepInfer は NVIDIA と Ascend 950 の両方で動き、Q&A の設計目標の 1 つ目も「複数ベンダーのチップ」です。 そのためにハード依存の部分をカーネルに閉じ込め、運用層から切り離す必要があったことが、エンジンを切り出す圧力になったと推測します。「国産チップのために公開した」とは DeepSeek は言っていません。 閉じた層に乗るのは、計算資源の希少さ 制約は価格にも出ています。2026-04-24 の V4 の発表で DeepSeek は、高性能な計算資源が足りず V4-Pro の処理量に限りがあり、Ascend 950 の超節点が量産されれば大幅に値下げすると述べました（財聯社の引用による）。2026-08 にはピークとオフピークで料金を分けています。 ただ、運用層を閉じるのは DeepSeek に限りません。地政学が決めているのは閉じるかどうかではなく、閉じた層に何が埋め込まれるかで、DeepSeek ではそれが計算資源の希少さだと私は読んでいます。 OpenAI は逆に、結合を一か所に集めた OpenAI も運用層は出していません。逆なのは結合の置き方で、ハードの層の結合はほどき、状態と制御の層に集めました。 Habitat: 負債と知りつつ一か所に寄せる OpenAI の社内ストレージ基盤 Habitat は、約 40 地域、毎秒 7,000 万件超、500PB 超の規模です（2026-09-11 の記事）。 始まりは DevDay 2023 の、単一の DB につながる Python クライアントライブラリでした。のちにサービスに集約し、アクセス制御・監査ログ・ストレージへのアクセス制限を一か所で効かせられるようにしています。これを本人たちは戦略的に引き受ける技術的負債と呼んでいます。 ChatGPT の DB も、単一プライマリの PostgreSQL と約 50 のリードレプリカです（2026-01-22）。Habitat の背後は Azure Cosmos DB、PostgreSQL も Azure の管理サービスで、状態の層の足場はまだ Microsoft の上にあります。 ハード層は多重化して広げた チップの調達先は、DeepSeek と同じく複数ベンダーに広げました。学習と推論の大部分はなお NVIDIA だとしつつ（2026-03）、AMD（6GW）、Broadcom（自社設計 10GW と推論チップ Jalapeño）、AWS Trainium（2GW、GeekWire）、Cerebras（750MW、TechCrunch）と組んでいます。 Microsoft の独占も、優先交渉権への後退（2025-01）、その廃止（2025-10-28）、全製品を任意のクラウドで提供可（2026-04-27）の 3 段階でほどけました。 提供サービスの線は「状態を持つか」で引かれたように見える 2026-02-27 の共同声明で、Azure は「stateless な OpenAI API」の独占クラウドのままとされました。同じ時期に Amazon とは、Bedrock 上で記憶や権限を保持する「stateful runtime」を作ると報じられています（InfoWorld、2026-02）。 契約の線が状態を持つ層かどうかで引かれた、というのが私の読みです。2026-04 の改定後もこの線が残るかは、Microsoft のブログ本文からは確認できませんでした。 顧客と政府の要件も、状態と制御の層に集まります。 データの所在地: 2026-01-16 から ChatGPT Enterprise などで米国か欧州の地域内で推論 ゼロデータ保持（ZDR）: /v1/files など状態を持つエンドポイントは対象外 FedRAMP 20x Moderate（米連邦政府向けクラウドの認証、2026-04-27） 国防総省との合意（2026-02-28）: cloud-only で、安全の仕組みは OpenAI が自社で運用 出しているのは、重み（gpt-oss、2025-08）と運用記事と障害報告です。配信・安全・ストレージのスタックは出しておらず、境界の説明も見つかりませんでした。状態と制御の層こそ売っている部分なので出さない、というのが私の推測です。 制御面については、OpenAI 自身が政策の側から求めてもいます。2025-03 の OSTP（米大統領府の科学技術政策局）への意見書で、米国が最も優遇する国々（輸出規則の Tier I）のデータセンターに、Tier I の国に本社を置く企業による支配と、運用への不正アクセスの防止を求めました。これは OpenAI の提案で、課された条件ではありません。 何を出せるかも契約で縛られています。2025-10 の Microsoft との契約では、オープンウェイトの公開に能力基準（中身は非公開）が付きました。輸出・政府販売・提携の三方から、制御面を手元に置く動機が重なっている、と私は読んでいます（推測）。 OpenAI の閉じた層に埋め込まれているのは、所在地と統制の要件です。 Mooncake は、結合部分そのものを外に出した Moonshot（Kimi の開発元）の Mooncake は、DeepSeek が残した層のうち、KV の転送・保存・索引を公開しています。 Transfer Engine（2024-11-28）: RDMA などで KV を運ぶ転送層 Mooncake Store（2025-03-07）: 分散 KV キャッシュのプール Conductor（2026-09〜）: cache-aware なルータ（KV が残っているエンジンへ要求を回す）が使う KV インデクサ 2024-11 の公開時から、大モデル時代のストレージの「标准接口」（標準インタフェース）と参考実装を目標に掲げていました（量子位、2024-11-28）。その後 vLLM・SGLang・TensorRT-LLM・Dynamo・llm-d にコネクタが入り、2026-02-12 に PyTorch Ecosystem に加わっています。 担い手は Moonshot だけではない 2024-11 の公開は、清華大学の研究室と Moonshot が主導する産学の共同開源でした。 MAINTAINERS.md の codeowner 4 人は Alibaba Cloud の 2 人と清華系の 9#AISoft・趋境科技の 2 人で、Moonshot 所属はいません。git 履歴の社用メールでも Alibaba 259 件、tencent.com 114 件に対し、moonshot.cn は 2 件です（全 2,480 件。個人メールが大半）。 Alibaba は Moonshot の大口株主で（2024 年時点で約 36%、SCMP の報道）、Tencent も 2024-08 の調達に参加しました（Bloomberg）。どちらもクラウドを売る側で、Alibaba の tair-kvcache と Tencent の FlexKV は Mooncake に対応しています。標準になれば自社クラウドの得になる、というのは推測です。 契約と測定は、後から足した押さえ 公開の理由と商流の押さえは、時期が違います。コードを出した 2024-11〜2025-03 に見える理由は、共同開発・標準狙い・株主のクラウドです。商流の押さえは、その後に足されました。その後も KV インデクサ（Conductor、2026-09〜）の公開は続いていて、出すものと押さえるものを並行させている形です。 測定（2025-09〜）: Vendor Verifier は、Fireworks や Together などの第三者 API のスコアを公式と並べて公開する 契約（2026-07）: Kimi K3 License は、12 か月の売上が 2,000 万ドルを超える MaaS 事業者（モデルを API で提供する事業者）に、商用利用の前に別契約を求める ブログには "Weights are open. The knowledge to run them correctly must be too." とあります。運用の知識は開き、品質と商流はライセンスと検証で押さえる形です（推測）。 Moonshot では地政学の影は薄く見えます。国務院の「人工智能+」の意見（2025-08）は開源を奨励していますが、Mooncake の公開はそれより前で、政策が後押しした証拠は見つかりませんでした。 置き場所を決めるのは、お金と責任の流れ ラボ 結合の置き場所 出したもの 出さないもの 乗るお金と責任（推測） DeepSeek 運用層（KV・負荷分散・伸縮） カーネル、通信、エンジン単体 KV システム、P/D、DP 負荷分散 キャッシュ命中の料金、ピーク料金、処理量の上限 OpenAI 状態と制御の層 重み（gpt-oss）、運用記事、障害報告 配信・安全・ストレージのスタック クラウド契約、データ所在地、FedRAMP、政府契約 Moonshot 契約と測定（公開の後に追加） 転送・KV ストア・KV インデクサ（2024-11〜） 本番との差分（同じかは不明） MaaS の売上条項、提供品質の検証 どの社も、お金と責任が乗る層は手元に残しているように読めます（Moonshot は運用層を出した後に、契約と測定を足しました）。乗るものの中身には地政学が入り込み、DeepSeek では計算資源の希少さが料金と処理量に、OpenAI では所在地と統制の要件が契約に表れています（推測）。 DeepSeek は 2026-06〜07 に初の外部資金を受け、7 月 15 日の登記変更で国家人工智能产业投资基金が直接の株主になりました（財聯社、2026-07-15）。持分は約 0.28% と小さく、これだけで国家の関与が強いとは言えません。上場の準備も報じられています（Reuters 経由の The Star、2026-10-22）。 時系列だけ確かめておくと、2025-04 の見送りは外部資金の前、DeepInfer の公開は外部資金の後で上場準備の最中です。資金が公開の判断を左右したことを示す材料はありません。 一方、2026-09-10 の発表では "2,000 GPUs + a storage cluster? Let's talk." と呼びかけています。運用層は全員には出さず、規模のある相手とは個別に組む道を残している、と読んでいます（推測）。 業務システムの密結合は業務要件から生まれます。AI 基盤の密結合は、モデルとハードの事情から生まれる面が大きいように見えます。そう考えると、結合の位置がチップと料金の事情に引っ張られるのも自然です（推測）。 まとめ 公開の境界は秘密主義の度合いではなく、結合をどこに置いたかという設計の結果として読める DeepSeek は運用層に、OpenAI は状態と制御の層に結合を置いた。Moonshot は運用層を共同体で出し、後から契約と測定を足した その置き場所は、お金と責任が乗る層に重なる 地政学が効くのは閉じるかどうかより、閉じた層に何が埋め込まれるか（DeepSeek は計算資源の希少さ、OpenAI は所在地と統制の要件） 次のリリースや技術ブログでは、次の 5 つを確かめてみてください。 どの層が欠けているか、前回から動いたか（README の「含まれないもの」の欄） フックや設定の跡はあるか（空実装、外から注入する口、tests からしか呼ばれない関数） 誰が保守しているか（MAINTAINERS、コミットのメールドメイン） ライセンスと測定で何を押さえているか（売上条項、認定パートナー、検証ツール） 閉じた層にどの制約・要件が乗っているか（チップの調達、データの所在地、政府との契約） 今回出せた理由、出さない層の意図、地政学の効き方の解釈は、各社の明言ではなく私の推測です。 参考リンク DeepSeek DeepInfer（README） DeepInfer の Q&A 文書（doc/inference_deployment_qa.md） llm_engine.py（仮想関数の箇所） The Path to Open-Sourcing the DeepSeek Inference Engine（2025-04-14） Day 6: V3/R1 Inference System Overview（2025-03-01） DeepSeek-V3 Technical Report Fire-Flyer AI-HPC（SC24） Context Caching on Disk（2024-08-02） 財聯社（2026-04-24、V4-Pro の処理量の制約と値下げの条件） V4-Pro の GA とピーク・オフピーク料金（2026-08-13） V4.1-Flash の発表（2026-09-10） NVIDIA 8-K（2025-04、H20 の輸出許可） ChinaTalk: DeepSeek CEO インタビュー英訳（2024-11-27） 財聯社（2026-07-15、株主の変更） The Star / Reuters（2026-10-22、追加調達と上場準備） OpenAI 10 億人超の ChatGPT ユーザーを支えるオンラインストレージの急速な拡張（Habitat、2026-09-11） PostgreSQL を拡張して 8 億人の ChatGPT ユーザーに対応（2026-01-22） OpenAI raises $122 billion（2026-03-31） OpenAI and Broadcom unveil inference chip（2026-06-24） AMD and OpenAI（2025-10-06） Microsoft: The next chapter of the Microsoft–OpenAI partnership（2025-10-28） Microsoft and OpenAI joint statement（2026-02-27） The next phase of the Microsoft–OpenAI partnership（2026-04-27） InfoWorld: OpenAI launches stateful AI on AWS（2026-02） Your data（データの所在地と ZDR） Introducing data residency in Europe（2026-01-16 の追記） OpenAI available at FedRAMP Moderate（2026-04-27） Our agreement with the Department of War（2026-02-28） OpenAI の OSTP への意見書（AI Action Plan、2025-03-13、PDF） gpt-oss Moonshot / Mooncake Mooncake（README） Mooncake MAINTAINERS.md Mooncake 論文（arXiv 2407.00079） 量子位: Mooncake の共同開源（2024-11-28） Kimi K3 License Kimi-Vendor-Verifier Kimi Vendor Verifier（ブログ） SCMP: Alibaba の Moonshot 持分 BNN Bloomberg: Tencent が Moonshot の調達に参加（2024-08-05） Alibaba tair-kvcache（Mooncake をストレージに使える） 国務院「人工智能+」行動の意見（2025-08-26）