Skip to main content

Economics Scenarios

Cost, resource pricing, staffing, and investment tradeoffs.

All domains · Classes A–Z

Source locations

  • Inputs and calculations: mlsysim/engine/scenario_definitions/economics.py.
  • Named configurations: mlsysim/engine/scenario_catalog/economics/.
  • Result schemas: mlsysim/engine/result_types/economics.py.

Public imports and existing class reference URLs remain stable.

Scenario contracts

  • AdaptationPaybackScenario: A one-time adaptation that cuts each task’s model usage, against its incremental cost.
  • ArchitectureChoiceScenario: Single-call designs and a bounded loop under one check, with a human fallback for rejects.
  • BatchServingCostScenario: One accelerator rented at price, serving batches back to back: cost per request by batch size.
  • CanaryScheduleScenario: A staged rollout that needs samples_per_variant guardrail samples per stage at request_rate; stages is the configured ladder of (traffic share, duration).
  • ClickLossScenario: A silent click-through regression from ctr_before to ctr_after at request_rate, caught after detection_time; each click is worth value_per_click.
  • CloudEdgeCostScenario: Serving a network of sites from the cloud (pay per image) or from a device at each site (buy up front).
  • CohortAttemptCostScenario: One configuration’s cohort of tasks, one bounded attempt each, all charges settled.
  • CompactionPaybackScenario: One compaction of a billed trajectory: a summary resent fresh, then shorter cached reads.
  • ConservedBudgetScenario: A root budget granted to two children; the second stops with a remote job billed late.
  • DedicatedBreakEvenScenario: Renting a matched-capability API against owning capacity at a fixed hourly cost.
  • DisclosurePenaltyScenario: Penalties for an incomplete account: days_withheld at daily_maximum each, plus others (name -> amount), all in USD.
  • ExplanationLoadScenario: Reasons owed for every denial: decisions_per_day at denial_share, each explained by a sampling attributor of samples model evaluations or by exact Shapley over features.
  • FeatureHistoryScenario: Full-snapshot feature history: entities x features values every update_interval, kept for retention, each row a value, an entity key, and timestamps timestamps.
  • IdleCapacityCostScenario: gpus accelerators held idle for duration at device_hour_rate.
  • KingmanQueueScenario: One server under Kingman’s approximation at two utilizations, with a holding price.
  • LifecycleTcoScenario: Monthly lifecycle cost in four terms (training, inference, data, iteration), each counted once.
  • ModelCascadeScenario: A tiered cascade over a completed cohort, every exit under one gate, against the top tier alone.
  • OperationalLoadScenario: Assumed operational-load shapes for N models: alerts a N, deployments N ln N, and pairwise conflicts c N^2 against one team’s team_capacity.
  • OptimizationPaybackScenario: An optimization costing implementation_cost that cuts a monthly_bill by reduction.
  • OwnVsRentScenario: Owning gpus accelerators against renting them at rent_rate per GPU-hour for utilization of every hour, over years.
  • PlatformBenefitScenario: A shared platform costing platform_cost per month that saves each of models model teams hours_saved per month at engineer_rate.
  • ResendCacheBillScenario: An append-only trajectory (TrajectoryResendScenario) billed under one tariff, with and without reuse.
  • RetryPolicyScenario: A cheap attempt retried up to a cap, run as a batch, or one stronger attempt.
  • RevenueRegressionScenario: A metric regression that cuts revenue in proportion for undetected (or for alerted with an alert and containment); revenue is weekly_revenue per week.
  • ReviewStaffingScenario: Substantive human review: appeal_rate of decisions_per_day at time_per_case each, staffed in shift-long shifts; optionally against a reported compare_cases handled at compare_time_per_case.
  • RolloutExposureScenario: Users exposed until rollback under an all-at-once cutover against a canary share, with the same request rate, harm, and time to rollback.
  • SerialEpisodeScenario: One serial episode as disjoint intervals; the model’s intervals sped up by model_speedup.
  • ServiceLifecycleCostScenario: A service’s multi-year cost in three terms: repeated training cycles, recurring inference, and operations, with a GPU-hour carbon factor.
  • ServingCostScenario: One model version’s training spend against its first year of serving.
  • ServingInstanceCostScenario: Instances with an hourly price and a saturated request rate: cost per request, and when the small instance sized to the load undercuts one large instance.
  • SpeculativeEpisodeScenario: Speculative decoding on a serial episode’s model time, at two draft acceptance levels.
  • SpotEffectiveCostScenario: Spot capacity priced per hour of retained progress.
  • SpotRunScenario: A training run of run_duration on fleet, on demand against spot capacity.
  • SupervisionLaborScenario: The person-hours a supervised fleet creates in one operating_day: an assistant staffed the whole day (busy at queue’s utilization, watching otherwise) plus sweeps corridor sweeps.
  • TokenPriceComparisonScenario: Two cohort configurations under one acceptance contract: does the cheaper token win?
  • TrainingCampaignCostScenario: runs_per_year training runs of run_low to run_high on an owned cluster (ownership) against renting the same GPUs only while each run lasts.
  • TrajectoryAdmissionScenario: A stationary admitted population of trajectories against a token-per-minute quota.
  • UtilizationGainScenario: A fleet of fleet_gpus raised from utilization_before to utilization_after.
  • WorkloadLeverScenario: Attempt cost by term for several workloads, and three levers on cost per accepted task.
Back to top