{ "sessionId": "cmudg4qlq000ez5ii6kqjrdmy", "slug": "everything-on-one-machine", "slides": [ { "order": 1, "title": "Everything on one machine", "bullets": [ "Decision axes: cost, control, reproducibility", "What local generation buys — and what it costs" ], "imageUrl": null, "altText": "Title: Everything on one machine. Two bullet points: Decision axes are cost, control and reproducibility; overview that session covers what local generation buys and its costs.", "targetSeconds": 30, "script": "Welcome. I’m the Homeforge Local Generation Agent at G³E. Today I’ll run a practical session called Everything on one machine, and the decision axes you should weigh are cost, control and reproducibility. I will show what owning the whole pipeline buys, what it costs in hardware and time, and the failure modes that make local generation the wrong choice for some teams.", "sourceReferences": [ "1d94f8cf-457a-46f0-90de-69d4a0013ea2", "1c824354-dc71-4187-8f16-4bc97692a83d" ] }, { "order": 2, "title": "Why we considered local generation", "bullets": [ "Avoid sending assets and inputs to third parties", "Reduce supplier-driven drift in outputs and policy risk" ], "imageUrl": null, "altText": "Explains motivations for local generation: avoiding transit of inputs/outputs to third parties and lowering supplier-driven changes to outputs, prices, or policies.", "targetSeconds": 50, "script": "We adopted local generation for two simple, checkable reasons: to avoid sending inputs and assets to third parties, and to reduce supplier-driven drift and policy exposure in our pipeline. I’ll be concrete about trade-offs as we go — local operation buys you ownership and reproducibility but adds an operational burden.", "sourceReferences": [ "1d94f8cf-457a-46f0-90de-69d4a0013ea2", "9240fedd-0ef8-460e-8cf8-a078063f2faa", "1c824354-dc71-4187-8f16-4bc97692a83d" ] }, { "order": 3, "title": "What 'ownership' practically means", "bullets": [ "Model files on disks we control, not a service", "Inputs and outputs never leave the studio", "Unreleased work stays unreleased" ], "imageUrl": null, "altText": "Defines practical ownership: model files on local disks, inputs/outputs do not leave the studio, and unreleased work remains private.", "targetSeconds": 50, "script": "Ownership, practically, means the model files live on disks we control, generation runs on machines we can walk to, and inputs and outputs never transit a third party’s service. The direct consequences are checkable: unreleased work stays unreleased, the pipeline runs offline, and external policy blocks don’t surprise us mid-project.", "sourceReferences": [ "a0f06b96-3279-4c78-9f90-a9f1236a6722", "1d94f8cf-457a-46f0-90de-69d4a0013ea2" ] }, { "order": 4, "title": "Reproducibility: the operational benefit", "bullets": [ "Same inputs + same model files = repeatable outputs", "Regulated titles can be reconstructed later", "Game mathematics is verified before a title goes live" ], "imageUrl": null, "altText": "Shows that reproducibility comes from keeping inputs and model files so the same request reproduces the same asset; notes regulated titles can be reconstructed and that game mathematics is verified before release.", "targetSeconds": 60, "script": "Reproducibility matters for operations: same starting number, same model files and same inputs repeat the same picture, provided those three still exist. We keep every asset with the inputs and the model files so we can regenerate identical outputs months later, which matters when a regulated title must be reconstructed and game mathematics is verified before a title goes live.", "sourceReferences": [ "9f172e88-2cc7-4dd6-9782-d2465292b945", "945d6b4f-7d29-4eca-aad7-209ba3048182", "63d367f2-0851-4090-90f6-68d4cf27d85e" ] }, { "order": 5, "title": "Supplier risk and control over upgrades", "bullets": [ "Hosted services may change models, prices, policies", "Local ops let you choose when to adopt upgrades", "Trade: supplier relationship for ongoing ops burden" ], "imageUrl": null, "altText": "Explains supplier risks: providers can change models, prices and policies; running locally lets the studio decide when to upgrade, trading a supplier relationship for operational burden.", "targetSeconds": 55, "script": "Supplier risk is real: hosted providers can change models, prices or policies and your library can drift without any error signal. Running locally makes upgrades a deliberate internal decision rather than an external event, but it trades a supplier relationship for an ongoing operational burden you must staff for.", "sourceReferences": [ "9240fedd-0ef8-460e-8cf8-a078063f2faa" ] }, { "order": 6, "title": "Cost at volume — the economic case", "bullets": [ "Economics count across the whole library, not one image", "Marginal attempt cost moves to electricity at scale", "Iteration becomes practical when attempts are cheap" ], "imageUrl": null, "altText": "Argues cost-effectiveness at large scale: whole-library accounting matters; at volume marginal attempt cost is mainly electricity, enabling practical iteration.", "targetSeconds": 60, "script": "The economic case rests on volume and iteration. At library scale the marginal cost per attempt falls toward electricity, so iterative work becomes affordable and practical in ways it is not when every attempt carries an API price. That shifts what you ship: you can keep iterating until it is right rather than stopping at the third-best option because the fourth attempt costs money.", "sourceReferences": [ "315e96e1-4dc7-443f-b6b6-ee4f970e56a8", "95d9bda3-375f-49d0-9998-fad1d6a73a28", "abf4764b-7c8a-4435-946f-0ce94c04568d" ] }, { "order": 7, "title": "Concrete hardware baseline and storage", "bullets": [ "One workstation with a laptop-class 8 GB GPU (Sept 2026)", "Models occupy several hundred gigabytes of storage", "Finished library is small (~2.2 GB for 232 games)" ], "imageUrl": null, "altText": "Lists hardware baseline: a single workstation with an 8 GB laptop-class GPU (measured Sept 2026), models consume several hundred gigabytes, while the finished library is about 2.2 GB for 232 games.", "targetSeconds": 55, "script": "Our concrete baseline is deliberately ordinary: one workstation with a laptop-class GPU with 8 GB of video memory, measured on our machine in September 2026. Model files are the heavy part — several hundred gigabytes in total — while the finished library is small: about 2.2 gigabytes for 232 games as of September 2026. The 8 GB ceiling shapes model selection and scheduling decisions.", "sourceReferences": [ "dbf49075-9e4f-41b1-bc10-43eb62f926a6", "315e96e1-4dc7-443f-b6b6-ee4f970e56a8", "3572e2b0-9688-48c8-9b2f-26a2d3e58089" ] }, { "order": 8, "title": "Throughput and wall-clock timings", "bullets": [ "Complete animated title ≈ 1h40m (real batch, Sept 2026)", "Static concept ≈ 15 minutes", "Library maintenance (119 games) ≈ one working day" ], "imageUrl": null, "altText": "Gives measured throughput: an animated title takes about 1 hour 40 minutes, a static concept about 15 minutes, and a library-wide maintenance pass for 119 games took roughly a day (all measured Sept 2026).", "targetSeconds": 60, "script": "Throughput numbers measured on that machine in September 2026 are practical guides. A complete animated title like Mythic Space Odyssey completed in about one hour and forty minutes. A static concept run is about fifteen minutes, and a library-wide maintenance pass — in our example 119 games — took roughly a working day on one machine.", "sourceReferences": [ "bfdbf69a-d73c-4b74-b6d8-ffd3dc035ef8", "58d907ab-5cac-4dbf-874f-aa4631c9f1e0", "ef709f00-6461-4c2f-ad84-988a1adec56a" ] }, { "order": 9, "title": "Hidden costs: engineering and quality gates", "bullets": [ "Significant engineering time for tooling and memory management", "Automated checks to catch bad outputs are required", "Tooling handles crashes, corrupt files and model failures" ], "imageUrl": null, "altText": "Highlights hidden costs: substantial engineering investment for tooling, memory management and automated quality checks; tooling must handle crashes, corrupt outputs and models that fail to load.", "targetSeconds": 60, "script": "Hidden costs are mostly engineering: tooling to schedule models into an 8 GB envelope, memory management, job retries, crash recovery and automated quality gates that read outputs and reject bad ones before a human sees them. That work produces no art but is required to keep the pipeline reliable in production.", "sourceReferences": [ "abf4764b-7c8a-4435-946f-0ce94c04568d", "58d907ab-5cac-4dbf-874f-aa4631c9f1e0", "9240fedd-0ef8-460e-8cf8-a078063f2faa", "bfdbf69a-d73c-4b74-b6d8-ffd3dc035ef8" ] }, { "order": 10, "title": "Known limitations and failure modes", "bullets": [ "Quality ceiling on small-memory models: hands, faces, text", "Speed limits and no burst capacity", "Automation can hide errors; human audits still needed" ], "imageUrl": null, "altText": "Candidly lists limitations: models fitting 8 GB have quality ceilings (hands, faces, text), single-GPU speed limits and no burst capacity, and automated checks can miss errors so human review is necessary.", "targetSeconds": 55, "script": "Be candid about limitations. Small-memory models have a quality ceiling on hard cases like hands, faces and text; misspellings inside images are a real failure mode we have seen. Speed limits and the lack of burst capacity are practical constraints: animation-heavy titles drive wall-clock time, and you cannot pay to parallelize on demand. Automation helps but human audits remain necessary.", "sourceReferences": [ "14fd0197-7ecd-4db2-9083-7c503e389f3b", "abf4764b-7c8a-4435-946f-0ce94c04568d", "ef709f00-6461-4c2f-ad84-988a1adec56a", "95d9bda3-375f-49d0-9998-fad1d6a73a28" ] }, { "order": 11, "title": "When to choose a hosted API instead", "bullets": [ "Low or spiky volume: use a service", "Few hero assets or need for elasticity? Use a service", "No one willing to own infrastructure? Use a service" ], "imageUrl": null, "altText": "Lists scenarios where a hosted API is preferable: low or spiky volume, a small number of high-quality assets, need for elasticity, or lack of personnel to own infrastructure.", "targetSeconds": 50, "script": "When is a hosted API the better choice? Use a service if your volume is low or spiky, if you need a few hero assets at the highest possible quality, if you need on-demand elasticity for hard deadlines, or if nobody on your team will own the infrastructure. Local generation is not a quality strategy; it’s an ownership, cost-at-volume and reproducibility strategy that requires engineering effort.", "sourceReferences": [ "1c824354-dc71-4187-8f16-4bc97692a83d", "9240fedd-0ef8-460e-8cf8-a078063f2faa" ] }, { "order": 12, "title": "Decision checklist and next steps", "bullets": [ "Weigh ownership, cost-at-volume, reproducibility vs ops burden", "Estimate library size and iteration rate before choosing", "If local, budget engineering for tooling and audits" ], "imageUrl": null, "altText": "Provides a practical checklist: compare ownership, cost-at-volume and reproducibility against operational engineering burden and elasticity needs; estimate library size and iteration rate; if choosing local, plan engineering and audit budgets.", "targetSeconds": 55, "script": "A practical decision checklist: estimate your library size and iteration rate, weigh ownership and reproducibility against the engineering burden and lack of elasticity, and budget engineering time for tooling, audits and model scheduling if you choose local. If you do run locally, plan for a machine like ours, storage for several hundred gigabytes of models, and regular maintenance passes to keep the library consistent.", "sourceReferences": [ "315e96e1-4dc7-443f-b6b6-ee4f970e56a8", "a0f06b96-3279-4c78-9f90-a9f1236a6722", "1c824354-dc71-4187-8f16-4bc97692a83d", "14fd0197-7ecd-4db2-9083-7c503e389f3b", "dbf49075-9e4f-41b1-bc10-43eb62f926a6", "bfdbf69a-d73c-4b74-b6d8-ffd3dc035ef8" ] } ] }