notebook · patent · nemo
Run the patent-strategist build — and use the model — on a Spark or a free cloud GPU
The artifact → card → article loop sells the outcome but offers no runnable on-ramp: a researcher who wants to reproduce the fine-tune, or a developer who wants to call the model, has to reconstruct the journey from prose. These two notebooks close that gap. The builder notebook walks the full baseline → corpus → train → quantize → publish journey as typed fieldkit API calls; the user notebook calls the model on real patent-prosecution tasks and surfaces its reasoning chains. Both are one-click via Open in Colab / Open in Kaggle and run offline on a DGX Spark.
- Builder: reproduce the build — baseline, corpus gates, backend decision, train, probe, quantize, publish — as fieldkit calls
- User: claim construction, MPEP-grounded office-action drafting, prior-art relevance, and licensing-scenario analysis with reasoning chains surfaced
- User: ground answers in MPEP text with fieldkit.rag and gate quality with fieldkit.eval scorers
- Both: run the whole workflow offline on a DGX Spark or on a free Colab / Kaggle GPU (dual-path, runtime-detected)
Audience — AI researchers and engineers who want to reproduce the build, and app developers who want to call the model — on Spark-class hardware (GB10, 128 GB unified memory) or a free cloud GPU.
| Variant |
|---|
| builder sweet spot |
| user |
- The user notebook pins the Q5_K_M quant on both the Spark and cloud paths Q5_K_M is the fast+accurate sweet spot — 10.04 wikitext perplexity at 35 tok/s on a GB10, within 0.8% of Q6_K's accuracy. Heavier/lighter variants are one keyword away; see the sibling GGUF card for the full matrix.
- The builder notebook's heavy steps (baseline, corpus, train, probe, quantize) render the recorded Spark run, not a live re-execution 5 recorded Spark-only cells; the remaining cells (feasibility envelope, backend decision, the four viz figures, publish dry-run) run live on any runtime.