$$ \newcommand{\AbsoluteConicImageEntry}{B} \newcommand{\AbsoluteConicImageMatrix}{\mathbf{B}} \newcommand{\AbsoluteConicVector}{\mathbf{b}} \newcommand{\AcceleratedEpisodeTime}{T'} \newcommand{\AcceleratedFractionSpeedup}{G} \newcommand{\AccelerationNoiseDensityMatrix}{\mathbf{Q}_c} \newcommand{\AccelerationNoiseSpectralDensity}{q_c} \newcommand{\AccelerationWhiteNoise}{w} \newcommand{\AcceleratorBatchTime}{T_{\text{GPU}}} \newcommand{\AcceleratorConsumptionRate}{R_{\text{accel}}} \newcommand{\AcceleratorCount}{N_{\text{GPU}}} \newcommand{\AcceleratorDataConsumptionRate}{R_{\text{consumption}}} \newcommand{\AcceleratorGain}{G_{\text{accel}}} \newcommand{\AcceleratorHourlyPrice}{R_{\text{GPU/hr}}} \newcommand{\AcceleratorMemoryBandwidth}{\text{BW}_{\text{accelerator}}} \newcommand{\AcceleratorRailVoltage}{V_{\text{rail}}} \newcommand{\AcceleratorSecondsPerQuery}{S_{\text{GPU/query}}} \newcommand{\AcceleratorSupplyCurrent}{i} \newcommand{\AcceleratorTargetQueryRate}{R_{\text{GPU,target}}} \newcommand{\AcceleratorsPerNode}{G_{\text{node}}} \newcommand{\AccelerometerBias}{b_a} \newcommand{\AcceptanceFraction}{\alpha} \newcommand{\AcceptanceIntervalLowerLimit}{L} \newcommand{\AcceptanceIntervalUpperLimit}{U} \newcommand{\AcceptanceProbability}{p_{\text{acc}}} \newcommand{\AcceptedInfluences}{\text{Inf}} \newcommand{\AcceptedInputSet}{\mathcal{A}_{\tau}} \newcommand{\AcceptedLabelCount}{d} \newcommand{\AcceptedOutcomePayoff}{V} \newcommand{\AcceptedSampleCount}{X} \newcommand{\AcceptedTaskMeanCost}{C_{\text{succ}}} \newcommand{\AcceptedTasks}{N_{\text{acc}}} \newcommand{\AcceptingStateSet}{F} \newcommand{\AccessAttemptTime}{t} \newcommand{\AccountQueryDistribution}{p_{\text{user}}} \newcommand{\AccumulatedProcessNoiseCovariance}{\mathbf{Q}_d} \newcommand{\AccumulatedSyncTime}{T_{\text{sync}}} \newcommand{\AccumulatedUpdateTime}{T_{\text{effective}}} \newcommand{\AccumulationStepCount}{k} \newcommand{\AccuracyAfterDeployment}{\text{Accuracy}} \newcommand{\AccuracyDecayRate}{\gamma} \newcommand{\AccuracyPayoffPerQuery}{V} \newcommand{\AchievedBrakingDeceleration}{a} \newcommand{\AchievedKernelBandwidth}{\text{BW}_{\text{effective}}} \newcommand{\AcquisitionEpoch}{t_{\text{acq}}} \newcommand{\ActVariationalObjective}{\mathcal{L}_{\text{ACT}}} \newcommand{\ActionBinCount}{B} \newcommand{\ActionChunk}{\mathbf{A}} \newcommand{\ActionChunkHorizon}{H} \newcommand{\ActionChunkIndex}{k} \newcommand{\ActionDimension}{d_a} \newcommand{\ActionExecutionRate}{f_{\text{exec}}} \newcommand{\ActionFilterCutoffFrequency}{f_{\text{cutoff}}} \newcommand{\ActionLowerBound}{\mathbf{a}_{\min}} \newcommand{\ActionMagnitudeBound}{a_{\max}} \newcommand{\ActionRangeMaximum}{a_{\max}} \newcommand{\ActionRangeMinimum}{a_{\min}} \newcommand{\ActionRecoverableFraction}{\rho_{a}} \newcommand{\ActionResidualVector}{\mathbf{r}} \newcommand{\ActionSpace}{\mathcal{A}} \newcommand{\ActionTokenPrefix}{a_{<j}} \newcommand{\ActionUpperBound}{\mathbf{a}_{\max}} \newcommand{\ActivationCheckpointCount}{n_{\text{ckpt}}} \newcommand{\ActivationFunction}{f} \newcommand{\ActivationInput}{x} \newcommand{\ActivationLipschitzBound}{L_{\phi}} \newcommand{\ActivationMatrix}{\mathbf{A}} \newcommand{\ActivationMemory}{M_{\text{activations}}} \newcommand{\ActivationPayloadSize}{M_{\text{act}}} \newcommand{\ActivationStagingTime}{t_{\text{activate}}} \newcommand{\ActivationVector}{\mathbf{a}} \newcommand{\ActiveContactIndex}{k} \newcommand{\ActiveControlTorque}{\mathbf{u}_{\text{active}}} \newcommand{\ActiveInferencePower}{P_{\text{active}}} \newcommand{\ActiveLeaseCount}{N_{\text{active}}} \newcommand{\ActiveMotionDuration}{T_{\text{motion}}} \newcommand{\ActiveParameterCount}{P_{\text{model}}} \newcommand{\ActivePrefillRequestSet}{\mathcal{P}_{\text{active}}} \newcommand{\ActiveSchemaSet}{\mathcal{S}} \newcommand{\ActiveTargetTokenCount}{N_{\text{active}}} \newcommand{\ActorAccelerationBound}{a_{k,\max}} \newcommand{\ActorBodyRadius}{r} \newcommand{\ActorUpdateDelayCount}{d} \newcommand{\ActuatedJointAccelerations}{\ddot{\mathbf{q}}_j} \newcommand{\ActuatedJointBiasForces}{\mathbf{h}_j} \newcommand{\ActuatedJointCoordinates}{\mathbf{q}_j} \newcommand{\ActuationSelectionBaseBlock}{\mathbf{S}_b} \newcommand{\ActuationSelectionMatrix}{\mathbf{S}} \newcommand{\ActuatorAxisCount}{N_{\text{axes}}} \newcommand{\ActuatorBiasEffort}{u_{\text{bias}}} \newcommand{\ActuatorCyclePeriod}{t_{\text{cycle}}} \newcommand{\ActuatorDutyCycle}{D_{\text{cycle}}} \newcommand{\ActuatorEffort}{u} \newcommand{\ActuatorOffTime}{t_{\text{off}}} \newcommand{\ActuatorOnTime}{t_{\text{on}}} \newcommand{\ActuatorResponseTime}{T_{\text{act}}} \newcommand{\ActuatorTorqueLowerBound}{\mathbf{u}_{\min}} \newcommand{\ActuatorTorqueUpperBound}{\mathbf{u}_{\max}} \newcommand{\AdamFirstMoment}{m} \newcommand{\AdamMomentDecayRate}{\beta} \newcommand{\AdamSecondMoment}{v} \newcommand{\AdaptationEnergyAllowance}{E_{\text{slack}}} \newcommand{\AdaptationInvestmentCost}{C_{\text{invest}}} \newcommand{\AdaptationLatencyIncrease}{\Delta L_{\text{lat,fg}}^{\text{wc}}} \newcommand{\AdaptationModule}{g_{\psi}} \newcommand{\AdaptationPeakMemory}{M_{\text{peak}}} \newcommand{\AdaptationPowerIncrement}{P_{\text{update}}} \newcommand{\AdaptationWindowEnergy}{E_{\text{update}}} \newcommand{\AdaptedHiddenActivation}{\mathbf{h}'} \newcommand{\AdaptedTaskCost}{C_{\text{task, adapt}}} \newcommand{\AdaptedWeightMatrix}{\mathbf{W}_{\text{adapted}}} \newcommand{\AdapterActivationFunction}{\sigma} \newcommand{\AdapterAssignmentVector}{\mathbf{m}} \newcommand{\AdapterDownProjectionMatrix}{\mathbf{A}} \newcommand{\AdapterIndex}{k} \newcommand{\AdapterInitializationStandardDeviation}{\sigma} \newcommand{\AdapterRank}{r} \newcommand{\AdapterScalingFactor}{\gamma} \newcommand{\AdapterUpProjectionMatrix}{\mathbf{B}} \newcommand{\AdjacentNeighboringDataset}{X'} \newcommand{\AdjacentQueryResult}{v'} \newcommand{\AdminLeaseTime}{T_{\text{admin}}} \newcommand{\AdmissibleBacklogCount}{n} \newcommand{\AdmissibleControlSet}{\mathcal{U}_{\text{adm}}} \newcommand{\AdmissibleDisturbanceSet}{\mathcal{W}} \newcommand{\AdmissionCheckCount}{n_{\text{chk}}} \newcommand{\AdmissionCheckIndex}{i} \newcommand{\AdmissionDecisionEvent}{e_{\text{auth}}} \newcommand{\AdmissionInclusivePrebrakeDelay}{T_{\text{true}}} \newcommand{\AdmissionRouteYield}{Y} \newcommand{\AdmittedAttemptCap}{N} \newcommand{\AdmittedCommand}{u} \newcommand{\AdmittedContactForce}{F^*} \newcommand{\AdmittedControlCommand}{\mathbf{u}} \newcommand{\AdmittedSpeedCommand}{v^*} \newcommand{\AdmittedTargetPosition}{\hat{\mathbf{p}}_{\text{target}}} \newcommand{\AdmittedWorkUnitCount}{m} \newcommand{\AdvantageStabilizer}{\epsilon_{\text{stab}}} \newcommand{\AdversarialDisturbance}{\mathbf{d}} \newcommand{\AdversarialExample}{x_{\text{adv}}} \newcommand{\AdversarialInputLength}{n} \newcommand{\AdversarialPenaltyWeight}{\lambda_{\text{adv}}} \newcommand{\AdversarialPerturbation}{\boldsymbol{\delta}_{\text{adv}}} \newcommand{\AdversarialPerturbationBudget}{\epsilon_{\text{adv}}} \newcommand{\AdversaryLoss}{\mathcal{L}_{\text{adv}}} \newcommand{\AffordanceFrame}{\mathcal{F}_{\text{affordance}}} \newcommand{\AffordanceSuccessEstimate}{V_{\text{policy}}} \newcommand{\AgeBlindTravel}{\Delta x_{\text{blind}}} \newcommand{\AgeCheckInstant}{t_{\text{curr}}} \newcommand{\AggregateServerPower}{P_{\text{servers}}} \newcommand{\AggregateSlotWork}{W} \newcommand{\AggregatedRecoveryDataset}{\mathcal{D}} \newcommand{\AggregatedSurrogateLoss}{\epsilon_N} \newcommand{\AggregationLearnedPolicy}{\hat{\pi}} \newcommand{\AggregationLearnerStateDistribution}{d_{\hat{\pi}_i}} \newcommand{\AggregationRoundCount}{N} \newcommand{\AggregationRoundIndex}{i} \newcommand{\AggregationRoundTrajectorySet}{\mathcal{T}} \newcommand{\AiStandaloneSensitivity}{S_{\text{AI}}} \newcommand{\AisleTravelSpeed}{v_{\text{aisle}}} \newcommand{\AisleWidth}{w} \newcommand{\AlertCheckCount}{N_{\text{tests}}} \newcommand{\AlertFalsePositiveRate}{\alpha_{\text{fp}}} \newcommand{\AlgorithmTaxonomyAxis}{\mathsf{Algorithm}} \newcommand{\AliasedVibrationFrequency}{f_{\text{alias}}} \newcommand{\AliasingHarmonicIndex}{k} \newcommand{\AllGatherCompletionTime}{T_{\text{allgather}}} \newcommand{\AllOnesVector}{\mathbf{1}} \newcommand{\AllReduceCompletionTime}{T_{\text{allreduce}}} \newcommand{\AllReduceMinimumBandwidthTime}{T_{\text{bandwidth}}^{\text{min}}} \newcommand{\AllRunsPassEstimate}{\widehat{r}} \newcommand{\AllToAllCompletionTime}{T_{\text{alltoall}}} \newcommand{\AllToAllExchangeTime}{T} \newcommand{\AllocatedBlockCount}{N_{\text{blocks}}} \newcommand{\AllocatedHazardRate}{\lambda_{\text{alloc}}} \newcommand{\AllocatedWallTime}{T_{\text{wall}}} \newcommand{\AllowableCollisionEnergy}{E_{k, \text{allow}}} \newcommand{\AllowableRailDroop}{\Delta V_{\text{droop, max}}} \newcommand{\AllowableRailExcursion}{\Delta V_{\max}} \newcommand{\AllowableWindingTemperatureRise}{\Delta T_{\max}} \newcommand{\AllowedTokenSet}{\mathcal{V}_{\text{allow}}} \newcommand{\AllowedViolationFraction}{V^{\text{allow}}} \newcommand{\AlphabetByte}{b} \newcommand{\AlternateModelInput}{x'} \newcommand{\AmbientDimension}{D} \newcommand{\AmbientTemperature}{T_{\text{amb}}} \newcommand{\AmortizedTurnCost}{\bar{C}_{\text{turn}}} \newcommand{\AngularAcceleration}{\boldsymbol{\alpha}} \newcommand{\AngularClearance}{\theta_{\text{clear}}} \newcommand{\AngularClearanceRate}{\dot{\theta}_{\text{clear}}} \newcommand{\AngularFrequency}{\omega} \newcommand{\AngularSpeed}{\omega} \newcommand{\AngularVelocity}{\boldsymbol{\omega}} \newcommand{\AngularVelocityDerivative}{\dot{\boldsymbol{\omega}}} \newcommand{\AnnualQueryVolume}{Q_{\text{annual}}} \newcommand{\AnonymitySetSize}{k_{\text{anon}}} \newcommand{\AntiWindupTrackingTimeConstant}{T_t} \newcommand{\AntialiasingFilterVariance}{s} \newcommand{\ApiAccount}{u} \newcommand{\ApparentContrast}{C} \newcommand{\AppearanceRealityGap}{\Delta_{\text{vis}}} \newcommand{\AppliedForce}{F} \newcommand{\AppliedLoadCycleCount}{n} \newcommand{\ApproachChannelCount}{K_a} \newcommand{\ApproachDirection}{\hat{\mathbf{a}}_{\text{approach}}} \newcommand{\ApproachPosition}{x} \newcommand{\ApproachPredicate}{P_{\text{approach}}} \newcommand{\ApproachSpeed}{v_{\text{app}}} \newcommand{\ApprovalCatchFraction}{q} \newcommand{\ApprovalHeldTrajectories}{N_{\text{held}}} \newcommand{\ApproximatingDistribution}{q} \newcommand{\ArbitrationFieldBitCount}{B_{\text{arb},i}} \newcommand{\ArcObstacleDistance}{d_{\text{arc}}} \newcommand{\ArchitectureResourceCost}{C} \newcommand{\ArchitectureSearchSpace}{\mathcal{A}} \newcommand{\ArcsineEffectSize}{h} \newcommand{\ArgumentLegConfidence}{r} \newcommand{\ArgumentLegCount}{m} \newcommand{\ArithmeticIntensity}{I} \newcommand{\ArmStoppingDeceleration}{a_{\text{arm}}} \newcommand{\ArmSuccessProbability}{p} \newcommand{\ArmingSettleDuration}{t_{\text{settle}}} \newcommand{\ArrivalOffsetTravel}{\Delta x} \newcommand{\ArrivalRate}{\lambda_{\text{arr}}} \newcommand{\ArrivalStampOffset}{\Delta t_{\text{recv}}} \newcommand{\ArrivalTimestamp}{t_{\text{recv}}} \newcommand{\ArtifactVersion}{v} \newcommand{\AssessedContactForceLimit}{F_{\text{limit}}} \newcommand{\AssignedJobGpu}{g} \newcommand{\AssociationCostEntry}{c} \newcommand{\AssuranceClaim}{C} \newcommand{\AsymptoticTightBound}{\Theta} \newcommand{\AtmosphericExtinctionCoefficient}{\beta_{\text{atm}}} \newcommand{\AttackStepsPgd}{K_{\text{PGD}}} \newcommand{\AttackedTrialCount}{n} \newcommand{\AttainableComputeRate}{R_{\text{attain}}} \newcommand{\AttemptCleanupCost}{C_{\text{cleanup}}} \newcommand{\AttemptCost}{C_{\text{attempt}}} \newcommand{\AttemptCycleDuration}{t_{\text{cyc}}} \newcommand{\AttemptDuration}{t_{\text{att}}} \newcommand{\AttemptGenerationTime}{T_{\text{gen}}} \newcommand{\AttemptPassProbability}{p} \newcommand{\AttemptRuntimeOverheadCost}{C_{\text{runtime}}} \newcommand{\AttemptVerificationCost}{C_{\text{verify}}} \newcommand{\AttentionHeadCount}{N_{\text{heads}}} \newcommand{\AttentionHeadDimension}{d_{\text{head}}} \newcommand{\AttentionHeadIndex}{i} \newcommand{\AttentionHeadOutput}{\mathbf{O}} \newcommand{\AttentionKeyMatrix}{\mathbf{K}} \newcommand{\AttentionOutputMatrix}{\mathbf{O}} \newcommand{\AttentionOutputProjectionMatrix}{\mathbf{W}_{O}} \newcommand{\AttentionQueryMatrix}{\mathbf{Q}} \newcommand{\AttentionScoreEntry}{S_{ij}} \newcommand{\AttentionScoreMatrix}{\mathbf{S}} \newcommand{\AttentionScoreRow}{\mathbf{S}_{i, \cdot}} \newcommand{\AttentionScoreSummand}{S_{ik}} \newcommand{\AttentionScoreTile}{\mathbf{S}_{ij}} \newcommand{\AttentionValuesMatrix}{\mathbf{V}} \newcommand{\AttentionValuesProjectionMatrix}{\mathbf{W}_{V}} \newcommand{\AttentionValuesSourceMatrix}{\mathbf{X}_{V}} \newcommand{\AttentionValuesVector}{\mathbf{v}} \newcommand{\AttentionWeightEntry}{A_{ij}} \newcommand{\AttentionWeightMatrix}{\mathbf{A}} \newcommand{\AttentionWeightVector}{\mathbf{a}} \newcommand{\AttitudeError}{\theta_{\text{att}}} \newcommand{\AttributionFeatureCount}{n_{\text{feat}}} \newcommand{\AuditGroupRecordCount}{n_{\text{records}}} \newcommand{\AuthorityExposureLevel}{A} \newcommand{\AutocorrelationLagIndex}{k} \newcommand{\AutoencoderReconstructionError}{\mathcal{L}_{\text{rec}}} \newcommand{\AutomatedResetTime}{t_{\text{reset,auto}}} \newcommand{\AutomatonStateSet}{Q} \newcommand{\AutomatonTransitionFunction}{\delta} \newcommand{\AutonomousExecutionComputeCost}{C_{\text{compute}}} \newcommand{\AutoscalingDecisionTime}{T_{\text{decide}}} \newcommand{\AutoscalingDetectionTime}{T_{\text{detect}}} \newcommand{\AutoscalingResponseTime}{T_{\text{response}}} \newcommand{\AvailabilityObjective}{S_{\text{availability}}} \newcommand{\AvailableBrakingDistance}{D_{\text{avail}}} \newcommand{\AvailableDeceleration}{a} \newcommand{\AvailableObservations}{\mathcal{O}_{\text{avail}}} \newcommand{\AverageCopperLossPower}{\bar{P}_{\text{loss}}} \newcommand{\AverageOnlineRegret}{\gamma_N} \newcommand{\AveragePower}{P_{\text{avg}}} \newcommand{\AverageStateVisitationDistribution}{\bar{d}} \newcommand{\AxiBurstLength}{A_{\text{len}}} \newcommand{\AxisGridPointCount}{N} \newcommand{\AzimuthAngle}{\theta_{\text{az}}} \newcommand{\BackEmfVoltage}{e_{\text{bemf}}} \newcommand{\BacklashAngle}{\theta_{\text{backlash}}} \newcommand{\BackwardEulerEigenvalue}{\lambda_{\text{BE}}} \newcommand{\BackwardEulerTransitionMatrix}{\mathbf{A}_{\text{BE}}} \newcommand{\BackwardPassTime}{T_{\text{backward}}} \newcommand{\BackwardReachableTube}{\mathcal{R}} \newcommand{\BalanceDivergenceTime}{\tau_{\text{fall}}} \newcommand{\BallRadius}{r} \newcommand{\BallVolume}{V_D} \newcommand{\Bandwidth}{\text{BW}} \newcommand{\BankConflictPenalty}{\Delta t_{\text{conflict}}} \newcommand{\BarrierConstraintBound}{b_{\text{cbf}}} \newcommand{\BarrierConstraintCount}{K_b} \newcommand{\BarrierConstraintNormal}{\mathbf{a}_{\text{cbf}}} \newcommand{\BarrierFunction}{h} \newcommand{\BarrierFunctionRate}{\dot{h}} \newcommand{\BarrierHalfSpaceControlSet}{\mathcal{U}_{\text{safe}}} \newcommand{\BarrierMargin}{\delta} \newcommand{\BarrierNormalizationScale}{h_{\text{scale}}} \newcommand{\BarrierProjectionLagrangian}{L_{\text{Lag}}} \newcommand{\BarrierProjectionMultiplier}{\lambda} \newcommand{\BarrierRelativeDegree}{r} \newcommand{\BaseAbscissaVelocity}{\dot{x}} \newcommand{\BaseAccelerationCommand}{a} \newcommand{\BaseBatchSize}{B_{\text{base}}} \newcommand{\BaseCameraRotation}{\mathbf{R}_{\text{base}}^{\text{cam}}} \newcommand{\BaseCameraTransform}{\mathbf{T}_{\text{base}}^{\text{cam}}} \newcommand{\BaseCameraTranslation}{\mathbf{t}_{\text{base}}^{\text{cam}}} \newcommand{\BaseFlangeTransform}{\mathbf{T}_{\text{base}}^{\text{flange}}} \newcommand{\BaseForwardSpeed}{v} \newcommand{\BaseFramePoint}{\mathbf{p}_{\text{base}}} \newcommand{\BaseHeadingRate}{\dot{\theta}_{\text{head}}} \newcommand{\BaseJointInertiaCoupling}{\mathbf{M}_{bj}} \newcommand{\BaseLateralPosition}{y_{\text{base}}} \newcommand{\BaseLateralVelocity}{\dot{y}} \newcommand{\BaseLayerCount}{N_{L,0}} \newcommand{\BaseLearningRate}{\eta_{\text{base}}} \newcommand{\BaseLongitudinalPosition}{x_{\text{base}}} \newcommand{\BaseLongitudinalVelocity}{\dot{x}} \newcommand{\BaseOdometrySpeed}{v} \newcommand{\BaseOrdinateVelocity}{\dot{y}} \newcommand{\BasePosition}{\mathbf{p}_{\text{base}}} \newcommand{\BasePromptLength}{S_{\text{base}}} \newcommand{\BaseStoppingDistance}{d_{\text{base}}} \newcommand{\BaseToCameraTransform}{\mathbf{T}_{\text{cam} \leftarrow \text{base}}} \newcommand{\BaseTrainingComputeCost}{C_{\text{compute}}} \newcommand{\BaseTrajectoryTokenCount}{N_{\text{base}}} \newcommand{\BaseTravelDistance}{d} \newcommand{\BaseTravelSpeed}{v_{\text{base}}} \newcommand{\BaseWidthMultiplier}{w_{\text{mult},0}} \newcommand{\BaseWorkerCount}{N_{\text{base}}} \newcommand{\BaseWristTransform}{\mathbf{T}_{\text{base} \leftarrow \text{wrist}}} \newcommand{\BaseYawRateBias}{\omega_{\text{bias}}} \newcommand{\BaselineAcceptanceEstimate}{\hat{p}_{\text{base}}} \newcommand{\BaselineAnnualOperationsCost}{C_{\text{current}}} \newcommand{\BaselineControllerAction}{\mathbf{a}_t^{\text{base}}} \newcommand{\BaselineConversionRate}{p_0} \newcommand{\BaselineFeatureMean}{\mu_{\text{base}}} \newcommand{\BaselineFeatureStandardDeviation}{\sigma_{\text{base}}} \newcommand{\BaselineIntervalLowerLimit}{l_{\text{base}}} \newcommand{\BaselineIntervalUpperLimit}{u_{\text{base}}} \newcommand{\BaselineLowerLimitDistance}{\delta^-_{\text{base}}} \newcommand{\BaselineOnlyAcceptedTaskCount}{b} \newcommand{\BaselineOnlyCorrectCount}{n_{\text{base}}} \newcommand{\BaselinePolicyAcceptanceProbability}{p_{X}} \newcommand{\BaselinePolicyCost}{C_{X}} \newcommand{\BaselineStateDistribution}{d^{\pi_{\text{base}}}} \newcommand{\BaselineTaskCost}{C_{\text{task, base}}} \newcommand{\BaselineToolCallDistribution}{p_{b}} \newcommand{\BaselineTrackingError}{e_{\text{track}}} \newcommand{\BaselineTrainingDuration}{T_{\text{hours}}} \newcommand{\BaselineTrajectoryGoodput}{\mathcal{G}_{b}} \newcommand{\BaselineUpperLimitDistance}{\delta^+_{\text{base}}} \newcommand{\BatchArrivalRate}{\lambda_{\text{batch}}} \newcommand{\BatchAxisLabel}{b} \newcommand{\BatchBufferMemory}{M_{\text{batch}}} \newcommand{\BatchCostPerAcceptedTask}{C_{\text{eff,batch}}} \newcommand{\BatchDataVolume}{D_{\text{vol}}^{(\text{batch})}} \newcommand{\BatchExampleIndex}{n} \newcommand{\BatchFetchTime}{T_{\text{fetch}}} \newcommand{\BatchFillArrivalCount}{k} \newcommand{\BatchFixedOverheadTime}{T_{\text{fixed}}} \newcommand{\BatchFlushStartTime}{t_{\text{start}}} \newcommand{\BatchFormationDelay}{L_{\text{lat,form}}} \newcommand{\BatchIndex}{k} \newcommand{\BatchLabelComponent}{y_{ij}} \newcommand{\BatchLatencyEnvelope}{L_{\text{lat,envelope}}} \newcommand{\BatchLoss}{\mathcal{L}_{\text{batch}}} \newcommand{\BatchMaxOutputLength}{S_{\text{max}}} \newcommand{\BatchMaximumDeviationMultiple}{k} \newcommand{\BatchMeanOutputLength}{\bar{S}} \newcommand{\BatchNormMean}{\mu_{\mathcal{B}}} \newcommand{\BatchNormOutput}{y} \newcommand{\BatchNormRunningMean}{\boldsymbol{\mu}_{\mathcal{B}}} \newcommand{\BatchNormRunningStandardDeviation}{\boldsymbol{\sigma}_{\mathcal{B}}} \newcommand{\BatchNormStandardDeviation}{\sigma_{\mathcal{B}}} \newcommand{\BatchOperations}{O_{\text{batch}}} \newcommand{\BatchPredictedProbability}{\hat{y}_{ij}} \newcommand{\BatchProcessingTime}{T_{\text{process}}} \newcommand{\BatchRolloutCount}{N_{\text{batch}}} \newcommand{\BatchScalingFactor}{k} \newcommand{\BatchServiceTime}{T_{\text{svc}}} \newcommand{\BatchSize}{B} \newcommand{\BatchTransferTime}{T_{\text{transfer}}} \newcommand{\BatchedDecodeStepTime}{t_{\text{step}}} \newcommand{\BatchedEventIndex}{i} \newcommand{\BatchedRequestLatency}{L_{\text{lat,batch}}} \newcommand{\BatchingLatencyBudget}{L_{\text{lat,budget}}} \newcommand{\BatchingQueueWait}{L_{\text{lat,wait}}} \newcommand{\BatchingWindow}{T_{\text{window}}} \newcommand{\BatteryCellResistance}{R_{\text{cell}}} \newcommand{\BeamDivergenceAngle}{\delta\theta_{\text{div}}} \newcommand{\BeamWidth}{W} \newcommand{\BearingRay}{\mathbf{r}} \newcommand{\BeatFrequency}{f_b} \newcommand{\BehaviorCloningHorizon}{S} \newcommand{\BehaviorCloningLoss}{\mathcal{L}_{\text{BC}}} \newcommand{\BehaviorDistribution}{b} \newcommand{\BehaviorPolicyVersion}{\text{ver}_b} \newcommand{\BeliefErrorBound}{E} \newcommand{\BeliefInvalidationHorizon}{T_{\text{inv}}} \newcommand{\BeliefState}{b} \newcommand{\BellmanBackupTarget}{y} \newcommand{\BellmanErrorLoss}{\mathcal{L}_{\text{Bellman}}} \newcommand{\BelowThresholdIndicator}{\mathbf{1}_{\{|(\mathbf{W}_{\text{sparse}})_{ij}| \leq \delta_{\text{prune}}\}}} \newcommand{\BestEffortWireBitCount}{B_{\text{BE,wire}}} \newcommand{\BetterArmSuccessProbability}{p_{\text{high}}} \newcommand{\BetweenTaskStandardDeviation}{\sigma_{\text{task}}} \newcommand{\BevPillarFeature}{\mathbf{V}_{\text{BEV}}} \newcommand{\BevPillarXIndex}{X} \newcommand{\BevPillarYIndex}{Y} \newcommand{\BiasFeedbackFactor}{\alpha_{\text{fb}}} \newcommand{\BiasVector}{\mathbf{b}} \newcommand{\BilledAllocationTime}{T_{\text{total}}} \newcommand{\BinaryActivationVector}{\mathbf{a}} \newcommand{\BinaryClassifier}{h} \newcommand{\BinaryWeightVector}{\mathbf{w}} \newcommand{\BinomialSuccessCount}{X} \newcommand{\BipedTiltAcceleration}{\ddot{\theta}_{\text{tilt}}} \newcommand{\BisectionBandwidth}{\text{BW}_{\text{bisect}}} \newcommand{\BitFlippedFloatNumber}{x_{\text{corrupt}}} \newcommand{\BitTime}{T_{\text{bit}}} \newcommand{\BlackoutClockConversionError}{\Delta t_{\text{one-sigma scenario}}} \newcommand{\BlendDeadline}{t_{\text{blend}}} \newcommand{\BlendedCommandJerk}{j_{\text{cmd}}} \newcommand{\BlendedControlCommand}{\mathbf{u}_{\text{blend}}} \newcommand{\BlendedInputTokenPrice}{c_{\text{in}}} \newcommand{\BlendingTransitionWindow}{\tau_{\text{blend}}} \newcommand{\BlindTravelDistance}{d_{\text{blind}}} \newcommand{\BlockCheckTime}{T_{\text{ver}}} \newcommand{\BlockCoordinateX}{b_x} \newcommand{\BlockCoordinateY}{b_y} \newcommand{\BlockCoordinateZ}{b_z} \newcommand{\BlockEdgeVoxelCount}{n_{\text{blk}}} \newcommand{\BlockMaximum}{M} \newcommand{\BlockMaximumLevel}{z} \newcommand{\BlockMaximumLimitDistribution}{G} \newcommand{\BlockMaximumNormalizingScale}{a} \newcommand{\BlockMaximumNormalizingShift}{b} \newcommand{\BlockMetadataSize}{s_{\text{meta}}} \newcommand{\BlockQuantizationScale}{s_b} \newcommand{\BlockRangeMaximum}{x_{\max,i}} \newcommand{\BlockRangeMinimum}{x_{\min,i}} \newcommand{\BlockSampleCount}{n} \newcommand{\BlockedWorkerCount}{N_{\text{blocked}}} \newcommand{\BlockingCallTimeout}{T_{\text{out}}} \newcommand{\BlockingTaskIndex}{k} \newcommand{\BodyAcceleration}{\dot{v}} \newcommand{\BodyDisplacement}{x} \newcommand{\BodyEndEffectorTransform}{\mathbf{T}_{BE}} \newcommand{\BodyFramePoint}{\mathbf{p}_{\text{body}}} \newcommand{\BodyFramePointCovariance}{\boldsymbol{\Sigma}_{\text{body}}} \newcommand{\BodyLidarTransform}{\mathbf{T}_{bl}} \newcommand{\BodyReferenceFrame}{\mathcal{F}_B} \newcommand{\BodyRegionMass}{m_H} \newcommand{\BodySpeed}{v} \newcommand{\BoltzmannConstant}{k_B} \newcommand{\BoltzmannStateEnergy}{E} \newcommand{\BoltzmannTemperature}{T} \newcommand{\BootstrapQuantileFunction}{Q} \newcommand{\BootstrapReplicateCount}{B_{\text{boot}}} \newcommand{\BootstrapReplicateIndex}{r} \newcommand{\BottomedOutContactStiffness}{k_{\infty}} \newcommand{\BouligandContingentCone}{T_{\mathcal{C}}} \newcommand{\BoundaryConditionVector}{\mathbf{b}} \newcommand{\BoundaryLayerTime}{t_{\text{fast}}} \newcommand{\BoundedRegimeTimestamp}{t_{\text{bounded}}} \newcommand{\BoxMaximumHorizontalCoordinate}{x_{\text{max}}} \newcommand{\BoxMaximumVerticalCoordinate}{y_{\text{max}}} \newcommand{\BoxMinimumHorizontalCoordinate}{x_{\text{min}}} \newcommand{\BoxMinimumVerticalCoordinate}{y_{\text{min}}} \newcommand{\BrakeChopperResistance}{R_{\text{brake}}} \newcommand{\BrakeCommandForce}{F_{\text{cmd}}} \newcommand{\BrakeResistorPulseEnergy}{E_{\text{pulse}}} \newcommand{\BrakingDistance}{d_{\text{brake}}} \newcommand{\BrakingForce}{F_{\text{brake}}} \newcommand{\BrakingOnsetContactForce}{F_{\text{cmd}}} \newcommand{\BrakingWork}{W_{\text{brake}}} \newcommand{\BreadthCriticalPathLatency}{T^{\text{breadth}}} \newcommand{\BreadthPeakKvCacheMemory}{M_{\text{KV}}^{\text{breadth}}} \newcommand{\BreakEvenAcceptanceProbability}{p'} \newcommand{\BreakEvenBrakingDeceleration}{a} \newcommand{\BreakEvenParseFailureRate}{p_{\text{break}}} \newcommand{\BreakEvenTaskCount}{N^*} \newcommand{\BreakEvenUtilization}{u^*} \newcommand{\BreakerCooldownInterval}{T_{\text{cool}}} \newcommand{\BreakerFailureFraction}{r} \newcommand{\BreakerMinimumSampleCount}{n_{\min}} \newcommand{\BreakerOutcomeIndex}{i} \newcommand{\BreakerOutcomeWindow}{W} \newcommand{\BreakerTripThreshold}{r_{\text{trip}}} \newcommand{\BridgeTraceResistance}{R_{\text{trace}}} \newcommand{\BroadcastColumnElement}{A} \newcommand{\BroadcastColumnTensor}{\mathbf{A}} \newcommand{\BroadcastCompletionTime}{T_{\text{broadcast}}} \newcommand{\BroadcastRowElement}{b} \newcommand{\BroadcastRowTensor}{\mathbf{B}} \newcommand{\BroadcastTableSize}{s_{\text{table}}} \newcommand{\BspLearningRate}{\eta_{\text{BSP}}} \newcommand{\BsplineBasisFunction}{B} \newcommand{\BudgetEvaluationTime}{\tau} \newcommand{\BudgetFreeBalance}{F} \newcommand{\BudgetNodeIndex}{k} \newcommand{\BudgetReservedFunds}{R} \newcommand{\BudgetSettledCharges}{E} \newcommand{\BudgetedAcceptanceProbability}{q_{\pi}} \newcommand{\BufferDependencyEdgeSet}{E} \newcommand{\BufferDependencyGraph}{G} \newcommand{\BufferDependencyVertexSet}{V} \newcommand{\BufferIndex}{i} \newcommand{\BulkDecouplingCapacitance}{C_{\text{bulk}}} \newcommand{\BumplessTransferBlend}{\alpha} \newcommand{\BumplessTransferBlendAcceleration}{\ddot{\alpha}} \newcommand{\BumplessTransferBlendRate}{\dot{\alpha}} \newcommand{\BumplessTransferBlendSlope}{\alpha'} \newcommand{\BumplessTransferProgress}{\hat{t}} \newcommand{\BumplessTransferStartInstant}{t_{\text{start}}} \newcommand{\BurstArrivalCount}{N_{\text{burst}}} \newcommand{\BurstSurvivalTime}{t_{\text{limit}}} \newcommand{\BusBitRate}{R_{\text{bit}}} \newcommand{\BusCapacitorEnergy}{E_C} \newcommand{\BusCapacitorVoltage}{V_C} \newcommand{\BusSerializationTime}{t_{\text{bus}}} \newcommand{\ButterflyAllReduceTime}{T_{\text{butterfly}}} \newcommand{\ByteAlphabet}{\Sigma} \newcommand{\ByteString}{u} \newcommand{\ByzantineClientCount}{f} \newcommand{\ByzantineFaultCount}{f} \newcommand{\CableFlexCycleCount}{n_{\text{cable}}} \newcommand{\CableRatedFatigueLife}{L_{\text{cable}}} \newcommand{\CacheMissStallFraction}{f} \newcommand{\CachedInputTokenCount}{n_{\text{cache}}} \newcommand{\CachedInputTokenPrice}{c_{\text{cache}}} \newcommand{\CalibratedAcceptanceEstimate}{\hat{p}} \newcommand{\CalibrationBinCount}{N_{\text{bins}}} \newcommand{\CalibrationBinExampleSet}{B_m} \newcommand{\CalibrationBinIndex}{m} \newcommand{\CalibrationConstraintMatrix}{\mathbf{V}} \newcommand{\CalibrationDataDistribution}{p_{\text{cal}}} \newcommand{\CalibrationDataset}{\mathcal{C}_{\text{cal}}} \newcommand{\CalibrationExampleCount}{n_{\text{cal}}} \newcommand{\CalibrationModelPoint}{\mathbf{M}} \newcommand{\CalibrationPoseIndex}{k} \newcommand{\CalibrationRotationAxisCount}{N} \newcommand{\CalibrationSceneIndex}{j} \newcommand{\CalibrationTemperature}{T_{\text{cal}}} \newcommand{\CalibrationViewCount}{N} \newcommand{\CallLatency}{T_{\text{call}}} \newcommand{\CallPostprocessingTime}{T_{\text{post}}} \newcommand{\CallPreparationTime}{T_{\text{prep}}} \newcommand{\CallTailProbability}{p_{\text{tail}}} \newcommand{\CallUsefulWorkTime}{W} \newcommand{\CameraCenterArcPosition}{x_{\text{rot}}} \newcommand{\CameraExtrinsicRotation}{\mathbf{R}_{bc}} \newcommand{\CameraExtrinsicTransform}{\mathbf{T}_{bc}} \newcommand{\CameraExtrinsicTranslation}{\mathbf{p}_{bc}} \newcommand{\CameraFrameDepth}{Z_c} \newcommand{\CameraFrameHorizontalCoordinate}{X_c} \newcommand{\CameraFramePeriod}{T_{\text{sample}}} \newcommand{\CameraFramePoint}{\mathbf{p}_c} \newcommand{\CameraFramePointCovariance}{\boldsymbol{\Sigma}_c} \newcommand{\CameraFrameVerticalCoordinate}{Y_c} \newcommand{\CameraIdentifierEmbedding}{\mathbf{e}_{\text{cam}}} \newcommand{\CameraImage}{\mathbf{I}} \newcommand{\CameraImuTimeOffset}{\Delta t_{\text{imu}}} \newcommand{\CameraIntrinsicCalibrationMatrix}{\mathbf{K}} \newcommand{\CameraIntrinsicInverseTranspose}{\mathbf{K}^{-\top}} \newcommand{\CameraLateralStandardDeviation}{\sigma_{x_c}} \newcommand{\CameraMountTiltAngle}{\theta_{\text{ext}}} \newcommand{\CameraObjectTransform}{\mathbf{T}_{\text{camera}}^{\text{object}}} \newcommand{\CameraOpticalCenter}{\mathbf{o}} \newcommand{\CameraReferenceFrame}{\mathcal{F}_{\text{cam}}} \newcommand{\CameraRotationColumn}{\mathbf{r}} \newcommand{\CameraSampleTimestamp}{t_{\text{cam}}} \newcommand{\CameraSkewCoefficient}{\gamma} \newcommand{\CameraTargetTransform}{\mathbf{T}_{\text{cam}}^{\text{target}}} \newcommand{\CameraToWorldRotation}{\mathbf{R}_{WC}} \newcommand{\CameraToWorldTransform}{\mathbf{T}_{WC}} \newcommand{\CameraToWorldTranslation}{\mathbf{t}_{WC}} \newcommand{\CampaignActiveTime}{T_{\text{active}}} \newcommand{\CanHighLineVoltage}{V_{\text{CANH}}} \newcommand{\CanLowLineVoltage}{V_{\text{CANL}}} \newcommand{\CanaryAllocationFraction}{\rho} \newcommand{\CanaryInterventionRate}{\lambda_{\text{canary}}} \newcommand{\CanaryLabelDelay}{t_{\text{label}}} \newcommand{\CanarySpeedBound}{v_{\text{canary}}} \newcommand{\CanaryStageDuration}{T_{\text{stage}}} \newcommand{\CanaryTrafficFraction}{p_{\text{stage}}} \newcommand{\CandidateAcceptanceEstimate}{\hat{p}_{\text{cand}}} \newcommand{\CandidateActionVector}{\hat{\mathbf{a}}} \newcommand{\CandidateArchitecture}{a} \newcommand{\CandidateAvailabilityEstimate}{\widehat{q}} \newcommand{\CandidateAvailabilityProbability}{q} \newcommand{\CandidateCheckingCost}{v} \newcommand{\CandidateClientCount}{K_{\text{candidates}}} \newcommand{\CandidateControlCommand}{\mathbf{u}^{\text{cand}}} \newcommand{\CandidateControlCommandDerivative}{\dot{\mathbf{u}}^{\text{cand}}} \newcommand{\CandidateDefectRate}{\epsilon} \newcommand{\CandidateGenerationCost}{g} \newcommand{\CandidateIndex}{i} \newcommand{\CandidateIntervalLowerLimit}{l_{\text{cand}}} \newcommand{\CandidateIntervalUpperLimit}{u_{\text{cand}}} \newcommand{\CandidateLowerLimitDistance}{\delta^-_{\text{cand}}} \newcommand{\CandidateOnlyAcceptedTaskCount}{c} \newcommand{\CandidatePolicyAcceptanceProbability}{p_{Y}} \newcommand{\CandidatePolicyAction}{\mathbf{a}_t^{\text{cand}}} \newcommand{\CandidatePolicyCost}{C_{Y}} \newcommand{\CandidatePoolSize}{N} \newcommand{\CandidateProposal}{p} \newcommand{\CandidateRoutingPolicy}{Y} \newcommand{\CandidateScoreVector}{\mathbf{c}} \newcommand{\CandidateScoringCost}{c_{\text{infer}}} \newcommand{\CandidateScoringError}{\epsilon} \newcommand{\CandidateSkill}{a} \newcommand{\CandidateSpeedCommand}{v_{\text{cand}}} \newcommand{\CandidateTailCompletionTime}{\widehat{T}_{c,0.99}} \newcommand{\CandidateToolCallDistribution}{p_{c}} \newcommand{\CandidateTrackingErrorStandardDeviation}{\sigma_{\text{track}}} \newcommand{\CandidateTrajectoryGoodput}{\mathcal{G}_{c}} \newcommand{\CandidateUpperLimitDistance}{\delta^+_{\text{cand}}} \newcommand{\CandidateUtility}{U} \newcommand{\CandidateUtilityMean}{\mu} \newcommand{\CandidateUtilityStandardDeviation}{\sigma_{U}} \newcommand{\CandidateViolationCount}{V_{c}} \newcommand{\CandidateWinCount}{j} \newcommand{\CapabilityGrant}{\Gamma} \newcommand{\CaptureAgeEmbedding}{\mathbf{e}_{\Delta t}} \newcommand{\CaptureSampleIndex}{t_0} \newcommand{\CaptureSampleKalmanGain}{\mathbf{G}_{t_0}} \newcommand{\CaptureSampleMeasurementMatrix}{\mathbf{H}_{t_0}} \newcommand{\CaptureSamplePredictedCovariance}{\mathbf{P}_{t_0|t_0-1}} \newcommand{\CaptureSamplePredictedEstimate}{\hat{\mathbf{x}}_{t_0|t_0-1}} \newcommand{\CaptureSampleUpdatedCovariance}{\mathbf{P}_{t_0|t_0}} \newcommand{\CaptureSampleUpdatedEstimate}{\hat{\mathbf{x}}_{t_0|t_0}} \newcommand{\CaptureTimestamp}{t_{\text{capture}}} \newcommand{\CapturedSensorObservation}{\mathbf{z}_{t_0}} \newcommand{\CartesianAcceleration}{\ddot{\mathbf{p}}} \newcommand{\CartesianPosition}{\mathbf{p}} \newcommand{\CartesianXCoordinate}{x} \newcommand{\CartesianYCoordinate}{y} \newcommand{\CartesianZCoordinate}{z} \newcommand{\CascadeEscalationProbability}{p_{\text{escalate}}} \newcommand{\CascadeGateCost}{g} \newcommand{\CascadeGateDuration}{v} \newcommand{\CascadeInferenceEnergy}{E_{\text{cascade}}} \newcommand{\CascadeTaskCost}{C_{\text{cascade}}} \newcommand{\CascadeTaskDuration}{T_{\text{cascade}}} \newcommand{\CascadeTierCost}{c^{\text{tier}}} \newcommand{\CascadeTierDuration}{t} \newcommand{\CascadeTierIndex}{j} \newcommand{\CascadedBarrierCertificate}{\psi} \newcommand{\CascadedBarrierClassKFunction}{\alpha} \newcommand{\CascadedBarrierDerivative}{\dot{\psi}} \newcommand{\CaseAmbientThermalResistance}{R_{\text{th,case-amb}}} \newcommand{\CaseTemperature}{T_{\text{case}}} \newcommand{\CaseThermalCapacitance}{C_{\text{case}}} \newcommand{\CaseThermalTimeConstant}{\tau_{\text{th,case}}} \newcommand{\CatalogDefinitionTokens}{S_{\text{catalog}}} \newcommand{\CatalogStagingCallCount}{N} \newcommand{\CategoryRecordCount}{n} \newcommand{\CausalInterventionMask}{\mathcal{M}} \newcommand{\CausalMediator}{M} \newcommand{\CausalTokenPosition}{s} \newcommand{\CbsRuntimeBudget}{Q} \newcommand{\CellOccupancyProbability}{p} \newcommand{\CenterCount}{k} \newcommand{\CentralizedTrainingEnergy}{E_{\text{centralized}}} \newcommand{\CentroidalAngularMomentum}{\mathbf{h}_{\text{ang}}} \newcommand{\CentroidalAngularMomentumDerivative}{\dot{\mathbf{h}}_{\text{ang}}} \newcommand{\CentroidalLinearMomentum}{\mathbf{h}_{\text{lin}}} \newcommand{\CentroidalLinearMomentumDerivative}{\dot{\mathbf{h}}_{\text{lin}}} \newcommand{\CentroidalMomentum}{\mathbf{h}_G} \newcommand{\CentroidalMomentumMatrix}{\mathbf{A}_G} \newcommand{\CentroidalMomentumMatrixDerivative}{\dot{\mathbf{A}}_G} \newcommand{\CentroidalMomentumRate}{\dot{\mathbf{h}}_G} \newcommand{\CertifiedCommandWindow}{\mathbf{u}^*_{t:t+H-1}} \newcommand{\CertifiedControlAction}{\mathbf{u}^*} \newcommand{\CertifiedJointTorque}{u^*} \newcommand{\CertifiedRadius}{R} \newcommand{\ChainRuleInput}{x} \newcommand{\ChainRuleIntermediate}{u} \newcommand{\ChainRuleOutput}{v} \newcommand{\ChainedOperationCount}{n_{\text{ops}}} \newcommand{\ChanceAnnotatorAgreement}{p_e} \newcommand{\ChannelAuthorityState}{S} \newcommand{\ChannelCommand}{u} \newcommand{\ChannelStoredEnergy}{E_{\text{channel}}} \newcommand{\CharacteristicPolynomial}{p} \newcommand{\CharacteristicPolynomialCoefficient}{c} \newcommand{\ChassisThermalResistance}{R_{\text{th,chassis}}} \newcommand{\CheapConfigurationAttemptCost}{c_{\text{small}}} \newcommand{\CheapConfigurationPassProbability}{p_{\text{small}}} \newcommand{\CheckIntervalStepCount}{m} \newcommand{\CheckPassProbability}{p^{\text{chk}}} \newcommand{\CheckSlotTime}{T} \newcommand{\CheckWindowTurnCount}{w} \newcommand{\CheckedSignal}{x} \newcommand{\CheckedSignalLimit}{L_{\text{limit}}} \newcommand{\CheckpointAttemptDuration}{T_{\text{att}}} \newcommand{\CheckpointExtraPauseTime}{T_{\text{pause}}} \newcommand{\CheckpointInterval}{T_{\text{ckpt}}} \newcommand{\CheckpointLoadTime}{T_{\text{load}}} \newcommand{\CheckpointLogPosition}{j_{\text{ckpt}}} \newcommand{\CheckpointOrdinalIndex}{m} \newcommand{\CheckpointOverheadFraction}{f_{\text{ckpt}}} \newcommand{\CheckpointOverheadRatio}{w} \newcommand{\CheckpointRecoveryOverheadTime}{T_{\text{overhead}}} \newcommand{\CheckpointRestoreTime}{T_{\text{restore}}} \newcommand{\CheckpointStride}{k} \newcommand{\CheckpointSuffixReadTime}{T_{\text{read}}} \newcommand{\CheckpointWasteFraction}{W} \newcommand{\CheckpointWriteTime}{T_{\text{write}}} \newcommand{\ChildBatchSize}{n_{\text{batch}}} \newcommand{\ChildBudgetAllocation}{C_{\max,C}} \newcommand{\ChildCapabilityGrant}{\Gamma_{\text{child}}} \newcommand{\ChildFreeBalance}{F_{C}} \newcommand{\ChildPruningProbability}{p_{\text{prune}}} \newcommand{\ChildReservedFunds}{R_{C}} \newcommand{\ChildSettledCharges}{E_{C}} \newcommand{\ChinchillaIrreducibleLoss}{E} \newcommand{\ChirpDuration}{T_c} \newcommand{\ChirpSlope}{S} \newcommand{\ChopperClampVoltage}{V_{\text{clamp}}} \newcommand{\ChopperTurnOffVoltage}{V_{\text{clamp,off}}} \newcommand{\ChopperTurnOnVoltage}{V_{\text{clamp,on}}} \newcommand{\ChunkActionDimension}{d_{\text{chunk}}} \newcommand{\ChunkEnsemblingWeight}{w} \newcommand{\ChunkExecutionHorizon}{H_{\text{exec}}} \newcommand{\ChunkImitationLoss}{\mathcal{L}_{\text{chunk}}} \newcommand{\ChunkLease}{T_{\text{lease}}} \newcommand{\ChunkLeaseTime}{T_{\text{lease}}} \newcommand{\ChunkReactionLatency}{T_{\text{reaction}}} \newcommand{\ChunkRenewalPeriod}{T_{\text{chunk}}} \newcommand{\ChunkRenewalRate}{f_{\text{replan}}} \newcommand{\ChunkStepIndex}{i} \newcommand{\ClampedControlCommand}{\mathbf{u}_{\text{clip}}} \newcommand{\ClassCount}{K} \newcommand{\ClassIndex}{j} \newcommand{\ClassKFunction}{\kappa} \newcommand{\ClassKFunctionSet}{\mathcal{K}} \newcommand{\ClassProbabilityVector}{\mathbf{p}} \newcommand{\ClassificationThreshold}{\gamma_{\text{cls}}} \newcommand{\CleanLabelSampleCount}{D_{\text{clean}}} \newcommand{\CleanTrainingDataset}{\mathcal{S}} \newcommand{\CleanupGraphEdgeSet}{E} \newcommand{\CleanupGraphVertexSet}{V} \newcommand{\ClearDistance}{D_{\text{clear}}} \newcommand{\ClearanceAcceleration}{\ddot{D}_{\text{clear}}} \newcommand{\ClearanceAllowance}{C} \newcommand{\ClearanceExhaustionTime}{t_{\text{impact}}} \newcommand{\ClearanceInset}{C_{\text{inset}}} \newcommand{\ClearanceQueryTime}{t_{\text{query}}} \newcommand{\ClearanceRate}{\dot{D}_{\text{clear}}} \newcommand{\ClearanceSpeedClamp}{v_{\text{clamp}}} \newcommand{\ClearanceTimeBudget}{T_{\text{total}}} \newcommand{\ClfClassKFunction}{\alpha_V} \newcommand{\ClfDescentControlSet}{\mathcal{U}_{\text{CLF}}} \newcommand{\ClientGradientVector}{\mathbf{g}} \newcommand{\ClientIndex}{k} \newcommand{\ClientLocalDataset}{\mathcal{D}} \newcommand{\ClientLocalTrainingEnergy}{E_{\text{client}}} \newcommand{\ClientMaskVector}{\mathbf{r}} \newcommand{\ClientObjectiveWeight}{w} \newcommand{\ClientSampleCount}{n} \newcommand{\ClientUpdateUploadEnergy}{E_{\text{upload}}} \newcommand{\ClippedSurrogateObjective}{\mathcal{M}} \newcommand{\ClippingRangeLowerBound}{\alpha} \newcommand{\ClippingRangeUpperBound}{\beta} \newcommand{\ClockConversionBound}{\epsilon_{\text{sync}}} \newcommand{\ClockConversionIntercept}{b_{\text{clk}}} \newcommand{\ClockConversionSlope}{a} \newcommand{\ClockFrequency}{f} \newcommand{\ClockOffset}{\theta_{\text{offset}}} \newcommand{\ClockPeriod}{T_{\text{clk}}} \newcommand{\ClockSynchronizationSkew}{\delta_{\text{skew}}} \newcommand{\ClosedLoopTrajectoryDensity}{p_{\text{cl}}} \newcommand{\ClosingSpeedBound}{v_{\text{close}}} \newcommand{\CloudInferenceEnergy}{E_{\text{cloud}}} \newcommand{\CloudOffloadEnergy}{E_{\text{transmit}}} \newcommand{\CloudTrainingRunEnergy}{E_{\text{cloud,train}}} \newcommand{\ClusterAvailability}{A_{\text{cluster}}} \newcommand{\ClusterCount}{k} \newcommand{\ClusterHeadroom}{N} \newcommand{\ClusterNodeCount}{N_{\text{nodes}}} \newcommand{\ClusterPower}{P_{\text{cluster}}} \newcommand{\CoarseCellCount}{C} \newcommand{\CodecDecodeTime}{T_{\text{decode}}} \newcommand{\CodecEncodeTime}{T_{\text{encode}}} \newcommand{\CodecOverheadTime}{T_{\text{overhead}}} \newcommand{\CognitivePolicyAction}{\mathbf{a}} \newcommand{\CoherencyCoefficient}{\kappa_{\text{coh}}} \newcommand{\ColdCopperLossPower}{P_0} \newcommand{\ColdResetCycleTime}{T_{\text{cycle,cold}}} \newcommand{\CollaborativeContactForce}{F_{\text{contact}}} \newcommand{\CollectedPhotocharge}{Q} \newcommand{\CollectionCohortCost}{C_{\text{cohort}}} \newcommand{\CollectionStateVisitationDistribution}{p^{\pi_{\text{col}}}} \newcommand{\CollectiveCallStartupLatency}{\alpha_{\text{eff}}} \newcommand{\CollectiveInputTensor}{\mathbf{X}} \newcommand{\CollectivePayloadSize}{M} \newcommand{\CollectiveTensorSize}{M_{\text{coll}}} \newcommand{\CollisionHullCount}{N_{\text{hulls}}} \newcommand{\CollocationDefect}{\Delta} \newcommand{\ColumnAccessLatency}{t_{\text{CL}}} \newcommand{\ColumnModeComponentVector}{\mathbf{b}_s} \newcommand{\ColumnModeFactorMatrix}{\mathbf{B}} \newcommand{\ColumnModeFactorSlice}{\mathbf{b}} \newcommand{\ColumnParallelWeightMatrix}{\mathbf{A}} \newcommand{\CombinedBatch}{B_{\text{total}}} \newcommand{\CombinedPlanValidationAllowance}{t_{\text{validate}}} \newcommand{\CommandComponentCount}{N_c} \newcommand{\CommandRateCeiling}{r} \newcommand{\CommandTransportTime}{T_{\text{bus}}} \newcommand{\CommandedActuatorEffort}{u_{\text{cmd}}} \newcommand{\CommandedApproachAcceleration}{a_{\text{cmd}}} \newcommand{\CommandedJointConfiguration}{\mathbf{q}_{\text{cmd}}} \newcommand{\CommandedJointCount}{N_j} \newcommand{\CommandedJointTorque}{\tau} \newcommand{\CommandedJointTorqueSlew}{\dot{\tau}} \newcommand{\CommandedTrackedPosition}{r_{\text{cmd}}} \newcommand{\CommandedTractiveForce}{F_{\text{cmd}}} \newcommand{\CommitBatchRecordCount}{N_{\text{batch}}} \newcommand{\CommitmentInstant}{t_{\text{commit}}} \newcommand{\CommitmentPathPosition}{q_{c}} \newcommand{\CommonPositionShift}{\Delta} \newcommand{\CommunicationComputeRatio}{\rho} \newcommand{\CommunicationIntensity}{\text{CI}} \newcommand{\CommunicationSlowdownFactor}{r} \newcommand{\CommunicationTime}{T_{\text{comm}}} \newcommand{\CommunicationTimeFraction}{f} \newcommand{\CompactedContextLength}{S_{\text{comp}}} \newcommand{\CompactionBoundaryCount}{k} \newcommand{\CompactionBoundaryIndex}{i} \newcommand{\CompactionCycleTurnCount}{n_{\text{cycle}}} \newcommand{\CompactionCycleTurnIndex}{i} \newcommand{\CompactionLossProbability}{\rho} \newcommand{\CompactionPassCost}{C_{\text{comp}}} \newcommand{\CompactionPathCost}{C_{\text{compact}}} \newcommand{\CompactionPaybackCallCount}{N_{\min}} \newcommand{\CompactionPerCallSaving}{s} \newcommand{\CompactionTargetLength}{S_{\text{low}}} \newcommand{\CompactionTriggerLength}{S_{\text{high}}} \newcommand{\CompactionUpfrontCost}{U} \newcommand{\ComparedPeriodAccuracy}{a} \newcommand{\ComparisonArmTrialCount}{n_{\text{arm}}} \newcommand{\ComparisonContext}{c} \newcommand{\ComparisonSampleEmpiricalCdf}{G_{m}} \newcommand{\ComparisonSampleSize}{m} \newcommand{\ComparisonTrajectory}{z} \newcommand{\ComparisonTrajectoryDerivative}{\dot{z}} \newcommand{\CompensatedEnvironmentState}{\sigma_0'} \newcommand{\CompensationPostcondition}{\phi} \newcommand{\CompensationPostconditionSet}{\Phi} \newcommand{\CompetingKeyCount}{n} \newcommand{\CompetingKeyLogit}{z} \newcommand{\CompilationBreakevenCount}{N_{\text{breakeven}}} \newcommand{\CompilationTime}{T_{\text{compile}}} \newcommand{\CompiledExecutionTime}{T_{\text{compiled}}} \newcommand{\CompilerBackendCount}{N_{\text{backend}}} \newcommand{\CompilerFrontendCount}{M} \newcommand{\ComplementarityNormalForce}{\lambda_n} \newcommand{\CompletedRequestCount}{N} \newcommand{\CompletedRoundIndex}{r} \newcommand{\CompletionCriteria}{\mathcal{K}_{\text{comp}}} \newcommand{\CompletionDeadline}{T_{\text{deadline}}} \newcommand{\CompletionOffset}{c} \newcommand{\CompliantElementPreload}{F_{\text{preload}}} \newcommand{\CompliantElementStiffness}{k_{\text{spring}}} \newcommand{\ComponentAvailability}{A_{\text{component}}} \newcommand{\ComponentFailureRate}{\lambda} \newcommand{\ComponentHazardRate}{h} \newcommand{\ComponentMttf}{\text{MTTF}_{\text{component}}} \newcommand{\ComponentReliability}{R_{\text{single}}} \newcommand{\ComposedChainTransform}{\mathbf{T}_{AC}} \newcommand{\ComposedFunctionInput}{x} \newcommand{\ComposedFunctionOutput}{y} \newcommand{\ComposedMechanismCount}{k} \newcommand{\CompoundScalingCoefficient}{\phi} \newcommand{\CompressedCommunicationTime}{T_{\text{compressed}}} \newcommand{\CompressedGradientUpdate}{\mathbf{v}} \newcommand{\CompressedGradientUpdateElement}{v} \newcommand{\CompressedOnlyCorrectCount}{n_{\text{comp}}} \newcommand{\CompressionRatio}{r_{\text{comp}}} \newcommand{\ComputationalDimensionCount}{N_{\text{comp}}} \newcommand{\ComputationalGraph}{G} \newcommand{\ComputeBudgetConstraint}{g} \newcommand{\ComputeChipPower}{P_{\text{chip}}} \newcommand{\ComputeConstrainedLagrangian}{\mathcal{L}_{\text{Lagrange}}} \newcommand{\ComputeConstraintMultiplier}{\lambda} \newcommand{\ComputeDemandVolume}{Q} \newcommand{\ComputeLimitedSampleRate}{R_{\text{compute}}} \newcommand{\ComputeOptimalTokenCount}{D_{\text{opt}}} \newcommand{\ComputeUnitCost}{P} \newcommand{\ConcordantTaskCount}{n} \newcommand{\ConcurrentTrajectories}{N_{\text{traj}}} \newcommand{\ConditionalDamageProbability}{p} \newcommand{\ConditionalDistribution}{p(y \mid x)} \newcommand{\ConditionalFlowMap}{\psi} \newcommand{\ConditionalVelocityField}{v} \newcommand{\ConditioningTokenPrefix}{x} \newcommand{\ConductorCurrent}{I} \newcommand{\ConeLimitStepSize}{\tau} \newcommand{\ConfidenceCalibrationDataset}{\mathcal{D}_{\text{cal}}} \newcommand{\ConfidenceCriticalQuantile}{z_{\alpha/2}} \newcommand{\ConfidenceLevel}{C} \newcommand{\ConfidentialityLabel}{\kappa} \newcommand{\ConfigurationSpace}{\mathcal{C}} \newcommand{\ConfirmationHitCount}{M} \newcommand{\ConfirmationWindowCount}{N_{\text{conf}}} \newcommand{\ConfluentVandermondeMatrix}{\mathbf{M}} \newcommand{\ConformalMiscoverageRate}{\epsilon} \newcommand{\ConformalPredictionSet}{\mathcal{C}} \newcommand{\ConformalQuantileRank}{k_{\epsilon}} \newcommand{\ConformalScoreQuantile}{\widehat{q}_{1-\epsilon}} \newcommand{\ConservativePenaltyWeight}{\alpha_{\text{CQL}}} \newcommand{\ConservativeSamplingDistribution}{\mu} \newcommand{\ConsoleCommunicationTime}{T_{\text{comm}}} \newcommand{\ConsolidationOverheadTime}{T_{\text{overhead}}} \newcommand{\ConsolidationStride}{c} \newcommand{\ConstantDivisorGrpoObjective}{\widehat{\mathcal{J}}_{\text{const}}} \newcommand{\ConstantHazardRate}{\lambda} \newcommand{\ConstrainedCallLatency}{T_{\text{constrained}}} \newcommand{\ConstrainedDecodingAutomaton}{\mathcal{D}} \newcommand{\ConstrainedParameterVector}{\mathbf{w}} \newcommand{\ConstrainedTestEnvelope}{\mathcal{S}} \newcommand{\ConstraintLagrangeMultiplier}{\lambda} \newcommand{\ConstraintRetentionFraction}{\eta_{\mathcal{C}}} \newcommand{\ContactApproachSpeed}{v_{\text{approach}}} \newcommand{\ContactCount}{N_c} \newcommand{\ContactDeformationDuration}{\Delta t_{\text{def}}} \newcommand{\ContactDirectionSpeed}{v_c} \newcommand{\ContactDirectionVelocity}{\dot{x}} \newcommand{\ContactDriftAcceleration}{a_{\text{drift}}} \newcommand{\ContactForce}{F_{\text{contact}}} \newcommand{\ContactForceBarrierFunction}{h_{\text{force}}} \newcommand{\ContactForceCap}{F_{\text{cap}}} \newcommand{\ContactForceCeiling}{F_{\max}} \newcommand{\ContactForceLimit}{F_{\text{limit}}} \newcommand{\ContactForceMagnitude}{F} \newcommand{\ContactForceRegularizationWeight}{w_f} \newcommand{\ContactForceRiseTime}{t_{\text{rise}}} \newcommand{\ContactGapAcceleration}{\ddot{\phi}} \newcommand{\ContactGapFunction}{\phi} \newcommand{\ContactGapVelocity}{\dot{\phi}} \newcommand{\ContactImpulse}{I} \newcommand{\ContactJacobianBaseBlock}{\mathbf{J}_{k,b}} \newcommand{\ContactJacobianJointBlock}{\mathbf{J}_{k,j}} \newcommand{\ContactLoopResponseTime}{T_c} \newcommand{\ContactNaturalTimescale}{T_{\text{contact}}} \newcommand{\ContactNormal}{\hat{\mathbf{n}}} \newcommand{\ContactNormalDeflection}{x} \newcommand{\ContactNormalJacobian}{\mathbf{J}_n} \newcommand{\ContactNormalJacobianDerivative}{\dot{\mathbf{J}}_n} \newcommand{\ContactNormalPosition}{x} \newcommand{\ContactNormalVelocity}{v_n} \newcommand{\ContactPatchRegion}{\mathcal{A}} \newcommand{\ContactPointForce}{\mathbf{f}} \newcommand{\ContactPointIndex}{i} \newcommand{\ContactPointJacobian}{\mathbf{J}_{\text{c}}} \newcommand{\ContactPointJacobianDerivative}{\dot{\mathbf{J}}_{\text{c}}} \newcommand{\ContactPointOffset}{\mathbf{r}} \newcommand{\ContactPointPosition}{x} \newcommand{\ContactPointTorque}{\boldsymbol{\tau}} \newcommand{\ContactReactionForce}{F} \newcommand{\ContactResponseLatency}{t_{\text{resp}}} \newcommand{\ContactStiffness}{k_{\text{contact}}} \newcommand{\ContactTorqueCeiling}{\tau_{\max}} \newcommand{\ContactTripwireForce}{F_{\text{trip}}} \newcommand{\ContactWrench}{\mathbf{w}} \newcommand{\ContactWrenchCeiling}{\mathbf{w}_{\max}} \newcommand{\ContactWrenchEnvelope}{\mathbf{w}_{\text{contact}}} \newcommand{\ContactWrenchTransform}{\mathbf{X}_k^*} \newcommand{\ContactYieldDeadline}{t_{\text{yield}}} \newcommand{\ContainerInnerRadius}{R} \newcommand{\ContainmentForceCeiling}{F_{\max}} \newcommand{\ContendingApplicationCount}{N} \newcommand{\ContentionCoefficient}{\sigma_{\text{cont}}} \newcommand{\ContextChunkTokenCount}{n} \newcommand{\ContextHiddenRepresentation}{\mathbf{h}_{\text{context}}} \newcommand{\ContextParallelDegree}{c} \newcommand{\ContextParallelRankIndex}{i} \newcommand{\ContextSaveTime}{t_{\text{context\_save}}} \newcommand{\ContextWindow}{S_{\max}} \newcommand{\ContinuationCount}{K} \newcommand{\ContinuationIndex}{i} \newcommand{\ContinuationReturnStandardDeviation}{\sigma} \newcommand{\ContinuityCorrectedCrossProduct}{A} \newcommand{\ContinuousActionComponent}{a} \newcommand{\ContinuousActionSpace}{\mathcal{A}} \newcommand{\ContinuousActionVector}{\mathbf{a}} \newcommand{\ContinuousCurrent}{I_{\text{cont}}} \newcommand{\ContinuousFactorialFunction}{\Gamma} \newcommand{\ContinuousMeasurementNoiseIntensity}{\mathbf{R}_{\text{cont}}} \newcommand{\ContinuousMotionModel}{\mathbf{f}} \newcommand{\ContinuousOutcome}{\mathbf{x}} \newcommand{\ContinuousRandomVariable}{\mathbf{X}} \newcommand{\ContinuousStateTransitionMatrix}{\boldsymbol{\Phi}} \newcommand{\ContinuousTorque}{\tau_{\text{cont}}} \newcommand{\ContractedBarrierFunction}{h_{\text{contracted}}} \newcommand{\ControlAffineDriftField}{\mathbf{f}} \newcommand{\ControlAffineInputField}{\mathbf{g}} \newcommand{\ControlCommand}{\mathbf{u}} \newcommand{\ControlCommandDerivative}{\dot{\mathbf{u}}} \newcommand{\ControlCommandSpace}{\mathcal{U}} \newcommand{\ControlConversionRate}{\hat{p}_A} \newcommand{\ControlCycleIndex}{i} \newcommand{\ControlInput}{\mathbf{u}} \newcommand{\ControlInputDimension}{m} \newcommand{\ControlInputLowerLimit}{\mathbf{u}_{\min}} \newcommand{\ControlInputSet}{\mathcal{U}} \newcommand{\ControlInputUpperLimit}{\mathbf{u}_{\max}} \newcommand{\ControlInputWindow}{\mathbf{u}_{[t, t+\Delta t]}} \newcommand{\ControlSampleIndex}{k} \newcommand{\ControlSampleSize}{m_A} \newcommand{\ControlSetpointJerk}{\mathbf{j}} \newcommand{\ControlSetpointPeriod}{\Delta t_{\text{ctrl}}} \newcommand{\ControlStepIndex}{t} \newcommand{\ControlTaskIndex}{i} \newcommand{\ControllabilityMatrix}{\mathbf{C}_{\text{ctrb}}} \newcommand{\ControlledStopCommand}{\mathbf{u}_{\text{stop}}} \newcommand{\ControllerReactionDelay}{T_{\text{react}}} \newcommand{\ConversationTurnIndex}{i} \newcommand{\ConverterLockoutVoltage}{V_{\text{uvlo}}} \newcommand{\ConveyorSpeed}{v_{\text{conv}}} \newcommand{\ConveyorSpeedBound}{v_{\text{conv}}} \newcommand{\ConvolutionActivation}{H} \newcommand{\ConvolutionTimeInstant}{t'} \newcommand{\CookedTokenKeyVector}{\mathbf{k}_{\text{cooked}}} \newcommand{\CookedTokenQueryVector}{\mathbf{q}_{\text{cooked}}} \newcommand{\CoolantHeatLoad}{P_{\text{thermal}}} \newcommand{\CoolantMassFlowRate}{\dot{m}} \newcommand{\CoolantTemperature}{T} \newcommand{\CoolingEnergy}{E_{\text{cooling}}} \newcommand{\CoordinateFrameEmbedding}{\mathbf{e}_{\text{frame}}} \newcommand{\CoordinationLatency}{L_{\text{lat,coordination}}} \newcommand{\CoordinationOverhead}{h} \newcommand{\CopperIronThermalResistance}{R_{\text{th,cu-iron}}} \newcommand{\CopperReferenceTemperature}{T_0} \newcommand{\CopperTemperatureCoefficient}{\alpha_{\text{Cu}}} \newcommand{\CopperThermalCapacitance}{C_{\text{cu}}} \newcommand{\CopperThermalTimeConstant}{\tau_{\text{th,cu}}} \newcommand{\CoreAmbientThermalResistance}{R_{\text{th,ca}}} \newcommand{\CoreRailVoltageDroop}{\Delta V_{\text{droop}}} \newcommand{\CoreThermalCapacitance}{C_{\text{core}}} \newcommand{\CoresetBudget}{K} \newcommand{\CoriolisCentrifugalMatrix}{\mathbf{C}} \newcommand{\CorrectCandidateTrialPassProbability}{p_{g}} \newcommand{\CorrectClassIndex}{c} \newcommand{\CorrectClassLogit}{z_{c}} \newcommand{\CorrectClassProbability}{\hat{y}_{c}} \newcommand{\CorrectnessReward}{R_{\text{corr}}} \newcommand{\CorrelationCoefficient}{\rho} \newcommand{\CorruptedAttentionScoreMatrix}{\mathbf{S}_{\text{corrupt}}} \newcommand{\CorruptedModelWeight}{w'} \newcommand{\CostAnomalyScore}{Z} \newcommand{\CostBudgetUsedFraction}{\rho_C} \newcommand{\CostCeiling}{C_{\max}} \newcommand{\CostPerAcceptedTask}{C_{\text{eff}}} \newcommand{\CostPerEmittedArtifact}{C_{\text{emit}}} \newcommand{\CostToGo}{C} \newcommand{\CoulombFrictionCoefficient}{\mu} \newcommand{\CoulombFrictionForce}{F_{\text{friction}}} \newcommand{\CountedFailureIndicator}{e} \newcommand{\CovariateDriftBound}{\mathcal{O}(S^2 \epsilon)} \newcommand{\CoverageFactor}{k} \newcommand{\CpuEnergy}{E_{\text{CPU}}} \newcommand{\CredibleBrakingDeceleration}{a_{\text{brake}}} \newcommand{\CreditWindowCapacity}{N_{\text{win}}} \newcommand{\CriticActionReturnEstimate}{Q_{\phi}} \newcommand{\CriticApproximationError}{\epsilon} \newcommand{\CriticModel}{M_{\text{value}}} \newcommand{\CriticParameters}{\phi} \newcommand{\CriticReturnEstimate}{V_{\phi}} \newcommand{\CriticalBatchSize}{B^{*}} \newcommand{\CriticalConstraint}{c} \newcommand{\CriticalPathDuration}{T_{\text{crit}}} \newcommand{\CriticalSectionIndex}{s} \newcommand{\CriticalSectionWcet}{C^{\text{cs}}} \newcommand{\CriticalTrackingErrorBound}{\epsilon_{\text{crit}}} \newcommand{\CriticalTransitDistance}{d_{\text{crit}}} \newcommand{\CrossEntropyLevelThreshold}{\gamma} \newcommand{\CrossEntropyLoss}{\mathcal{L}_{\text{CE}}} \newcommand{\CrossoverFrequency}{\omega_c} \newcommand{\CruiseSpeed}{v_{c}} \newcommand{\CumulativeArrivals}{A} \newcommand{\CumulativeCompletions}{C} \newcommand{\CumulativeIncidentCount}{N} \newcommand{\CumulativeLogLikelihoodRatio}{\Lambda} \newcommand{\CumulativeScheduleStepIndex}{s} \newcommand{\CumulativeTransmittance}{T} \newcommand{\CumulativeWorkCost}{C} \newcommand{\CurrentBinProportion}{A} \newcommand{\CurrentDistribution}{P_t} \newcommand{\CurrentFeatureMean}{\mu_{\text{curr}}} \newcommand{\CurrentFeatureStandardDeviation}{\sigma_{\text{curr}}} \newcommand{\CurrentLayerWidth}{n_{\ell}} \newcommand{\CurrentModelParameters}{\theta_{\text{old}}} \newcommand{\CurrentMonotonicTime}{t_{\text{now,mono}}} \newcommand{\CurrentNodeIndex}{j} \newcommand{\CurrentPeriodCost}{C_{\text{current}}} \newcommand{\CurrentStateDigest}{h_{\text{state},t}} \newcommand{\CurrentStateEstimate}{\hat{\mathbf{x}}_{t_{\text{current}}}} \newcommand{\CurrentTime}{t_{\text{now}}} \newcommand{\CurrentWallClockTime}{t_{\text{current}}} \newcommand{\CutCrossingDataVolume}{V_{\text{cut}}} \newcommand{\CvaeEncoderParameters}{\phi} \newcommand{\CvaeRecognitionEncoder}{q_\phi} \newcommand{\CycleAveragePowerCeiling}{\bar{P}_{\max}} \newcommand{\CycleGuardTime}{t_{\text{guard}}} \newcommand{\CylinderForce}{F_{\text{cyl}}} \newcommand{\DailyAccountQueryCount}{q_{\text{daily}}} \newcommand{\DailyQueryVolume}{Q_{\text{day}}} \newcommand{\DamageEventCount}{N_{\text{damage}}} \newcommand{\DamageProbabilityTolerance}{\epsilon} \newcommand{\DamageProbabilityUpperBound}{p_U} \newcommand{\DamagingOutcomeIndicator}{Y} \newcommand{\DampedLeastSquaresPseudoinverse}{\mathbf{J}_{\lambda}^\dagger} \newcommand{\DampedStepConfiguration}{\mathbf{q}_\lambda} \newcommand{\DampingRatio}{\zeta} \newcommand{\DataAcquisitionCost}{C_{\text{acquire}}} \newcommand{\DataDebtGrowthRate}{r} \newcommand{\DataEgressCost}{C_{\text{egress}}} \newcommand{\DataFieldBitCount}{B_{\text{data},i}} \newcommand{\DataInformationContent}{\mathcal{I}} \newcommand{\DataLabelingCost}{C_{\text{label}}} \newcommand{\DataLoaderWorkerCount}{W} \newcommand{\DataMovementEnergyFraction}{q} \newcommand{\DataParallelDegree}{N_{\text{DP}}} \newcommand{\DataPhaseBitRate}{R_{\text{data}}} \newcommand{\DataPipelineProcessingCost}{C_{\text{process}}} \newcommand{\DataProcessingCost}{C_{\text{process}}} \newcommand{\DataScaleCoefficient}{B} \newcommand{\DataScalingExponent}{\beta} \newcommand{\DataScalingLossFactor}{D^{-\beta}} \newcommand{\DataStallFraction}{f_{\text{stall}}} \newcommand{\DataStorageCost}{C_{\text{store}}} \newcommand{\DataSupplyRate}{R_{\text{data}}} \newcommand{\DataTaxonomyAxis}{\mathsf{Data}} \newcommand{\DataVolume}{D_{\text{vol}}} \newcommand{\DatasetQuery}{f} \newcommand{\DatasetQueryResult}{v} \newcommand{\DatasetShardCount}{K_{\text{shards}}} \newcommand{\DatasetSize}{D} \newcommand{\DatasetTransferTime}{T} \newcommand{\DcBusBulkCapacitance}{C_{\text{bus}}} \newcommand{\DcBusOvervoltageThreshold}{V_{\text{max\_safe}}} \newcommand{\DcBusVoltage}{V_{\text{bus}}} \newcommand{\DcRailVoltage}{V_{\text{rail}}} \newcommand{\DeadTimeCycleCount}{N_{\text{dtg}}} \newcommand{\DeadTimeDqVoltageError}{\Delta V_{d,q}} \newcommand{\DeadTimeSafetyMargin}{t_{\text{margin}}} \newcommand{\DeadTimeTickPeriod}{T_{\text{dtg}}} \newcommand{\DeadTimeVoltageError}{\Delta V_{\text{phase}}} \newcommand{\DeadlineInstant}{t_{\text{deadline}}} \newcommand{\DebiasingTotalLoss}{\mathcal{L}_{\text{total}}} \newcommand{\DebounceFrameCount}{N} \newcommand{\DecisionProcessState}{s} \newcommand{\DecisionScore}{s_{\text{dec}}} \newcommand{\DecisionStepIndex}{k} \newcommand{\DecodeArithmeticIntensity}{I_{\text{decode}}} \newcommand{\DecodeBatchSize}{B_{\text{dec}}} \newcommand{\DecodeInterval}{T_{\text{decode}}} \newcommand{\DecodeRequestSet}{\mathcal{D}} \newcommand{\DecodeTokenTimeFloor}{T_{\text{token}}} \newcommand{\DecoderEvaluationCount}{N_{\text{eval}}} \newcommand{\DecoderPassTime}{t_{\text{pass}}} \newcommand{\DecodingConstraintState}{q} \newcommand{\DecomposedTensor}{\mathcal{Y}} \newcommand{\DecomposedTensorEntry}{y_{ijt}} \newcommand{\DecouplingCapacitance}{C} \newcommand{\DecouplingDriftVector}{\mathbf{b}} \newcommand{\DecouplingMatrix}{\mathbf{E}} \newcommand{\DecouplingMatrixElement}{E} \newcommand{\DedicatedHourlyFixedCost}{C_{\text{fixed}}} \newcommand{\DedicatedVariableTokenCost}{c_{\text{ded}}} \newcommand{\DefectiveActionProbability}{p_{\text{bad}}} \newcommand{\DefinitionSerializedSize}{S} \newcommand{\DeflectionComplianceAllowance}{\delta_{\text{deflect}}} \newcommand{\DegradedFrictionCoefficient}{\mu_{\text{fault}}} \newcommand{\DegradedStepTime}{T_{\text{slow}}} \newcommand{\DelassusOperator}{\mathbf{A}_{\text{Delassus}}} \newcommand{\DelayPhaseLag}{\Delta \phi} \newcommand{\DelayTravelDistance}{d_{\text{delay}}} \newcommand{\DelayWindowIntegrationTime}{\sigma} \newcommand{\DelayedObservation}{\mathbf{y}_{t_0}} \newcommand{\DelegatedAllocationAmount}{b} \newcommand{\DelegationTokenMultiple}{r} \newcommand{\DeliveredActuatorTorque}{\tau_{\text{act}}} \newcommand{\DeliveredCapacityFraction}{u} \newcommand{\DemandCap}{x_{\max}} \newcommand{\DemandPriceElasticity}{\epsilon_{\text{elast}}} \newcommand{\DemandThreshold}{x} \newcommand{\DemonstratedTargetA}{\mathbf{y}_A} \newcommand{\DemonstratedTargetB}{\mathbf{y}_B} \newcommand{\DemonstrationActionDistribution}{p} \newcommand{\DemonstrationActionLabel}{\mathbf{a}} \newcommand{\DemonstrationArchiveActionDistribution}{p_{\text{demo}}} \newcommand{\DemonstrationChunkDistribution}{p_{\text{data}}} \newcommand{\DemonstrationDataset}{\mathcal{D}_{\text{demo}}} \newcommand{\DemonstrationRetentionRate}{R} \newcommand{\DemonstratorAction}{\mathbf{a}^{*}} \newcommand{\DemonstratorActionComponent}{a} \newcommand{\DenseEvaluationEnergy}{E_{\text{eval}}} \newcommand{\DenseEvaluationRate}{f_{\text{eval}}} \newcommand{\DenseVoxelGridMemory}{M_{\text{dense}}} \newcommand{\DepartmentQuotaLimit}{Q_{\text{department}}} \newcommand{\DependencyGraphEdgeSet}{E} \newcommand{\DependencyGraphVertex}{v} \newcommand{\DependencyGraphVertexSet}{V} \newcommand{\DepletedBusVoltage}{V_{\text{low}}} \newcommand{\DeploymentAge}{t} \newcommand{\DeploymentDistribution}{p_{\text{deploy}}} \newcommand{\DeploymentDuration}{T_{\text{deployment}}} \newcommand{\DepthBinCount}{D} \newcommand{\DepthBinDistribution}{\boldsymbol{\alpha}_{u, v}} \newcommand{\DepthBinIndex}{k} \newcommand{\DepthBinLogits}{\mathbf{d}_{u, v}} \newcommand{\DepthBinProbability}{\alpha_{u, v}} \newcommand{\DepthCalibrationScale}{s} \newcommand{\DepthCalibrationShift}{t} \newcommand{\DepthCriticalPathLatency}{T^{\text{depth}}} \newcommand{\DepthFrameRate}{f_{\text{cam}}} \newcommand{\DepthHypothesis}{d} \newcommand{\DepthModeComponentVector}{\mathbf{c}_s} \newcommand{\DepthModeFactorMatrix}{\mathbf{C}} \newcommand{\DepthModeFactorSlice}{\mathbf{c}} \newcommand{\DepthRayCount}{N_{\text{rays}}} \newcommand{\DepthScalingRatio}{\alpha} \newcommand{\DepthStandardDeviation}{\sigma_z} \newcommand{\DerivativeControlEffort}{\mathbf{u}_{d}} \newcommand{\DerivativeFilterTimeConstant}{T_{f}} \newcommand{\DerivativeGainMatrix}{\mathbf{K}_{d}} \newcommand{\DerivativeOperator}{d} \newcommand{\DerivativeSplineControlPoint}{\mathbf{v}} \newcommand{\DerivedMemoryEntry}{c} \newcommand{\DerivedRecord}{y} \newcommand{\DesignLatencyQuantile}{Q_{1-\epsilon}} \newcommand{\DesiredContactPosition}{x_{\text{des}}} \newcommand{\DesiredContactVelocity}{\dot{x}_{\text{des}}} \newcommand{\DesiredTaskAcceleration}{\ddot{\mathbf{x}}_d} \newcommand{\DesiredTaskPosition}{\mathbf{x}_d} \newcommand{\DesiredTaskSpaceAcceleration}{\ddot{\mathbf{x}}^{\text{des}}} \newcommand{\DesiredTaskVelocity}{\dot{\mathbf{x}}_d} \newcommand{\DestinationRankIndex}{j} \newcommand{\DetectionCount}{n_{\text{det}}} \newcommand{\DetectionInterval}{t_{\text{detect}}} \newcommand{\DetectionMeasurementNoiseCovariance}{\boldsymbol{\Sigma}_{\text{meas},j}} \newcommand{\DetectionRangeShortfall}{\Delta d_{\text{detect}}} \newcommand{\DetectionTimestamp}{t_{\text{det}}} \newcommand{\DetectorMissProbability}{p_{\text{miss}}} \newcommand{\DeterministicPolicy}{\mu_{\theta}} \newcommand{\DevelopmentIterationCount}{N_{\text{dev}}} \newcommand{\DeviationDisadvantage}{u} \newcommand{\DeviceCount}{N} \newcommand{\DeviceEnergy}{E_{\text{device}}} \newcommand{\DeviceHardwareTime}{T_{\text{hw}}} \newcommand{\DeviceMemoryCapacity}{M_{\text{device}}} \newcommand{\DevicePower}{P_{\text{device}}} \newcommand{\DeviceRequestCapacity}{Q_{\text{req,max}}} \newcommand{\DeviceSilentCorruptionProbability}{p} \newcommand{\DiagnosticCoverage}{C_{\text{diag}}} \newcommand{\DictionaryCoefficientMatrix}{\mathbf{C}} \newcommand{\DifferentiabilityClass}{C} \newcommand{\DifferentialEntropy}{h} \newcommand{\DiffusionCumulativeSchedule}{\bar{\alpha}} \newcommand{\DiffusionGaussianNoise}{\boldsymbol{\epsilon}} \newcommand{\DiffusionMatchingLoss}{\mathcal{L}_{\text{diff}}} \newcommand{\DiffusionNoiseVariance}{\beta} \newcommand{\DiffusionStepCount}{N} \newcommand{\DiffusionStepIndex}{k} \newcommand{\DiffusionStepRetention}{\alpha} \newcommand{\DiffusionTimeCoordinate}{t_{\text{diff}}} \newcommand{\DirectAxisCurrent}{i_d} \newcommand{\DirectAxisInductance}{L_d} \newcommand{\DirectAxisVoltage}{v_d} \newcommand{\DirectionalCosineMatrix}{\mathbf{R}} \newcommand{\DirectionalDerivativeStep}{\epsilon} \newcommand{\DisadvantagedGroupClassificationThreshold}{\gamma_{\text{cls},g=\text{B}}} \newcommand{\DiscordantPairCount}{n_{\text{disc}}} \newcommand{\DiscordantPairFraction}{\psi} \newcommand{\DiscountFactor}{\gamma} \newcommand{\DiscountedReturn}{G} \newcommand{\DiscountedReturnStepOffset}{j} \newcommand{\DiscountedStateVisitationDistribution}{d} \newcommand{\DiscreteLqrFeedbackGain}{\mathbf{K}_{\text{lqr},d}} \newcommand{\DiscreteLqrQuadraticObjective}{J_d} \newcommand{\DiscreteOutcome}{x} \newcommand{\DiscretePlantDynamics}{f} \newcommand{\DiscreteRandomVariable}{X} \newcommand{\DiscreteSampleIndex}{k} \newcommand{\DiscreteStateSpaceInputMatrix}{\mathbf{B}_{d}} \newcommand{\DiscreteStateSpaceSystemMatrix}{\mathbf{A}_{d}} \newcommand{\DiscretizationBinCount}{n_{\text{bin}}} \newcommand{\DisengagedTakeoverResponseTime}{T_{\Sigma,2}} \newcommand{\DiskBandwidth}{\text{BW}_{\text{disk}}} \newcommand{\DisparityStandardDeviation}{\sigma_d} \newcommand{\DispatchAdmissionCeiling}{\Delta_{\text{da,max}}} \newcommand{\DispatchAdmissionInterval}{\Delta_{\text{da}}} \newcommand{\DispatchObservationAge}{t_{\text{age}}} \newcommand{\DispatchedOperationCount}{N_{\text{ops}}} \newcommand{\DisplayPipelineLatency}{t_{\text{disp}}} \newcommand{\DispreferredReferenceRelativeScore}{\Delta_l} \newcommand{\DispreferredTrajectory}{\tau_l} \newcommand{\DistanceEstimateStandardDeviation}{\sigma} \newcommand{\DistanceMeasurement}{z} \newcommand{\DistanceNormOrder}{p} \newcommand{\DistanceQueryPoint}{\mathbf{y}} \newcommand{\DistillationClassProbability}{p^{(T_{\text{distill}})}} \newcommand{\DistillationLoss}{\mathcal{L}_{\text{distill}}} \newcommand{\DistillationLossWeight}{\gamma_{\text{KD}}} \newcommand{\DistillationTemperature}{T_{\text{distill}}} \newcommand{\DistortedImageAbscissa}{x_d} \newcommand{\DistortedImageOrdinate}{y_d} \newcommand{\DistributedStepTime}{T_{\text{step}}} \newcommand{\DisturbanceAccelerationBound}{a_{\text{dist}}} \newcommand{\DisturbanceBasisCoefficient}{\psi} \newcommand{\DisturbanceBasisCount}{K} \newcommand{\DisturbanceBasisFunction}{B} \newcommand{\DisturbanceBudget}{\Delta_{w}} \newcommand{\DisturbanceDimension}{p} \newcommand{\DisturbanceForceBound}{d_{\max}} \newcommand{\DisturbanceParameterSet}{\Psi} \newcommand{\DisturbanceParameterVector}{\boldsymbol{\psi}} \newcommand{\DisturbanceTrajectory}{w_{\text{dist}}} \newcommand{\DivergenceInstant}{t_{\text{div}}} \newcommand{\DivergenceMeasure}{\mathcal{D}} \newcommand{\DivergenceTolerance}{\delta_{\text{tol}}} \newcommand{\DmaBurstPeriod}{T_{\text{dma}}} \newcommand{\DmaBurstStallTime}{C_{\text{dma}}} \newcommand{\DmaQueueTime}{t_{\text{DMA}}} \newcommand{\DocumentPayloadFraction}{q} \newcommand{\DomainRandomizationDistribution}{\mathcal{D}_{\text{DR}}} \newcommand{\DomainRandomizationObjective}{J_{\text{DR}}} \newcommand{\DominantComponentEnergy}{E_{\text{dominant}}} \newcommand{\DominantShare}{d} \newcommand{\DoorOpenReward}{r_{\text{open}}} \newcommand{\DoubleIntegratorPosition}{p} \newcommand{\DoubleIntegratorPositionDerivative}{\dot{p}} \newcommand{\DoubleIntegratorVelocity}{v} \newcommand{\DoubleIntegratorVelocityDerivative}{\dot{v}} \newcommand{\DoubleTreeAllReduceTime}{T_{\text{double-tree}}} \newcommand{\DownstreamStageLatency}{Y} \newcommand{\DpoLoss}{\mathcal{L}_{\text{DPO}}} \newcommand{\DraftAcceptanceRate}{\alpha} \newcommand{\DraftCandidateToken}{\tilde{x}} \newcommand{\DraftModelDistribution}{q_{\phi}} \newcommand{\DraftPositionAcceptanceProbability}{\alpha_{\text{spec}, j}} \newcommand{\DraftPositionIndex}{i} \newcommand{\DraftSamplingDistribution}{q} \newcommand{\DraftTokenAcceptanceProbability}{\alpha_{\text{acc}}} \newcommand{\DraftTokenCostRatio}{\beta} \newcommand{\DraftTokenCount}{\gamma} \newcommand{\DraftedToken}{T} \newcommand{\DragonflyGlobalChannelCount}{h} \newcommand{\DragonflyGroupRouterCount}{a} \newcommand{\DragonflyTerminalPortCount}{p} \newcommand{\DrainSourceVoltage}{V_{\text{ds}}} \newcommand{\DriftElapsedTime}{t_{\text{drift}}} \newcommand{\DriftImpactTime}{t_{\text{impact}}} \newcommand{\DriftLieDerivativeOperator}{L_{\mathbf{f}}} \newcommand{\DriftSpeedBound}{v_{\text{drift}}} \newcommand{\DriftTestSampleSize}{n} \newcommand{\DriftVelocityBound}{v_{\text{drift}}} \newcommand{\DriveBrakingForceCeiling}{F} \newcommand{\DriveBrakingTorqueCeiling}{\tau} \newcommand{\DrivenWheelLoadFraction}{\phi_{\text{drive}}} \newcommand{\DriverInterruptLatency}{t_{\text{driver\_irq}}} \newcommand{\DrivetrainAntiresonanceFrequency}{f_{\text{anti}}} \newcommand{\DrivetrainResonanceFrequency}{f_{\text{res}}} \newcommand{\DroopedSupplyVoltage}{V_{\text{droop}}} \newcommand{\DropletDiameter}{d_{\text{droplet}}} \newcommand{\DropoutProbability}{p_{\text{drop}}} \newcommand{\DualNumberInfinitesimal}{\epsilon} \newcommand{\DuplicateEffectProbability}{p_{\text{dup}}} \newcommand{\DurableAcknowledgmentTime}{t_{\text{ack}}} \newcommand{\DurableStoreWriteBandwidth}{\text{BW}_{\text{store}}} \newcommand{\DutyCyclePeriod}{T_{\text{period}}} \newcommand{\DynamicPower}{P_{\text{dynamic}}} \newcommand{\DynamicReachableSet}{\mathcal{R}} \newcommand{\DynamicsRealityGap}{\Delta_{\text{dyn}}} \newcommand{\EagerExecutionTime}{T_{\text{eager}}} \newcommand{\EarlierBaseFlangeTransform}{\mathbf{T}_{\text{base}, k}^{\text{flange}}} \newcommand{\EarlierCameraTargetTransform}{\mathbf{T}_{\text{cam}, k}^{\text{target}}} \newcommand{\EarlierControlStepIndex}{t'} \newcommand{\EarlierWorkerCount}{k} \newcommand{\EarliestConflictTime}{t_{\text{conflict}}} \newcommand{\EarthReferenceFrame}{\mathcal{F}_{\text{earth}}} \newcommand{\EchoFactor}{e} \newcommand{\EchoRoundTripTime}{t_{\text{rt}}} \newcommand{\EditGrantRights}{\mathcal{R}_{\Gamma_{\text{edit}}}} \newcommand{\EditPhaseCapabilityGrant}{\Gamma_{\text{edit}}} \newcommand{\EffectiveAdmissionCeiling}{Q_{\text{effective}}} \newcommand{\EffectiveApiOutputTokenPrice}{c_{\text{API}}} \newcommand{\EffectiveBrakingDelay}{T_{\text{eff}}} \newcommand{\EffectiveBranchingFactor}{b_{\text{eff}}} \newcommand{\EffectiveConfidentialityLabel}{\kappa_{\text{eff}}} \newcommand{\EffectiveFleetThroughput}{R_{\text{eff}}} \newcommand{\EffectiveImpactMass}{m_{\text{eff}}} \newcommand{\EffectiveIntegrityProvenance}{\iota_{\text{eff}}} \newcommand{\EffectiveJointInertia}{J_{\text{eff}}} \newcommand{\EffectiveLossResistance}{R_{\text{eff}}} \newcommand{\EffectiveSampleSize}{N_{\text{eff}}} \newcommand{\EffectiveSeriesStiffness}{k_{\text{eff}}} \newcommand{\EffectiveServiceRate}{\mu_{\text{eff}}} \newcommand{\EffectiveSpotTrainingCost}{C_{\text{effective}}} \newcommand{\EffectiveStorageThroughput}{R_{\text{storage,eff}}} \newcommand{\EffectiveWasteFraction}{W_{\text{effective}}} \newcommand{\EfficiencyHw}{\eta_{\text{hw}}} \newcommand{\EgressArrivalRate}{\lambda_{\text{arr}}} \newcommand{\EgressBufferCapacity}{Q_{\text{max}}} \newcommand{\EgressPortUtilization}{\rho_{\text{egress}}} \newcommand{\EgressPrice}{R_{\text{egress/GB}}} \newcommand{\EgressQueueOccupancy}{Q} \newcommand{\EgressServiceRate}{\mu} \newcommand{\ElapsedPlanningPeriods}{n} \newcommand{\ElasticJointTorque}{\mathbf{z}} \newcommand{\ElasticMaximumWorkerCount}{N_{\text{max}}} \newcommand{\ElasticMinimumWorkerCount}{N_{\text{min}}} \newcommand{\ElasticModalFrequencyMatrix}{\boldsymbol{\Omega}} \newcommand{\ElasticPotentialEnergy}{E} \newcommand{\ElasticStrainEnergy}{U_{\text{elastic}}} \newcommand{\ElasticTorqueSecondDerivative}{\ddot{\mathbf{z}}} \newcommand{\ElbowSwivelAngle}{\psi} \newcommand{\ElectricalAngularSpeed}{\omega_e} \newcommand{\ElectricalResistance}{R} \newcommand{\ElectricalRotorAngle}{\theta_e} \newcommand{\ElectricalTimeConstant}{\tau_e} \newcommand{\ElectricityPrice}{R_{\$/\text{kWh}}} \newcommand{\ElementStorageSize}{s_{\text{elem}}} \newcommand{\ElementaryCharge}{q} \newcommand{\ElementaryOperationCount}{W} \newcommand{\ElevationAngle}{\phi} \newcommand{\EligibleCachedPrefixLength}{S_{\text{hit}}} \newcommand{\EligibleTargetPositionSet}{\mathcal{P}_{\text{elig}}} \newcommand{\EligibleVectorCount}{N} \newcommand{\EliteSampleFraction}{\beta} \newcommand{\EmbeddingDimension}{d} \newcommand{\EmbeddingShardCount}{N_{\text{shards}}} \newcommand{\EmergencyStopContact}{S} \newcommand{\EmergencyStopCount}{n_{\text{estop}}} \newcommand{\EmittedArtifactCount}{N_{\text{emit}}} \newcommand{\EmittedTokenCount}{S_{\text{out}}} \newcommand{\EmpiricalBellmanOperator}{\mathcal{B}} \newcommand{\EmpiricalExceedanceFraction}{\hat{\zeta}_{u}} \newcommand{\EmpiricalTimestepAverage}{\hat{\mathbb{E}}} \newcommand{\EmpiricalTransferDiscrepancy}{\hat{\epsilon}_{\text{gap}}} \newcommand{\EmptyByteString}{\epsilon} \newcommand{\EncodedLatentState}{\hat{\mathbf{z}}} \newcommand{\EncoderAngle}{\theta_{\text{enc}}} \newcommand{\EncoderBitCount}{n} \newcommand{\EncoderLatentRepresentation}{\mathbf{z}} \newcommand{\EncoderVelocityEstimate}{\dot{\theta}_{\text{enc}}} \newcommand{\EncoderVelocityNoise}{\sigma_{\dot{\theta}_{\text{enc}}}} \newcommand{\EndEffectorCameraTransform}{\mathbf{T}_{EC}} \newcommand{\EndEffectorFirstAxisPosition}{x} \newcommand{\EndEffectorPitchAngle}{\phi_{\text{pitch}}} \newcommand{\EndEffectorPose}{\mathbf{T}_{WE}} \newcommand{\EndEffectorRollAngle}{\phi_{\text{roll}}} \newcommand{\EndEffectorSecondAxisPosition}{y} \newcommand{\EndEffectorTaskAcceleration}{\ddot{\mathbf{x}}} \newcommand{\EndEffectorTaskPosition}{\mathbf{x}} \newcommand{\EndEffectorTaskVelocity}{\dot{\mathbf{x}}} \newcommand{\EndEffectorThirdAxisPosition}{z} \newcommand{\EndEffectorTwist}{\mathbf{V}_E} \newcommand{\EndEffectorVelocity}{\mathbf{v}_e} \newcommand{\EndEffectorYawAngle}{\phi_{\text{yaw}}} \newcommand{\EndToEndRequestLatency}{L_{\text{lat,total}}} \newcommand{\EnergyCrossoverIntensity}{I_{\text{crossover}}} \newcommand{\EnergyLimitedContactForce}{F_E} \newcommand{\EnergyPerByteMoved}{E_{\text{move}}} \newcommand{\EnergyPerOperation}{E_{\text{compute}}} \newcommand{\EnergyTankBarrierFunction}{h_{\text{energy}}} \newcommand{\EnergyTankLevel}{E_{\text{tank}}} \newcommand{\EnergyTankPower}{\dot{E}_{\text{tank}}} \newcommand{\EnergyTankReserve}{E_{\text{min}}} \newcommand{\EnforcedCommandLabel}{\mathbf{a}_{\text{enf}, t}} \newcommand{\EnforcedCommandTap}{a_{\text{enf}}} \newcommand{\EnforcerComputeTime}{T_{\text{comp}}} \newcommand{\EnforcerDeadline}{T_{\text{deadline,enf}}} \newcommand{\EngineerHourlyCost}{C_{\text{engineer}}} \newcommand{\EngineeringTeamSize}{n} \newcommand{\EngineeringTemperatureCeiling}{T_{\text{ceil}}} \newcommand{\EnsembleSpreadThreshold}{\sigma_{\text{thresh}}} \newcommand{\EnsemblingDecayRate}{m} \newcommand{\EnsemblingWindowLength}{K} \newcommand{\EntityCount}{N_{\text{entities}}} \newcommand{\EntityEmbedding}{\mathbf{e}} \newcommand{\EntityIndex}{j} \newcommand{\EntropyTemperature}{\alpha} \newcommand{\EnvelopeCallCount}{N} \newcommand{\EnvelopeSetupTime}{T_{\text{setup}}} \newcommand{\EnvironmentCycleTime}{T_{\text{cycle}}} \newcommand{\EnvironmentFixture}{f} \newcommand{\EnvironmentLatentDimension}{d_z} \newcommand{\EnvironmentLatentVector}{\mathbf{z}} \newcommand{\EnvironmentParameters}{e} \newcommand{\EnvironmentResetTime}{T_{r}} \newcommand{\EnvironmentResponseFunction}{g} \newcommand{\EnvironmentRolloutStepCount}{h} \newcommand{\EnvironmentTransitionDistribution}{p} \newcommand{\EpipolarLine}{\mathbf{l}} \newcommand{\EpochCount}{N_{\text{epochs}}} \newcommand{\EpochIndex}{n_{\text{epoch}}} \newcommand{\EquilibriumWindingTemperature}{T_\infty} \newcommand{\EquivalentSeriesStiffness}{k_{\text{eq}}} \newcommand{\ErasureDataFragmentCount}{d} \newcommand{\ErasureParityFragmentCount}{m} \newcommand{\ErroneousPredictionCost}{C_{\text{error}}} \newcommand{\ErrorBudgetConsumption}{B} \newcommand{\ErrorCovarianceDerivative}{\dot{\mathbf{P}}} \newcommand{\ErrorFeedbackResidual}{\mathbf{e}} \newcommand{\ErrorFeedbackResidualElement}{e} \newcommand{\ErrorGrowthRate}{r} \newcommand{\ErrorRecoveryCost}{C_{\text{recovery}}} \newcommand{\EscalationDecision}{d} \newcommand{\EscalationLossMatrix}{\mathbf{L}} \newcommand{\EscalationThresholdProbability}{p_{\text{threshold}}} \newcommand{\EssentialMatrix}{\mathbf{E}} \newcommand{\EstimateEpoch}{t_{\text{est}}} \newcommand{\EstimatedAcceptanceProbability}{\hat{p}} \newcommand{\EstimatedAccuracy}{\hat{p}} \newcommand{\EstimatedCandidateUtility}{\hat{U}} \newcommand{\EstimatedCleanActionChunk}{\hat{\mathbf{A}}} \newcommand{\EstimatedCoriolisMatrix}{\hat{\mathbf{C}}} \newcommand{\EstimatedDamageProbability}{\hat{p}} \newcommand{\EstimatedDivergenceInstant}{\hat{t}_{\text{div}}} \newcommand{\EstimatedForceSensorBias}{\hat{b}} \newcommand{\EstimatedGravitationalTorque}{\hat{\mathbf{g}}} \newcommand{\EstimatedGripContactForce}{\hat{x}} \newcommand{\EstimatedHistoryAdvantage}{\hat{A}} \newcommand{\EstimatedInertiaMatrix}{\hat{\mathbf{M}}} \newcommand{\EstimatedPairedAcceptanceDifference}{\hat{\Delta}} \newcommand{\EstimatedPlantState}{\hat{\mathbf{x}}} \newcommand{\EstimatedPosition}{\hat{\mathbf{p}}} \newcommand{\EstimatedRemainingReturn}{\hat{V}} \newcommand{\EstimatedUtilityStandardDeviation}{s} \newcommand{\EstimatedVelocity}{\hat{\mathbf{v}}} \newcommand{\EstimatedWindingTemperature}{\hat{T}_{\text{wind}}} \newcommand{\EstimationErrorCovariance}{\mathbf{P}} \newcommand{\EstimatorDrawCount}{N} \newcommand{\EstimatorDrawStandardDeviation}{\sigma} \newcommand{\EstimatorState}{\mathbf{x}} \newcommand{\EstimatorStateVector}{\mathbf{x}} \newcommand{\EstimatorStepIndex}{k} \newcommand{\EulerIntegralFirstShape}{a} \newcommand{\EulerIntegralSecondShape}{b} \newcommand{\EulerIntegralVariable}{t} \newcommand{\EvaluatedExceedance}{y} \newcommand{\EvaluationPredicate}{\phi} \newcommand{\EvaluationSampleCount}{N} \newcommand{\EvaluationTrialCount}{N} \newcommand{\EvaluationTrialIndex}{i} \newcommand{\EventContrastThreshold}{C_{\text{th}}} \newcommand{\EventDetectionPower}{P_{\text{detect}}} \newcommand{\EventIndicator}{\mathbf{1}} \newcommand{\EventPacket}{e} \newcommand{\EventPolarity}{p} \newcommand{\EventProcessingEnergy}{E_{\text{event}}} \newcommand{\EvidenceCaptureInstant}{t_{\text{capture}}} \newcommand{\EvidenceEpoch}{t_0} \newcommand{\EvidenceHorizon}{\tau_{\text{ev}}} \newcommand{\EvidenceLowerBound}{\mathcal{L}_{\text{ELBO}}} \newcommand{\EvidenceRecordEvent}{e_{\text{obs}}} \newcommand{\ExactFailureLowerLimit}{p_{L}} \newcommand{\ExactFailureUpperLimit}{p_{U}} \newcommand{\ExampleAveragedBatchLoss}{\mathcal{L}_{\text{example}}} \newcommand{\ExampleIndex}{i} \newcommand{\ExampleLabel}{y} \newcommand{\ExceedanceReturnLevel}{z_\epsilon} \newcommand{\ExceedanceSampleSet}{\mathcal{Y}_u} \newcommand{\ExceedanceThreshold}{u} \newcommand{\ExcessDistributionFunction}{F_{u}} \newcommand{\ExcessForcePenaltyWeight}{\lambda_f} \newcommand{\ExcessSupportUpperEndpoint}{y_{\max}} \newcommand{\ExecutedActionStepCount}{T_a} \newcommand{\ExecutedToolCall}{a} \newcommand{\ExecutedTrialCount}{N_{\text{trial}}} \newcommand{\ExecutionHorizon}{H_{\text{exec}}} \newcommand{\ExecutionNondeterminism}{\xi} \newcommand{\ExecutionSwitchTime}{T_{\text{switch}}} \newcommand{\ExogenousDataDistribution}{\mathcal{D}} \newcommand{\ExpectedCategoryFrequency}{n_i^{\text{exp}}} \newcommand{\ExpectedCheckingTime}{T_{\text{check}}} \newcommand{\ExpectedCostLimit}{\delta} \newcommand{\ExpectedDecisionRisk}{\mathcal{R}} \newcommand{\ExpectedHistoryActionReturn}{Q} \newcommand{\ExpectedIrreversibleLoss}{L_A} \newcommand{\ExpectedNormalMaximum}{m_{N}} \newcommand{\ExpectedQueryDistribution}{p_{\text{expected}}} \newcommand{\ExpectedRemainingReturn}{V} \newcommand{\ExpectedReturnObjective}{J} \newcommand{\ExpectedRunCompletionTime}{T} \newcommand{\ExpectedTaskCostSum}{J} \newcommand{\ExperienceReplayBuffer}{\mathcal{D}} \newcommand{\ExperimentCount}{N_{\text{exp}}} \newcommand{\ExperimentUserIndex}{i} \newcommand{\ExpertCapacityFactor}{C_{\text{cap}}} \newcommand{\ExpertCount}{N_{\text{experts}}} \newcommand{\ExpertDiscountedStateVisitationDistribution}{d^{\pi^*}} \newcommand{\ExpertIndex}{e} \newcommand{\ExpertSelectionProbability}{p_e} \newcommand{\ExpertStateVisitationDistribution}{p^{\pi^*}} \newcommand{\ExpertTokenCount}{B_e} \newcommand{\ExploitCandidateFraction}{p_{\text{exp}}} \newcommand{\ExploitTrajectory}{\tau_{\text{hack}}} \newcommand{\ExploratoryStateVisitationDistribution}{p^{\pi_{\text{expl}}}} \newcommand{\ExponentBitIndex}{k} \newcommand{\ExponentialSeriesArgument}{u} \newcommand{\ExponentialStabilityConstant}{k} \newcommand{\ExposedCommunicationTime}{T_{\text{comm,exposed}}} \newcommand{\ExposedUnitCount}{E_{\text{exposure}}} \newcommand{\ExposureDuration}{t_{\text{exp}}} \newcommand{\ExposureMidpointTime}{t_{\text{mid}}} \newcommand{\ExposureMotionDisplacement}{\Delta x_{\text{motion}}} \newcommand{\ExposureStartTime}{t_{\text{start}}} \newcommand{\ExposureTravelDistance}{\Delta x} \newcommand{\ExtendedClassKInfinityFamily}{\mathcal{K}_\infty} \newcommand{\ExtendedDepthLength}{K_{\text{ext}}} \newcommand{\ExternalContactTorque}{\boldsymbol{\tau}_{\text{ext}}} \newcommand{\ExternalDispatchAction}{a_{\text{ext}}} \newcommand{\ExternalDisturbanceForce}{d} \newcommand{\ExternalDisturbanceLoad}{\mathbf{d}_{\text{ext}}} \newcommand{\ExternalJointTorque}{\tau_{\text{ext}}} \newcommand{\ExternalObjectWrench}{\mathbf{w}_{\text{ext}}} \newcommand{\ExternalWait}{T_{\text{wait}}} \newcommand{\ExternalWrench}{\mathbf{F}_{\text{ext}}} \newcommand{\ExtractionAnomalyClassifier}{f_{\theta}} \newcommand{\ExtractionQueryCount}{n_{\text{queries}}} \newcommand{\ExtrinsicCalibrationCovariance}{\boldsymbol{\Sigma}_{\text{ext}}} \newcommand{\ExtrinsicCovarianceJacobian}{\mathbf{J}_{\text{ext}}} \newcommand{\ExtrinsicLateralError}{\Delta y} \newcommand{\ExtrinsicMisalignmentAngle}{\theta_{\text{ext}}} \newcommand{\EyeInHandCameraMotion}{\mathbf{B}} \newcommand{\EyeInHandFlangeMotion}{\mathbf{A}} \newcommand{\EyeInHandUnknownTransform}{\mathbf{X}} \newcommand{\EyeToHandCameraPose}{\mathbf{B}'} \newcommand{\EyeToHandFlangePose}{\mathbf{A}'} \newcommand{\EyeToHandTargetTransform}{\mathbf{Z}} \newcommand{\EyeToHandUnknownTransform}{\mathbf{X}'} \newcommand{\FacilityEnergy}{E_{\text{facility}}} \newcommand{\FacilityHeatRemovalCapacity}{\dot{Q}_{\text{remove,max}}} \newcommand{\FacilityPower}{P_{\text{facility}}} \newcommand{\FacilityWaterConsumption}{W_{\text{water}}} \newcommand{\FactoredIntermediateActivation}{\mathbf{z}} \newcommand{\FactorizationRank}{k} \newcommand{\FailureDetectionTime}{T_{\text{detect}}} \newcommand{\FailureEventCost}{C_{\text{per-failure}}} \newcommand{\FailureFlagLatency}{\delta_{\text{flag}}} \newcommand{\FailureMarginFunction}{l} \newcommand{\FailureModeOccurrenceCount}{n_{f}} \newcommand{\FailureObservationInterval}{T} \newcommand{\FailureOverheadFraction}{F_{\text{fail}}} \newcommand{\FailureRecoveryTime}{T_{\text{recovery}}} \newcommand{\FailureRegion}{F} \newcommand{\FailureSet}{\mathcal{F}_{\text{fail}}} \newcommand{\FailureUpperConfidenceLimit}{p_{\text{fail, upper}}} \newcommand{\FairShareStabilizingConstant}{\epsilon_{\text{stab}}} \newcommand{\FairnessGapTolerance}{\epsilon_{\text{fair}}} \newcommand{\FakeQuantizedOutput}{x_{\text{fake}}} \newcommand{\FallbackCost}{C_{\text{fallback}}} \newcommand{\FallbackDeadline}{T_{\text{deadline,fallback}}} \newcommand{\FallbackHold}{T_{\text{hold}}} \newcommand{\FalseAcceptHarmCost}{C_{\text{harm}}} \newcommand{\FalseApprovalCount}{N_{\text{fa}}} \newcommand{\FalseApprovalOutcomeCount}{k} \newcommand{\FalseApprovalPropensity}{Q} \newcommand{\FalseApprovalPropensityLevel}{q} \newcommand{\FalseDiscoveryRateTarget}{q} \newcommand{\FalsificationInitialStateSet}{\mathcal{X}_0} \newcommand{\FanoutBackendCount}{m} \newcommand{\FarthestCandidateDistance}{D_{\max}} \newcommand{\FatTreeHostCount}{N_{\text{hosts}}} \newcommand{\FatigueLifeCycleCount}{N} \newcommand{\FaultContainmentLatency}{\Delta t_{\text{bounded}}} \newcommand{\FaultDetectionLatency}{\Delta t_{\text{det}}} \newcommand{\FaultDomainIsolation}{\mathcal{F}} \newcommand{\FaultInjectionDuration}{\Delta t_{\text{duration}}} \newcommand{\FaultStartTimestamp}{t_{\text{fault\_start}}} \newcommand{\FaultTakeoverLatency}{\Delta t_{\text{takeover}}} \newcommand{\FaultTakeoverTimestamp}{t_{\text{takeover}}} \newcommand{\FaultToleranceCost}{C_{\text{ft}}} \newcommand{\FaultToleranceInvestment}{x} \newcommand{\FeasibleOutputTokenRate}{\mu_{\text{out}}} \newcommand{\FeasibleTrajectoryProjection}{\Pi_{\mathcal{K}}} \newcommand{\FeasibleTrajectorySet}{\mathcal{K}} \newcommand{\FeatureCategoryCount}{k} \newcommand{\FeatureCategoryIndex}{i} \newcommand{\FeatureCellVector}{\mathbf{f}_{u, v}} \newcommand{\FeatureChannelCount}{C} \newcommand{\FeatureCount}{N_{\text{features}}} \newcommand{\FeatureFreshnessLatency}{T_{\text{freshness}}} \newcommand{\FeatureMapColumnCoordinate}{x} \newcommand{\FeatureMapGrowthRate}{g} \newcommand{\FeatureMapHeight}{H_{\text{img}}} \newcommand{\FeatureMapRowCoordinate}{y} \newcommand{\FeatureMapWidth}{W_{\text{img}}} \newcommand{\FeatureRecordTime}{t} \newcommand{\FeatureRetentionWindow}{T_{\text{retention}}} \newcommand{\FeatureUpdateInterval}{T_{\text{update}}} \newcommand{\FeatureUpdateLag}{T_{\text{staleness}}} \newcommand{\FeatureUpdateTimestamp}{t_{\text{feat}}} \newcommand{\FeatureViewingDistance}{r} \newcommand{\FederatedRoundCount}{R} \newcommand{\FederatedRoundIndex}{t} \newcommand{\FederatedTrainingEnergy}{E_{\text{federated}}} \newcommand{\FeedForwardOperations}{O_{\text{FFN}}} \newcommand{\FeedForwardWidth}{d_{\text{ff}}} \newcommand{\FeedbackCheckDuration}{t_{\text{check}}} \newcommand{\FeedbackCriticalPathLatency}{T^{\text{feedback}}} \newcommand{\FeedbackIntervalCount}{k} \newcommand{\FeedbackStepIndex}{t} \newcommand{\FeedforwardJointTorque}{\boldsymbol{\tau}_{\text{ff}}} \newcommand{\FeedthroughMatrix}{\mathbf{D}} \newcommand{\FewShotStepCount}{n_{\text{steps}}} \newcommand{\FewShotSupportSet}{\mathcal{D}_{\text{shot}}} \newcommand{\FiberPropagationSpeed}{c_{\text{fiber}}} \newcommand{\FieldbusCycleTime}{T_{\text{cycle}}} \newcommand{\FilmEncounterRate}{\lambda_{\text{film}}} \newcommand{\FilterSolveBudget}{T_{\text{budget}}} \newcommand{\FilterSolveTime}{T_{\text{solve}}} \newcommand{\FilterTapCount}{N} \newcommand{\FilterWeight}{w} \newcommand{\FilteredScreenSpaceCovariance}{\boldsymbol{\Sigma}_{2D}'} \newcommand{\FinalBusVoltage}{V_{\text{final}}} \newcommand{\FinalGeneratorLatentVector}{\mathbf{z}_{m}} \newcommand{\FinalLayerFunction}{f_{N_L}} \newcommand{\FinalLayerWidth}{n_{N_L}} \newcommand{\FinalMiniBatchActivation}{a_{B}} \newcommand{\FinalRecurrentHiddenState}{\mathbf{h}_{S}} \newcommand{\FinalWatchdogToken}{T_{\text{final}}} \newcommand{\FingerNormalForce}{f_n} \newcommand{\FingerTangentialForce}{\mathbf{f}_t} \newcommand{\FinishedWorkerCount}{j} \newcommand{\FiniteChange}{\Delta} \newcommand{\FiniteSampleGeneralizationBound}{\delta_N} \newcommand{\FiniteTimeHorizon}{T} \newcommand{\FirstAdjacentCheckIndex}{a} \newcommand{\FirstAdjacentCheckPassProbability}{p_{a}} \newcommand{\FirstAdjacentCheckSlotTime}{T_{a}} \newcommand{\FirstAtomicGradientUpdate}{A} \newcommand{\FirstCatalogDefinitionCount}{n_{\text{def},A}} \newcommand{\FirstCatalogDefinitionSize}{S_{A}} \newcommand{\FirstClassCoverageFloor}{a} \newcommand{\FirstClientMaskedUpdate}{\mathbf{y}_A} \newcommand{\FirstClientModelParameters}{\theta_A} \newcommand{\FirstComparedGroupLabel}{a} \newcommand{\FirstComparedItem}{i} \newcommand{\FirstDiscardedSingularNumber}{\sigma_{r+1}} \newcommand{\FirstErrorStepIndex}{k} \newcommand{\FirstFloatingPointAddend}{a} \newcommand{\FirstGroupClassificationThreshold}{\tau_{\text{thr},a}} \newcommand{\FirstGroupQualifiedFraction}{q_a} \newcommand{\FirstGroupSampleApprovalRate}{\hat{p}_a} \newcommand{\FirstGroupSampleSize}{n_a} \newcommand{\FirstGroupThresholdClassifier}{h_a} \newcommand{\FirstIncidentTime}{t_1} \newcommand{\FirstInputNodePrimal}{v_{1-N}} \newcommand{\FirstJaccardSet}{\mathcal{A}} \newcommand{\FirstMistakeEvent}{\mathcal{E}} \newcommand{\FirstRankComputeTime}{T_{\text{rank}_0}} \newcommand{\FirstRaterCategoryFraction}{p_{y,1}} \newcommand{\FirstRingTraceElement}{a} \newcommand{\FirstSummandStandardDeviation}{\sigma_a} \newcommand{\FirstTwinCriticReturnEstimate}{Q_{\phi_1}} \newcommand{\FittedSensitivity}{\lambda} \newcommand{\FixedClearanceAllowance}{\delta} \newcommand{\FlangeCameraTransform}{\mathbf{T}_{\text{flange}}^{\text{cam}}} \newcommand{\FlangePose}{\mathbf{T}_{\text{flange}}} \newcommand{\FlangeReferenceFrame}{\mathcal{F}_{\text{flange}}} \newcommand{\FlangeTargetTransform}{\mathbf{T}_{\text{flange}}^{\text{target}}} \newcommand{\FlattenedFilterWeights}{\mathbf{w}_{\text{col}}} \newcommand{\FleetAcceleratorCount}{N_{\text{fleet}}} \newcommand{\FleetCommunicationTaxonomyAxis}{C_2} \newcommand{\FleetComputeTaxonomyAxis}{C_1} \newcommand{\FleetCoordinationTaxonomyAxis}{C_3} \newcommand{\FleetEnergyProductivity}{\rho_{\text{energy}}} \newcommand{\FleetManufacturingDistribution}{\mathcal{M}} \newcommand{\FleetResourceCapacity}{C_{r}} \newcommand{\FleetRobotCount}{N_{\text{fleet}}} \newcommand{\FlippedFloatExponentField}{e'} \newcommand{\FloatEncodedNumber}{x} \newcommand{\FloatExponentField}{e} \newcommand{\FloatMantissaField}{m} \newcommand{\FloatSignBit}{s} \newcommand{\FloatingBaseAccelerations}{\ddot{\mathbf{q}}_b} \newcommand{\FloatingBaseBiasForces}{\mathbf{h}_b} \newcommand{\FloatingBaseInertiaBlock}{\mathbf{M}_{bb}} \newcommand{\FloatingBasePose}{\mathbf{q}_b} \newcommand{\FlopPrice}{c_{\text{FLOP}}} \newcommand{\FlowMatchingLoss}{\mathcal{L}_{\text{FM}}} \newcommand{\FlowProbabilityPath}{\rho} \newcommand{\FlowSampleVector}{\mathbf{y}} \newcommand{\FlowTimeCoordinate}{t} \newcommand{\FocalLength}{f} \newcommand{\FollowerForwardWave}{\mathbf{u}_s} \newcommand{\FollowerJointPositions}{\mathbf{q}_{\text{follower}}} \newcommand{\FollowerMechanicalLatency}{t_{\text{mech}}} \newcommand{\FollowerReturnWave}{\mathbf{w}_s} \newcommand{\ForceGuidedRelay}{K} \newcommand{\ForceReadingInnovation}{\nu} \newcommand{\ForceSensorBias}{b} \newcommand{\ForceSensorReading}{y} \newcommand{\ForegroundLatency}{L_{\text{lat,fg}}} \newcommand{\ForgetDataset}{D_{\text{forget}}} \newcommand{\ForkBoundarySet}{\mathcal{B}_{\text{fork}}} \newcommand{\ForkedTrajectoryTokenCount}{N_{\text{total}}} \newcommand{\FormatComplianceScore}{\Phi} \newcommand{\FormatEfficiency}{\eta_{\text{format}}} \newcommand{\FormatRewardWeight}{\lambda_{\text{fmt}}} \newcommand{\ForwardDiffusionDistribution}{q} \newcommand{\ForwardEulerEigenvalue}{\lambda_{\text{FE}}} \newcommand{\ForwardEulerTransitionMatrix}{\mathbf{A}_{\text{FE}}} \newcommand{\ForwardInvariantSafeSet}{\mathcal{C}} \newcommand{\ForwardKinematicsMap}{\mathbf{FK}} \newcommand{\ForwardOccupancySet}{\mathcal{R}} \newcommand{\ForwardPassTokenCount}{n} \newcommand{\ForwardPosteriorMean}{\tilde{\boldsymbol{\mu}}} \newcommand{\ForwardPosteriorVariance}{\tilde{\beta}} \newcommand{\FourthRingTraceElement}{d} \newcommand{\FrameBitCount}{B_{\text{frame}}} \newcommand{\FrameBlockingTime}{B} \newcommand{\FrameExposureStartTime}{t_{\text{start}}} \newcommand{\FrameIndex}{i} \newcommand{\FramePayloadSize}{B_{\text{payload}}} \newcommand{\FramePeriod}{T} \newcommand{\FrameReadoutTime}{t_{\text{readout}}} \newcommand{\FrameReleaseJitter}{J} \newcommand{\FrameResponseTime}{R} \newcommand{\FrameSerializationTime}{t_{\text{frame},i}} \newcommand{\FrameTransmissionTime}{C} \newcommand{\FrameWireBitCount}{B_{\text{wire},i}} \newcommand{\FreeConfigurationSpace}{\mathcal{C}_{\text{free}}} \newcommand{\FreeCreditCount}{N_{\text{free}}} \newcommand{\FreeSpaceDepth}{d_{\text{free}}} \newcommand{\FreeSpaceLogOddsIncrement}{L_{\text{free}}} \newcommand{\FreeSurfaceTiltAngle}{\theta_{\text{tilt}}} \newcommand{\FreeboardHeight}{h_{f}} \newcommand{\FreshEvidenceTime}{t_{\text{fresh}}} \newcommand{\FreshInputTokenCount}{S_{\text{fresh}}} \newcommand{\FreshnessObjective}{S_{\text{freshness}}} \newcommand{\FrictionCoefficientFloor}{\mu_{\min}} \newcommand{\FrictionPyramidMatrix}{\mathbf{F}} \newcommand{\FrobeniusNorm}{F} \newcommand{\FrozenBackboneFunction}{f} \newcommand{\FrozenFeatureEncoder}{f} \newcommand{\FrozenWeightMatrix}{\mathbf{W}_{\text{frozen}}} \newcommand{\FrustumFeature}{\mathbf{c}_{u, v, k}} \newcommand{\FullBatchLoss}{\mathcal{L}_B} \newcommand{\FullDatasetSize}{D_{\text{total}}} \newcommand{\FullPrecisionWeight}{w} \newcommand{\FullSnapshotWriteVolume}{D_{\text{vol,full}}} \newcommand{\FullSpeedTravelTime}{b} \newcommand{\FunctionInputAdjoint}{\bar{x}} \newcommand{\FunctionInputDimension}{N} \newcommand{\FunctionInputElement}{x} \newcommand{\FunctionInputTangent}{\dot{x}} \newcommand{\FunctionInputVariable}{x} \newcommand{\FunctionInputVector}{\mathbf{x}} \newcommand{\FunctionJacobian}{\mathbf{J}} \newcommand{\FunctionOutputDimension}{M} \newcommand{\FunctionOutputElement}{y} \newcommand{\FunctionOutputVariable}{z} \newcommand{\FunctionOutputVector}{\mathbf{y}} \newcommand{\FunctionSecondInputVariable}{y} \newcommand{\FundamentalMatrix}{\mathbf{F}} \newcommand{\FusedConvolutionBias}{\mathbf{b}_{\text{fused}}} \newcommand{\FusedConvolutionWeight}{\mathbf{W}_{\text{fused}}} \newcommand{\FusedTokenCount}{N_{\text{total}}} \newcommand{\FusionCandidate}{x_{\text{cand}}} \newcommand{\FusionInputList}{\mathcal{L}} \newcommand{\FusionInputRank}{r} \newcommand{\FusionInputTensor}{\mathbf{X}} \newcommand{\FusionIntermediateTensor}{\mathbf{Z}} \newcommand{\FusionOutputTensor}{\mathbf{Y}} \newcommand{\FutureControlTrajectory}{\mathbf{u}_{[t, \infty)}} \newcommand{\FutureTimeInstant}{t'} \newcommand{\GaeAdvantageEstimate}{\widehat{A}^{\text{GAE}}} \newcommand{\GateCurrent}{I_g} \newcommand{\GateDriverSkew}{t_{\text{prop, skew}}} \newcommand{\GatePropagationDelay}{t_{\text{prop}}} \newcommand{\GateSourceCapacitance}{C_{\text{gs}}} \newcommand{\GateSourceCharge}{Q_{\text{gs}}} \newcommand{\GateSourceVoltage}{V_{\text{gs}}} \newcommand{\GaussianCovarianceMatrix}{\boldsymbol{\Sigma}} \newcommand{\GaussianDistribution}{\mathcal{N}} \newcommand{\GaussianFirstAxisScale}{s_{x}} \newcommand{\GaussianMeanVector}{\boldsymbol{\mu}} \newcommand{\GaussianMechanismNoiseVector}{\mathbf{z}} \newcommand{\GaussianMechanismStandardDeviation}{\sigma_{\text{mech}}} \newcommand{\GaussianOpacityLogit}{o} \newcommand{\GaussianPrimitiveCovariance}{\boldsymbol{\Sigma}} \newcommand{\GaussianPrimitiveDensity}{G} \newcommand{\GaussianPrimitiveIndex}{i} \newcommand{\GaussianPrimitiveMean}{\boldsymbol{\mu}} \newcommand{\GaussianPrimitiveOpacity}{\alpha} \newcommand{\GaussianPrimitiveScaleMatrix}{\mathbf{S}} \newcommand{\GaussianSecondAxisScale}{s_{y}} \newcommand{\GaussianStandardDeviation}{\sigma} \newcommand{\GaussianThirdAxisScale}{s_{z}} \newcommand{\GaussianViewDependentColor}{c} \newcommand{\GearFaceWidth}{b} \newcommand{\GearModule}{m} \newcommand{\GearRatedFatigueLife}{L_{\text{gear}}} \newcommand{\GearReductionRatio}{N_{\text{gear}}} \newcommand{\GearTangentialLoad}{W_t} \newcommand{\GearToothBendingStress}{\sigma_b} \newcommand{\GearTorqueReversalCount}{n_{\text{gear}}} \newcommand{\GearboxTransmissionEfficiency}{\eta_{\text{gear}}} \newcommand{\GemmAccumulatorScale}{\beta} \newcommand{\GemmColumnDimension}{N} \newcommand{\GemmInnerDimension}{K} \newcommand{\GemmLeftOperand}{\mathbf{A}} \newcommand{\GemmLeftOperandElement}{A} \newcommand{\GemmLeftOperandEntry}{A_{ik}} \newcommand{\GemmOutputElement}{C} \newcommand{\GemmOutputEntry}{C_{ij}} \newcommand{\GemmOutputMatrix}{\mathbf{C}} \newcommand{\GemmProductScale}{\alpha} \newcommand{\GemmReductionIndex}{k} \newcommand{\GemmRightOperand}{\mathbf{B}} \newcommand{\GemmRightOperandElement}{B} \newcommand{\GemmRightOperandEntry}{B_{kj}} \newcommand{\GemmRowDimension}{M} \newcommand{\GemmTileColumnDimension}{N_{\text{tile}}} \newcommand{\GemmTileInnerDimension}{K_{\text{tile}}} \newcommand{\GemmTileRowDimension}{M_{\text{tile}}} \newcommand{\GemvArithmeticIntensity}{I_{\text{GEMV}}} \newcommand{\GeneralPurposeEnergyProductivity}{\rho_{\text{energy,general}}} \newcommand{\GeneralizedAccelerationLowerBound}{\ddot{\mathbf{q}}_{\min}} \newcommand{\GeneralizedAccelerationUpperBound}{\ddot{\mathbf{q}}_{\max}} \newcommand{\GeneralizedAccelerations}{\ddot{\mathbf{q}}} \newcommand{\GeneralizedBiasForces}{\mathbf{h}} \newcommand{\GeneralizedCoordinateCount}{n} \newcommand{\GeneralizedCoordinates}{\mathbf{q}} \newcommand{\GeneralizedInertiaMatrix}{\mathbf{M}} \newcommand{\GeneralizedParetoDistribution}{H} \newcommand{\GeneralizedParetoLikelihood}{L} \newcommand{\GeneralizedVelocities}{\dot{\mathbf{q}}} \newcommand{\GeneratedResponse}{y} \newcommand{\GeneratedSampleCount}{n} \newcommand{\GeneratedTokenCap}{N_{\text{cap}}} \newcommand{\GenerationStepErrorRate}{\lambda_{\text{error}}} \newcommand{\GenerativeActionModelDistribution}{p_\theta} \newcommand{\GeneratorLatentVector}{\mathbf{z}} \newcommand{\GenericRandomVariable}{X} \newcommand{\GeometricStateRepresentation}{\mathbf{Z}_{\text{geom}}} \newcommand{\GevLocationParameter}{\mu} \newcommand{\GevScaleParameter}{\sigma} \newcommand{\GlobalBatchGradient}{\mathbf{g}_{\text{global}}} \newcommand{\GlobalBatchSize}{B_{\text{global}}} \newcommand{\GlobalDeviationPenalty}{\mathcal{R}} \newcommand{\GlobalModelParameters}{\theta_{\text{global}}} \newcommand{\GoalConfiguration}{\mathbf{q}_{\text{goal}}} \newcommand{\GoalSet}{\mathcal{G}_{\text{goal}}} \newcommand{\GoodputRelativeTolerance}{\epsilon_{\mathcal{G}}} \newcommand{\GpdCumulativeDistribution}{F_{\text{GPD}}} \newcommand{\GpdScaleParameter}{\tilde{\sigma}} \newcommand{\GpuAvailability}{A_{\text{GPU}}} \newcommand{\GpuEnergy}{E_{\text{GPU}}} \newcommand{\GpuFailureRate}{\lambda_{\text{GPU}}} \newcommand{\GpuMttf}{\text{MTTF}_{\text{GPU}}} \newcommand{\GpuTopologicalDistance}{d} \newcommand{\GradientClippingNorm}{C} \newcommand{\GradientCovarianceMatrix}{\Sigma} \newcommand{\GradientElementCount}{d_{\text{grad}}} \newcommand{\GradientMemory}{M_{\text{gradients}}} \newcommand{\GradientPayload}{M_{\text{grad}}} \newcommand{\GradientStaleness}{\tau_{\text{stale}}} \newcommand{\GrantAllowedAccesses}{\mathcal{A}} \newcommand{\GrantCondition}{\phi_{\Gamma}} \newcommand{\GrantExpiryTime}{t_{\text{exp}}} \newcommand{\GrantIssueTime}{T} \newcommand{\GrantRights}{\mathcal{R}_{\Gamma}} \newcommand{\GraphEdgeSet}{E} \newcommand{\GraphNodeIndex}{i} \newcommand{\GraphNodeSet}{V} \newcommand{\GraspContactDisplacement}{\mathbf{d}} \newcommand{\GraspForceCeiling}{f_{\max}} \newcommand{\GraspForceFloor}{f_{\min}} \newcommand{\GraspMap}{\mathbf{G}} \newcommand{\GraspOrientation}{\mathbf{R}_{\text{grasp}}} \newcommand{\GraspPose}{\mathbf{T}_{\text{grasp}}} \newcommand{\GraspPosition}{\mathbf{p}_{\text{grasp}}} \newcommand{\GraspVerticalAcceleration}{a_z} \newcommand{\GravitationalTorqueVector}{\mathbf{g}} \newcommand{\Gravity}{g} \newcommand{\GravityCenterHeight}{h_{\text{cg}}} \newcommand{\GravityVector}{\mathbf{g}_0} \newcommand{\GridFeedCapacity}{P_{\text{grid}}} \newcommand{\GridSideCellCount}{N} \newcommand{\GripContactForce}{x} \newcommand{\GripperContactAngle}{\theta_{\text{contact}}} \newcommand{\GripperOpeningCommand}{a_{\text{gripper}}} \newcommand{\GroundPlaneAbscissa}{x} \newcommand{\GroundPlaneOrdinate}{y} \newcommand{\GroupCommitWaitTime}{L_{\text{lat}, i}} \newcommand{\GroupContrastProbability}{p_{\text{contrast}}} \newcommand{\GroupDisparity}{\Delta_g} \newcommand{\GroupMeanReward}{\mu_{R}} \newcommand{\GroupRelativeAdvantage}{\hat{A}} \newcommand{\GroupRewardStandardDeviation}{\sigma_{R}} \newcommand{\GroupRolloutIndex}{i} \newcommand{\GroupSize}{G} \newcommand{\GrpoSampledObjective}{\widehat{\mathcal{J}}_{\text{GRPO}}} \newcommand{\GuardBandDuration}{t_{\text{guard}}} \newcommand{\GuardedContactPredicate}{P_{\text{contact}}} \newcommand{\GuestImageMemory}{M_{\text{guest}}} \newcommand{\GuestKernelBootTime}{T_{\text{kernel}}} \newcommand{\HadamardRotationMatrix}{\mathbf{H}} \newcommand{\HalfPrecisionGemvIntensity}{I_{\text{GEMV, 16-bit}}} \newcommand{\HammingDataBitCount}{n} \newcommand{\HandForceCriterion}{F_h} \newcommand{\HandleAffordanceFrame}{\mathcal{F}_{\text{handle}}} \newcommand{\HandoffExceedanceProbability}{\epsilon} \newcommand{\HandoverTimeout}{T_{\text{timeout}}} \newcommand{\HandoverTimeoutCeiling}{T_{\text{config}}} \newcommand{\HandshakeProtocolLatency}{T_{\text{handshake}}} \newcommand{\HardwareCommonCauseRate}{\lambda_{\text{other}}} \newcommand{\HardwareParameterVector}{\boldsymbol{\xi}_{\text{real}}} \newcommand{\HardwareServiceLife}{T_{\text{lifetime}}} \newcommand{\HarmInclusiveTaskCost}{C_{\text{with\ harm}}} \newcommand{\HarmInstant}{t_{\text{harm}}} \newcommand{\HarmLeadTime}{t_{\text{harm}}} \newcommand{\HarmonicDriveTorsionalStiffness}{k_c} \newcommand{\HarmonicPeriodMultiple}{m} \newcommand{\HarnessConnectorResistance}{R_{\text{harness}}} \newcommand{\HashBucketCount}{N_{\text{buckets}}} \newcommand{\HashEntrySize}{s_{\text{entry}}} \newcommand{\HashRingServer}{s} \newcommand{\HashRingServerCount}{N} \newcommand{\HashRingServerSet}{\mathcal{S}_{\text{srv}}} \newcommand{\HashedGridMemory}{M_{\text{hashed}}} \newcommand{\HazardClassIndex}{h} \newcommand{\HazardOnset}{t_{\text{onset}}} \newcommand{\HazardOnsetBound}{t_{\text{bound}}} \newcommand{\HazardousProposalRate}{\lambda_{\text{proposal}, h}} \newcommand{\HazardousWorldState}{s_B} \newcommand{\HeadAxisLabel}{h} \newcommand{\HeadByteAllocation}{M_{\text{head}}} \newcommand{\HeadComponentIndex}{m} \newcommand{\HeadDimensionAxisLabel}{d} \newcommand{\HeadKeyProjectionMatrix}{\mathbf{W}_{K,i}} \newcommand{\HeadQueryProjectionMatrix}{\mathbf{W}_{Q,i}} \newcommand{\HeadSamplingProbability}{\theta} \newcommand{\HeadValuesProjectionMatrix}{\mathbf{W}_{V,i}} \newcommand{\HeadingAngle}{\theta_{\text{head}}} \newcommand{\HeadingCurvature}{\kappa} \newcommand{\HealthyStepTime}{T_{\text{healthy}}} \newcommand{\HeartbeatAge}{\Delta t_{\text{heartbeat}}} \newcommand{\HeartbeatInterval}{H} \newcommand{\HeartbeatReceiptTime}{t_{\text{local}}} \newcommand{\HeartbeatSequenceCounter}{k} \newcommand{\HeartbeatTimestamp}{t^{\text{hb}}} \newcommand{\HeatDissipationPower}{P_{\text{heat}}} \newcommand{\HermiteBasisFunction}{h} \newcommand{\HermiteInterpolationFraction}{\lambda} \newcommand{\HermiteSegmentProgress}{s} \newcommand{\HertzianContactCoefficient}{k_{c}} \newcommand{\HertzianContactStiffness}{k_H} \newcommand{\HiddenActivation}{\mathbf{h}} \newcommand{\HiddenActivationMatrix}{\mathbf{H}} \newcommand{\HiddenDimension}{d} \newcommand{\HiddenUnitOutput}{h} \newcommand{\HighOccupancyBinCount}{m} \newcommand{\HigherPriorityFrames}{hp} \newcommand{\HigherPriorityTasks}{hp} \newcommand{\HighestSignalFrequency}{f_{\max}} \newcommand{\HnswLayerIndex}{L} \newcommand{\HnswLevelDraw}{U} \newcommand{\HnswLevelNormalization}{m_\ell} \newcommand{\HnswMaximumConnectionCount}{M} \newcommand{\HnswSearchBeamWidth}{ef_{\text{search}}} \newcommand{\HoldingTorque}{\tau_{\text{hold}}} \newcommand{\HomogeneousCameraFramePoint}{\tilde{\mathbf{p}}_C} \newcommand{\HomogeneousPixelCoordinates}{\tilde{\mathbf{m}}} \newcommand{\HomogeneousPointCoordinates}{\tilde{\mathbf{p}}} \newcommand{\HomogeneousTransform}{\mathbf{T}_{AB}} \newcommand{\HomogeneousWorldFramePoint}{\tilde{\mathbf{p}}_W} \newcommand{\HomographyColumn}{\mathbf{h}} \newcommand{\HomographyColumnEntry}{h} \newcommand{\HomographyConstraintVector}{\mathbf{v}} \newcommand{\HomographyScaleFactor}{\lambda} \newcommand{\HomomorphicCiphertext}{c} \newcommand{\HomomorphicFunction}{f} \newcommand{\HomomorphicPublicKey}{pk} \newcommand{\HomomorphicSecretKey}{sk} \newcommand{\HorizonStepIndex}{k} \newcommand{\HorizontalFocalLength}{f_x} \newcommand{\HostArrivalTimestamp}{t_{\text{host}}} \newcommand{\HostHeartbeatRate}{f_{\text{heartbeat}}} \newcommand{\HostLinkBandwidth}{\text{BW}_{\text{link}}} \newcommand{\HostPower}{P_{\text{host}}} \newcommand{\HostPreparationTime}{T_{\text{prep}}} \newcommand{\HostRuntimeCount}{N_{\text{host}}} \newcommand{\HostSoftwareTime}{T_{\text{sw}}} \newcommand{\HostTransferBandwidth}{\text{BW}_{\text{host}}} \newcommand{\HotTierHitProbability}{h} \newcommand{\HotTierServiceTime}{T_{\text{hot}}} \newcommand{\HourlyAccountQueryCount}{q_{\text{hourly}}} \newcommand{\HourlyComponentFailureRate}{\lambda_{\text{hour}}} \newcommand{\HuberLossThreshold}{\delta} \newcommand{\HullQueryTime}{t_{\text{query}}} \newcommand{\HullSphereRadius}{r_{\text{hull}}} \newcommand{\HumanCommandRate}{\dot{\mathbf{u}}_{\text{human}}} \newcommand{\HumanControlCommand}{\mathbf{u}_{\text{human}}} \newcommand{\HumanFallbackCost}{C_{h}} \newcommand{\HumanReactionTime}{T_{\text{human}}} \newcommand{\HumanResolutionProbability}{h} \newcommand{\HumanReviewCost}{C_{\text{human}}} \newcommand{\HumanStandaloneSensitivity}{S_{\text{human}}} \newcommand{\HumanWalkingSpeedBound}{v_h} \newcommand{\HybridIterationTime}{T_{\text{step}}} \newcommand{\HydraulicSupplyPressure}{p} \newcommand{\HypothesisIndex}{h} \newcommand{\HypothesisTestFalseNegativeRate}{\beta_{\text{stat}}} \newcommand{\HypothesisTestSignificanceLevel}{\alpha_{\text{sig}}} \newcommand{\HypothesizedAcceptanceProbability}{p} \newcommand{\HypothesizedTrialFailureProbability}{p} \newcommand{\IdealAcceleratorTime}{T_{\text{ideal}}} \newcommand{\IdealMemoryQueueDelay}{t_{\text{queue,ideal}}} \newcommand{\IdempotentAlgebraElement}{x} \newcommand{\IdentityMatrix}{\mathbf{I}} \newcommand{\IllustrativeFunction}{f} \newcommand{\ImageChannelCount}{C} \newcommand{\ImageChannelIndex}{c} \newcommand{\ImageColumnIndex}{w} \newcommand{\ImageEpipole}{\mathbf{e}} \newcommand{\ImageHeight}{H} \newcommand{\ImagePlanePixelCoordinates}{\mathbf{u}_{\text{px}}} \newcommand{\ImageRowIndex}{h} \newcommand{\ImageTensorElement}{X} \newcommand{\ImageWidth}{W} \newcommand{\ImaginaryUnit}{j} \newcommand{\ImitationLearnedPolicy}{\hat{\pi}} \newcommand{\ImitationTargetCommand}{\mathbf{u}_{\text{target}}} \newcommand{\ImmediateTaskCostScore}{C} \newcommand{\ImpactInstant}{T} \newcommand{\ImpactRiseTime}{t_{\text{rise}}} \newcommand{\ImpactSpeed}{v_{\text{impact}}} \newcommand{\ImpedanceControlledPosition}{x} \newcommand{\ImpedanceControlledVelocity}{\dot{x}} \newcommand{\ImpedanceEquilibriumPosition}{x_{\text{des}}} \newcommand{\ImpedanceEquilibriumVelocity}{\dot{x}_{\text{des}}} \newcommand{\ImpedanceRestoringForce}{F} \newcommand{\ImplicitPolicyEnergyFunction}{E_\theta} \newcommand{\ImportanceProposalDistribution}{q} \newcommand{\ImportanceSampledFailureProbability}{\hat{p}_F} \newcommand{\ImuSampleTime}{t_{\text{IMU}}} \newcommand{\InContactViableSet}{\mathcal{C}_{\text{contact}}} \newcommand{\IncidenceAngle}{\theta_{\text{inc}}} \newcommand{\IncidentOpticalPower}{P_{\text{opt}}} \newcommand{\IncomingChannelCommand}{u_{\text{new}}} \newcommand{\IncomingCommandDerivative}{\dot{u}_{\text{new}}} \newcommand{\IncorrectCandidateTrialPassProbability}{p_{b}} \newcommand{\IncrementalSnapshotWriteVolume}{D_{\text{vol,delta}}} \newcommand{\IncumbentControlCommand}{\mathbf{u}^{\text{incumbent}}} \newcommand{\IncumbentInterventionRate}{\lambda_{\text{incumbent}}} \newcommand{\IncumbentTrackingErrorStandardDeviation}{\sigma_{\text{incumbent}}} \newcommand{\IndependentAttemptCount}{k} \newcommand{\IndependentEventProbability}{p} \newcommand{\IndependentSampleRate}{f} \newcommand{\IndexGraphNodeSet}{V} \newcommand{\IndexedDocumentCount}{N} \newcommand{\IndicatorFunction}{\mathbb{I}} \newcommand{\InducedGateVoltage}{V_{\text{gs,induced}}} \newcommand{\InductiveVoltage}{v} \newcommand{\InequalityConstraintFunction}{g} \newcommand{\InertiaMatchingRatio}{N^*} \newcommand{\InertiaMatrixDerivative}{\dot{\mathbf{M}}} \newcommand{\InertialIntegrationTime}{T} \newcommand{\InferenceActiveTime}{t_{\text{inference}}} \newcommand{\InferenceCost}{C_{\text{infer}}} \newcommand{\InferenceDutyCycle}{\alpha_{\text{duty}}} \newcommand{\InferenceEnergy}{E_{\text{inf}}} \newcommand{\InferenceLatency}{L_{\text{lat,infer}}} \newcommand{\InferenceLoadSocPower}{P_{\text{load}}} \newcommand{\InflatedHullRadius}{r_{\text{inflated}}} \newcommand{\InflightRolloutReservation}{M_{\text{inflight}}} \newcommand{\InfluenceFunction}{I} \newcommand{\InformationTechnologyEnergy}{E_{\text{IT}}} \newcommand{\InformationTechnologyHeatLoad}{\dot{Q}_{\text{IT}}} \newcommand{\InformationTechnologyPower}{P_{\text{IT}}} \newcommand{\InformativeTaskFraction}{p_{\text{inform}}} \newcommand{\IngestionPricePerSample}{C_{\text{ingest/sample}}} \newcommand{\InitialAccuracy}{\text{Accuracy}_0} \newcommand{\InitialBusVoltage}{V_{\text{initial}}} \newcommand{\InitialPositionStandardDeviation}{\sigma_{p,0}} \newcommand{\InitialPositionVelocityCovariance}{\sigma_{pv,0}} \newcommand{\InitialProposalDistribution}{q_{\boldsymbol{\psi}_0}} \newcommand{\InitialStateDistribution}{\rho_0} \newcommand{\InitialTrackingError}{e_0} \newcommand{\InitialVelocityStandardDeviation}{\sigma_{v,0}} \newcommand{\InitiatedTasks}{N} \newcommand{\InjectionBandwidth}{\text{BW}_{\text{inject}}} \newcommand{\InjectionTriggerEpoch}{t_{\text{inject}}} \newcommand{\InnerChainTransform}{\mathbf{T}_{BC}} \newcommand{\InnerLayerFunction}{g} \newcommand{\InnerProductLeftComponent}{a} \newcommand{\InnerProductLeftVector}{\mathbf{a}} \newcommand{\InnerProductRightComponent}{v} \newcommand{\InnerProductRightVector}{\mathbf{b}} \newcommand{\InnovationBias}{b} \newcommand{\InnovationCovariance}{\mathbf{S}} \newcommand{\InnovationVariance}{S} \newcommand{\InputCaptureTime}{T_{\text{capture}}} \newcommand{\InputChannelCount}{C_{\text{in}}} \newcommand{\InputChannelIndex}{c} \newcommand{\InputColumnLieDerivativeOperator}{L_{\mathbf{g}_j}} \newcommand{\InputConsumerAcceleratorCount}{N_{\text{GPU}}} \newcommand{\InputCoordinateCount}{d} \newcommand{\InputDistribution}{p(x)} \newcommand{\InputEventRate}{r_{\text{event}}} \newcommand{\InputFeatureIndex}{i} \newcommand{\InputFeatureVector}{\mathbf{x}} \newcommand{\InputLieDerivativeOperator}{L_{\mathbf{g}}} \newcommand{\InputNodePrimal}{v_{i-N}} \newcommand{\InputPipelineRate}{R_{\text{pipeline}}} \newcommand{\InputPipelineRatio}{r_{\text{pipe}}} \newcommand{\InputPipelineServiceRate}{r_{\text{pipeline}}} \newcommand{\InputPipelineStageIndex}{j} \newcommand{\InputQuantizationScale}{s_X} \newcommand{\InputResolution}{r} \newcommand{\InputStageServiceRate}{r} \newcommand{\InputTokenPrice}{c_{\text{in}}} \newcommand{\InputTokenSequence}{x_{1:S}} \newcommand{\InputVariableIndex}{m} \newcommand{\InsetAvailableBrakingDistance}{D_{\text{avail}}} \newcommand{\InstanceReplenishTime}{T_{\text{init}}} \newcommand{\InstantaneousPhaseCurrent}{i_{\text{phase}}} \newcommand{\InstantaneousRequestOccupancy}{Q} \newcommand{\IntegerWeightCode}{q} \newcommand{\IntegralControlEffort}{\mathbf{u}_{\text{int}}} \newcommand{\IntegralGainMatrix}{\mathbf{K}_{i}} \newcommand{\IntegratedPixelResponse}{I_{\text{pixel}}} \newcommand{\IntegrationCandidateCommitHash}{h_{\text{candidate}}} \newcommand{\IntegrationDummyTime}{t'} \newcommand{\IntegrationHeadCommitHash}{h_{\text{head}}} \newcommand{\IntegrationPoint}{\mathbf{y}} \newcommand{\IntegrationPointCoordinate}{y} \newcommand{\IntegrationTimeInstant}{s} \newcommand{\IntegratorState}{\mathbf{z}} \newcommand{\IntegratorStateRate}{\dot{\mathbf{z}}} \newcommand{\IntegratorUnwindDelay}{T_{\text{unwind}}} \newcommand{\IntegrityProvenance}{\iota} \newcommand{\IntegrityTrustLabel}{\iota} \newcommand{\IntentAcknowledgmentEvent}{e_{\text{flush}}} \newcommand{\IntentAdministrativeLease}{T_{\text{admin}}} \newcommand{\IntentDemonstrationDataset}{\mathcal{D}_{\text{intent}}} \newcommand{\IntentLease}{\mathcal{I}_{\text{intent}}} \newcommand{\IntentLeaseExpiry}{t_{\text{intent\_exp}}} \newcommand{\IntentProposalPeriod}{T_{\text{period}}} \newcommand{\InterAnnotatorAgreement}{\kappa} \newcommand{\InterFeedInterval}{T_{\text{feed}}} \newcommand{\InterGroupColumnDelay}{t_{\text{CCD\_S}}} \newcommand{\InterKernelGapTime}{T_{\text{gap}}} \newcommand{\InterNodeContextParallelDegree}{c_{\text{inter}}} \newcommand{\InterQueryIntervalDeviation}{\sigma_{\text{inter-query}}} \newcommand{\InterSensorClockSkew}{\Delta t_{\text{skew}}} \newcommand{\InteractionHistory}{h} \newcommand{\InteractionPortForce}{F} \newcommand{\InteractionPortVelocity}{v} \newcommand{\InterarrivalVariationCoefficient}{c_{a}} \newcommand{\InterfaceMaterialThermalResistance}{R_{\text{th,TIM}}} \newcommand{\InterferenceSlowdownFactor}{r_{\text{slow}}} \newcommand{\InterframeSpacingTime}{t_{\text{interframe},i}} \newcommand{\InterleavedPipelineBubbleFraction}{b_{\text{interleaved}}} \newcommand{\IntermediateTensorSize}{M_{\text{tensor}}} \newcommand{\InternalDissipationPower}{g} \newcommand{\IntervalCompletionTime}{T_{\text{total}}} \newcommand{\IntervalMean}{\bar{T}} \newcommand{\IntervalMeanOccupancy}{\bar{Q}} \newcommand{\IntervalNormalQuantile}{z} \newcommand{\IntervalStandardDeviation}{\sigma} \newcommand{\IntervalTransitionMatrix}{\boldsymbol{\Phi}} \newcommand{\IntervalVariationCoefficient}{c} \newcommand{\InterventionDensity}{D_{\text{int}}} \newcommand{\InterventionRate}{\lambda_{\text{int}}} \newcommand{\InterventionWindowDuration}{W} \newcommand{\IntraClusterCorrelation}{\rho_{\text{ICC}}} \newcommand{\IntraGroupColumnDelay}{t_{\text{CCD\_L}}} \newcommand{\IntraNodeContextParallelDegree}{c_{\text{intra}}} \newcommand{\IntrusionDistance}{C} \newcommand{\IntrusionDistanceAllowance}{C} \newcommand{\InvalidatedArtifactNode}{v} \newcommand{\InverseDepth}{\rho} \newcommand{\InverseDepthLandmarkParameters}{\mathbf{y}} \newcommand{\InverseKinematicsDamping}{\lambda} \newcommand{\InverseSensorLogOdds}{L_{\text{sensor}}} \newcommand{\InverterCurrentLimit}{I_{\max}} \newcommand{\InverterDeadTime}{t_{\text{dead}}} \newcommand{\IoTransferTime}{T_{\text{IO}}} \newcommand{\IronCaseThermalResistance}{R_{\text{th,iron-case}}} \newcommand{\IronLawComputeTime}{T_{\text{compute}}} \newcommand{\IronLawMemoryTime}{T_{\text{memory}}} \newcommand{\IronLossPower}{P_{\text{iron}}} \newcommand{\IronThermalCapacitance}{C_{\text{iron}}} \newcommand{\IrreducibleLoss}{C_{\mathcal{L}}} \newcommand{\IsolatedEnforcerExecutionTime}{t_{\text{iso}}} \newcommand{\IsolatedJobRunTime}{T} \newcommand{\IspProcessingTime}{t_{\text{ISP}}} \newcommand{\IsrExecutionTime}{t_{\text{ISR}}} \newcommand{\IterationCost}{C_{\text{iter}}} \newcommand{\IterationTokenBudget}{N_{\text{budget}}} \newcommand{\JaccardSimilarity}{J} \newcommand{\JacobianLeftSingularMatrix}{\mathbf{U}} \newcommand{\JacobianLeftSingularVector}{\mathbf{u}} \newcommand{\JacobianPseudoinverse}{\mathbf{J}^\dagger} \newcommand{\JacobianRightSingularMatrix}{\mathbf{V}} \newcommand{\JacobianRightSingularVector}{\mathbf{v}} \newcommand{\JacobianSingularNumber}{\sigma} \newcommand{\JacobianSingularNumberMatrix}{\boldsymbol{\Sigma}} \newcommand{\JawAperture}{w_{\text{aperture}}} \newcommand{\JensenShannonDivergence}{\mathcal{D}_{\text{JS}}} \newcommand{\JensenShannonMixtureDistribution}{\bar{P}} \newcommand{\JerkLimit}{j_{\max}} \newcommand{\JerkWeightMatrix}{\mathbf{W}_j} \newcommand{\JitterBufferPlayoutDelay}{T_{\text{buf}}} \newcommand{\JobAbsoluteDeadline}{d} \newcommand{\JobAvailability}{A_{\text{all}}} \newcommand{\JobDuration}{T_{\text{job}}} \newcommand{\JobIndex}{j} \newcommand{\JobQueueWaitTime}{W} \newcommand{\JobReleaseTime}{r} \newcommand{\JobRestartTime}{T_{\text{restart}}} \newcommand{\JobSlowdown}{S} \newcommand{\JobStartupTime}{T_{\text{startup}}} \newcommand{\JointAcceleration}{\ddot{q}} \newcommand{\JointAngle}{\theta_{\text{joint}}} \newcommand{\JointAngleLowerLimit}{q_{\min}} \newcommand{\JointAngleUpperLimit}{q_{\max}} \newcommand{\JointAngularAcceleration}{\dot{\omega}} \newcommand{\JointAngularRate}{\omega} \newcommand{\JointAngularSpeed}{\omega} \newcommand{\JointBaseInertiaCoupling}{\mathbf{M}_{jb}} \newcommand{\JointBiasTorque}{\tau_{\text{bias}}} \newcommand{\JointCoordinate}{q} \newcommand{\JointCount}{n} \newcommand{\JointFrictionTorque}{\tau_{\text{fric}}} \newcommand{\JointIndex}{i} \newcommand{\JointJerk}{j_{\text{joint}}} \newcommand{\JointLoadTorque}{\tau_{\text{load}}} \newcommand{\JointOutputImpedance}{Z_{\text{out}}} \newcommand{\JointOutputTorque}{\tau_{\text{out}}} \newcommand{\JointPathCurvature}{\mathbf{q}''} \newcommand{\JointPathTangent}{\mathbf{q}'} \newcommand{\JointPosition}{q} \newcommand{\JointPositionLowerLimit}{\mathbf{q}_{\min}} \newcommand{\JointPositionSetpoint}{\mathbf{q}^*} \newcommand{\JointPositionTarget}{q_{\text{des}}} \newcommand{\JointPositionUpperLimit}{\mathbf{q}_{\max}} \newcommand{\JointReflectedRotorInertia}{J_{m}} \newcommand{\JointSampleTimestamp}{t_{\text{joint}}} \newcommand{\JointTorque}{\boldsymbol{\tau}} \newcommand{\JointTorqueConstant}{K_t} \newcommand{\JointTorqueLimit}{\tau_{\max}} \newcommand{\JointTorqueLimits}{\boldsymbol{\tau}_{\max}} \newcommand{\JointTorqueLowerLimit}{\boldsymbol{\tau}_{\min}} \newcommand{\JointTorqueSlew}{\dot{\boldsymbol{\tau}}} \newcommand{\JointTorqueSlewLimit}{\dot{\boldsymbol{\tau}}_{\max}} \newcommand{\JointTorqueTarget}{\tau_{\text{des}}} \newcommand{\JointTorqueUpperLimit}{\boldsymbol{\tau}_{\max}} \newcommand{\JointTorsionalStiffnessMatrix}{\mathbf{K}} \newcommand{\JointTrackingError}{\mathbf{e}} \newcommand{\JointVelocity}{\dot{q}} \newcommand{\JointVelocityCeiling}{\dot{q}_{\max}} \newcommand{\JointVelocityLimit}{\dot{\mathbf{q}}_{\max}} \newcommand{\JointVelocitySetpoint}{\dot{\mathbf{q}}^*} \newcommand{\JointVelocityTarget}{\dot{q}_{\text{des}}} \newcommand{\JouleanTemperatureRise}{\Delta T} \newcommand{\JunctionAmbientThermalResistance}{R_{\text{th,JA}}} \newcommand{\JunctionCaseThermalResistance}{R_{\text{th,JC}}} \newcommand{\JunctionTemperature}{T_{\text{j}}} \newcommand{\KalmanBucyObserverGain}{\mathbf{L}} \newcommand{\KalmanGain}{\mathbf{G}} \newcommand{\KeepContextPathCost}{C_{\text{keep}}} \newcommand{\KendallMarkovianCode}{M} \newcommand{\KernelActiveTime}{T_{\text{compute}}} \newcommand{\KernelColumnOffset}{n} \newcommand{\KernelExecutionTime}{T_{\text{kernel}}} \newcommand{\KernelHeight}{K_h} \newcommand{\KernelHorizontalLoopOffset}{k_{x}} \newcommand{\KernelRowOffset}{m} \newcommand{\KernelSize}{K} \newcommand{\KernelVerticalLoopOffset}{k_{y}} \newcommand{\KernelWeight}{W} \newcommand{\KernelWidth}{K_w} \newcommand{\KeyAxisLabel}{j} \newcommand{\KeyBufferPosition}{j} \newcommand{\KeyComponent}{k_{jm}} \newcommand{\KeyLeftSingularMatrix}{\mathbf{U}} \newcommand{\KeyLeftSingularVector}{\mathbf{u}} \newcommand{\KeyProjectionMatrix}{\mathbf{W}_{K}} \newcommand{\KeyRightSingularMatrix}{\mathbf{V}} \newcommand{\KeyRightSingularVector}{\mathbf{v}} \newcommand{\KeySingularNumber}{\sigma} \newcommand{\KeySingularSpectrumMatrix}{\mathbf{\Sigma}} \newcommand{\KeySourceMatrix}{\mathbf{X}_{K}} \newcommand{\KeySpectrumLength}{q} \newcommand{\KeyVector}{\mathbf{k}} \newcommand{\KineticEnergy}{E_k} \newcommand{\KineticEnergyCeiling}{E_{\max}} \newcommand{\KineticInsetBarrierFunction}{h_{\text{kinetic}}} \newcommand{\KineticInsetBarrierRate}{\dot{h}_{\text{kinetic}}} \newcommand{\KlDivergence}{\mathcal{D}_{\text{KL}}} \newcommand{\KlPenaltyCoefficient}{\beta_{\text{KL}}} \newcommand{\KlSampleStatistic}{d} \newcommand{\KnownComponentStopDistance}{d_{\text{budget}}} \newcommand{\KolmogorovSmirnovCriticalThreshold}{c_{\text{crit}}} \newcommand{\KolmogorovSmirnovStatistic}{\mathcal{D}_{\text{KS}}} \newcommand{\KroneckerIndicator}{\delta} \newcommand{\KrumClientCount}{n} \newcommand{\KrylovSubspace}{\mathcal{K}} \newcommand{\KsCriticalCoefficient}{c} \newcommand{\KvBlockSize}{S_{\text{blk}}} \newcommand{\KvBlockTailWaste}{\Delta_{\text{tail}}} \newcommand{\KvCacheBytesPerToken}{m_{\text{token}}} \newcommand{\KvCacheHandoffTime}{T_{\text{handoff}}} \newcommand{\KvCacheMemory}{M_{\text{KV}}} \newcommand{\KvElementStorageSize}{s_{\text{elem,KV}}} \newcommand{\KvHeadCount}{H_{\text{KV}}} \newcommand{\KvPoolHeadroomFraction}{f_{\text{head}}} \newcommand{\KvPoolMemory}{M_{\text{pool}}} \newcommand{\KvRecomputeTime}{T_{\text{recompute}}} \newcommand{\KvReloadTime}{T_{\text{reload}}} \newcommand{\KvTileCount}{T_c} \newcommand{\KvTileIndex}{j} \newcommand{\KvTileSize}{B_c} \newcommand{\LaSalleInvariantSet}{\Omega} \newcommand{\LabelCategoryIndex}{i} \newcommand{\LabelVector}{\mathbf{y}} \newcommand{\LabeledRecord}{x} \newcommand{\LabeledSampleCount}{D_{\text{labeled}}} \newcommand{\LabelingRoundIndex}{k} \newcommand{\LaggedModelInput}{x_{t-\Delta}} \newcommand{\LaggedStateDigest}{h_{\text{state},t-k}} \newcommand{\LandmarkDepth}{d} \newcommand{\LanguageInstruction}{c_{\text{instr}}} \newcommand{\LanguageSkillPrior}{p_{\text{LLM}}} \newcommand{\LaplaceLikelihoodScale}{b} \newcommand{\LaplaceNoiseSample}{x} \newcommand{\LaplaceNoiseScale}{b} \newcommand{\LaplaceVariable}{s} \newcommand{\LargestDrivenWheelLoadShare}{\varphi} \newcommand{\LargestEigenvalue}{\lambda_{\max}} \newcommand{\LargestInvariantSet}{\mathcal{M}} \newcommand{\LargestSingularNumber}{\sigma_{\max}} \newcommand{\LarsGlobalLearningRate}{\eta_{\text{global}}} \newcommand{\LastCandidateEmbeddingVector}{\mathbf{x}_N} \newcommand{\LastFunctionInputComponent}{x_N} \newcommand{\LastMeasurementTime}{t_{\text{last}}} \newcommand{\LastRankComputeTime}{T_{\text{rank}_{N-1}}} \newcommand{\LatchApproachSpeed}{v_{\text{latch}}} \newcommand{\LatchClearance}{c} \newcommand{\LatchContactForce}{f} \newcommand{\LatchForceLimit}{F_{\text{lim}}} \newcommand{\LatchPlateStiffness}{k_{\text{latch}}} \newcommand{\LatchStallForce}{F} \newcommand{\LatchStrengthFloor}{F_{\text{floor}}} \newcommand{\LateHandoffProbability}{p} \newcommand{\Latency}{L_{\text{lat}}} \newcommand{\LatencyBandwidthCrossoverSize}{n^*} \newcommand{\LatencyBoundedBatchSize}{B_{\text{SLO}}} \newcommand{\LatencyObjective}{S_{\text{latency}}} \newcommand{\LatencyQuantileFunction}{Q_p} \newcommand{\LatencyRewardExponent}{\beta_{\text{lat}}} \newcommand{\LatencySlo}{L_{\text{lat,SLO}}} \newcommand{\LatentActionComponent}{u} \newcommand{\LatentComponentMean}{\mu_{\phi, j}} \newcommand{\LatentComponentStandardDeviation}{\sigma_{\phi, j}} \newcommand{\LatentDimension}{d_z} \newcommand{\LatentGaussianPolicyDensity}{\mu} \newcommand{\LatentKlWeight}{\beta} \newcommand{\LatentPosteriorDistribution}{q} \newcommand{\LatentPosteriorMean}{\boldsymbol{\mu}_\phi} \newcommand{\LatentPosteriorStandardDeviation}{\boldsymbol{\sigma}_\phi} \newcommand{\LatentStateEncoder}{q_\phi} \newcommand{\LatentStyleVariable}{\mathbf{z}} \newcommand{\LatentVariableSpace}{\mathcal{Z}} \newcommand{\LaterBaseFlangeTransform}{\mathbf{T}_{\text{base}, k+1}^{\text{flange}}} \newcommand{\LaterCameraTargetTransform}{\mathbf{T}_{\text{cam}, k+1}^{\text{target}}} \newcommand{\LaterRolloutTurnIndex}{j} \newcommand{\LaterStepIndex}{j} \newcommand{\LateralClearance}{W_{\text{clear}}} \newcommand{\LatestSequentialObservation}{X_m} \newcommand{\LayerAllReduceTime}{T_{\text{layer comm}}} \newcommand{\LayerBackwardTime}{T_{\text{layer backward}}} \newcommand{\LayerCount}{N_L} \newcommand{\LayerExposedCommunicationTime}{T_{\text{exposed}}} \newcommand{\LayerFunction}{f} \newcommand{\LayerIndex}{\ell} \newcommand{\LayerInputComponent}{x} \newcommand{\LayerInputMatrix}{\mathbf{X}} \newcommand{\LayerInputVector}{\mathbf{x}} \newcommand{\LayerInputWidth}{d_{\text{in}}} \newcommand{\LayerIntermediateStateMemory}{s_{\ell}} \newcommand{\LayerNonlinearity}{\phi} \newcommand{\LayerNormMean}{\mu_{\text{LN}}} \newcommand{\LayerNormStandardDeviation}{\sigma_{\text{LN}}} \newcommand{\LayerOutputMatrix}{\mathbf{Y}} \newcommand{\LayerOutputVector}{\mathbf{y}} \newcommand{\LayerOutputWidth}{d_{\text{out}}} \newcommand{\LayerParameterPayload}{M_{\text{layer}}} \newcommand{\LayerSavedTensorCount}{n_{\text{saved}}} \newcommand{\LayerSelectionIndex}{i} \newcommand{\LayerWeightEntry}{W} \newcommand{\LayerWeights}{\mathbf{w}} \newcommand{\LayerWidth}{n} \newcommand{\LcResonantFrequency}{f_0} \newcommand{\LeaderForwardWave}{\mathbf{u}_m} \newcommand{\LeaderJointPositions}{\mathbf{q}_{\text{leader}}} \newcommand{\LeaderPortEffort}{\mathbf{F}_m} \newcommand{\LeaderPortFlow}{\dot{\mathbf{x}}_m} \newcommand{\LeaderPortPower}{P_m} \newcommand{\LeaderReturnWave}{\mathbf{w}_m} \newcommand{\LeaderWristRollAngle}{\theta_{\text{roll}}} \newcommand{\LeadingSupportDistance}{d_{\text{lead}}} \newcommand{\LeakageCurrent}{I_{\text{leak}}} \newcommand{\LeakagePower}{P_{\text{leakage}}} \newcommand{\LearnedActionProposal}{\hat{\mathbf{a}}_{\text{learned}}} \newcommand{\LearnedNominalTrajectory}{\hat{\mathbf{q}}_{\text{learned}}} \newcommand{\LearnedRemainingReturnEstimate}{\widehat{V}} \newcommand{\LearnedVelocityField}{v_\theta} \newcommand{\LearnerStateDisagreementRate}{\epsilon_\pi} \newcommand{\LearnerStateVisitationDistribution}{p^{\pi}} \newcommand{\LearningCurveSampleCount}{n} \newcommand{\LearningRate}{\eta} \newcommand{\LeaseAdmissionInstant}{t_{\text{adm}}} \newcommand{\LeaseDirtyMemory}{M_{\text{dirty}}} \newcommand{\LeaseExpiryDelaySubtotal}{\tau_{\text{delay,sub}}} \newcommand{\LeaseHoldTime}{T_{\text{hold}}} \newcommand{\LeasePathTravel}{d_{\text{lease}}} \newcommand{\LeaseRefreshInstant}{t_{\text{refresh}}} \newcommand{\LeftEvasionAction}{\mathbf{a}_{\text{left}}} \newcommand{\LeftSingularVectorMatrix}{\mathbf{P}} \newcommand{\LengthPenaltyWeight}{\lambda_{\text{len}}} \newcommand{\LeverArmLength}{r_{\text{arm}}} \newcommand{\LeverArmSweepError}{e_{\text{rot}}} \newcommand{\LewisFormFactor}{Y} \newcommand{\LexicalDocument}{x} \newcommand{\LexicalFrequencySaturation}{k_1} \newcommand{\LexicalLengthNormalization}{b} \newcommand{\LexicalQuery}{Q} \newcommand{\LidarAzimuthAngle}{\theta_{\text{az}}} \newcommand{\LidarBeamDirection}{\mathbf{d}} \newcommand{\LidarElevationAngle}{\phi} \newcommand{\LidarFramePoint}{\mathbf{p}_{\text{lidar}}} \newcommand{\LidarReferenceFrame}{\mathcal{F}_{\text{lidar}}} \newcommand{\LidarScanRate}{f_{\text{scan}}} \newcommand{\LidarSweepPeriod}{T_{\text{sweep}}} \newcommand{\LidarSweepStartTime}{t_{\text{sweep}}} \newcommand{\LieDerivativeAlongControl}{L_{\mathbf{g}} h} \newcommand{\LieDerivativeAlongDrift}{L_{\mathbf{f}} h} \newcommand{\LieDerivativeOrder}{k} \newcommand{\LikelihoodRatioWeight}{w} \newcommand{\LimitMarginFunction}{M} \newcommand{\LinearAcceleration}{\mathbf{a}} \newcommand{\LinearBarrierDecayRate}{\gamma_{\text{cbf}}} \newcommand{\LinearMomentum}{p} \newcommand{\LinearizedVirtualInput}{\mathbf{v}} \newcommand{\LinkAngularAcceleration}{\ddot{\theta}_{\text{link}}} \newcommand{\LinkBandwidth}{\beta} \newcommand{\LinkBitRate}{R_{\text{link}}} \newcommand{\LinkLength}{l} \newcommand{\LinkOutputPosition}{q_{\text{out}}} \newcommand{\LintFalseAcceptFraction}{\phi} \newcommand{\LipschitzConstant}{K} \newcommand{\LiveAutomatonStateSet}{Q_{\text{live}}} \newcommand{\LoadCurrent}{I_{\text{load}}} \newcommand{\LoadInertia}{J_{\text{load}}} \newcommand{\LoadStepCurrentDeficit}{\Delta I_{\text{step}}} \newcommand{\LoadStepDeficitDuration}{\Delta t_{\text{step}}} \newcommand{\LoadedEnforcerExecutionTime}{t_{\text{enf}}} \newcommand{\LoadedJunctionTemperature}{T_{\text{load}}} \newcommand{\LocalBatchSize}{B_{\text{local}}} \newcommand{\LocalEpochCount}{E} \newcommand{\LocalGradient}{\mathbf{g}} \newcommand{\LocalInferenceEnergy}{E_{\text{local}}} \newcommand{\LocalPathTime}{T_{\text{local}}} \newcommand{\LocalRankIndex}{i} \newcommand{\LocalTokenCount}{B_{\text{tok}}} \newcommand{\LocalUpdateCount}{H_{\text{local}}} \newcommand{\LocalityPenaltyFunction}{w} \newcommand{\LocalizationBound}{\delta_{\text{loc}}} \newcommand{\LogFailureRatio}{s_{\text{fail}}} \newcommand{\LogOddsLowerClamp}{L_{\min}} \newcommand{\LogOddsUpperClamp}{L_{\max}} \newcommand{\LogPositionIndex}{j} \newcommand{\LoggedEvent}{e} \newcommand{\LoggedEventPrefix}{\mathbf{e}_{1:j}} \newcommand{\LoggpLongMessageTime}{T_{\text{long}}} \newcommand{\LogisticProbability}{p_{\text{sig}}} \newcommand{\LogitMask}{\mathbf{M}} \newcommand{\LogitMaskEntry}{M} \newcommand{\LogitStorageSize}{s_{\text{logit}}} \newcommand{\LogitVector}{\mathbf{z}} \newcommand{\LogpNetworkLatency}{L_{\text{LogGP}}} \newcommand{\LonePassAdvantage}{\hat{A}_{\text{pass}}} \newcommand{\LongMessageGapPerByte}{G} \newcommand{\LongestInterruptMaskTime}{t_{\text{irq\_disabled,max}}} \newcommand{\LongitudinalFrictionCoefficient}{\mu_x} \newcommand{\LongitudinalSlipRatio}{\lambda} \newcommand{\LongitudinalTractionStiffness}{C_x} \newcommand{\LongitudinalVehicleSpeed}{v_x} \newcommand{\LookaheadStepIndex}{l} \newcommand{\LoopAcceptanceProbability}{p_{\text{loop}}} \newcommand{\LoopGainScalingFactor}{\kappa} \newcommand{\LoopNestDepth}{n_{\text{loops}}} \newcommand{\LoopOrderCount}{N_{\text{order}}} \newcommand{\LoopParallelizationChoiceCount}{\mathcal{P}_{\text{parallel}}} \newcommand{\LoopTurnCost}{C} \newcommand{\Loss}{L} \newcommand{\LossAdjointSeed}{\bar{\mathcal{L}}} \newcommand{\LossFunction}{\mathcal{L}} \newcommand{\LossGradient}{g} \newcommand{\LossGradientVector}{\mathbf{g}} \newcommand{\LossHessian}{\mathbf{H}} \newcommand{\LossLowerBound}{\mathcal{L}_{\inf}} \newcommand{\LossScaleFactor}{s_{\text{loss}}} \newcommand{\LossTimeDerivative}{\dot{\mathcal{L}}} \newcommand{\LostMotionDeflection}{\delta_{\text{lost}}} \newcommand{\LostSuffixTurnCount}{H_{\text{suffix},i}} \newcommand{\LostWorkReplayTime}{T_{\text{replay}}} \newcommand{\LotSamplingProbability}{q} \newcommand{\LowRankLeftFactor}{\mathbf{U}} \newcommand{\LowRankRightFactor}{\mathbf{V}} \newcommand{\LowerPriorityFrames}{lp} \newcommand{\LowerPriorityTasks}{lp} \newcommand{\LowerRatioClippingWidth}{\epsilon_{\text{low}}} \newcommand{\LqrControlWeightMatrix}{\mathbf{R}_u} \newcommand{\LqrCostToGoMatrix}{\mathbf{P}} \newcommand{\LqrFeedbackGain}{\mathbf{K}_{\text{lqr}}} \newcommand{\LqrQuadraticObjective}{J} \newcommand{\LqrStateWeightMatrix}{\mathbf{Q}_x} \newcommand{\LshBandCount}{L} \newcommand{\LshCandidateProbability}{p_{\text{candidate}}} \newcommand{\LshRowsPerBand}{r} \newcommand{\LyapunovAnalysisDomain}{\mathcal{D}} \newcommand{\LyapunovFunction}{V} \newcommand{\LyapunovFunctionDerivative}{\dot{V}} \newcommand{\LyapunovPositivityMargin}{\epsilon_{\text{pos}}} \newcommand{\LyapunovSublevelSet}{\Omega_c} \newcommand{\MacAccumulator}{\text{acc}} \newcommand{\MachineTaxonomyAxis}{\mathsf{Machine}} \newcommand{\MahalanobisDistance}{d_M} \newcommand{\ManifestTrackIndex}{k} \newcommand{\ManipulatorBaseFrame}{\mathcal{F}_{\text{base}}} \newcommand{\ManipulatorJacobian}{\mathbf{J}} \newcommand{\ManualLease}{T_{\text{lease,man}}} \newcommand{\ManualResetTime}{t_{\text{reset,manual}}} \newcommand{\ManualReviewCost}{C_{\text{manual}}} \newcommand{\ManualReviewFraction}{r_{\text{manual}}} \newcommand{\MapCovarianceJacobian}{\mathbf{J}_{\text{map}}} \newcommand{\MapOdometryTransform}{\mathbf{T}_{\text{map}}^{\text{odom}}} \newcommand{\MapParameterEstimate}{\theta_{\text{MAP}}} \newcommand{\MapPoseCovariance}{\boldsymbol{\Sigma}_{\text{map}}} \newcommand{\MapReferenceFrame}{\mathcal{F}_{\text{map}}} \newcommand{\MappedCommandTap}{a_{\text{cmd}}} \newcommand{\MappingSearchSpaceSize}{\mathcal{S}_{\text{mapping}}} \newcommand{\MarginalFalseApprovalProbability}{p} \newcommand{\MarginalRequestServiceTime}{t_{\text{req}}} \newcommand{\MarginalStoppingThreshold}{\epsilon_{\text{stop}}} \newcommand{\MarginalVelocityField}{u} \newcommand{\MarginalizedModelParameters}{\theta'} \newcommand{\MarkovDecisionProcess}{\mathcal{M}} \newcommand{\MaskTokenIndex}{i} \newcommand{\MaskedClientUpdate}{\mathbf{y}} \newcommand{\MaskedFinetuningLoss}{\mathcal{L}_{\text{SFT}}} \newcommand{\MaskedImitationDataset}{\mathcal{D}_{\text{train}}} \newcommand{\MaskedImitationLoss}{\mathcal{L}_{\text{imitation}}} \newcommand{\MaskedLogitVector}{\mathbf{z}'} \newcommand{\MaskedTokenLogit}{z'} \newcommand{\Mass}{m} \newcommand{\MassCenterAcceleration}{\ddot{\mathbf{c}}} \newcommand{\MassCenterHeight}{z_c} \newcommand{\MassCenterPosition}{\mathbf{c}} \newcommand{\MasterProcessingTime}{t_{\text{master}}} \newcommand{\MatchingRowCount}{K} \newcommand{\MatrixColumnIndex}{j} \newcommand{\MatrixEigenvalue}{\lambda} \newcommand{\MatrixMultiplyDestination}{\mathbf{D}} \newcommand{\MatrixRowIndex}{i} \newcommand{\MaxBatchSize}{B_{\text{max}}} \newcommand{\MaxBatchingWindow}{T_{\text{max}}} \newcommand{\MaxReceivedTokenCount}{B_{\text{max}}} \newcommand{\MaxResidentContextCount}{B_{\max}} \newcommand{\MaximumActuatorEffort}{u_{\max}} \newcommand{\MaximumBreakerCooldownInterval}{T_{\text{cool}}^{\max}} \newcommand{\MaximumCompletionOffset}{c_{\max}} \newcommand{\MaximumDepthHypothesis}{d_{\max}} \newcommand{\MaximumEntropyObjective}{J} \newcommand{\MaximumLoadCurrentStep}{\Delta I_{\max}} \newcommand{\MaximumLogit}{z_{\max}} \newcommand{\MaximumObservationAge}{t_{\text{age},\max}} \newcommand{\MaximumPlateIndentation}{x_{\max}} \newcommand{\MaximumRetryBackoffInterval}{b_{\max}} \newcommand{\MaximumTurnOffDelay}{t_{\text{off, max}}} \newcommand{\McnemarTestStatistic}{\chi^2} \newcommand{\McuCaptureTime}{t_{\text{MCU,capture}}} \newcommand{\McuDispatchTime}{t_{\text{MCU,dispatch}}} \newcommand{\MealTokenKeyVector}{\mathbf{k}_{\text{meal}}} \newcommand{\MealTokenQueryVector}{\mathbf{q}_{\text{meal}}} \newcommand{\MeanAcceptedDraftLength}{\bar{m}} \newcommand{\MeanAttemptCost}{c} \newcommand{\MeanClusterSize}{m} \newcommand{\MeanContextLength}{\bar{S}} \newcommand{\MeanDeliveryPayloadLength}{L} \newcommand{\MeanDocumentLength}{\overline{|x|}} \newcommand{\MeanHoldTime}{\bar{T}_{\text{hold}}} \newcommand{\MeanLatchContactForce}{\bar{F}} \newcommand{\MeanMessageQueueDelay}{\bar{T}_q} \newcommand{\MeanNeesStatistic}{\bar{\epsilon}} \newcommand{\MeanQueryDistance}{\mu_D} \newcommand{\MeanRolloutLength}{\bar{N}} \newcommand{\MeanSlotOccupancy}{\bar{N}_{\text{slot}}} \newcommand{\MeanSquaredErrorCloningLoss}{\mathcal{L}_{\text{MSE}}} \newcommand{\MeanStoredTokensPerRecord}{\bar{S}} \newcommand{\MeanTargetTokensPerRecord}{\bar{w}} \newcommand{\MeanTimeBetweenFailures}{\text{MTBF}} \newcommand{\MeanTimeToFailure}{\text{MTTF}} \newcommand{\MeanTimeToRepair}{\text{MTTR}} \newcommand{\MeanVerifierServiceTime}{\bar{T}_{\text{svc}}} \newcommand{\MeasuredAxisPosition}{x_{\text{meas}}} \newcommand{\MeasuredContactForce}{\mathbf{F}_{\text{contact}}} \newcommand{\MeasuredJointVelocities}{\dot{\mathbf{q}}_{\text{meas}}} \newcommand{\MeasuredPixelDepth}{Z_{\text{meas}}} \newcommand{\MeasuredResponseTap}{a_{\text{meas}}} \newcommand{\MeasuredSeamAccelerations}{\ddot{\mathbf{q}}_{\text{meas}}} \newcommand{\MeasuredSeamConfiguration}{\mathbf{q}_{\text{meas}}} \newcommand{\MeasuredSeamVelocities}{\dot{\mathbf{q}}_{\text{meas}}} \newcommand{\MeasuredTrackedPosition}{\mathbf{p}_{\text{meas}}} \newcommand{\MeasurementCovariance}{\boldsymbol{\Sigma}_z} \newcommand{\MeasurementDimension}{m} \newcommand{\MeasurementErrorStandardDeviation}{\sigma} \newcommand{\MeasurementFunction}{h} \newcommand{\MeasurementHistory}{\mathbf{y}_{1:k}} \newcommand{\MeasurementInnovation}{\boldsymbol{\nu}} \newcommand{\MeasurementMatrix}{\mathbf{H}} \newcommand{\MeasurementNoiseCovariance}{\boldsymbol{\Sigma}_{\text{meas}}} \newcommand{\MeasurementNoiseVector}{\mathbf{v}_{\text{meas}}} \newcommand{\MeasurementVector}{\mathbf{y}} \newcommand{\MeasurementVectorDerivative}{\dot{\mathbf{y}}} \newcommand{\MeasurementWindowEnd}{t_{\text{end}}} \newcommand{\MechanicalEnergy}{E} \newcommand{\MechanicalEnergyDerivative}{\dot{E}} \newcommand{\MechanicalImpedanceMap}{Z} \newcommand{\MechanicalPlantState}{\mathbf{x}} \newcommand{\MechanicalWork}{W} \newcommand{\MechanismAcceptanceProbability}{p'_{\text{acc}}} \newcommand{\MechanismAttemptCost}{C'_{\text{attempt}}} \newcommand{\MechanismLogMoment}{\alpha_{\mathcal{M}}} \newcommand{\MechanismOutcome}{o} \newcommand{\MechanismOutputSet}{\mathcal{S}} \newcommand{\MechanismOutputVector}{\mathbf{y}} \newcommand{\MechanismRenyiPrivacyBudget}{\epsilon_{\text{R},i}} \newcommand{\MemoryBusQueueDelay}{t_{\text{queue}}} \newcommand{\MemoryEntryBirthGeneration}{g_{\text{birth}}} \newcommand{\MemoryEntryDeathGeneration}{g_{\text{death}}} \newcommand{\MemoryHierarchyLevelCount}{N_{\text{mem}}} \newcommand{\MemoryHoldDuringWait}{O_{\text{mem}}} \newcommand{\MemoryPlacementCount}{\mathcal{M}_{\text{placement}}} \newcommand{\MemorySubsystemEnergy}{E_{\text{memory}}} \newcommand{\MergedAttentionOutput}{\mathbf{O}^{\text{new}}} \newcommand{\MergedSoftmaxMaximum}{m^{\text{new}}} \newcommand{\MergedSoftmaxNormalizer}{z^{\text{new}}} \newcommand{\MergedWeightMatrix}{\mathbf{W}_{\text{final}}} \newcommand{\MessageInjectionGap}{g} \newcommand{\MessageQueueDelay}{T_q} \newcommand{\MessageStartupLatency}{\alpha} \newcommand{\MessageTimestamp}{t_{\text{msg}}} \newcommand{\MetricDepth}{z_{\text{metric}}} \newcommand{\MicroUnitPrefix}{\text{µ}} \newcommand{\MicrobatchCount}{m} \newcommand{\MicrobatchGradient}{\mathbf{g}} \newcommand{\MicrobatchIndex}{j} \newcommand{\MicrobatchPassTime}{T_{\text{micro},j}} \newcommand{\MicrobatchSize}{B_{\text{micro}}} \newcommand{\MicrocontrollerClockTime}{t_{\text{MCU}}} \newcommand{\MillerCapacitance}{C_{\text{gd}}} \newcommand{\MillerCharge}{Q_{\text{gd}}} \newcommand{\MillerDisplacementCurrent}{I_{\text{miller}}} \newcommand{\MillerPlateauDuration}{t_{\text{plateau}}} \newcommand{\MillerPlateauVoltage}{V_{\text{plateau}}} \newcommand{\MinHashPermutation}{\sigma} \newcommand{\MinHashPermutationCount}{n_{\sigma}} \newcommand{\MinHashSketchSize}{s} \newcommand{\MiniBatchActivation}{a} \newcommand{\MiniBatchSet}{\mathcal{B}} \newcommand{\MinibatchGradient}{\mathbf{g}} \newcommand{\MinimumActuatorEffort}{u_{\min}} \newcommand{\MinimumCellSupportCount}{N_{\min}} \newcommand{\MinimumChunkSetpointCount}{h_{\min}} \newcommand{\MinimumCompletionOffset}{c_{\min}} \newcommand{\MinimumDepthHypothesis}{d_{\min}} \newcommand{\MinimumDetectableEffect}{\delta_{\text{MDE}}} \newcommand{\MinimumPrefetchBufferCount}{Q_{\text{prefetch,min}}} \newcommand{\MinimumRailVoltage}{V_{\text{rail,min}}} \newcommand{\MinimumRoundTripLatency}{L_{\text{lat,min}}} \newcommand{\MinimumStableBatchSize}{B_{\text{min}}} \newcommand{\MinimumTransitTime}{t_{\min}} \newcommand{\MinimumTurnOnDelay}{t_{\text{on, min}}} \newcommand{\MisclassifiedFraction}{r_{\text{error}}} \newcommand{\MisroutedQueryFraction}{m} \newcommand{\MissAcceptanceProbability}{\alpha} \newcommand{\MissPathServiceTime}{T_{\text{cold}}} \newcommand{\MissionDuration}{T_{\text{mission}}} \newcommand{\MissionEnergy}{E_{\text{mission}}} \newcommand{\MissionExceedanceBudget}{\epsilon_{\text{mission}}} \newcommand{\MissionHandoffCount}{K} \newcommand{\MixtureComponentCount}{M} \newcommand{\MixtureComponentCovariance}{\boldsymbol{\Sigma}_m} \newcommand{\MixtureComponentIndex}{m} \newcommand{\MixtureComponentMean}{\boldsymbol{\mu}_m} \newcommand{\MixtureComponentWeight}{w_m} \newcommand{\MixupSample}{\tilde{x}} \newcommand{\MixupWeight}{\lambda_{\text{mix}}} \newcommand{\MlProductivityGoodput}{\text{MPG}} \newcommand{\MlpWeightArithmeticIntensity}{I_{\text{MLP}}} \newcommand{\MobileBaseBarrierFunction}{h_{\text{base}}} \newcommand{\MobilenetWidthMultiplier}{\alpha_{\text{width}}} \newcommand{\ModelBandwidthUtilization}{\text{MBU}} \newcommand{\ModelCallIndex}{i} \newcommand{\ModelCallRequest}{\mathcal{R}} \newcommand{\ModelDownloadEnergy}{E_{\text{download}}} \newcommand{\ModelFlopsUtilization}{\text{MFU}} \newcommand{\ModelGenerationIndex}{n} \newcommand{\ModelInput}{x} \newcommand{\ModelLifetimeCost}{C_{\text{total}}} \newcommand{\ModelParameters}{\theta} \newcommand{\ModelPointAbscissa}{X} \newcommand{\ModelPointHeight}{Z} \newcommand{\ModelPointOrdinate}{Y} \newcommand{\ModelPrediction}{\hat{y}} \newcommand{\ModelPredictor}{f} \newcommand{\ModelScore}{s} \newcommand{\ModelStepOperations}{O_{\text{model}}} \newcommand{\ModelTime}{T_{\text{model}}} \newcommand{\ModelTimeFraction}{f} \newcommand{\ModelWeight}{w} \newcommand{\MomentOrder}{\lambda_{\text{mom}}} \newcommand{\MonitorStartupTime}{T_{\text{vmm}}} \newcommand{\MonitoredFairnessMetricCount}{m} \newcommand{\MonitoredFeatureLevel}{x_{\text{feat}}} \newcommand{\MonitoredGroupCount}{k} \newcommand{\MonitoredMetric}{X} \newcommand{\MonitoredMetricMean}{\mu} \newcommand{\MonitoredMetricStandardDeviation}{\sigma} \newcommand{\MonitoringAlertCost}{C_{\text{alert}}} \newcommand{\MonitoringComputeCost}{C_{\text{compute}}} \newcommand{\MonitoringCostComponent}{C_*} \newcommand{\MonitoringIngestionCost}{C_{\text{ingest}}} \newcommand{\MonitoringStorageCost}{C_{\text{storage}}} \newcommand{\MonotonicClockInstant}{t} \newcommand{\MonthlyOptimizationSavings}{C_{\text{save,monthly}}} \newcommand{\MotionBlurLength}{L} \newcommand{\MotionCyclePeriod}{T_{\text{cycle}}} \newcommand{\MotionModelInput}{\mathbf{u}} \newcommand{\MotorBackEmfConstant}{K_e} \newcommand{\MotorConstant}{K_m} \newcommand{\MotorPhaseRmsCurrent}{I_{\text{phase}}} \newcommand{\MotorRotorAccelerations}{\ddot{\boldsymbol{\theta}}_{\text{motor}}} \newcommand{\MotorRotorCoordinates}{\boldsymbol{\theta}_{\text{motor}}} \newcommand{\MotorRotorVelocities}{\dot{\boldsymbol{\theta}}_{\text{motor}}} \newcommand{\MotorShaftDamping}{D_{\text{motor}}} \newcommand{\MotorShaftPosition}{q_{\text{motor}}} \newcommand{\MotorTorque}{\tau_{\text{motor}}} \newcommand{\MotorTorqueConstant}{K_t} \newcommand{\MotorViscousDamping}{B_{m}} \newcommand{\MotorViscousDampingMatrix}{\mathbf{B}_m} \newcommand{\MpcControlSequence}{\mathbf{u}_{0:N_{\text{mpc}}-1}} \newcommand{\MpcControlSequenceTail}{\mathbf{u}_{1:N_{\text{mpc}}-1}} \newcommand{\MpcHorizonObjective}{J} \newcommand{\MpcPredictionHorizon}{N_{\text{mpc}}} \newcommand{\MpcTerminalCost}{\ell_f} \newcommand{\MpcTerminalCostMatrix}{\mathbf{P}_{N_{\text{mpc}}}} \newcommand{\MultiAgentAcceptanceProbability}{p_{\text{multi}}} \newcommand{\MultiDeviceRunTime}{T_N} \newcommand{\MultimodalFusedTokenStream}{\mathbf{Z}} \newcommand{\MultimodalObservation}{\mathbf{o}} \newcommand{\MutatingToolAction}{a} \newcommand{\MutualInformation}{I} \newcommand{\NaturalLogarithmBase}{e} \newcommand{\NearestCandidateDistance}{D_{\min}} \newcommand{\NeesStatistic}{\epsilon} \newcommand{\NegativeGateSupplyVoltage}{V_{\text{ee}}} \newcommand{\NeighborCount}{k} \newcommand{\NeighborUserIndex}{j} \newcommand{\NeighboringDataset}{X} \newcommand{\NetAngularBrakingDeceleration}{\alpha_{\text{net}}} \newcommand{\NetBrakingDeceleration}{a_{\text{net}}} \newcommand{\NetworkBandwidth}{\text{BW}_{\text{network}}} \newcommand{\NetworkDelayStandardDeviation}{\sigma_d} \newcommand{\NetworkEnergy}{E_{\text{network}}} \newcommand{\NetworkEquipmentPower}{P_{\text{network}}} \newcommand{\NetworkFunction}{f_{\text{net}}} \newcommand{\NetworkLatency}{L_{\text{lat,network}}} \newcommand{\NetworkOutput}{y} \newcommand{\NetworkTrafficVolume}{M} \newcommand{\NeuralLyapunovFactor}{\mathbf{L}_{\phi}} \newcommand{\NeuronActivation}{a} \newcommand{\NeuronBias}{b} \newcommand{\NeuronConnectionWeight}{w_{ij}} \newcommand{\NeuronIndex}{j} \newcommand{\NeuronPreactivation}{z} \newcommand{\NewSoftmaxRunningMaximum}{m_{\text{new}}} \newcommand{\NextDecisionProcessState}{s'} \newcommand{\NextFailureTime}{F} \newcommand{\NextLayerActivationMemory}{M_{\text{activations}}^{(\ell+1)}} \newcommand{\NextProprioceptiveObservation}{\mathbf{o}_{\text{proprio}, t+1}} \newcommand{\NextRobotAction}{\mathbf{a}'} \newcommand{\NextTokenDistribution}{p} \newcommand{\NextTokenEntropy}{\mathcal{H}} \newcommand{\NextTokenLogitFunction}{\mathbf{f}_\theta} \newcommand{\NgramLength}{n} \newcommand{\NicMttf}{\text{MTTF}_{\text{nic}}} \newcommand{\NicsPerNode}{n_{\text{nic}}} \newcommand{\NodeAcceleratorCount}{n_{\text{acc}}} \newcommand{\NodeHbmCapacity}{M_{\text{HBM}}} \newcommand{\NodeMtbf}{\text{MTBF}_{\text{node}}} \newcommand{\NodeStragglerProbability}{p_{\text{straggle}}} \newcommand{\NoisePredictionNetwork}{\boldsymbol{\epsilon}_\theta} \newcommand{\NoisedActionChunk}{\mathbf{A}^k} \newcommand{\NoisyClassProbability}{\tilde{p}} \newcommand{\NoisyClassProbabilityVector}{\tilde{\mathbf{p}}} \newcommand{\NoisyLabelSampleCount}{D_{\text{noisy}}} \newcommand{\NominalBitRate}{R_{\text{nom}}} \newcommand{\NominalBitTime}{T_{\text{bit,nom}}} \newcommand{\NominalBrakingDeceleration}{a_{\text{nominal}}} \newcommand{\NominalClearance}{C_{\text{nominal}}} \newcommand{\NominalClockFrequency}{f_{\text{nom}}} \newcommand{\NominalCommandWindow}{\mathbf{u}_{\text{nom}, t:t+H-1}} \newcommand{\NominalContactForces}{\mathbf{f}_{\text{nom}}} \newcommand{\NominalControlCommand}{\mathbf{u}_{\text{nom}}} \newcommand{\NominalFrameInterval}{T_{\text{nominal}}} \newcommand{\NominalFrictionCoefficient}{\mu_{\text{nom}}} \newcommand{\NominalOscillatorFrequency}{f_{\text{nom}}} \newcommand{\NominalPlanExpiry}{t_{\text{plan\_exp}}} \newcommand{\NominalRatedSpeed}{v_{\text{nominal}}} \newcommand{\NominalReferenceClearance}{c} \newcommand{\NominalSupplyVoltage}{V_{\text{nom}}} \newcommand{\NominalTickPeriod}{T_{\text{period}}} \newcommand{\NominalTrackingTolerance}{\epsilon_{\text{nom}}} \newcommand{\NonconformityScore}{s} \newcommand{\NoninferiorityRatioMargin}{\delta} \newcommand{\NoninferiorityTolerance}{\delta_{\text{tol}}} \newcommand{\NonlinearBiasTorque}{\mathbf{h}} \newcommand{\NonlinearObservationSpace}{\mathbf{O}_{\text{NL}}} \newcommand{\NonlinearOutputFunction}{\mathbf{h}} \newcommand{\NonzeroCount}{n_{\text{nz}}} \newcommand{\NonzeroParameterBudget}{k_{\text{nz}}} \newcommand{\NormWeightMatrix}{\mathbf{W}} \newcommand{\NormalContactForce}{f_{k, \perp}} \newcommand{\NormalContactImpulse}{P_n} \newcommand{\NormalizationScale}{\gamma} \newcommand{\NormalizationScaleVector}{\boldsymbol{\gamma}} \newcommand{\NormalizationShift}{\beta} \newcommand{\NormalizationShiftVector}{\boldsymbol{\beta}} \newcommand{\NormalizedActionCommand}{\tilde{a}} \newcommand{\NormalizedActionResidual}{e} \newcommand{\NormalizedActivation}{\hat{a}} \newcommand{\NormalizedCandidateScore}{c} \newcommand{\NormalizedElapsedTimeRatio}{D} \newcommand{\NormalizedGearRatio}{\tilde{N}} \newcommand{\NormalizedImageAbscissa}{x_n} \newcommand{\NormalizedImageOrdinate}{y_n} \newcommand{\NormalizedMetricBaseline}{v} \newcommand{\NormalizedPredicateMargin}{\bar{f}} \newcommand{\NormalizedRadialDistance}{r} \newcommand{\NormalizedStatusEnvelope}{\mathcal{N}} \newcommand{\NormalizerTokenIndex}{w} \newcommand{\NormalizingClassIndex}{k} \newcommand{\NormalizingKeyIndex}{m} \newcommand{\NormalizingNextState}{\tilde{s}} \newcommand{\NoticeByteAllocation}{M_{\text{notice}}} \newcommand{\NucleusProbabilityMass}{p} \newcommand{\NullSpaceProjector}{\mathbf{N}} \newcommand{\NullSpaceVelocityBias}{\dot{\mathbf{q}}_0} \newcommand{\NumericBitWidth}{b} \newcommand{\NumericalStabilityConstant}{\epsilon} \newcommand{\ObjectHandle}{h} \newcommand{\ObjectWrench}{\mathbf{w}_{\text{obj}}} \newcommand{\ObservabilityMatrix}{\mathbf{O}_{\text{obs}}} \newcommand{\ObservableModelOutput}{O} \newcommand{\ObservationAge}{t_{\text{age}}} \newcommand{\ObservationAgeBudget}{t_{\text{age},\max}} \newcommand{\ObservationAgeDisplacement}{\Delta \mathbf{p}} \newcommand{\ObservationBinding}{\lambda} \newcommand{\ObservationByteBudget}{M_{\text{obs},\max}} \newcommand{\ObservationCount}{N} \newcommand{\ObservationDataset}{\mathcal{D}} \newcommand{\ObservationEncodingTime}{t_{\text{enc}}} \newcommand{\ObservationFunction}{h} \newcommand{\ObservationHistory}{\mathbf{O}} \newcommand{\ObservationHistoryLength}{H_{\text{hist}}} \newcommand{\ObservationHistorySequence}{\mathbf{o}_{0:t}} \newcommand{\ObservationHistoryWindow}{\mathbf{o}_{t-H_{\text{hist}}:t}} \newcommand{\ObservationIntervalEnd}{t_{b}} \newcommand{\ObservationIntervalLength}{T_{\text{obs}}} \newcommand{\ObservationIntervalStart}{t_{a}} \newcommand{\ObservationPairingLag}{\Delta t_{\text{lag}}} \newcommand{\ObservationPayload}{\mathbf{T}_{\text{payload}}} \newcommand{\ObservationResponseLatency}{T_{\text{total}}} \newcommand{\ObservationTimestamp}{t_{\text{obs}}} \newcommand{\ObservationTokenCount}{S_{\text{obs}}} \newcommand{\ObservationTokenSequence}{\mathbf{z}_{\text{token}}} \newcommand{\ObservedAnnotatorAgreement}{p_o} \newcommand{\ObservedCategoryCount}{n_i^{\text{obs}}} \newcommand{\ObservedCycleCount}{N} \newcommand{\ObservedDataPoint}{\mathbf{x}} \newcommand{\ObservedFailureCount}{k} \newcommand{\ObservedFailureFraction}{\hat{p}} \newcommand{\ObservedFreeSpace}{\mathcal{M}_{\text{free}}} \newcommand{\ObservedLabelCount}{n} \newcommand{\ObservedOccupiedSpace}{\mathcal{M}_{\text{occ}}} \newcommand{\ObservedPixelCoordinates}{\tilde{\mathbf{m}}_{\text{observed}}} \newcommand{\ObservedPlantState}{\mathbf{x}_{\text{obs}}} \newcommand{\ObservedPointRange}{r} \newcommand{\ObservedRelativeSpeed}{v_{\text{rel}}} \newcommand{\ObservedSignificanceLevel}{p_{\text{val}}} \newcommand{\ObservedSuccessFraction}{\hat{p}} \newcommand{\ObservedTrialFailureCount}{k} \newcommand{\ObservedViolationFraction}{V} \newcommand{\ObservedVolume}{V_{\text{obs}}} \newcommand{\ObstacleConfigurationSet}{\mathcal{C}_{\text{obs}}} \newcommand{\ObstacleCostWeight}{\lambda_{\text{obs}}} \newcommand{\ObstaclePoint}{\mathbf{o}} \newcommand{\ObstaclePosition}{x_{\text{obstacle}}} \newcommand{\ObstacleProximityCost}{c_{\text{obs}}} \newcommand{\ObstacleRiskRadius}{r_{\text{risk}}} \newcommand{\ObstacleSeparationDistance}{d} \newcommand{\ObstacleStateSet}{\mathcal{X}_{\text{obs}}} \newcommand{\ObstacleSurfaceArea}{A_{\text{surface}}} \newcommand{\OccupancyCoverageMultiplier}{k_\sigma} \newcommand{\OccupancyLogOdds}{L} \newcommand{\OccupancyThreshold}{k} \newcommand{\OccupiedLogOddsIncrement}{L_{\text{occ}}} \newcommand{\OccupiedScenarioCellCount}{N_{\text{supported}}} \newcommand{\OdometryBaseTransform}{\mathbf{T}_{\text{odom}}^{\text{base}}} \newcommand{\OdometryCovarianceJacobian}{\mathbf{J}_{\text{odom}}} \newcommand{\OdometryNoiseStandardDeviation}{\sigma_{w}} \newcommand{\OdometryPoseCovariance}{\boldsymbol{\Sigma}_{\text{odom}}} \newcommand{\OdometryReferenceFrame}{\mathcal{F}_{\text{odom}}} \newcommand{\OfflineTransitionDataset}{\mathcal{D}_{\text{offline}}} \newcommand{\OffloadTailNetworkTime}{t_{\text{net}}^{\text{tail}}} \newcommand{\OffloadTailProcessingTime}{t_{\text{proc}}^{\text{tail}}} \newcommand{\OffloadTransactionWindow}{W} \newcommand{\OhmUnit}{\Omega} \newcommand{\OilBulkModulus}{\beta} \newcommand{\OldSoftmaxRunningMaximum}{m_{\text{old}}} \newcommand{\OnDieDecouplingCapacitance}{C_{\text{die}}} \newcommand{\OnlineSoftmaxKeyTile}{\mathbf{K}_{\text{tile}}} \newcommand{\OnlineSoftmaxQueryBlock}{\mathbf{Q}_{\text{block}}} \newcommand{\OnlineSoftmaxScoreBlock}{\mathbf{A}_{\text{block}}} \newcommand{\OpenLoopTransferFunction}{L} \newcommand{\OpenLoopTransferMatrix}{\mathbf{L}} \newcommand{\OperationChargeBound}{\bar{c}} \newcommand{\OperationDispatchOverhead}{t_{\text{dispatch}}} \newcommand{\OperationRecipient}{r} \newcommand{\OperationReconciliationTime}{T_{\text{rec}}} \newcommand{\OperationalFailureProbability}{p_F} \newcommand{\OperationalOverheadFraction}{f_{\text{overhead}}} \newcommand{\OperationalScenarioDistribution}{p} \newcommand{\OperationalTaxonomyDimension}{C} \newcommand{\OperationalTestDistribution}{\mathcal{D}} \newcommand{\Operations}{O} \newcommand{\OperationsPerSample}{O_{\text{sample}}} \newcommand{\OperatorCognitiveTime}{T_{\text{cognitive}}} \newcommand{\OperatorMotorTime}{T_{\text{motor}}} \newcommand{\OperatorResponseLatency}{t_{\text{hum}}} \newcommand{\OperatorSensoryTime}{T_{\text{sensory}}} \newcommand{\OperatorStabilizationInstant}{t_{\text{stabilize}}} \newcommand{\OperatorWindowTime}{t'} \newcommand{\OperatorWorkspaceMemory}{M_{\text{workspace}}} \newcommand{\OpticalFrequency}{\nu} \newcommand{\OpticalWavelength}{\lambda_{\text{wl}}} \newcommand{\OptimalCheckpointInterval}{T^\ast_{\text{ckpt}}} \newcommand{\OptimalCostToGoDerivative}{\dot{V}} \newcommand{\OptimalCostToGoFunction}{V} \newcommand{\OptimalModelParameters}{\theta^*} \newcommand{\OptimalStateReturn}{V_{\text{RL}}} \newcommand{\OptimizationBreakevenTime}{T_{\text{breakeven}}} \newcommand{\OptimizationImplementationCost}{C_{\text{optimization}}} \newcommand{\OptimizationIterate}{x} \newcommand{\OptimizerStateMemory}{M_{\text{optimizer}}} \newcommand{\OptimizerStepIndex}{t} \newcommand{\OptimizerStepTime}{T_{\text{update}}} \newcommand{\OptimizerUpdateCount}{T} \newcommand{\OptimumMissFactor}{x} \newcommand{\OrderedTestRank}{r} \newcommand{\OrientationTolerance}{\theta_{\text{tol}}} \newcommand{\OrphanSweepInterval}{T} \newcommand{\OscillationPriorStateDigest}{h_{\text{state},t-2}} \newcommand{\OscillatorAcceleration}{\ddot{q}} \newcommand{\OscillatorNaturalFrequency}{\omega} \newcommand{\OscillatorPosition}{q} \newcommand{\OscillatorStepVelocity}{v} \newcommand{\OscillatorVelocity}{\dot{q}} \newcommand{\OutcomeAlphabet}{\mathcal{X}} \newcommand{\OutcomeCheckPassProbability}{p_{\text{out}}} \newcommand{\OutcomeCheckSlotTime}{T_{\text{out}}} \newcommand{\OutcomePairPrivacyLoss}{\mathcal{L}_{\text{priv},(X,X')}^{(o)}} \newcommand{\OutcomeStandardDeviation}{\sigma} \newcommand{\OutgoingChannelCommand}{u_{\text{prior}}} \newcommand{\OutgoingCommandDerivative}{\dot{u}_{\text{prior}}} \newcommand{\OutputBearingDamping}{D_{\text{joint}}} \newcommand{\OutputChannel}{y} \newcommand{\OutputChannelCount}{C_{\text{out}}} \newcommand{\OutputChannelIndex}{k} \newcommand{\OutputComponentFunction}{h} \newcommand{\OutputDimension}{p} \newcommand{\OutputFeatureMapHeight}{H_{\text{out}}} \newcommand{\OutputFeatureMapWidth}{W_{\text{out}}} \newcommand{\OutputIndex}{\ell} \newcommand{\OutputLayerBiasVector}{\mathbf{b}_{\text{out}}} \newcommand{\OutputLayerWeightMatrix}{\mathbf{W}_{\text{out}}} \newcommand{\OutputLength}{K} \newcommand{\OutputLengthStandardDeviation}{\sigma} \newcommand{\OutputLimit}{K_{\max}} \newcommand{\OutputLogit}{z} \newcommand{\OutputNodeAdjoint}{\bar{v}_W} \newcommand{\OutputNodePrimal}{v_W} \newcommand{\OutputProjectionOperations}{O_{\text{out}}} \newcommand{\OutputQuantizationScale}{s_Y} \newcommand{\OutputRelativeDegree}{r} \newcommand{\OutputToken}{y} \newcommand{\OutputTokenPrefix}{y_{<t}} \newcommand{\OutputTokenPrice}{c_{\text{out}}} \newcommand{\OutputTokenSequence}{y_{1:K}} \newcommand{\OutputTorqueCeiling}{\tau_{\text{out,max}}} \newcommand{\OutstandingItemCount}{N_{\text{out}}} \newcommand{\OverheadCameraEmbedding}{\mathbf{e}_{\text{overhead}}} \newcommand{\OverlappedBackwardCommunicationTime}{T_{\text{pipelined}}} \newcommand{\OverlappedTime}{T_{\text{overlap}}} \newcommand{\OverlappingGaussianSet}{\mathcal{N}} \newcommand{\OversubscriptionRatio}{R} \newcommand{\OwnershipAcquisitionTime}{T_{\text{own}}} \newcommand{\PackageDecouplingCapacitance}{C_{\text{pkg}}} \newcommand{\PackageInductance}{L_{\text{pkg}}} \newcommand{\PackageResistance}{R_{\text{pkg}}} \newcommand{\PackageThermalCapacitance}{C_{\text{th}}} \newcommand{\PackageThermalTimeConstant}{\tau_{\text{th}}} \newcommand{\PackedExampleIndex}{k} \newcommand{\PackedExampleLength}{s} \newcommand{\PackedExampleOffset}{b} \newcommand{\PacketBuffer}{b} \newcommand{\PaddingWasteFraction}{W} \newcommand{\PageRankDampingFactor}{d} \newcommand{\PageRankScoreVector}{\mathbf{r}} \newcommand{\PairedAcceptanceDifference}{\Delta} \newcommand{\PairedDifferenceLowerLimit}{L_{\Delta}} \newcommand{\PairedDifferenceUpperLimit}{U_{\Delta}} \newcommand{\PairedOutcomeCellCount}{n} \newcommand{\PairedRandomVariable}{Y} \newcommand{\PairedTaskIndex}{j} \newcommand{\PairedTimeInstant}{s} \newcommand{\PairedVerdictCorrelation}{\hat{\phi}} \newcommand{\PairingLagCeiling}{\Delta t_{\text{lag,max}}} \newcommand{\PairwiseCoordinationCoefficient}{\beta_{\text{pair}}} \newcommand{\PairwiseMaskSecret}{\mathbf{s}} \newcommand{\ParallelEnvironmentCount}{n_{\text{env}}} \newcommand{\ParallelFraction}{f_{\text{parallel}}} \newcommand{\ParallelLoopCount}{k_{\text{parallel}}} \newcommand{\ParallelRigCount}{N_{\text{rig}}} \newcommand{\ParameterPayload}{M_{\text{param}}} \newcommand{\ParameterRandomizationRanges}{\mathcal{P}} \newcommand{\ParameterScaleCoefficient}{A} \newcommand{\ParameterScalingExponent}{\alpha} \newcommand{\ParameterServerCount}{K_{\text{srv}}} \newcommand{\ParameterSpace}{\Theta} \newcommand{\ParameterSpaceDirection}{u} \newcommand{\ParameterStreamingTime}{t_{\text{stream}}} \newcommand{\ParameterVelocity}{\dot{\theta}} \newcommand{\ParameterizedPredictor}{f_{\theta}} \newcommand{\Parameters}{P} \newcommand{\ParametricProposalDistribution}{q_{\boldsymbol{\psi}}} \newcommand{\ParasiticLoopInductance}{L_{\text{parasitic}}} \newcommand{\ParentCapabilityGrant}{\Gamma_{\text{parent}}} \newcommand{\ParentFreeBalance}{F_{P}} \newcommand{\ParentNodeIndex}{k} \newcommand{\ParentReservedFunds}{R_{P}} \newcommand{\ParentSettledCharges}{E_{P}} \newcommand{\ParetoMinimumDemand}{x_{\min}} \newcommand{\ParetoTailExponent}{\alpha_{\text{tail}}} \newcommand{\ParetoTaskDemand}{X} \newcommand{\ParticipatingClientCount}{N_{\text{clients}}} \newcommand{\PartnerBitIndex}{k} \newcommand{\PassAtKEstimate}{\widehat{\operatorname{pass@}k}} \newcommand{\PassedTrialCount}{N_{\text{pass}}} \newcommand{\PassingRunCount}{s} \newcommand{\PassingSampleCount}{c} \newcommand{\PassiveModelPrediction}{\hat{Y}} \newcommand{\PastSynchronizationStepIndex}{j} \newcommand{\PatchColumnIndex}{w} \newcommand{\PatchRowIndex}{h} \newcommand{\PatchTokenCount}{N} \newcommand{\PathAcceleration}{\ddot{s}} \newcommand{\PathAccelerationInput}{u} \newcommand{\PathAccelerationLowerBound}{\ddot{s}_{\min}} \newcommand{\PathAccelerationTorqueCoefficient}{\mathbf{a}_{\tau}} \newcommand{\PathAccelerationUpperBound}{\ddot{s}_{\max}} \newcommand{\PathCoordinate}{s} \newcommand{\PathDelayAsymmetry}{\Delta t_{\text{asym}}} \newcommand{\PathGridPointCount}{N_{\text{grid}}} \newcommand{\PathVelocity}{\dot{s}} \newcommand{\PathVelocityField}{v} \newcommand{\PathVelocitySquaredTorqueCoefficient}{\mathbf{b}_{\tau}} \newcommand{\PayloadGravityTorque}{\tau_{g}} \newcommand{\PayloadLeverArm}{r} \newcommand{\PcieLinkFailureRate}{\lambda_{\text{PCIe}}} \newcommand{\PdnBranchCurrent}{I_{\text{branch}}} \newcommand{\PdnBranchResistance}{R_{\text{PDN}}} \newcommand{\PdnTargetImpedance}{Z_{\text{target}}} \newcommand{\PeakBridgeJerk}{j_{\text{peak}}} \newcommand{\PeakContactForce}{F_{\text{peak}}} \newcommand{\PeakCopperLossPower}{P_{\text{peak}}} \newcommand{\PeakCurrent}{I_{\text{peak}}} \newcommand{\PeakMemoryBandwidth}{\text{BW}_{\text{peak}}} \newcommand{\PeakPenetrationDepth}{\delta_{\max}} \newcommand{\PeakRate}{R_{\text{peak}}} \newcommand{\PeakRegenerativePower}{P_{\text{regen, peak}}} \newcommand{\PeakRotorAngularSpeed}{\omega_{\max}} \newcommand{\PeakSlipRatio}{\lambda_{\text{peak}}} \newcommand{\PeakStopDeceleration}{a_{\text{peak}}} \newcommand{\PeakTorque}{\tau_{\text{peak}}} \newcommand{\PeakTractionCoefficient}{\mu_{\text{peak}}} \newcommand{\PearsonFitStatistic}{\chi^2} \newcommand{\PeerReviewerIndex}{i} \newcommand{\PeerToolCallIndex}{j} \newcommand{\PenaltyContactDamping}{c} \newcommand{\PenaltyContactStiffness}{k_{\text{pen}}} \newcommand{\PenaltyPenetrationDepth}{\delta_{\text{pen}}} \newcommand{\PenaltyRestitutionDuration}{\Delta t_{\text{res}}} \newcommand{\PendulumNaturalFrequency}{\omega_0} \newcommand{\PenetrationDepth}{\delta} \newcommand{\PenetrationRate}{\dot{\delta}} \newcommand{\PenultimateLayerWidth}{n_{N_L-1}} \newcommand{\PerDeviceComputeTime}{T_{\text{compute,local}}} \newcommand{\PerDeviceWeightReadTime}{T_{\text{read}}} \newcommand{\PerExperimentComputeCost}{C_{\text{compute,per-exp}}} \newcommand{\PerExperimentEngineeringCost}{C_{\text{engineer,per-exp}}} \newcommand{\PerFrameDetectionProbability}{p_{\text{frame}}} \newcommand{\PerGpuNetworkFailureRate}{\lambda_{\text{network/GPU}}} \newcommand{\PerGpuPowerFailureRate}{\lambda_{\text{power/GPU}}} \newcommand{\PerGpuTotalFailureRate}{\lambda_{\text{total/GPU}}} \newcommand{\PerStepCostBound}{C_{\max}} \newcommand{\PerStepErrorRate}{\epsilon} \newcommand{\PerStreamTokenRate}{R} \newcommand{\PerTaskRunCount}{R} \newcommand{\PerTestSignificanceLevel}{\alpha_{\text{sig}}'} \newcommand{\PerTokenDecodeTime}{t_{\text{decode}}} \newcommand{\PerTokenKlEstimate}{\hat{\mathcal{D}}} \newcommand{\PerTokenMaskingTime}{t_{\text{mask}}} \newcommand{\PerTokenPrefillTime}{t_{\text{prefill}}} \newcommand{\PerWorkerBatchSize}{B_{\text{per-worker}}} \newcommand{\PerceptionDepthCovariance}{\boldsymbol{\Sigma}_{\text{depth}}} \newcommand{\PerceptionDispatchTime}{t_{\text{IPC}}} \newcommand{\PerceptionErrorScale}{\epsilon_{\text{scale}}} \newcommand{\PeriodicPeakWindingTemperature}{T_{\text{peak}}} \newcommand{\PeriodicTaskCount}{n} \newcommand{\PermanentMagnetFluxLinkage}{\lambda_{\text{pm}}} \newcommand{\PermissionLoopPeriod}{T_{\text{tick}}} \newcommand{\PermissionPathKernel}{G_\kappa} \newcommand{\PermissionPathParameters}{\kappa} \newcommand{\PermissionTickWaitTime}{t_{\text{wait}}} \newcommand{\PermissionTickWcet}{T_{\text{wcet}}} \newcommand{\PermittedActions}{\mathcal{A}_{\text{perm}}} \newcommand{\PermittedUsePassProbability}{p_{\text{use}}} \newcommand{\PersonApproachTravel}{S_h} \newcommand{\PersonPositionUncertainty}{Z_d} \newcommand{\PersonalizationPenaltyWeight}{\lambda_{\text{reg}}} \newcommand{\PersonalizationVector}{\mathbf{p}} \newcommand{\PerturbationNoiseStandardDeviation}{\sigma} \newcommand{\PerturbationNormOrder}{p} \newcommand{\PerturbedPose}{\mathbf{T}'} \newcommand{\PerturbedSignalDimension}{D} \newcommand{\PerturbedSignalVector}{\mathbf{x}} \newcommand{\PfcWatchdogTimeout}{T_{\text{watchdog}}} \newcommand{\PhaseInductance}{L_{\text{phase}}} \newcommand{\PhaseJoulePower}{P_{\text{phase}}} \newcommand{\PhaseMargin}{\Phi_m} \newcommand{\PhaseResistance}{R_{\text{phase}}} \newcommand{\PhotodiodeQuantumEfficiency}{\eta_{\text{QE}}} \newcommand{\PhysicalPlantDynamics}{f_{\text{real}}} \newcommand{\PhysicalRestoreTime}{t_{\text{physical\_restore}}} \newcommand{\PhysicalReturnLevel}{z_{T, \text{real}}} \newcommand{\PhysicalStateTrajectory}{s_{\text{real}}} \newcommand{\PhysicalStlRobustness}{\rho_{\text{real}}} \newcommand{\PhysicalTrajectorySet}{\mathcal{S}_{\text{real}}} \newcommand{\PhysicalWorldState}{s} \newcommand{\PidDerivativeGain}{K_d} \newcommand{\PidIntegralGain}{K_i} \newcommand{\PidProportionalGain}{K_p} \newcommand{\PidProportionalGainMatrix}{\mathbf{K}_p} \newcommand{\PipelineBubbleFraction}{b_{\text{pipe}}} \newcommand{\PipelineBufferMemory}{M_{\text{required}}} \newcommand{\PipelineClockSkew}{t_{\text{skew}}} \newcommand{\PipelineFlushDelay}{t_{\text{hw\_pipe}}} \newcommand{\PipelineIterationTime}{T_{\text{iteration}}} \newcommand{\PipelineParallelDegree}{N_{\text{PP}}} \newcommand{\PipelineTimeSlot}{t} \newcommand{\PipelinedExecutionTime}{T_{\text{pipelined}}} \newcommand{\PistonArea}{A} \newcommand{\PixelColumnCoordinate}{u} \newcommand{\PixelLastEventTime}{t_{\text{last}}} \newcommand{\PixelOpacityContribution}{\alpha'} \newcommand{\PixelRowCoordinate}{v} \newcommand{\PixelRowStandardDeviation}{\sigma_v} \newcommand{\PixelStandardDeviation}{\sigma_u} \newcommand{\PlacementChoiceCount}{n} \newcommand{\PlaintextInput}{m} \newcommand{\PlanAction}{a} \newcommand{\PlanarHomographyMatrix}{\mathbf{H}} \newcommand{\PlanarPositionEmbedding}{\mathbf{E}_{\text{pos}}^{2D}} \newcommand{\PlanarSpecialEuclideanGroup}{SE(2)} \newcommand{\PlanckConstant}{h} \newcommand{\PlanningOperator}{o} \newcommand{\PlanningStageLatency}{T_{\text{plan}}} \newcommand{\PlanningStartInstant}{t_{\text{plan}}} \newcommand{\PlantDynamicsFunction}{\mathbf{f}} \newcommand{\PlantDynamicsParameters}{\theta_{\text{plant}}} \newcommand{\PlantOutcomeFunction}{g} \newcommand{\PlantParameters}{m} \newcommand{\PlantStateAcceleration}{\ddot{\mathbf{x}}} \newcommand{\PlantStateComponentCount}{N_s} \newcommand{\PlantStateDimension}{n} \newcommand{\PlantStateRate}{\dot{\mathbf{x}}} \newcommand{\PlantStateSpace}{\mathcal{X}} \newcommand{\PlantTransitionDensity}{p_m} \newcommand{\PlantTransitionKernel}{\mathcal{T}} \newcommand{\PlatformAnnualOperationsCost}{C_{\text{after}}} \newcommand{\PlatformResourceCapacity}{\text{Cap}} \newcommand{\PlatformResourceIndex}{i} \newcommand{\PlatformTotalCost}{C_{\text{platform}}} \newcommand{\PlatformUtilization}{U_{\text{platform}}} \newcommand{\PointClearanceMargin}{d_{\text{margin}}} \newcommand{\PointToPointMessageSize}{n} \newcommand{\PointToPointTransferTime}{T} \newcommand{\PoisonedModel}{f_{\mathcal{S} \cup \mathcal{S}_{\text{poison}}}} \newcommand{\PoisoningDataset}{\mathcal{S}_{\text{poison}}} \newcommand{\PoisoningTargetDataset}{\mathcal{S}_{\text{test}}} \newcommand{\PoissonSubintervalCount}{n} \newcommand{\Policy}{\pi_\theta} \newcommand{\PolicyAction}{a} \newcommand{\PolicyActionStandardDeviation}{\sigma^{\pi}} \newcommand{\PolicyActionWindow}{\mathbf{A}_{t:t+H-1}} \newcommand{\PolicyCheckpoint}{v} \newcommand{\PolicyEnsembleCovariance}{\boldsymbol{\Sigma}_{\pi}} \newcommand{\PolicyEntropy}{\mathcal{H}} \newcommand{\PolicyGaussianMean}{\boldsymbol{\mu}_{\theta}} \newcommand{\PolicyGaussianMeanComponent}{\mu^{\pi}} \newcommand{\PolicyGaussianStandardDeviation}{\boldsymbol{\sigma}_{\theta}} \newcommand{\PolicyGradientBaseline}{b} \newcommand{\PolicyGradientEstimate}{\widehat{g}} \newcommand{\PolicyHistoryActionReturn}{Q^{\pi}} \newcommand{\PolicyHistoryAdvantage}{A^{\pi}} \newcommand{\PolicyImitationLoss}{\mathcal{L}_{\text{policy}}} \newcommand{\PolicyLipschitzBound}{L_{\text{lip}}} \newcommand{\PolicyObservedState}{s} \newcommand{\PolicyPassRate}{f} \newcommand{\PolicyProbabilityRatio}{\rho} \newcommand{\PolicyRemainingReturn}{V^{\pi}} \newcommand{\PolicyRequestLength}{S_{\pi}} \newcommand{\PolicyStateActionDistribution}{\rho_{\pi_\theta}} \newcommand{\PolicyTrajectoryDistribution}{p_\theta} \newcommand{\PolicyTti}{T_{\text{TTI}}} \newcommand{\PolicyUpdateStepTime}{T_{\text{step}}} \newcommand{\PolyakAveragingCoefficient}{\tau} \newcommand{\PolynomialCoefficientVector}{\mathbf{a}} \newcommand{\PolynomialTrajectoryCoefficient}{a} \newcommand{\PomdpActionSet}{\mathsf{A}} \newcommand{\PomdpObservationFunction}{\mathsf{O}} \newcommand{\PomdpObservationSet}{\Omega} \newcommand{\PomdpRewardFunction}{\mathsf{R}} \newcommand{\PomdpStateSpace}{\mathsf{S}} \newcommand{\PomdpTransitionFunction}{\mathsf{T}} \newcommand{\PoolResidentMemory}{M_{\text{pool}}} \newcommand{\PooledAcceptanceProbability}{\bar{p}} \newcommand{\PooledConversionRate}{\hat{p}} \newcommand{\PooledSampleApprovalRate}{\hat{p}} \newcommand{\PopulationStabilityBinCount}{n_{\text{bins}}} \newcommand{\PopulationStabilitySmoothingConstant}{\epsilon_{\text{smooth}}} \newcommand{\PortCycleNetEnergy}{\Delta E} \newcommand{\PortEffort}{\mathbf{F}} \newcommand{\PortFlow}{\dot{\mathbf{x}}} \newcommand{\PortInput}{\mathbf{u}} \newcommand{\PortOutput}{\mathbf{y}} \newcommand{\PortStoredEnergy}{E} \newcommand{\PortVelocity}{v} \newcommand{\Pose}{\mathbf{T}} \newcommand{\PoseTwistPerturbation}{\boldsymbol{\epsilon}} \newcommand{\PoseTwistPerturbationMatrix}{\hat{\boldsymbol{\epsilon}}} \newcommand{\PositionComponent}{p} \newcommand{\PositionConfidenceEllipsoidRadius}{\chi_{3,0.95}} \newcommand{\PositionErrorBound}{E} \newcommand{\PositionErrorCeiling}{e_{\max}} \newcommand{\PositionErrorCovariance}{\mathbf{P}_{pp}} \newcommand{\PositionErrorEnvelope}{e} \newcommand{\PositionLossMask}{m} \newcommand{\PositionUncertaintyRadius}{r} \newcommand{\PositionalTaskTolerance}{r_{\text{tol}}} \newcommand{\PositiveClassInput}{x_{+}} \newcommand{\PositiveIntegerExponent}{n} \newcommand{\PostContactDrivenStroke}{\Delta x_{\text{driven}}} \newcommand{\PostImpactNormalVelocity}{v_n^+} \newcommand{\PostRevocationDelay}{\tau_{\text{rev}}} \newcommand{\PosteriorCovarianceMatrix}{\boldsymbol{\Sigma}_{\text{post}}} \newcommand{\PosteriorDifferentialEntropy}{h_{\text{post}}} \newcommand{\PostprocessingLatency}{L_{\text{lat,post}}} \newcommand{\PotentialOutcome}{Y^{\text{pot}}} \newcommand{\PowerCriticalQuantile}{z_{\beta}} \newcommand{\PowerLimitBase}{a} \newcommand{\PowerRailInductance}{L_{\text{bus}}} \newcommand{\PowerRailResistance}{R_{\text{bus}}} \newcommand{\PoweredHoldCommand}{\mathbf{u}_{\text{hold}}} \newcommand{\PoweredHoldState}{\mathbf{x}_{\text{hold}}} \newcommand{\PoweredServerCount}{N} \newcommand{\PpoClippedSurrogateObjective}{\mathcal{L}^{\text{CLIP}}} \newcommand{\PqApproximateDistance}{\tilde{d}} \newcommand{\PqCentroidCode}{c^{\text{pq}}} \newcommand{\PqSubspaceIndex}{j} \newcommand{\PqSubvectorCount}{m} \newcommand{\PreForwardEnvironmentState}{\sigma_0} \newcommand{\PreImpactNormalVelocity}{v_n^-} \newcommand{\PreImpactSeparationDistance}{d_{\text{sep}}} \newcommand{\PrePivotCatchRate}{v} \newcommand{\PreTriggerWindowDuration}{T_{\text{pre}}} \newcommand{\PreactivationMatrix}{\mathbf{Z}} \newcommand{\PreactivationVector}{\mathbf{z}} \newcommand{\PrebrakeDelay}{\tau_{\text{delay}}} \newcommand{\PrebrakeDelayCeiling}{\tau_{\text{delay},\max}} \newcommand{\PredecessorGraphVertex}{u} \newcommand{\PredicateLipschitzConstant}{L_{\phi}} \newcommand{\PredicateNormalizationScale}{c} \newcommand{\PredictedActionComponent}{\hat{a}} \newcommand{\PredictedClassProbability}{p} \newcommand{\PredictedConfidence}{\hat{p}} \newcommand{\PredictedDecision}{\hat{Y}} \newcommand{\PredictedEnvironmentLatent}{\hat{\mathbf{z}}} \newcommand{\PredictedErrorCovariance}{\mathbf{P}_{k|k-1}} \newcommand{\PredictedForceReading}{\hat{y}} \newcommand{\PredictedOutput}{\hat{\mathbf{y}}} \newcommand{\PredictedOutputComponent}{\hat{y}} \newcommand{\PredictedPolicyAction}{\hat{\mathbf{a}}} \newcommand{\PredictedProtectedAttribute}{\hat{a}} \newcommand{\PredictedRelativeDepth}{z_{\text{pred}}} \newcommand{\PredictedStateEmbedding}{\mathbf{e}_{\text{state}}} \newcommand{\PredictedStateEstimate}{\hat{\mathbf{x}}_{k|k-1}} \newcommand{\PredictionHeadFunction}{g} \newcommand{\PredictionStepIndex}{i} \newcommand{\PredictiveEntropy}{H_{\text{pred}}} \newcommand{\PreemptionFanoutCount}{k} \newcommand{\PreemptionRate}{\lambda_{\text{preempt}}} \newcommand{\PreemptionTaxTime}{T_{\text{preempt}}} \newcommand{\PreferenceMargin}{z} \newcommand{\PreferencePairDataset}{\mathcal{D}} \newcommand{\PreferenceScale}{\beta} \newcommand{\PreferenceScoredPositionSet}{\mathcal{A}} \newcommand{\PreferredReferenceRelativeScore}{\Delta_w} \newcommand{\PreferredTrajectory}{\tau_w} \newcommand{\PrefetchBufferCount}{N_{\text{prefetch}}} \newcommand{\PrefillAllocatedTokenCount}{C} \newcommand{\PrefillArithmeticIntensity}{I_{\text{prefill}}} \newcommand{\PrefillChunkSize}{C_{\text{chunk}}} \newcommand{\PrefillOperations}{O_{\text{prefill}}} \newcommand{\PrefillRequestIndex}{i} \newcommand{\PrefillTime}{T_{\text{prefill}}} \newcommand{\PrefixHitRate}{\rho_{\text{prefix}}} \newcommand{\PregraspPosition}{\mathbf{p}_{\text{pre}}} \newcommand{\PreprocessingLatency}{L_{\text{lat,pre}}} \newcommand{\PreprocessingServiceTime}{T_{\text{preprocessing}}} \newcommand{\PreprocessingThroughput}{R_{\text{preprocessing}}} \newcommand{\PresaturationTorqueCommand}{\boldsymbol{\tau}_{\text{cmd}}} \newcommand{\PreviousLayerWidth}{n_{\ell-1}} \newcommand{\PreviousPeriodCost}{C_{\text{previous}}} \newcommand{\PreviousRangeObservationHistory}{z_{1:t-1}} \newcommand{\PreviousUpdatedErrorCovariance}{\mathbf{P}_{k-1|k-1}} \newcommand{\PreviousUpdatedStateEstimate}{\hat{\mathbf{x}}_{k-1|k-1}} \newcommand{\PrimitiveOperation}{\phi} \newcommand{\PrincipalPointColumn}{c_x} \newcommand{\PrincipalPointRow}{c_y} \newcommand{\PriorCovarianceMatrix}{\boldsymbol{\Sigma}_{\text{prior}}} \newcommand{\PriorDifferentialEntropy}{h_{\text{prior}}} \newcommand{\PriorStandardDeviation}{\sigma_0} \newcommand{\PriorTurnCount}{j} \newcommand{\PrivacyAdditiveSlack}{\delta} \newcommand{\PrivacyBudget}{\epsilon} \newcommand{\PrivacyLossVariable}{\mathcal{L}_{\text{priv}}} \newcommand{\PrivacyNoiseMultiplier}{\sigma} \newcommand{\PrivatizedQuery}{\tilde{f}} \newcommand{\PrivilegeTrapTime}{T_{\text{trap}}} \newcommand{\PrivilegedSimulatorState}{s_{\text{priv}}} \newcommand{\PrivilegedStateDimension}{d_{\text{priv}}} \newcommand{\PrivilegedStateEncoder}{E} \newcommand{\ProbabilityFunction}{p} \newcommand{\ProbabilitySimplex}{\Delta} \newcommand{\ProbedCellCount}{n_{\text{probe}}} \newcommand{\ProcessConditionCheckTime}{T_{\text{proc}}} \newcommand{\ProcessConditionPassProbability}{p_{\text{proc}}} \newcommand{\ProcessNoiseCovariance}{\mathbf{Q}} \newcommand{\ProcessNoiseIntensity}{\mathbf{Q}} \newcommand{\ProcessNoiseVector}{\mathbf{w}} \newcommand{\ProcessedDataVolume}{D_{\text{vol,processed}}} \newcommand{\ProcessedKeyTileIndex}{t} \newcommand{\ProcessedSampleCount}{N_{\text{samples}}} \newcommand{\ProcessingBufferCount}{N_{\text{processing}}} \newcommand{\ProcessingPrice}{R_{\text{process/GB}}} \newcommand{\ProductFactorIndex}{j} \newcommand{\ProductionExecutionCount}{N_{\text{prod}}} \newcommand{\ProductionModelCount}{N_{\text{models}}} \newcommand{\ProductionOnlyFailureCount}{n_{\text{prod}}} \newcommand{\ProfileAccelerationBound}{a_{\max}} \newcommand{\ProfileJerk}{\dot{a}} \newcommand{\ProgramGoodput}{\eta_{\text{program}}} \newcommand{\ProgramInvariantPredicate}{P} \newcommand{\ProgramState}{s} \newcommand{\ProgramStateSpace}{\Sigma} \newcommand{\ProjectedSeamState}{\hat{\mathbf{x}}_{\text{seam}}} \newcommand{\ProjectedTrajectoryRecord}{R} \newcommand{\ProjectedTurnGradientContribution}{Z} \newcommand{\ProjectionBallRadius}{\epsilon} \newcommand{\ProjectionConstraintSet}{\mathcal{C}} \newcommand{\ProjectiveDistanceSample}{s} \newcommand{\ProjectiveRayScale}{\lambda} \newcommand{\ProjectiveScaleFactor}{s} \newcommand{\PromotedFusionInputRank}{r'} \newcommand{\PromptLength}{S_{\text{prompt}}} \newcommand{\PromptToken}{x} \newcommand{\PromptTokensSent}{S_{\text{sent}}} \newcommand{\PropagatedPositionStandardDeviation}{\sigma_p} \newcommand{\PropensityPriorApprovalShape}{a} \newcommand{\PropensityPriorRejectionShape}{b} \newcommand{\ProportionTestStatistic}{z} \newcommand{\ProportionalGainMatrix}{\mathbf{K}_{p}} \newcommand{\ProportionalPotentialEnergy}{\mathcal{L}_{\text{pos}}} \newcommand{\ProposalDeserializationTime}{t_{\text{deser}}} \newcommand{\ProposalExpiryInstant}{t_{\text{valid}}} \newcommand{\ProposalFirstWaypoint}{\mathbf{a}_0} \newcommand{\ProposalLinkTransportTime}{t_{\text{link}}} \newcommand{\ProposalParameterVector}{\boldsymbol{\psi}} \newcommand{\ProposalPayload}{\mathcal{P}} \newcommand{\ProposedAccess}{r} \newcommand{\ProposedContactForce}{F_{\text{nom}}} \newcommand{\ProposedEndEffectorPoseSequence}{\mathbf{X}_{1:H}} \newcommand{\ProposedGripperCommandSequence}{\mathbf{g}_{1:H}} \newcommand{\ProposedJointPositionSequence}{\mathbf{Q}_{1:H}} \newcommand{\ProposedJointVelocitySequence}{\dot{\mathbf{Q}}_{1:H}} \newcommand{\ProposedOperation}{o} \newcommand{\ProposerConfidenceScore}{\hat{p}} \newcommand{\ProposerEvaluationRate}{f} \newcommand{\ProposerInferenceTime}{t_{\text{infer}}} \newcommand{\ProprioceptiveInputSpace}{\mathcal{X}} \newcommand{\ProprioceptiveInputVector}{\mathbf{x}} \newcommand{\ProprioceptiveTokenEmbeddings}{\mathbf{z}_{\text{proprio}}} \newcommand{\ProtectedAttribute}{a} \newcommand{\ProtectedGroupMembership}{G} \newcommand{\ProtectedTrainingRecord}{R} \newcommand{\ProtectionSwitchResistance}{R_{\text{switch}}} \newcommand{\ProtectiveClearanceMargin}{\delta_{\text{margin}}} \newcommand{\ProtectiveSeparationDistance}{S_p} \newcommand{\ProtectiveSpringStiffness}{k_{\text{spring}}} \newcommand{\ProtectiveSpringTravel}{\delta} \newcommand{\ProxyTrajectoryReward}{\hat{R}} \newcommand{\PrunedWeightMatrix}{\hat{\mathbf{W}}} \newcommand{\PruningMask}{\mathbf{M}} \newcommand{\PruningMaskEntry}{M_{i,j}} \newcommand{\PruningThreshold}{\delta_{\text{prune}}} \newcommand{\PsuMttf}{\text{MTTF}_{\text{psu}}} \newcommand{\PtpExchangeTimestamp}{t} \newcommand{\PtpForwardPathDelay}{T_{\text{prop}, M \to S}} \newcommand{\PtpHardwareTimestamp}{t_{\text{PTP}}} \newcommand{\PtpPropagationDelay}{T_{\text{prop}}} \newcommand{\PtpReversePathDelay}{T_{\text{prop}, S \to M}} \newcommand{\PublicationEpoch}{t_{\text{pub}}} \newcommand{\PufChallenge}{C} \newcommand{\PufResponse}{R} \newcommand{\PufResponseBit}{r} \newcommand{\PulseRoundTripTime}{\Delta t} \newcommand{\PureNoiseActionChunk}{\mathbf{A}^N} \newcommand{\PureTransportDelay}{T_d} \newcommand{\PwmPeriod}{T_{\text{pwm}}} \newcommand{\QuadratureAxisInductance}{L_q} \newcommand{\QuadratureAxisVoltage}{v_q} \newcommand{\QualifiedAdmissionRate}{r} \newcommand{\QualityObjective}{S_{\text{quality}}} \newcommand{\QuantileLevel}{u} \newcommand{\QuantileProbabilityLevel}{q} \newcommand{\QuantileThresholdCandidate}{x} \newcommand{\QuantizationBitWidth}{b} \newcommand{\QuantizationBlockSize}{b_{\text{block}}} \newcommand{\QuantizationScale}{s} \newcommand{\QuantizationStep}{\delta} \newcommand{\QuantizationZeroPoint}{z} \newcommand{\QuantizedGradient}{\mathbf{g}_{\text{int8}}} \newcommand{\QuantizedIntegerCode}{x_q} \newcommand{\QuantizedWeightEntry}{W_{ik}} \newcommand{\QuantizerInput}{x} \newcommand{\QuarterCycleCompressionTime}{t_{\text{peak}}} \newcommand{\QueryAxisLabel}{i} \newcommand{\QueryBlockCount}{T_r} \newcommand{\QueryBlockIndex}{i} \newcommand{\QueryBlockSize}{B_r} \newcommand{\QueryBoundaryCount}{S_{\text{eff}}} \newcommand{\QueryBufferPosition}{i} \newcommand{\QueryComponent}{q_{im}} \newcommand{\QueryPrice}{p_{\text{query}}} \newcommand{\QueryProjectionMatrix}{\mathbf{W}_{Q}} \newcommand{\QuerySensitivity}{\Delta} \newcommand{\QuerySourceMatrix}{\mathbf{X}_{Q}} \newcommand{\QueryVector}{\mathbf{q}} \newcommand{\QueryWord}{q} \newcommand{\QueryWordDocumentFrequency}{n} \newcommand{\QueryWordFrequency}{f} \newcommand{\QueryWorkspaceGeneration}{g_q} \newcommand{\QueueArrivalTime}{t_{\text{arr}, i}} \newcommand{\QueueServerCount}{c} \newcommand{\QueueServiceVariationCoefficient}{c_{s}} \newcommand{\QueueSystemCapacity}{K} \newcommand{\QueueWaitTime}{W_{q}} \newcommand{\QueuedJobCount}{N_{\text{queue}}} \newcommand{\QueuedTransactionBytes}{D_{\text{vol}}} \newcommand{\QueuedTransactionCount}{K} \newcommand{\QueuedTransactionSet}{\mathcal{Q}} \newcommand{\QueueingLatency}{L_{\text{lat,queue}}} \newcommand{\QuiescentJunctionTemperature}{T_{\text{j},\text{target}}} \newcommand{\QuiescentSocPower}{P_{\text{base}}} \newcommand{\QuinticBlendCoefficient}{\mathbf{a}} \newcommand{\QuotaReductionSensitivity}{\gamma_{\text{rate}}} \newcommand{\RadarRangeResolution}{\Delta R} \newcommand{\RadialBasisKernelCoefficient}{\gamma} \newcommand{\RadialDistortionCoefficient}{k} \newcommand{\RadialRange}{R} \newcommand{\RadialRangeStandardDeviation}{\sigma_R} \newcommand{\RadiationWavelength}{\lambda} \newcommand{\RailVoltageTolerance}{\delta_{\text{tol}}} \newcommand{\RandomEnvironmentState}{S} \newcommand{\RandomRetainedElementCount}{K_{\text{rand}}} \newcommand{\RandomSampleCollectionSize}{D_{\text{eval,total}}} \newcommand{\RandomVectorDimension}{d} \newcommand{\RandomizationClusterCount}{K} \newcommand{\RandomizedMechanism}{\mathcal{M}} \newcommand{\RandomizedSmoothingNoise}{\boldsymbol{\delta}} \newcommand{\RangeObservation}{z} \newcommand{\RangeObservationHistory}{z_{1:t}} \newcommand{\RankComponentIndex}{s} \newcommand{\RankConstrainedMatrix}{\mathbf{A}} \newcommand{\RankContribution}{x} \newcommand{\RankCountBinaryExponent}{m} \newcommand{\RankFusionSmoothingConstant}{k_{\text{rrf}}} \newcommand{\RankIndex}{i} \newcommand{\RankReductionResult}{y} \newcommand{\RankingFunction}{V} \newcommand{\RatedActuatorTorque}{\tau_{\text{rated}}} \newcommand{\RatedCurrentEquilibriumTemperature}{T_{\text{eq}}} \newcommand{\RatedFatigueLife}{L_{10}} \newcommand{\RatedJointTorque}{\boldsymbol{\tau}_{\text{rated}}} \newcommand{\RatingCategory}{y} \newcommand{\RatioClippingWidth}{\epsilon_{\text{clip}}} \newcommand{\RationaleTokens}{z} \newcommand{\RawClearanceBarrierFunction}{h_{\text{raw}}} \newcommand{\RawDataUploadEnergy}{E_{\text{raw}}} \newcommand{\RawHardwareFaultRate}{\lambda_{\text{raw}}} \newcommand{\RawPipelineInput}{x} \newcommand{\RawRecordCount}{N} \newcommand{\RawSensoryData}{\mathbf{S}} \newcommand{\RayReturnRange}{r_{\text{hit}}} \newcommand{\RayStepCount}{N_{\text{steps}}} \newcommand{\RayTraversalLength}{d_{\text{ray}}} \newcommand{\RayVoxelRange}{r_{\text{voxel}}} \newcommand{\RayleighDissipationFunction}{\mathcal{D}} \newcommand{\ReachabilityCostate}{\mathbf{p}} \newcommand{\ReachabilityHamiltonian}{\mathcal{H}} \newcommand{\ReachabilityHorizonInstant}{t'} \newcommand{\ReachabilityLevelFunction}{V} \newcommand{\ReachabilityTerminalTime}{T} \newcommand{\ReachableArtifactNode}{u} \newcommand{\ReachableDistance}{d_{\text{reach}}} \newcommand{\ReachableWorkspace}{\mathcal{W}} \newcommand{\ReadEndSequenceCount}{c_{\text{end}}} \newcommand{\ReadStartSequenceCount}{c_{\text{start}}} \newcommand{\ReadTimeCeiling}{R} \newcommand{\RealDataset}{\mathcal{S}_{\text{real}}} \newcommand{\RealTimeTaskIndex}{i} \newcommand{\RealityGapVector}{\boldsymbol{\Delta}_{\text{sim2real}}} \newcommand{\RealizedActuatorEffort}{u_{\text{act}}} \newcommand{\RealizedArrivalCount}{n} \newcommand{\RealizedDamageOutcome}{y} \newcommand{\RealizedDampingPower}{P_d} \newcommand{\RealizedDeviceComputeRate}{R} \newcommand{\RealizedFalseAlarmProbability}{\alpha_{*}} \newcommand{\RealizedMissedDegradationProbability}{\beta_{*}} \newcommand{\RealizedServiceTime}{s} \newcommand{\ReceiptSampleIndex}{t_{\text{recv}}} \newcommand{\ReceiveBandwidth}{\text{BW}_{\text{rx}}} \newcommand{\ReceiverOverhead}{o_{\text{recv}}} \newcommand{\ReceiverTimingJitter}{\sigma_{\Delta t}} \newcommand{\RecentUsageShare}{F_{\text{actual}}} \newcommand{\RecommenderItemCount}{N_{\text{items}}} \newcommand{\RecommenderUserCount}{N_{\text{users}}} \newcommand{\ReconcilableToolInterface}{\mathbb{T}_{a}} \newcommand{\ReconstructedGradient}{\hat{\mathbf{g}}} \newcommand{\ReconstructedWeight}{\hat{w}} \newcommand{\RecordAdequacyPassProbability}{p_{\text{record}}} \newcommand{\RecordSizeCeiling}{s_{\max}} \newcommand{\RecordedAuthorityState}{S_{\text{auth}}} \newcommand{\RecoveryCompletionInstant}{t_{\text{rec}}} \newcommand{\RecoveryPoseTolerance}{\epsilon_{\text{sync}}} \newcommand{\RecoveryTargetLogPosition}{j_{\text{target}}} \newcommand{\RecoveryWarmupTime}{T_{\text{warmup}}} \newcommand{\RecurrentHiddenBias}{\mathbf{b}_{\text{h}}} \newcommand{\RecurrentHiddenState}{\mathbf{h}} \newcommand{\RecurrentInputWeights}{\mathbf{W}_{\text{hx}}} \newcommand{\RecurrentOutputWeights}{\mathbf{W}_{\text{yh}}} \newcommand{\RecurrentStateWeights}{\mathbf{W}_{\text{hh}}} \newcommand{\ReduceScatterCompletionTime}{T_{\text{reducescatter}}} \newcommand{\ReducedBoundaryConditionVector}{\mathbf{b}_{\text{red}}} \newcommand{\ReducedImpactMass}{m_{\text{red}}} \newcommand{\ReducibleLoss}{\hat{\mathcal{L}}} \newcommand{\ReductionInputCount}{n} \newcommand{\RedundantComponentCount}{N_{\text{red}}} \newcommand{\RedundantReplicaCount}{k} \newcommand{\RedundantServiceAvailability}{A_{\text{system}}} \newcommand{\ReferenceActionDisadvantage}{A_t^{\pi^*}} \newcommand{\ReferenceAssessedFailure}{F} \newcommand{\ReferenceBinIndex}{b} \newcommand{\ReferenceBinProportion}{E} \newcommand{\ReferenceCostToGo}{Q_t^{\pi^*}} \newcommand{\ReferenceDisagreementProbability}{\mathcal{L}} \newcommand{\ReferenceDistribution}{p} \newcommand{\ReferenceJointAccelerations}{\ddot{\mathbf{q}}^{\text{ref}}} \newcommand{\ReferenceJointPosition}{q_{\text{reference}}} \newcommand{\ReferenceJointPositions}{\mathbf{q}^{\text{ref}}} \newcommand{\ReferenceJointVelocities}{\dot{\mathbf{q}}^{\text{ref}}} \newcommand{\ReferenceLogProbabilitySum}{\Delta_{\text{ref}}} \newcommand{\ReferenceMixingProbability}{\lambda} \newcommand{\ReferenceNextTokenDistribution}{q} \newcommand{\ReferencePosition}{\mathbf{r}} \newcommand{\ReferenceProbabilityRatio}{z} \newcommand{\ReferenceRelativeScore}{\Delta_\theta} \newcommand{\ReferenceRequestLength}{S_{\text{ref}}} \newcommand{\ReferenceSampleEmpiricalCdf}{F} \newcommand{\ReferenceStateDisagreementRate}{\epsilon_E} \newcommand{\ReferenceStateDistribution}{d_{\pi^*}} \newcommand{\ReferenceStepDisagreementRate}{\epsilon} \newcommand{\ReferenceWindingResistance}{R_0} \newcommand{\ReflectedContactForce}{F_{\text{contact}}} \newcommand{\ReflectedRotorInertia}{J_{\text{ref}}} \newcommand{\ReflectedRotorInertiaMatrix}{\mathbf{J}_m} \newcommand{\ReflectedTransmissionInputInertia}{J_{\text{ref,in}}} \newcommand{\ReflectionAngle}{\theta_{\text{refl}}} \newcommand{\ReflexCollisionBudget}{T_{\text{reflex\_budget}}} \newcommand{\RegeneratedBrakingEnergy}{E_{\text{regen}}} \newcommand{\RegenerativeBrakingTorque}{\tau_{\text{brake}}} \newcommand{\RegenerativeRecoveryEfficiency}{\eta_{\text{regen}}} \newcommand{\RegisterSetupTime}{t_{\text{setup}}} \newcommand{\RegisteredDescriptorCount}{n_{\text{reg}}} \newcommand{\RegularizedEulerIntegral}{I} \newcommand{\RejectionDecodeStep}{t_{\text{cut}}} \newcommand{\RelationalSelection}{\sigma} \newcommand{\RelativeContrastTolerance}{\epsilon_{\text{contrast}}} \newcommand{\RelativeDeviationBound}{\delta} \newcommand{\RelativeImprovementFraction}{\delta} \newcommand{\RelativeStandardError}{r} \newcommand{\RelevantRecordSet}{\mathcal{D}^*} \newcommand{\ReliabilityTargetIndex}{i} \newcommand{\ReliableDetectionFrameCount}{N_{\text{frames}}} \newcommand{\RemainingCallCount}{N_{\text{rem}}} \newcommand{\RemainingDistanceEstimate}{\hat{s}} \newcommand{\RemainingExecutionLease}{T_{\text{lease,rem}}} \newcommand{\RemainingHarmDistance}{d_{\text{rem}}} \newcommand{\RemainingIntentTime}{T_{\text{rem}}} \newcommand{\RemainingReturn}{R_{\geq k}} \newcommand{\RemainingUprightDistance}{s} \newcommand{\RemoteHardwareEfficiency}{\eta_{\text{hw,remote}}} \newcommand{\RemotePathTime}{T_{\text{remote}}} \newcommand{\RemotePeakRate}{R_{\text{peak,remote}}} \newcommand{\RenderedPixelColor}{C} \newcommand{\RenewalJitterAllowance}{T_{\text{jitter}}} \newcommand{\RenyiDivergence}{\mathcal{D}_{\alpha_{\text{R}}}} \newcommand{\RenyiOrder}{\alpha_{\text{R}}} \newcommand{\RenyiPrivacyBudget}{\epsilon_{\text{R}}} \newcommand{\RepairAttemptCost}{C_{\text{repair}}} \newcommand{\RepairCap}{K_{\text{repair}}} \newcommand{\RepairCapabilityGrant}{\Gamma_{\text{repair}}} \newcommand{\RepairFirstCost}{C_{\text{repair\ first}}} \newcommand{\RepairPatchArtifact}{P} \newcommand{\RepairSuccessProbability}{p} \newcommand{\RepairTurnLatency}{T_{\text{repair}}} \newcommand{\ReparameterizationNoise}{\boldsymbol{\epsilon}} \newcommand{\RepeatedRunCount}{k} \newcommand{\RepeatedRunMean}{\mu_{\text{run}}} \newcommand{\RepeatedRunStandardDeviation}{\sigma_{\text{run}}} \newcommand{\ReplacementLatency}{L} \newcommand{\ReplacementTimingReserve}{T_{\text{reserve}}} \newcommand{\ReplanRequestOffset}{T_{\text{request}}} \newcommand{\ReplayBuffer}{\mathcal{M}} \newcommand{\ReplayBufferTransitionCount}{n_{\text{replay}}} \newcommand{\ReplayedErrorCovariance}{\mathbf{P}_{t_{\text{recv}}}} \newcommand{\ReplayedStateEstimate}{\hat{\mathbf{x}}_{t_{\text{recv}}}} \newcommand{\ReplicaAvailability}{A_{\text{single}}} \newcommand{\ReplicaColdStartTime}{T_{\text{cold-start}}} \newcommand{\ReplicaCount}{R} \newcommand{\ReplicaModelLoadTime}{T_{\text{load}}} \newcommand{\ReplicaProvisioningTime}{T_{\text{provision}}} \newcommand{\ReplicaWarmupTime}{T_{\text{warmup}}} \newcommand{\ReplyLossProbability}{q_{\text{rep}}} \newcommand{\RepositoryEdgeSourceIndex}{i} \newcommand{\RepositoryEdgeTargetIndex}{j} \newcommand{\RepositoryEdgeWeight}{A} \newcommand{\RepositoryEdgeWeightMatrix}{\mathbf{A}} \newcommand{\RepositoryFileCount}{n} \newcommand{\RepositoryGraphEdgeSet}{E} \newcommand{\RepositoryGraphVertexSet}{V} \newcommand{\RepositoryTransitionMatrix}{\mathbf{P}_{\text{graph}}} \newcommand{\ReprojectionResidual}{\epsilon_{\text{reproj}}} \newcommand{\RepublicationIndex}{k} \newcommand{\RepublicationPeriod}{T_{\text{rep}}} \newcommand{\RequantizationScale}{s_{\text{eff}}} \newcommand{\RequestCompressionRatio}{\gamma_{\text{req}}} \newcommand{\RequestConcurrency}{Q_{\text{req}}} \newcommand{\RequestLossProbability}{q_{\text{req}}} \newcommand{\RequestOutputLength}{S} \newcommand{\RequestPromptTokens}{\mathbf{x}} \newcommand{\RequestQueueTime}{T_{\text{queue}}} \newcommand{\RequestResidenceTime}{W} \newcommand{\RequestResponseTime}{t} \newcommand{\RequestSeenBatchSize}{B_{\text{req}}} \newcommand{\RequestServiceTime}{T_{\text{svc}}} \newcommand{\RequestTimeInSystem}{T_{\text{lat}}} \newcommand{\RequestedActionTap}{a_{\text{req}}} \newcommand{\RequiredClearance}{C_{\text{safe}}} \newcommand{\RequiredComponentCount}{N} \newcommand{\RequiredDetectionRange}{d_{\text{detect}}} \newcommand{\RequiredInputBandwidth}{\text{BW}_{\text{required}}} \newcommand{\RequiredMemoryBandwidth}{\text{BW}_{\text{req}}} \newcommand{\RequiredPremiseClaim}{P} \newcommand{\RequiredPremiseConfidence}{p} \newcommand{\RequiredPremiseCount}{n} \newcommand{\RequiredResultCount}{k} \newcommand{\RequiredScenarioCellCount}{N_{\text{req}}} \newcommand{\RequiredScenarioSet}{\mathcal{S}_{\text{req}}} \newcommand{\RequiredServiceRate}{\mu_{\text{required}}} \newcommand{\RequiredTaskPairCount}{N'} \newcommand{\RequiredUsersPerVariant}{n} \newcommand{\ResampledReplacementToken}{T_4'} \newcommand{\ReservedDeviceMemory}{M_{\text{reserve}}} \newcommand{\ResetCalibrationTime}{t_{\text{calibration}}} \newcommand{\ResetDuration}{t_{\text{rst}}} \newcommand{\ResetLatency}{T_{\text{reset}}} \newcommand{\ResidentStopDistance}{d_{\text{suffix}}} \newcommand{\ResidentWeightMemory}{M_{\text{weights,resident}}} \newcommand{\ResidualAdapterFunction}{A} \newcommand{\ResidualBlockOutput}{\mathbf{y}} \newcommand{\ResidualCorrectionCeiling}{\Delta_{\max}} \newcommand{\ResidualDynamicsPerturbation}{\Delta \mathbf{f}} \newcommand{\ResidualFrequencyError}{\Delta f_{\text{res}}} \newcommand{\ResidualFunction}{\mathcal{F}} \newcommand{\ResidualGate}{g} \newcommand{\ResidualPolicyTorque}{\boldsymbol{\tau}_{\text{res},\theta}} \newcommand{\ResidualSamplingDistribution}{p_{\text{res}}} \newcommand{\ResizedWorkerCount}{N_{\text{new}}} \newcommand{\ResolutionScalingRatio}{\gamma} \newcommand{\ResourceChangeRate}{r_{\text{chg}}} \newcommand{\ResourceCostBudget}{C_{\text{max}}} \newcommand{\ResourceTypeIndex}{r} \newcommand{\ResourceUtilization}{U} \newcommand{\ResponseActionTokens}{a} \newcommand{\ResponseMetadata}{\mathbf{m}} \newcommand{\ResponsePayload}{\mathbf{y}} \newcommand{\ResponseReward}{r} \newcommand{\ResponseThreshold}{\tau} \newcommand{\ResponseTimeDistributionFunction}{F} \newcommand{\ResponseTimeIterationIndex}{\ell} \newcommand{\ResponseTimeStandardDeviation}{\sigma_t} \newcommand{\RestConfiguration}{\mathbf{q}_{\text{rest}}} \newcommand{\RestitutionCoefficient}{e} \newcommand{\RestoreWorkerCount}{w} \newcommand{\RestrictedAccelerationBound}{a_{\text{restricted}}} \newcommand{\RestrictedSpeedBound}{v_{\text{restricted}}} \newcommand{\ResultActionTime}{T_{\text{action}}} \newcommand{\ResumeTime}{T_{\text{resume}}} \newcommand{\RetainedDigestCount}{m} \newcommand{\RetainedGradientElementCount}{K_{\text{top}}} \newcommand{\RetainedProductiveTime}{T_{\text{productive}}} \newcommand{\RetainedSpectralEnergyFraction}{\eta_r} \newcommand{\RetainingCallCount}{H_{\text{rem}}} \newcommand{\RetiringChunkJointVelocity}{\dot{q}_A} \newcommand{\RetiringChunkReferenceState}{\mathbf{x}_A} \newcommand{\RetrainingComputeCost}{C_{\text{compute}}} \newcommand{\RetrainingDeploymentCost}{C_{\text{deployment}}} \newcommand{\RetrainingInterval}{T} \newcommand{\RetrainingRiskCost}{C_{\text{risk}}} \newcommand{\RetrainingRunCost}{C} \newcommand{\RetrainingValidationCost}{C_{\text{validation}}} \newcommand{\RetrievalCollectionSize}{N} \newcommand{\RetrievalCutoffCount}{k} \newcommand{\RetrievalMethodIndex}{i} \newcommand{\RetrievedRecordSet}{\mathcal{R}} \newcommand{\RetryAttemptIndex}{j} \newcommand{\RetryBackoffInterval}{b} \newcommand{\RetryJitterDelay}{d} \newcommand{\ReturnLevel}{z} \newcommand{\ReturnPeriodTrialCount}{T} \newcommand{\ReturnStepOffset}{k} \newcommand{\ReturnedClassLabel}{c} \newcommand{\ReusedPrefixLength}{S_{\text{match}}} \newcommand{\ReverseModeWorkConstant}{C} \newcommand{\ReverseTransitionCovariance}{\boldsymbol{\Sigma}} \newcommand{\ReverseTransitionMean}{\boldsymbol{\mu}_\theta} \newcommand{\RevertFidelity}{\rho_{\text{revert}}} \newcommand{\ReviewerFalseApprovalIndicator}{X} \newcommand{\ReviewerIndex}{j} \newcommand{\RevisionPassProbability}{p_{\text{rev}}} \newcommand{\Reward}{r} \newcommand{\RewardFunction}{r} \newcommand{\RewardModel}{r} \newcommand{\RightEvasionAction}{\mathbf{a}_{\text{right}}} \newcommand{\RightSingularVectorMatrix}{\mathbf{Q}} \newcommand{\RigidGangJob}{J} \newcommand{\RigidImpactInstant}{t_{\text{impact}}} \newcommand{\RigidTransformTranslation}{\mathbf{t}} \newcommand{\RingAllReduceBandwidthTime}{T_{\text{bandwidth}}} \newcommand{\RingAllReduceCompletionTime}{T_{\text{ring}}} \newcommand{\RingAllReduceStartupTime}{T_{\text{latency}}} \newcommand{\RingBufferHorizon}{T_{\text{buffer}}} \newcommand{\RingBufferSlotCount}{N_{\text{buffer}}} \newcommand{\RingStepIndex}{s} \newcommand{\RingTreeCrossoverPayload}{M_{\text{crossover}}} \newcommand{\RmsMotorTorque}{\tau_{\text{rms}}} \newcommand{\RmspropSquaredGradientAverage}{s} \newcommand{\RobotAction}{\mathbf{a}} \newcommand{\RobotApproachSpeed}{v_r} \newcommand{\RobotApproachVelocity}{v_{\text{robot}}} \newcommand{\RobotObservation}{\mathbf{o}} \newcommand{\RobotPosition}{x_{\text{robot}}} \newcommand{\RobotPositionUncertainty}{Z_r} \newcommand{\RobotReactionTime}{T_r} \newcommand{\RobotReactionTravel}{S_r} \newcommand{\RobotStoppingTravel}{S_s} \newcommand{\RobotStructuralStiffness}{k_{\text{robot}}} \newcommand{\RobotTransitVolume}{\mathcal{T}_{\text{robot}}} \newcommand{\RollingShutterDistortion}{\Delta \mathbf{x}} \newcommand{\RollingShutterFrameSkew}{\Delta t_{\text{skew}}} \newcommand{\RollingShutterRowReadout}{t_{\text{row}}} \newcommand{\RolloutAction}{a} \newcommand{\RolloutActionSequence}{\mathbf{a}_{0:T}} \newcommand{\RolloutAdmissionAge}{\Delta T_{\text{rollout}}} \newcommand{\RolloutAssessmentTime}{T_{v}} \newcommand{\RolloutDuration}{T_{\text{rollout}}} \newcommand{\RolloutEnvironmentState}{s} \newcommand{\RolloutHorizon}{T} \newcommand{\RolloutLoss}{\mathcal{L}} \newcommand{\RolloutPolicyParameters}{\theta_{\text{old}}} \newcommand{\RolloutPolicyTokenCount}{N} \newcommand{\RolloutStateSequence}{s_{0:T}} \newcommand{\RolloutStepCount}{N} \newcommand{\RolloutStepIndex}{k} \newcommand{\RolloutSurrogateObjective}{\mathcal{L}} \newcommand{\RolloutTurnIndex}{k} \newcommand{\RooflineRidgePoint}{I_{\text{ridge}}} \newcommand{\RotaryRotationMatrix}{\mathbf{R}} \newcommand{\RotatedActivationMatrix}{\mathbf{X}'} \newcommand{\RotatedWeightMatrix}{\mathbf{W}'} \newcommand{\RotatingBodyAngularSpeed}{\omega} \newcommand{\RotatingBodyInertia}{J} \newcommand{\RotationOriginAcceleration}{\mathbf{a}_O} \newcommand{\RotationOriginVelocity}{\mathbf{v}_O} \newcommand{\RotationalKineticEnergy}{E_{k,\text{rot}}} \newcommand{\RotationalSpringStiffness}{K} \newcommand{\RotorAngularSpeed}{\omega_m} \newcommand{\RotorInertia}{J_{\text{rotor}}} \newcommand{\RotorPolePairCount}{N_{\text{poles}}} \newcommand{\RoundCommunicationVolume}{M_r} \newcommand{\RoundDownloadVolume}{M_{\text{download},r}} \newcommand{\RoundDuration}{t_r} \newcommand{\RoundEmittedTokenCount}{N_{\text{emit}}} \newcommand{\RoundProtocolVolume}{M_{\text{protocol},r}} \newcommand{\RoundRetryVolume}{M_{\text{retry},r}} \newcommand{\RoundSampleCount}{n_{\text{round}}} \newcommand{\RoundUploadVolume}{M_{\text{upload},r}} \newcommand{\RoundedClassProbability}{p^{\text{rnd}}} \newcommand{\RoundingDecimalCount}{d_{\text{dec}}} \newcommand{\RoutedExpertCount}{k_{\text{experts}}} \newcommand{\RouterGateProbability}{p_{\text{gate}}} \newcommand{\RowActivationDelay}{t_{\text{RCD}}} \newcommand{\RowActiveTime}{t_{\text{RAS}}} \newcommand{\RowAttitudeIncrement}{\Delta \boldsymbol{\theta}_{\text{att}}} \newcommand{\RowConflictCount}{N_{\text{conflict}}} \newcommand{\RowCycleTime}{t_{\text{RC}}} \newcommand{\RowExposureStartTime}{t_{\text{scan}}} \newcommand{\RowModeComponentVector}{\mathbf{a}_s} \newcommand{\RowModeFactorMatrix}{\mathbf{A}} \newcommand{\RowModeFactorSlice}{\mathbf{a}} \newcommand{\RowParallelOutputMatrix}{\mathbf{Z}} \newcommand{\RowParallelWeightMatrix}{\mathbf{B}} \newcommand{\RowPrechargeTime}{t_{\text{RP}}} \newcommand{\RunIndexSubset}{J} \newcommand{\RuntimeGoodput}{\eta_{\text{runtime}}} \newcommand{\RuntimeReserveMemory}{M_{\text{runtime}}} \newcommand{\SCurveAccelerationPhaseTime}{T_{\text{acc}}} \newcommand{\SafeApproachSpeedEnvelope}{v_{\text{safe}}} \newcommand{\SafeControlSet}{\mathcal{U}_{\text{safe}}} \newcommand{\SafeOverrideCommand}{\mathbf{u}_{\text{safe}}} \newcommand{\SafeSeparationDistance}{d_{\text{safe}}} \newcommand{\SafeSetProjection}{\mathcal{P}_{\mathcal{C}}} \newcommand{\SafeStateConstraintSet}{\mathcal{X}_{\text{safe}}} \newcommand{\SafeStateSet}{\mathcal{X}_{\text{safe}}} \newcommand{\SafeWorldState}{s_A} \newcommand{\SafeguardSeparationDistance}{S} \newcommand{\SafeguardStoppingTime}{T} \newcommand{\SafetyBoundaryManifold}{\partial \mathcal{C}} \newcommand{\SagaCompensatingStep}{C} \newcommand{\SagaFailedForwardStep}{F_k^{\text{fail}}} \newcommand{\SagaForwardStep}{F} \newcommand{\SagaStepIndex}{k} \newcommand{\SampleAcquisitionPrice}{c_{\text{sample}}} \newcommand{\SampleGradientStandardDeviation}{\sigma} \newcommand{\SampleLabelingPrice}{c_{\text{label}}} \newcommand{\SampleStatistic}{\widehat{\theta}} \newcommand{\SampleStorageSize}{s_{\text{sample}}} \newcommand{\SampledPolicyToken}{w} \newcommand{\SampledSimulationParameterVector}{\tilde{\boldsymbol{\xi}}} \newcommand{\SampledUnit}{y} \newcommand{\SampledUnitCount}{m} \newcommand{\SamplingParameters}{\mathbf{\Theta}_{\text{sample}}} \newcommand{\SamplingPeriod}{T_s} \newcommand{\SamplingRate}{f_s} \newcommand{\SamplingTemperature}{\tau_{\text{temp}}} \newcommand{\SandboxColdBootTime}{T_{\text{cold}}} \newcommand{\SaturatedJointTorque}{\boldsymbol{\tau}_{\text{act}}} \newcommand{\SavedEngineeringTime}{T_{\text{saved}}} \newcommand{\ScalarFieldSize}{k} \newcommand{\ScalarGraphFunction}{f} \newcommand{\ScalarKalmanGain}{g} \newcommand{\ScalarTrackingError}{e} \newcommand{\ScalarTrackingErrorAcceleration}{\ddot{e}} \newcommand{\ScalarTrackingErrorRate}{\dot{e}} \newcommand{\ScaleCoefficient}{A_{\mathcal{L}}} \newcommand{\ScaledBatchSize}{B_{\text{new}}} \newcommand{\ScaledJointStiffnessMatrix}{\tilde{\mathbf{K}}} \newcommand{\ScaledLearningRate}{\eta_{\text{new}}} \newcommand{\ScaledResource}{X} \newcommand{\ScaledSerialFraction}{s} \newcommand{\ScalingCurveWorkerCount}{k} \newcommand{\ScalingEfficiency}{\eta_{\text{scaling}}} \newcommand{\ScalingExponent}{\alpha_{\text{scale}}} \newcommand{\ScalingLawLoss}{\mathcal{L}} \newcommand{\ScanCapabilityGrant}{\Gamma_{\text{scan}}} \newcommand{\ScatteringCrossSection}{\sigma_s} \newcommand{\ScenarioCellRecordCount}{N_{\text{cell}}} \newcommand{\SceneRadiance}{I} \newcommand{\ScheduleFinishTime}{T_{\text{finish}}} \newcommand{\ScheduledSessionDuration}{T_{\text{sched}}} \newcommand{\SchedulingClassWeight}{w} \newcommand{\SchedulingGoodput}{\eta_{\text{scheduling}}} \newcommand{\SchedulingIntervalLength}{t} \newcommand{\ScoreNoiseStandardDeviation}{\sigma} \newcommand{\ScoreNoiseVector}{\mathbf{z}} \newcommand{\ScoreRefreshInterval}{k_{\text{refresh}}} \newcommand{\ScoredPrefixLength}{S_{\text{step}}} \newcommand{\ScoredStepCount}{J} \newcommand{\ScoredStepIndex}{j} \newcommand{\ScoredToolCall}{a} \newcommand{\ScoredToolCallCount}{N} \newcommand{\ScoringErrorStandardDeviation}{\sigma} \newcommand{\ScreenSpaceCovariance}{\boldsymbol{\Sigma}_{2D}} \newcommand{\ScreenedFeature}{x} \newcommand{\ScreenedFeatureSet}{X} \newcommand{\ScreeningMissRate}{m} \newcommand{\SeamActualAccelerations}{\ddot{\mathbf{q}}_{\text{actual}}} \newcommand{\SeamActualConfiguration}{\mathbf{q}_{\text{actual}}} \newcommand{\SeamActualVelocities}{\dot{\mathbf{q}}_{\text{actual}}} \newcommand{\SeamBlendReference}{\mathbf{s}} \newcommand{\SeamBridgeDuration}{T_{\text{blend}}} \newcommand{\SeamBridgePosition}{q_{\text{blend}}} \newcommand{\SeamInstant}{t_{\text{seam}}} \newcommand{\SeamStepTorque}{\tau_{\text{request}}} \newcommand{\SearchBranchingFactor}{b} \newcommand{\SearchDepth}{d_{\max}} \newcommand{\SearchDepthIndex}{d} \newcommand{\SearchQueryEmbedding}{\mathbf{q}} \newcommand{\SecondAdjacentCheckIndex}{b} \newcommand{\SecondAdjacentCheckPassProbability}{p_{b}} \newcommand{\SecondAdjacentCheckSlotTime}{T_{b}} \newcommand{\SecondAtomicGradientUpdate}{B} \newcommand{\SecondCatalogDefinitionCount}{n_{\text{def},B}} \newcommand{\SecondCatalogDefinitionSize}{S_{B}} \newcommand{\SecondClassCoverageFloor}{b} \newcommand{\SecondClientMaskedUpdate}{\mathbf{y}_B} \newcommand{\SecondClientModelParameters}{\theta_B} \newcommand{\SecondComparedGroupLabel}{b} \newcommand{\SecondComparedItem}{j} \newcommand{\SecondFloatingPointAddend}{b} \newcommand{\SecondGroupClassificationThreshold}{\tau_{\text{thr},b}} \newcommand{\SecondGroupQualifiedFraction}{q_b} \newcommand{\SecondGroupSampleApprovalRate}{\hat{p}_b} \newcommand{\SecondGroupSampleSize}{n_b} \newcommand{\SecondJaccardSet}{\mathcal{B}} \newcommand{\SecondRankComputeTime}{T_{\text{rank}_1}} \newcommand{\SecondRaterCategoryFraction}{p_{y,2}} \newcommand{\SecondRingTraceElement}{b} \newcommand{\SecondSummandStandardDeviation}{\sigma_b} \newcommand{\SecondTwinCriticReturnEstimate}{Q_{\phi_2}} \newcommand{\SecurityLabelLattice}{\mathbb{L}} \newcommand{\SecurityLabelSet}{\mathcal{S}_{\text{lab}}} \newcommand{\SelectedActuationCommand}{\mathbf{u}_{\text{act}}} \newcommand{\SelectedDescriptorCount}{n_{\text{sel}}} \newcommand{\SelectedLayerSet}{\mathcal{S}} \newcommand{\SelectionOverheadSize}{S_{\text{sel}}} \newcommand{\SelectionScoreFunction}{f} \newcommand{\SelectionTime}{T_{\text{selection}}} \newcommand{\SelectiveAcceptanceScore}{\kappa} \newcommand{\SelfConsistencySampleCount}{k} \newcommand{\SelfWatchdogTimeout}{T_{\text{self}}} \newcommand{\SenderOverhead}{o_{\text{send}}} \newcommand{\SensingRealityGap}{\Delta_{\text{sens}}} \newcommand{\SensingStageLatency}{T_{\text{sense}}} \newcommand{\SensorErrorBound}{\epsilon} \newcommand{\SensorFeatureTokens}{\mathbf{z}_{\text{sensor}}} \newcommand{\SensorLeverArm}{\mathbf{r}_{P/O}} \newcommand{\SensorLeverArmLength}{r} \newcommand{\SensorLinkTransportTime}{t_{\text{transport}}} \newcommand{\SensorNoiseBound}{\epsilon} \newcommand{\SensorNoiseDensity}{N_{\text{IMU}}} \newcommand{\SensorNoiseStandardDeviation}{\sigma} \newcommand{\SensorObservationFunction}{g} \newcommand{\SensorPatternDictionary}{\mathbf{\Phi}_{\text{dict}}} \newcommand{\SensorPitchAngle}{\theta_{\text{pitch}}} \newcommand{\SensorPointAcceleration}{\mathbf{a}_P} \newcommand{\SensorPointVelocity}{\mathbf{v}_P} \newcommand{\SensorReadoutTime}{t_{\text{readout}}} \newcommand{\SensorReferenceFrame}{\mathcal{F}_{\text{sensor}}} \newcommand{\SensorRowIndex}{y} \newcommand{\SensorTraceMatrix}{\mathbf{X}} \newcommand{\SequenceCounterReading}{S} \newcommand{\SequenceIterationOperations}{c_{\text{decode}}} \newcommand{\SequenceLength}{S} \newcommand{\SequenceToken}{x} \newcommand{\SequentialAttemptIndex}{j} \newcommand{\SequentialBackwardCommunicationTime}{T_{\text{sequential}}} \newcommand{\SequentialCandidateCount}{M} \newcommand{\SequentialCostPerAcceptedTask}{C_{\text{eff,seq}}} \newcommand{\SequentialExecutionTime}{T_{\text{sequential}}} \newcommand{\SequentialLikelihoodRatio}{\Lambda_m} \newcommand{\SequentialLogLikelihoodRatio}{\Lambda_m} \newcommand{\SequentialTestObservation}{X} \newcommand{\SequentialTrialCount}{m} \newcommand{\SerialAutocorrelation}{\rho} \newcommand{\SerialCallCount}{n} \newcommand{\SerialFraction}{r} \newcommand{\SerialLinkClockFrequency}{f_{\text{link}}} \newcommand{\SerialReferenceTime}{T_{\text{serial}}} \newcommand{\SerializationLatency}{L_{\text{lat,serialization}}} \newcommand{\SerializedChunkVolume}{D_{\text{vol,chunk}}} \newcommand{\SerializedTrainingExample}{X} \newcommand{\SeriesComponentCount}{N_{\text{series}}} \newcommand{\SeriesElasticStiffness}{k} \newcommand{\SeriesPsuCount}{n_{\text{psu}}} \newcommand{\ServerAggregationEnergy}{E_{\text{aggregation}}} \newcommand{\ServerIndex}{i} \newcommand{\ServerPower}{P_{\text{server}}} \newcommand{\ServerRoutingWeight}{w} \newcommand{\ServiceRate}{\mu} \newcommand{\ServiceTimeStandardDeviation}{\sigma} \newcommand{\ServiceTimeVariationCoefficient}{c_{s}} \newcommand{\ServingCostPerQuery}{C_{\text{serving}}} \newcommand{\ServingEmpiricalCdf}{F_{P_t}} \newcommand{\ServingPathPredictor}{f_{\text{serve}}} \newcommand{\ServingTransformFunction}{f_{\text{serve}}} \newcommand{\ServingUtilization}{\rho_{\text{serv}}} \newcommand{\ServoFrequencyCorrection}{\Delta f} \newcommand{\SessionAttemptCount}{N_{\text{att}}} \newcommand{\SessionRequestCount}{N_{\text{session}}} \newcommand{\SetMemberPoint}{\mathbf{z}} \newcommand{\SetpointSampleIndex}{k} \newcommand{\SetpointStepInterval}{\Delta t_{\text{step}}} \newcommand{\SettledOperationCharge}{c} \newcommand{\SettledTrajectoryCost}{C} \newcommand{\SetupShareCap}{\phi} \newcommand{\ShadowOnlyFailureCount}{n_{\text{shadow}}} \newcommand{\ShannonEntropy}{H} \newcommand{\ShapedObservationSize}{S_{\text{shaped}}} \newcommand{\ShapedTotalReward}{r_{\text{total}}} \newcommand{\ShapingPotential}{\Phi} \newcommand{\ShardIndex}{s} \newcommand{\ShardReaderCount}{n_{\text{workers}}} \newcommand{\SharedBusBandwidth}{\text{BW}_{\text{bus}}} \newcommand{\SharedHardwareInterferenceDelay}{T_{\text{interf,shared}}} \newcommand{\SharedPoolWorkerCount}{N_{\text{pool}}} \newcommand{\SharedPrefixFraction}{f} \newcommand{\SharedPrefixLength}{S_{\text{prefix}}} \newcommand{\SharedPrefixRequestCount}{n_{\text{req}}} \newcommand{\ShellRelativeThickness}{\epsilon} \newcommand{\ShieldInterceptionCoverage}{c_h} \newcommand{\ShiftedMpcControlSequence}{\tilde{\mathbf{u}}_{0:N_{\text{mpc}}-1}} \newcommand{\ShiftedTestDistribution}{\mathcal{D}'} \newcommand{\ShingleLength}{w} \newcommand{\ShipDecision}{\mathbf{1}_{\text{ship}}} \newcommand{\ShootThroughCurrent}{I_{\text{shoot-through}}} \newcommand{\SiblingPolicyAction}{a'} \newcommand{\SiblingTeamAllocation}{U_{\text{allocated}}} \newcommand{\SightlineRange}{d} \newcommand{\SigmoidFunction}{\sigma} \newcommand{\SignalDimension}{n} \newcommand{\SignalHandoff}{\mathcal{H}} \newcommand{\SignalPropagationDelay}{t_{\text{prop}}} \newcommand{\SignalTrajectory}{s} \newcommand{\SignatureBandCount}{b} \newcommand{\SignificanceCriticalQuantile}{z_{1-\alpha_{\text{sig}}/2}} \newcommand{\SignificanceLevel}{\alpha} \newcommand{\SiliconThermalTimeConstant}{\tau_{\text{th,silicon}}} \newcommand{\SimplexProjection}{\Pi_{\Delta^{K-1}}} \newcommand{\SimulatedPlantDynamics}{f_{\text{sim}}} \newcommand{\SimulatedReturnLevel}{z_{T, \text{sim}}} \newcommand{\SimulatedStateTrajectory}{s_{\text{sim}}} \newcommand{\SimulatedStlRobustness}{\rho_{\text{sim}}} \newcommand{\SimulatedTrajectorySet}{\mathcal{S}_{\text{sim}}} \newcommand{\SimulatedTransportDelay}{T_{d,\text{sim}}} \newcommand{\SimulatedUnbrakedImpactForce}{F_{\text{unbraked,sim}}} \newcommand{\SimulationParameterSet}{\Xi} \newcommand{\SimulationParameterVector}{\boldsymbol{\xi}} \newcommand{\SimulatorStepFunction}{\mathbf{F}} \newcommand{\SingleAgentAcceptanceProbability}{p_{\text{single}}} \newcommand{\SingleDeviceContextLength}{S_{\text{single}}} \newcommand{\SingleDeviceRunTime}{T_1} \newcommand{\SingleJointAccelerationLimit}{\ddot{q}_{i,\max}} \newcommand{\SingleJointInertia}{M} \newcommand{\SingleJointVelocityLimit}{\dot{q}_{i,\max}} \newcommand{\SingleLinkBandwidth}{\text{BW}_{\text{link}}} \newcommand{\SinglePrecisionGemvIntensity}{I_{\text{GEMV, 32-bit}}} \newcommand{\SingleStepImitationError}{\epsilon} \newcommand{\SingularSpectrumMatrix}{\mathbf{\Sigma}} \newcommand{\SisaShardCount}{K} \newcommand{\SisaTrainingShard}{S} \newcommand{\SixthHarmonicTorqueRipple}{\tau_{\text{ripple}}} \newcommand{\SkewDisplacementEnvelope}{d_{\text{skew}}} \newcommand{\SkillSelectionDistribution}{p} \newcommand{\SlaveDriveCount}{S} \newcommand{\SlaveDriveIndex}{s} \newcommand{\SlaveForwardingDelay}{t_{\text{slave},s}} \newcommand{\SlipAccelerationBound}{a_{\text{slip}}} \newcommand{\SlipRegularizationSpeed}{\epsilon_{\text{reg}}} \newcommand{\SloVector}{\mathbf{S}} \newcommand{\SlowdownPersistenceUpdateCount}{K} \newcommand{\SmallChange}{\delta} \newcommand{\SmallPerturbation}{\delta} \newcommand{\SmallestJacobianSingularNumber}{\sigma_{\min}} \newcommand{\SmallestKeySingularNumber}{\sigma_{\min(S, d_{\text{head}})}} \newcommand{\SmoothedClassifier}{g} \newcommand{\SmoothedRunnerUpProbability}{p_{B}} \newcommand{\SmoothedTargetAction}{\tilde{\mathbf{a}}'} \newcommand{\SmoothedTopClassProbability}{p_{A}} \newcommand{\SmoothingNoiseClipBound}{c} \newcommand{\SmoothingNoiseStandardDeviation}{\sigma} \newcommand{\SmoothnessConstant}{L_s} \newcommand{\SnapshotReadTime}{t_{\text{own}}} \newcommand{\SnapshotResetCycleTime}{T_{\text{cycle,snap}}} \newcommand{\SnapshotStepIndex}{s} \newcommand{\SoftExpectedActionReturn}{Q} \newcommand{\SoftExpectedRemainingReturn}{V} \newcommand{\SoftenedStudentProbabilityVector}{\mathbf{p}_{\text{student}}^{(T_{\text{distill}})}} \newcommand{\SoftenedTeacherProbabilityVector}{\mathbf{p}_{\text{teacher}}^{(T_{\text{distill}})}} \newcommand{\SoftmaxFunction}{\sigma} \newcommand{\SoftmaxInputScore}{x} \newcommand{\SoftmaxInputVector}{\mathbf{x}} \newcommand{\SoftmaxNormalizer}{z} \newcommand{\SoftmaxOutputProbability}{p} \newcommand{\SoftmaxRowMaximum}{m} \newcommand{\SoftmaxRowScore}{s} \newcommand{\SoftmaxRunningMaximum}{m} \newcommand{\SoftmaxVectorLength}{n} \newcommand{\SontagStabilizingControl}{\mathbf{u}_{\text{Sontag}}} \newcommand{\SourceCurrent}{I_{\text{source}}} \newcommand{\SourceEventTime}{T_{\text{event}}} \newcommand{\SourceFramePoint}{\mathbf{p}_B} \newcommand{\SourceSinkPathSet}{\Pi} \newcommand{\SourceVoltage}{V_{\text{source}}} \newcommand{\SourceWriteShardGrant}{\Gamma_{c}} \newcommand{\SpareStoppingClearance}{d_{\text{spare}}} \newcommand{\SparseMatrixEntryCount}{n_{\text{elem}}} \newcommand{\SparseMatrixRowCount}{n_{\text{rows}}} \newcommand{\SparseProductInputComponent}{v} \newcommand{\SparseWeightMatrix}{\mathbf{W}_{\text{sparse}}} \newcommand{\SparsityPenaltyWeight}{\lambda_{\text{L1}}} \newcommand{\SparsityRatio}{\rho_{\text{sparse}}} \newcommand{\SpatialClearancePredicate}{P_{\text{clear}}} \newcommand{\SpatialColumnIndex}{j} \newcommand{\SpatialCovarianceEmbedding}{\mathbf{e}_{\Sigma}} \newcommand{\SpatialErrorVector}{\boldsymbol{\epsilon}_{\text{spatial}}} \newcommand{\SpatialHashFunction}{h} \newcommand{\SpatialMemoryMap}{\mathcal{M}} \newcommand{\SpatialPositionCount}{N_{\text{pix}}} \newcommand{\SpatialRowIndex}{i} \newcommand{\SpatialTransformation}{\mathcal{T}} \newcommand{\SpecialEuclideanAlgebra}{\mathfrak{se}(3)} \newcommand{\SpecialEuclideanGroup}{SE(3)} \newcommand{\SpecialOrthogonalGroup}{SO(3)} \newcommand{\SpecializedEnergyProductivity}{\rho_{\text{energy,specific}}} \newcommand{\SpecificHeatCapacity}{c_p} \newcommand{\SpectrallyNormalizedWeightMatrix}{\overline{\mathbf{W}}} \newcommand{\SpeculativeDecodingSpeedup}{S_{\text{spec}}} \newcommand{\SpeculativeDraftLength}{K} \newcommand{\SpeculativeDraftTokenCount}{k} \newcommand{\SpeedAtDetection}{v} \newcommand{\SpeedBound}{v_{\max}} \newcommand{\SpendingWindowDuration}{T_{\text{win}}} \newcommand{\SphereSurfaceArea}{S_{D-1}} \newcommand{\SplineControlPoint}{\mathbf{p}} \newcommand{\SplineDegree}{p} \newcommand{\SplineFinalControlIndex}{L} \newcommand{\SplineKnotTime}{\xi} \newcommand{\SplitAssignmentMap}{s} \newcommand{\SplitMessageCount}{N_{\text{msg}}} \newcommand{\SpotHourlyPrice}{C_{\text{spot}}} \newcommand{\SpringBrakeEngagementTime}{t_{\text{engage}}} \newcommand{\SpringCompressionForce}{F} \newcommand{\SprtExpectedLogIncrement}{m} \newcommand{\SprtLowerBoundary}{\Lambda_{\text{lo}}} \newcommand{\SprtLowerLogBoundary}{b_{\text{low}}} \newcommand{\SprtStoppingSampleCount}{N_{\text{stop}}} \newcommand{\SprtUpperBoundary}{\Lambda_{\text{up}}} \newcommand{\SprtUpperLogBoundary}{u} \newcommand{\SquareGemmDimension}{N} \newcommand{\SquaredGaussianSumQuantile}{\chi} \newcommand{\SquaredPathVelocity}{x} \newcommand{\SquaredRadiusSubstitution}{u} \newcommand{\SquashedActionComponent}{a} \newcommand{\SramCapacity}{M_{\text{SRAM}}} \newcommand{\StabilizationErrorThreshold}{\epsilon_{\text{stable}}} \newcommand{\StabilizationSlewCeiling}{j_{\text{stable}}} \newcommand{\StackedContactForces}{\mathbf{f}_{\text{c}}} \newcommand{\StageConditionalAcceptanceProbability}{q} \newcommand{\StageEpisodeCount}{N_{\text{episodes}}} \newcommand{\StageReachProbability}{r} \newcommand{\StagedDefinitionCount}{n_{\text{def}}} \newcommand{\StagingExhaustionTime}{T_{\text{exhaust}}} \newcommand{\StagingStoreCapacity}{M_{\text{stage}}} \newcommand{\StaleSupportRate}{\epsilon_{\text{stale}}} \newcommand{\StalenessAdjustedLearningRate}{\eta'} \newcommand{\StalenessBound}{s} \newcommand{\StallCounterTorque}{\tau_{\text{stall}}} \newcommand{\StallTravelBound}{d_{\text{F1}}} \newcommand{\StandardDeviationMultiple}{k} \newcommand{\StandardNormalCumulativeDistribution}{\Phi} \newcommand{\StandardNormalQuantile}{z_q} \newcommand{\StandbyInstanceMemory}{M_{\text{standby}}} \newcommand{\StandbyPower}{P_{\text{idle}}} \newcommand{\StandbyReserveCount}{N_{\text{reserve}}} \newcommand{\StandstillSpeedThreshold}{\epsilon_{\text{vel}}} \newcommand{\StateConstraintMatrix}{\mathbf{H}_x} \newcommand{\StateConstraintVector}{\mathbf{b}_x} \newcommand{\StateCotangentSpace}{T_{\mathbf{x}}^*} \newcommand{\StateDimension}{n} \newcommand{\StateDistribution}{d_\pi} \newcommand{\StateEstimate}{\hat{\mathbf{x}}} \newcommand{\StateEstimateDerivative}{\dot{\hat{\mathbf{x}}}} \newcommand{\StateEstimationError}{\mathbf{e}} \newcommand{\StateExposureLevel}{S} \newcommand{\StateNormWeighting}{W} \newcommand{\StateOperation}{f} \newcommand{\StateParameterSensitivity}{\mathbf{S}} \newcommand{\StateRecurrencePeriod}{\ell} \newcommand{\StateScalarFunction}{\phi} \newcommand{\StateSpaceDimension}{d_s} \newcommand{\StateSpaceInputMatrix}{\mathbf{B}} \newcommand{\StateSpaceSystemMatrix}{\mathbf{A}_{\text{sys}}} \newcommand{\StateTokenCount}{K_s} \newcommand{\StateTrackingWeightMatrix}{\mathbf{W}_q} \newcommand{\StateTransitionMatrix}{\mathbf{F}} \newcommand{\StatelessCursorPayload}{d} \newcommand{\StaticBatchingOperations}{O_{\text{traditional}}} \newcommand{\StaticChassisPower}{P_{\text{chassis\_static}}} \newcommand{\StaticDataDistribution}{p_{\text{data}}} \newcommand{\StationaryConditionPolynomial}{P} \newcommand{\StatisticalDivergence}{\mathcal{D}(P_t \| P_0)} \newcommand{\StatisticalFalseNegativeRate}{\beta} \newcommand{\StatisticalHypothesis}{H} \newcommand{\StatisticalPowerQuantile}{z_{1-\beta}} \newcommand{\StatisticalSignificanceLevel}{\alpha_{\text{sig}}} \newcommand{\StatorCoreTemperature}{T_{\text{core}}} \newcommand{\StatorIronTemperature}{T_{\text{iron}}} \newcommand{\StatorThermalCapacitance}{C_{\text{th}}} \newcommand{\StatusPollCount}{N_{\text{poll}}} \newcommand{\SteadyDeceleration}{a} \newcommand{\SteadyStateAvailability}{A} \newcommand{\SteadyStateCurrent}{I_{\text{final}}} \newcommand{\SteadyStateErrorCovariance}{\mathbf{P}_{\text{est}}} \newcommand{\SteadyStateIntegratorState}{\mathbf{z}_{\text{ss}}} \newcommand{\SteadyStateTemperatureRise}{\Delta T_{\max}} \newcommand{\SteadyStateTrackingError}{\mathbf{e}_{\text{ss}}} \newcommand{\SteeringTransferTime}{T} \newcommand{\StepFailureHazard}{a} \newcommand{\StepGenerationCost}{C_{\text{gen}}} \newcommand{\StepGenerationTime}{T_{\text{step}}} \newcommand{\StepIoTime}{T_{\text{IO}}} \newcommand{\StepResponsePhaseLag}{\Delta \phi} \newcommand{\StepSettlingTime}{t_{\text{settle}}} \newcommand{\StepSuccessProbability}{p} \newcommand{\StepTestVoltage}{V_{\text{step}}} \newcommand{\StepTimePenalty}{c_{\text{time}}} \newcommand{\StepTokenLogit}{z_{t,v}} \newcommand{\StereoBaseline}{b} \newcommand{\StereoDisparity}{d} \newcommand{\StlEventuallyDeadline}{\tau} \newcommand{\StlFormula}{\phi} \newcommand{\StlIntervalEnd}{b} \newcommand{\StlIntervalStart}{a} \newcommand{\StlPredicateFunction}{f} \newcommand{\StlRobustness}{\rho} \newcommand{\StlUntilOperator}{\mathcal{U}_{[a, b]}} \newcommand{\StockoutNormalQuantile}{z_{1-\epsilon}} \newcommand{\StockoutProbabilityTarget}{\epsilon} \newcommand{\StopAxisAcceleration}{\ddot{q}_{\text{stop}}} \newcommand{\StopAxisPosition}{q_{\text{stop}}} \newcommand{\StopCompletionInstant}{t_{\text{stop\_end}}} \newcommand{\StopDecisionComputeBound}{T_{\text{compute}}} \newcommand{\StopProgress}{u} \newcommand{\StopSequenceSet}{\mathcal{S}_{\text{stop}}} \newcommand{\StoppingBoundaryClearance}{z} \newcommand{\StoppingCrossoverSpeed}{v^{*}} \newcommand{\StoppingDeadline}{t_{\text{deadline,stop}}} \newcommand{\StoppingDistance}{d_{\text{stop}}} \newcommand{\StoppingDistanceBudget}{d_{\text{budget}}} \newcommand{\StoppingDuration}{T_{\text{stop}}} \newcommand{\StorageAccessFactor}{F_{\text{access}}} \newcommand{\StorageBandwidth}{\text{BW}_{\text{storage}}} \newcommand{\StorageCapacityPrice}{C_{\text{storage/byte-time}}} \newcommand{\StorageEquipmentPower}{P_{\text{storage}}} \newcommand{\StorageFunction}{V} \newcommand{\StorageFunctionDerivative}{\dot{V}} \newcommand{\StorageIngestBandwidth}{\text{BW}_{\text{ingest}}} \newcommand{\StoragePrice}{c_{\text{storage}}} \newcommand{\StorageReadTime}{T_{\text{read}}} \newcommand{\StorageRetentionTime}{T_{\text{months}}} \newcommand{\StorageThroughput}{R_{\text{storage}}} \newcommand{\StoredDataVolume}{D_{\text{vol,store}}} \newcommand{\StoredEmbedding}{\mathbf{z}} \newcommand{\StoredIndexVector}{\mathbf{x}} \newcommand{\StoredSystemState}{s} \newcommand{\StoredTokenVolume}{V} \newcommand{\StragglerStepTime}{T_{\text{step,straggler}}} \newcommand{\StreamAcceptanceProbability}{p} \newcommand{\StreamingEndToEndLatency}{T_{\text{streaming}}} \newcommand{\StrideCheckpointCount}{N} \newcommand{\StrongConfigurationAttemptCost}{c_{\text{big}}} \newcommand{\StrongConfigurationPassProbability}{p_{\text{big}}} \newcommand{\StruckObjectMass}{m_{\text{obj}}} \newcommand{\StructuredSparsityGroupSize}{m_{\text{group}}} \newcommand{\StructuredSparsityNonzeroCount}{n_{\text{keep}}} \newcommand{\StudentProbabilityVector}{\mathbf{p}_{\text{student}}} \newcommand{\StuffBitTime}{t_{\text{stuff},i}} \newcommand{\SubgroupIndex}{g} \newcommand{\SubgroupSampleSize}{n} \newcommand{\SubintervalFailureProbability}{p} \newcommand{\SublevelSetThreshold}{c} \newcommand{\SubsequentArrivalTime}{\tau} \newcommand{\SubsetAllPassIndicator}{I_J^{\text{all}}} \newcommand{\SubsetAnyPassIndicator}{I_J} \newcommand{\SubsetDatasetSize}{D_{\text{subset}}} \newcommand{\SuccessCountIndex}{j} \newcommand{\SuccessLowerConfidenceLimit}{p_{\text{lower}}} \newcommand{\SuccessfulTrialCount}{k} \newcommand{\SuccessorActionVector}{\mathbf{a}'} \newcommand{\SuccessorPlanningState}{s'} \newcommand{\SuffixFoldTime}{T_{\text{fold}}} \newcommand{\SummaryOutputLength}{K_{\text{sum}}} \newcommand{\SummaryTokenEmbedding}{\mathbf{x}_{\text{class}}} \newcommand{\SupervisoryMtbi}{T_{\text{MTBI}}} \newcommand{\SupervisoryTakeoverLatency}{T_{\Sigma}} \newcommand{\SupplyVoltage}{V} \newcommand{\SupportPolygon}{\mathcal{P}_{\text{support}}} \newcommand{\SupportSetSize}{n_{\text{shot}}} \newcommand{\SustainableAttemptRate}{R_{\text{attempt}}} \newcommand{\SustainableCopperLossPower}{P_{\text{loss,ss}}} \newcommand{\SustainableHoldingTorque}{\tau_{\text{hold,max}}} \newcommand{\SustainedComputeRate}{R_{\text{sustained}}} \newcommand{\SustainedDropoutFrameCount}{N_{\text{drop}}} \newcommand{\SustainedMemoryBandwidth}{\text{BW}_{\text{mem}}} \newcommand{\SweepCandidateCostFraction}{f} \newcommand{\SweepCandidateCount}{k} \newcommand{\SwitchBreakdownVoltage}{V_{\text{breakdown}}} \newcommand{\SwitchInputCapacitance}{C_{\text{iss}}} \newcommand{\SwitchOnResistance}{R_{\text{ds(on)}}} \newcommand{\SwitchRadix}{k} \newcommand{\SwitchedCapacitance}{C} \newcommand{\SwitchingActivityFactor}{\alpha} \newcommand{\SwitchingEnergy}{E} \newcommand{\SwitchingTransitionTime}{t_{\text{sw}}} \newcommand{\SymbolicPlanningState}{s} \newcommand{\SymmetricClippingThreshold}{\alpha_{\text{sym}}} \newcommand{\SymmetricMessageOverhead}{o} \newcommand{\SymplecticEulerTransitionMatrix}{\mathbf{A}_{\text{symp}}} \newcommand{\SyncMessageInterval}{\Delta t_{\text{interval}}} \newcommand{\SyncPairingDisplacement}{\Delta \mathbf{x}_{\text{sync}}} \newcommand{\SynchronizationBlackout}{T_{\text{blackout}}} \newcommand{\SynchronizationClearanceMargin}{d_{\text{sync}}} \newcommand{\SynchronizationErrorBound}{\epsilon_{\text{sync}}} \newcommand{\SynchronizationStepIndex}{k} \newcommand{\SynchronizationTime}{T_{\text{sync}}} \newcommand{\SyntheticDataGenerator}{G_{\theta}} \newcommand{\SyntheticDataset}{\mathcal{S}_{\text{synthetic}}} \newcommand{\SystemCallFilterTime}{T_{\text{filter}}} \newcommand{\SystemCallOverheadTime}{T_{\text{syscall}}} \newcommand{\SystemFailureRate}{\lambda_{\text{system}}} \newcommand{\SystemHazardRate}{\lambda_{\text{system}, h}} \newcommand{\SystemInstructionTokenCount}{S_{\text{system}}} \newcommand{\SystemMatrixPowerIndex}{k} \newcommand{\SystemMemoryBandwidth}{\text{BW}_{\text{system}}} \newcommand{\SystemMtbf}{\text{MTBF}_{\text{system}}} \newcommand{\SystemReliability}{R_{\text{system}}} \newcommand{\TableRowCount}{N} \newcommand{\TailByteAllocation}{M_{\text{tail}}} \newcommand{\TailMomentOrder}{k} \newcommand{\TailPerformanceMetric}{X} \newcommand{\TailRequestLatency}{T_{\text{lat},\text{p99}}} \newcommand{\TailRequestSeenBatchSize}{B_{\text{req,p99}}} \newcommand{\TailRiskDistributionFunction}{F} \newcommand{\TailRiskObservation}{X} \newcommand{\TailRiskObservationLevel}{x} \newcommand{\TailShapeParameter}{\xi} \newcommand{\TailStepIoTime}{T_{\text{IO,p99}}} \newcommand{\TailSupportUpperEndpoint}{x_F} \newcommand{\TakeoverInstant}{t_{\text{takeover}}} \newcommand{\TakeoverResponseTime}{T_{\Sigma, 1}} \newcommand{\TakeoverStateVisitationDistribution}{p^{\text{takeover}}} \newcommand{\TakeoverTrackingError}{\mathbf{e}_{\text{track}}} \newcommand{\TangentDirection}{\mathbf{v}} \newcommand{\TangentSeedVector}{\dot{\mathbf{x}}} \newcommand{\TangentialContactShear}{\mathbf{f}_{k, \parallel}} \newcommand{\TangentialSpeed}{v_{\text{tangential}}} \newcommand{\TapeIntermediateResult}{y_{\text{tape}}} \newcommand{\TargetAcceptanceDifference}{\Delta} \newcommand{\TargetActionReturnEstimate}{\hat{Q}} \newcommand{\TargetActorParameters}{\theta'} \newcommand{\TargetBatchSize}{B_{\text{target}}} \newcommand{\TargetCompletionQuantile}{q} \newcommand{\TargetComputeRate}{R_{\text{ops}}} \newcommand{\TargetComputeTimeFraction}{\eta_{\text{target}}} \newcommand{\TargetCriticParameters}{\phi'} \newcommand{\TargetCriticReturnEstimate}{Q_{\phi'}} \newcommand{\TargetDeterministicPolicy}{\mu_{\theta'}} \newcommand{\TargetError}{\epsilon} \newcommand{\TargetExceedanceProbability}{\epsilon} \newcommand{\TargetFairShare}{F_{\text{target}}} \newcommand{\TargetFramePoint}{\mathbf{p}_A} \newcommand{\TargetHazardRate}{\lambda_{\text{target}}} \newcommand{\TargetImpedanceDampingMatrix}{\mathbf{D}_d} \newcommand{\TargetImpedanceInertiaMatrix}{\mathbf{M}_d} \newcommand{\TargetImpedanceStiffnessMatrix}{\mathbf{K}_d} \newcommand{\TargetInferenceLatency}{L_{\text{lat,target}}} \newcommand{\TargetKeyAttentionWeight}{\alpha_{\text{target}}} \newcommand{\TargetKeyLogit}{z_{\text{target}}} \newcommand{\TargetModelDistribution}{p_{\theta}} \newcommand{\TargetOrientation}{\mathbf{R}_{\text{target}}} \newcommand{\TargetPlantState}{\mathbf{x}_{f}} \newcommand{\TargetPolicyEntropy}{\overline{\mathcal{H}}} \newcommand{\TargetPose}{\mathbf{T}_{\text{target}}} \newcommand{\TargetPosition}{\mathbf{p}_{\text{target}}} \newcommand{\TargetPositionComponent}{p_{\text{target},i}} \newcommand{\TargetRange}{z} \newcommand{\TargetRepeatedRunConsistency}{p_{\text{target}}} \newcommand{\TargetSamplingDistribution}{p} \newcommand{\TargetServingUtilization}{\rho_{\text{target}}} \newcommand{\TargetSmoothingNoise}{\boldsymbol{\epsilon}} \newcommand{\TargetSmoothingNoiseStandardDeviation}{\sigma} \newcommand{\TargetTokenVolume}{W} \newcommand{\TargetTravelDistance}{d} \newcommand{\TargetTrialFailureProbability}{p_{*}} \newcommand{\TargetTrialSuccessProbability}{p_{\text{target}}} \newcommand{\TargetTwinCriticReturnEstimate}{Q_{\phi'_i}} \newcommand{\TargetUnitQuaternion}{\mathbf{q}_{\text{quat,target}}} \newcommand{\TargetUpdateCount}{K_{\text{target}}} \newcommand{\TargetUtilizationBatchSize}{B_{\text{util}}} \newcommand{\TargetXPosition}{x} \newcommand{\TargetYPosition}{p_y} \newcommand{\TargetZPosition}{z} \newcommand{\TaskAcceptanceLabel}{x} \newcommand{\TaskBlockingTime}{B} \newcommand{\TaskContract}{\mathcal{C}} \newcommand{\TaskContractGoal}{G} \newcommand{\TaskCost}{C_{\text{task}}} \newcommand{\TaskCount}{K} \newcommand{\TaskCoverageProbability}{Q} \newcommand{\TaskCriticalSections}{cs} \newcommand{\TaskDerivativeGain}{\mathbf{K}_{d,i}} \newcommand{\TaskDistance}{d_{\text{task}}} \newcommand{\TaskEnvironment}{\mathcal{E}_{\text{env}}} \newcommand{\TaskErrorTolerance}{\tau_{\text{tol}}} \newcommand{\TaskGroupMap}{g} \newcommand{\TaskIndex}{i} \newcommand{\TaskInterferenceTime}{I} \newcommand{\TaskJacobian}{\mathbf{J}} \newcommand{\TaskJacobianDerivative}{\dot{\mathbf{J}}} \newcommand{\TaskJacobianPseudoinverse}{\mathbf{J}^\dagger} \newcommand{\TaskKinematicMap}{f} \newcommand{\TaskLoss}{\mathcal{L}_{\text{task}}} \newcommand{\TaskLossGradient}{\nabla \mathcal{L}} \newcommand{\TaskPeriod}{T} \newcommand{\TaskProportionalGain}{\mathbf{K}_{p,i}} \newcommand{\TaskReadCount}{n_{\text{read}}} \newcommand{\TaskRelativeDeadline}{D} \newcommand{\TaskRelevantOutcome}{\mathbf{Y}_{\text{task}}} \newcommand{\TaskReward}{r_{\text{task}}} \newcommand{\TaskSetUtilization}{U} \newcommand{\TaskSpaceAcceleration}{\ddot{\mathbf{x}}} \newcommand{\TaskSpaceCoordinates}{\mathbf{x}} \newcommand{\TaskSpaceDimension}{m} \newcommand{\TaskSpaceReference}{\mathbf{x}_i^{\text{ref}}} \newcommand{\TaskSpaceReferenceAcceleration}{\ddot{\mathbf{x}}^{\text{ref}}} \newcommand{\TaskSpaceReferenceVelocity}{\dot{\mathbf{x}}^{\text{ref}}} \newcommand{\TaskSpaceVelocity}{\dot{\mathbf{x}}} \newcommand{\TaskSpecificLoss}{\mathcal{L}} \newcommand{\TaskStateTokenCount}{S_{\text{state}}} \newcommand{\TaskToleranceSemiAxes}{\mathbf{r}} \newcommand{\TaskToleranceSemiAxis}{r} \newcommand{\TaskTurnCost}{C_{\text{call}}} \newcommand{\TaskWeight}{w} \newcommand{\TasksPerComparisonArm}{N_{\text{arm}}} \newcommand{\TeacherProbabilityVector}{\mathbf{p}_{\text{teacher}}} \newcommand{\TeamQuotaCap}{Q_{\text{team}}} \newcommand{\TelemetryFlushTime}{t_{\text{telemetry\_flush}}} \newcommand{\TelemetryFreshnessBound}{\Delta t_{\text{fresh}}} \newcommand{\TelemetryRetentionDuration}{T_{\text{retention}}} \newcommand{\TelemetrySamplingFrequency}{f_{\text{sample}}} \newcommand{\TelemetrySeriesCount}{N_{\text{series}}} \newcommand{\TelemetryTickInterval}{\Delta t_s} \newcommand{\TeleoperationCommandLatency}{t_{\text{cmd}}} \newcommand{\TeleoperationDownlinkTime}{T_{\text{downlink}}} \newcommand{\TeleoperationRoundTripLatency}{t_{\text{loop}}} \newcommand{\TeleoperationRoundTripTime}{T_{\text{RTT}}} \newcommand{\TeleoperationStateVisitationDistribution}{p^{\pi_{\text{teleop}}}} \newcommand{\TeleoperationUplinkTime}{T_{\text{uplink}}} \newcommand{\TeleoperationVideoLatency}{T_{\text{video}}} \newcommand{\TemperatureDualObjective}{\mathcal{L}} \newcommand{\TemperatureStepSize}{\lambda_{\alpha}} \newcommand{\TemplateSharedMemory}{M_{\text{template}}} \newcommand{\TemporalDifferenceResidual}{\delta} \newcommand{\TemporalEnsemblingWeight}{w_i} \newcommand{\TenantIndex}{i} \newcommand{\TenantResourceAllocation}{a_{i,r}} \newcommand{\TensorAxisCount}{n} \newcommand{\TensorColumnModeSize}{J} \newcommand{\TensorCoreAccumulatorMatrix}{\mathbf{C}_{\text{acc}}} \newcommand{\TensorCoreLeftInput}{\mathbf{A}_{\text{tc}}} \newcommand{\TensorCoreOutputMatrix}{\mathbf{D}_{\text{tc}}} \newcommand{\TensorCoreRightInput}{\mathbf{B}_{\text{tc}}} \newcommand{\TensorDepthModeSize}{T} \newcommand{\TensorElementCount}{N} \newcommand{\TensorModeIndex}{n_{\text{mode}}} \newcommand{\TensorParallelDegree}{N_{\text{TP}}} \newcommand{\TensorParallelLayerTime}{T_{\text{inference}}} \newcommand{\TensorRowModeSize}{I} \newcommand{\TerminalFeedbackGain}{\mathbf{K}_f} \newcommand{\TerminalInvariantSet}{\mathcal{X}_{f}} \newcommand{\TerminalPlantState}{\mathbf{x}_N} \newcommand{\TerminalTransitTime}{t_{\text{transit}}} \newcommand{\TerminalVoltageLimit}{V_{\max}} \newcommand{\TerminationProtocol}{\kappa} \newcommand{\TestExample}{z_{\text{test}}} \newcommand{\TestFamilySize}{k} \newcommand{\TestPhaseCapabilityGrant}{\Gamma_{\text{test}}} \newcommand{\TestsDirectoryShardGrant}{\Gamma_{a}} \newcommand{\TextTokenCount}{S_{\text{text}}} \newcommand{\TextTokenEmbeddings}{\mathbf{z}_{\text{text}}} \newcommand{\ThermalExpansionCoefficient}{\alpha} \newcommand{\ThermalPenaltyWeight}{\lambda_T} \newcommand{\ThermalPowerLimit}{P_{\text{thermal}}} \newcommand{\ThermalResistance}{R_{\text{th}}} \newcommand{\ThermalTimeConstant}{\tau_{\text{th}}} \newcommand{\ThirdAtomicGradientUpdate}{C} \newcommand{\ThirdFloatingPointAddend}{c} \newcommand{\ThirdRingTraceElement}{c} \newcommand{\ThresholdExceedanceCount}{N_u} \newcommand{\ThresholdExceedanceRate}{\zeta_u} \newcommand{\ThresholdExcess}{y} \newcommand{\ThresholdExcessVariable}{Y} \newcommand{\ThresholdedSparsityRatio}{\rho_{\text{sparse},\delta}} \newcommand{\ThrottleClearTemperature}{T_{\text{clear}}} \newcommand{\ThrottleOnsetJunctionTemperature}{T_{\text{j},\text{start}}} \newcommand{\ThrottleRecoveryTime}{t_{\text{recov}}} \newcommand{\ThrottleTripTemperature}{T_{\text{trip}}} \newcommand{\ThrottledClockFrequency}{f_{\text{throt}}} \newcommand{\TickCycleCount}{N} \newcommand{\TickIndex}{n} \newcommand{\TickPeriodJitterBound}{J_{\text{phase}}} \newcommand{\TieredRequestServiceTime}{T} \newcommand{\TightenedDiscreteSafeSet}{\mathcal{C}_{\text{discrete}}} \newcommand{\TileRowIndex}{m} \newcommand{\TiltAngle}{\theta_{\text{tilt}}} \newcommand{\Time}{T} \newcommand{\TimeBudgetUsedFraction}{\rho_T} \newcommand{\TimeInstant}{t} \newcommand{\TimeScaleSeparationRatio}{\epsilon} \newcommand{\TimeStepIndex}{t} \newcommand{\TimeToResult}{T_{\text{result}}} \newcommand{\TimeToTarget}{T_{\text{target}}} \newcommand{\TimeoutSafetyMultiplier}{k} \newcommand{\TimeoutTrialCount}{n_{\text{timeout}}} \newcommand{\TimerClockPeriod}{T_{\text{timer\_clk}}} \newcommand{\TimestampJitterDelay}{\delta_{\text{jitter}}} \newcommand{\TimestampQuantizationBound}{T_{\text{quant}}} \newcommand{\TimestampSkew}{t_{\text{skew}}} \newcommand{\TimingJitter}{\sigma_{\text{jitter}}} \newcommand{\TimingRealityGap}{\Delta_{\text{lat}}} \newcommand{\TokenAuthenticationCode}{\sigma} \newcommand{\TokenAveragedBatchLoss}{\mathcal{L}_{\text{token}}} \newcommand{\TokenBucketDepth}{b} \newcommand{\TokenBucketRefillRate}{r} \newcommand{\TokenBudgetUsedFraction}{\rho_N} \newcommand{\TokenByteDecoding}{s} \newcommand{\TokenCaveat}{c} \newcommand{\TokenDispatchTime}{T_{\text{dispatch}}} \newcommand{\TokenIdentifierSize}{s_{\text{id}}} \newcommand{\TokenIndex}{t} \newcommand{\TokenPrefix}{x_{<t}} \newcommand{\TokenVocabulary}{\mathcal{V}} \newcommand{\TokenizationTime}{T_{\text{tokenize}}} \newcommand{\ToleranceEllipsoidMatrix}{\mathbf{E}} \newcommand{\ToleratedFailureProbability}{\epsilon} \newcommand{\ToleratedPositionError}{\epsilon_{\text{pos}}} \newcommand{\TombstonedNodeSet}{V_{\text{tomb}}} \newcommand{\TombstonedRecordFraction}{\rho_{\text{dead}}} \newcommand{\ToolArgumentKey}{p} \newcommand{\ToolCallCategory}{y} \newcommand{\ToolCallCost}{c_{\text{tool}}} \newcommand{\ToolCallIndex}{i} \newcommand{\ToolCallReadSet}{R} \newcommand{\ToolCallWriteSet}{W} \newcommand{\ToolCartesianPose}{\mathbf{x}} \newcommand{\ToolCartesianVelocity}{\dot{\mathbf{x}}} \newcommand{\ToolCenterPointAxis}{\hat{\mathbf{z}}_{\text{TCP}}} \newcommand{\ToolCenterPointFrame}{\mathcal{F}_{\text{TCP}}} \newcommand{\ToolCenterPointPose}{\mathbf{T}_{\text{TCP}}} \newcommand{\ToolCenterPointPosition}{\mathbf{p}_{\text{TCP}}} \newcommand{\ToolClearanceDistance}{d_{\text{tool}}} \newcommand{\ToolDeclarationTokenCount}{S_{\text{tools}}} \newcommand{\ToolDescriptorSize}{S_{\text{desc}}} \newcommand{\ToolPlanarAbscissa}{x} \newcommand{\ToolPlanarOrdinate}{y} \newcommand{\ToolPositionError}{e_{\text{tool}}} \newcommand{\ToolServiceCount}{N_{\text{tool}}} \newcommand{\ToolSpeedLimit}{v_{\text{TCP}}} \newcommand{\ToolTargetState}{s} \newcommand{\ToolTime}{T_{\text{tool}}} \newcommand{\ToolTipPose}{\mathbf{T}_{\text{tool}}} \newcommand{\TopClassCount}{k} \newcommand{\TopMagnitudeIndicator}{\mathbf{1}_{|\mathbf{g}| \geq |\mathbf{g}|_{(K_{\text{top}})}}} \newcommand{\TopTokenSampleCount}{k} \newcommand{\TopologicalPlaceNode}{p^{\text{place}}} \newcommand{\TopologyEndpointCount}{N} \newcommand{\TorqueCutoffCommand}{\mathbf{u}_{\text{cutoff}}} \newcommand{\TorqueEffortPenaltyWeight}{\lambda_{\tau}} \newcommand{\TorqueProducingCurrent}{i_q} \newcommand{\TorqueRateLimit}{\dot{\tau}_{\max}} \newcommand{\TorqueRegularizationWeight}{w_\tau} \newcommand{\TorqueSlewPenaltyWeight}{\lambda_{\dot{\tau}}} \newcommand{\TorusFirstAxisChipCount}{X} \newcommand{\TorusSecondAxisChipCount}{Y} \newcommand{\TorusThirdAxisChipCount}{Z} \newcommand{\TotalChipPower}{P_{\text{total}}} \newcommand{\TotalCollisionQueryTime}{T_{\text{query\_total}}} \newcommand{\TotalDataCost}{C_{\text{total}}} \newcommand{\TotalDelayPhaseShift}{\phi_{\text{total}}} \newcommand{\TotalEnergy}{E_{\text{total}}} \newcommand{\TotalExecutedTrialCount}{N_{\text{total}}} \newcommand{\TotalFailureRecoveryTime}{T_{\text{recovery}}} \newcommand{\TotalGateCharge}{Q_g} \newcommand{\TotalInterventionCount}{N_{\text{int}}} \newcommand{\TotalKineticEnergy}{E_{k,\text{total}}} \newcommand{\TotalMemoryFootprint}{M_{\text{total}}} \newcommand{\TotalPipelineLatency}{L_{\text{lat,total}}} \newcommand{\TotalTrainingRunCost}{C_{\text{total}}} \newcommand{\TraceCrashCount}{N_{\text{crash}}} \newcommand{\TraceCrashIndex}{i} \newcommand{\TraceDecay}{\lambda} \newcommand{\TraceIntermediateAdjoint}{\bar{v}} \newcommand{\TraceIntermediateTangent}{\dot{v}} \newcommand{\TraceIntermediateVariable}{v} \newcommand{\TrackIndex}{i} \newcommand{\TrackLastUpdateTime}{t_{\text{last}}} \newcommand{\TrackLossTimeout}{T_{\text{lost}}} \newcommand{\TrackPositionDeviation}{\sigma_{\text{track}}} \newcommand{\TrackPredictedErrorCovariance}{\mathbf{P}_{t|t-1}} \newcommand{\TrackPredictedStateEstimate}{\hat{\mathbf{x}}_{t|t-1}} \newcommand{\TrackedEvidenceHorizon}{\tau_{\text{ev,tracked}}} \newcommand{\TrackerFrameIndex}{t} \newcommand{\TrackingErrorAcceleration}{\ddot{\mathbf{e}}} \newcommand{\TrackingErrorAllowance}{\epsilon_{\text{pos}}} \newcommand{\TrackingErrorBound}{\epsilon_{\text{track}}} \newcommand{\TrackingErrorDistance}{e} \newcommand{\TrackingErrorRate}{\dot{\mathbf{e}}} \newcommand{\TrackingErrorVector}{\mathbf{e}} \newcommand{\TrackingRelaxationSlack}{\delta} \newcommand{\TrackingSlackPenaltyWeight}{p} \newcommand{\TrackingStartInstant}{t_{\text{start}}} \newcommand{\TractionLimitedDeceleration}{a} \newcommand{\TractiveForce}{F_x} \newcommand{\TrainableStateMemory}{M_{\text{train}}} \newcommand{\TrainerUpdateTime}{T_{\text{train}}} \newcommand{\TrainingCompute}{O_{\text{train}}} \newcommand{\TrainingCost}{C_{\text{train}}} \newcommand{\TrainingDataset}{D} \newcommand{\TrainingDistribution}{P_0} \newcommand{\TrainingEmpiricalCdf}{F_{P_0}} \newcommand{\TrainingExample}{z} \newcommand{\TrainingFailureCount}{N_{\text{failures}}} \newcommand{\TrainingFeatureMean}{\mu} \newcommand{\TrainingFeatureStandardDeviation}{\sigma} \newcommand{\TrainingLabelMask}{\mathcal{M}_{\text{train}}} \newcommand{\TrainingLoss}{\mathcal{L}_{\text{train}}} \newcommand{\TrainingPathPredictor}{f_{\text{train}}} \newcommand{\TrainingPipelineFunction}{f} \newcommand{\TrainingRunCount}{N_{\text{runs}}} \newcommand{\TrainingSampleThroughput}{R_{\text{train}}} \newcommand{\TrainingSchemaKeySet}{\mathcal{K}_{\text{train}}} \newcommand{\TrainingServingSkew}{S_{\text{skew}}} \newcommand{\TrainingSplitFraction}{f_{\text{train}}} \newcommand{\TrainingStepCount}{K} \newcommand{\TrainingStepEnergy}{E_{\text{step}}} \newcommand{\TrainingStepOperations}{O_{\text{step}}} \newcommand{\TrainingStepTime}{T_{\text{step}}} \newcommand{\TrainingThroughput}{R_{\text{training}}} \newcommand{\TrainingTime}{T_{\text{train}}} \newcommand{\TrainingTransformFunction}{f_{\text{train}}} \newcommand{\Trajectory}{\tau} \newcommand{\TrajectoryAction}{a} \newcommand{\TrajectoryAdmissionRate}{\lambda_{\text{traj}}} \newcommand{\TrajectoryBudget}{\mathbf{B}} \newcommand{\TrajectoryCallCount}{N_{\text{call}}} \newcommand{\TrajectoryCategoryIndex}{j} \newcommand{\TrajectoryCheckpointCount}{N_{\text{ckpt}}} \newcommand{\TrajectoryDivergenceResidual}{e_{\text{div}}} \newcommand{\TrajectoryDuration}{T_{\text{traj}}} \newcommand{\TrajectoryGoodput}{\mathcal{G}} \newcommand{\TrajectoryObservation}{o} \newcommand{\TrajectoryOptimizationObjective}{\mathcal{U}} \newcommand{\TrajectoryRecordDuration}{T_{\text{record}}} \newcommand{\TrajectoryRecordFrame}{\mathcal{F}} \newcommand{\TrajectoryReturn}{R} \newcommand{\TrajectoryReward}{R} \newcommand{\TrajectorySampleCount}{N} \newcommand{\TrajectoryState}{s} \newcommand{\TrajectoryStateSpace}{\mathcal{S}} \newcommand{\TrajectoryTimeLimit}{T_{\max}} \newcommand{\TrajectoryTokenCost}{C_{\text{session}}} \newcommand{\TrajectoryTokenLimit}{N_{\max}} \newcommand{\TrajectoryTurnLimit}{H_{\max}} \newcommand{\TransceiverDelay}{t_{\text{transceiver}}} \newcommand{\TransductionInstant}{t_{\text{transduction}}} \newcommand{\TransferBufferCount}{N_{\text{transfer}}} \newcommand{\TransferDiscrepancyBound}{\epsilon_{\text{gap}}} \newcommand{\TransferTimeForPayload}{T_{\text{transfer}}} \newcommand{\TransferredDataVolume}{D_{\text{vol,transfer}}} \newcommand{\TransformGraph}{\mathcal{G}} \newcommand{\TransformGraphEdgeSet}{\mathcal{E}} \newcommand{\TransformGraphFrame}{\mathcal{F}} \newcommand{\TransformGraphVertexSet}{\mathcal{V}} \newcommand{\TransformRotationBlock}{\mathbf{R}_{AB}} \newcommand{\TransformTranslationBlock}{\mathbf{t}_{AB}} \newcommand{\TransformationInputCount}{k} \newcommand{\TransformedCartesianPosition}{\mathbf{p}'} \newcommand{\TransformedHomogeneousPointCoordinates}{\tilde{\mathbf{p}}'} \newcommand{\TransistorThresholdVoltage}{V_{\text{th}}} \newcommand{\TransitionStorageSize}{b_{\text{tr}}} \newcommand{\TranslationComponent}{v} \newcommand{\TranslationVector}{\mathbf{v}} \newcommand{\TranslationalDriftError}{e_{\text{trans}}} \newcommand{\TranslationalJerk}{j} \newcommand{\TranslationalKineticEnergy}{E_{k,\text{trans}}} \newcommand{\TransmissionEnergyPerByte}{E_{\text{tx}}} \newcommand{\TransmissionInputInertia}{J_{\text{in}}} \newcommand{\TransmissionTorsionalStiffness}{K_{\text{joint}}} \newcommand{\TransverseStandardDeviation}{\sigma_\perp} \newcommand{\TravelPosition}{x} \newcommand{\TraverseDistance}{d} \newcommand{\TreatedNeighborFraction}{e} \newcommand{\TreatmentAssignment}{w} \newcommand{\TreatmentConversionRate}{\hat{p}_B} \newcommand{\TreatmentSampleSize}{m_B} \newcommand{\TreeAllReduceCompletionTime}{T_{\text{tree}}} \newcommand{\TreeLikeAllReduceTime}{T_{\text{tree-like}}} \newcommand{\TreeSearchExplorationWeight}{c_{\text{explore}}} \newcommand{\TreeSearchLeafScore}{V} \newcommand{\TreeSearchMeanReturn}{Q} \newcommand{\TreeSearchPriorDistribution}{p_{\text{prior}}} \newcommand{\TreeSearchVisitCount}{N_{\text{visit}}} \newcommand{\TrialCampaignWallTime}{T_{\text{wall}}} \newcommand{\TrialCompletionIndicator}{Y} \newcommand{\TrialCondition}{c} \newcommand{\TrialControlStepCount}{N_{\text{steps}, i}} \newcommand{\TrialCount}{N} \newcommand{\TrialFailureIndicator}{x} \newcommand{\TrialFailureProbability}{p_{\text{fail}}} \newcommand{\TrialIndex}{n} \newcommand{\TrialInterventionCount}{n_{\text{int}}} \newcommand{\TrialLoadReversalCount}{n_{\text{rev}}} \newcommand{\TrialPassProbability}{p_{\text{trial}}} \newcommand{\TrialPathDistance}{d} \newcommand{\TrialResetLatency}{T_{\text{reset}}} \newcommand{\TrialResetTime}{t_{\text{reset}}} \newcommand{\TrialRolloutTime}{t_{\text{rollout}}} \newcommand{\TrialRunTime}{t_{\text{run}}} \newcommand{\TrialSuccessProbability}{p} \newcommand{\TriggeredWindowArrivalCount}{Q_{\text{arr}}} \newcommand{\TrueClearance}{C_{\text{true}}} \newcommand{\TrueLabelComponent}{y} \newcommand{\TrueOutcome}{Y} \newcommand{\TrueOutcomeLevel}{v} \newcommand{\TrueReferentScore}{c_{y_j}} \newcommand{\TruncatedDistanceSample}{d_{\mu}} \newcommand{\TruncatedKeyApproximation}{\hat{\mathbf{K}}_r} \newcommand{\TruncatedKeyLeftSingularMatrix}{\mathbf{U}_r} \newcommand{\TruncatedKeyRightSingularMatrix}{\mathbf{V}_r} \newcommand{\TruncatedKeySpectrumMatrix}{\mathbf{\Sigma}_r} \newcommand{\TruncationBandVolume}{V_{\text{band}}} \newcommand{\TruncationRank}{r} \newcommand{\TruthInstrumentSet}{\mathcal{I}_{\text{truth}}} \newcommand{\TsdfAccumulatedDistance}{D} \newcommand{\TsdfAccumulatedWeight}{W} \newcommand{\TsdfObservationWeight}{w} \newcommand{\TsdfTruncationBand}{\mu_{\text{tsdf}}} \newcommand{\TsdfWeightCap}{W_{\max}} \newcommand{\TuckerCoreTensor}{\mathcal{G}} \newcommand{\TurnAppendLength}{\Delta S_{\text{turn}}} \newcommand{\TurnBoundaryDelay}{t_{\text{boundary}}} \newcommand{\TurnBudgetUsedFraction}{\rho_H} \newcommand{\TurnContext}{c} \newcommand{\TurnContributionDeviationBound}{\sigma} \newcommand{\TurnCovarianceBoundScale}{C} \newcommand{\TurnCovarianceDecayRatio}{\alpha_{\text{corr}}} \newcommand{\TurnFailureRate}{\lambda_{\text{fail}}} \newcommand{\TurnGeneratedTokenCount}{n_{\text{gen}}} \newcommand{\TurnHorizon}{H} \newcommand{\TurnIndex}{t} \newcommand{\TurnInputTokenCost}{C_{\text{in}}} \newcommand{\TurnOffGateCurrent}{I_{g,\text{off}}} \newcommand{\TurnOffGateResistance}{R_{g,\text{off}}} \newcommand{\TurnOnGateResistance}{R_{g,\text{on}}} \newcommand{\TurnOutputTokenCost}{C_{\text{out}}} \newcommand{\TurnPayloadProbability}{q_{\text{turn}}} \newcommand{\TurnReadCount}{r} \newcommand{\TurnReconstructionTime}{T_{\text{recon}}} \newcommand{\TurnReexecutionTime}{T_{\text{exec}}} \newcommand{\TurnReward}{r} \newcommand{\TurnSandboxCost}{C_{\text{sandbox}}} \newcommand{\TurnStateGrowth}{s_{\text{turn}}} \newcommand{\TurnToolFeeCost}{C_{\text{tools}}} \newcommand{\TustinEigenvalue}{\lambda_{\text{Tustin}}} \newcommand{\TustinTransitionMatrix}{\mathbf{A}_{\text{Tustin}}} \newcommand{\TwinCriticReturnEstimate}{Q_{\phi_i}} \newcommand{\TwistCoordinates}{\boldsymbol{\xi}} \newcommand{\TwistCovarianceMatrix}{\boldsymbol{\Sigma}_{\boldsymbol{\xi}}} \newcommand{\TwistMatrix}{\hat{\boldsymbol{\xi}}} \newcommand{\TwistRotationAngle}{\theta_{\text{rot}}} \newcommand{\TwistRotationCoordinates}{\boldsymbol{\omega}} \newcommand{\TwistTranslationMatrix}{\mathbf{V}} \newcommand{\TwistWedgeOperator}{\wedge} \newcommand{\UnacceptedTaskMeanCost}{C_{\text{fail}}} \newcommand{\UnassistedCompletionCount}{N_{\text{unassisted}}} \newcommand{\UnassistedSuccessIndicator}{A} \newcommand{\UnbiasedAngularBrakingDeceleration}{\alpha_{\text{nom}}} \newcommand{\UnbrakedImpactForce}{F_{\text{unbraked}}} \newcommand{\UncachedInputTokenCount}{n_{\text{in}}} \newcommand{\UncachedPromptLength}{S_{\text{new}}} \newcommand{\UncertainScenarioParameters}{x} \newcommand{\UnconstrainedCallLatency}{T_{\text{free}}} \newcommand{\UnconstrainedParseFailureRate}{p_{\text{err}}} \newcommand{\UndampedNaturalFrequency}{\omega_n} \newcommand{\UnfoldedConvolutionOutput}{\mathbf{Y}_{\text{col}}} \newcommand{\UnfoldedPatchMatrix}{\mathbf{X}_{\text{col}}} \newcommand{\UniformDistribution}{\mathcal{U}} \newcommand{\UniformLoopTurnCost}{C_{\text{turn}}} \newcommand{\UnitAliasMultiplier}{k} \newcommand{\UnitImpulseFunction}{\delta} \newcommand{\UnitQuaternion}{\mathbf{q}_{\text{quat}}} \newcommand{\UnitQuaternionScalarComponent}{q_w} \newcommand{\UnitQuaternionSphere}{S^3} \newcommand{\UnitQuaternionXComponent}{q_x} \newcommand{\UnitQuaternionYComponent}{q_y} \newcommand{\UnitQuaternionZComponent}{q_z} \newcommand{\UnitTemperatureProbabilityVector}{\mathbf{p}_{\tau_{\text{temp}}=1}} \newcommand{\UnlabeledPool}{U} \newcommand{\UnloadedTickExecutionTime}{t_{\text{unloaded}}} \newcommand{\UnmitigatedHardwareFaultRate}{\lambda_{\text{unmitigated}}} \newcommand{\UnmodeledCommandPathDelay}{\Delta t_{\text{bus}}} \newcommand{\UnobservableForceOffset}{\Delta} \newcommand{\UnobservedUnknownSpace}{\mathcal{M}_{\text{unknown}}} \newcommand{\UnprojectionJacobian}{\mathbf{J}_{\text{unproj}}} \newcommand{\UnrecoverableDamageCost}{C_{\text{blast}}} \newcommand{\UnreservedStopDelay}{\delta} \newcommand{\UnscaledAttentionScoreMatrix}{\mathbf{A}} \newcommand{\UnshardedLocalExecutionTime}{T_{\text{compute}}} \newcommand{\UnsquashedLatentAction}{\mathbf{u}} \newcommand{\UntilPrefixTime}{t''} \newcommand{\UntrackedEvidenceHorizon}{\tau_{\text{ev,untracked}}} \newcommand{\UpdatedErrorCovariance}{\mathbf{P}_{k|k}} \newcommand{\UpdatedModelParameters}{\theta_{\text{new}}} \newcommand{\UpdatedParameterSubset}{\theta_{\text{updated}}} \newcommand{\UpdatedSoftmaxRunningMaximum}{m'} \newcommand{\UpdatedStateEstimate}{\hat{\mathbf{x}}_{k|k}} \newcommand{\UpperRatioClippingWidth}{\epsilon_{\text{high}}} \newcommand{\UprightPosition}{\mathbf{p}_{\text{upright}}} \newcommand{\UprightRange}{r} \newcommand{\UpstreamGradientElement}{\bar{y}} \newcommand{\UpstreamGradientVector}{\mathbf{v}} \newcommand{\UpstreamStageLatency}{X} \newcommand{\UsableDemonstrationYield}{Y_{\text{usable}}} \newcommand{\UsefulAcceleratorHourCost}{C_{\text{useful}}} \newcommand{\UsefulComputeFraction}{f_{\text{compute}}} \newcommand{\UsefulModelFlops}{O_{\text{useful}}} \newcommand{\UsefulStepCount}{N} \newcommand{\UsefulTrainingTime}{T_{\text{useful}}} \newcommand{\UserConnectionSet}{\mathcal{N}} \newcommand{\UserSpaceSetupTime}{T_{\text{user}}} \newcommand{\UvloThresholdVoltage}{V_{\text{UVLO}}} \newcommand{\VacuumLightSpeed}{c} \newcommand{\ValidCandidateRate}{p_{\text{valid}}} \newcommand{\ValidTokenSet}{\mathcal{V}_{\text{valid}}} \newcommand{\ValidatedMotionDuration}{T_{\text{yield}}} \newcommand{\ValidatedProposalEvent}{e_{\text{prop}}} \newcommand{\ValidationDataset}{\mathcal{D}_{\text{val}}} \newcommand{\ValidationGateThreshold}{\gamma_{\text{gate}}} \newcommand{\ValidationLoss}{\mathcal{L}_{\text{val}}} \newcommand{\VanishingTimeOffset}{\epsilon} \newcommand{\VariationalDistribution}{q_\phi} \newcommand{\VariationalParameters}{\phi} \newcommand{\VectorAngle}{\phi} \newcommand{\VectorElementCount}{N_{\text{vec}}} \newcommand{\Velocity}{\mathbf{v}} \newcommand{\VelocitySaturationExponent}{\alpha} \newcommand{\VerificationCheckCost}{C_{\text{ver}}} \newcommand{\VerificationCheckCount}{K} \newcommand{\VerificationPoolCapacity}{\mu_{\text{verify}}} \newcommand{\VerificationScheduleCost}{C} \newcommand{\VerificationTrialCount}{n_{\text{trial}}} \newcommand{\VerificationTrialIndex}{j} \newcommand{\VerificationTrialTime}{T_{\text{trial}}} \newcommand{\VerifiedDemonstrationDataset}{\mathcal{D}_{\text{verified}}} \newcommand{\VerifierFalseAcceptanceRate}{\epsilon_{\text{FA}}} \newcommand{\VerifierFalseRejectionRate}{\epsilon_{\text{FR}}} \newcommand{\VerifierPassProbability}{q} \newcommand{\VerifierPrecision}{\Pi_{V}} \newcommand{\VerifierTimeout}{T_{\text{out}}} \newcommand{\VerifierTrueAcceptanceRate}{u} \newcommand{\VerifierVerdict}{V} \newcommand{\VersionSkewBound}{k_{\text{skew}}} \newcommand{\VertexSlotTime}{d} \newcommand{\VerticalFocalLength}{f_y} \newcommand{\VibrationFrequency}{f_{\text{vib}}} \newcommand{\VirtualAccelerationCommand}{\ddot{\mathbf{q}}^*} \newcommand{\VirtualDampingMatrix}{\mathbf{D}_{\text{virt}}} \newcommand{\VirtualPipelineStagesPerDevice}{V} \newcommand{\ViscousDampingMatrix}{\mathbf{D}} \newcommand{\VisionBackboneTime}{t_{\text{backbone}}} \newcommand{\VisionTokenEmbeddings}{\mathbf{z}_{\text{vision}}} \newcommand{\VisualConditioningEmbedding}{\mathbf{E}} \newcommand{\VisualEncodingTime}{t_{\text{vis}}} \newcommand{\VitImagePatch}{\mathbf{x}_p} \newcommand{\VitPatchProjectionWeights}{\mathbf{W}_{\text{patch}}} \newcommand{\VitPatchSize}{p_{\text{patch}}} \newcommand{\VitPatchTokenEmbedding}{\mathbf{z}} \newcommand{\VocabularyToken}{v} \newcommand{\VocabularyTokenLogit}{o} \newcommand{\VolumetricFlowRate}{\dot{V}} \newcommand{\VoxelBlockCoordinate}{\mathbf{b}} \newcommand{\VoxelBlockEdgeLength}{L_{\text{blk}}} \newcommand{\VoxelCenterPosition}{\mathbf{p}_{\text{vox}}} \newcommand{\VoxelIndex}{i} \newcommand{\VoxelOccupancyState}{m} \newcommand{\VoxelPitch}{r} \newcommand{\VoxelStorageSize}{s_{\text{voxel}}} \newcommand{\VoxelUpdateTraffic}{s_{\text{rw}}} \newcommand{\WarmupEpochCount}{N_{\text{warmup}}} \newcommand{\WarmupStepCount}{W} \newcommand{\WatchdogClockFrequency}{f_{\text{wdg}}} \newcommand{\WatchdogCounterReading}{W} \newcommand{\WatchdogEarliestServiceTime}{T_{\text{lower}}} \newcommand{\WatchdogLatestServiceTime}{T_{\text{upper}}} \newcommand{\WatchdogLowerWindowCount}{W_{\text{lower}}} \newcommand{\WatchdogReloadCount}{W_{\text{init}}} \newcommand{\WatchdogServiceTime}{t_{\text{service}}} \newcommand{\WatchdogToken}{T} \newcommand{\WatchdogUpperWindowCount}{W_{\text{upper}}} \newcommand{\WaveImpedance}{b} \newcommand{\WeightElementStorageSize}{s_{\text{elem,W}}} \newcommand{\WeightMatrix}{\mathbf{W}} \newcommand{\WeightMatrixColumnCount}{n} \newcommand{\WeightMatrixEntry}{W_{ij}} \newcommand{\WeightMatrixRowCount}{m} \newcommand{\WeightMemory}{M_{\text{weights}}} \newcommand{\WeightOnlyStepTime}{t} \newcommand{\WeightPenaltyStrength}{\lambda_{\text{reg}}} \newcommand{\WeightQuantizationScale}{s_W} \newcommand{\WeightRangeBound}{W_{\text{max}}} \newcommand{\WeightStreamingDecodeTime}{T_{\text{decode}}} \newcommand{\WeightVector}{\mathbf{w}} \newcommand{\WeightedNormArgument}{\mathbf{z}} \newcommand{\WheelAngularSpeed}{\omega} \newcommand{\WheelDiameter}{D_{\text{wheel}}} \newcommand{\WheelInertia}{J_{\text{wheel}}} \newcommand{\WheelNormalLoad}{F_z} \newcommand{\WheelRadius}{r} \newcommand{\WheelRevolutionCount}{N_{\text{rev}}} \newcommand{\WheelTrackWidth}{b} \newcommand{\WhiteNoiseProcess}{\mathcal{WN}} \newcommand{\WholeBodyDecisionVariables}{\mathbf{z}} \newcommand{\WholeRepositoryShardGrant}{\Gamma_{b}} \newcommand{\WidthMultiplier}{w_{\text{mult}}} \newcommand{\WidthScalingRatio}{\beta} \newcommand{\WilsonIntervalCenter}{\tilde{p}} \newcommand{\WindingCoreThermalResistance}{R_{\text{th,wc}}} \newcommand{\WindingCurrent}{I} \newcommand{\WindingJouleHeat}{E_{\text{thermal}}} \newcommand{\WindingLossPower}{P_{\text{loss}}} \newcommand{\WindingTemperature}{T_{\text{winding}}} \newcommand{\WindingTemperatureLimit}{T_{\text{limit}}} \newcommand{\WindingTerminalVoltage}{V_{\text{terminal}}} \newcommand{\WindingThermalCapacitance}{C_{\text{wind}}} \newcommand{\WindowArrivalCount}{k} \newcommand{\WindowArrivalOffset}{t} \newcommand{\WindowSpendingLimit}{C_{\text{win}}} \newcommand{\WithinTaskRunStandardDeviation}{\sigma_{\text{run}}} \newcommand{\WorkedTraceProduct}{c} \newcommand{\WorkedTraceProductAdjoint}{\bar{c}} \newcommand{\WorkedTraceSine}{b} \newcommand{\WorkedTraceSineAdjoint}{\bar{b}} \newcommand{\WorkedTraceSquare}{a} \newcommand{\WorkedTraceSquareAdjoint}{\bar{a}} \newcommand{\WorkerBaseCommitHash}{h_{\text{base}}} \newcommand{\WorkerCandidateCommitHash}{h_{\text{worker}}} \newcommand{\WorkerCompletionDistribution}{F} \newcommand{\WorkerCompletionTime}{T} \newcommand{\WorkerCount}{N_{\text{workers}}} \newcommand{\WorkerDelayProbability}{p} \newcommand{\WorkerIndex}{k} \newcommand{\WorkerMinibatch}{B} \newcommand{\WorkerOverheadSlope}{\gamma} \newcommand{\WorkerTransformTime}{T_{\text{transform}}} \newcommand{\WorkerWrittenFileCount}{w} \newcommand{\WorkloadMeanOutputLength}{\mu} \newcommand{\WorkloadRequestIndex}{i} \newcommand{\WorkspaceExtentX}{L_x} \newcommand{\WorkspaceExtentY}{L_y} \newcommand{\WorkspaceExtentZ}{L_z} \newcommand{\WorkspaceRestoreTime}{T_{\text{ws}}} \newcommand{\WorkspaceVolume}{V_{\text{ws}}} \newcommand{\WorldBaseTransform}{\mathbf{T}_{WB}} \newcommand{\WorldBodyTransform}{\mathbf{T}_{wb}} \newcommand{\WorldFramePoint}{\mathbf{p}_{\text{world}}} \newcommand{\WorldLidarTransform}{\mathbf{T}_{wl}} \newcommand{\WorldMapTransform}{\mathbf{T}_{\text{world}}^{\text{map}}} \newcommand{\WorldPointCovariance}{\boldsymbol{\Sigma}_{\text{world}}} \newcommand{\WorldReferenceFrame}{\mathcal{F}_W} \newcommand{\WorldStateSpace}{\mathcal{S}} \newcommand{\WorldToCameraRotation}{\mathbf{R}_{CW}} \newcommand{\WorldToCameraTransform}{\mathbf{T}_{CW}} \newcommand{\WorldToCameraTranslation}{\mathbf{t}_{CW}} \newcommand{\WornPlantTransitionDistribution}{p_{n \gg 1}} \newcommand{\WorseArmSuccessProbability}{p_{\text{low}}} \newcommand{\WorstCaseExecutionTime}{C} \newcommand{\WorstCaseInterruptLatency}{t_{\text{irq,lat}}} \newcommand{\WorstCasePermissionCycleTime}{T_{\text{exec}}} \newcommand{\WorstCaseResponseTime}{R} \newcommand{\WristAngularVelocity}{\boldsymbol{\omega}_{\text{wrist}}} \newcommand{\WristCameraEmbedding}{\mathbf{e}_{\text{wrist}}} \newcommand{\WristLinearVelocity}{\mathbf{v}_{\text{wrist}}} \newcommand{\WristObjectTransform}{\mathbf{T}_{\text{wrist} \leftarrow \text{object}}} \newcommand{\WristSkewDisplacement}{\Delta \mathbf{p}_{\text{skew}}} \newcommand{\XAxisAngularRate}{\omega_x} \newcommand{\XAxisRotationCoordinate}{\omega_x} \newcommand{\XForceCeiling}{F_x} \newcommand{\XPositionErrorEnvelope}{e_x} \newcommand{\XTaskToleranceSemiAxis}{r_x} \newcommand{\XTorqueCeiling}{\tau_x} \newcommand{\YAxisAngularRate}{\omega_y} \newcommand{\YAxisRotationCoordinate}{\omega_y} \newcommand{\YForceCeiling}{F_y} \newcommand{\YPositionErrorEnvelope}{e_y} \newcommand{\YTaskToleranceSemiAxis}{r_y} \newcommand{\YTorqueCeiling}{\tau_y} \newcommand{\YawRate}{\omega_z} \newcommand{\YoshikawaManipulability}{w} \newcommand{\ZAxisRotationCoordinate}{\omega_z} \newcommand{\ZForceCeiling}{F_z} \newcommand{\ZPositionErrorEnvelope}{e_z} \newcommand{\ZTaskToleranceSemiAxis}{r_z} \newcommand{\ZTorqueCeiling}{\tau_z} \newcommand{\ZTransformVariable}{z} \newcommand{\ZeroEntryIndicator}{\mathbf{1}_{\{(\mathbf{W}_{\text{sparse}})_{ij} = 0\}}} \newcommand{\ZeroFailureTrialCount}{n} \newcommand{\ZeroFailureUpperConfidenceLimit}{p_{\text{fail, upper}}^{95\%}} \newcommand{\ZeroMatrix}{\mathbf{0}} \newcommand{\ZeroMomentPoint}{\mathbf{p}_{\text{ZMP}}} \newcommand{\ZeroVector}{\mathbf{0}} \newcommand{\ZohHoldTravel}{d_{\text{ZOH}}} \newcommand{\ZohPhaseShift}{\phi_{\text{ZOH}}} \newcommand{\ZohTransportDelay}{\tau_{\text{ZOH}}} \newcommand{\AuthorityLevels}{\AuthorityExposureLevel} \newcommand{\BreakEvenTaskVolume}{\BreakEvenTaskCount} \newcommand{\PertokenPricesCache}{\CachedInputTokenPrice} \newcommand{\ContentionAndCoherencyCoefficientsTwo}{\CoherencyCoefficient} \newcommand{\CoherencyContentionCoefficient}{\CoherencyCoefficient} \newcommand{\TaskDeadline}{\CompletionDeadline} \newcommand{\Deadline}{\CompletionDeadline} \newcommand{\Confidentiality}{\ConfidentialityLabel} \newcommand{\ContentionAndCoherencyCoefficients}{\ContentionCoefficient} \newcommand{\CostPerAcceptedTaskEff}{\CostPerAcceptedTask} \newcommand{\DuplicateeffectProbability}{\DuplicateEffectProbability} \newcommand{\EstimatedAdvantageK}{\EstimatedHistoryAdvantage} \newcommand{\EstimatedValueK}{\EstimatedRemainingReturn} \newcommand{\ExpectedIrreversibleLossA}{\ExpectedIrreversibleLoss} \newcommand{\PertokenPricesIn}{\InputTokenPrice} \newcommand{\CohensKappa}{\InterAnnotatorAgreement} \newcommand{\KvBlockSizeBlk}{\KvBlockSize} \newcommand{\MaskedFinetuningLossSft}{\MaskedFinetuningLoss} \newcommand{\ValidityIntervalOfAMemoryEntryBirth}{\MemoryEntryBirthGeneration} \newcommand{\ValidityIntervalOfAMemoryEntryDeath}{\MemoryEntryDeathGeneration} \newcommand{\MemoryHeldDuringAWait}{\MemoryHoldDuringWait} \newcommand{\OptimalCheckpointIntervalCkpt}{\OptimalCheckpointInterval} \newcommand{\PertokenPricesOut}{\OutputTokenPrice} \newcommand{\PertokenDecodeTime}{\PerTokenDecodeTime} \newcommand{\TokenLossMask}{\PositionLossMask} \newcommand{\LossMaskT}{\PositionLossMask} \newcommand{\ValidityIntervalOfAMemoryEntryQ}{\QueryWorkspaceGeneration} \newcommand{\RequestAndReplylossProbabilitiesTwo}{\ReplyLossProbability} \newcommand{\RequestAndReplylossProbabilities}{\RequestLossProbability} \newcommand{\EnvironmentStateK}{\RolloutEnvironmentState} \newcommand{\StalesupportRate}{\StaleSupportRate} \newcommand{\StateLevels}{\StateExposureLevel} \newcommand{\GoalContract}{\TaskContractGoal} \newcommand{\Environment}{\TaskEnvironment} \newcommand{\Vocabulary}{\TokenVocabulary} \newcommand{\ActionProposal}{\TrajectoryAction} \newcommand{\ConcurrentTrajectoriesTwo}{\TrajectoryAdmissionRate} \newcommand{\ActionObservation}{\TrajectoryObservation} \newcommand{\Observation}{\TrajectoryObservation} \newcommand{\StateAtTurn}{\TrajectoryState} \newcommand{\PerturnAppend}{\TurnAppendLength} \newcommand{\Context}{\TurnContext} \newcommand{\Horizon}{\TurnHorizon} \newcommand{\VerifierFalseacceptance}{\VerifierFalseAcceptanceRate} \newcommand{\VerifierFalseacceptanceFr}{\VerifierFalseRejectionRate} \newcommand{\WorkerCountWorkers}{\WorkerCount} \newcommand{\AllocationHoldTime}{\AllocatedWallTime} \newcommand{\CheckpointIntervalCkpt}{\CheckpointInterval} \newcommand{\AcceleratorsPerNodeNodes}{\ClusterNodeCount} \newcommand{\CommunicationcomputationRatio}{\CommunicationComputeRatio} \newcommand{\PercomponentFailureRate}{\ComponentFailureRate} \newcommand{\Correlation}{\CorrelationCoefficient} \newcommand{\DataparallelDegreeDp}{\DataParallelDegree} \newcommand{\NumberOfDevices}{\DeviceCount} \newcommand{\TypeIAndTypeIiErrorRatesStat}{\HypothesisTestFalseNegativeRate} \newcommand{\TypeIAndTypeIiErrorRatesSig}{\HypothesisTestSignificanceLevel} \newcommand{\DollarCostInfer}{\InferenceCost} \newcommand{\KvcacheBytesPerToken}{\KvCacheBytesPerToken} \newcommand{\KvcacheMemory}{\KvCacheMemory} \newcommand{\CrossoverPoint}{\LatencyBandwidthCrossoverSize} \newcommand{\LoggpLongmessageTime}{\LoggpLongMessageTime} \newcommand{\LogploggpNetworkLatency}{\LogpNetworkLatency} \newcommand{\LongmessageGapPerByte}{\LongMessageGapPerByte} \newcommand{\MeanTimeBetweenFailuresThree}{\MeanTimeBetweenFailures} \newcommand{\PermessageLatency}{\MessageStartupLatency} \newcommand{\NdeviceTime}{\MultiDeviceRunTime} \newcommand{\PipelineparallelDegreePp}{\PipelineParallelDegree} \newcommand{\MlProductivityGoodputFactorsProgram}{\ProgramGoodput} \newcommand{\ReceiverOverheadRecv}{\ReceiverOverhead} \newcommand{\CollectiveCompletionTimeRing}{\RingAllReduceCompletionTime} \newcommand{\RingtreeCrossoverPayload}{\RingTreeCrossoverPayload} \newcommand{\MlProductivityGoodputFactorsRuntime}{\RuntimeGoodput} \newcommand{\GoodputRatio}{\RuntimeGoodput} \newcommand{\ScalingExponentScale}{\ScalingExponent} \newcommand{\MlProductivityGoodputFactorsScheduling}{\SchedulingGoodput} \newcommand{\SingledeviceTimeOne}{\SingleDeviceRunTime} \newcommand{\ReliabilityFunctionSystem}{\SystemReliability} \newcommand{\TensorparallelDegreeTp}{\TensorParallelDegree} \newcommand{\SmallConstant}{\ToleratedFailureProbability} \newcommand{\DollarCostTrain}{\TrainingCost} \newcommand{\CollectiveCompletionTimeTree}{\TreeAllReduceCompletionTime} \newcommand{\UsefulComputetimeFraction}{\UsefulComputeFraction} \newcommand{\AccuracyAtTime}{\AccuracyAfterDeployment} \newcommand{\NumberOfAttentionHeads}{\AttentionHeadCount} \newcommand{\Distribution}{\InputDistribution} \newcommand{\NumberOfKeyValueHeads}{\KvHeadCount} \newcommand{\NumberOfKeyvalueHeadsKv}{\KvHeadCount} \newcommand{\NumberOfLayers}{\LayerCount} \newcommand{\LayerInputAndOutputWidths}{\LayerInputWidth} \newcommand{\LayerInputAndOutputWidthsTwo}{\LayerOutputWidth} \newcommand{\Gradient}{\LossGradient} \newcommand{\TrainingDistributionZero}{\TrainingDistribution} \newcommand{\AcceleratorCountGpu}{\AcceleratorCount} \newcommand{\ActivationMemoryActivations}{\ActivationMemory} \newcommand{\BatchServiceTimeSvc}{\BatchServiceTime} \newcommand{\EnergyPerOperationCompute}{\EnergyPerOperation} \newcommand{\GradientMemoryGradients}{\GradientMemory} \newcommand{\IronlawTermTimesCompute}{\IronLawComputeTime} \newcommand{\SingleDeviceComputeTime}{\IronLawComputeTime} \newcommand{\IronlawTermTimesMemory}{\IronLawMemoryTime} \newcommand{\LossscaleFactor}{\LossScaleFactor} \newcommand{\OptimizerstateMemory}{\OptimizerStateMemory} \newcommand{\RequestTimeInSystemLat}{\RequestTimeInSystem} \newcommand{\StoragePricePerByteTime}{\StorageCapacityPrice} \newcommand{\WeightMemoryWeights}{\WeightMemory} \newcommand{\WindingAndAmbientTemperatureTwo}{\AmbientTemperature} \newcommand{\BackemfVoltageBemf}{\BackEmfVoltage} \newcommand{\CoordinateReferenceFramesB}{\BodyReferenceFrame} \newcommand{\CameraframeThreedCoordinate}{\CameraFramePoint} \newcommand{\CartesianThreedPosition}{\CartesianPosition} \newcommand{\CommandTransportTimeBus}{\CommandTransportTime} \newcommand{\ContactForceVectorK}{\ContactPointForce} \newcommand{\ContactPointJacobianK}{\ContactPointJacobian} \newcommand{\ContinuousPeakCurrent}{\ContinuousCurrent} \newcommand{\CredibleDecelerationBrake}{\CredibleBrakingDeceleration} \newcommand{\OpenloopCrossoverFrequency}{\CrossoverFrequency} \newcommand{\PhaseLagDegradation}{\DelayPhaseLag} \newcommand{\DiffusionScheduleParameterK}{\DiffusionCumulativeSchedule} \newcommand{\DispatchtoadmissionIntervalDa}{\DispatchAdmissionInterval} \newcommand{\EmittedTokenCountOut}{\EmittedTokenCount} \newcommand{\FundamentalAndEssentialMatricesTwo}{\EssentialMatrix} \newcommand{\ForwardinvariantSafeSet}{\ForwardInvariantSafeSet} \newcommand{\FreespaceDepth}{\FreeSpaceDepth} \newcommand{\FundamentalAndEssentialMatrices}{\FundamentalMatrix} \newcommand{\TransmissionEfficiencyGear}{\GearboxTransmissionEfficiency} \newcommand{\HardwareAndCommoncauseRateOther}{\HardwareCommonCauseRate} \newcommand{\ContinuousPeakTorqueHold}{\HoldingTorque} \newcommand{\OptimalInertiamatchingRatio}{\InertiaMatchingRatio} \newcommand{\IntentleaseExpiryIntentexp}{\IntentLeaseExpiry} \newcommand{\LatentStyleStateEmbedding}{\LatentStyleVariable} \newcommand{\LinearBarrierDecayRateCbf}{\LinearBarrierDecayRate} \newcommand{\Momentum}{\LinearMomentum} \newcommand{\RotorAndLoadInertiaTwo}{\LoadInertia} \newcommand{\LqrGainAndWeights}{\LqrFeedbackGain} \newcommand{\CenterOfMass}{\MassCenterPosition} \newcommand{\TorqueAndBackemfConstants}{\MotorTorqueConstant} \newcommand{\NoisePredictionNetworkTwo}{\NoisedActionChunk} \newcommand{\ObservabilityMatricesNl}{\NonlinearObservationSpace} \newcommand{\ObservabilityMatrices}{\ObservabilityMatrix} \newcommand{\ContinuousPeakCurrentTwo}{\PeakCurrent} \newcommand{\ContinuousPeakTorque}{\PeakTorque} \newcommand{\PermissionloopPeriodTick}{\PermissionLoopPeriod} \newcommand{\PhaseInductanceAndResistance}{\PhaseInductance} \newcommand{\PhaseInductanceAndResistanceTwo}{\PhaseResistance} \newcommand{\InitialAndCeilingError}{\PositionErrorCeiling} \newcommand{\RenewaljitterAllowance}{\RenewalJitterAllowance} \newcommand{\ResidentStopDistanceSuffix}{\ResidentStopDistance} \newcommand{\CoefficientOfRestitution}{\RestitutionCoefficient} \newcommand{\RigidtransformTranslation}{\RigidTransformTranslation} \newcommand{\RotorAndLoadInertia}{\RotorInertia} \newcommand{\SamplingPeriodAndRate}{\SamplingPeriod} \newcommand{\SensorLeverarmVector}{\SensorLeverArm} \newcommand{\SequentialLoglikelihoodRatioM}{\SequentialLogLikelihoodRatio} \newcommand{\SinglestepImitationError}{\SingleStepImitationError} \newcommand{\SprtBoundariesLo}{\SprtLowerBoundary} \newcommand{\SprtBoundariesUp}{\SprtUpperBoundary} \newcommand{\LinearStatespaceMatrices}{\StateSpaceInputMatrix} \newcommand{\LinearStatespaceMatricesSys}{\StateSpaceSystemMatrix} \newcommand{\PertrialProbabilitiesTarget}{\TargetTrialSuccessProbability} \newcommand{\TorqueproducingCurrent}{\TorqueProducingCurrent} \newcommand{\TrackingerrorBound}{\TrackingErrorBound} \newcommand{\PertrialProbabilitiesFail}{\TrialFailureProbability} \newcommand{\TsdfAccumulatedVolumeVox}{\TsdfAccumulatedWeight} \newcommand{\VirtualDampingAndStiffness}{\VirtualDampingMatrix} \newcommand{\Radius}{\WheelRadius} \newcommand{\WindingAndAmbientTemperature}{\WindingTemperature} \newcommand{\CoordinateReferenceFramesW}{\WorldReferenceFrame} \newcommand{\ZerofailureTrialCount}{\ZeroFailureTrialCount} \newcommand{\ZeroMomentPointZmp}{\ZeroMomentPoint} \newcommand{\Glyph}[1]{#1} $$

10 Model Compression

Isometric compression workshop where a large model passes through pruning, distillation, and quantization stations before fitting into a constrained device envelope.

Purpose

Machine Learning Systems Architecture Stack

Architecture stack focus for this chapter.

Why do the models that win benchmarks rarely become the models that run in production?

A capable trained model is not automatically a deployable one. Cloud, Edge, Mobile, and TinyML environments each impose physical constraints that research benchmarks ignore, including memory budgets measured in megabytes rather than gigabytes, latency targets measured in milliseconds rather than seconds, and power envelopes measured in milliwatts rather than kilowatts. Research optimizes for accuracy on held-out test sets; production optimizes for accuracy per dollar, accuracy per watt, and accuracy per millisecond. Models that win benchmarks are frequently larger, slower, and more resource-intensive than production envelopes permit. Bridging this gap requires a systematic discipline of compression that trades capabilities the deployment does not need for physical constraints it cannot violate. Because many trained models carry more numerical precision, parameters, or representational capacity than the target workload requires, some of that surplus can be removed while preserving predictive behavior, though a smaller representation is not automatically a faster one. Unless the hardware and runtime software stack exploit the new precision or structure, a nominal size reduction merely moves the bottleneck while latency remains unchanged: removing half the weights in a tensor leaves execution time and energy untouched if the underlying hardware still fetches, stores, and multiplies every zero. Applied effectively, compression reduces model size by integer factors, transforming a research artifact that runs only on data center accelerators into a production asset capable of executing on a mobile phone, sensor node, or embedded microcontroller. The engineering goal is to make the right model viable within its physical environment, which differs fundamentally from making a model as small as possible. In D·A·M terms, model compression enacts algorithm-machine co-design directly on the network, reshaping its mathematical structure to satisfy the physical limits of the target hardware.

Learning Objectives
  • Explain compression as algorithm-machine co-design that trades surplus capacity for memory, latency, and energy constraints
  • Compare pruning, distillation, and quantization by the resource each relaxes and where each lands on the accuracy-efficiency frontier
  • Calculate parameter memory, precision, and sparsity reductions to estimate best-case compression gains
  • Apply post-training, quantization-aware, and weight-only strategies under accuracy and hardware constraints
  • Select structured pruning and operator choices that map to available accelerator kernels
  • Design compression pipelines that order pruning, distillation, and quantization and account for why their combined gains do not multiply
  • Evaluate measured latency, energy, and accuracy on target hardware rather than relying on FLOP counts

10.1 Fitting the Deployment Budget

A trained model arrives with demands on memory capacity, latency, and energy that were set by the server accelerators it trained on, not by the device it must run on. The target device instead enforces a strict deployment budget: the memory, time, and energy it grants to each result the model produces. Memory capacity bounds the bytes of weights and activations that can stay resident, a frame rate or token rate bounds the milliseconds available for each result, and a battery or thermal envelope bounds the joules that each result may consume. Bringing a model’s demands inside that budget, by changing what the model computes, how its values are stored, and how its operations execute, is the work of model compression.

Data Selection lowered the cost of producing a trained model by spending training compute only on examples that carry signal. Its savings end where the trained model begins. A model trained on a curated subset has the same parameter count, numerical precision, and memory footprint as one trained on the full corpus, so it can still overflow a phone’s memory or leave inference bound by memory bandwidth. Hardware Acceleration then examines the silicon that executes a model. Compression comes before it because compression decides what that silicon is asked to run: how many operations, how many bytes per value, and which kernels.

Vertical log-scale ladder of blue bars: a 175B FP16 weight footprint at top towers over a phone RAM bar, which towers over a tiny microcontroller RAM bar at the bottom.

Frontier weights dwarf phone and microcontroller memory; compression bridges the gap.

The gap is easiest to see at its extreme. A 7-billion-parameter language model requires 14 GB merely to store its weights in FP16. A smartphone offers 8 GB of RAM shared across the operating system, background applications, and the user interface, so even if the operating system surrendered its entire memory pool to one process, the weights would not fit. Fitting in memory would only expose a second limit, the token rate. At batch size one, dense autoregressive decoding is memory-bandwidth bound because generating each token reads every weight from DRAM, and no other request shares those bytes. Over a flagship phone’s 51.2 GB/s low-power DDR (LPDDR) bus, streaming 14 GB takes about 270 ms per token and about 2 J of DRAM access energy, so the memory traffic alone would draw about 8 W, above the phone’s sustained thermal envelope of 3–5 W. A model of this size is the extreme case; the rest of the chapter works with models that come closer to fitting, where the engineering choices are less obvious.

Under the silicon contract (principle 4), compute throughput, memory bandwidth, memory capacity, and fixed launch overhead determine which physical resource binds first for a given model on a given machine. Training sets those quantities generously. Server-class accelerators supply the aggregate memory and floating-point throughput that wide layers, high numerical precision, and large auxiliary state require, because training must hold gradients, optimizer moment buffers, and activation caches across backward passes. Inference deployment relaxes several of these demands because execution is forward-only, intermediate activation buffers can be reused after their last consumer, and optimizer states disappear, even though residual branches still extend some tensor lifetimes and autoregressive decoding retains KV state across tokens. While mixed-precision methods improve training throughput by selectively adopting FP16 or BF16, deployment can reduce precision further, to INT8, INT4, or specialized microformats, when the target’s execution units support them. Model compression is the systematic process of meeting the silicon contract of a constrained execution context, reducing parameter footprint, memory traffic, or arithmetic operations while preserving task accuracy.

↩︎ Mixed-precision training with FP16 and BF16, including loss scaling and FP32 accumulation, is established in Mixed-precision training.

Across deployment targets, the disparity in weight memory spans about six orders of magnitude, from the 350 GB of FP16 weights in a 175-billion-parameter frontier model to the 512 KB of on-chip SRAM in an embedded microcontroller. The bitter lesson explains why this gap persists. General methods that scale with compute keep winning benchmarks, so the winning models grow with available training compute while a phone’s or microcontroller’s memory and power envelope stays fixed for the life of the device. Compression is the deployment-side counterweight to scale.

↩︎ The bitter lesson, that general methods which scale with compute keep displacing hand-engineered ones, is established in The Bitter Lesson.

Hendrycks, Dan, Collin Burns, Steven Basart, Andy Zou, Mantas Mazeika, Dawn Song, and Jacob Steinhardt. 2020. “Measuring Massive Multitask Language Understanding.” arXiv Preprint.

The record of language models shows how much ground that counterweight can recover. Figure 1 follows the smallest dense model reported to score at least 60 percent on the Massive Multitask Language Understanding (MMLU) benchmark (Hendrycks et al. 2020) at each point in time. That size fell from 280 billion parameters for Gopher at the end of 2021 to 3 billion for Qwen2.5-Coder-3B, a code-specialized model, in 2024, about 93× smaller in under three years (Epoch AI 2026). Better training data, longer training, and distillation from larger models all contributed, so the decline is not compression alone, but it shows that a capability first reached at frontier scale can later fit a far smaller deployment budget.

Figure 1: Smallest Model Reaching a Fixed Score: Parameter counts of dense language models against release date on a logarithmic axis, with models scoring at least 60 percent on the MMLU benchmark in blue and the rest in gray. The red step line tracks the smallest model at or above that score released up to each date. Scores are as reported by each source, and parameter counts come from model names, so the line is a lower envelope of reported results rather than a controlled comparison. Data from Epoch AI (2026).
Epoch AI. 2026. Capabilities and Benchmarking.

Bridging the gap between frontier models and fixed deployment targets requires an engineering framework with predictable physical trade-offs. Every compression technique removes specific structure from the model, whether unnecessary weights, surplus numerical bits, or redundant operator subgraphs. Designing a production deployment requires identifying which resource binds first on the target platform and analyzing how successive approximations compound across the memory hierarchy. The framework this chapter builds works on three tiers: what the model computes (its structure), how many bits represent each value (its precision), and how the result executes on the target processor (its implementation). Benefits compound only when transformations relieve distinct binding bottlenecks and the runtime supports the resulting graph.

Definition 10.1: Model compression

Model compression is a family of techniques that reduce a trained model’s computational cost and memory footprint by eliminating redundant parameters (pruning), reducing numerical precision (quantization), or transferring learned behavior into a smaller architecture (distillation), while preserving as much predictive accuracy as possible.

  1. Significance: In the iron law (principle 3), compression targets both the Algorithm factor (\(\text{FLOPs/Sample}\), and therefore total operations \(\Operations\)) and the Machine factor (\(\text{Seconds/FLOP}\), through its physical data-movement and compute terms). INT8 quantization of a 175-billion-parameter LLM leaves \(\text{FLOPs/Sample}\) unchanged but cuts weight memory from 350 GB (FP16) to 175 GB, a 2× reduction in \(\DataVolume\), while dedicated low-precision matrix units can raise \(\PeakRate\) when kernels and layouts use the supported INT8 path. Unstructured pruning to 50 percent sparsity halves the nonzero parameter count, but executed operations fall only when the runtime can skip those zeros through a supported sparse format or kernel without inflating \(\text{Seconds/FLOP}\) via index-traffic stalls.
  2. Distinction: Unlike post-training compression methods such as pruning and quantization, neural architecture search discovers efficient architectures from scratch by exploring a design space. Here, NAS is treated as a related structural optimization technique, because it changes the representation before training rather than compressing a finished model post hoc.
  3. Common pitfall: Compression techniques do not compose without interference. Pruning changes weight distributions and operation patterns; quantization adds calibration and kernel constraints. Their combination can lose accuracy or fail to accelerate without joint validation.

The three tiers form a stack that descends from algorithmic software toward physical silicon, the same direction in which ML Frameworks lowered a computational graph to kernels. At the top sits what operations the model executes, in the middle how many bits encode each operand, and at the bottom how kernels map onto the processor’s compute and memory structures (figure 2).

Figure 2: Three Tiers of Compression: Model optimization progresses from software-level representation (pruning, distillation, NAS) down through numerical precision (quantization) to hardware execution (kernel fusion, sparsity engines). Lowering abstraction moves optimizations closer to physical silicon, where representation decisions dictate achievable execution efficiency.

Each tier removes a different kind of surplus across the two levels of the iron law. The top tier, efficient model representation, removes structure and lowers the Algorithm factor (\(\text{FLOPs/Sample}\)). Pruning drops weights or whole channels that contribute little to accuracy, knowledge distillation trains a compact student to match a larger teacher, and neural architecture search (NAS) looks for layer shapes that meet an explicit latency or memory bound. The middle and bottom tiers leave \(\text{FLOPs/Sample}\) unchanged and instead lower the Machine factor (\(\text{Seconds/FLOP}\)). In the middle tier, efficient numerics representation removes bits. Quantization maps floating-point values to 8-bit or 4-bit integers, which shrinks weight memory and bus traffic (\(\DataVolume\)) by two to four times and lets integer units execute each operation at higher peak rate (\(\PeakRate\)) and lower energy. In the bottom tier, efficient hardware implementation removes wasted execution. Kernel fusion keeps intermediate activations in on-chip memory instead of sending them back to DRAM (shrinking \(\DataVolume\)) and reduces launch overhead (\(\Latency\)), while sparsity pays off only when its zeros follow a pattern the hardware can skip, such as two zeros in every group of four weights, so that cutting \(\text{FLOPs/Sample}\) does not inflate \(\text{Seconds/FLOP}\).

These three tiers are tightly coupled across the compilation and execution boundary. Pruning alters weight distributions and activation profiles, changing the dynamic ranges required for subsequent quantization-range calibration. Quantization reduces data-movement volume across the memory bus, shifting a previously memory-bound workload toward compute-bound execution where kernel fusion and tile scheduling dominate. Achieving compounding performance gains requires co-designing transformations across all three tiers rather than applying them in isolation, a composition strategy that section 10.5.3 develops through a staged pipeline.

Every technique in this chapter answers to the conservation-of-complexity heuristic that opened Part I. Complexity tends to move among the Data, Algorithm, and Machine axes rather than disappear, so engineers must account for where each technique sends cost and risk. It is a heuristic, not a literal conservation law, and removing genuinely avoidable work can reduce total cost. Pruning may reduce parameters while asking the runtime to exploit sparse structure; distillation may reduce inference cost while adding a teacher-student training phase; quantization may reduce data movement while spending numerical precision. The engineer’s task is to move complexity to where the cost is lowest given deployment constraints.

Which tier of the optimization stack yields the highest return depends entirely on the physical machine hosting the workload. A data-center server equipped with several high-bandwidth memory (HBM) accelerators tolerates multi-gigabyte models but demands high token throughput under concurrency. A smartphone or an embedded microcontroller operates under severe physical ceilings on memory capacity, bus bandwidth, and thermal dissipation.

10.1.1 Deployment budgets and the running cases

Cloud serving, a phone camera, and an embedded microcontroller each break down on a different term of the deployment budget, so compression begins by asking which term a given model violates and what it costs to stop violating it. Cloud inference centers on throughput (requests per second per dollar), where supported integer quantization paths increase serving density and kernel fusion reduces per-request kernel launch overhead (Choudhary et al. 2020; Dean et al. 2018). Mobile and edge deployments must fit within tight physical memory bounds while meeting deterministic real-time deadlines. A serialized camera pipeline that must finish each frame before the next arrives at 30 frames per second has about 33 ms per frame. A pipelined design that overlaps capture, inference, and display can sustain 30 frames per second even when each frame takes longer than 33 ms end to end, so it must check frame rate and per-frame latency as two separate budgets.

Choudhary, Tejalal, Vipul Mishra, Anurag Goswami, and Jagannathan Sarangapani. 2020. “A Comprehensive Survey on Model Compression and Acceleration.” Artificial Intelligence Review 53 (7): 5113–55. https://doi.org/10.1007/s10462-020-09816-7.
Dean, Jeff, David Patterson, and Cliff Young. 2018. “A New Golden Age in Computer Architecture: Empowering the Machine-Learning Revolution.” IEEE Micro 38 (2): 21–29. https://doi.org/10.1109/mm.2018.112130030.
Banbury, Colby R., Vijay Janapa Reddi, Max Lam, William Fu, Amin Fazel, Jeremy Holleman, Xinyuan Huang, et al. 2020. “Benchmarking TinyML Systems: Challenges and Direction.” arXiv Preprint arXiv:2003.04821.

TinyML makes physical fit a deployment requirement. A microcontroller with only a few hundred kilobytes of SRAM and limited model storage cannot accommodate a 100 MB model without a compatible placement strategy, regardless of predictive accuracy (Banbury et al. 2020). Persistent weights may reside in flash or other supported storage, while runtime buffers occupy working memory. Without paging, the peak SRAM working set must fit the available SRAM; the model artifact must separately fit its storage budget. Capacity is also a hard bound on mobile and cloud devices, though their placement options differ.

↩︎ The latency, memory, and power envelopes defining cloud, edge, mobile, and TinyML tiers are established in Four Deployment Regimes Across Nine Orders of Magnitude.

Meeting real-time deadlines on commodity mobile hardware depends as much on the hardware-supported precision path as on absolute memory capacity. When execution units provide hardware acceleration exclusively for fixed-point arithmetic, precision selection dictates whether a workload executes on energy-efficient neural processing units or falls back to power-hungry general-purpose cores. That choice decides the chapter’s running case, a camera pipeline that must meet an interactive frame rate within a phone’s thermal budget (Example 10.1).

Example 10.1: The running case: Real-time blur on a phone
Scenario: A labeled composite. A camera application deploys a MobileNetV2-based segmentation model for real-time background blur on mid-tier smartphones at 30 FPS.

Diagnosis: An uncompressed FP32 MobileNetV2 model runs on the phone’s CPU at only 8 FPS, about 125 ms per frame against a 33 ms budget, while holding the CPU at a power level the thermal envelope cannot sustain. The phone’s NPU or DSP accelerates integer matrix arithmetic, not FP32, so the uncompressed model cannot use it.

Systems lesson: INT8 quantization cuts raw parameter payload by 4\(\times\), but most of the gain from 8 FPS to 35 FPS comes from what INT8 unlocks, a move from the CPU onto the integer accelerator. The precision change is the enabler; the change of processor supplies most of the speed. The frame rates are illustrative, so speed and power still require device measurement.

The chapter follows that camera pipeline through the structural and hardware tiers of the stack. MobileNetV2 is the book’s compute-bound lighthouse in its efficient regime. Depthwise separable convolutions keep its arithmetic small, and at batch one on a phone its frame time goes to arithmetic and activation traffic rather than to reading weights. The precision tier needs a workload whose time is set by bytes, so it follows GPT-2 XL decoding on the same phone. GPT-2 XL is the book’s bandwidth-bound lighthouse, and every token it generates streams every weight. Two callouts mark the ends of the memory constraint. DLRM (Naumov et al. 2019), the capacity-bound lighthouse, shows precision deciding whether embedding tables fit, and keyword spotting (KWS) (Y. Zhang et al. 2017), the power-bound lighthouse, shows precision deciding whether a model fits a microcontroller’s SRAM and energy budget. ResNet-50, the compute-bound lighthouse, serves twice, as the teacher that distills into MobileNetV2 and as the subject of the closing INT8 deployment profile. Rather than running every technique on all five, the chapter returns to each workload where it exposes the binding resource most clearly.

↩︎ The iron law of ML systems, which splits execution time into data-movement, compute, and fixed-overhead terms, is established in Iron Law of ML Systems.

Table 1 places the cases’ weight bytes and work beside the deployment budget, and two of its rows explain how the chapter divides the work. MobileNetV2’s FP32 weights stream across the phone’s 51.2 GB/s memory bus in about 0.27 ms, roughly 1 percent of the 33 ms frame budget, so the frame is spent on its 600 MFLOP of arithmetic and on activation traffic, and the structural and execution tiers are the levers that matter. GPT-2 XL’s FP16 weights fit in the phone’s memory but take about 59 ms to stream for every generated token, so precision, which shrinks the bytes behind each weight, is the lever that matters. Even MobileNetV2 at INT8 exceeds the TinyML envelope by about 6.7×, while the purpose-built depthwise separable convolutional network (DS-CNN) keyword spotter fits it after INT8 quantization.

Table 1: Deployment Budget for the Running Cases: Weight memory, work per result, and the time a flagship phone’s 51.2 GB/s memory bus needs to read the weights once, against the phone and TinyML memory envelopes. Work counts two FLOPs per multiply-accumulate; GPT-2 XL’s work and streaming time are per generated token, and MobileNetV2 must finish each frame within the 33 ms budget of a 30 FPS camera. DLRM represents recommendation-model embedding pressure (Naumov et al. 2019); DS-CNN represents the TinyML keyword-spotting case (Y. Zhang et al. 2017). The accounting covers weights only; activations, the KV cache, workspace, and metadata are excluded, and the DLRM row is a single reference configuration whose production counterparts can be far larger. Numbers in parentheses show how many times the model exceeds device memory.
Model and precision Weight memory Work per result Weight streaming on the phone Phone (8 GB) TinyML (~512 KB)
MobileNetV2, FP32 14 MB 600 MFLOP per frame 0.27 ms fits no (26.7×)
MobileNetV2, INT8 3.5 MB 600 MFLOP per frame 0.07 ms fits no (6.7×)
ResNet-50, FP32 (teacher) 102.4 MB 8.2 GFLOP per image 2 ms fits no (195.3×)
GPT-2 XL, FP16 3 GB 3 GFLOP per token 59 ms fits no (5722×)
GPT-2 XL, INT4 0.75 GB 3 GFLOP per token 15 ms fits no (1430.5×)
DS-CNN (KWS), INT8 200 KB 20 MFLOP per inference runs on a microcontroller fits fits
DLRM (reference) 100 GB lookup-dominated does not fit no (11.6×) no (190734.9×)

The chapter descends the optimization stack one tier at a time (table 2). Structural optimization changes what the model computes and carries the camera pipeline through pruning, low-rank factorization, distillation from a ResNet-50 teacher, efficient architecture design, architecture search, and input-dependent computation. Numerical precision changes how each surviving value is stored and carries GPT-2 XL decoding from numerical formats and their energy, through the quantization methods, to the conditions under which fewer bits run faster. Hardware implementation changes how the remaining operations execute, through the fusions and sparse kernels that compression makes possible and the gap between paper savings and measured ones. Choosing and combining techniques maps a binding constraint to the levers that relieve it, sequences them on the camera pipeline, and turns to the toolchains that apply them. Measuring compression gains closes the chapter on a ResNet-50 INT8 deployment profile, which Hardware Acceleration takes up. The descent begins at the top of the stack, with the structure of the model itself.

Table 2: Chapter Map: Each section of the chapter works one tier of the optimization stack, from what the model computes down to how it executes, and names the iron law term that tier most affects and the condition under which its paper savings become measured ones.
Section Tier of the stack What changes Iron law term most affected Condition for a measured gain
Structural Optimization Model representation Which weights, channels, layers, and paths exist Operations \(\Operations\), and weight bytes in \(\DataVolume\) Removed structure leaves smaller dense tensors or a supported sparse format
Numerical Precision Numerics representation Bits per weight and activation Bytes moved \(\DataVolume\), and energy per operation The target has a kernel path for the format
Hardware Implementation Hardware implementation Which kernels run, and what they skip \(\DataVolume\), fixed overhead \(\Latency\), and efficiency \(\EfficiencyHw\) The compiler can fuse the pattern and the kernel can skip the zeros
Choosing and Combining Techniques All three tiers Which levers apply, and in what order Whichever term binds The binding resource is identified before any lever is applied
Measuring Compression Gains The deployed system Nothing in the model; the claims are measured All terms, end to end Measured on the target hardware against quality limits
Self-Check: Question
  1. The chapter’s optimization framework organizes model compression along three abstraction levels. Which sequence matches the stack from most software-level to most hardware-level?

    1. Efficient numerics representation → efficient model representation → efficient hardware implementation
    2. Efficient hardware implementation → efficient model representation → efficient numerics representation
    3. Efficient model representation → efficient numerics representation → efficient hardware implementation
    4. Efficient hardware implementation → efficient numerics representation → efficient model representation
  2. A \(7\text{-billion}\)-parameter language model in FP16 occupies \(14\text{ GB}\) of weight memory alone. The target deployment platform is a smartphone with \(8\text{ GB}\) of shared RAM. Explain how quantizing weights to INT4 addresses both the physical memory capacity ceiling and the memory-bandwidth bottleneck during autoregressive token generation.

  3. True or False: When a model cannot be deployed because its parameter footprint exceeds the device’s physical RAM capacity, operator fusion is an effective direct substitute for pruning or quantization.

  4. A ____ is the memory, time, and energy that a target device grants to each result a model produces, and model compression is the work of bringing a trained model’s demands inside it.

  5. Across the deployment contexts analyzed in the chapter, which platform most clearly makes model compression a feasibility requirement rather than mainly a throughput or cost optimization?

    1. TinyML microcontrollers, where SRAM and storage budgets are so small that some models cannot be placed at all without compression or redesign
    2. Cloud inference clusters, where only cloud systems face hard capacity limits and all smaller devices can compensate in software
    3. Autonomous edge servers, where continuous thermal throttling is preferred over changing the model
    4. Mobile smartphones, where unified memory architecture eliminates meaningful capacity constraints for large neural networks
  6. A mobile video-conferencing feature requires \(30\text{ FPS}\) background segmentation, but baseline FP32 MobileNetV3 runs at only \(8\text{ FPS}\). Applying INT8 quantization accelerates the model to \(35\text{ FPS}\) with a minor \(0.4\%\) drop in mIoU, satisfying the shipping requirement. Which region of the chapter’s compression-accuracy Pareto frontier best describes this outcome?

    1. Region 1 (free lunch), because achieving 35 FPS proves that INT8 quantization incurs zero loss in segmentation boundary fidelity
    2. Region 3 (danger zone), because any reduction in numerical precision destabilizes temporal consistency in video processing
    3. An unfeasible operating point outside the Pareto frontier, because 35 FPS exceeds the maximum display refresh rate
    4. Region 2 (efficient trade), because a modest, acceptable drop in segmentation accuracy unlocks a 4.4× frame rate increase that satisfies the 30 FPS real-time shipping threshold

See Answers →

10.2 Structural Optimization: Changing What the Model Computes

A standard ResNet-50 trained on ImageNet contains over 25 million parameters, yet with careful magnitude pruning and retraining about 80 percent of its weights can be removed for roughly a one-point loss in top-1 accuracy (Gale et al. 2019). Modern neural networks routinely carry far more parameters than deployment requires.1 Unused capacity still consumes memory, computation, and energy. Structural optimization is the first tier of the stack, efficient model representation, by modifying what the model computes. Although additional capacity can aid optimization during training, parameters that do not improve the deployed model still impose deployment cost. The job is to remove capacity the task does not need without removing what it does need, and operating along the Pareto frontier2 means deciding where the conservation-of-complexity heuristic sends the cost, whether into training-time discovery, runtime sparse indexing, or student-model capacity.

1 Overparameterization: C. Zhang et al. (2017) demonstrated that networks large enough to fit ImageNet can also memorize completely random labels, showing that training capacity can exceed the structure needed for natural labels. Pruning studies then show the deployment consequence, that trained models often contain many parameters that can be removed or sparsified with modest task loss when pruning and fine-tuning are done carefully (Gale et al. 2019; Blalock et al. 2020). The redundancy is not a universal 10\(\times\) constant; it depends on architecture, dataset, sparsity pattern, and runtime support.

Zhang, Chiyuan, Samy Bengio, Moritz Hardt, Benjamin Recht, and Oriol Vinyals. 2017. “Understanding Deep Learning Requires Rethinking Generalization.” International Conference on Learning Representations (ICLR).
Gale, Trevor, Erich Elsen, and Sara Hooker. 2019. “The State of Sparsity in Deep Neural Networks.” arXiv Preprint arXiv:1902.09574.

2 Pareto frontier in compression: EfficientNet traces the frontier concretely, from B0 (77.1 percent accuracy, 390 million FLOPs) to B7 (84.4 percent, 37 billion FLOPs), a 95\(\times\) compute increase for 7.3 percentage points of accuracy, quantifying how steep the trade-off becomes at the frontier’s edge (Tan and Le 2019).

Tan, Mingxing, and Quoc V Le. 2019. “EfficientNet: Rethinking Model Scaling for Convolutional Neural Networks.” International Conference on Machine Learning (ICML), 6105–14.
Hutter, Frank, Lars Kotthoff, and Joaquin Vanschoren. 2019. Automated Machine Learning: Methods, Systems, Challenges. In Automated Machine Learning. The Springer Series on Challenges in Machine Learning. Springer International Publishing. https://doi.org/10.1007/978-3-030-05318-5.

These techniques address the challenge through complementary structural mechanisms. Pruning eliminates redundant parameters from an existing network, and low-rank factorization stores an existing weight matrix as a product of two thin ones. Knowledge distillation transfers learned behavior into an independently designed compact network, efficient architecture design and neural architecture search build a network that is efficient on the target by construction (Hutter et al. 2019), and adaptive computation decides for each input how much of the network runs. In production pipelines, these techniques frequently compose, as when a NAS-discovered architecture, supervised by a distilled teacher, is pruned before final quantization.

The camera pipeline gives every structural technique the same test. MobileNetV2 must finish a frame within 33 ms on the phone, and its weights are not what fills that budget, so a structural change pays off only if it removes multiply-accumulates or activation traffic that the phone actually executes. The analysis below evaluates what structural artifact each method produces, what fine-tuning or recovery step it requires, and which hardware execution conditions allow it to deliver physical speedups. Pruning comes first because it exposes the systems constraint most directly. Eliminating mathematical parameters translates to physical hardware acceleration only when the resulting sparsity pattern aligns with the memory hierarchy and compute units of the target processor.

10.2.1 Pruning

For the camera pipeline, pruning3 is the first lever to try because it starts from the trained MobileNetV2 rather than from a new design. Removing whole channels from its convolutions shrinks every layer that consumes them and cuts the multiply-accumulates that fill the 33 ms frame budget. Removing scattered individual weights, by contrast, leaves the same layers in place and saves bytes or time only if the runtime stores the zeros compactly and skips them. The safe removable fraction depends on the architecture, task, pruning pattern, and recovery procedure, and every pruning design turns on three choices: what to prune (individual weights vs. entire structures), how to score what is expendable (magnitude, gradients, or activations), and when to prune (after training, during training, or at initialization).

3 Optimal Brain Damage: Introduced by LeCun et al. (1989), the method achieved 4\(\times\) parameter reduction, with proportional memory savings, in a handwriting recognizer by using a diagonal approximation to second-derivative (Hessian) information to estimate the loss increase from removing each weight. A full Hessian has \(\mathcal{O}(\Parameters^2)\) entries for \(\Parameters\) parameters, but Optimal Brain Damage avoids storing that full matrix by approximating its diagonal. Modern-scale pruning still favors cheaper criteria such as magnitude because even diagonal curvature estimation adds training cost.

LeCun, Yann, John S. Denker, and Sara A. Solla. 1989. “Optimal Brain Damage.” Advances in Neural Information Processing Systems 2 (NIPS 1989), 598–605.
Definition 10.2: Pruning

Pruning is a model-compression technique that sparsifies the parameter space by removing the weights or structures whose removal increases the training loss least.

  1. Significance: It can convert dense matrices into sparse structures, reducing memory footprint and total data volume \((\DataVolume)\) when the sparse representation, metadata, and recovery procedure preserve acceptable quality.
  2. Distinction: Unlike quantization, which reduces the precision of every weight, pruning reduces the count of weights by identifying and eliminating redundancy.
  3. Common pitfall: A frequent misconception is that pruning “automatically” speeds up execution. In reality, without specialized sparse execution support, the resulting sparse matrices may actually run slower than dense ones due to irregular memory access patterns. A speedup requires a storage format and a kernel that skip the zeros, not merely a faster processor.

The formal pruning objective seeks a sparse parameter tensor \(\PrunedWeightMatrix\) that minimizes empirical loss subject to a parameter budget \(\NonzeroParameterBudget\): \[ \min_{\PrunedWeightMatrix} \LossFunction(\PrunedWeightMatrix) \quad \text{subject to} \quad \|\PrunedWeightMatrix\|_0 \leq \NonzeroParameterBudget\] where \(\|\PrunedWeightMatrix\|_0\) is the \(\ell_0\) norm (the count of nonzero parameters). Solving this cardinality-constrained optimization is combinatorial, so practical methods use heuristics4 such as magnitude-based pruning. The thresholding heuristic keeps the largest weights and zeroes the rest (listing 1). Applied to an \(11\times 11\) weight tensor, it collapses sub-threshold entries to zero while irregular, high-magnitude weights persist across the grid (figure 3).

4 Heuristic: From Greek heuriskein (to discover), the same root as Archimedes’ “eureka.” In pruning, the dominant heuristic (larger magnitude means more important) works well empirically but creates a systems trap. Magnitude-based pruning applied globally can remove most parameters from overparameterized layers while leaving critical bottleneck layers largely intact, giving the appearance of aggressive compression while preserving much of the compute and memory cost in the layers that matter (Blalock et al. 2020). Iterative prune-retrain cycles with per-layer budgets are therefore often safer than naive global magnitude pruning, because each cycle lets the network redistribute importance before the next cut.

Blalock, Davis, Jose Javier Gonzalez Ortiz, Jonathan Frankle, and John Guttag. 2020. “What Is the State of Neural Network Pruning?” Proceedings of Machine Learning and Systems (MLSys) 2: 129–46.
Listing 1: Magnitude-Based Pruning: Removes weights below a threshold to create sparse matrices, reducing the number of nonzero parameters from 9 to 4 \((\NonzeroParameterBudget=4)\).
import torch

# Original dense weight matrix
weights = torch.tensor(
    [[0.8, 0.1, -0.7], [0.05, -0.9, 0.03], [-0.6, 0.02, 0.4]]
)

# Simple magnitude-based pruning: keep only the 4 largest weights
threshold = 0.5
mask = torch.abs(weights) >= threshold
pruned_weights = weights * mask

print("Original:", weights)
print("Pruned (4 nonzeros):", pruned_weights)
Figure 3: Sparse Matrix Transformation: Magnitude-based pruning replaces weights below a numerical threshold with exact zeros (white cells) while preserving salient high-magnitude connections (colored cells). The resulting sparsity cuts parameter count, but realizing hardware speedups requires translating these unstructured zero entries into sparse storage formats or specialized execution kernels.

The resulting sparse matrix retains only the high-magnitude values (colored cells) while near-zero weights become exact zeros. In models amenable to pruning, much of the representational capacity remains intact after removing low-magnitude weights, establishing magnitude thresholding as an effective baseline heuristic.

To make pruning computationally tractable during gradient-based training, practical methods often relax the combinatorial \(\ell_0\) constraint with continuous penalties such as \(\ell_1\)-regularization \((\SparsityPenaltyWeight\| \WeightMatrix\|_1)\), where \(\SparsityPenaltyWeight\) scales the sparsity penalty applied to weight tensor \(\WeightMatrix\). Penalizing weight magnitudes drives non-essential parameters toward zero, making downstream thresholding easier. Practitioners typically couple this with iterative pruning, removing parameters in successive increments interleaved with fine-tuning cycles to recover lost accuracy (Gale et al. 2019; Blalock et al. 2020).

Target structures

The choice of what to prune depends on the deployment target’s hardware constraints and which resource is the binding bottleneck. When memory capacity is primary, neuron pruning can provide direct relief in models whose fully connected layers dominate parameter storage. Removing entire neurons and their associated weights and biases reduces layer width and parameter count. Profiling must first establish that these layers, rather than embeddings, activations, or another component, are the actual bottleneck.

When convolutional inference latency on commodity accelerators is the bottleneck, channel pruning (also called filter pruning) is a strong candidate. Eliminating entire channels or filters reduces feature-map depth and the multiply-accumulate count in subsequent layers. The resulting subnetwork remains dense and regular, so it can map to conventional GPU and Tensor Processing Unit (TPU) kernels without an unstructured sparse format. Realized latency still depends on the resulting dimensions, kernels, and memory traffic.

When a model contains removable stages, layer pruning removes entire layers from the network. Each removal eliminates all computation in that stage, but it also reduces representational depth and may change tensor shapes, residual paths, or downstream interfaces. The remaining layers must absorb the lost function, typically through fine-tuning or retraining. The nominal operation saving therefore does not guarantee proportional latency, because graph rewrites, kernel shapes, and memory traffic still govern execution. Layer pruning demands careful task validation and end-to-end profiling. Side by side, the two granularities differ in what they remove. An individual filter slice contracts intermediate feature depth, while an excised layer collapses a full computational stage (figure 4).

Figure 4: Channel vs. Layer Pruning: Structural pruning operates at different architectural granularities. Channel pruning (left) removes feature map slices within convolutional layers while preserving overall network topology and dense execution, whereas layer pruning (right) eliminates entire computational stages, requiring graph rewiring and risking greater capacity loss to achieve larger per-operation savings.

Channel and layer pruning place different demands on accelerator hardware. Channel pruning contracts the inner dimensions of dense general matrix multiply (GEMM) operations, because eliminating output channels in layer \(\ell\) reduces the input channel dimension in layer \(\ell+1\). The tensors remain dense and avoid sparse pointer lookups, but their dimensions still decide how well single instruction, multiple data (SIMD) lanes and Tensor Core tiles fill. Pruning a 256-channel layer to 250 channels, for example, removes about 2 percent of the work yet can leave a matrix unit that processes channels in groups of 8 running a partly empty final tile, so the layer may run no faster. Pruning to 248 keeps every tile full. The camera pipeline’s MobileNetV2 shows the same rule in its design, since its reference implementation rounds every channel count to a multiple of 8, and a pruning policy for the phone keeps the pruned counts on that grid. The preferred multiple depends on the kernel and numerical format, and because it counts elements rather than bytes, it is a different constraint from cache-line or memory-transaction alignment. Layer pruning removes full computational stages and their associated launches and intermediates, but the rewritten graph must still satisfy shape, residual-connection, and kernel-layout requirements. Both approaches require quality validation.

Unstructured pruning

Unstructured pruning removes individual weights while preserving the overall network architecture. Some connections become redundant during training, contributing little to the final output. Pruning these weak connections reduces the nonzero count and can preserve most task quality after recovery.

Formalizing this process, let \(\WeightMatrix\in \mathbb{R}^{\WeightMatrixRowCount\times \WeightMatrixColumnCount}\) represent a weight matrix in a given layer. Pruning removes a subset of weights by applying a binary mask \(\PruningMask\in \{0,1\}^{\WeightMatrixRowCount\times \WeightMatrixColumnCount}\), yielding a pruned weight matrix: \[ \PrunedWeightMatrix= \PruningMask\odot \WeightMatrix\] where \(\odot\) represents the element-wise Hadamard product. The mask \(\PruningMask\) is constructed based on a pruning criterion, typically weight magnitude. A common approach is magnitude-based pruning, which removes a fraction \(\SparsityRatio\) of the lowest-magnitude weights by defining a threshold \(\PruningThreshold\) such that: \[ \PruningMaskEntry = \begin{cases} 1, & \text{if } |\LayerWeightEntry_{i,j}| > \PruningThreshold\\ 0, & \text{otherwise} \end{cases} \] where \(\PruningThreshold\) is chosen to ensure that only the largest \((1 - \SparsityRatio)\) fraction of weights remain. This method assumes that larger-magnitude weights contribute more to the network’s function, making them preferable for retention.

Unstructured pruning reduces the count of nonzero parameters, but translating that reduction into physical storage savings requires an indexed sparse encoding such as Compressed Sparse Row (CSR) or coordinate list (COO), whose positional metadata can cancel the saving at low sparsity. Storing a dense tensor with zeroed entries saves no memory at all. Where the indexed formats break even in bytes and in time is a question about execution rather than about which weights to remove, and section 10.4.2.2 answers it.

Structured pruning

Where unstructured pruning removes individual weights across arbitrary tensor coordinates, structured pruning (Li et al. 2017) eliminates regular groups of parameters: channels, filters, attention heads, or entire layers. Because removing whole structural units contracts weight arrays into smaller, contiguous dense tensors, the remaining computation executes directly on standard Basic Linear Algebra Subprograms (BLAS) and convolution engines without specialized sparse libraries or metadata indexing overhead.

Li, Hao, Asim Kadav, Igor Durdanovic, Hanan Samet, and Hans Peter Graf. 2017. “Pruning Filters for Efficient ConvNets.” International Conference on Learning Representations (ICLR).

5 N:M structured sparsity: Introduced commercially with NVIDIA’s A100 GPU (2020), the 2:4 pattern was chosen because it halves multiply-accumulate operations while keeping position metadata small enough for the sparse Tensor Core path (NVIDIA Corporation 2020; Choquette et al. 2021). This fixed ratio is a hardware constraint, not a mathematical optimum. The A100 Sparse Tensor Core path accelerates 2:4 sparse operands, yielding up to 2\(\times\) math-throughput speedup over dense execution when kernels and layouts satisfy the constraint. Other ratios are not accelerated by this specific hardware path, illustrating how silicon design constrains which sparsity patterns translate to actual speedup.

NVIDIA Corporation. 2020. NVIDIA A100 Tensor Core GPU Architecture. NVIDIA Whitepaper, V1.0.
Choquette, Jack, Wishwesh Gandhi, Olivier Giroux, Nick Stam, and Ronny Krashinsky. 2021. “NVIDIA A100 Tensor Core GPU: Performance and Innovation.” IEEE Micro 41 (2): 29–35. https://doi.org/10.1109/mm.2021.3061394.

Between unconstrained irregular masks and coarse-grained channel excision lies hardware-aligned fine-grained regularity. Hardware-aware pruning strategies, such as N:M structured sparsity,5 enforce fine-grained patterns that map directly onto accelerator execution datapaths. Under a 2:4 structured sparsity constraint, every contiguous block of four weights must contain exactly two zeros and two nonzero values: \[ \text{Original block (4 values):}\quad [0.0,\; 1.4,\; 0.0,\; -2.1] \;\longrightarrow\; \text{Compressed storage:}\quad [1.4,\; -2.1] \quad \text{with 2-bit indices:}\; [01_2,\; 11_2] \] Because every group of four weights compresses to exactly two values, the value payload halves, and a 2-bit index per kept value adds only a small, fixed metadata cost with no structural irregularity. This chapter uses the 2:4 pattern as the canonical compression example, and section 10.4.2 returns to what a sparse matrix unit does with it.

↪ How sparse Tensor Cores use the 2-bit metadata to select matching activations and skip the zeroed multiplies is developed in N:M structured sparsity mechanics.

The regularity-compression trade-off spans three architectural granularities, from irregular connection masking to coarse-grained neuron dropping and full convolutional channel excision (figure 5). Moving from left to right trades per-weight freedom for dense tensor structure that standard hardware kernels can execute directly.

Figure 5: Unstructured vs. Structured Pruning: The regularity-compression trade-off across pruning granularities. Unstructured pruning (left) removes arbitrary individual connections and requires a sparse representation and matching kernel to change execution. Structured pruning of neurons (middle) or convolutional channels (right) can produce smaller dense tensors that remain compatible with standard kernels, although realized latency depends on the resulting shapes and runtime. Source: (Qi et al. 2021).
Qi, Chen, Shibo Shen, Rongpeng Li, Zhifeng Zhao, Qing Liu, Jing Liang, and Honggang Zhang. 2021. “An Efficient Pruning Scheme of Deep Neural Networks for Internet of Things Applications.” EURASIP Journal on Advances in Signal Processing 2021 (1): 31. https://doi.org/10.1186/s13634-021-00744-4.

In fully connected layers (center of figure 5), pruning neurons eliminates the corresponding rows and columns in adjacent weight matrices. In convolutional layers (right), pruning channels removes complete 3D filter slices. Either way the subnetwork stays dense, so the remaining systems requirement is matching the resulting tensor shapes and layouts to efficient kernels, the tile-filling condition of section 10.2.1.1.

A common approach to structured pruning ranks entire neurons or filters by the magnitude of their associated weights. A low group norm is an inexpensive proxy for low importance, not proof that the unit is dispensable. The score can use an \(\ell_1\)-norm or \(\ell_2\)-norm over the weights associated with each unit; groups below a selected threshold become pruning candidates. Layer-wise ranking matters because raw scales can differ across layers. The method needs no representative data pass, but computing scores, choosing a threshold, materializing the smaller graph, and validating or fine-tuning the result still incur engineering and compute cost.

Another strategy is activation-based pruning, which evaluates neuron or filter activations over a dataset. Units that remain weak across representative inputs become candidates for removal, subject to ablation or fine-tuning checks. This method captures input-dependent behavior rather than relying only on static weights. Its ranking can still miss rare but important inputs, depend on activation scaling, or change after upstream units are removed. Activation-based pruning therefore requires representative profiling data and validation after the selected structures are removed.

Gradient-based pruning uses loss derivatives to estimate how removing a neuron or filter would change the objective. A small first-order score suggests a candidate at the current checkpoint and on the sampled data; it does not establish permanent irrelevance or capture every interaction among units. Gradient-based criteria can combine a unit’s value with its gradient to rank the expected local loss change. Mathematically, this criterion approximates the change in loss \(\FiniteChange\LossFunction\) when zeroing parameter \(\ModelWeight_i\) via a first-order Taylor expansion: \(\FiniteChange\LossFunction \approx |\ModelWeight_i \cdot \frac{\partial \LossFunction}{\partial \ModelWeight_i}|\). Weights that are either near zero or have negligible gradients exert minimal influence on the objective, making them prime candidates for excision. Unlike weight-only magnitude criteria, they require backward computation and are usually integrated into training or fine-tuning. The pruned result still needs task-level validation because the score is a local approximation.

These criteria trade measurement cost against fidelity to model behavior. Magnitude scores are inexpensive and provide a useful baseline, but they ignore the input distribution. Activation scores incorporate representative inputs and expose units that are quiet on that workload, while gradient-based scores also incorporate the local loss surface at additional training cost. None dominates across models, and none establishes that removal is harmless. A sound comparison prunes to the same structural target, applies the same recovery budget, and measures task quality after removal. It then profiles the exported graph, because a better importance score can preserve quality without producing shapes that the target runtime executes efficiently. The choice therefore depends on available data and compute, the structure being removed, and the deployment’s quality margin.

Pruning trade-offs

The three pruning approaches occupy different positions on the regularity-versus-granularity trade-off. Unstructured pruning can remove individual weights and therefore express fine-grained sparsity, but accelerators need matching sparse formats and kernels to skip those zeros. Structured pruning removes channels, filters, or layers and can produce smaller dense operations that conventional hardware already supports. Dynamic pruning, which section 10.2.6 develops with the other input-dependent methods, makes the executed structure depend on each input, adding control and batching overhead in exchange for conditional allocation. The three differ in what they remove, what the runtime must support, and what recovery they need (table 3).

These categories describe deployed execution rather than mutually exclusive training algorithms. A structured subnetwork may be learned with a dynamic schedule and then frozen for serving; classify the artifact by what its runtime actually executes.

Table 3: Pruning Strategies: Unstructured pruning removes individual weights but needs sparse storage and matching kernels for deployment gains; structured pruning removes whole components that map more directly to dense hardware, while dynamic pruning adds runtime adaptation and overhead.
Aspect Unstructured Pruning Structured Pruning Dynamic Pruning
Removed unit Individual weights in the model Entire neurons, channels, filters, or layers Adjusts pruning based on runtime conditions
Model structure Sparse weight matrices; original architecture remains unchanged Model architecture is modified; pruned layers are fully removed Structure adapts dynamically
Impact on memory Reduces the nonzero count; storage falls only with an appropriate sparse representation Reduces model storage by removing entire components Varies based on real-time pruning
Impact on computation Dense work remains unless a supported sparse path skips zeros Reduces nominal FLOPs; latency depends on resulting shapes and kernels Varies with routing policy and controller overhead
Hardware compatibility Requires sparse formats and matching execution support Produces dense subnetworks, but awkward shapes can still underutilize hardware Requires adaptive inference engines
Fine-tuning requirement Often used to recover accuracy after pruning Often used after structural modification Depends on how the routing policy and subnetworks are trained
Use cases Targets whose runtime provides sparse formats and kernels, or storage-bound high sparsity Real-time inference optimization, mobile/edge AI, and efficient training Adaptive AI applications, real-time systems

Pruning schedules

The pruning schedule affects how much recovery training the network receives after capacity is removed. Two primary scheduling strategies govern weight removal: iterative pruning and one-shot pruning.

Iterative pruning

Iterative pruning removes capacity gradually, alternating each structural cut with fine-tuning so that the network recovers before the next cut. Across three successive prune-and-retrain cycles, accuracy drops after each cut and recovers during the fine-tuning that follows (figure 6).

Figure 6: Illustrative Iterative Pruning Performance: Three rows depict successive prune-then-fine-tune cycles, each removing two of the original twenty-two channels. Accuracy drops from 0.995 to 0.971 after the first prune, recovers to 0.992 after fine-tuning, and settles at 0.991 after all three cycles, a 0.4 percent loss with 27 percent fewer channels.

In the illustrative workflow, a convolutional network loses six channels with recovery between successive cuts. Rather than removing all six channels in a single pass, the pipeline removes two channels per cycle across three iterations, fine-tuning the remaining parameters after each cut. The initial cut drops accuracy from 0.995 to 0.971, but brief fine-tuning restores performance to 0.992. Two subsequent prune-and-tune cycles produce a final model at 0.991 accuracy, a 0.4 percent degradation despite a 27 percent reduction in channel count. Staging structural surgery across multiple retraining intervals allows surviving weights to adjust their representations along the loss landscape.

One-shot pruning

One-shot pruning removes multiple architectural components in a single step, followed by an extensive fine-tuning phase to recover model accuracy. This aggressive approach compresses the model quickly but risks greater accuracy degradation, as the network must adapt to significant structural changes simultaneously.

Applying one-shot pruning to the same network illustrates the hazard of aggressive structural truncation. Removing all six highlighted channels at once (figure 7) causes a sharp accuracy drop from 0.995 to 0.914, from which fine-tuning recovers only partially to 0.943, leaving about a 5 percent quality penalty under the recovery procedure shown. The two figures illustrate a mechanism, not a controlled result. Both runs end with the same tensor geometry, but the iterative run also received three rounds of fine-tuning, so its better final accuracy mixes the benefit of smaller cuts with the benefit of more recovery training. A fair comparison holds the final structure and the total recovery budget fixed.

Figure 7: Illustrative One-Shot Pruning Impact: All six channels (27 percent) are removed simultaneously, causing accuracy to drop from 0.995 to 0.914. Fine-tuning recovers only to 0.943, a 5 percent degradation from the original accuracy.

The working rule follows from that mechanism. Start with one-shot pruning plus recovery, because it is cheapest, and accept it if the recovered model meets the quality target. Move to an iterative schedule when it does not, which is most likely at high sparsity, where a single large cut removes capacity the network cannot rebuild in one recovery phase. Compare the two at a matched recovery budget, and spend the extra cycles only when the target accelerator can exploit the sparsity pattern that results.

Lottery ticket hypothesis (optional depth)

Standard pruning workflows assume a fully trained dense model from which weights are subsequently removed. Yet the relationship between network structure and optimization dynamics runs deeper, because pruning can reveal inherently efficient, highly trainable subnetworks embedded within the initial random parameterization.

This perspective leads to the Lottery Ticket Hypothesis6 (LTH), which challenges conventional pruning workflows by proposing that within large neural networks, there exist small, well-initialized subnetworks (“winning tickets”) that can achieve comparable accuracy to the full model when trained in isolation. Rather than viewing pruning as a post-training compression step, LTH suggests it can serve as a discovery mechanism to identify these efficient subnetworks early in training (Rachwan et al. 2022).

6 Lottery ticket hypothesis: Named for the intuition that training a large network is like buying many lottery tickets, most of which lose, while a few “winning tickets” (sparse subnetworks with favorable initializations) can train to comparable accuracy on their own. Frankle and Carbin (2019) established the hypothesis on smaller vision and fully connected networks; later work surveyed and extended the idea to larger settings (Rachwan et al. 2022). The systems implication is that some of the memory and compute spent training dense networks may be discoverable overhead, but the practical payoff depends on whether the winning subnetwork can be found before paying most of the original training cost.

Frankle, Jonathan, and Michael Carbin. 2019. “The Lottery Ticket Hypothesis: Finding Sparse, Trainable Neural Networks.” International Conference on Learning Representations (ICLR).
Rachwan, John, Daniel Zügner, Bertrand Charpentier, Simon Geisler, Morgane Ayle, and Stephan Günnemann. 2022. “Winning the Lottery Ahead of Time: Efficient Early Network Pruning.” International Conference on Machine Learning (ICML), 18293–309.

The discovery procedure is an iterative pruning-and-rewinding loop. After training to convergence and pruning low-magnitude connections, the surviving weights reset to their initialization state \(\ModelParameters_0\), which isolates a sparse subnetwork (figure 8). Repeating the cycle can isolate a sparse subnetwork that, in the reported settings, trains to accuracy comparable with the original network (Frankle and Carbin 2019). Whether the same procedure succeeds depends on architecture, scale, optimizer, and training budget.

Figure 8: Lottery Ticket Iteration Cycle: The original procedure repeatedly trains, prunes low-magnitude weights, and resets surviving weights to their initial state \(\ModelParameters_0\). The cycle tests whether the resulting sparse subnetwork can match the dense baseline when trained in isolation; the outcome is empirical rather than guaranteed.

The Lottery Ticket Hypothesis suggests that compact, trainable subnetworks may exist inside an overparameterized initialization, which motivates direct sparse-training research. The standard discovery procedure, however, does not eliminate dense training cost. It first pays for one or more dense or partially dense runs, plus a rewind and a recovery phase per pruning cycle, to find the ticket. A winning ticket is therefore a training result. It becomes a systems win only when that total accelerator time, the final artifact size, target latency, and task quality beat the simpler alternatives: training a smaller dense model from the start, one-shot pruning with recovery, and direct sparse training.

Pruning in practice

While the Lottery Ticket Hypothesis illuminates the optimization landscape, practical serving systems care only about executable artifacts. Framework-level pruning is useful only when it materializes concrete hardware savings: a smaller dense tensor, a hardware-aligned structured sparse matrix, or an indexed sparse layout paired with matching runtime kernels. Training-time pruning often begins as mask application. The original tensor remains resident in memory, while a binary mask zeros selected weights during forward propagation. That mechanism guides gradient flow during recovery, but it delivers zero memory reduction or latency improvement on its own. Measurable efficiency gains emerge only after the masked structure is exported into the physical artifact loaded by the inference engine.

This artifact boundary is where the unstructured and structured strategies part ways. An exported unstructured mask still needs a sparse storage format and a matching kernel, whereas exported structured pruning is already a smaller dense graph. The systems audit therefore has three concrete steps. Identify what was pruned, identify the format the runtime receives, and verify that the target hardware has kernels that make the sparsity useful.

↪ Benchmark protocols that separate structured from unstructured pruning and specify the hardware and sparse-kernel support behind any measured speedup are developed in Compression benchmarks.

7 BERT pruning: BERT’s 12 attention heads per layer can contain substantial redundancy. Michel et al. (2019) found on MultiNLI that many heads could be removed without a statistically significant performance change. The removable fraction depends on the layer and task, so deployment pruning must measure both task quality and whether the resulting structure reduces runtime work.

Michel, Paul, Omer Levy, and Graham Neumann. 2019. “Are Sixteen Heads Really Better Than One?” Advances in Neural Information Processing Systems (NeurIPS).
Jiao, Xiaoqi, Yichun Yin, Lifeng Shang, Xin Jiang, Xiao Chen, Linlin Li, Fang Wang, and Qun Liu. 2020. “TinyBERT: Distilling BERT for Natural Language Understanding.” Findings of the Association for Computational Linguistics: EMNLP 2020, 4163–74. https://doi.org/10.18653/v1/2020.findings-emnlp.372.

In practice, BERT-style transformers7 have been pruned by removing redundant attention heads or intermediate dimensions, while separate distillation methods such as DistilBERT and TinyBERT train smaller dense student models that retain much of BERT’s performance (Sanh et al. 2019; Jiao et al. 2020). Pruning decides which weights exist, and every weight it keeps is still stored and multiplied at full size. A second way to shrink an existing layer keeps every weight position but stores the matrix as a product of two thin matrices, which suits layers whose weights carry less information than their dimensions suggest.

10.2.2 Low-rank factorization

Fetching and multiplying a full \(4096 \times 4096\) weight block from DRAM spends 93.75 percent of its memory traffic and arithmetic on directions that barely change the layer’s output when a rank-128 subspace already captures almost all of the transformation’s variance. Deep network weight matrices often show this rapid singular-value decay, and structured approximation exploits it by decomposing dense \(M \times N\) weight tensors into products of low-rank matrices or tensor factors that require only a fraction of the original scalar parameters (6.25 percent in the rank-128 case). Low-rank matrix factorization and multi-linear tensor decompositions translate this algebraic redundancy into reduced memory traffic and lower arithmetic cost. In the camera pipeline, the candidates are MobileNetV2’s pointwise convolutions, which are matrix multiplications over channels, and factoring one trades fewer multiply-accumulates against an extra kernel and an intermediate tensor, the trade-off developed below.

Matrix factorization

Low-rank matrix factorization (LRMF) approximates weight matrices with lower-rank representations. Given a weight matrix \(\WeightMatrix\in \mathbb{R}^{\WeightMatrixRowCount\times \WeightMatrixColumnCount}\), LRMF identifies factor matrices \(\LowRankLeftFactor\in \mathbb{R}^{\WeightMatrixRowCount\times \FactorizationRank}\) and \(\LowRankRightFactor\in \mathbb{R}^{\WeightMatrixColumnCount\times \FactorizationRank}\) such that: \[ \WeightMatrix\approx \LowRankLeftFactor\LowRankRightFactor^T \] where the approximation rank \(\FactorizationRank\ll \min(\WeightMatrixRowCount, \WeightMatrixColumnCount)\). This decomposition is typically computed via singular value decomposition (SVD),8 retaining only the \(\FactorizationRank\) largest singular values. Writing the truncated decomposition as \(\WeightMatrix\approx \LeftSingularVectorMatrix_k \SingularSpectrumMatrix_k \RightSingularVectorMatrix_k^T\) and splitting the singular values evenly between the two factors gives \(\LowRankLeftFactor= \LeftSingularVectorMatrix_k \SingularSpectrumMatrix_k^{1/2}\) and \(\LowRankRightFactor= \RightSingularVectorMatrix_k \SingularSpectrumMatrix_k^{1/2}\). During inference, computing the layer output as \(\HiddenActivation= \LowRankLeftFactor(\LowRankRightFactor^T \LayerInputVector)\) replaces a single large matrix-vector product with two sequential, smaller multiplications. The primary systems question is whether the reduction in parameter footprint and arithmetic operations compensates for the overhead of staging an intermediate activation and dispatching an additional kernel.

8 Singular value decomposition (SVD): The Eckart-Young theorem (1936) proves that retaining the top \(\FactorizationRank\) singular values yields an optimal rank-\(\FactorizationRank\) approximation in the Frobenius and spectral norms. The key systems trade-off is whether the high, one-time compute cost of this factorization, \(\mathcal{O}(\WeightMatrixRowCount \WeightMatrixColumnCount\cdot \min(\WeightMatrixRowCount,\WeightMatrixColumnCount))\), is amortized by the memory and bandwidth savings from using the smaller model in repeated inference calls.

Systems Perspective 10.1: The bandwidth-compute trade-off
Low-rank factorization can reduce both arithmetic and bandwidth demand when the retained rank is small, though it adds a second factor operation and possible kernel-launch overhead. Storing a 4096 by 4096 matrix requires 67.1 MB (at FP32). Fetching this matrix for a single inference imposes substantial memory traffic, especially when execution is limited by physical memory bandwidth.

Factoring the matrix at rank \(\FactorizationRank=\) 128 requires storing two smaller matrices (4096 by 128 and 128 by 4096), totaling only 4.2 MB, a 16× reduction in stored values. When inference uses the two factors directly, matrix-vector arithmetic also falls from \(\mathcal{O}(\WeightMatrixRowCount \WeightMatrixColumnCount)\) to \(\mathcal{O}(\FactorizationRank(\WeightMatrixRowCount+\WeightMatrixColumnCount))\) for small \(\FactorizationRank\). The deployment speeds up only if the two factor operations and their intermediate traffic cost less than the original dense kernel. Explicitly materializing \(\LowRankLeftFactor\LowRankRightFactor^T\) would add \(\mathcal{O}(\WeightMatrixRowCount \FactorizationRank \WeightMatrixColumnCount)\) work and defeat the purpose.

This bandwidth-compute trade-off exemplifies the memory wall at the operator level. When batch sizes are small, execution is bottlenecked by the time required to fetch weight bytes from DRAM rather than the time required to perform multiply-accumulate operations. In production serving engines, evaluating the factored representation avoids full-rank materialization entirely. The original \(\WeightMatrixRowCount\times \WeightMatrixColumnCount\) weight matrix \(\WeightMatrix\) becomes the product of a tall factor \(\LowRankLeftFactor\) (\(\WeightMatrixRowCount\times \FactorizationRank\)) and a wide factor \(\LowRankRightFactor^T\) (\(\FactorizationRank\times \WeightMatrixColumnCount\)) (figure 9).

↪ The AI memory wall, the regime in which arithmetic throughput outpaces the memory bandwidth that feeds it, is developed in The AI memory wall.

Figure 9: Low-Rank Factorization: A weight matrix \(\WeightMatrix\) of size \(\WeightMatrixRowCount{\times}\WeightMatrixColumnCount\) is approximated by two smaller factors, \(\LowRankLeftFactor\) \((\WeightMatrixRowCount{\times}\FactorizationRank)\) and \(\LowRankRightFactor^T\) \((\FactorizationRank{\times}\WeightMatrixColumnCount)\). Storage falls from \(\WeightMatrixRowCount \times \WeightMatrixColumnCount\) to \(\WeightMatrixRowCount \times \FactorizationRank + \FactorizationRank \times \WeightMatrixColumnCount\) parameters, while one dense operation becomes two factor operations.

LRMF applies directly to fully connected projection layers and to flattened convolutional weight tensors. The storage and arithmetic savings derived above are only half of the accounting on a real accelerator. The intermediate activation vector \(\FactoredIntermediateActivation= \LowRankRightFactor^T \LayerInputVector\) must be staged in on-chip SRAM or round-tripped through memory, and dispatching two separate kernels incurs launch latency unless the operations are fused. Furthermore, if the approximation rank \(\FactorizationRank\) is small or unaligned with hardware tile dimensions (such as \(16{\times}16\) systolic arrays), the hardware compute units operate well below peak throughput. Selecting rank \(\FactorizationRank\) therefore balances memory footprint and bandwidth reduction against approximation error, kernel dispatch overhead, and hardware tile utilization.

↪ How a matrix is tiled onto a fixed-size systolic array, and why a dimension just past the tile width drops utilization sharply, is developed in Tiling.

Tensor decomposition (optional depth)

Tensor decomposition extends low-rank approximation to multidimensional arrays, such as four-dimensional convolutional kernels (\(\LayerOutputWidth \times \LayerInputWidth \times \KernelHeight \times \KernelWidth\)) and multi-head attention weights. Matrix factorization could compress such a tensor only after unfolding it into a matrix, which discards which axis was which. Tensor decompositions instead keep each axis separate by representing the tensor through multilinear products of lower-dimensional factors. A three-dimensional tensor \(\DecomposedTensor\in \mathbb{R}^{\TensorRowModeSize\times \TensorColumnModeSize\times \TensorDepthModeSize}\), for example, decomposes into three rank-\(\FactorizationRank\) factor matrices (\(\RowModeFactorMatrix\), \(\ColumnModeFactorMatrix\), and \(\DepthModeFactorMatrix\)), and outer products of the slice vectors \(\RowModeFactorSlice_i\), \(\ColumnModeFactorSlice_j\), and \(\DepthModeFactorSlice_t\) reconstruct entry \(\DecomposedTensorEntry\) (figure 10).

Figure 10: Tensor Decomposition: A three-dimensional tensor \(\DecomposedTensor\in\mathbb{R}^{\TensorRowModeSize{\times}\TensorColumnModeSize{\times}\TensorDepthModeSize}\) is approximated by factor matrices \(\RowModeFactorMatrix\), \(\ColumnModeFactorMatrix\), and \(\DepthModeFactorMatrix\). The highlighted factor vectors \(\RowModeFactorSlice_i\), \(\ColumnModeFactorSlice_j\), and \(\DepthModeFactorSlice_t\) combine across rank \(\FactorizationRank\) to reconstruct the entry \(\DecomposedTensorEntry\). Extending low-rank approximation from two dimensions to three carries the storage and computation argument into convolutional layers. Source: (Gholami et al. 2022).

Formats trade parameter reduction against contraction complexity. CP decomposition (canonical polyadic decomposition) is the form drawn in figure 10. It expresses the tensor as a sum of \(\FactorizationRank\) rank-one components, \(\DecomposedTensor\approx \sum_{\RankComponentIndex=1}^{\FactorizationRank} \RowModeComponentVector \otimes \ColumnModeComponentVector \otimes \DepthModeComponentVector\), where \(\RowModeComponentVector\), \(\ColumnModeComponentVector\), and \(\DepthModeComponentVector\) are column \(\RankComponentIndex\) of \(\RowModeFactorMatrix\), \(\ColumnModeFactorMatrix\), and \(\DepthModeFactorMatrix\) (Lebedev et al. 2015), giving maximal parameter reduction but often unstable rank optimization. Tucker decomposition keeps a small dense core tensor multiplied along each mode by a factor matrix, \(\DecomposedTensor\approx \TuckerCoreTensor\times _1 \RowModeFactorMatrix\times _2 \ColumnModeFactorMatrix\times _3 \DepthModeFactorMatrix\), where \(\times_{\TensorModeIndex}\) multiplies along axis \(\TensorModeIndex\) of the tensor. Tensor-train (TT) stores a many-axis tensor (the order of a tensor is its number of axes) as a chain of small third-order cores, which avoids the exponential growth of Tucker cores with the number of axes.

Lebedev, Vadim, Yaroslav Ganin, Maksim Rakhuba, Ivan Oseledets, and Victor Lempitsky. 2015. “Speeding up Convolutional Neural Networks Using Fine-Tuned CP-Decomposition.” 3rd International Conference on Learning Representations (ICLR).

Tensor decomposition applies to convolutional filters, attention projections, and embedding tables. Its barrier is execution cost, because accelerators are specialized for dense matrix multiplication (GEMM). Contracting decomposed tensors needs transposition kernels or many small contractions, and without fused contraction kernels the data movement and launch latency can erase the arithmetic savings. LRMF and tensor decomposition differ in the data structures they apply to, the compression they achieve, and what they ask of the execution engine (table 4).

Table 4: Matrix and Tensor Factorization: LRMF applies to two-dimensional matrices, while tensor decompositions extend low-rank representations to multidimensional tensors; realized storage and latency depend on rank choice and kernel support.
Feature Low-Rank Matrix Factorization (LRMF) Tensor Decomposition
Applicable Data Structure Two-dimensional matrices Multi-dimensional tensors
Compression Mechanism Factorizes a matrix into two or more lower-rank matrices Decomposes a tensor into multiple lower-rank components
Common Methods SVD; Alternating Least Squares (ALS), which fits one factor at a time CP Decomposition, Tucker Decomposition, Tensor-Train (TT)
Compute cost Depends on the factorization method, selected rank, and kernels Depends on the decomposition, selected ranks, optimization procedure, and tensor-contraction kernels
Storage Reduction Reduces storage from \(\mathcal{O}(\WeightMatrixRowCount \WeightMatrixColumnCount)\) to \(\mathcal{O}(\WeightMatrixRowCount \FactorizationRank+ \FactorizationRank \WeightMatrixColumnCount)\) Depends on the decomposition and selected ranks; stores factor matrices and, for some methods, a core tensor
Inference execution Replaces one dense operation with two factor operations Introduces tensor contractions whose latency depends on available kernels
Primary Use Cases Fully connected layers, embeddings, recommendation systems Convolutional filters, attention mechanisms, multi-modal learning
Implementation Complexity Easier to implement, often involves direct factorization methods More complex, requiring iterative optimization and rank selection

In production pipelines, practitioners frequently combine these structured approximations, applying LRMF to large linear projections and embedding tables while targeting multi-dimensional convolutional layers with tensor decompositions. Under the D·A·M taxonomy, structured approximation alters the Algorithm to relieve Machine memory-capacity and bandwidth bottlenecks. When fetched weights dominate serving latency, reducing weight bytes can reduce that component of execution time. Added factor operations, intermediate tensors, and launch overhead must still be counted; they can offset the saving in either a memory-bound or compute-bound workload.

Pruning and factorization both modify the parameterization of an existing model, and neither can replace an operator that suits the target poorly. If the original operator choices, kernel dimensions, or memory access patterns are ill-suited to the target accelerator, removing or factoring weights cannot substitute more efficient primitives. When deployment limits demand a different topology altogether, the compression objective shifts from subtracting weights to training a compact model to behave like the original.

10.2.3 Knowledge distillation

The camera pipeline’s MobileNetV2 does not have to learn its task from labels alone. A ResNet-50 trained for the same task needs 102.4 MB of FP32 weights and 8.2 GFLOP per image against MobileNetV2’s 14 MB and 600 MFLOP (table 1), far too much arithmetic for the phone’s frame budget, yet its output distribution carries information that labels do not. Knowledge distillation trains a compact student network, here MobileNetV2, to reproduce the output behavior and representations of an overparameterized teacher, here ResNet-50 (Hinton et al. 2015; Sanh et al. 2019). While the term borrows from chemical purification,9 the systems mechanism is algorithmic. Distillation transfers dark knowledge across architectures, amortizing a one-time training phase across millions of lower-latency inference queries.

9 Distillation: The name borrows from the chemical process of separating a mixture. In model compression, the student learns from a teacher’s softened output distribution or internal representations rather than copying its parameters. Soft targets can encode relationships among classes, but the student learns only what its objective and training data expose. The metaphor is useful but not literal, since the temperature parameter comes from softmax scaling, and the size-quality trade-off depends on the student, data, objective, and training procedure (Hinton et al. 2015). Deployment savings come from the student architecture, not from the metaphor itself.

Hinton, Geoffrey, Oriol Vinyals, and Jeff Dean. 2015. “Distilling the Knowledge in a Neural Network.” arXiv Preprint.
Definition 10.3: Knowledge distillation

Knowledge distillation is a model-compression technique that trains a smaller student model to match the behavior of a larger, pretrained teacher model.

  1. Significance: Distillation moves cost from repeated inference to an additional training phase. A student can be substantially smaller than its teacher while retaining useful task performance; DistilBERT, for example, reports 40 percent fewer parameters, 60 percent faster inference, and 97 percent of BERT’s language-understanding performance (Sanh et al. 2019). This trade-off is valuable when the student-training cost is amortized across many deployed queries.
  2. Distinction: Unlike pruning, which removes parameters from an existing architecture, and quantization, which lowers numerical precision, distillation trains a new dense architecture. The student inherits behavior from the teacher’s output distribution or intermediate representations rather than inheriting the teacher’s full parameter count or layer structure.
  3. Common pitfall: A frequent misconception is that distillation is lossless compression. In reality, the student is bounded by its own capacity, the quality of the teacher, and the match between the distillation data and deployment distribution; a student can faithfully reproduce teacher errors as well as teacher knowledge.

Data selection used the teacher’s soft targets as training data (Knowledge distillation); here they become a compression mechanism. Teacher models transfer semantic knowledge through nonzero probabilities assigned across non-target classes. Whereas a one-hot ground-truth label assigns a probability of one exclusively to the correct class, a teacher’s distribution keeps the inter-class correlations known as dark knowledge, revealing that an input classified as a cat (85 percent) shares subtle semantic features with a dog (10 percent) and a fox (5 percent) (figure 11).

Figure 11: Soft Target Distribution: The teacher’s relative confidence levels indicate which classes are semantically similar (for example, cat vs. dog), providing a much richer supervision signal than a binary “correct” label.

Training a student model requires balancing teacher imitation against ground-truth task supervision. Operationally, the workflow requires four decisions before training begins: selecting a teacher with the desired behavior, designing a student whose dense architecture satisfies the target accelerator’s memory and compute budget, generating soft targets over the training corpus, and choosing the temperature and loss weights that govern optimization. In the resulting dual-path pipeline, an input sample \(\ModelInput\) passes through both the teacher and the student, temperature-scaled soft predictions (\(\DistillationTemperature > 1\)) feed the distillation loss, and unscaled student predictions (\(\DistillationTemperature = 1\)) are scored against ground-truth hard labels (figure 12).

Figure 12: Knowledge Distillation Workflow: An input sample passes through both the teacher and the student network. The teacher produces soft labels via temperature-scaled softmax, while the student output is compared against both the soft labels (distillation loss) and the hard labels (student loss).

Deploying the distilled student requires verifying more than top-1 accuracy. Because a student can inherit the teacher’s systematic biases and miscalibrations as readily as its useful representations, verification must measure calibration error, subgroup behavior, and executed latency on the target hardware.

Distillation mathematics

Standard softmax normalization converts raw model logits \(\OutputLogit_i\) into probabilities. Introducing a temperature parameter10 \(\DistillationTemperature\) softens the resulting probability distribution across output classes: \[ \DistillationClassProbability_i = \frac{\exp(\OutputLogit_i/\DistillationTemperature)}{\sum_j \exp(\OutputLogit_j/\DistillationTemperature)} \]

10 Temperature (softmax): The term comes from the Boltzmann distribution in statistical mechanics. Dividing logits by a temperature above one produces a softer distribution and can expose relative probabilities among non-target classes. At \(\DistillationTemperature{=}1\), the expression is standard softmax; increasing the temperature reduces logit gaps but does not guarantee that the revealed probabilities help the student. The useful amount of softening depends on logit scale, teacher calibration, student capacity, loss weighting, and the accompanying \(\DistillationTemperature^2\) factor. Temperature is therefore selected empirically rather than fixed to a universal range.

11 KL divergence: Introduced by Solomon Kullback and Richard Leibler in 1951, \(\KlDivergence(\ReferenceDistribution\lVert \ApproximatingDistribution)\) quantifies the extra bits needed to encode samples from distribution \(\ReferenceDistribution\) using a code optimized for \(\ApproximatingDistribution\). The key asymmetric consequence: \(\KlDivergence(\text{teacher} \lVert \text{student})\) penalizes the student heavily for assigning zero probability to teacher-probable outputs, forcing the student to maintain broad coverage of the teacher’s distribution, including low-probability “soft labels” that carry the teacher’s learned uncertainty. Distillation can affect calibration, which must be evaluated separately.

A higher \(\DistillationTemperature\) flattens the softmax distribution and exposes more of the dark knowledge carried in relative class probabilities, such as a teacher assigning a small but nonzero probability to dog and near-zero probability to truck when classifying an image of a cat. The total distillation loss \(\DistillationLoss\) balances standard cross-entropy with the Kullback-Leibler (KL) divergence against the teacher’s softened distribution:11

\[ \DistillationLoss = (1 - \DistillationLossWeight) \CrossEntropyLoss(\StudentProbabilityVector, \LabelVector) + \DistillationLossWeight\DistillationTemperature^2 \KlDivergence(\SoftenedTeacherProbabilityVector \lVert \SoftenedStudentProbabilityVector) \]

Here \(\SoftenedTeacherProbabilityVector\) and \(\SoftenedStudentProbabilityVector\) are the probability vectors computed at temperature \(\DistillationTemperature\), \(\LabelVector\) is the one-hot ground-truth label vector, and \(\DistillationLossWeight\in [0,1]\) balances the hard-label and soft-target objectives. The scaling factor \(\DistillationTemperature^2\) ensures that the gradient magnitude of the distillation loss remains commensurate with the hard cross-entropy loss. Dividing logits by \(\DistillationTemperature\) scales the derivative of the softmax probabilities by \(1/\DistillationTemperature\), and the gradient of the KL divergence with respect to the student’s logits scales as \(1/\DistillationTemperature^2\) in the high-temperature limit. Multiplying by \(\DistillationTemperature^2\) prevents the teacher’s supervisory gradient from vanishing relative to the hard-label loss as \(\DistillationTemperature\) increases. This formulation defines response-based distillation, matching final output distributions. Modern pipelines also employ feature-based distillation, training intermediate student layers to directly match the teacher’s hidden representations or attention maps using mean squared error or cosine distance to guide gradient updates across deep backbones.

Efficiency gains and trade-offs

Distillation’s primary deployment advantage over unstructured pruning is that it produces a smaller dense model. Standard accelerators achieve peak throughput on contiguous matrix multiplications; unstructured sparse models incur irregular memory access and index decoding overheads that often negate theoretical FLOP reductions unless sparsity is extreme. A compact dense student maintains coalesced memory access and executes vendor-optimized dense GEMM kernels. However, parameter reduction alone does not guarantee lower latency, because operational intensity, layer depth, attention sequence length, and memory bandwidth limits still govern runtime. DistilBERT, for example, is about 60 percent faster (roughly 1.6\(\times\)) primarily because it removes half of BERT’s transformer layers (Sanh et al. 2019). The gap from the ideal 2\(\times\) reflects work that halving the layers does not remove, such as the embedding layer, the task head, and fixed per-request overheads.

Sanh, Victor, Lysandre Debut, Julien Chaumond, and Thomas Wolf. 2019. “DistilBERT, a Distilled Version of BERT: Smaller, Faster, Cheaper and Lighter.” arXiv Preprint arXiv:1910.01108, ahead of print. https://doi.org/10.48550/arXiv.1910.01108.
Gordon, Mitchell, Kevin Duh, and Nicholas Andrews. 2020. “Compressing BERT: Studying the Effects of Weight Pruning on Transfer Learning.” Proceedings of the 5th Workshop on Representation Learning for NLP, 143–55. https://doi.org/10.18653/v1/2020.repl4nlp-1.18.

Distillation composes with pruning and quantization in multi-stage compression pipelines, and the order matters. Quantization usually comes last, because its calibration must see the weight and activation distributions of the final structure. Pruning first and then distilling makes the pruned network itself the student, so distillation doubles as the recovery training after the cut. Section 10.5.3 applies this order to the camera pipeline and to a modeled BERT pipeline. Structural compression can also happen earlier than fine-tuning. Gordon et al. (2020) show that BERT pruned during pretraining transfers to downstream tasks, so the structural step need not wait for a task-specific model.

These operational gains trade inference efficiency for substantial training overhead. Distillation requires running inference across the teacher model to generate soft targets and backpropagating loss through the student across millions of tokens. For large models, this auxiliary training phase consumes significant accelerator FLOPs and memory bandwidth, whereas post-training quantization, introduced later in this chapter, needs only a pass over a small calibration set. Compression effectiveness is also bounded by student capacity and teacher fidelity. An undersized student lacks the capacity to absorb the teacher’s distribution, while an inaccurate or uncalibrated teacher imparts its own systematic errors to the student. Selecting an optimization strategy therefore requires evaluating task accuracy, parameter footprint, serving latency, and total training cost together, the comparison that table 11 in section 10.5 makes for distillation, pruning, and quantization.

Distillation still needs a student architecture, and the student’s own design decides how much of the frame budget remains for everything else. Efficient architecture design and neural architecture search build that student to be efficient on the target by construction.

10.2.4 Efficient architecture design

Hardware-aware design begins before compression. If the target device cannot keep convolution kernels fed, cannot store activations without spilling, or cannot meet the power budget at the chosen input resolution, pruning and quantization only treat symptoms. The architecture itself must expose the kind of work the hardware can execute efficiently. That means choosing layer shapes, scaling rules, and operator patterns with memory bandwidth, parallelism, and energy as first-class constraints rather than post-hoc deployment checks. The efficient families of Network Architectures, among them MobileNetV2’s depthwise separable factorization, are best read here as responses to a measured deployment bottleneck rather than as a catalog of architectures.

Efficient design principles

The first design step is to identify what the trace shows as the limiting resource. A model can miss its target because every layer is too expensive, because one convolution family dominates arithmetic, because activations or parameters do not fit the memory hierarchy, or because the candidate architecture ignores the platform’s preferred operators. Table 5 organizes the common responses by the bottleneck they address rather than by model family.

Table 5: Hardware-Aware Design Principles: A profiling trace should determine which architectural response is appropriate. MobileNet responds to redundant convolutional computation with depthwise separable convolutions, DenseNet and SqueezeNet respond to memory pressure with feature reuse and parameter reduction, and hardware-aware NAS incorporates measured platform behavior directly into the search objective.
Observed bottleneck Architectural response Example networks
Over-budget model scaling Adjust depth, width, and resolution together so the model stays within the latency, memory, and power envelope. EfficientNet
Redundant computation Replace expensive dense operations with factorized or grouped operations that preserve useful channel mixing at lower arithmetic cost. MobileNet, ResNeXt
Memory pressure Reduce parameter storage or reuse features, then check peak activation lifetimes; feature reuse can retain a larger working set. DenseNet, SqueezeNet
Platform mismatch Include measured device latency, operator support, and power behavior in the architecture search or design loop instead of optimizing FLOPs alone. MobileNetV3, MnasNet

These responses interact. Reducing convolutional FLOPs with depthwise separable convolutions helps only if the target runtime has efficient kernels for the resulting operators. Shrinking a model with parameter-reduction layers helps only if activation storage or memory traffic was part of the measured problem. Hardware-aware design therefore does not replace profiling; it moves profiling information earlier, into the architecture itself.

Scaling optimization

The first architectural response is global. When every stage of the profile is over budget, the problem is not one bad layer; the model is scaled incorrectly for the deployment envelope. The design task is then to distribute capacity across depth, width, and input resolution rather than choose a single parameter count: depth adds sequential stages and activation storage, whereas width exposes more parallel work within each stage at the cost of larger weight and activation tensors, and higher input resolution sharpens spatial detail by multiplying the positions every convolution must visit. Which dimension to grow therefore depends on the machine, since a wide parallel accelerator can absorb extra channels while a small edge device is limited first by memory capacity and energy per access.

Mathematically, the total FLOPs for a convolutional model can be approximated as: \[ \Operations\propto \LayerCount \cdot \WidthMultiplier^2 \cdot \InputResolution^2, \] where \(\LayerCount\) is depth (number of layers), \(\WidthMultiplier\) is the width multiplier (channel count relative to a base model), and \(\InputResolution\) is the input resolution. This expression shows why naive scaling fails. Increasing width and resolution together multiplies work quickly, and the resulting model may exceed the memory bandwidth or power budget even when the parameter count appears reasonable.

The camera pipeline’s own architecture exposes one of these knobs directly. MobileNetV2’s width multiplier scales every layer’s channel count, and at a width of 0.75 the network shrinks from 3.5M to 2.6M parameters and from 600 MFLOP to 418 MFLOP per frame, keeping about 70 percent of the arithmetic. The square law predicts a larger cut, because depthwise layers cost in proportion to the width rather than its square, and the network’s final convolution keeps its full width at reduced multipliers. A width setting is therefore a trade the phone can measure directly, in milliseconds per frame, against the accuracy the narrower network loses.

Compound scaling turns this balancing act into a controlled design rule. Instead of adjusting depth, width, and resolution independently, compound scaling grows all three dimensions by fixed ratios \((\DepthScalingRatio, \WidthScalingRatio, \ResolutionScalingRatio)\) relative to a base model: \[ \LayerCount = \DepthScalingRatio^\CompoundScalingCoefficient \BaseLayerCount, \quad \WidthMultiplier= \WidthScalingRatio^\CompoundScalingCoefficient \BaseWidthMultiplier, \quad \InputResolution= \ResolutionScalingRatio^\CompoundScalingCoefficient \InputResolution_0 \] Here, \(\CompoundScalingCoefficient\) is a scaling coefficient, and \(\DepthScalingRatio\), \(\WidthScalingRatio\), and \(\ResolutionScalingRatio\) (as in the original EfficientNet paper) are scaling factors determined from empirical accuracy and efficiency measurements. The rule matters because it prevents one dimension from consuming the budget before the others can contribute useful accuracy.

EfficientNet (section 10.2.5) validated this principle by using search to find a baseline architecture and then scaling it with balanced depth, width, and resolution coefficients (Tan and Le 2019). The lesson is not that every deployment should use EfficientNet. The systems lesson is that scaling is a resource-allocation decision, because the same accuracy target can imply different depth-width-resolution trade-offs depending on which resource the target platform makes scarce. Benchmarking formalizes how to measure those trade-offs; the design principle here is to scale the dimensions against the binding resource.

The same logic extends beyond convolutional models. Transformer layers, attention heads, sequence length, and embedding width play roles analogous to depth, width, and resolution. Each increases capacity, but each stresses compute, memory bandwidth, or activation storage differently. Hardware-aware scaling keeps those dimensions tied to the measured bottleneck instead of treating model size as a single scalar.

Computation reduction

If the profile shows that a small set of convolutional operators dominates arithmetic, reducing the whole model uniformly is wasteful. The better response is to change the expensive operator. Modern efficient architectures do this by factorizing dense computations into cheaper pieces that preserve the representation needed for accuracy.

Depthwise separable convolutions, the factorization behind the MobileNetV2 and KWS lighthouses (Howard et al. 2017; Sandler et al. 2018), are the standard example. They split a standard convolution into a depthwise stage that filters each input channel separately and a pointwise \(1{\times}1\) stage that mixes channels, which cuts the arithmetic to about \(1/\LayerOutputWidth + 1/\KernelSize^2\) of a standard layer with \(\LayerOutputWidth\) output channels and kernel width \(\KernelSize\), roughly one-ninth for \(3{\times}3\) kernels and many output channels. What this chapter adds to that result is the deployment condition. The wall-clock benefit depends on kernel support and memory behavior. A mobile runtime with optimized depthwise kernels can convert much of this arithmetic reduction into latency savings, while a poorly supported backend may expose the factorized operations as many small, memory-bound kernels.

Howard, Andrew G., Menglong Zhu, Bo Chen, Dmitry Kalenichenko, Weijun Wang, Tobias Weyand, Marco Andreetto, and Hartwig Adam. 2017. “MobileNets: Efficient Convolutional Neural Networks for Mobile Vision Applications.” CoRR abs/1704.04861.

↩︎ Depthwise separable convolution and its cost reduction relative to a standard convolution are established in Depthwise separable convolutions.

Other factorization patterns follow the same logic: ResNeXt’s grouped convolutions split feature maps into independent channel groups before merging them, whereas ResNet’s bottleneck blocks and SqueezeNet’s fire modules use \(1{\times}1\) convolutions to narrow the channel dimension before an expensive spatial convolution so that both arithmetic and parameter storage fall. Because all of these rewrites help only when the spatial convolution they shrink actually dominates the trace, they yield much smaller gains once memory traffic, launch overhead, or unsupported kernels become the binding cost.

Arithmetic reduction is only one possible response. When profiling instead identifies memory capacity or data movement as the binding resource on the target device, the architecture must address that memory bottleneck directly.

Memory optimization

When the profile points to memory rather than arithmetic, the architecture must reduce the working set or the number of expensive memory accesses. Activations, feature maps, and parameters can exceed cache, SRAM, accelerator memory, or edge-device storage even when the FLOP count is acceptable. Memory-efficient architectures therefore try to preserve useful information while storing or moving less data.

DenseNet illustrates the feature-reuse response (Huang et al. 2017). In a traditional convolutional network, each layer computes a new set of feature maps, increasing the activation footprint as the network deepens. DenseNet connects layers so later computations can reuse earlier feature maps instead of relearning similar representations. In DenseNet with \(\LayerCount\) layers and growth rate \(\FeatureMapGrowthRate\), each layer generates \(\FeatureMapGrowthRate\) new feature maps concatenated with prior layers, causing the total number of feature maps to grow linearly: \[ \mathcal{O}(\LayerCount \FeatureMapGrowthRate) \]

Huang, Gao, Zhuang Liu, Laurens Van Der Maaten, and Kilian Q. Weinberger. 2017. “Densely Connected Convolutional Networks.” 2017 IEEE Conference on Computer Vision and Pattern Recognition (CVPR), 2261–69. https://doi.org/10.1109/cvpr.2017.243.

DenseNet reduces parameter redundancy through feature reuse, but concatenating retained features can increase activation storage and memory traffic. The resulting working set and runtime must be measured on the target hardware.

Parameter reduction applies the same reasoning to storage. SqueezeNet uses \(1{\times}1\) convolutions to reduce the number of input channels before applying standard convolutions, making the expensive layer operate on a smaller representation (Iandola et al. 2016). The number of parameters in a standard convolutional layer is: \[ \mathcal{O}(\LayerInputWidth \LayerOutputWidth \KernelSize^2) \]

Iandola, Forrest N., Song Han, Matthew W. Moskewicz, Khalid Ashraf, William J. Dally, and Kurt Keutzer. 2016. “SqueezeNet: AlexNet-Level Accuracy with 50x Fewer Parameters and <0.5MB Model Size.” ArXiv Preprint abs/1602.07360.

By reducing \(\LayerInputWidth\) using \(1{\times}1\) convolutions, SqueezeNet reduces parameter count, achieving the paper’s AlexNet-level accuracy target with far fewer parameters than AlexNet. That trade is attractive when the deployment constraint is flash storage, model download size, or parameter bandwidth; it is less decisive when activation memory or operator overhead dominates.

Feature reuse and parameter reduction are therefore not interchangeable recipes: reused features cut redundant representations, whereas \(1{\times}1\) bottlenecks cut parameter movement at deployment, so the profile’s binding memory term decides between them. Each of these manual motifs fixes one operator pattern at a time, leaving open how to choose kernel sizes, expansion ratios, and channel widths jointly across an entire network.

10.2.5 Neural architecture search

Hand-tuning kernel sizes, expansion ratios, and channel widths across twenty or more layers can explore only a handful of the billions of valid configurations that fit a phone’s latency budget, leaving significant accuracy or speed on the table. Neural architecture search (NAS) automates this structural design by systematically traversing a bounded space of operations, topologies, and compound scaling rules prior to training (Elsken et al. 2019). Early reinforcement-learning formulations maximized task accuracy without hardware constraints (Zoph and Le 2016); subsequent weight-sharing methods amortized evaluation overhead (Pham et al. 2018); and hardware-aware NAS explicitly incorporated measured device latency and energy into the multi-objective search (Tan et al. 2019). For the camera pipeline, architecture search is already part of the model’s lineage, since MnasNet and MobileNetV3, MobileNetV2’s successors, came from searches that measured candidate latency on phones (Tan et al. 2019; Howard et al. 2019).

Elsken, Thomas, Jan Hendrik Metzen, and Frank Hutter. 2019. “Neural Architecture Search.” In The Springer Series on Challenges in Machine Learning, vol. 20. Springer International Publishing. https://doi.org/10.1007/978-3-030-05318-5_3.

12 Hardware-aware NAS: Optimizes measured latency rather than FLOPs, which can diverge by 3–5\(\times\) when memory access or operator support dominates. Tan et al. (2019) fed device latency into search and found architectures 1.8\(\times\) faster than MobileNetV2 at higher accuracy.

Tan, Mingxing, Bo Chen, Ruoming Pang, Vijay Vasudevan, Mark Sandler, Andrew Howard, and Quoc V. Le. 2019. “MnasNet: Platform-Aware Neural Architecture Search for Mobile.” 2019 IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR), 2815–23. https://doi.org/10.1109/cvpr.2019.00293.

Discovery runs as a closed loop. The search strategy samples candidate architectures \(\CandidateArchitecture\in \ArchitectureSearchSpace\) from the defined search space, and the performance estimation engine evaluates their latency or accuracy and feeds the result back to refine subsequent proposals (figure 13). NAS12 returns graphs that sit on the Pareto frontier under explicit resource bounds.

Figure 13: Neural Architecture Search Flow: An automated optimization loop for architecture discovery. The search strategy samples candidate subnetworks from a predefined search space, while the performance estimation engine evaluates candidates against target accuracy and hardware constraints (such as latency or energy), feeding reward signals back to steer subsequent exploration toward Pareto-optimal designs.

The NAS optimization problem (optional depth)

NAS rests on three design decisions: the search space, the search strategy, and how each candidate is evaluated. An architecture’s quality cannot be known until it is trained, and training is expensive, which creates two nested decisions: which operations to include (the architecture) and which parameters work best for them (the weights).

NAS is therefore a bi-level optimization problem.13 The outer loop searches the architecture space \(\ArchitectureSearchSpace\), while the inner loop trains candidate architectures to evaluate performance. Formally, the objective seeks the optimal architecture \(\CandidateArchitecture^*\) that minimizes validation loss \(\ValidationLoss\) under constraints \(\ArchitectureResourceCost\) (latency, memory): \[ \CandidateArchitecture^* = \operatorname{arg\,min}_{\CandidateArchitecture\in \ArchitectureSearchSpace} \ValidationLoss(\ModelParameters^*(\CandidateArchitecture), \CandidateArchitecture) \quad \text{subject to} \quad \ArchitectureResourceCost(\CandidateArchitecture) \leq \ResourceCostBudget\] where \(\ModelParameters^*(\CandidateArchitecture)\) represents the optimal model parameters for architecture \(\CandidateArchitecture\), obtained by minimizing training loss: \[ \ModelParameters^*(\CandidateArchitecture) = \operatorname{arg\,min}_{\ModelParameters} \TrainingLoss(\ModelParameters, \CandidateArchitecture) \]

13 Bi-level optimization: A formulation where one optimization problem sits inside another. In NAS, the outer level selects an architecture while the inner level trains that candidate’s weights, so early methods paid a full training cost for every architecture evaluated. Weight-sharing methods such as Efficient Neural Architecture Search (ENAS) amortize one training run across many candidates, reducing search cost by roughly 1,000× (Pham et al. 2018).

Pham, Hieu, Melody Y. Guan, Barret Zoph, Quoc V. Le, and Jeff Dean. 2018. “Efficient Neural Architecture Search via Parameter Sharing.” Proceedings of the 35th International Conference on Machine Learning (ICML), Proceedings of machine learning research, vol. 80: 4095–104.

The computational bottleneck lies in this inner loop. If evaluating every candidate requires independent training from scratch, a modest search space of 10 operation choices across 20 layers yields \(10^{20}\) possible architectures, making exhaustive enumeration impossible. Practical NAS methods overcome this combinatorial explosion through three mechanisms: restricting the search space to reusable cells, amortizing evaluation through weight sharing, or relaxing discrete choices into continuous, differentiable formulations.

Search space design (optional depth)

Many NAS systems search for reusable cells that are stacked to form complete networks, rather than searching whole architectures. A convolutional cell might choose among \(3{\times}3\) convolution, \(5{\times}5\) convolution, depthwise separable convolution, max pooling, or identity connections. A simplified cell with four nodes and two operations per edge yields roughly 10,000 possible cell designs, far more tractable than searching full architectures. NASNet discovered reusable normal and reduction cells this way.

Search spaces also encode hardware constraints by restricting candidate operations to primitives with efficient kernels on the target platform. Mobile search spaces, for example, prioritize depthwise separable convolutions with bounded kernel sizes and channel counts (Zhang et al. 2020). MobileNetV3 paired this structured block-level search space with NetAdapt to prune layer channels against measured mobile CPU latency (Howard et al. 2019).

Zhang, Li Lyna, Yuqing Yang, Yuhang Jiang, Wenwu Zhu, and Yunxin Liu. 2020. “Fast Hardware-Aware Neural Architecture Search.” 2020 IEEE/CVF Conference on Computer Vision and Pattern Recognition Workshops (CVPRW). https://doi.org/10.1109/cvprw50498.2020.00354.

Search strategies (optional depth)

Search strategies trade search cost against architectural diversity (table 6). Reinforcement learning treats search as a sequential decision in which a controller proposes architectures and receives an accuracy reward. It discovered NASNet, but every reward requires training a candidate; Zoph and Le (2016) evaluated roughly 12,800 architectures on 800 GPUs for 28 days, a total of 22,400 GPU-days, a cost that pushed practical NAS toward weight sharing and cheaper performance predictors. Evolutionary algorithms instead mutate and recombine a population of candidates and keep the fittest; AmoebaNet reached ImageNet accuracy competitive with top human-designed models after 3,150 GPU-days (Real et al. 2019), a cost that needs proxy tasks, weight sharing, or massive parallelism to control. Gradient-based methods such as DARTS (Differentiable Architecture Search) (Liu et al. 2019) relax the search space into weighted combinations of all operations and optimize architecture weights and model weights jointly by gradient descent, reducing search cost from hundreds of GPU-days to one to four, though the relaxation may miss discrete patterns that discrete search finds.

Table 6: NAS Search Strategy Comparison: Representative trade-offs between search efficiency, use cases, and limitations for different NAS approaches. The costs are method-specific results from early reinforcement-learning and evolutionary searches and from DARTS, not universal ranges for each strategy (Zoph and Le 2016; Real et al. 2019; Liu et al. 2019).
Zoph, Barret, and Quoc V. Le. 2016. “Neural Architecture Search with Reinforcement Learning.” International Conference on Learning Representations 3.
Real, Esteban, Alok Aggarwal, Yanping Huang, and Quoc V. Le. 2019. “Regularized Evolution for Image Classifier Architecture Search.” Proceedings of the AAAI Conference on Artificial Intelligence 33 (01): 4780–89. https://doi.org/10.1609/aaai.v33i01.33014780.
Liu, Hanxiao, Karen Simonyan, and Yiming Yang. 2019. “DARTS: Differentiable Architecture Search.” International Conference on Learning Representations (ICLR).
Strategy Search Efficiency When to Use Key Challenge
Reinforcement Learning 22,400 GPU-days Novel domains, unconstrained search High computational cost
Evolutionary Algorithms 3,150 GPU-days Parallel infrastructure available Requires large populations
Gradient-Based (DARTS) 1–4 GPU-days Limited compute budget May converge to suboptimal local minima

Hardware-aware NAS optimizes execution metrics on target silicon rather than FLOP counts, which correlate poorly with latency when memory bandwidth or launch overheads dominate. Under the arithmetic intensity law (principle 6), an operation with few FLOPs but low arithmetic intensity can run slower than a higher-FLOP operation that saturates compute. MnasNet addresses this divergence by measuring each candidate’s latency directly on a mobile phone and folding it into the reward, which combines accuracy and latency through a weighted product: \[ \text{Reward}(\CandidateArchitecture) = \text{Accuracy}(\CandidateArchitecture) \times \left(\frac{\TargetInferenceLatency}{\InferenceLatency(\CandidateArchitecture)}\right)^{\LatencyRewardExponent}\] where \(\InferenceLatency(\CandidateArchitecture)\) is the measured on-device inference latency of architecture \(\CandidateArchitecture\), \(\TargetInferenceLatency\) is the latency constraint, and the exponent \(\LatencyRewardExponent\) controls the accuracy-latency trade-off. Architectures that exceed the latency target are penalized. In the reported MnasNet search space, varying inverted-residual expansion ratios produced a stronger accuracy-latency trade-off than uniform expansion.

When to use NAS

Neural architecture search can discover architectures that outperform hand-designed alternatives, but its cost demands a check on whether the investment is justified. NAS can be worthwhile for novel hardware platforms with unusual constraints, such as new accelerator architectures or highly constrained edge devices, where existing architectures are poorly optimized. It can also make sense at deployment scales where small efficiency improvements justify the upfront search cost, or when architecture families for cloud, edge, and mobile deployments can amortize one search across many variants.

Conversely, custom NAS is difficult to justify when standard deployment constraints already have well-optimized architecture families. If the compute budget is only a few GPU-days, large reinforcement-learning or evolutionary searches are impractical; differentiable or weight-sharing methods such as DARTS may remain feasible, but still require deployment-scale and validation-cost justification. Rapidly changing requirements also weaken the case because the target can move before search and validation finish.

For most practitioners, existing NAS-discovered or NAS-assisted architectures provide strong baselines before funding a search from scratch. EfficientNet jointly scales depth, width, and resolution with compound coefficients (Tan and Le 2019), MobileNetV3 combines hardware-aware search with NetAdapt for phone latency targets (Howard et al. 2019), MnasNet folds measured phone latency into its reward (Tan et al. 2019), and FBNet puts device-specific latency into a mobile-CPU search objective (Wu et al. 2019). NAS has also been applied to compact transformer models under compute or memory constraints. These results show what search found under particular spaces, objectives, and measurements, not that search universally beats careful manual design. When latency, memory, or energy enters the objective and is measured on the target platform, the search evaluates candidates against the resource deployment actually constrains, yet the transfer quality of the resulting architectures still depends on task and hardware. Reserve custom NAS for unusual constraints or deployment scales that can amortize the search and validation investment. Even a searched architecture, however, still executes the same fixed graph on every input, spending as much compute on a blank background frame as on a crowded street scene.

Howard, Andrew, Mark Sandler, Bo Chen, Weijun Wang, Liang-Chieh Chen, Mingxing Tan, Grace Chu, et al. 2019. “Searching for MobileNetV3.” 2019 IEEE/CVF International Conference on Computer Vision (ICCV), 1314–24. https://doi.org/10.1109/iccv.2019.00140.
Wu, Bichen, Kurt Keutzer, Xiaoliang Dai, Peizhao Zhang, Yanghan Wang, Fei Sun, Yiming Wu, Yuandong Tian, Peter Vajda, and Yangqing Jia. 2019. “FBNet: Hardware-Aware Efficient ConvNet Design via Differentiable Neural Architecture Search.” 2019 IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR), 10726–34. https://doi.org/10.1109/cvpr.2019.01099.

10.2.6 Adaptive computation methods

A static 24-layer transformer executes identical multiply-accumulate (MAC) operations and streams its entire parameter footprint from HBM or off-chip DRAM for an obvious, easily classified sample as it does for an ambiguous one. Because pruning, distillation, factorization, and architecture search all produce a fixed execution graph, every input follows the same scheduled path regardless of difficulty. Adaptive inference replaces this open-loop pipeline with an input-dependent control loop, in which intermediate representations or runtime budgets decide whether to terminate execution early or which specialized subnetwork receives the activations. While dynamic paths can reduce average arithmetic operations and memory traffic, they introduce runtime overheads in routing logic, batch management, confidence calibration, and latency variance. The camera pipeline is a natural candidate, because many frames are easy and the phone processes one frame at a time. Dynamic pruning applies the idea at the granularity of channels and filters; early exits, conditional layers, and expert subnetworks apply it at coarser grain, where the savings per decision are larger and so is the cost of a wrong one.

Dynamic pruning

Traditional pruning methods, whether unstructured or structured, produce a static pruning mask or subnetwork that remains fixed during deployment, even if the mask was learned gradually during training. Dynamic pruning instead decides at inference time, from each input, which computation is active, so the executed subnetwork changes from one input to the next.

Dynamic pruning can therefore allocate different amounts of work to different inputs and can use, for a hard input, capacity that a static deployment mask would remove permanently. Activation-conditioned pruning, for example, deactivates neurons or channels for particular inputs (Hu et al. 2023). On a simple image with mostly uniform regions, some convolutional filters produce negligible activations, and a dynamic policy can exclude them for that frame. The exclusion reduces nominal work, but the controller sits on the critical path, input-dependent routing fragments execution across SIMD vector lanes, and any quality change remains part of the result. Training may also need routing losses or regularization so that the policy actually uses its cheaper paths. Dynamic pruning is therefore a candidate when input complexity varies enough to repay the controller and batching overhead, not a default substitute for static pruning, and its gain must be measured as latency and accuracy together across the full input distribution.

Hu, Jie, Peng Lin, Huajun Zhang, Zining Lan, Wenxin Chen, Kailiang Xie, Siyun Chen, Hao Wang, and Sheng Chang. 2023. “A Dynamic Pruning Method on Multiple Sparse Structures in Deep Neural Networks.” IEEE Access 11: 38448–57. https://doi.org/10.1109/access.2023.3267469.

↪ Joint evaluation of compressed models on accuracy and target efficiency metrics such as latency, plotted as an efficiency-quality frontier, is measured in Compression validation: The efficiency-quality frontier.

Methods that change the mask during training are sometimes also called dynamic, but they solve a different problem. Gradual magnitude pruning progressively increases the fraction of pruned parameters while fine-tuning the survivors, which is the iterative schedule of section 10.2.1.5 run inside training, and dynamic sparse training additionally regrows connections that prove important later. Both end in a static mask for deployment, so this chapter reserves dynamic pruning for input-dependent execution.

Dynamic schemes

Because input samples vary widely in difficulty, spending the same compute budget on every input wastes memory bandwidth and execution cycles on simple cases. Dynamic schemes modulate execution paths to lower amortized computation while preserving the deep network for worst-case inputs. This architectural flexibility spans four primary control variables: network depth (early exit), structural routing (conditional layer skipping), expert subnetworks (mixture-of-experts), and continuous computational allocation.

To control execution depth, early exit architectures attach auxiliary classification heads to intermediate layers, terminating execution when intermediate representations yield sufficient prediction confidence (Teerapittayanon et al. 2017). BranchyNet implements this mechanism across convolutional backbones using shallow exit branches, whereas multi-exit vision transformers attach linear probes and entropy estimators between transformer blocks (Xin et al. 2021). When an input satisfies an exit criterion, such as softmax prediction entropy dropping below a pre-tuned threshold, the runtime halts evaluation and returns the intermediate prediction. The net operational benefit requires that the arithmetic operations and memory transfers avoided in subsequent layers exceed the computational overhead of evaluating the intermediate classifiers and gating thresholds.

Teerapittayanon, Surat, Bradley McDanel, and H. T. Kung. 2017. “BranchyNet: Fast Inference via Early Exiting from Deep Neural Networks.” 2016 23rd International Conference on Pattern Recognition (ICPR), 2464–69. https://doi.org/10.1109/icpr.2016.7900006.
Hu, Ting-Kuei, Tianlong Chen, Haotao Wang, and Zhangyang Wang. 2020. “Triple Wins: Boosting Accuracy, Robustness and Efficiency Together by Enabling Input-Adaptive Inference.” International Conference on Learning Representations (ICLR).
Chen, Yanxi, Xuchen Pan, Yaliang Li, Bolin Ding, and Jingren Zhou. 2024. “EE-LLM: Large-Scale Training and Inference of Early-Exit Large Language Models with 3D Parallelism.” Proceedings of the 41st International Conference on Machine Learning (ICML).

The systems trade-off diverges sharply across hardware deployment targets. On single-sample edge processors (batch size \(\BatchSize=1\), typical of microcontrollers and mobile NPUs), early exit immediately terminates the execution thread (Hu et al. 2020). Skipping remaining layers eliminates both the arithmetic operations and the off-chip DRAM transactions required to load subsequent layer weights into on-chip SRAM cache. Conversely, on parallel throughput accelerators (GPUs and TPUs) processing batched workloads (\(\BatchSize> 1\)), early exit introduces severe batch fragmentation (Chen et al. 2024). If only a subset of samples in a batch reaches the exit threshold, the remaining samples must still traverse deeper layers. Unless the runtime executes dynamic batch compaction (gathering unresolved activation tensors into a contiguous memory buffer through memory copies and kernel synchronizations), inactive samples remain allocated in memory, or the accelerator must mask inactive SIMD or single instruction, multiple threads (SIMT) lanes. Consequently, tail latency for the batch remains dictated by the deepest traversing sample. Along a transformer backbone, each block taps its intermediate representation into an auxiliary classifier and a learned confidence estimator (learning to exit, LTE) that can trigger an early exit, while unresolved inputs continue to deeper layers (figure 14).

↪ The latency-throughput trade-offs of batching under production request streams, including service-level objective (SLO) violations, are developed in Dynamic batching latency-throughput trade-offs.

Figure 14: Early Exit Architecture: Transformer layers dynamically adjust computation by classifying each layer’s output and enabling early termination if sufficient confidence is reached, reducing average latency and power when many inputs can exit before the final layer. Source: (Xin et al. 2021).
Xin, Ji, Raphael Tang, Yaoliang Yu, and Jimmy Lin. 2021. “BERxiT: Early Exiting for BERT with Better Fine-Tuning and Extension to Regression.” In Proceedings of the 16th Conference of the European Chapter of the Association for Computational Linguistics: Main Volume, edited by Paola Merlo, Jorg Tiedemann, and Reut Tsarfaty. Association for Computational Linguistics. https://doi.org/10.18653/v1/2021.eacl-main.8.

Where early exit truncates depth along a single linear pipeline, conditional computation dynamically modulates the topological routing of activations through the network graph (Bengio et al. 2015). Instead of executing every block in a predefined sequence, gating functions evaluate activation tensors to bypass residual layers, alter operator kernels, or select specialized functional blocks. This converts a static directed acyclic graph (DAG) into an input-dependent dynamic graph.

Bengio, Emmanuel, Pierre-Luc Bacon, Joelle Pineau, and Doina Precup. 2015. “Conditional Computation in Neural Networks for Faster Models.” arXiv Preprint arXiv:1511.06297.
Wang, Xin, Fisher Yu, Zi-Yi Dou, Trevor Darrell, and Joseph E. Gonzalez. 2018. “SkipNet: Learning Dynamic Routing in Convolutional Networks.” In European Conference on Computer Vision (ECCV). Springer. https://doi.org/10.1007/978-3-030-01261-8_25.

SkipNet illustrates the pattern at the granularity of whole blocks. It uses lightweight recurrent or feedforward gating controllers to conditionally bypass residual blocks in convolutional networks, preserving full network depth only for computationally difficult inputs (Wang et al. 2018). From a hardware systems perspective, conditional routing achieves wall-clock speedups only when the cycles saved by bypassing operators surpass the latency of evaluating the gating network, executing host-device control synchronization, and managing uncoalesced memory accesses.

In a dense transformer, every token computes against every weight matrix, so parameter capacity and per-token compute grow together. The mixture-of-experts (MoE) architecture decouples them by replacing dense feedforward network (FFN) layers with a bank of parallel expert subnetworks coordinated by a parameterized router (Shazeer et al. 2017). Google’s Switch Transformer14 steers each token to a single expert (\(\RoutedExpertCount=1\)), which reduces communication overhead relative to routing to \(\RoutedExpertCount> 1\) experts (Fedus et al. 2022).

14 Switch Transformer: Fedus et al. (2022) scales to roughly 1.6 trillion total parameters while routing each token to one expert; in a compute-matched experiment, Switch-Base with 64 experts reached the T5-Base quality target in about one-seventh the training time; the trillion-parameter comparison reported roughly 4\(\times\) speedup over T5-XXL. Routing each token to one expert reduces communication relative to routing to \(\RoutedExpertCount> 1\) experts, but load imbalance requires auxiliary losses and capacity factors, which cap how many tokens each expert accepts per batch. This trade-off, massive parameter capacity at low per-token compute cost in exchange for complex load-balancing engineering, defines the MoE design space.

Fedus, William, Barret Zoph, and Noam Shazeer. 2022. “Switch Transformers: Scaling to Trillion Parameter Models with Simple and Efficient Sparsity.” Journal of Machine Learning Research 23 (120): 1–39.
Lepikhin, Dmitry, HyoukJoong Lee, Yuanzhong Xu, Dehao Chen, Orhan Firat, Yanping Huang, Maxim Krikun, Noam Shazeer, and Zhifeng Chen. 2021. “GShard: Scaling Giant Models with Conditional Computation and Automatic Sharding.” International Conference on Learning Representations (ICLR).

Sparse activation trades compute for memory. A token routed to one of \(\ExpertCount\) experts executes arithmetic against only \(1/\ExpertCount\) of the expert parameters, yet an all-resident deployment keeps all \(\ExpertCount\) expert matrices in device memory. In a Switch Transformer block, a Switching FFN layer sits inside the standard transformer stack, and its gating router dispatches individual tokens (“More” with \(\RouterGateProbability=0.65\), “Parameters” with \(\RouterGateProbability=0.8\)) to distinct expert sub-blocks (FFN 2 and FFN 1) while unselected experts stay idle (figure 15). Because the router lies on the critical path, the runtime must gather tokens assigned to the same expert into contiguous tiles (Lepikhin et al. 2021); at low batch sizes or under a skewed routing distribution, divergent routing leaves some experts with too few tokens to keep matrix units busy and overloads others, forcing the runtime either to truncate tokens or to launch kernels that leave lanes idle.

Figure 15: Switch Transformer Architecture: Replacing dense feedforward layers with a Switching FFN layer (left) enables sparse conditional routing. A gating network routes each token to a single expert (right) out of a large pool, decoupling total model capacity (parameters) from per-token compute cost (FLOPs). Source: (Fedus et al. 2022).

↪ How runtimes execute tensors whose shapes vary, by matching precompiled shape profiles, padding, splitting the batch, or falling back to a general kernel, is developed in Dynamic kernel execution.

Yang, Le, Yizeng Han, Xi Chen, Shiji Song, Jifeng Dai, and Gao Huang. 2020. “Resolution Adaptive Networks for Efficient Inference.” 2020 IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR), 2366–75. https://doi.org/10.1109/cvpr42600.2020.00244.
Wu, Zuxuan, Tushar Nagarajan, Abhishek Kumar, Steven Rennie, Larry S. Davis, and Rogerio Feris. 2018. “BlockDrop: Dynamic Inference Paths in Residual Networks.” IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR), 8817–26. https://doi.org/10.1109/cvpr.2018.00919.

Early exit and MoE routing make discrete branch selections, but adaptive inference can also modulate depth or iteration counts continuously according to task difficulty (Yang et al. 2020). BlockDrop adjusts the number of active layers with a runtime policy network (Wu et al. 2018), and dynamic layer scaling adds computation until output uncertainty drops below a calibrated threshold. In an embedded vision system, high-contrast frames with clear road geometry resolve through a minimal prefix of layers, whereas degraded frames with occluded obstacles trigger deeper processing. The gain materializes only if the control evaluation remains computationally lightweight and the runtime schedules frames with matched execution depths concurrently to maintain high hardware utilization.

Implementation challenges

Realizing the efficiency gains of adaptive computation requires overcoming challenges across optimization, runtime orchestration, and hardware execution. During training, discrete routing decisions (such as non-differentiable \(\mathrm{argmax}\) branch selections) break standard gradient-based backpropagation. Practitioners overcome this with continuous relaxations such as the Gumbel-Softmax estimator, which replaces hard selections with smooth approximations so gradients flow, with policy gradients that reinforce routing choices that earn a reward, or with auxiliary load-balancing losses that keep routers from collapsing onto a single favored expert (Shazeer et al. 2017).

Shazeer, Noam, Azalia Mirhoseini, Krzysztof Maziarz, Andy Davis, Quoc Le, Geoffrey Hinton, and Jeff Dean. 2017. “Outrageously Large Neural Networks: The Sparsely-Gated Mixture-of-Experts Layer.” International Conference on Learning Representations (ICLR).

At runtime, control-flow branching conflicts with the lockstep execution of modern accelerators, where the threads of a warp execute the same instruction. When threads within a GPU warp take divergent branches, the hardware may serialize them and mask inactive threads, which erodes the theoretical FLOP savings. Gating also introduces control dependencies that can limit fusion, require token-permutation buffers, or trigger host-device synchronization. If these dispatch overheads exceed the compute time saved by skipping layers, the dynamic model has higher end-to-end latency than a dense baseline. Runtime strategies such as ragged batching and dynamic kernel launch queues manage these patterns, and they belong to the accelerator runtime rather than to the model.

Dynamic control also adds quality and security failure modes. Poorly calibrated gates underallocate computation to rare inputs, which degrades accuracy on safety-critical edge cases, and adversarial perturbations can push the gates toward truncated early exits or maximally deep paths. Evaluating adaptive models therefore cannot rely on average FLOP counts alone. Rigorous system profiling must report path distribution histograms, tail latency (p99), accuracy stratified by input difficulty, and throughput stability under dynamic batching, and a production deployment keeps monitoring route frequency and quality by route after launch.

↪ Infrastructure telemetry that tracks latency distributions in deployed systems, alongside the model-quality signals production monitoring pairs with it, is developed in Infrastructure telemetry and hardware utilization.

The structural techniques covered so far (pruning, low-rank factorization, distillation, efficient architecture design, NAS, and adaptive computation) all optimize what computations the model performs, including which parameters exist, which connections remain, how the architecture is structured, and which paths a given input executes. These techniques can substantially reduce parameter counts and theoretical FLOPs. Regardless of structural efficiency, every surviving weight and activation must still be stored and processed at some numerical precision.

Checkpoint 10.1: Choosing a structural method

Structural methods relocate deployment cost in different ways.

Structural optimizations alter what a model computes, but the surviving graph must still execute within the physical memory bandwidth, register files, and cache hierarchies of the target silicon. When structural pruning and distillation have carved away unnecessary parameters and layers, every remaining operation continues to incur a memory-movement and arithmetic cost determined entirely by its bit representation. Optimizing this numerical representation forms the second tier of the optimization stack, and its clearest case is a workload whose time is set by bytes rather than by arithmetic.

Self-Check: Question
  1. A team prunes ResNet-50 to \(50\%\) sparsity using unstructured magnitude pruning and observes only a \(1.1\times\) speedup on a commodity GPU. Switching to structured channel pruning at the exact same \(50\%\) sparsity yields a \(1.8\times\) speedup. Which systems mechanism best explains this difference?

    1. Structured pruning removes more total weight parameters than unstructured pruning at any given nominal sparsity percentage
    2. Structured pruning removes entire contiguous channels or filters, allowing smaller dense kernels to execute efficiently, whereas unstructured sparsity needs sparse storage, metadata, and irregular activation access
    3. Unstructured magnitude pruning requires zero retraining or fine-tuning, whereas structured channel pruning requires full retraining from scratch
    4. Commodity GPU memory controllers automatically coalesce random non-zero memory addresses into single-cycle burst transfers
  2. Order the stages of finding a winning lottery ticket in a neural network according to the Lottery Ticket Hypothesis (LTH): (1) Reset surviving weights to their original initialization values (\(W_0\)), (2) Train the dense unpruned network to convergence, (3) Retrain the sparse subnetwork to convergence, (4) Prune the lowest-magnitude weights to create a sparse mask.

  3. A team must compress a large transformer model for deployment across a fleet of commodity GPUs that lack dedicated sparse-matrix acceleration kernels. Which structural optimization technique is the strongest candidate for producing a smaller model that still executes efficiently on this hardware?

    1. Unstructured magnitude pruning, because sparse matrix multiplication routines run with zero memory overhead on all standard GPUs
    2. Extreme binary weight quantization, because 1-bit representations eliminate all memory traffic without degrading language model perplexity
    3. Knowledge distillation, because it transfers teacher behavior into a compact dense student architecture that runs well on standard dense GPU kernels
    4. Low-rank factorization without fine-tuning, because mathematical decomposition guarantees zero loss in representation capacity
  4. A square weight matrix of size \(4096 \times 4096\) in a transformer layer is decomposed using low-rank factorization at rank \(r = 128\). Calculate the theoretical reduction factor in both parameter count and multiply-accumulate (MAC) operations, and explain what trade-off this structural approximation introduces.

  5. An engineering organization is deciding between running a custom Neural Architecture Search (NAS) from scratch versus adopting an established NAS-discovered family (such as MobileNetV3 or EfficientNet). Which circumstance most strongly justifies investing in custom NAS?

    1. Novel or custom hardware accelerators with unique memory hierarchies or massive production deployment scale where small per-inference efficiency gains amortize large one-time search costs
    2. Standard GPU clusters running established vision benchmarks where off-the-shelf architectures like MobileNetV3 already fit latency budgets
    3. Rapid prototyping projects with a total engineering timeline under one week and fewer than 10 available GPUs
    4. Small-scale enterprise applications processing fewer than 1,000 queries per day on cloud instances
  6. Compare one-shot pruning with an iterative schedule that removes 10 percentage points of the original weights in each of 8 rounds with recovery between rounds. Explain why staged recovery can help, and what controlled comparison is needed before concluding that the iterative schedule is better.

See Answers →

10.3 Numerical Precision: Changing How Values Are Stored

GPT-2 XL decoding on the phone shows what structural changes leave untouched. Its FP16 weights fit in the phone’s memory, yet every generated token streams all 3 GB of them across a 51.2 GB/s bus, about 59 ms per token before any arithmetic (table 1). Pruning or factorizing its layers would change which weights exist; the complementary optimization leaves the network topology unaltered and reduces the bit width of every surviving tensor. Quantization trades numerical precision for a smaller memory footprint, higher cache utilization, and higher arithmetic throughput on hardware with integer datapaths.

Definition 10.4: Quantization

Quantization is a model-compression technique that reduces information fidelity by mapping high-precision continuous values to a lower-precision discrete set.

  1. Significance: FP32-to-INT8 conversion reduces the raw payload per quantized value by 4\(\times\). Real artifact size, traffic, and latency also depend on scales, metadata, packing, operator coverage, and the target kernels.
  2. Distinction: Unlike pruning, which reduces the count of parameters, quantization reduces the bit depth of selected weights and/or activations.
  3. Common pitfall: A frequent misconception is that quantization is just “rounding.” In reality, it is a lossy mapping that requires careful range estimation and, often, quantization-aware training (QAT) to minimize its impact on accuracy.

Quantization15 concerns every neural network weight and activation stored at some numerical precision: FP32 (32 bits), FP16 (16 bits), INT8 (8 bits), or lower. Bit width sets how many bytes each value occupies, how much cache it uses, and how fast specialized matrix engines can run.

15 Quantization: Rooted in Shannon’s theory of representing continuous signals with discrete values (Shannon 1948), reducing FP32 to INT8 collapses over four billion representable values to just 256. Neural networks often tolerate this because trained weights concentrate information in relative magnitudes, not absolute precision: INT8 inference can stay close to the full-precision baseline with appropriate calibration or quantization-aware training, while INT4 and lower-bit methods become more architecture- and method-dependent (Jacob et al. 2018; Gholami et al. 2022; Shen et al. 2020; Lin et al. 2024). The systems consequence is that quantization viability must be validated per-model and per-task, not assumed from aggregate benchmarks.

Shannon, Claude E. 1948. “A Mathematical Theory of Communication.” Bell System Technical Journal 27 (3): 379–423. https://doi.org/10.1002/j.1538-7305.1948.tb01338.x.
Jacob, Benoit, Skirmantas Kligys, Bo Chen, Menglong Zhu, Matthew Tang, Andrew Howard, Hartwig Adam, and Dmitry Kalenichenko. 2018. “Quantization and Training of Neural Networks for Efficient Integer-Arithmetic-Only Inference.” 2018 IEEE/CVF Conference on Computer Vision and Pattern Recognition, 2704–13. https://doi.org/10.1109/cvpr.2018.00286.
Gholami, Amir, Sehoon Kim, Zhen Dong, Zhewei Yao, Michael W. Mahoney, and Kurt Keutzer. 2022. “A Survey of Quantization Methods for Efficient Neural Network Inference.” In Low-Power Computer Vision: Improve the Efficiency of Artificial Intelligence. Chapman; Hall/CRC. https://doi.org/10.1201/9781003162810-13.

↪ How accelerators trade precision and dynamic range for matrix-engine throughput, pairing low-precision inputs with higher-precision accumulation, is developed in Numerics and sparsity on the datapath.

Gupta, Suyog, Ankur Agrawal, Kailash Gopalakrishnan, and Pritish Narayanan. 2015. “Deep Learning with Limited Numerical Precision.” International Conference on Machine Learning (ICML), 1737–46.
Wang, Yu Emma, Gu-Yeon Wei, and David Brooks. 2019. “Benchmarking TPU, GPU, and CPU Platforms for Deep Learning.” arXiv Preprint arXiv:1907.10701.

Quantization transforms three physical terms of execution. First, converting FP32 to INT8 reduces raw weight payload by 4\(\times\) before scale and packing metadata, allowing models to fit within constrained device memories. Second, when tensors remain packed across memory buses, memory traffic drops proportionally, directly reducing token latency in bandwidth-bound autoregressive decoding. Third, fixed-point integer arithmetic units occupy smaller silicon area and consume significantly less energy per operation than floating-point units, enabling higher compute density on supported hardware (Gupta et al. 2015; Wang et al. 2019).

The accuracy cost varies by model, task, quantizer, calibration data, and bit width. Many convolutional neural network (CNN) inference models tolerate INT8 well; transformers, speech models, and outlier-heavy layers may need different granularity, mixed precision, or training-aware methods. The main approaches are post-training quantization (PTQ), quantization-aware training (QAT), and mixed-precision or extreme quantization for lower-bit deployment. They differ in training cost and control, not in a guaranteed ordering of accuracy.

The viability of each approach depends on how much precision a given model architecture can shed before quality degrades. Across precision formats from FP32 down to INT2, both CNN and transformer curves follow a low-loss plateau where INT8 quantization closely matches full-precision performance, followed by a steep accuracy cliff at lower bit widths where representational capacity breaks down. Because tolerable accuracy degradation depends on end-to-end application constraints, engineering teams must evaluate these cliff boundaries for each target workload and range-calibration recipe (figure 16).

Figure 16: Illustrative Quantization Regimes: The curves depict a qualitative plateau followed by an accuracy cliff as bit width falls. Their breakpoints are illustrative; actual boundaries depend on the model, layer distributions, quantizer, calibration or training method, and evaluation task.

10.3.1 Numerical formats

Cutting a tensor from 32 bits to 16 or 8 bits can still overflow on large activation outliers if the format lacks exponent range, or stall in software unpacking if the target processor lacks a native datapath for that bit width. How a format divides its bits between exponent range and fraction precision decides which values survive conversion, and whether the silicon provides a matching execution unit decides whether narrower values run any faster. Because neither property follows from bit count alone, selecting a numerical format requires balancing dynamic range and hardware execution support against memory traffic rather than minimizing bit width blindly. The formats commonly deployed across accelerator architectures differ in raw storage, peak arithmetic rate, and hardware support, each measured against standard 32-bit floating point (FP32) (table 7).

Table 7: Numerical Precision Formats: Storage ratios reflect raw value width; compute speed and power effects depend on hardware support and workload behavior.
Precision Format Bit-Width Storage Reduction (vs. FP32) Compute Speed (vs. FP32) Power Effect Use Cases
FP32 32-bit Baseline (1\(\times\)) Baseline (1\(\times\)) Baseline Training & inference (general-purpose)
FP16 16-bit 2\(\times\) smaller Up to 2\(\times\) peak on selected supported hardware Hardware- and workload-dependent Accelerated training, inference (NVIDIA Tensor Cores, TPUs)
BF16 (Brain Floating Point) 16-bit 2\(\times\) smaller Hardware- and workload-dependent Hardware- and workload-dependent Training on TPUs, transformer-based models
TF32 (TensorFloat-32) 19-bit None (stored as FP32) Up to 8\(\times\) peak on NVIDIA Ampere Tensor Cores Hardware- and workload-dependent Training on NVIDIA GPUs
FP8 (E4M3, E5M2) 8-bit 4\(\times\) smaller 2× the dense FP16 peak on the H100 Hardware- and workload-dependent Inference and training on recent data-center accelerators
INT8 (8-bit Integer) 8-bit 4\(\times\) smaller Hardware- and workload-dependent Hardware- and workload-dependent Quantized inference (Edge AI, mobile AI, NPUs)
INT4 (4-bit Integer) 4-bit 8\(\times\) smaller Hardware- and workload-dependent Hardware- and workload-dependent Ultra-low-power AI, experimental quantization
Binary/Ternary (1-bit/2-bit) 1–2-bit 16–32\(\times\) smaller Hardware- and workload-dependent Hardware- and workload-dependent Extreme efficiency (binary/ternary neural networks)

At 16 bits, FP16 and BF16 halve memory storage relative to FP32 while targeting dedicated matrix execution units (such as NVIDIA Tensor Cores and Google TPUs) to accelerate arithmetic throughput. The range-versus-precision trade between them is established with mixed-precision training in Mixed-precision training, and figure 17 shows the bit layouts that set it. BF16 keeps FP32’s 8-bit exponent and therefore its dynamic range, whereas FP16 spends more bits on the fraction and caps finite values at 65,504, which is why FP16 training needs loss scaling and BF16 training does not. For inference, the same range limits decide whether activations with large outliers survive the narrower format. TensorFloat-32 (TF32) adopts a hybrid compromise. It retains the 8-bit exponent of FP32 and the 10-bit fraction of FP16, executing on Tensor Cores to accelerate matrix multiplication while storing values in standard 32-bit memory.

Figure 17: Floating-Point Bit Layouts: Bit allocation trades dynamic range against significand precision. FP32 uses 8 exponent and 23 fraction bits. BF16 retains FP32’s 8-bit exponent and therefore a similar numerical range, but reduces the fraction to 7 bits. FP16 uses 5 exponent and 10 fraction bits, providing more significand precision than BF16 but a narrower range that can require loss scaling during training.

For inference workloads, INT8 precision provides a fourfold reduction in raw storage relative to FP32 when the chosen quantizer preserves acceptable prediction accuracy. Inference avoids the gradient backpropagation pass, eliminating the small-magnitude, high-dynamic-range updates that cause underflow during training. Activations and weights can still contain outliers or sensitive values, so range calibration or QAT must validate mapping them onto signed 8-bit integers (\([-128, 127]\)) using uniform affine or symmetric quantization scales. In bandwidth-limited inference regimes, such as autoregressive language model token generation, this \(4\times\) footprint reduction relieves memory bus contention by cutting DRAM and cache traffic. On compute-bound operators, dedicated INT8 vector and tensor units provide higher arithmetic operation density per clock cycle and per unit of silicon area than equivalent floating-point units.

FP8 gets its own row because it is the first 8-bit format that keeps an exponent. It comes in two layouts, each with one sign bit: E4M3, with four exponent and three mantissa bits, for weights and activations, and E5M2, with five exponent and two mantissa bits, for the wider range of gradients (Micikevicius et al. 2022). Like INT8, it halves the bytes of FP16, and on the reference H100 its peak matrix rate equals the INT8 rate, 2× the dense FP16 peak. Unlike INT8, it needs no zero-point, and its exponent absorbs the outliers that force an integer format to choose between clipping and resolution, so a model often converts to FP8 with less range-calibration effort than to INT8. FP8 as the default serving precision on such accelerators is developed in Model Serving. Microscaling formats carry the same idea below eight bits (Rouhani et al. 2023). A block of values, typically 32, shares one 8-bit power-of-two scale, so the elements of an MXFP8, MXFP6, or MXFP4 block borrow their range from the shared exponent and spend their few bits on precision. They are an awareness item here, because their payoff depends on accelerators with native support.

Micikevicius, Paulius, Dusan Stosic, Neil Burgess, Marius Cornea, Pradeep Dubey, Richard Grisenthwaite, Sangwon Ha, et al. 2022. “FP8 Formats for Deep Learning.” arXiv Preprint arXiv:2209.05433.
Rouhani, Bita Darvish, Ritchie Zhao, Ankit More, Mathew Hall, Alireza Khodamoradi, Summer Deng, Dhruv Choudhary, et al. 2023. “Microscaling Data Formats for Deep Learning.” arXiv Preprint arXiv:2310.10537.

Binary and ternary formats occupy the far end of table 7, constraining values to \(\{-1, +1\}\) or \(\{-1, 0, +1\}\) so that multiplication collapses into bitwise logic or a conditional add. They promise the largest storage ratio in the table, but byte-addressed memory and training stability make them a special case that section 10.3.4 develops in full. The keyword-spotting lighthouse shows why such formats are considered at all. Under the strict ~512 KB SRAM budget, INT8 is the baseline target, and INT4, binary, or ternary representations trade additional dynamic range to meet stricter memory and power bounds. Whereas table 7 counts bytes and peak rates, what each format saves in joules depends on where its bits travel, which is the subject of the energy comparison that follows.

10.3.2 Precision and energy

In silicon, energy dissipation scales directly with wire capacitance (\(\SwitchingEnergy\propto \SwitchedCapacitance \SupplyVoltage^2\)), so shuttling bits across long memory buses costs orders of magnitude more joules than toggling logic gates inside an arithmetic logic unit. Because physical data movement so often dominates a workload’s power budget, choosing a numerical precision is an energy decision governed by the number and location of memory accesses alongside the arithmetic performed. Reducing numerical precision directly shrinks the byte volume traversing the memory hierarchy (\(\DataVolume\)) and lowers the switching energy per ALU operation (\(\EnergyPerOperation\)), relaxing memory bandwidth and thermal bottlenecks across the hardware stack.

↪ Accelerator designs that keep operands in registers and on-chip SRAM, away from costly off-chip DRAM, are developed in Machine learning hardware specialization.

Where precision saves energy

Precision saves energy in two places, and the larger one is usually movement. The energy-movement principle (7), \(\EnergyPerByteMoved \gg \EnergyPerOperation\), says that moving an operand costs far more than operating on it (Horowitz 2014). In the reference technology model, a 32-bit read from off-chip DRAM costs about 640 pJ, roughly 2,100× the energy of the INT8 multiply-accumulate that consumes it, and the cost keeps rising as data leaves the chip for storage or the network (Energy Cost of Moving vs. Computing on a 32-Bit Value). A packed INT8 stream carries one quarter of the raw value bits of an FP32 stream, so each weight or activation that crosses the memory bus costs about a quarter of the movement energy, provided transactions stay full; caches, metadata, alignment, and transaction size set the realized saving. The reference measurements predate FP8, but an FP8 value moves the same eight bits as an INT8 value, so the movement saving applies to it unchanged.

Arithmetic supplies the second saving (table 8). An FP32 addition costs 0.9 pJ/op and an INT8 addition 0.03 pJ/op, a ratio of 30×; an FP32 multiply costs 3.7 pJ/op and an INT8 multiply 0.2 pJ/op, a ratio of 18.5×. Every multiply-accumulate a matrix unit performs combines the two, so the figure that governs a format decision is their combination. Because INT8 products accumulate in INT32, a full INT8 multiply-accumulate uses roughly 15× less energy than its FP32 equivalent, on top of the 4\(\times\) cut in bytes moved. Numbers to Know collects the reference energy ratios, and Numerical Representations compares numerical format trade-offs.

Table 8: INT8 versus FP32 Energy per Operation: Reference 45 nm energy for one add, one multiply, and one multiply-accumulate at each precision. The INT8 multiply-accumulate sums its products in INT32, so its cost is an INT8 multiply plus an INT32 add, which is why its ratio is the smallest of the three. A 32-bit DRAM read, at 640 pJ, costs more than every row here combined. Total inference energy also depends on operation counts, access counts, and where operands reside (Horowitz 2014).
Horowitz, Mark. 2014. “1.1 Computing’s Energy Problem (and What We Can Do about It).” 2014 IEEE International Solid-State Circuits Conference Digest of Technical Papers (ISSCC), 10–14. https://doi.org/10.1109/isscc.2014.6757323.
Operation FP32 (pJ) INT8 (pJ) FP32 / INT8
Add 0.90 0.03 30×
Multiply 3.70 0.20 18.5×
Multiply-accumulate 4.60 0.30 15×

Accelerators equipped with native low-precision units (such as NVIDIA Tensor Cores, Google TPUs, or mobile NPUs) compound these arithmetic savings with reduced memory traffic. In contrast, general-purpose processors lacking native low-precision execution pipelines lose much of this benefit to the runtime overhead of bit unpacking, format conversion, and scalar fallback. Precision is therefore a model-hardware decision, not a software configuration flag.

Which saving matters depends on where the workload sits. Under the iron law of ML systems (principle 3), reducing bit width changes the data-movement \((\DataVolume/\Bandwidth)\) and compute \((\Operations/(\PeakRate \cdot \EfficiencyHw))\) terms only through the execution path that uses the new representation. Workloads with little arithmetic per byte are memory bound, so shrinking data movement dominates; workloads with more arithmetic per byte are compute bound, so arithmetic savings matter more, a distinction the roofline model in The roofline model formalizes. Neither ratio predicts battery life on its own, because end-to-end energy also includes control, sensors, and idle power. When memory capacity binds, the more immediate benefit is placement, because smaller values may let the model reside in a memory tier that the uncompressed model cannot fit.

Three stacked boxes labeled D Data, A Algorithm, and M Machine, with the M Machine box highlighted.

The machine’s memory capacity, not arithmetic, now sets the constraint.

Recommendation models convert the energy argument into a placement problem, in which quantization must shrink the dominant memory structures enough to reside in the host machine’s physical memory. When an embedding table outgrows a single accelerator’s HBM, reducing bytes per entry determines whether the table fits on the node at all.

Lighthouse 10.1: DLRM and embedding quantization
The DLRM lighthouse presents a compression challenge where memory capacity, rather than compute throughput or memory bandwidth, is the binding constraint (Naumov et al. 2019). Even the reference configuration in table 1 needs 100 GB of weights, more than one accelerator’s memory, and production embedding tables can grow to terabytes that must be sharded across many devices.

For DLRM, quantization targets storage density rather than arithmetic throughput. Reducing embedding-table precision from FP32 to INT8 (or lower) shrinks the memory footprint by 4–8\(\times\), allowing larger tables to fit on fewer GPUs when accuracy and lookup kernels tolerate the lower precision. Compressing the lookup tables ensures that physical device memory can accommodate the algorithmic model.

Naumov, Maxim, Dheevatsa Mudigere, Hao-Jun Michael Shi, Jianyu Huang, Narayanan Sundaraman, Jongsoo Park, Xiaodong Wang, et al. 2019. “Deep Learning Recommendation Model for Personalization and Recommendation Systems.” arXiv Preprint arXiv:1906.00091.

Lighthouse 10.2: Keyword spotting and the SRAM budget
The KWS lighthouse, DS-CNN, operates at the opposite extreme of the iron law from DLRM (Y. Zhang et al. 2017). Consider a deployment that keeps weights in roughly 512 KB of SRAM. Even the purpose-built DS-CNN keyword spotter overshoots that budget in FP32, where its weights occupy 800 KB. Quantized to INT8, its weights shrink to 200 KB, leaving space whose sufficiency must be checked against peak activation and runtime-buffer use. A device that reads weights directly from flash has a separate weight-storage budget; its SRAM feasibility still depends on the working set. A stricter smart-doorbell microcontroller with 256 KB SRAM leaves closer to 100 KB for model weights after runtime buffers, audio windows, and feature extraction state, motivating more aggressive INT4 or binary compression.

In FP32, even the compact DS-CNN architecture moves 4\(\times\) more raw weight bytes than in INT8, and the arithmetic path can also cost more on hardware with efficient integer units. For an always-on coin-cell device, that reduction contributes to longer battery life, but sensor, wake-up, feature-extraction, and idle-power costs may dominate. Here, quantization reduces the model’s data-movement term and can improve its compute term \((\Operations / (\PeakRate \cdot \EfficiencyHw))\) when the integer path is supported.

Zhang, Yundong, Naveen Suda, Liangzhen Lai, and Vikas Chandra. 2017. Hello Edge: Keyword Spotting on Microcontrollers.

Together, DLRM and the TinyML lighthouse (10.2) illustrate the two operational extremes of this memory constraint. DLRM uses lower precision to fit embedding tables that can reach terabytes into host memory; TinyML uses lower precision to keep every inference within a tiny energy envelope and a few hundred kilobytes of on-chip SRAM. Across both extremes, reducing numerical precision attacks physical execution costs on two fronts, arithmetic energy and latency in the ALU and byte traffic across the memory bus. Both savings assume that the low-precision values still represent the model faithfully, and producing such values is the job of the quantization methods.

10.3.3 Quantization methods

Casting trained FP32 weights and activations straight to narrow integers without fitting their range clips outlier channels and rounds small values to zero, so practical quantization methods differ in how much calibration or retraining they spend to keep that error small. Post-training quantization, quantization-aware training, and extreme low-bit formats differ chiefly in the training and validation cost they require. Representation choices, such as selecting INT8 versus INT4, mixing bit widths across sensitive layers, or choosing per-tensor versus per-channel ranges, are orthogonal options evaluated within these workflows rather than separate maturity levels. Ordered by the engineering effort each requires, the deployment sequence moves from fast post-training range calibration through quantization-aware retraining to custom low-bit pipelines (figure 18).

Figure 18: Quantization Engineering Workflow: The tiers order deployment paths by engineering and validation effort, not by format or guaranteed accuracy. PTQ serves as the initial candidate because it operates over frozen weights with zero retraining cost; QAT introduces simulated quantization into the training loop when quality recovery demands backpropagation; specialized sub-4-bit and binary formats require custom kernel execution and extensive hardware-specific validation. Representation choices such as INT8 versus INT4, per-channel scaling, and mixed precision apply across these stages rather than defining separate maturity levels.

Post-training quantization is evaluated first, because it changes representations with minimal compute and pipeline overhead. When PTQ satisfies the application’s latency, energy, and quality thresholds, the optimization process stops. When post-training calibration introduces unacceptable accuracy degradation, quantization-aware training lets the weights adapt to discretization noise during backpropagation, and extreme sub-4-bit or ternary representations are reserved for targets that INT8 and INT4 cannot meet and whose hardware has kernels for them.

Post-training quantization

Retraining a large model checkpoint solely to adapt its weights to 8-bit arithmetic can cost hundreds of accelerator hours, and in many deployment pipelines the original training dataset or training cluster is not even available. Post-training quantization (PTQ) avoids that retraining loop altogether by converting weights and activation tensors from floating-point to fixed-point formats directly on a frozen checkpoint (Choukroun et al. 2019). Weight-only quantization requires only a single pass over static parameter tensors, while full integer quantization calibrates activation dynamic ranges using a small, unlabelled sample of representative inputs.

The principal constraint in PTQ is unmodeled discretization noise. Rounding introduces numerical error that cannot be compensated by gradient updates. While redundant architectures absorb 8-bit rounding noise with negligible accuracy loss, sensitive models or lower bit widths (such as INT4) experience degradation unless scaling granularities are refined or quantization-aware training is applied. Production runtimes such as TensorFlow Lite, Open Neural Network Exchange (ONNX) Runtime, and TensorRT provide automated calibration pipelines to profile tensor ranges and apply this conversion.

The core mechanism of PTQ is uniform quantization, which maps floating-point values to discrete integer levels using a consistent scaling factor. Because the interval between each quantized value is constant, uniform quantization simplifies implementation and enables efficient hardware execution. For the symmetric form shown here, \(\QuantizationScale\) is chosen from the maximum absolute value so that the resulting integers stay within the target range. The quantized value \(\QuantizedIntegerCode\) is computed as: \[ \QuantizedIntegerCode = \text{round} \left(\frac{\QuantizerInput}{\QuantizationScale} \right) \] where:

  • \(\QuantizedIntegerCode\) is the quantized integer representation,
  • \(\QuantizerInput\) is the original floating-point value,
  • \(\QuantizationScale\) is a scaling factor that maps the floating-point range to the available integer range.

Uniform quantization from FP32 to INT8 reduces the raw value payload from 32 to 8 bits per weight at the cost of a measurable quantization error, with scale metadata and packing overhead excluded (listing 2). Once a model is quantized, the runtime can use integer arithmetic where supported (Gholami et al. 2022).

Listing 2: Uniform Quantization: Converts FP32 weights to INT8, reducing raw per-weight payload from 32 to 8 bits while measuring quantization error; scale metadata and packing overhead are excluded.
import torch

# Original FP32 weights
weights_fp32 = torch.tensor(
    [0.127, -0.084, 0.392, -0.203], dtype=torch.float32
)
print(f"Original FP32: {weights_fp32}")
print(f"Memory per weight: 32 bits")

# Simple uniform quantization to INT8 (-128 to 127)
# Step 1: Find scale factor
max_val = weights_fp32.abs().max()
scale = max_val / 127  # 127 is max positive INT8 value

# Step 2: Quantize using our formula x_q = round(x/s)
weights_int8 = torch.round(weights_fp32 / scale).to(torch.int8)
print(f"Quantized INT8: {weights_int8}")
print(f"Memory per weight: 8 bits (reduced from 32)")

# Step 3: Dequantize to verify
weights_dequantized = weights_int8.float() * scale
print(f"Dequantized: {weights_dequantized}")
print(
    f"Quantization error: "
    f"{(weights_fp32 - weights_dequantized).abs().mean():.6f}"
)

Rounding to a uniform grid introduces an error with a precise bound. A uniform quantizer maps each value to the nearest of evenly spaced levels separated by a step size \(\QuantizationScale\) (range calibration derives \(\QuantizationScale\) from the tensor’s clipping range in equation 1, later in this section). For any value inside the clipping range, rounding to the nearest level misses by at most half a step, so within-range error is bounded by \([-\QuantizationScale/2, \QuantizationScale/2]\). Aggregated across many tensors, most error concentrates inside that bound, while the tails carry the larger distortion that comes from saturation clipping and from mixing tensors that use different step sizes (figure 19). Many CNNs tolerate INT8 well, whereas large transformers often need outlier-aware or mixed-precision schemes because a few activation channels carry extreme values. Selecting the appropriate numerical precision therefore requires balancing accuracy constraints, hardware support, and efficiency gains.

Figure 19: Illustrative Aggregate Quantization Residuals: Illustrative aggregate residual distribution across heterogeneous scales and clipped values. Within one unclipped uniform quantizer, rounding error is bounded by \([-\QuantizationScale/2, \QuantizationScale/2]\) for step size \(\QuantizationScale\); the displayed tails represent clipping or aggregation across different step sizes.

An alternative, nonuniform quantization, assigns finer-grained precision to numerical ranges that are more densely populated, which can preserve accuracy for models whose weight distributions concentrate around specific values. Nonuniform schemes require more complex calibration and are less common in production, but they can be effective for models particularly sensitive to precision changes. More generally, sensitivity to PTQ varies by architecture, layer, and distribution. When a uniform configuration misses the quality target, the next options include finer granularity, mixed precision, weight-only methods, better calibration, or QAT.

Range calibration

Mapping a tensor onto 8-bit or 4-bit integers with an ill-fitting range either saturates critical values through clipping or squanders available integer levels on sparse outliers. Quantization-range calibration prevents both failures by estimating the real-valued clipping range \([\ClippingRangeLowerBound, \ClippingRangeUpperBound]\) for each tensor (from here on, \(\ClippingRangeLowerBound\) and \(\ClippingRangeUpperBound\) denote its lower and upper bounds). Calibration minimizes representation error over the sampled distribution, although it does not guarantee bounds on out-of-distribution deployment inputs.

Because activation tensors vary with input data, profiling requires running an unlabelled calibration dataset through the forward pass to capture dynamic ranges. In the offline conversion pipeline, the pretrained model and a representative calibration dataset pass through a profiling stage that establishes dynamic ranges, and those ranges parameterize the quantization step that yields the final quantized model (figure 20). Layer by layer, activation observers record value distributions from which the scale and zero-point metadata are computed (algorithm 1). Range calibration in this sense is distinct from the confidence calibration that asks whether a model’s predicted probabilities match its observed accuracy, which returns in section 10.6.

Figure 20: Post-Training Quantization Pipeline: PTQ converts a trained FP32 model directly to INT8 without retraining. Representative calibration data passes through the model to record activation ranges \([\ClippingRangeLowerBound, \ClippingRangeUpperBound]\), computing scale factor \(\QuantizationScale\) and zero-point \(\QuantizationZeroPoint\) parameters to quantize parameters before deployment.

The single calibration pass over \(\CalibrationDataset\) avoids retraining, and FP32-to-INT8 weight quantization cuts raw stored weight values by 4\(\times\) before scale, zero-point, and packing metadata. The price is that the static activation ranges fixed in the loop risk saturation or wasted integer levels when the calibration data misses deployment tails. The quantization step then converts model parameters to the lower-precision format, producing the final quantized model.

Mapping an unnecessarily wide real-valued interval to the 256 discrete bins of an 8-bit integer wastes numerical resolution on empty range, whereas clipping too aggressively truncates signal. Three calibration methods balance this clipping-versus-resolution trade-off: max sets bounds to the absolute extremum (preserving extreme values at the cost of vulnerability to outliers), entropy selects bounds by minimizing the Kullback–Leibler (KL) divergence between original and quantized distributions, and percentile retains a chosen fraction (such as 99.9 percent) and clips the remaining tail. In one ResNet-50 layer, the dense bulk of activations clusters below 1.1, while a sparse outlier tail stretching past 2.0 motivates testing a candidate clipping boundary near 1.1 to allocate more INT8 bins to the bulk (figure 21). Choosing a percentile boundary requires cumulative activation counts; the illustrated boundary is not assigned a percentile rank. Task validation must establish whether clipping that tail preserves important rare cases.

Figure 21: Activation Distribution: ResNet-50 layer activations have a long tail, with outlier values that can lead to inefficient precision use if not handled carefully. Source: (Wu et al. 2020).
Tuning quantization ranges

Once calibration identifies clipping boundaries \([\ClippingRangeLowerBound, \ClippingRangeUpperBound]\), the range must be mapped onto integer endpoints, and two mapping schemes dominate (figure 22). A symmetric mapping uses a zero-centered range with zero-point zero, forcing real zero to integer zero by mapping \([-1, 1]\) directly onto \([-127, 127]\). An asymmetric mapping keeps one scale but a generally nonzero zero-point \(\QuantizationZeroPoint\), which accommodates skewed activation intervals such as \([-0.5, 1.5]\) across \([-128, 127]\).

Figure 22: Calibration Range Selection: Symmetric vs. asymmetric affine quantization mappings. Symmetric quantization (left) forces real zero to map to integer zero, using equal-magnitude negative and positive clipping bounds at the expense of wasted dynamic range for skewed activation distributions; asymmetric quantization (right) uses an explicit zero-point offset \(\QuantizationZeroPoint\) to map non-centered ranges \([\ClippingRangeLowerBound, \ClippingRangeUpperBound]\) efficiently.

Symmetric quantization simplifies integer matrix multiplication kernels because the zero-point is zero (\(\QuantizationZeroPoint= 0\)), eliminating cross-term additions during hardware accumulation. However, for activations following asymmetric distributions (such as post-ReLU feature maps where all values are non-negative), symmetric quantization wastes roughly half of the integer dynamic range on unused negative values. Asymmetric quantization recovers this dynamic range by mapping \([\ClippingRangeLowerBound, \ClippingRangeUpperBound]\) to \([0, 2^\QuantizationBitWidth- 1]\), but requires runtime hardware to compute offset corrections (\(\QuantizationZeroPoint\sum_k \QuantizedWeightEntry\) for output row \(\MatrixRowIndex\)) during multiply-accumulate operations. Either mapping is fully specified by two numbers per range, a scale and a zero-point, and the uniform quantizer introduced for PTQ is the special case whose zero-point is zero.

Napkin Math 10.1: Calculating scale and zero-point
The affine quantization formula: An affine map sends a floating-point range \([\ClippingRangeLowerBound, \ClippingRangeUpperBound]\) that includes zero to an integer range \([0, 2^\QuantizationBitWidth-1]\) (for example, UINT8) via the following construction.

Analysis: Affine quantization establishes a linear mapping \(\QuantizerInput\approx \QuantizationScale(\QuantizedIntegerCode - \QuantizationZeroPoint)\), where \(\QuantizationScale\) is the scale (step size) and \(\QuantizationZeroPoint\) is the zero-point (integer value corresponding to real zero). The mapping involves three computational steps:

  1. Calculate scale \((\QuantizationScale)\): Divide the real range by the integer range using equation 1. \[\QuantizationScale= \frac{\ClippingRangeUpperBound- \ClippingRangeLowerBound}{2^\QuantizationBitWidth- 1} \tag{1}\]

  2. Calculate zero-point \((\QuantizationZeroPoint)\): Shift the range so that real zero maps to an integer using equation 2. \[\QuantizationZeroPoint= \text{round}\left(\frac{-\ClippingRangeLowerBound}{\QuantizationScale}\right) \tag{2}\]

  3. Quantize \((\QuantizerInput\to \QuantizedIntegerCode)\): Divide by the scale, add the zero-point, then round and clamp to the integer range using equation 3. \[\QuantizedIntegerCode = \text{clamp}\left(\text{round}\left(\frac{\QuantizerInput}{\QuantizationScale} + \QuantizationZeroPoint\right), 0, 2^\QuantizationBitWidth- 1\right) \tag{3}\]

Scenario: Consider quantizing a \(2 \times 2\) activation matrix with values ranging from \(\ClippingRangeLowerBound = -1\) to \(\ClippingRangeUpperBound = 3\), and the target precision is UINT8 \((\QuantizationBitWidth=8)\):

\[\mathbf{X} = \begin{pmatrix} -1 & 1 \\ 0 & 3 \end{pmatrix}\]

  • Range: \(\ClippingRangeUpperBound - \ClippingRangeLowerBound = 4\).
  • Steps: \(2^8 - 1\) = 255.
  • Scale: \(\QuantizationScale = \frac{4}{255} \approx 0.0157\).
  • Zero-point: \(\QuantizationZeroPoint = \text{round}(-(\ClippingRangeLowerBound)/\QuantizationScale) = \text{round}\!\left(-(-1)/\frac{4}{255}\right) = \text{round}(63.75) = 64\).

Applying equation 3 element-wise maps each floating-point entry to an integer bin:

\[\mathbf{X}_q = \begin{pmatrix} 0 & 128 \\ 64 & 255 \end{pmatrix}\]

Systems insight: The real value \(0.0\) is represented exactly by the integer 64. This is critical because it ensures that zero-padding (common in CNNs) is represented exactly, preventing “quantization drift” where padding introduces nonzero noise.

Granularity

In convolutional filters or transformer projection matrices, weight magnitudes often vary widely from one channel to the next, so sharing a single scale factor across an entire tensor can collapse small-magnitude channels to zero or clip wider channels. Quantization granularity governs how broadly scale factors and zero-points are shared across a tensor, balancing representation resolution against metadata overhead and kernel complexity: across convolutional channels (filters 1 through \(\LayerOutputWidth\)), a global layerwise threshold spans the widest distribution at the cost of resolution in narrower filters, whereas per-channel clipping boundaries adapt tightly to each filter’s dynamic range at the cost of tracking additional scale vectors during matrix multiplication (figure 23).

Figure 23: Quantization Range Variation: Different convolutional filters can have different weight ranges, motivating per-filter quantization to reduce quantization error. The differing clipping scales illustrate the choice between one layerwise range and separate channelwise ranges. Source: (Gholami et al. 2022).

Quantization granularity trades calibration and metadata overhead against representation error. More local ranges can preserve information when channels differ, but they do not improve accuracy automatically and may lack an efficient kernel path. Each additional scale also has to be stored, loaded, and applied at the granularity supported by the backend. Four levels are common, from one shared layer range to local ranges within a filter (table 9).

Table 9: Quantization Granularity Levels: Granularity trades calibration and metadata overhead against representation error, from a single per-layer range to per-filter sub-ranges.
Level Range sharing Trade-off
Layerwise One range per layer Simple but suboptimal when filter ranges vary widely
Groupwise Filters grouped with shared ranges Used in Q-BERT (Shen et al. 2020) for transformer attention layers
Channelwise One range per filter Common default; balances quantization error against scale metadata and implementation overhead
Sub-channelwise Ranges within each filter More local ranges can reduce quantization error but increase metadata and implementation overhead

Channelwise quantization preserves accuracy over layerwise quantization when channel dynamic ranges differ, at the cost of storing additional scale vectors and executing per-channel rescaling in the kernel pipeline. Beyond scale granularity, execution efficiency depends on the distinction between static weights and dynamic activations, which impose fundamentally different memory and latency constraints on the deployment system.

Weights vs. activations

Executing low-precision inference requires transforming floating-point inputs before kernel execution and requantizing intermediate accumulator outputs. During integer matrix multiplication, multiplying two 8-bit integers produces a 16-bit product. Summing these products across an inner dimension of length \(\GemmInnerDimension\) causes bit-growth that quickly overflows 8-bit registers; hardware therefore accumulates into 32-bit integer registers (INT32). Before feeding the result into subsequent layers, requantization rescales the 32-bit accumulated sum by the layer’s effective scale factor (\(\RequantizationScale= \frac{\WeightQuantizationScale \cdot \InputQuantizationScale}{\OutputQuantizationScale}\)) and clamps the values back into the 8-bit integer range. The full pipeline therefore has four stages (figure 24): quantizers convert floating-point activations and weights into INT8 operands, an integer core executes the matrix multiplication, a 32-bit accumulator holds the sum, and a requantization stage returns the result to INT8 before the nonlinear activation.

↪ How a single Tensor Core matrix instruction takes low-precision input tiles into higher-precision accumulator registers is developed in Tensor Cores.

Figure 24: Quantized Matrix Multiplication Pipeline: Floating-point weights and activation inputs are quantized to INT8 (violet), fed into integer SIMD/Tensor Core matrix multiplication (blue), accumulated in 32-bit registers (red), and requantized back to INT8 (green) before non-linear activation. From the HarvardX TinyML course.

Activation quantization maps layer outputs to a lower-precision representation during inference. It reduces intermediate payloads and can reduce arithmetic cost on hardware with an efficient integer path, but it also introduces error between layers. For example, a CNN may convert FP32 feature maps to INT8 before later convolutions. The benefit is greatest when consecutive operators remain on the integer path; isolated quantized operators may pay conversion cost without reducing enough work. Whether activation quantization improves latency therefore depends on supported kernels, scale handling, tensor lifetimes, and any quantize or dequantize boundaries that remain in the exported graph.

Static vs. dynamic quantization

The clipping range also depends on when activation ranges are computed, which divides activation quantization into two primary execution models: static quantization and dynamic quantization. In static quantization, the clipping range is precalculated during offline calibration and remains fixed during inference. This approach introduces zero runtime range-estimation overhead, because inputs are scaled by fixed factors and directly fed to integer execution units. However, static ranges risk saturation or underflow whenever production inputs deviate from the calibration distribution (Jacob et al. 2018; Yao et al. 2021).

Yao, Zhewei, Amir Gholami, Sheng Shen, Kurt Keutzer, and Michael W. Mahoney. 2021. “HAWQ-V3: Dyadic Neural Network Quantization.” Proceedings of the 38th International Conference on Machine Learning (ICML), 11875–86.

Dynamic quantization instead calculates scaling factors and zero-points dynamically from runtime activation tensors. Adapting the clipping window to each input reduces mismatch with a fixed calibration range. Outliers can still consume resolution, and a policy that clips tails can still saturate values. The trade-off is runtime memory and latency overhead, because the hardware must perform reduction passes over intermediate activation tensors to extract minimum and maximum values before integer arithmetic can begin. On memory-bandwidth-bound operators, this reduction pass can erode the execution advantage of lower precision.

Checkpoint 10.2: Calibration and range choices

Quantization succeeds only when the range policy matches deployment data and runtime constraints.

Range design

PTQ in practice

Post-training quantization balances deployment turnaround against accuracy control. PTQ requires no gradient backpropagation or retraining. Whether offline calibration is sufficient depends on the architecture, calibration data distribution, numerical quantizer design, and target hardware constraints.

The primary limitation is that PTQ freezes model parameters, preventing compensation for accuracy loss. When a quantized model falls below the production threshold, mitigations include recalibrating, refining scale granularity, adopting mixed precision, or escalating to quantization-aware training. QAT integrates precision constraints directly into the training graph using a straight-through estimator (STE) (section 10.3.3.2.1) to pass gradients through nondifferentiable rounding operators. This enables weights to adapt to low-bit representations during retraining, recovering accuracy at the cost of additional training compute (\(\TrainingCompute\)) and hyperparameter tuning.

Quantization-aware training

When post-training quantization drops a sensitive model or a 4-bit target below its accuracy floor because frozen weights cannot adjust to coarse rounding steps, only gradient updates can recover the lost quality. Quantization-aware training incorporates numerical rounding noise directly into the optimization graph, retraining or fine-tuning a quantized checkpoint on the training dataset so its parameters adapt to low-precision discretization error (figure 25).

Figure 25: Quantization-Aware Training Pipeline: QAT inserts fake-quantization nodes into the forward graph to simulate low-precision clipping and rounding errors during training. Backpropagation updates floating-point master weights using straight-through estimators (STE), allowing network parameters to adapt to numerical noise before exporting fixed integer scales for inference.

Rather than training from scratch or cold-starting scale parameters, production workflows frequently initialize QAT using scale factors derived during an initial PTQ calibration pass. In this two-phase pipeline, a PTQ phase feeds calibration data into the pretrained model to establish initial scale metadata, and the resulting PTQ checkpoint enters a QAT phase in which the full training data drives fine-tuning (figure 26).

Figure 26: PTQ-to-QAT Pipeline: PTQ calibration can initialize ranges and scales before QAT fine-tunes the pretrained weights with simulated quantization. Calibration data feeds the PTQ stage, and training data feeds QAT.
Training mathematics

During forward propagation, weights and activations are quantized and dequantized to mimic reduced precision. Let \(\QuantizerInput\) be a full-precision value, \(\QuantizationScale\) the scaling factor that maps floating-point values into a lower-precision range, and \(\FakeQuantizedOutput\) the simulated (quantized, then dequantized) value. Ignoring clipping and the zero-point for this simplified expression, the process is represented as: \[ \FakeQuantizedOutput= \text{round} \left(\frac{\QuantizerInput}{\QuantizationScale} \right) \times \QuantizationScale\]

Although the forward pass executes with simulated quantization, computing gradients requires backpropagating through the rounding operator \(\text{round}(\cdot)\). Because rounding is a piecewise-constant step function, its mathematical derivative is zero almost everywhere and undefined at step transitions, which would zero out gradients and halt gradient descent. The Straight-Through Estimator (STE) resolves this bottleneck by substituting the identity function for the rounding operator during backpropagation (Bengio et al. 2013).16

16 Straight-through estimator (STE): Proposed by Bengio et al. (2013), the common identity STE copies the upstream gradient through the quantizer unchanged. Because that identity is not the derivative of rounding, the estimate is biased, so QAT descends an approximation of the quantized model’s loss surface rather than the surface itself.

Bengio, Yoshua, Nicholas Léonard, and Aaron Courville. 2013. “Estimating or Propagating Gradients Through Stochastic Neurons for Conditional Computation.” arXiv Preprint arXiv:1308.3432.
Krishnamoorthi, Raghuraman. 2018. “Quantizing Deep Convolutional Networks for Efficient Inference: A Whitepaper.” arXiv Preprint arXiv:1806.08342 abs/1806.08342.

Integrating quantization effects during training lets the model adapt its weights and activation ranges to simulated low-precision error. QAT can recover quality that a post-training route loses, particularly at aggressive bit widths, but the advantage depends on the model, quantizer, calibration, and training procedure (Krishnamoorthi 2018).

Fake quantization nodes and implementation

QAT implementation relies on fake quantization operations that simulate quantization during forward propagation while maintaining full precision for gradient computation. These operations insert quantize-dequantize pairs into the computational graph, creating a training-time simulation of inference-time behavior.

A fake quantization node must preserve the same errors the inference runtime will see, so its three operations model the deployment path during training:

  1. Quantization: Map floating-point value to discrete quantization level
  2. Clipping: Enforce range constraints based on bit width
  3. Dequantization: Convert back to floating-point for subsequent operations

Mathematically, for symmetric quantization with bit width \(\QuantizationBitWidth\), given a floating-point input value \(\QuantizerInput\): \[ \begin{aligned} \QuantizedIntegerCode &= \text{clip}\left(\text{round}\left(\frac{\QuantizerInput}{\QuantizationScale}\right), -2^{\QuantizationBitWidth-1}, 2^{\QuantizationBitWidth-1} - 1\right) \\ \FakeQuantizedOutput&= \QuantizedIntegerCode \times \QuantizationScale\end{aligned} \] where \(\QuantizedIntegerCode\) is the quantized integer level, \(\QuantizationScale= \frac{\max(|\QuantizerInput|)}{2^{\QuantizationBitWidth-1} - 1}\) is the scale factor computed from the input distribution, and \(\FakeQuantizedOutput\) represents the fake-quantized output that mimics INT8 values but remains in floating-point format.

For asymmetric quantization supporting unsigned integers, the node applies the scale, zero-point, and quantize steps of equation 1, equation 2, and equation 3 to the observed range (extended to include zero) and then dequantizes: \[ \begin{aligned} \QuantizationScale&= \frac{\max(\QuantizerInput) - \min(\QuantizerInput)}{2^\QuantizationBitWidth- 1} \\ \QuantizationZeroPoint&= \text{round}\left(-\frac{\min(\QuantizerInput)}{\QuantizationScale}\right) \\ \QuantizedIntegerCode &= \text{clip}\left(\text{round}\left(\frac{\QuantizerInput}{\QuantizationScale} + \QuantizationZeroPoint\right), 0, 2^\QuantizationBitWidth- 1\right) \\ \FakeQuantizedOutput&= (\QuantizedIntegerCode - \QuantizationZeroPoint) \times \QuantizationScale\end{aligned} \] where \(\QuantizationZeroPoint\) is the zero-point offset enabling asymmetric range representation and the observed range \([\min(\QuantizerInput), \max(\QuantizerInput)]\) serves as the clipping range \([\ClippingRangeLowerBound, \ClippingRangeUpperBound]\).

In the QAT forward path, fake quantization is applied to inputs and weights before convolution, simulating INT8 numerics while retaining floating-point tensors for training (listing 3).

Listing 3: QAT Convolution Forward Pass: Fake-quantizes activations and weights before convolution to simulate deployment numerics during training.
# Forward pass with fake quantization
def qat_conv_forward(x, weight):
    # Fake quantize input activations
    x_scale = compute_scale(x, bits=8, symmetric=False)
    x_zero = compute_zero_point(x, x_scale, bits=8)
    x_quant = fake_quantize(x, x_scale, x_zero, bits=8)

    # Fake quantize weights (typically symmetric)
    w_scale = compute_scale(weight, bits=8, symmetric=True)
    w_quant = fake_quantize(weight, w_scale, zero=0, bits=8)

    # Convolution with fake-quantized values
    output = conv2d(x_quant, w_quant)
    return output

During backpropagation, fake quantization nodes approximate gradients through a clipping-aware straight-through estimator: \[ \frac{\partial \FakeQuantizedOutput}{\partial \QuantizerInput} = \begin{cases} 1 & \text{if } \QuantizerInput\in [\ClippingRangeLowerBound, \ClippingRangeUpperBound] \\ 0 & \text{otherwise} \end{cases} \] Within the clipping range \([\ClippingRangeLowerBound, \ClippingRangeUpperBound]\), the estimator treats quantization as an identity mapping, passing the upstream gradient \(\frac{\partial \LossFunction}{\partial \FakeQuantizedOutput}\) unchanged to master weight \(\QuantizerInput\). Beyond clipping boundaries, the derivative evaluates to zero, blocking gradients from saturated outliers that would otherwise destabilize optimizer updates.

In practice, frameworks like PyTorch and TensorFlow implement fake quantization as custom autograd operators whose forward pass performs the quantize-dequantize round trip while the backward pass applies an STE. Scale handling depends on the method, since observers may track distributions and later freeze, or scales may be learned. Batch normalization also requires deployment-consistent handling. Workflows freeze batch-normalization statistics and fold them into the preceding convolution before export (section 10.4.1). Freezing running statistics before export allows fake-quantization scales to match the static fused parameters executed during inference.

QAT trade-offs

QAT’s17 primary advantage is additional control over quality at low precision. By incorporating simulated quantization noise during training or fine-tuning, the model can adapt to the deployed numerical path. Processors with dedicated integer units can then exploit INT8 arithmetic for faster or lower-energy inference when the exported operators are supported (Wu et al. 2020; Gholami et al. 2022). The benefit must be measured against PTQ for the same model and target, including the extra training cost and any difference in calibration, graph coverage, or kernel selection.

17 Quantization-aware training (QAT): QAT simulates low-precision behavior during training or fine-tuning so weight updates can adapt to clipping and rounding error. BERT studies report that training-aware or Hessian-aware methods can remain closer to full-precision General Language Understanding Evaluation (GLUE) baselines than simpler post-training routes in their evaluated settings (Zafrir et al. 2019; Shen et al. 2020). The exact gap depends on model, task, quantizer, bit width, training budget, and evaluation distribution; a closer benchmark result is evidence for trying QAT, not a guarantee that its added training cost or exported runtime will meet a production target.

Zafrir, Ofir, Guy Boudoukh, Peter Izsak, and Moshe Wasserblat. 2019. “Q8BERT: Quantized 8Bit BERT.” 2019 Fifth Workshop on Energy Efficient Machine Learning and Cognitive Computing - NeurIPS Edition (EMC2-NIPS), 36–39. https://doi.org/10.1109/emc2-nips53020.2019.00016.
Shen, Sheng, Zhen Dong, Jiayu Ye, Linjian Ma, Zhewei Yao, Amir Gholami, Michael W. Mahoney, and Kurt Keutzer. 2020. “Q-BERT: Hessian Based Ultra Low Precision Quantization of BERT.” Proceedings of the AAAI Conference on Artificial Intelligence 34 (05): 8815–21. https://doi.org/10.1609/aaai.v34i05.6409.
Wu, Hao, Patrick Judd, Xiaojie Zhang, Mikhail Isaev, and Paulius Micikevicius. 2020. “Integer Quantization for Deep Learning Inference: Principles and Empirical Evaluation.” arXiv Preprint arXiv:2004.09602 abs/2004.09602.
Choukroun, Yoni, Eli Kravchik, Fan Yang, and Pavel Kisilev. 2019. “Low-Bit Quantization of Neural Networks for Efficient Inference.” 2019 IEEE/CVF International Conference on Computer Vision Workshop (ICCVW), 3009–18. https://doi.org/10.1109/iccvw.2019.00363.

The cost is additional engineering complexity. QAT inserts simulated quantization into training, so teams must validate quantization schemes, scale behavior, and accuracy recovery on the target model. For very large models whose training budgets are already constrained, that overhead can make QAT impractical, and post-training routes avoid retraining altogether (Choukroun et al. 2019). QAT is therefore warranted only when the exported PTQ model misses its quality or deployment targets and training resources permit. A hybrid approach, starting with PTQ calibration and applying QAT fine-tuning only to accuracy-critical layers, often provides a useful balance.

The choice among PTQ, QAT, and dynamic quantization comes down to engineering budget, accuracy threshold, and input variability (table 10). Dynamic range computation is a timing choice orthogonal to PTQ versus QAT (dynamic PTQ is common), but it belongs in the comparison because it answers the third of those questions.

Table 10: Quantization Method Comparison: The choice turns on three binding questions, namely engineering budget, accuracy threshold, and input variability, rather than on a feature checklist.
Method Engineering effort Accuracy preservation Input adaptability Reach for it when
Static PTQ Low: no retraining Model-dependent; parameters do not adapt Fixed calibration range a calibrated model meets the measured accuracy and performance targets
Static QAT High: additional training with quantization simulation Often stronger when PTQ falls short Fixed calibration range PTQ misses the accuracy target and the training budget allows
Dynamic quantization Moderate: ranges recomputed at runtime Model-dependent; range fits each input Per-input range activation ranges vary widely across inputs and runtime overhead is acceptable

PTQ serves as the low-effort baseline; QAT spends training cycles when PTQ degrades task accuracy, while dynamic quantization expends runtime memory traffic and compute to track input-dependent dynamic ranges. In practice, PTQ and QAT commonly target 8-bit or 4-bit precision, where retained accuracy depends on the model, task, and quantizer. Some deployment scenarios, however, demand even more aggressive compression, pushing precision to the absolute limits of what neural networks can tolerate.

10.3.4 Extreme quantization

On a microcontroller whose runtime buffers and audio feature extraction leave barely 100 KB of SRAM for weights, or on an energy-harvesting sensor whose power envelope cannot afford hardware multipliers, even 8-bit and 4-bit integers exceed the deployment budget. Extreme quantization pushes numerical precision down to 1 or 2 bits per value for those targets (Courbariaux et al. 2015; Zhu et al. 2017). Binarization constrains weights and activations to two values, typically encoded as \(\{-1, +1\}\). In digital logic, mapping \(-1\) to binary \(0\) and \(+1\) to binary \(1\) renders scalar multiplication isomorphic to the bitwise XNOR operation, replacing floating-point or integer MAC units with bitwise logic and population count (popcount) instructions (Rastegari et al. 2016). Because a 64-bit register packs 64 binary values, a single 64-bit XNOR instruction computes 64 binary products in parallel and a hardware popcount instruction counts the matching bits to accumulate the dot product (\(2 \times \text{popcount}(\BinaryWeightVector\text{ XNOR } \BinaryActivationVector) - 64\)), eliminating hardware multipliers altogether. That efficiency comes at a steep cost in expressiveness, since 1-bit representations degrade accuracy sharply on complex perceptual and language tasks (Hubara et al. 2018).

Courbariaux, Matthieu, Yoshua Bengio, and Jean-Pierre David. 2015. “BinaryConnect: Training Deep Neural Networks with Binary Weights During Propagations.” Advances in Neural Information Processing Systems (NeurIPS) 28: 3123–31.

Ternarization mitigates this capacity loss by allowing three values: \(\{-1, 0, +1\}\) (Zhu et al. 2017). The zero state introduces sparsity and simplifies arithmetic. Multiplying an activation by \(+1\) requires an addition, multiplying by \(-1\) requires a subtraction, and multiplying by \(0\) is skipped entirely. This eliminates general-purpose multipliers, reducing the arithmetic unit to a conditional adder-subtractor accumulator. However, ternary values cannot be packed at one bit per value. They require at least two bits per weight in standard byte-aligned memory (wasting one of four possible 2-bit states) or multi-trit encoding (such as packing five trits into a single byte, since \(3^5 = 243 < 256\)) that introduces runtime decoding overhead. The arithmetic gains of multiplier-free execution must outweigh the instruction overhead required to decode and unpack the weights on the target architecture.

Both binary and ternary quantization introduce step functions whose derivative is zero almost everywhere (\(\frac{\DerivativeOperator}{d\QuantizerInput}\text{sign}(\QuantizerInput) = 0\) for \(\QuantizerInput\neq 0\)), causing backpropagation gradients to vanish. To train these representations, quantization-aware training again relies on the straight-through estimator (Bengio et al. 2013; Choi et al. 2018) of section 10.3.3.2.1, whose gradients reach full-precision latent weights that accumulate small optimizer steps until they cross the quantization thresholds.

Choi, Jungwook, Zhuo Wang, Swagath Venkataramani, Pierce I-Jen Chuang, Vijayalakshmi Srinivasan, and Kailash Gopalakrishnan. 2018. “PACT: Parameterized Clipping Activation for Quantized Neural Networks.” arXiv Preprint.

Challenges and limitations

Translating sub-byte precision into actual wall-clock speedups is constrained by standard processor architectures. Native support for binary or two-bit matrix operations varies across processors and kernel libraries. On a target without a matching sub-byte path, executing these representations requires bit-shifting, masking, or unpacking routines. The instruction overhead of this bit manipulation frequently offsets memory-bandwidth savings unless workloads run on custom bit-serial accelerators, field-programmable gate arrays (FPGAs), or specialized hardware with native bitwise execution units (Umuroglu et al. 2017).

Umuroglu, Yaman, Nicholas J. Fraser, Giulio Gambardella, Michaela Blott, Philip Leong, Magnus Jahre, and Kees Vissers. 2017. “Finn: A Framework for Fast, Scalable Binarized Neural Network Inference.” Proceedings of the 2017 ACM/SIGDA International Symposium on Field-Programmable Gate Arrays, 65–74. https://doi.org/10.1145/3020078.3021744.
Rastegari, Mohammad, Vicente Ordonez, Joseph Redmon, and Ali Farhadi. 2016. “XNOR-Net: ImageNet Classification Using Binary Convolutional Neural Networks.” In European Conference on Computer Vision (ECCV). Springer. https://doi.org/10.1007/978-3-319-46493-0_32.
Hubara, Itay, Matthieu Courbariaux, Daniel Soudry, Ran El-Yaniv, and Yoshua Bengio. 2018. “Quantized Neural Networks: Training Neural Networks with Low Precision Weights and Activations.” Journal of Machine Learning Research 18 (187): 1–30.
Zhu, Chenzhuo, Song Han, Huizi Mao, and William J. Dally. 2017. “Trained Ternary Quantization.” International Conference on Learning Representations (ICLR) 4 (4): 1–16.

Model quality is the second barrier. Extreme quantization sharply reduces the representational capacity of a network. While low-entropy workloads such as KWS on a microcontroller SRAM budget may tolerate binary or ternary weights, complex perceptual and generative models suffer steep accuracy degradation. Binary and ternary quantization become viable candidates only when higher-precision alternatives such as INT8 or INT4 fail to satisfy physical memory or energy budgets, and when the deployment hardware can execute bit-packed operations natively (Rastegari et al. 2016; Hubara et al. 2018; Zhu et al. 2017; Umuroglu et al. 2017). Production deployment requires evaluating binary and ternary baselines against INT8, INT4, structured pruning, and compact architectural redesigns on the identical workload, measuring total binary artifact size, end-to-end latency, energy per inference, and task accuracy on target hardware. Whether a narrower format actually runs faster is the last question the precision tier must answer.

10.3.5 When fewer bits run faster

Shrinking weights from 16 bits to 8 bits fails to speed up a compute-bound matrix multiplication if the processor lacks a faster 8-bit datapath, just as faster integer ALUs fail to speed up autoregressive decoding when latency is stalled on memory-bus transfers. Every byte that quantization removes is a byte the memory system no longer moves, so whether a quantized model runs faster depends on which hardware resource binds: a compute-bound matrix multiplication speeds up only when the hardware provides a higher-throughput datapath for the narrower format, whereas a bandwidth-bound decode speeds up in proportion to the bytes removed from each token’s traffic. The worked examples below bracket the payoff, first on the reference H100 for a compute-bound layer and then on the running case’s phone for GPT-2 XL decoding.

Napkin Math 10.2: The quantization speedup (compute bound)
Problem: A compute-bound matrix multiplication (for example, in a transformer multilayer perceptron block at a large batch) switches from FP16 to INT8 on the reference H100. What throughput speedup can the integer matrix units deliver?

Math: On hardware with dedicated INT8 units:

  1. Integer throughput path: The H100 rates its INT8 matrix path at 1979 TOPS against 989 TFLOP/s on the dense FP16 path (NVIDIA Corporation 2022; Choquette 2023). The peak throughput increase is that spec ratio, about 2×.
  2. Memory bandwidth: Packed INT8 weights carry half the raw weight bytes of FP16. Their streaming time can approach half at the same achieved bandwidth, before metadata and conversion costs.
  3. Combined effect: For compute-bound operations, the ideal throughput factor is about 2× at comparable utilization of the two arithmetic paths.

Systems insight: The speedup from quantization depends on the bottleneck. Compute-bound operations (large batch sizes, high arithmetic intensity \(\ArithmeticIntensity\)) can approach about 2× at comparable utilization of supported INT8 units, where the gain comes from the integer matrix path rather than reduced memory traffic. The bandwidth-bound case inverts this. Halving the bytes moved (FP16 to INT8) yields up to 2×, and larger bit-width reductions scale the gain further, as the decode example below traces.

Choquette, Jack. 2023. “NVIDIA Hopper H100 GPU: Scaling Performance.” IEEE Micro 43 (3): 9–17. https://doi.org/10.1109/mm.2023.3256796.
NVIDIA Corporation. 2022. NVIDIA H100 Tensor Core GPU Architecture. NVIDIA Corporation.

Processors without dedicated matrix units see the same compute-bound effect through data-level parallelism in their registers, the path a phone’s CPU takes before a model moves to its integer accelerator. Fixed-width vector execution units (SIMD) and systolic arrays process more operands per cycle when each operand occupies fewer bits.

Napkin Math 10.3: The SIMD multiplier
Problem: A compute-bound layer executes using INT8 rather than FP32 on the same processor. Determine the architectural source of arithmetic speedup under fixed register width.

Mechanism: SIMD execution. A CPU or GPU core processes data in fixed-width vector registers (for example, AVX-512 is 512 bits wide).

Math:

  1. Register width: 512 bits.
  2. FP32 capacity: 512/32 = 16 elements per vector instruction.
  3. INT8 capacity: 512/8 = 64 elements per vector instruction.

Result: Switching to INT8 packs 4× more elements into the same register. \(\text{Throughput Gain} = \text{INT8 elements/inst} / \text{FP32 elements/inst}\) = 64/16 = 4×

Systems insight: The packing ratio gives an ideal 4× throughput factor, assuming comparable vector-instruction throughput, occupied lanes, and supported operators. It is a candidate bound for compute-bound layers, not a measured layer speedup; memory traffic and conversion overhead still affect execution.

When an operation is bandwidth bound, speedup tracks the reduction in bytes transferred per token rather than peak arithmetic throughput. In autoregressive token generation with small batch sizes, memory bus traffic dominates latency.

Napkin Math 10.4: The quantization speedup (bandwidth bound)
Problem: The running case’s phone decodes GPT-2 XL (1.5B parameters) at batch size one with a full 1,024-token context. Its memory bus delivers 51.2 GB/s, and each token must read every weight and the whole KV cache. How much faster does decoding run with INT4 weights than with FP16 weights?

Math (FP16 weights):

  1. Weights: 3 GB at two bytes per parameter.
  2. KV cache: Keys and values across 48 layers, 25 heads, and 64 dimensions per head, stored in FP16 for 1,024 tokens, occupy 0.31 GB.
  3. Total per token: 3.3 GB, which fits the phone’s 8 GB but takes 65 ms to stream, or about 15 tokens/s.

Fix (INT4 weights):

  1. Weights: 0.75 GB at half a byte per parameter, for 1.06 GB per token with the unchanged FP16 KV cache.
  2. Speed: Streaming that total takes 21 ms, or about 48 tokens/s.

Systems insight: INT4 weights yield a 3.1× speedup in this traffic model, below the 4\(\times\) weight reduction because the FP16 KV-cache traffic is unchanged. The model already fit in memory at FP16; quantization bought speed, not feasibility. The realized speedup still depends on a kernel that unpacks INT4 weights inside the matrix multiplication rather than in a separate pass.

Across three vision networks (Inception v3, MobileNet v1, and ResNet v2), INT8 conversion contracts weight storage by exactly \(4\times\) (135 MB to 33.75 MB for the illustrative Inception bar), while the latency change varies with the architecture and its kernels (figure 27).

Figure 27: Illustrative Quantization Scenario: Paired bars separate FP32 and INT8 alternatives. The right panel shows illustrative weight storage, where reducing each weight from 32 to 8 bits produces an exact fourfold decrease; the left panel shows illustrative, architecture-dependent latency changes.

Mini roofline with one workload dot on the memory-bound slope labeled Memory 3.1× and one workload dot on the compute-bound ceiling labeled Compute 2×.

Quantization speedup depends on whether memory bandwidth or compute throughput is binding.

18 Activation-aware weight quantization (AWQ): Salience is determined by activation magnitude, not weight magnitude, a distinction that matters because a small weight multiplied by a large activation produces a large output contribution. AWQ protects about 1 percent of salient weight channels through activation-aware scaling while quantizing most weights to low-bit formats, so GPT-2 XL’s 3 GB of FP16 weights can move toward an INT4-class footprint of about 0.75 GB before metadata, scales, and kernel-specific packing overheads (Lin et al. 2024).

Lin, Ji, Jiaming Tang, Haotian Tang, Shang Yang, Wei-Ming Chen, Wei-Chen Wang, Guangxuan Xiao, Xingyu Dang, Chuang Gan, and Song Han. 2024. “AWQ: Activation-Aware Weight Quantization for on-Device LLM Compression and Acceleration.” Proceedings of Machine Learning and Systems 6: 87–100.

Activation-aware methods such as activation-aware weight quantization (AWQ)18 target weight traffic in large language model (LLM) inference. This approach serves exactly the regime of GPT-2 XL decoding on the phone, where loading model weights limits the token rate. By protecting a small fraction of salient weight channels based on activation magnitude, AWQ supports INT4-class weight quantization while controlling task degradation. Packed low-bit weights can reduce the memory traffic required during token generation when the runtime provides a matching kernel (Lin et al. 2024).

Checkpoint 10.3: Quantization and precision checkpoint

Quantization design review criteria:

These speedups are bounds computed from bytes and peak rates. Whether a deployed model reaches them depends on how its compressed operations are lowered onto kernels, which is the third tier of the stack.

Self-Check: Question
  1. According to the chapter’s Horowitz energy constants, an INT8 integer addition consumes roughly \(0.03\text{ pJ}\) compared to \(0.90\text{ pJ}\) for an FP32 addition—a \(30\times\) energy reduction despite only a \(4\times\) reduction in bit-width. What explains this operation-level energy dividend?

    1. INT8 arithmetic eliminates the need for registers and ALU logic on the silicon die
    2. INT8 quantization automatically prunes zero-valued parameters before they reach the execution units
    3. The 8-bit integer adder circuit requires significantly fewer logic gates, capacitance, and switching energy per operation than a 32-bit floating-point adder with exponent alignment and normalization logic
    4. Floating-point operations require continuous synchronization with host CPU DRAM on every instruction
  2. In affine (asymmetric) quantization, the integer parameter ____ shifts the quantized grid so that real-valued zero maps exactly to an integer representation, ensuring that zero-padded tensor regions introduce no numerical bias.

  3. Order the stages of a standard post-training quantization workflow with static activation calibration: (1) quantize the finalized weights and export the deployment artifact, (2) run representative floating-point calibration inputs through the model and collect activation statistics, (3) choose activation clipping bounds from the collected statistics, (4) derive activation scales and zero-points from those chosen bounds.

  4. Compare two validation settings for low-bit quantization: (1) candidate INT4 weight-only quantization for autoregressive decoding when profiling shows weight traffic dominates, and (2) candidate low-bit quantization for large-batch training of the same model. Explain why these two settings require different validation conditions before concluding the quantization is worthwhile.

  5. During post-training quantization of a convolutional network, activation profiling reveals that values are heavily concentrated near zero with a small set of extreme positive outliers. Which calibration strategy best preserves numerical resolution for the bulk of typical activations?

    1. Max-absolute-value calibration, because extending the quantization grid to include extreme outliers guarantees zero clipping error across all layers
    2. Uncalibrated uniform quantization, because activation distributions in neural networks always follow a perfectly uniform probability density
    3. Static symmetric quantization with range [-128, +127] mapped unconditionally to [-1.0, +1.0] across every layer
    4. Percentile or KL-divergence (entropy) calibration, which can clip extreme tails so more integer levels represent the dense bulk of activations
  6. A team quantizing a deep convolutional network finds that per-channel (filter-wise) quantization achieves significantly higher accuracy than per-tensor (layer-wise) quantization at the same INT8 bit-width. Which mechanism explains this accuracy advantage?

    1. Per-channel quantization eliminates the need to compute or store scale factors and zero-points
    2. Individual convolutional filters within a layer often exhibit drastically different weight magnitude ranges; per-channel quantization assigns an independent scale factor to each filter, preventing wide-range filters from degrading the precision of narrow-range filters
    3. Per-tensor quantization can only be executed on CPUs, whereas per-channel quantization is restricted to edge microcontrollers
    4. Per-channel quantization automatically converts float operations into sparse matrix multiplications

See Answers →

10.4 Hardware Implementation: Changing How the Model Executes

Pruning a model structurally to half its weights and quantizing the survivors from FP32 to INT8 cuts stored weight bytes by 2× and 4×, or 8× in all, yet in production such a model can easily run only 1.5× faster—roughly 18.8 percent of the paper projection. Profiling reveals where the missing speedup vanishes: sparse tensors continue to stream through dense kernels that cannot skip unindexed zeros, reduced-precision operators trigger unfused type conversions that flood the memory bus, and small layers spend more time launching kernels and moving intermediates than doing arithmetic. Paper metrics—parameter counts, theoretical FLOPs, and nominal bit depths—establish upper bounds that hold only when a workload is limited purely by weight traffic and every kernel exploits the new representation. Bridging the divide between paper reduction and measured hardware speedup is the job of the third tier of the stack, efficient hardware implementation.

The measured bottleneck selects the implementation technique. Kernel fusion consolidates memory-bound operator chains, custom dequantization loops keep packed low-precision weights inside cache, and hardware sparsity engines align with tensor layouts to bypass zeroed arithmetic.

10.4.1 Compression-specific fusion

In the camera pipeline’s MobileNetV2, every inverted residual block chains a convolution, a batch normalization, and a rectified linear unit (ReLU); executed as separate kernels, each operator writes its output to accelerator global memory and the next reads that output back, paying three memory round-trips for work that could stay in on-chip registers. Kernel fusion (or operator fusion) eliminates those redundant memory transactions by combining adjacent operators into a single kernel (Chen et al. 2018; NVIDIA 2024), and model compression introduces fusion requirements of its own. Folding batch normalization into a pruned convolution, keeping a dequantize step inside the matrix-multiplication kernel that consumes it, and choosing which adjacent operators of a rewritten graph can share one kernel are all fusion decisions that arise once the graph has been compressed.

Chen, Tianqi, Thierry Moreau, Ziheng Jiang, Lianmin Zheng, Eddie Q. Yan, Haichen Shen, Meghan Cowan, et al. 2018. “TVM: An Automated End-to-End Optimizing Compiler for Deep Learning.” Proceedings of the 13th USENIX Symposium on Operating Systems Design and Implementation (OSDI ’18), 578–94.

That read-compute-write cycle creates memory bandwidth bottlenecks for operations with low arithmetic intensity (FLOP/byte). The traffic rule for a fused chain, established in The memory wall and kernel fusion, bounds what fusion can recover. Fusing a chain of \(\ChainedOperationCount\) operations over an intermediate tensor of \(\IntermediateTensorSize\) bytes cuts idealized read-and-write traffic from \(2\,\ChainedOperationCount \IntermediateTensorSize\) to \(2\IntermediateTensorSize\) bytes, because the fused kernel reads its input once and writes its final output once. Weights, auxiliary inputs, cache effects, and register spills are outside this simple bound, and data dependencies, tensor shapes, and register pressure limit how much can legally be fused. Several inference patterns nevertheless approximate the bound closely enough for fusion to matter.

Convolution-BatchNorm-ReLU fusion

The common Conv-BN-ReLU pattern can replace three launches and intermediate round-trips with one fused path when the compiler can legally fold batch normalization and combine the activation (listing 4). Folding is compression-specific because it must happen after the convolution’s channels and scales are final. Workflows fold batch normalization into preceding convolution weights (\(\FusedConvolutionWeight= \frac{\NormalizationScaleVector}{\BatchNormRunningStandardDeviation} \WeightMatrix\)) where \(\BatchNormRunningStandardDeviation\) is the square root of the sum of running variance and the numerical stabilizer. Folding also adjusts the convolution bias, \(\FusedConvolutionBias = \frac{\NormalizationScaleVector}{\BatchNormRunningStandardDeviation}(\BiasVector- \BatchNormRunningMean) + \NormalizationShiftVector\), where \(\BatchNormRunningMean\) is the per-channel running mean and \(\NormalizationScaleVector\) and \(\NormalizationShiftVector\) are the learned batch-normalization scale and shift. Batch normalization’s per-channel scale thus multiplies into the surviving filters, and its shift becomes the convolution’s bias, so a pruned or quantized network is folded once its structure stops changing.

Listing 4: Conv-BN-ReLU Fusion: Combining three operations into a single kernel reduces the idealized intermediate-tensor stream from 6 transfers to 2; weights, auxiliary inputs, and spills are outside this count.
# Pseudocode: runtime APIs and fusion legality are
# implementation-dependent.
# === UNFUSED: 3 kernel launches, 6 memory transfers ===
conv_out = conv2d(input, weight)
bn_out = batch_norm(conv_out, ...)
relu_out = relu(bn_out)


# === FUSED: 1 kernel launch, 2 memory transfers ===
def conv_bn_relu_fused(input, weight, gamma, beta, mean, var):
    # Read input and weight once
    conv = conv2d(input, weight)

    # Apply batch norm in registers (no memory write)
    bn = gamma * (conv - mean) / sqrt(var + eps) + beta

    # Apply ReLU in registers (no memory write)
    output = relu(bn)

    # Write final result once
    return output

A blue bar labeled HBM sits between two rows of orange kernel boxes. Above it, three separate boxes labeled Unfused: 6 each connect to the bar by one up arrow and one down arrow. Below it, one wide box with dashed internal dividers, labeled Fused: 2, connects by a single down arrow and a single up arrow.

The idealized intermediate stream falls from six transfers to two.

The intended function is preserved, although batch-normalization folding changes the arithmetic sequence, and the intermediate traffic falls by 3×. Generic bias-activation and attention fusion, by contrast, do not depend on compression and belong to the general fusion toolkit of ML Frameworks.

↩︎ IO-aware attention tiling and its HBM-traffic accounting are established in FlashAttention: IO-aware attention optimization.

A ResNet-50 layer with 256 channels and a \(28{\times}28\) spatial size puts numbers on this. Its feature map occupies 802.8 KB, so the four intermediate transfers that fusion removes amount to \(4 \times 256 \times 28 \times 28 \times 4 \text{ bytes} \approx \text{3.2 MB}\) per layer. The full accounting also counts weights and parameters. Without fusion, each operation performs its own memory round-trip: Conv reads input (802.8 KB) plus weights (2.4 MB) and writes output (802.8 KB), totaling 4 MB. BN then reads that output, adds its parameters (2 KB), and writes again, for 1.6 MB. ReLU repeats the pattern for another 1.6 MB. The total unfused memory traffic is 7.2 MB. With fusion, the entire sequence reads input and weights once and writes the final output once, requiring only 4 MB, a 44.8 percent bandwidth reduction.

At the reference H100’s 3,350 GB/s HBM bandwidth, these traffic volumes imply ideal lower bounds of 2 microseconds before fusion and 1.2 microseconds after fusion, a 1.81× ratio for the traffic component alone. These are not full layer latencies because convolution compute, cache effects, and launch overhead must also be included. Furthermore, fusion needs the computation captured as a graph, and dynamic control flow, in-place mutation, or unsupported operations can block the rewrite, so the exported plan must be inspected rather than assumed (graph capture is developed in Graph capture and JIT compilation).

↪ The register pressure and accelerator-specific constraints that bound how far kernels can be fused on GPUs and TPUs are developed in Performance benefits and constraints.

Quantization adds a fusion of its own. A weight-only INT8 or INT4 kernel must turn each packed integer code \(\QuantizedIntegerCode\) back into a real value \(\QuantizerInput\) before multiplying it, using the scale \(\QuantizationScale\) and zero-point \(\QuantizationZeroPoint\) of equation 1 and equation 2: \[ \QuantizerInput= \QuantizationScale(\QuantizedIntegerCode - \QuantizationZeroPoint) \tag{4}\] Executed as a separate kernel, dequantization writes the full-precision weights back to memory and reads them again, restoring the traffic that quantization removed. Fused into the matrix-multiplication kernel, the dequantize step runs in registers on each tile as it arrives, so only the packed bytes cross the memory bus. That fusion is what lets GPT-2 XL’s INT4 weights deliver the decode speedup computed in section 10.3.5. When a runtime cannot fuse it, the quantized model can run slower than its FP16 baseline, a failure section 10.5.4.2 examines. Fusion removes intermediate traffic between operations that must all run, leaving the complementary hardware question of how to skip operands that pruning has already set to zero.

10.4.2 Sparsity exploitation

Replacing pruned weights with zeros inside a standard dense matrix still fetches every zero from memory and multiplies it in the ALU, yielding no wall-clock speedup. Sparsity exploitation designs the storage layouts and kernels that translate sparsity19—tensors where a substantial fraction of entries are zero—into reduced memory traffic and execution time.

19 Sparsity: From Latin sparsus (scattered), past participle of spargere (to scatter); in ML, \(\ell_1\) regularization such as the lasso can induce exact zeros rather than merely small values (Tibshirani 1996). Software can represent arbitrary sparsity patterns, while efficient hardware execution generally requires a supported format or structured pattern (for example, NVIDIA’s 2:4 sparsity). The gap between representable and executable sparsity separates theoretical compression from realized speedup.

Tibshirani, Robert. 1996. “Regression Shrinkage and Selection via the Lasso.” Journal of the Royal Statistical Society: Series B (Methodological) 58 (1): 267–88. https://doi.org/10.1111/j.2517-6161.1996.tb02080.x.

Formally, for a sparse weight matrix \(\SparseWeightMatrix\in \mathbb{R}^{\WeightMatrixRowCount\times \WeightMatrixColumnCount}\), the nominal sparsity ratio \(\SparsityRatio\) is: \[ \SparsityRatio= \frac{\Vert \ZeroEntryIndicator\Vert_0}{\WeightMatrixRowCount\times \WeightMatrixColumnCount} \] where \(\ZeroEntryIndicator\) is an indicator function that yields 1 if entry \((\MatrixRowIndex,\MatrixColumnIndex)\) is zero and 0 otherwise, and \(\Vert \cdot \Vert_0\) counts nonzero entries. When magnitude pruning treats entries below \(\PruningThreshold\) as removable, the thresholded sparsity ratio becomes: \[ \ThresholdedSparsityRatio= \frac{\Vert \BelowThresholdIndicator \Vert_0}{\WeightMatrixRowCount\times \WeightMatrixColumnCount} \] where \(\PruningThreshold\) defines the pruning boundary. Zeros yield wall-clock acceleration only when the execution pipeline skips both the arithmetic and the associated memory traffic.

From an execution standpoint, the spatial pattern of zeros determines memory transaction efficiency. As established in section 10.2.1.2, unstructured sparsity zeroes arbitrary scalar connections, requiring pointer arrays and non-unit-stride gathers that degrade bandwidth on SIMD and systolic units. Conversely, structured patterns, such as channel pruning or \(N\):\(M\) constraints, preserve predictable memory layouts, aligning with standard dense kernels or dedicated hardware datapaths.

Sparsity utilization methods

Translating zeros into runtime speedup requires a representation that encodes nonzero positions and a kernel that decodes those coordinates to bypass unneeded computation (Hoefler et al. 2021). In a matrix-vector product, a dense \(4{\times}4\) operator executes 16 multiply-accumulate operations, whereas a sparse execution path computes only the six nonzero products alongside the necessary metadata lookups: \[ \begin{bmatrix} 2 & 0 & 0 & 1 \\ 0 & 3 & 0 & 0 \\ 4 & 0 & 5 & 0 \\ 0 & 0 & 0 & 6 \end{bmatrix} \begin{bmatrix} \SparseProductInputComponent_1 \\ \SparseProductInputComponent_2 \\ \SparseProductInputComponent_3 \\ \SparseProductInputComponent_4 \end{bmatrix} = \begin{bmatrix} 2\SparseProductInputComponent_1 + \SparseProductInputComponent_4 \\ 3\SparseProductInputComponent_2 \\ 4\SparseProductInputComponent_1 + 5\SparseProductInputComponent_3 \\ 6\SparseProductInputComponent_4 \end{bmatrix} \]

The runtime benefit depends entirely on whether the latency eliminated by skipping 10 multiply-accumulate operations exceeds the latency added by coordinate decoding and non-contiguous activation loads. For unstructured sparsity, that trade has a computable answer in bytes and a measurable one in time.

Storage and execution break-even

A variant of the running case makes the byte side concrete. Suppose the camera team must also ship its MobileNetV2 to a wearable companion device whose microcontroller offers only 2 MB of flash memory, against the model’s 14 MB of FP32 weights. Retraining a smaller architecture from scratch would require weeks of data collection and validation that the product schedule does not allow. Suppose profiling shows that about 85.7 percent of the model’s weights are near zero and contribute little on the validation set. Removing those weights and fine-tuning the remainder for a few epochs leaves surviving weight values that total 2 MB with an acceptable accuracy loss. Whether the stored artifact also fits in 2 MB depends on how the surviving weights are stored. The numbers are a labeled scenario that anchors the engineering trade-off, not a universal MobileNet benchmark.

Storing only the surviving values requires an indexed sparse encoding such as Compressed Sparse Row (CSR) or coordinate list (COO). Because these formats must store positional metadata (such as column indices and row pointers) alongside the nonzero values, metadata overhead offsets savings at low sparsity. For example, storing a 16-bit floating-point weight with a 16-bit column index doubles the per-element byte footprint, requiring over 50 percent sparsity just to break even on artifact size (\(\DataVolume\)). Storing a dense tensor with zeroed entries saves zero memory. The wearable variant shows the consequence. Its surviving weights total 2 MB only if they cost nothing to locate. A 16-bit index beside each value adds half again to 32-bit values and doubles 16-bit ones, so the stored artifact misses the 2 MB flash budget. A denser position encoding, such as a bitmap, reduces the metadata overhead but cannot fit unchanged values that already consume the entire budget. Fitting requires further pruning or lower-precision values with room reserved for metadata, or structured removal of whole channels so that the remaining tensors can be stored without per-value indices.

↪ The memory footprint and index-pointer layouts for compressed sparse row (CSR) representations are collected for reference in Sparse matrix formats.

Nor does unstructured sparsity translate directly to inference acceleration on modern hardware. Commodity accelerators achieve peak throughput (\(\PeakRate\)) through dense systolic arrays and wide SIMD execution units that rely on memory coalescing. Memory transfers use device-dependent transaction granularity, and caches store data in cache lines. Coalescing nearby, aligned accesses lets parallel threads share transactions more efficiently. A dense masked tensor still moves its zero entries. An indexed sparse encoding instead packs nonzero values, but Sparse Matrix-Dense Matrix Multiplication (SpMM) kernels must decode metadata and gather the matching activations. Irregular activation accesses, load imbalance, and kernel overhead can offset the skipped arithmetic even when stored weight values are contiguous. The performance break-even point depends on shape, format, batch size, and the available sparse kernel, so artifact reduction alone does not establish a speedup.

Structured patterns

Structured patterns resolve the break-even problem by constraining where zeros occur, and achieving actual speedups from them requires hardware that can efficiently skip zero-valued computations. Processor architectures differ in which patterns they exploit. Ampere-generation and later Sparse Tensor Cores exploit fine-grained 2:4 structured patterns, while systolic arrays require dense block structures. Libraries such as cuSPARSE reformulate sparse computations into patterns the hardware handles well, and MegaBlocks (Gale et al. 2022) recasts sparse mixture-of-experts training as block-sparse operations on dense tiles.

Gale, Trevor, Deepak Narayanan, Cliff Young, and Matei Zaharia. 2022. “MegaBlocks: Efficient Sparse Training with Mixture-of-Experts.” arXiv Preprint.

A sparse pattern earns hardware speedup only when it is regular enough for kernels to predict. Two formats make that regularity explicit: block sparse matrices and N:M sparsity patterns. Block sparse matrices group nonzeros into dense submatrices, so operations on the large sparse matrix become a smaller number of dense operations on submatrices. In the illustrated representation, \(3\times 3\) dense sub-blocks are indexed by an auxiliary coordinate array, so sub-block kernels can bypass the empty tiles (figure 28) (NVIDIA 2020). The block size is a teaching choice. Actual speedup requires a block shape, layout, datatype, and kernel supported by the target library and hardware; regular blocks alone do not guarantee aligned memory transactions or Tensor Core execution.

Figure 28: Block Sparse Representation: Grouping non-zero weights into dense sub-blocks and storing an auxiliary index array lets matching kernels skip empty blocks. The \(3\times3\) tiles illustrate the representation; efficient GPU execution depends on supported block shapes, layouts, and kernels. Adapted from NVIDIA cuSPARSE documentation (NVIDIA 2020).
NVIDIA. 2020. Accelerating Matrix Multiplication with Block Sparse Format and NVIDIA Tensor Cores.

Similarly, N:M sparsity retains at most \(\StructuredSparsityNonzeroCount\) nonzeros in each group of \(\StructuredSparsityGroupSize\) consecutive elements; hardware-oriented pruning often enforces exactly \(\StructuredSparsityNonzeroCount\) retained values so every group has the same representation (Zhou et al. 2021). The deterministic format lets a supported kernel predict the value and metadata layout while retaining more capacity than removing whole channels or blocks. That regularity creates an executable compromise between arbitrary masks and dense computation, but only for targets with the matching path.

Zhou, Aojun, Yukun Ma, Junnan Zhu, Jianbo Liu, Zhijie Zhang, Kun Yuan, Wenxiu Sun, and Hongsheng Li. 2021. “Learning n:m Fine-Grained Structured Sparse Neural Networks from Scratch.” arXiv Preprint.
Lu, Yucheng, Shivani Agrawal, Suvinay Subramanian, Oleg Rybakov, Christopher De Sa, and Amir Yazdanbakhsh. 2023. “STEP: Learning n:m Structured Sparsity Masks from Scratch with Precondition.” arXiv Preprint.

On hardware with a sparse matrix path, the 2:4 pattern of section 10.2.1.3 turns into execution savings, since its 2-bit position indices cost far less than the pointer arrays of general CSR or COO formats (NVIDIA Corporation 2020). The sparse datapath that consumes those indices and skips the zeroed multiplies is developed in N:M structured sparsity mechanics. Learned masks need not stop at 2:4; STEP, for example, learns more general N:M masks for inference (Lu et al. 2023).

Unstructured pruning zeroes arbitrary individual weights. Those irregular locations can disrupt memory coalescing and lane utilization, while Compressed Sparse Row (CSR) or Coordinate (COO) metadata adds storage and non-unit-stride accesses. An unstructured sparse model can therefore run slower than its dense counterpart when metadata and underutilization outweigh skipped arithmetic. TPUs are useful contrast cases for dense systolic-array acceleration (Jouppi et al. 2021), but sparse acceleration still depends on a specific hardware and software path rather than accepting arbitrary masks. Field-programmable gate arrays can implement application-specific sparse formats, yet their efficiency depends on the chosen dataflow and resource budget; programmability is not a universal sparse-speedup guarantee.

Jouppi, Norman P., Doe Hyun Yoon, Matthew Ashcraft, Mark Gottscho, Thomas B. Jablin, George Kurian, James Laudon, et al. 2021. “Ten Lessons from Three Generations Shaped Google’s TPUv4i: Industrial Product.” 2021 ACM/IEEE 48th Annual International Symposium on Computer Architecture (ISCA), 1–14. https://doi.org/10.1109/isca52012.2021.00010.
Gale, Trevor, Matei Zaharia, Cliff Young, and Erich Elsen. 2020. “Sparse GPU Kernels for Deep Learning.” SC20: International Conference for High Performance Computing, Networking, Storage and Analysis 2020: 8955–67. https://doi.org/10.1109/sc41405.2020.00021.

Across all platforms, sparse operations can reduce memory bandwidth requirements and energy consumption when the sparse representation and kernels actually skip data movement rather than only arithmetic. This benefit compounds with quantization, since a sparse INT8 model can require less memory traffic than either technique alone when the format overhead is small enough (Hoefler et al. 2021; Gale et al. 2020).

Challenges and limitations

A blue speedup curve starts just below a dashed horizontal line labeled Dense 1×, crosses that line inside a gray shaded band labeled Break-even varies, then climbs to the right. The horizontal axis is labeled Sparsity. No sparsity percentage is marked.

Unstructured sparsity pays off only after crossing a hardware- and kernel-specific break-even point.

The dependence of every sparse speedup on a matching format and kernel explains why nominal sparsity often fails to deliver speedups in practice. First, the performance break-even point varies with tensor dimensions, sparse format, kernel implementation, and hardware architecture. When coordinate metadata and irregular activation gathers saturate cache lines, an unstructured sparse kernel can run slower than an optimized dense baseline until sparsity exceeds 80 to 90 percent. Second, the accuracy-efficiency trade-off is nonlinear, because models often tolerate moderate pruning before task quality degrades abruptly past a critical density threshold. Finally, energy savings do not scale linearly with skipped operations; irregular memory access and index decoding can consume more power on edge devices than the arithmetic they eliminate. Fusion and sparse kernels thus decide whether each technique’s paper savings survive contact with the hardware. Most deployments apply several techniques at once, and choosing and ordering them is the next decision.

Self-Check: Question
  1. A paper estimate predicts an \(8\times\) speedup for a compressed model under ideal assumptions, but the implementation measured on an unmodified GPU delivers only \(1.5\times\). Which statement best defines the role of hardware implementation in explaining this gap?

    1. It aligns computation graphs, memory access layouts, operator scheduling, and sparsity patterns with physical accelerator architectures so that theoretical compression can translate into measured wall-clock speedup
    2. It reduces the volume of training data needed to fine-tune compressed neural networks
    3. It eliminates all memory-bound operations by converting every neural network layer into a compute-bound GEMM
    4. It automates the hyperparameter tuning of learning rates and batch sizes during pretraining
  2. Operator fusion of Conv-BatchNorm-ReLU sequences produces substantial execution speedup on modern GPUs even though the fused kernel preserves the intended layer function. Which mechanism explains this latency reduction?

    1. Fusion reduces the total number of weight parameters stored in the convolutional layer
    2. Fusion retrains the network to use lower numerical precision during the forward pass
    3. Fusion skips zero-valued activation elements by converting dense tensors to sparse matrices
    4. Fusion executes convolution, batch normalization, and ReLU inside a single GPU kernel, keeping intermediate activations on chip and cutting intermediate-tensor traffic and launch overhead
  3. A compressed neural network achieves a \(50\%\) reduction in total floating-point operations (FLOPs), yet on the deployment accelerator, end-to-end inference latency decreases by only \(10\%\). Explain two distinct hardware and architectural mechanisms that cause this discrepancy.

  4. True or False: Commodity SIMD vector units automatically achieve proportional latency reductions on weight matrices with \(50\%\) unstructured sparsity because vector lanes automatically skip zero values without overhead.

  5. A team optimizes a deep network for NVIDIA Ampere GPUs that feature hardware-accelerated 2:4 structured sparsity. Which compression strategy directly engages this dedicated accelerator capability?

    1. Unconstrained unstructured magnitude pruning, because maximum zero count always yields the highest speedup on Ampere
    2. Dynamic channel pruning that alters tensor shapes per batch, because Tensor Cores require dynamic input dimensions
    3. Structured 2:4 sparsity (exactly 2 non-zero values in every contiguous block of 4 elements), because Ampere Tensor Cores include a supported sparse path for that pattern
    4. Activation checkpointing, because recomputing intermediate activations during inference eliminates sparse matrix indexing overhead

See Answers →

10.5 Choosing and Combining Techniques

When the chapter’s phone decodes GPT-2 XL, its FP16 weights and KV cache claim 3.3 GB of the 8 GB that the operating system and other applications also share, each generated token waits about 65 ms while every weight streams over the 51.2 GB/s bus, and the handset sustains only 3–5 W before thermal throttling. Choosing among compression techniques—and ordering them—starts from whichever of those physical limits binds first, alongside the allowable task accuracy loss and the available training budget.

The three primary optimization levers target different levels of the system stack. Distillation alters the algorithmic architecture by training a compact dense student to emulate a larger teacher, executing efficiently on standard hardware without specialized runtime support. Pruning modifies tensor topology and operation patterns, but yields wall-clock acceleration only when the resulting sparsity aligns with hardware execution units, such as 2:4 structured sparse matrix cores or channel-aligned sub-matrices. Quantization alters data representation by reducing numerical bit width, directly lowering memory bus traffic and cache footprint while engaging higher-throughput integer datapaths. Their first-order trade-offs, with representative ranges for common choices, sit side by side in table 11.

Table 11: Optimization Trade-Offs: Systems gain, quality impact, training cost, and hardware dependency for common compression choices. Region 1 marks little or no quality loss, region 2 a moderate trade, and region 3 steep quality loss. The ranges are representative engineering values synthesized from published work on inference runtimes, quantization, pruning, low-bit LLM quantization, and distillation (NVIDIA 2024; Jacob et al. 2018; Han et al. 2015; Lin et al. 2024; Hinton et al. 2015); actual results vary with architecture, task, range-calibration data, and implementation quality. The rows identify first-order candidates, not guaranteed outcomes, and the hardware dependency decides whether pruning or quantization changes latency at all.
NVIDIA. 2024. NVIDIA TensorRT: Programmable Inference Accelerator.
Han, Song, Jeff Pool, John Tran, and William J. Dally. 2015. “Learning Both Weights and Connections for Efficient Neural Networks.” Advances in Neural Information Processing Systems 28 (NeurIPS 2015), 1135–43.
Technique Systems gain Typical impact Training cost Hardware dependency Region
Kernel fusion 10–30% latency reduction No accuracy loss None The compiler must recognize the pattern 1
FP32 → BF16 2\(\times\) memory, ~2\(\times\) throughput \(<0.1\%\) accuracy drop None for inference A native BF16 path 1
FP16 → INT8 2\(\times\) memory, 2–4\(\times\) throughput Quantization error, 0.5–1% accuracy drop Low for PTQ; higher for QAT INT8 kernels for a runtime speedup 2
50% pruning ~2\(\times\) smaller model Capacity loss, 0.5–1% accuracy drop Usually includes fine-tuning Structured shapes or supported sparse kernels 2
Knowledge distillation 2–10\(\times\) smaller student Capability ceiling, 1–3% accuracy drop Teacher inference and a student run Low; the student is an ordinary dense model 2
4-bit quantization 4\(\times\) memory reduction Significant error, 2–5% accuracy drop Low for PTQ; higher for QAT Low-bit kernels with fused dequantization 2–3
90% pruning ~10\(\times\) smaller model Severe capacity loss, 5–15% accuracy drop Iterative fine-tuning Sparse kernels past the break-even point 3

10.5.1 The accuracy-efficiency frontier

Pushing a single compression knob too far—such as pruning 90 percent of a network’s weights or quantizing sensitive layers to 4 bits without retraining—crosses a cliff where a modest extra byte saving costs 5 to 15 percentage points of task accuracy (table 11). Every lever in the table moves the model along this accuracy-efficiency trade-off: additional model capacity can improve predictive accuracy while demanding larger weight payloads, expanded activation working sets, and higher memory bandwidth during inference. On hardware with strict memory or power limits, engineers first eliminate avoidable implementation costs, then choose among feasible operating points on the Pareto frontier (principle 5).

Systems Perspective 10.2: The compression-accuracy trade-off curve
The measured trade-off is not uniform. A structure-preserving implementation improvement can move a dominated model toward the frontier with little or no accuracy loss. Once on an efficient frontier, improving one objective trades against another; aggressive structural changes can enter regions with steep quality penalties.

The engineering decision is where to stop. The “knee” of the curve marks a region where further resource savings incur a sharper quality penalty. It is a useful visual diagnostic, but accuracy points cannot be compared directly with milliseconds, bytes, or joules. Stop at an operating point that meets the deployment’s quality and resource thresholds, using explicit objective weights if a further trade must be ranked.

Techniques that preserve model structure, such as kernel fusion and modest precision reduction (FP32 to BF16), can yield latency or memory gains with little quality loss when the model and execution path support them. In contrast, techniques that alter network structure, such as pruning and distillation, yield larger reductions in memory and arithmetic volume but risk significant quality degradation without careful retraining. Optimization therefore begins by identifying the binding hardware constraint—memory capacity on mobile devices, frame latency in interactive pipelines, or energy per inference on battery-powered sensors—so each tier can target the resource that actually binds: structural methods cut parameter and operation counts, quantization shrinks memory traffic and raises arithmetic intensity, and compiler-level fusion eliminates intermediate memory round-trips. The regions in table 11 mark where each choice typically lands on that curve, and a structured decision framework maps each binding hardware constraint to the specific levers worth testing first.

Checkpoint 10.4: The efficiency frontier

Optimization can remove avoidable costs or trade among efficient operating points.

Trade-offs

10.5.2 Decision framework

Applying a compression technique that targets the wrong hardware bottleneck wastes engineering cycles and task accuracy: pruning FLOPs from a layer stalled on off-chip weight streaming leaves memory-bus latency intact, whereas quantizing weights to 8 bits on a compute-bound processor that lacks an integer matrix unit leaves arithmetic throughput unchanged. Identifying the binding hardware constraint first narrows the search to the optimization tiers that can relieve it. Under the D·A·M taxonomy, compression methods redistribute resource demands across Algorithm (topology, pruning, distillation, and the numerical representation of weights) and Machine (execution units and memory hierarchies); range-calibration sets are the main Data-axis input. Each system constraint maps to the optimization tiers that can relieve it (table 12), where the marks identify mechanisms to investigate rather than guaranteed deployment gains.

Table 12: Optimization Tiers: System constraints drive optimization along three core tiers: model representation, numerical precision, and hardware implementation, each addressing different resource limitations and performance goals. ✓ marks a direct lever, while \(\triangle\) marks a workload- or hardware-dependent benefit; for example, low-precision arithmetic helps only when the accelerator and runtime provide a supported path.
System Constraint Model Representation Numerical Precision Hardware Implementation
Computational Cost ✓ \(\triangle\) ✓
Memory and Storage ✓ ✓ \(\triangle\)
Latency and Throughput ✓ \(\triangle\) ✓
Energy Efficiency ✓ ✓ ✓
Scalability ✓ \(\triangle\) ✓

One technique can move more than one term of the iron law. For example, quantizing weights from FP32 to INT8 directly relieves on-device storage capacity. A bandwidth-limited operator approaches proportional latency savings only when the affected traffic dominates and conversion overhead does not consume the gain. A compute-limited operator needs a faster supported execution path. Unstructured pruning likewise reduces executed arithmetic only when sparse kernels exploit the removed weights; indexing and irregular memory accesses can offset the saving. The changed representation therefore supplies a candidate improvement whose effect must be measured on the target.

When persistent storage or device memory capacity binds the deployment, as over-the-air package limits and microcontroller flash budgets do, quantization provides the most direct payload reduction. Relative to FP32 storage, INT8 post-training quantization (PTQ) cuts raw weight storage by 4\(\times\) without requiring retraining cycles. INT4 cuts raw payload by 8\(\times\), though aggressive bit-width reduction increases the risk of accuracy degradation. If uniform low-bit quantization causes unacceptable accuracy loss on sensitive layers, distilling knowledge into a smaller dense architecture followed by moderate quantization preserves fidelity while satisfying the storage budget.

When latency is compute-bound, the workload operates above the accelerator’s ridge point, the arithmetic intensity at which its compute and memory-bandwidth limits meet, saturating execution units. Relieving this bottleneck requires reducing executed operations or increasing arithmetic throughput. Structured pruning removes channels, attention heads, or entire layers, yielding smaller dense matrices that execute on standard libraries without sparse runtime overhead; however, pruning to dimensions that misalign with hardware warp or tile sizes (such as channel counts not divisible by 8 or 16) degrades tensor core efficiency and curtails wall-clock gains. If the target platform provides dedicated integer execution units, INT8 quantization increases the instruction throughput rate, accelerating compute-bound kernels directly. Early-exit architectures provide an alternative algorithmic path by dynamically halting inference on simpler inputs, provided that routing and pipeline synchronization overhead do not disrupt batch processing.

↪ How the ridge point shifts across accelerators and precisions is developed in Hardware ridge points.

Small-batch transformer generation often exposes a weight-bandwidth bottleneck, as GPT-2 XL decoding on the phone showed, because dense decoding streams large parameter matrices for matrix-vector operations with low arithmetic intensity. When fetched weights dominate latency, weight-only quantization (such as INT4 or INT8 weights paired with FP16 activations) can approach a speedup proportional to the reduction in those bytes. KV-cache traffic and dequantization overhead limit that gain without necessarily making execution compute-bound; larger batches can increase weight reuse and shift the limiting resource.

When energy or thermal dissipation binds, quantization provides substantial benefits because moving data across off-chip memory buses consumes orders of magnitude more energy per bit than on-chip arithmetic or local SRAM access. Reducing operand bit widths directly lowers bus capacitance charging energy, while integer ALUs consume less switching energy than floating-point datapaths. Structured pruning compounds these savings by eliminating operations and memory transactions entirely. Full-system power audits must still measure peripheral components (memory refresh, host bus communication, and static idle leakage) to ensure that kernel-level energy savings translate into extended operating life.

Selection also depends on the engineering and computational budget available. Calibrated PTQ needs only a small representative dataset, and QAT adds training cost only when PTQ misses the accuracy threshold. Knowledge distillation costs more, requiring teacher forward passes and substantial training cycles to optimize a smaller student model. Hardware-aware NAS occupies the highest cost tier, justified only when high-volume deployment amortizes the extensive compute needed to explore the architectural search space.

Applied to GPT-2 XL decoding on the phone, this framework makes INT4 weight-only quantization the first candidate, not a completed solution. It cuts the weight bytes to a quarter of FP16, but each token also streams the unchanged KV cache, and the gain holds only when dequantization is fused into the matrix multiplication (section 10.3.5). Distillation to a smaller model is another candidate if the remaining gap justifies its training cost. Each candidate must pass task-quality, latency, peak-memory, and sustained-power checks against the phone’s 3–5 W envelope.

Choosing an individual technique addresses a single binding bottleneck, but production deployment budgets frequently require compounding gains across multiple dimensions. When memory capacity, bandwidth, and compute throughput are all constrained simultaneously, optimizing a system requires composing structural alterations, precision reductions, and custom execution kernels into an integrated transformation pipeline.

10.5.3 Combining and sequencing techniques

Quantizing a network to fixed 8-bit integer ranges before pruning its channels shifts the activation distributions that those ranges were calibrated to fit, while removing floating-point precision before distillation hinders gradient recovery. Because each tier changes the weight and activation distributions or tensor shapes that the next tier sees, the order in which compression techniques are applied governs both final accuracy and hardware utilization. On the camera pipeline, the sequence follows directly from those dependencies between the tiers. Channel pruning comes first, with pruned channel counts kept on a multiple of the hardware’s tile width so the smaller layers still fill the phone’s matrix tiles. Distillation from the ResNet-50 teacher then serves as the recovery training for the pruned network, the prune-then-distill order described in section 10.2.3. INT8 quantization comes last among the model changes, because range calibration must see the weight and activation distributions of the final structure, and because INT8 is what moves the model from the phone’s CPU onto its integer accelerator. Batch-normalization folding and the remaining fusions are applied when the graph is compiled for the device. Each step is profiled on the phone before the next is taken, because each one changes the bottleneck that the next one faces. The steps also move different quantities, and most of the frame time comes off at the step that changes the processor (figure 29).

Figure 29: Compression Waterfall for the Camera Pipeline: MobileNetV2 weight memory (left) and frame time (right) after each model change, against the 33 ms budget of a 30 FPS camera. Weight memory follows from the parameter counts. The FP32 frame time is the running case’s illustrative value, and the hatched bars scale the running case’s frame times by the share of arithmetic the pruned network keeps. Channel pruning to width 0.75 keeps 70 percent of the arithmetic but leaves the frame near 87 ms on the CPU. INT8 cuts the weights by 4× and moves the model onto the integer accelerator, which brings the frame to about 20 ms. Folding and fusion, applied at compile time, are not modeled.

A modeled BERT-Base pipeline attaches numbers to the same staging. Pruning, distillation, and quantization together reduce its footprint from 440 MB to 28 MB (rounded), a 16× raw-footprint reduction. Each stage addresses a distinct bottleneck. Structural pruning removes redundant matrix multiplications, distillation supervises the compact student to recover representational capacity, and quantization packs weights and activations into lower-bit integers to relieve memory bandwidth pressure.

Example 10.2: BERT-Base mobile deployment pipeline
Scenario: A modeled deployment targets executing a 110M-parameter BERT-Base language model on resource-constrained mobile hardware. The compact graph is stipulated for this example; the figures are not reported DistilBERT results.

The FP32 teacher begins at 440 MB with assigned task accuracy 76.2 percent. Structural pruning produces a stipulated 27.5M-parameter graph, a 75 percent parameter reduction, with raw FP32 weights of 110 MB and assigned accuracy 75.1 percent.

That pruned graph is the distillation student. Teacher supervision recovers its assigned accuracy to 75.9 percent without another parameter-count reduction. Final INT8 quantization leaves the same parameter count, reduces raw weight storage to 27.5 MB, and has assigned accuracy 75.6 percent. The headline ratio uses this unrounded weight payload; scales, zero-points, packing, activations, and runtime workspace remain outside the calculation.

Diagnosis: In this modeled comparison, quantization before pruning has an assigned accuracy loss of 2.1 percent. One mechanism to investigate is whether structural changes invalidate previously calibrated ranges. Pruning and distillation before quantization allow calibration to use the resulting distributions. These modeled values illustrate the mechanism and do not establish a universal ordering.

Systems lesson: In this modeled pipeline, pruning, then distillation, then post-training INT8 quantization produce a 16× footprint reduction (440 MB to 28 MB) while limiting task accuracy loss to 0.6 percent. Because tensor distributions and hardware kernel efficiencies vary across architectures, each intermediate artifact must be profiled on the target runtime.

Sequencing matters because these transformations interact through shared parameters and activation distributions. Structural pruning removes channels or attention heads, altering the dynamic range and variance of surviving weight tensors. Quantizing before pruning can leave ranges poorly matched to the resulting distributions, so recalibration or joint adaptation may be needed. In the staged candidate, floating-point recovery lets the pruned network adapt, and distillation supplies a teacher signal before final quantization. QAT itself updates floating-point master weights through approximate gradients; it does not require direct integer weight updates. Alternative schedules should be compared at matched recovery and calibration budgets.

Combining techniques also changes the size-quality trade-off itself (Han et al. 2016). In one reported setting (figure 30), while individual SVD and pruning curves suffer steep accuracy cliffs below about 15 percent and 6 percent model size respectively, combining pruning with quantization extends the zero-loss plateau down to roughly 3 percent of original parameter footprint. This comparison does not isolate transformation order. The magnitude of these gains remains model- and runtime-specific, requiring engineers to validate each transformation stage independently.

Figure 30: Compression Methods in One Reported Setting: The cited comparison plots accuracy change against model-size ratio for pruning, quantization, their combination, and SVD. In this setting, pruning plus quantization reaches the smallest ratio near baseline accuracy; the ordering is model- and implementation-specific. Source: (Han et al. 2016).
Han, Song, Huizi Mao, and William J. Dally. 2016. “Deep Compression: Compressing Deep Neural Networks with Pruning, Trained Quantization and Huffman Coding.” arXiv Preprint.

Systems Perspective 10.3: The optimization composition problem
Optimization techniques interact through shared representations and physical resources rather than composing as independent functions. Pruning changes the surviving value distribution, tensor shapes, or sparse format; quantization adds scales and changes the available kernels; fusion changes which intermediates are materialized and can alter the profile that justified earlier choices. Composing pruning with quantization, as when 2:4 structured sparsity is paired with INT8 weights, leaves an executable that must carry both the sparsity metadata and the quantization scales, and a pruned shape that breaks the memory alignment a quantized kernel expects can erase the speedup of both (Hoefler et al. 2021). Effective optimization therefore treats the model-runtime-hardware combination as a coupled system, measures it after every transformation, and revisits the sequence when a new bottleneck appears. This makes compression a systems engineering problem as well as a machine learning problem.

Hoefler, Torsten, Dan Alistarh, Tal Ben-Nun, Nikoli Dryden, and Alexandra Peste. 2021. “Sparsity in Deep Learning: Pruning and Growth for Efficient Inference and Training in Neural Networks.” Journal of Machine Learning Research 22 (241): 1–124.

A footprint reduction that compounds on paper therefore becomes a speedup only where the runtime supports every transformation in the sequence at once, which makes the toolchain that applies them part of the decision.

10.5.4 Compression toolchains

Quantizing a large model by hand would mean editing thousands of operator call sites to insert scale factors and track activation ranges. Manual graph surgery also cannot guarantee autograd consistency during retraining or the memory alignment that accelerator kernels require. Compression therefore runs through tooling, and the tool choice follows the layer of the software stack that owns the transformation. Framework APIs operate on the high-level computation graph during training and calibration, where the execution engine maintains visibility into weights, activations, and autograd state. At this stage, quantization is typically simulated, with fake-quantization nodes that clamp and round values within floating-point registers, modeling numerical precision loss while preserving differentiability.

Simulating quantization does not itself establish a physical speedup. A compiler or runtime must lower the graph into supported kernels; frameworks may integrate that stage or export to a separate deployment engine. The runtime compiler fuses scale factor arithmetic directly into matrix-multiplication compute tiles and packs sparse weights into hardware-specific metadata layouts (such as 2:4 structured sparsity formats). This lowering eliminates round-trip memory transactions to HBM that would otherwise negate the benefits of reduced precision.

Reproducibility is the first requirement of a multi-stage pipeline. Compressing a model alters its numerical representations across both the algorithm and machine layers of the D·A·M taxonomy. Unrecorded calibration inputs or mismatched rounding modes can degrade accuracy silently without raising runtime errors, so every deployed artifact must remain traceable from its source training checkpoint, through the calibration data, pruning schedule, and fusions that produced it, to its compiled hardware execution graph.

↪ Versioned artifacts and the lineage graphs that keep deployed models traceable are developed in Versioning and lineage.

Model optimization APIs and tools

At the model-development layer, compression algorithms require access to runtime state that downstream deployment compilers discard: gradient histories, optimizer state variables, and dynamic activation distributions. When post-training quantization or one-shot pruning degrades accuracy beyond acceptable operating thresholds, recovery requires retraining or iterative fine-tuning. Frameworks such as PyTorch and TensorFlow provide optimization APIs specifically to manage this graph-transformation boundary. These APIs inject quantization nodes and observers, reparameterize weight tensors with sparsity masks, and preserve calibration metadata alongside the trained parameters, which is what makes a compression recipe repeatable across many models.

Quantization-aware training demonstrates this graph-level intervention. Optimization APIs insert the fake-quantization operators of section 10.3.3.2.2 into the compute graph; these operators clamp and round in the forward pass and apply the straight-through estimator of section 10.3.3.2.1 in the backward pass. Producing a deployable low-precision artifact then takes a short sequence of graph transformations and metadata tracking (listing 5).

Listing 5: Quantization-Aware Training: Mechanism-level transformation that trains through simulated low-precision behavior and exports the calibration metadata needed for deployment.
choose target precision and calibration policy
insert quantize/dequantize boundaries around selected tensors
train with simulated low-precision values while keeping gradient flow intact
record scales, zero points, accumulator precision, and unsupported operations
export the calibrated graph and metadata as one reproducible artifact

Pruning tools implement the mask-then-export boundary of section 10.2.1.7. A mask-based API keeps the dense weight tensor \(\WeightMatrix\) and a binary mask \(\PruningMask\) of the same shape during recovery training, computing \(\PrunedWeightMatrix= \PruningMask\odot \WeightMatrix\) in the forward pass so the existing dense kernels and gradient updates keep working. An export pass then finalizes the transformation, either slicing away pruned channels or encoding the nonzeros in a sparse format the target’s kernels accept. What must be recorded along the way, so that the compressed model can be reproduced, is short but not optional (listing 6).

Listing 6: Pruning Artifact Boundary: Applies unstructured or structured removal rules, then records the mask and fine-tuning context needed to reproduce the compressed model.
choose pruning granularity: individual weights, channels, blocks, or attention heads
score candidate parameters by magnitude, sensitivity, or validation loss impact
remove or mask the selected structure according to the hardware-compatible rule
fine-tune the compressed model against the original validation target
export weights, masks, sparsity pattern, and calibration evidence together

Hardware-specific optimization libraries

Exporting an optimized model from a training framework produces an intermediate graph representation, not an executable binary. Compilers and runtime engines such as TensorRT, Accelerated Linear Algebra (XLA), OpenVINO, and TVM own the final translation step: compiling a pruned, quantized, or fused graph into machine instructions tailored to the target accelerator. In D·A·M terms, algorithmic compression remains theoretical until the graph maps to kernels that physically exploit the target machine’s memory hierarchy and execution units.

The compilation pass verifies whether nominal compression yields physical speedup. Pruning that leaves zeros in dense tensors still streams and multiplies those entries with a dense kernel. Compact sparse formats need matching kernels, such as a supported 2:4 path, while structured channel removal can produce smaller tensors for ordinary dense kernels. Quantization lowers bitwidth, but a weight-only path may unpack operands into floating-point registers before arithmetic. That unpacking adds instructions; its cost must be compared with the packed weight traffic saved.

The result can be the runtime dequantization trap. If an accelerator provides native INT8 matrix-multiplication kernels but lacks an INT8 implementation for an adjacent operation (such as LayerNorm, GeLU, or an attention softmax reduction), the runtime encounters a type boundary. An unfused execution path may allocate a temporary buffer, launch a dequantization kernel to recover floating-point values (\(\QuantizerInput= \QuantizationScale(\QuantizedIntegerCode - \QuantizationZeroPoint)\), equation 4), execute the unsupported operator, and launch another kernel to re-quantize its output. The floating-point format and opportunities to fuse conversion depend on the runtime. These intermediate format conversions incur extra kernel launches, introduce synchronization barriers, and add temporary floating-point traffic that can make the quantized model slower than the FP16 baseline. A fused weight-only path instead unpacks values within the consuming kernel, the fusion of section 10.4.1, and retains a net memory-traffic benefit.

Low-precision kernels also require specialized tensor layouts, such as tiled or interleaved memory channels, to ensure coalesced loads into shared memory or register files. When an unsupported operator sequence blocks the fusions of section 10.4.1, the memory-bandwidth bottleneck remains intact. Whether integrated into a framework or supplied separately, the compiler and runtime determine which graph-level opportunities become an efficient machine execution plan. Whether that plan delivers the savings computed in the earlier sections is a question only measurement on the target hardware can answer.

Self-Check: Question
  1. A deployment fails because the model’s static weight footprint alone exceeds the available memory or storage budget on the target device. Which optimization dimensions should an engineer prioritize first?

    1. Hardware implementation alone, because runtime execution scheduling determines disk and RAM consumption
    2. Operator fusion alone, because fusing layers eliminates static weight parameter matrices
    3. Increasing training batch size, because larger batches compress parameter representations during optimization
    4. Model representation (pruning, distillation) and numerical precision (quantization), because both directly target the byte footprint of the deployed model
  2. A \(13\text{-billion}\)-parameter FP16 language model fits on the target edge server only at short context, but the required production KV cache and workspace do not fit. Profiling that feasible short-context baseline shows autoregressive decoding is dominated by weight traffic. Which optimization is the most direct initial candidate to test?

    1. Weight-only INT4 or INT8 post-training quantization (PTQ), because it directly shrinks raw weight bytes and can reduce weight-bandwidth pressure if the remaining memory budget also fits
    2. Unstructured magnitude pruning with 90% target sparsity, because arbitrary sparse patterns run fastest on edge memory controllers
    3. Neural Architecture Search from scratch, because searching a new architecture is the fastest way to resolve an immediate deployment deadline
    4. LayerNorm operator fusion alone, because LayerNorm compute dominates total parameter storage in large language models
  3. Order the stages of a practical compression decision procedure: (1) test a low-cost candidate and measure all relevant quality and resource constraints, (2) establish the binding constraint from a decisive capacity bound or from profiling a feasible baseline, (3) map that constraint to candidate optimization levers, (4) if the candidate fails, consider recovery training or a structural candidate appropriate to the failed constraint.

  4. The chapter’s illustrative BERT compression pipeline compresses a \(440\text{ MB}\) FP32 model down to \(28\text{ MB}\) (roughly \(16\times\)) by sequencing pruning, distillation, and INT8 quantization. Why do these techniques compound multiplicatively rather than substituting for one another?

    1. The techniques duplicate each other’s reductions, causing total compression to saturate at the performance of the single strongest method
    2. Pruning produces the smaller student graph, distillation recovers its quality at the same parameter count, and quantization reduces numerical bit-width per parameter; because these operate on orthogonal resource axes, their compression ratios multiply (\(4\times \text{ structural} \times 4\times \text{ precision} \approx 16\times \text{ total}\))
    3. Applying quantization automatically converts the pruned network into a student model without requiring teacher supervision
    4. Multiplicative gains occur only when the pipeline starts with operator fusion on uncompressed weights
  5. In a modeled scenario, one compression order loses \(0.6\%\) accuracy while the reversed order loses \(2.1\%\). Propose a plausible pruning-quantization interaction that could explain this gap, and state what a fair comparison should hold fixed before concluding the ordering matters.

  6. A measured compression-quality curve shows a clear knee: before it, each extra compression step saves substantial resource with small quality loss; after it, additional compression yields much smaller resource savings for noticeably larger quality loss. Explain how an engineer should use that knee when choosing an operating point for a deployment with explicit quality and resource constraints.

  7. An engineering team evaluates TensorFlow Model Optimization Toolkit (TFMOT) and PyTorch’s torch.ao APIs for a pipeline compressing hundreds of production models per month. What is the primary systems value these framework toolkits provide?

    1. They eliminate the need for engineers to benchmark or validate models on physical target hardware
    2. They automate the insertion and state management of complex compression primitives—such as fake-quantization observers, dynamic range trackers, and sparsity masking hooks—making compression scalable and reproducible across hundreds of models
    3. They automatically discover optimal hyperparameter architectures from scratch without compute overhead
    4. They guarantee identical execution performance across all CPU, GPU, and TPU backends without requiring hardware-specific compilers
  8. A model is pruned and quantized inside a training framework, but the exported deployment shows almost no speedup on the target accelerator. Explain why a hardware-specific compiler or runtime is still needed, and why framework-level masks or fake-quant operations are not enough evidence of real acceleration.

See Answers →

10.6 Measuring Compression Gains

Shrinking a model’s weights by \(4\times\) with INT8 quantization rarely cuts end-to-end latency by \(4\times\), because cache residency, memory bus contention, and kernel launch overhead absorb much of the theoretical gain. Every saving computed so far in this chapter is a paper bound, and only a measurement on the target device turns a bound into a result: profiling on the deployment hardware identifies which resource binds each layer, fixes an honest baseline, and separates model execution time from runtime and pipeline overhead.

10.6.1 Profiling and opportunity analysis

Compressing the layers with the most parameters or FLOPs can leave wall-clock latency barely changed when low-intensity operators—such as layer normalization or elementwise activations—contribute almost no FLOPs yet consume a large share of execution time by streaming whole activation tensors across memory. The top-down profiling method of Identifying Bottlenecks tells compression where to act, and two of its measurements decide the technique. Static footprint (weight tensors and persistent buffers) decides whether parameters fit in fast memory or device DRAM without spilling across PCIe, while dynamic allocation (activation tensors and KV caches) sets peak residency and so bounds batch size and serving concurrency. Alongside memory residency, each operator’s arithmetic intensity (\(\ArithmeticIntensity= \Operations/\DataVolume\)) shows whether removing FLOPs or removing bytes will actually shorten it.

A profile of a Vision Transformer (ViT) on an edge accelerator illustrates this operational heterogeneity. Per token and layer, the multilayer perceptron (MLP) block costs about \(8\HiddenDimension^2\) multiply-accumulates against \(4\HiddenDimension^2\) for the query, key, value, and output projections. In a ViT-Base-sized model the MLP blocks therefore carry nearly two-thirds of FLOPs and the projections just under one-third, with the attention score and weighting products adding only a few percent at standard image resolution. Layer normalization inverts the picture, contributing almost no FLOPs yet can claim a visible share of wall-clock latency, because it streams whole activation tensors with little arithmetic per byte. The camera pipeline’s MobileNetV2 splits the same way in convolutional form. Its \(1{\times}1\) expansion and projection layers carry most of the multiply-accumulates (Sandler et al. 2018), while its depthwise layers, like layer normalization, do little arithmetic per byte moved and take a larger share of time than of work. Profiling isolates the governing physical bottleneck for each component, dictating targeted optimizations rather than uniform compression: structured pruning of MLP hidden units relieves the compute-dominant blocks, kernel fusion eliminates intermediate global memory round-trips for memory-bound normalization layers, and INT8 quantization shrinks the static footprint that the MLP and projection weights dominate.

Sandler, Mark, Andrew Howard, Menglong Zhu, Andrey Zhmoginov, and Liang-Chieh Chen. 2018. “MobileNetV2: Inverted Residuals and Linear Bottlenecks.” 2018 IEEE/CVF Conference on Computer Vision and Pattern Recognition, 4510–20. https://doi.org/10.1109/cvpr.2018.00474.

A horizontal stacked bar has a narrow orange segment at the left, labeled Model 20% above it, and a wide slate-gray segment labeled Other 80% filling the rest.

Non-model work dominates latency, so compression caps speedup at 1.25\(\times\).

Translating layer-level profiling metrics into end-to-end system speedup requires accounting for the complete serving pipeline. In production serving systems, model execution frequently represents only a fraction of total latency, with the remainder consumed by image decoding, tokenization, RPC deserialization, or network transfer. Optimizing the model in isolation encounters an Amdahl ceiling whenever non-model stages dominate the latency budget, a ceiling that End-to-end vs. component latency measures end to end.

Systems Perspective 10.4: FLOPs reduction is not proportional speedup
Reducing a model’s FLOPs by 50 percent does not guarantee 50 percent latency reduction. Memory-bound operations see little benefit from arithmetic reduction because data movement, not multiplication, sets their time. Amdahl’s law (principle 8) applies at the system level. If model inference accounts for only 20 percent of end-to-end latency (with the remaining 80 percent spent on data loading, preprocessing, and postprocessing), then even perfect model optimization yields at most 1.25× overall speedup. Tokenization and network transfer can occupy the non-model fraction in language-model serving; image decoding, resizing, and normalization can do the same in vision pipelines. Profile the complete path on target hardware before estimating optimization benefits.

Complementing latency and throughput profiles, layer-wise sensitivity analysis quantifies how individual layers tolerate perturbation. In deep networks, different layers tolerate very different amounts of precision reduction or weight removal. Profiling accuracy degradation while systematically perturbing one layer at a time, with quantization noise or weight removal, identifies which components require high-precision representations and which can absorb aggressive 4-bit quantization or structured pruning without compromising task accuracy. Once opportunity and sensitivity profiles have guided a compression pass, the resulting candidate must be evaluated across both statistical quality and physical execution metrics.

10.6.2 Measuring optimization effectiveness

Judging a compressed model by a single scalar metric—such as top-1 accuracy or parameter count—can approve a candidate whose batch-one latency barely budges under kernel-launch overhead or whose confidence calibration drifts past safety limits on rare subgroups. Evaluating compression requires balancing statistical quality against physical execution costs across the Data, Algorithm, and Machine (D·A·M) axes. Quality baselines must capture aggregate accuracy, confidence calibration (verifying that predicted probabilities reflect empirical correctness), and performance across underrepresented input slices. Simultaneously, efficiency baselines must record peak memory residency, latency distributions (including p99 tail latency), memory bus saturation, and per-inference energy.

ResNet-50, the camera pipeline’s teacher and the book’s compute-bound lighthouse, shows how one compression decision ripples across physical and statistical dimensions. Quantizing it from FP32 to INT8 on the reference H100 changes latency, throughput, artifact size, energy, accuracy, and confidence calibration at once, and a deployment profile must report all six rather than an isolated accuracy number (table 13).

Table 13: ResNet-50 INT8 Deployment Profile on the Reference H100: Latency and FP32 throughput come from the modeled H100 engine profile, INT8 throughput is the MLPerf Inference measurement, and the accuracy and calibration values are illustrative. A real profile must measure all six on the target system.
Metric FP32 baseline INT8 result Deployment reading
Top-1 accuracy 76.1% 75.8% (0.3 pp drop) Aggregate accuracy mostly holds, but subgroup checks still matter.
Batch-one latency 0.38 ms 0.30 ms (1.3×) Fixed per-request costs dilute the gain for one image.
Large-batch throughput 15,200 img/s 89,470 img/s (5.9×) INT8 Tensor Cores pay off once arithmetic dominates.
Model size 102.4 MB 25.6 MB (4×) The artifact becomes easier to cache, transmit, and deploy on edge.
Energy/inference 46.1 mJ 7.8 mJ (5.9×) Assumes full board power at large batch; measure it directly.
Confidence-calibration error 2.1% 3.4% Confidence calibration can drift even when accuracy looks acceptable.

Converting weights to INT8 shrinks the artifact by 4× (from 102.4 MB to 25.6 MB), but the speed gain depends on how the model is served. At batch one, a compiled INT8 engine is only 1.3× faster than its FP32 counterpart (0.30 ms against 0.38 ms), because launch overhead, per-kernel floors, and the weight read form most of a single image’s time and shrink little with precision. At large batch the arithmetic dominates, and INT8 throughput of 89,470 img/s, as MLPerf Inference measured it, is 5.9× the modeled FP32 rate, a ratio between a measured rate and a modeled one from different software stacks. Energy per image follows throughput only if the board draws its full 700 W in both precisions; the 5.9× energy figure is that assumption, not a separate measurement. The runtime comparison in Inference Runtime Selection derives both latency figures from the same engine profile. While aggregate top-1 accuracy drops by only 0.3 percentage points (from 76.1 percent to 75.8 percent), confidence-calibration error (the gap between predicted probability and observed accuracy, distinct from the range calibration of quantization) increases from 2.1 percent to 3.4 percent. Post-quantization probability distributions drift, which can compromise safety-critical confidence thresholds even when top-1 classification accuracy appears preserved. Production deployment decisions require corresponding quality, latency, and energy measurements using a supported execution path on target hardware.

Suppose the application requires at least 75.5 percent top-1 accuracy and no more than 3.0 percent confidence-calibration error, measured with the same validation data and calibration metric as the profile. The INT8 candidate passes the accuracy limit but fails the calibration limit. Its modeled resource savings therefore do not justify acceptance. Retain the baseline for comparison, try confidence recalibration or a less aggressive quantization configuration, and repeat the quality checks before validating resource gains on the target runtime.

Two horizontal gray bars start from a shared zero line, labeled FP32 2.1% and INT8 3.4%. A red dashed vertical line labeled Limit 3.0% crosses them; the FP32 bar ends to its left and the INT8 bar extends past it.

The INT8 candidate fails the calibration limit despite holding accuracy.

A deployment profile shows whether a compressed model meets its limits but not why it misses one. Explaining a failure such as the calibration miss above requires looking inside the model, at where clipping, rounding, and pruning masks have changed its internal values.

10.6.3 Diagnostic visualization

When an exported model fails a quality or latency gate—like the ResNet-50 candidate whose confidence calibration drifted to 3.4 percent—summary metrics cannot tell whether the culprit is a single activation channel saturating its clipping bounds, a pruning mask erasing an active feature detector, or an unsupported operator falling back to floating point. Diagnostic inspection looks inside the compressed graph to verify numerical integrity after framework APIs calibrate the model and hardware optimization libraries lower it to the execution substrate (section 10.5.4). While system-scale validation and artifact monitoring belong to downstream deployment infrastructure, the immediate diagnostic task is verifying that quantization clipping, pruning masks, or sparsity patterns have not perturbed internal feature distributions beyond acceptable task error tolerances.

Quantization error histograms show whether error is broadly distributed or concentrated in outliers. Activation visualizations help detect clipping, overflow, and saturation. In a grid of first-layer convolutional filters, the top rows show distinct edge, color, and frequency detectors, while the bottom row shows uniform-looking filters that appear redundant at a glance but require measured activation tracing before they can be pruned safely (figure 31). Framework observers and debuggers can expose quantization ranges and tensor error, while compiler or runtime inspectors can show the graph and kernels that the exported model actually executes.

Figure 31: First-Layer Convolutional Filter Patterns: An \(8\times5\) grid groups stylized kernels into edge, color, frequency, mixed, and uniform-looking patterns. Appearance alone does not establish inactivity; pruning requires measured activation or importance evidence in addition to low weight variance.

Sparsity diagnostics identify candidate layers for sparse execution. The layer-wise schematic in figure 32 spans convolutional, fully connected, and transformer layer types and is not a measurement from one model or pruning run. Its rows illustrate how a pruning policy might distribute zeros unevenly across architectural blocks. A real diagnostic would pair each layer’s density with its storage format and target-kernel profile to determine whether those zeros reduce memory traffic or execution time. Graph viewers and sparsity inspection tools help locate the affected tensors; profiling establishes the deployment benefit.

Figure 32: Illustrative Layer-Wise Sparsity Distribution: This schematic combines several layer types to illustrate non-uniform parameter removal. Darker tiles indicate more zero-valued weights; their shade establishes neither task redundancy nor a runtime benefit.

The diagnostic value is the nonuniformity, not the exact shade of any one cell. Greater sparsity in later layers shows where the policy removed weights; it does not establish that those representations were redundant. Compare task quality after removing weights from a candidate layer and after recovery training, including performance on important input slices. Early-layer sparsity warrants the same checks because damaging feature extraction can propagate through subsequent layers. Only those comparisons can establish whether the observed removal pattern preserves required behavior. Each density also has a machine reading, because a layer whose zeros never cross the storage and execution break-even of section 10.4.2.2 saves neither bytes nor time, however dark its tile.

Checkpoint 10.5: From compression claim to deployment evidence

A compressed artifact must pass the same application requirements as its baseline.

Implementation tools make compression repeatable, but they do not make the trade-offs disappear. Pruning alters model structure or parameter count, quantization changes numerical representation, and distillation trains the smaller artifact against a teacher’s output distribution, and composing them unmeasured can produce latency regressions or silent accuracy collapse on target hardware. The methodology that makes a measured gain trustworthy, from benchmark design to the statistics of repeated runs, is developed in Benchmarking. The fallacies that follow collect the places where intuitive compression assumptions fail.

Self-Check: Question
  1. A profile of a ViT-Base-sized model shows that the MLP blocks carry nearly two-thirds of FLOPs and the query, key, value, and output projections just under one-third, while layer normalization contributes almost no FLOPs yet claims a visible share of wall-clock latency. What is the primary systems lesson this profile teaches?

    1. Optimization should focus exclusively on layer normalization because its latency share exceeds its FLOP share
    2. A single global optimization technique (such as uniform pruning) must be applied equally across all layers to ensure balanced execution
    3. Theoretical FLOP count is perfectly correlated with wall-clock execution time across all transformer layer types
    4. Different components exhibit distinct physical bottlenecks, so optimization must be component-specific rather than uniform across the whole model
  2. An engineering team reports that an INT8-quantized ResNet-50 model maintains top-1 validation accuracy within \(0.2\%\) of its FP32 baseline on ImageNet. Explain why this metric alone is insufficient to certify the model as deployment-ready, identifying at least three additional critical measurement axes required by the chapter.

  3. True or False: If an INT8-quantized classifier achieves the exact same top-1 accuracy as its full-precision baseline, its output probability distributions and confidence calibration are guaranteed to be equally reliable for downstream safety thresholds.

  4. In PyTorch and TensorFlow quantization toolkits, ____ nodes are temporarily attached to tensor edges during calibration or Quantization-Aware Training (QAT) to collect running statistics (min/max or histograms) and compute scale and zero-point parameters without altering the forward-pass numerical values.

See Answers →

10.7 Fallacies and Pitfalls

A team deploying GPT-2 XL on a phone might find that an uncalibrated 4-bit quantization cuts weight memory by 4\(\times\) while generation quality collapses. Conversely, a vision team might achieve 70 percent weight sparsity through unstructured pruning only to find inference latency increases because commodity GPU kernels cannot execute irregular sparse indexing. Model compression presents numerous counterintuitive traps where theoretical parameter or FLOP reductions fail to produce wall-clock speedups. The following fallacies and pitfalls examine where standard engineering assumptions break down across the model-runtime interface.

Fallacy: Optimization techniques can be applied independently without considering their interactions.

Engineers assume optimization strategies compose additively: 50 percent pruning plus 4× quantization yields combined benefits. In reality, techniques interact nonlinearly and compound losses. In a representative BERT-style compression scenario, pruning to 70 percent sparsity may preserve most task performance, but applying INT8 quantization afterward can lose more accuracy than QAT on the pruned model. Knowledge distillation from heavily pruned teachers can also transfer degenerate attention patterns that reduce student accuracy compared with distilling from dense teachers. As section 10.5.3 demonstrates, successful optimization requires coordinated application where techniques are sequenced together.

Pitfall: Assuming theoretical metrics or compression ratios translate directly into proportional deployment speedup.

Teams frequently reduce FLOPs or parameter counts substantially without realizing proportional latency gains on physical hardware. In one representative trace, a pruned model with 40 percent fewer parameters achieves only a 12 percent latency reduction because irregular sparsity prevents efficient execution. Similarly, reducing a transformer from 440 MB to 110 MB through INT8 quantization yields a 4× raw weight-payload reduction, yet format conversion and scalar fallback on hardware without a native low-precision datapath erode the latency gain. In the chapter’s illustrative composed pipeline combining 50 percent structured pruning and INT8 quantization, the realized speedup reaches only 1.5× against an 8× paper target. Measure wall-clock latency on the target execution units rather than extrapolating from nominal compression ratios.

Fallacy: Aggressive quantization maintains model performance with minimal accuracy loss.

Engineers assume quantization error scales uniformly with bit width. In practice, precision reduction can show threshold effects, and the threshold depends on the model, layer, quantizer, calibration, and training method. The ResNet and BERT values in this chapter are illustrative rather than universal degradation bands. Even operations such as LayerNorm and Softmax can be implemented with integer approximations, so they do not universally require FP16; whether a low-precision implementation preserves task quality must be measured. As section 10.3.3 demonstrates, mixed-precision approaches can retain higher precision where uniform quantization fails.

Pitfall: Defaulting to FP32 everywhere to avoid quantization risk.

FP32 uses twice the raw storage and bandwidth of BF16, but lower-precision execution does not automatically preserve convergence or accuracy. Mixed-precision training often retains FP32 accumulators or master weights and may require loss scaling, while inference precision must be validated per model and operator. The right question is what lowest precision preserves quality on the evaluation distribution and maps efficiently to the target hardware.

Fallacy: Post-training optimization is always enough.

Teams often begin with post-training quantization (PTQ) because it avoids retraining, and move to quantization-aware training (QAT) only when the PTQ artifact misses its thresholds. Post-training pruning and post-hoc distillation can likewise underperform training-aware schedules at aggressive sparsity or bit width. As detailed in section 10.3.3, the production threshold, not a presumption that either path is universally superior, governs the decision.

Fallacy: Sparse matrix representations always save memory and accelerate inference.

Sparse formats introduce coordinate metadata that erodes storage savings at moderate densities, as the 16-bit case of section 10.4.2.2 showed; 32-bit indices make the penalty larger. To represent \(\NonzeroCount\) nonzero values across \(\SparseMatrixRowCount\) rows, a coordinate list (COO) stores explicit coordinate tuples (row_idx, col_idx, value). For 32-bit floats and 32-bit integer indices, each nonzero element consumes 12 bytes (\(3\times\) a dense 4-byte FP32 entry), requiring greater than 66.7 percent sparsity just to break even on memory footprint. Compressed sparse row (CSR) eliminates redundant row coordinates by storing three arrays: values (\(\NonzeroCount \times 4\text{ B}\)), col_indices (\(\NonzeroCount \times 4\text{ B}\)), and row_pointers (\((\SparseMatrixRowCount+1) \times 4\text{ B}\)). Each nonzero entry costs 8 bytes (\(2\times\) a dense FP32 entry), requiring over 50 percent sparsity before the sparse structure consumes less memory than the original dense tensor; below 50 percent sparsity, CSR metadata expands the model’s memory footprint.

Execution faces similar break-even constraints. Converting tensors to sparse storage as soon as pruning creates zeros degrades latency if metadata decoding, irregular gather operations, and poor cache locality outweigh the saved arithmetic. No universal sparsity threshold exists, because tensor dimensions, sparse format, runtime kernel, batch size, and hardware architecture jointly govern whether sparse execution outperforms dense execution. Specialized formats such as 2:4 structured sparsity eliminate index arrays in favor of fixed 2-bit multiplexer metadata, providing an accelerator datapath that nearly halves weight traffic with minimal indexing overhead (section 10.2.1.3). Production workflows must therefore measure realized density and commit to a sparse representation only after verifying that the operational break-even threshold has been crossed on target hardware.

Self-Check: Question
  1. Which statement best captures the chapter’s analysis regarding the interaction between multiple model compression techniques?

    1. Compression techniques compose strictly linearly, so combining a \(2\times\) pruning gain and a \(2\times\) quantization gain always yields a \(4\times\) latency reduction regardless of hardware
    2. Quantization is the only technique that interacts with other methods, while pruning and distillation can always be designed in isolation
    3. Compression techniques interact nonlinearly through shared hardware bottlenecks (cache capacity, memory bandwidth) and competing accuracy budgets; their combined efficacy depends heavily on pipeline sequencing and joint on-target validation
    4. Applying more than one compression technique is never recommended because accuracy degradation is always strictly additive
  2. True or False: If a neural network’s parameter count is reduced by \(4\times\) via magnitude pruning, its deployed end-to-end inference latency on a standard mobile CPU is guaranteed to improve by approximately \(4\times\).

  3. Explain two distinct hidden runtime overheads—such as dynamic dequantization on unsupported hardware and uncoalesced memory access from unstructured sparsity—that can cause a model with an \(8\times\) theoretical compression ratio to exhibit virtually no wall-clock speedup when deployed in production.

See Answers →

10.8 Summary

Model compression fits a trained model inside a deployment budget by working three tiers of one stack, the descent the chapter map laid out at the start (table 2). Structural optimization changes what the model computes, precision changes how each value is stored, and hardware implementation decides how efficiently the remaining operations execute. The running cases showed each tier where it matters most. The camera pipeline’s MobileNetV2 spends its frame budget on arithmetic, so channel pruning, distillation from a ResNet-50 teacher, and an INT8 path onto the phone’s integer accelerator are its levers. GPT-2 XL decoding spends its token on bytes, so INT4 weights raise its token rate by 3.1× on the same phone, and only when dequantization is fused into the matrix multiplication. The tiers can compound, but their gains do not multiply automatically. Pruning, distillation, and quantization together produce the illustrative pipeline’s 16× footprint reduction from 440 MB to 28 MB; metadata, unsupported operators, and hardware mapping determine the realized deployment gain. A parameter reduction approaches the same latency reduction only when the affected work is on the critical path and the runtime can exploit the new representation. Profile on target hardware, not paper metrics.

Data selection and model compression divide the efficiency work along the D·A·M axes. Data selection acts on the Data axis and lowers the cost of producing a model by spending compute only on examples that carry signal. Compression acts where Algorithm meets Machine and lowers the cost of running the model by reshaping its structure and numerics for the target. Whether those deployment savings become real speedups still depends on the hardware and runtime that execute the compressed model. The need for them does not fade, because the bitter lesson keeps growing the models that win benchmarks while the envelopes of phones and microcontrollers stay fixed.

The counting rules developed across the chapter fit on one page (table 14). Together they let an engineer bound what a compression plan can save before a model is profiled on its target.

Table 14: Key Equations: The chapter’s counting rules in the notation of the sections that derive them. Each gives a paper bound; the hardware tier explains why a measured gain can fall short of it.
Quantity Formula Where derived
Nominal sparsity \(\SparsityRatio= \frac{\Vert \ZeroEntryIndicator\Vert_0}{\WeightMatrixRowCount\times \WeightMatrixColumnCount}\) section 10.4.2
Low-rank storage \(\WeightMatrixRowCount \FactorizationRank + \FactorizationRank \WeightMatrixColumnCount\) values in place of \(\WeightMatrixRowCount \WeightMatrixColumnCount\) section 10.2.2.1
Depthwise separable cost \(1/\LayerOutputWidth + 1/\KernelSize^2\) of a standard convolution’s arithmetic section 10.2.4.3
Convolutional model scaling \(\Operations\propto \LayerCount \cdot \WidthMultiplier^2 \cdot \InputResolution^2\) section 10.2.4.2
Affine scale and zero-point \(\QuantizationScale= \frac{\ClippingRangeUpperBound- \ClippingRangeLowerBound}{2^\QuantizationBitWidth- 1}\), \(\QuantizationZeroPoint= \text{round}\left(\frac{-\ClippingRangeLowerBound}{\QuantizationScale}\right)\) equation 1, equation 2
Dequantization \(\QuantizerInput= \QuantizationScale(\QuantizedIntegerCode - \QuantizationZeroPoint)\) equation 4
Requantization scale \(\RequantizationScale= \frac{\WeightQuantizationScale \cdot \InputQuantizationScale}{\OutputQuantizationScale}\) section 10.3.3.1.4
Fused chain traffic \(2\,\ChainedOperationCount \IntermediateTensorSize\) bytes unfused; \(2\IntermediateTensorSize\) fused section 10.4.1
Bandwidth-bound decode time \(\DataVolume/\Bandwidth\) per token, where \(\DataVolume\) counts the weight bytes plus the KV-cache bytes section 10.3.5
Key Takeaways: From benchmark winner to production model
  • Compression spends surplus capacity: Production models trade unused parameters, precision, and capacity for latency, memory, power, or cost limits the deployment cannot violate. The target is an artifact that meets the deployment objective and all required quality and resource constraints.
  • Savings multiply only when aligned: Structural pruning, distillation, quantization, and architecture changes can compound raw footprint reductions, as the modeled BERT mobile pipeline’s 16× ratio illustrates. The gain becomes real only when task quality holds and the resulting operators match the target runtime and accelerator.
  • Precision is a deployment decision: Where the target runtime supports it, INT8 post-training quantization is a useful first experiment because it reduces raw FP32 weight payload by 4\(\times\) without retraining. QAT, distillation, or mixed precision become candidates when range calibration or layer sensitivity exposes unacceptable error.
  • Hardware decides what a saving is worth: Unstructured sparsity and theoretical FLOP cuts do not imply latency gains unless kernels and memory layouts can exploit them. The chapter’s hypothetical 8× paper target vs. 1.5× realized outcome illustrates why target-hardware profiling is mandatory.
  • End-to-end latency caps model wins: Compression reduces end-to-end latency only when it accelerates the critical path; capacity or energy savings can remain valuable elsewhere. When inference is 20 percent of total request latency, Amdahl’s law (principle 8) caps even perfect model acceleration at 1.25×, so preprocessing, dispatch, and data movement may be the true optimization target.

The techniques in this chapter differ in almost every detail, yet one rule runs beneath all of them. Each obtains a smaller, faster, or cooler model by giving up something else. Pruning gives up capacity, quantization gives up numerical precision, and distillation consumes training compute. Where the model holds no surplus to give up, task quality degrades instead. Apart from removing genuinely avoidable work, such as an unfused intermediate round-trip, compression does not make the work disappear; it moves cost or risk from one part of the system to another, and the hardware decides how much each move saves. A technique that helps on a phone can therefore be worthless on a data-center GPU. This is the conservation-of-complexity heuristic at the level of a single model. A production artifact is a model whose structure, representation, and execution path have been engineered together until they fit the silicon and application constraints that govern deployment.

What’s Next: From math to physics
These optimization techniques compress the model’s logic, reducing the work the algorithm asks the machine to perform. Whether less work becomes less time depends on the silicon that executes it, and this chapter repeatedly ran into the memory wall, the regime where fetching a weight costs more than computing with it. Hardware Acceleration starts from that wall and from the ResNet-50 INT8 profile that closed this chapter, and explains how GPUs, TPUs, and NPUs organize tensor units, systolic arrays, and tiered SRAM/HBM hierarchies to keep arithmetic fed, which is what decides whether a quantized or sparse representation actually runs faster.

10.9 Self-Check Answers

Self-Check: Answer
  1. The chapter’s optimization framework organizes model compression along three abstraction levels. Which sequence matches the stack from most software-level to most hardware-level?

    1. Efficient numerics representation → efficient model representation → efficient hardware implementation
    2. Efficient hardware implementation → efficient model representation → efficient numerics representation
    3. Efficient model representation → efficient numerics representation → efficient hardware implementation
    4. Efficient hardware implementation → efficient numerics representation → efficient model representation

    Answer: The correct answer is C. The framework moves from changing the model graph itself, to changing how surviving values are represented, to changing how the resulting graph executes on hardware. An ordering that starts with hardware implementation confuses abstraction level with execution chronology: hardware constraints guide all three levels, but the figure presents a stack, not a compulsory workflow.

    Learning Objective: Identify the three abstraction levels in the chapter’s optimization framework from model representation down to hardware implementation

  2. A \(7\text{-billion}\)-parameter language model in FP16 occupies \(14\text{ GB}\) of weight memory alone. The target deployment platform is a smartphone with \(8\text{ GB}\) of shared RAM. Explain how quantizing weights to INT4 addresses both the physical memory capacity ceiling and the memory-bandwidth bottleneck during autoregressive token generation.

    Answer: INT4 cuts the raw weight payload from about \(14\text{ GB}\) in FP16 to about \(3.5\text{ GB}\), which can make the model a candidate for an \(8\text{ GB}\) phone where memory is shared with the OS, runtime, KV cache, activations, and metadata. In low-batch autoregressive decoding, latency can be dominated by streaming dense weights, so reducing weight bytes by \(4\times\) can reduce that weight traffic by about \(4\times\). The practical consequence is that INT4 can relieve both fit and bandwidth pressure, but it does not guarantee full runtime fit or a \(4\times\) end-to-end throughput gain because other memory and kernel costs remain.

    Learning Objective: Apply capacity and bandwidth reasoning to evaluate when INT4 weight quantization is a strong candidate for edge LLM deployment

  3. True or False: When a model cannot be deployed because its parameter footprint exceeds the device’s physical RAM capacity, operator fusion is an effective direct substitute for pruning or quantization.

    Answer: False. Fusion primarily reduces intermediate-tensor traffic and launch overhead by keeping adjacent operations on chip. If the dominant problem is the raw weight footprint itself, fusion does not remove enough stored parameter bytes to substitute for pruning or quantization, though some parameter folding patterns such as batch normalization folding can slightly change stored parameters.

    Learning Objective: Distinguish execution optimizations that reduce intermediate traffic from techniques that reduce the dominant stored weight footprint

  4. A ____ is the memory, time, and energy that a target device grants to each result a model produces, and model compression is the work of bringing a trained model’s demands inside it.

    Answer: deployment budget. Memory capacity bounds the bytes of weights and activations that can stay resident, a frame rate or token rate bounds the milliseconds available for each result, and a battery or thermal envelope bounds the joules each result may consume. A trained model’s demands were set by the accelerators it trained on, not by the device it must run on.

    Learning Objective: Define the deployment budget and name the three resources it bounds.

  5. Across the deployment contexts analyzed in the chapter, which platform most clearly makes model compression a feasibility requirement rather than mainly a throughput or cost optimization?

    1. TinyML microcontrollers, where SRAM and storage budgets are so small that some models cannot be placed at all without compression or redesign
    2. Cloud inference clusters, where only cloud systems face hard capacity limits and all smaller devices can compensate in software
    3. Autonomous edge servers, where continuous thermal throttling is preferred over changing the model
    4. Mobile smartphones, where unified memory architecture eliminates meaningful capacity constraints for large neural networks

    Answer: The correct answer is A. TinyML devices can have only hundreds of kilobytes of SRAM plus separate flash or storage limits, so a model may simply not fit unless its weights and working set are reduced enough. Capacity limits also matter on mobile and cloud systems, but the chapter uses microcontrollers to illustrate the clearest hard feasibility boundary. Claims that only cloud has hard limits or that phone memory is effectively unconstrained contradict the section’s deployment-budget comparison.

    Learning Objective: Compare deployment contexts to identify where compression is most directly required for basic model feasibility

  6. A mobile video-conferencing feature requires \(30\text{ FPS}\) background segmentation, but baseline FP32 MobileNetV3 runs at only \(8\text{ FPS}\). Applying INT8 quantization accelerates the model to \(35\text{ FPS}\) with a minor \(0.4\%\) drop in mIoU, satisfying the shipping requirement. Which region of the chapter’s compression-accuracy Pareto frontier best describes this outcome?

    1. Region 1 (free lunch), because achieving 35 FPS proves that INT8 quantization incurs zero loss in segmentation boundary fidelity
    2. Region 3 (danger zone), because any reduction in numerical precision destabilizes temporal consistency in video processing
    3. An unfeasible operating point outside the Pareto frontier, because 35 FPS exceeds the maximum display refresh rate
    4. Region 2 (efficient trade), because a modest, acceptable drop in segmentation accuracy unlocks a 4.4× frame rate increase that satisfies the 30 FPS real-time shipping threshold

    Answer: The correct answer is D. Region 2 (efficient trade) represents the practical operational sweet spot where an engineer trades a small, tolerable accuracy concession for a massive efficiency gain (\(8\text{ FPS} \to 35\text{ FPS}\)) that moves the application across a hard production requirement (\(30\text{ FPS}\)). Calling this a ‘free lunch’ overlooks that INT8 rounding introduces real numerical quantization error, while placing it in the ‘danger zone’ confuses a successful deployment trade-off with catastrophic accuracy failure.

    Learning Objective: Classify real-world deployment trade-offs into the three characteristic regions of the compression-accuracy Pareto frontier

← Back to Questions

Self-Check: Answer
  1. A team prunes ResNet-50 to \(50\%\) sparsity using unstructured magnitude pruning and observes only a \(1.1\times\) speedup on a commodity GPU. Switching to structured channel pruning at the exact same \(50\%\) sparsity yields a \(1.8\times\) speedup. Which systems mechanism best explains this difference?

    1. Structured pruning removes more total weight parameters than unstructured pruning at any given nominal sparsity percentage
    2. Structured pruning removes entire contiguous channels or filters, allowing smaller dense kernels to execute efficiently, whereas unstructured sparsity needs sparse storage, metadata, and irregular activation access
    3. Unstructured magnitude pruning requires zero retraining or fine-tuning, whereas structured channel pruning requires full retraining from scratch
    4. Commodity GPU memory controllers automatically coalesce random non-zero memory addresses into single-cycle burst transfers

    Answer: The correct answer is B. Structured channel pruning produces smaller dense tensors that still map well to standard dense kernels. Unstructured sparsity can reduce nonzeros, but exploiting it requires sparse encodings and matching kernels, which add metadata handling, irregular activation gathers, and possible load imbalance. The idea that random sparse accesses are automatically coalesced ignores the execution problem the section emphasizes, and equal nominal sparsity does not mean structured pruning removes more weights.

    Learning Objective: Compare structured and unstructured pruning in terms of how well each maps to efficient execution on commodity accelerators

  2. Order the stages of finding a winning lottery ticket in a neural network according to the Lottery Ticket Hypothesis (LTH): (1) Reset surviving weights to their original initialization values (\(W_0\)), (2) Train the dense unpruned network to convergence, (3) Retrain the sparse subnetwork to convergence, (4) Prune the lowest-magnitude weights to create a sparse mask.

    Answer: The correct order is: (2) Train the dense unpruned network to convergence, (4) Prune the lowest-magnitude weights to create a sparse mask, (1) Reset surviving weights to their original initialization values (\(W_0\)), (3) Retrain the sparse subnetwork to convergence. First, dense training allows gradient descent to differentiate parameter importance. Second, magnitude pruning isolates the most critical connections to form a binary mask. Third, resetting surviving parameters to their exact initial values (\(W_0\)) isolates the subnetwork’s topological initialization. Finally, retraining the sparse subnetwork validates whether it can match or exceed the original dense model’s accuracy.

    Learning Objective: Design an experimental procedure that sequences the iterative steps used to evaluate winning lottery tickets under the Lottery Ticket Hypothesis

  3. A team must compress a large transformer model for deployment across a fleet of commodity GPUs that lack dedicated sparse-matrix acceleration kernels. Which structural optimization technique is the strongest candidate for producing a smaller model that still executes efficiently on this hardware?

    1. Unstructured magnitude pruning, because sparse matrix multiplication routines run with zero memory overhead on all standard GPUs
    2. Extreme binary weight quantization, because 1-bit representations eliminate all memory traffic without degrading language model perplexity
    3. Knowledge distillation, because it transfers teacher behavior into a compact dense student architecture that runs well on standard dense GPU kernels
    4. Low-rank factorization without fine-tuning, because mathematical decomposition guarantees zero loss in representation capacity

    Answer: The correct answer is C. Distillation trains a new compact dense student, so the deployed model can use ordinary dense kernels that commodity GPUs already execute efficiently. That makes it a strong candidate when sparse acceleration support is absent. Unstructured pruning still depends on sparse formats and kernels, low-rank factorization is an approximation rather than a zero-loss guarantee, and the section does not claim pruning can never remove layers or that binary quantization is broadly safe for this setting.

    Learning Objective: Evaluate distillation as a structural optimization candidate when deployment hardware favors dense execution

  4. A square weight matrix of size \(4096 \times 4096\) in a transformer layer is decomposed using low-rank factorization at rank \(r = 128\). Calculate the theoretical reduction factor in both parameter count and multiply-accumulate (MAC) operations, and explain what trade-off this structural approximation introduces.

    Answer: The original matrix contains \(4096 \times 4096 = 16{,}777{,}216\) parameters (\(16.78\text{M}\) MACs per vector product). Factoring into two matrices of dimensions \(4096 \times 128\) and \(128 \times 4096\) requires \(2 \times (4096 \times 128) = 1{,}048{,}576\) parameters (\(1.05\text{M}\) MACs). This yields an exact theoretical reduction factor of \(\frac{4096^2}{2 \times 4096 \times 128} = \frac{4096}{256} = 16\times\) for both parameter storage and arithmetic operations. The trade-off is that factorization restricts the layer’s representational capacity to a low-dimensional subspace of rank 128, which can degrade model expressiveness and task accuracy unless recovered through subsequent fine-tuning, while introducing the runtime overhead of launching two consecutive matrix multiplication kernels.

    Learning Objective: Calculate parameter and arithmetic reduction factors for low-rank matrix factorization and evaluate the resulting rank-capacity trade-off

  5. An engineering organization is deciding between running a custom Neural Architecture Search (NAS) from scratch versus adopting an established NAS-discovered family (such as MobileNetV3 or EfficientNet). Which circumstance most strongly justifies investing in custom NAS?

    1. Novel or custom hardware accelerators with unique memory hierarchies or massive production deployment scale where small per-inference efficiency gains amortize large one-time search costs
    2. Standard GPU clusters running established vision benchmarks where off-the-shelf architectures like MobileNetV3 already fit latency budgets
    3. Rapid prototyping projects with a total engineering timeline under one week and fewer than 10 available GPUs
    4. Small-scale enterprise applications processing fewer than 1,000 queries per day on cloud instances

    Answer: The correct answer is A. Custom Neural Architecture Search (NAS) incurs substantial compute expenditure (historically hundreds to thousands of GPU-days), making it justifiable primarily when targeting novel hardware accelerators whose physical constraints are not served by existing architectures, or when extreme deployment scale (billions of daily inferences) allows modest per-query latency and energy gains to rapidly amortize the upfront search cost. For standard hardware, existing NAS-designed architectures (e.g., EfficientNet, MobileNetV3) provide proven efficiency out of the box without incurring search expenses. Fast prototyping and low-volume applications cannot justify the substantial time and compute cost required by NAS.

    Learning Objective: Evaluate the economic and architectural conditions that justify custom Neural Architecture Search versus adopting established efficient architectures

  6. Compare one-shot pruning with an iterative schedule that removes 10 percentage points of the original weights in each of 8 rounds with recovery between rounds. Explain why staged recovery can help, and what controlled comparison is needed before concluding that the iterative schedule is better.

    Answer: Iterative pruning removes capacity in stages, giving the surviving weights chances to recover after each cut, so it is often a strong candidate when high sparsity is the goal. For example, eight rounds of removing \(10\) percentage points of the original weights each can reach \(80\%\) total sparsity while interleaving recovery. But the chapter does not claim this always beats one-shot pruning at the same final target: the outcome depends on the recovery budget, architecture, and pruning procedure. The practical implication is to compare schedules fairly at matched recovery effort instead of assuming staged pruning is universally superior.

    Learning Objective: Compare one-shot and iterative pruning while recognizing that recovery quality depends on schedule and recovery budget, not a universal rule

← Back to Questions

Self-Check: Answer
  1. According to the chapter’s Horowitz energy constants, an INT8 integer addition consumes roughly \(0.03\text{ pJ}\) compared to \(0.90\text{ pJ}\) for an FP32 addition—a \(30\times\) energy reduction despite only a \(4\times\) reduction in bit-width. What explains this operation-level energy dividend?

    1. INT8 arithmetic eliminates the need for registers and ALU logic on the silicon die
    2. INT8 quantization automatically prunes zero-valued parameters before they reach the execution units
    3. The 8-bit integer adder circuit requires significantly fewer logic gates, capacitance, and switching energy per operation than a 32-bit floating-point adder with exponent alignment and normalization logic
    4. Floating-point operations require continuous synchronization with host CPU DRAM on every instruction

    Answer: The correct answer is C. The \(30\times\) arithmetic energy disparity (\(0.03\text{ pJ}\) for INT8 add vs. \(0.9\text{ pJ}\) for FP32 add based on Horowitz constants) stems directly from silicon circuit complexity: an 8-bit integer addition requires a compact adder circuit with minimal logic gates and switching capacitance, whereas a 32-bit floating-point adder requires extensive barrel shifters for exponent alignment, mantissa addition, normalization, and rounding logic. Quantization does not eliminate ALU circuitry or prune parameters, nor does FP32 require host CPU synchronization.

    Learning Objective: Explain the circuit-level physical mechanisms responsible for the energy efficiency advantage of INT8 arithmetic over FP32

  2. In affine (asymmetric) quantization, the integer parameter ____ shifts the quantized grid so that real-valued zero maps exactly to an integer representation, ensuring that zero-padded tensor regions introduce no numerical bias.

    Answer: zero-point. The zero-point (or zero point, \(Z\)) provides an integer offset that ensures the real floating-point value \(0.0\) is mapped precisely to an integer without rounding error, which is crucial for preserving exact zero representations in padded convolutional feature maps and ReLU activations.

    Learning Objective: Calculate the zero-point parameter in affine asymmetric quantization to preserve exact zero representations

  3. Order the stages of a standard post-training quantization workflow with static activation calibration: (1) quantize the finalized weights and export the deployment artifact, (2) run representative floating-point calibration inputs through the model and collect activation statistics, (3) choose activation clipping bounds from the collected statistics, (4) derive activation scales and zero-points from those chosen bounds.

    Answer: The correct order is: (2) run representative floating-point calibration inputs through the model and collect activation statistics, (3) choose activation clipping bounds from the collected statistics, (4) derive activation scales and zero-points from those chosen bounds, (1) quantize the finalized weights and export the deployment artifact. Calibration data must be observed before clipping bounds can be chosen, and those bounds must be fixed before scales and zero-points can be derived. Export belongs last because the deployment artifact should reflect the completed quantization parameters rather than precede them. Swapping calibration with export would freeze an artifact before the activation ranges needed to define it were established.

    Learning Objective: Sequence the main stages of static-calibrated post-training quantization from calibration through export

  4. Compare two validation settings for low-bit quantization: (1) candidate INT4 weight-only quantization for autoregressive decoding when profiling shows weight traffic dominates, and (2) candidate low-bit quantization for large-batch training of the same model. Explain why these two settings require different validation conditions before concluding the quantization is worthwhile.

    Answer: In low-batch autoregressive decoding, each generated token can be dominated by streaming dense model weights, so cutting weight bytes from FP16 toward INT4 can substantially reduce weight traffic and improve latency when the runtime has a matching kernel. The ideal bound is set by the weight-byte reduction, not an automatic \(4\times\) end-to-end speedup, because KV-cache traffic, activations, and dequantization overhead remain. Large-batch training is different: it is not automatically accelerated by weight-only INT4, because training is often compute-heavy and also requires a low-precision training recipe, supported execution units, and numerical validation rather than just compressing stored weights.

    Learning Objective: Contrast why weight-only low-bit quantization is most compelling for weight-bandwidth-bound decoding rather than automatically for training

  5. During post-training quantization of a convolutional network, activation profiling reveals that values are heavily concentrated near zero with a small set of extreme positive outliers. Which calibration strategy best preserves numerical resolution for the bulk of typical activations?

    1. Max-absolute-value calibration, because extending the quantization grid to include extreme outliers guarantees zero clipping error across all layers
    2. Uncalibrated uniform quantization, because activation distributions in neural networks always follow a perfectly uniform probability density
    3. Static symmetric quantization with range [-128, +127] mapped unconditionally to [-1.0, +1.0] across every layer
    4. Percentile or KL-divergence (entropy) calibration, which can clip extreme tails so more integer levels represent the dense bulk of activations

    Answer: The correct answer is D. When a tensor has a dense bulk near zero plus a rare outlier tail, percentile or KL-based calibration can trade some clipping of that tail for better resolution where most values actually lie. A percentile method such as keeping \(99.9\%\) of values clips the remaining tail by design. That trade can improve typical representation quality, but it is not harmless by definition because rare outliers may still matter for task accuracy. Max calibration instead spends range on those extremes and can waste bins on mostly empty space.

    Learning Objective: Compare calibration strategies for long-tailed activation distributions by analyzing the trade-off between clipping and resolution

  6. A team quantizing a deep convolutional network finds that per-channel (filter-wise) quantization achieves significantly higher accuracy than per-tensor (layer-wise) quantization at the same INT8 bit-width. Which mechanism explains this accuracy advantage?

    1. Per-channel quantization eliminates the need to compute or store scale factors and zero-points
    2. Individual convolutional filters within a layer often exhibit drastically different weight magnitude ranges; per-channel quantization assigns an independent scale factor to each filter, preventing wide-range filters from degrading the precision of narrow-range filters
    3. Per-tensor quantization can only be executed on CPUs, whereas per-channel quantization is restricted to edge microcontrollers
    4. Per-channel quantization automatically converts float operations into sparse matrix multiplications

    Answer: The correct answer is B. In deep convolutional neural networks, different filters within the same layer specialize in distinct feature patterns, often resulting in weight distributions with variances that differ by orders of magnitude. Under per-tensor (layer-wise) quantization, a single clipping range must encompass all filters, forcing narrow-distribution filters into a tiny subset of quantization bins. Per-channel (per-filter) quantization assigns an independent scale factor \(S_c\) and zero-point \(Z_c\) to each output channel, giving narrow-range filters finer numerical resolution when their ranges differ. This can explain the measured quality advantage, but scale metadata, kernel support, and the calibration policy still determine the deployment trade-off.

    Learning Objective: Explain why per-channel quantization granularity preserves accuracy in convolutional networks compared to per-tensor quantization

← Back to Questions

Self-Check: Answer
  1. A paper estimate predicts an \(8\times\) speedup for a compressed model under ideal assumptions, but the implementation measured on an unmodified GPU delivers only \(1.5\times\). Which statement best defines the role of hardware implementation in explaining this gap?

    1. It aligns computation graphs, memory access layouts, operator scheduling, and sparsity patterns with physical accelerator architectures so that theoretical compression can translate into measured wall-clock speedup
    2. It reduces the volume of training data needed to fine-tune compressed neural networks
    3. It eliminates all memory-bound operations by converting every neural network layer into a compute-bound GEMM
    4. It automates the hyperparameter tuning of learning rates and batch sizes during pretraining

    Answer: The correct answer is A. Hardware implementation is the layer that determines whether compressed representations map to efficient kernels, memory layouts, and execution paths on the target accelerator. A paper target such as \(8\times\) can collapse to a much smaller measured gain when sparse patterns, metadata, unsupported kernels, or layout issues block efficient execution. The section’s example is illustrative rather than a guaranteed multiplication of pruning and INT8 effects, so the right lesson is to explain the measured gap, not to assume the paper ratio must appear in practice.

    Learning Objective: Explain how hardware implementation determines whether theoretical compression savings become real speedups on target hardware

  2. Operator fusion of Conv-BatchNorm-ReLU sequences produces substantial execution speedup on modern GPUs even though the fused kernel preserves the intended layer function. Which mechanism explains this latency reduction?

    1. Fusion reduces the total number of weight parameters stored in the convolutional layer
    2. Fusion retrains the network to use lower numerical precision during the forward pass
    3. Fusion skips zero-valued activation elements by converting dense tensors to sparse matrices
    4. Fusion executes convolution, batch normalization, and ReLU inside a single GPU kernel, keeping intermediate activations on chip and cutting intermediate-tensor traffic and launch overhead

    Answer: The correct answer is D. Fusion helps by avoiding extra writes and rereads of intermediate activations and by reducing separate kernel launches. In the chapter’s idealized Conv-BN-ReLU accounting, the intermediate-tensor stream falls from six transfers to two, but that count excludes weights, auxiliary inputs, cache effects, and spills. The idea that fusion preserves exactly the same arithmetic is too strong: some patterns such as batch-normalization folding change the operation sequence while preserving the intended function within numerical tolerance.

    Learning Objective: Analyze operator fusion as a reduction in intermediate-tensor traffic and launch overhead rather than a change in model structure

  3. A compressed neural network achieves a \(50\%\) reduction in total floating-point operations (FLOPs), yet on the deployment accelerator, end-to-end inference latency decreases by only \(10\%\). Explain two distinct hardware and architectural mechanisms that cause this discrepancy.

    Answer: First, Amdahl’s Law at the pipeline level limits overall speedup: if model execution accounts for only a fraction of the end-to-end request pipeline (with data ingestion, preprocessing, tokenization, and postprocessing consuming the remainder), accelerating model arithmetic yields a diminished system-level improvement. Second, within the model itself, many non-compute-intensive layers (such as LayerNorm, Softmax, residual additions, and activation functions) are memory-bandwidth bound or latency-bound rather than compute-bound; cutting FLOPs in the compute-heavy layers leaves memory-bound execution time largely unchanged, capping measured speedup.

    Learning Objective: Explain why theoretical FLOP reductions fail to produce proportional latency gains using Amdahl’s law and memory-bound layer analysis

  4. True or False: Commodity SIMD vector units automatically achieve proportional latency reductions on weight matrices with \(50\%\) unstructured sparsity because vector lanes automatically skip zero values without overhead.

    Answer: False. A dense masked tensor still moves and processes zeros. To skip them, the runtime needs a compact sparse representation and a matching kernel, but that path adds metadata handling, irregular activation accesses, and possible load imbalance. Whether sparse execution wins depends on format, shape, batch size, and hardware; there is no universal sparsity percentage that guarantees proportional speedup.

    Learning Objective: Reject the misconception that unstructured sparsity automatically accelerates dense SIMD hardware

  5. A team optimizes a deep network for NVIDIA Ampere GPUs that feature hardware-accelerated 2:4 structured sparsity. Which compression strategy directly engages this dedicated accelerator capability?

    1. Unconstrained unstructured magnitude pruning, because maximum zero count always yields the highest speedup on Ampere
    2. Dynamic channel pruning that alters tensor shapes per batch, because Tensor Cores require dynamic input dimensions
    3. Structured 2:4 sparsity (exactly 2 non-zero values in every contiguous block of 4 elements), because Ampere Tensor Cores include a supported sparse path for that pattern
    4. Activation checkpointing, because recomputing intermediate activations during inference eliminates sparse matrix indexing overhead

    Answer: The correct answer is C. Ampere’s sparse Tensor Core path is designed for the specific 2:4 pattern, where each group of four weights keeps two nonzeros. The chapter’s example uses compact metadata with 2 bits per retained position, so one 4-element group carries 4 bits of position metadata alongside the retained values. That structure can nearly halve weight traffic and offers up to a \(2\times\) sparse arithmetic-rate improvement, but it is not an end-to-end guarantee once the rest of the execution path is included. Arbitrary unstructured masks do not activate this fixed hardware path.

    Learning Objective: Match NVIDIA Ampere’s 2:4 sparse acceleration path to the structured sparsity pattern it is designed to support

← Back to Questions

Self-Check: Answer
  1. A deployment fails because the model’s static weight footprint alone exceeds the available memory or storage budget on the target device. Which optimization dimensions should an engineer prioritize first?

    1. Hardware implementation alone, because runtime execution scheduling determines disk and RAM consumption
    2. Operator fusion alone, because fusing layers eliminates static weight parameter matrices
    3. Increasing training batch size, because larger batches compress parameter representations during optimization
    4. Model representation (pruning, distillation) and numerical precision (quantization), because both directly target the byte footprint of the deployed model

    Answer: The correct answer is D. If capacity is the binding constraint, the first useful levers are the ones that can reduce stored model bytes: changing the representation or reducing numerical precision. Quantization often gives the most direct byte reduction, while pruning or distillation can further reduce model size when they preserve acceptable quality. Hardware implementation still matters, but fusion cannot generally solve a dominant static-weight-capacity problem by itself.

    Learning Objective: Identify which optimization dimensions most directly address a deployment bottleneck in memory or storage capacity

  2. A \(13\text{-billion}\)-parameter FP16 language model fits on the target edge server only at short context, but the required production KV cache and workspace do not fit. Profiling that feasible short-context baseline shows autoregressive decoding is dominated by weight traffic. Which optimization is the most direct initial candidate to test?

    1. Weight-only INT4 or INT8 post-training quantization (PTQ), because it directly shrinks raw weight bytes and can reduce weight-bandwidth pressure if the remaining memory budget also fits
    2. Unstructured magnitude pruning with 90% target sparsity, because arbitrary sparse patterns run fastest on edge memory controllers
    3. Neural Architecture Search from scratch, because searching a new architecture is the fastest way to resolve an immediate deployment deadline
    4. LayerNorm operator fusion alone, because LayerNorm compute dominates total parameter storage in large language models

    Answer: The correct answer is A. In the chapter’s small-batch decoding regime, fetched weights can dominate latency, so lowering weight precision is the most direct way to attack both raw model size and streamed weight traffic. INT4 quarters raw weight bytes relative to FP16, while INT8 halves them. That makes weight-only PTQ a strong initial candidate, but not an automatic fix: feasibility still depends on the rest of memory usage, and realized speedup depends on the runtime path and overheads. Unstructured pruning and LayerNorm fusion do not target the dominant weight-byte bottleneck as directly.

    Learning Objective: Select weight-only post-training quantization as the strongest first candidate for a weight-bandwidth-bound LLM deployment

  3. Order the stages of a practical compression decision procedure: (1) test a low-cost candidate and measure all relevant quality and resource constraints, (2) establish the binding constraint from a decisive capacity bound or from profiling a feasible baseline, (3) map that constraint to candidate optimization levers, (4) if the candidate fails, consider recovery training or a structural candidate appropriate to the failed constraint.

    Answer: The correct order is: (2) establish the binding constraint from a decisive capacity bound or from profiling a feasible baseline, (3) map that constraint to candidate optimization levers, (1) test a low-cost candidate and measure all relevant quality and resource constraints, (4) if the candidate fails, consider recovery training or a structural candidate appropriate to the failed constraint. The team must first know what resource actually binds, then connect that diagnosis to plausible levers before choosing an initial candidate. Only after measuring the candidate against the deployment’s real constraints does it make sense to escalate. Swapping testing with diagnosis would risk optimizing for the wrong bottleneck, while swapping escalation earlier would spend retraining effort before the simple candidate was fairly evaluated.

    Learning Objective: Sequence a conditional compression workflow from bottleneck diagnosis through candidate testing and escalation

  4. The chapter’s illustrative BERT compression pipeline compresses a \(440\text{ MB}\) FP32 model down to \(28\text{ MB}\) (roughly \(16\times\)) by sequencing pruning, distillation, and INT8 quantization. Why do these techniques compound multiplicatively rather than substituting for one another?

    1. The techniques duplicate each other’s reductions, causing total compression to saturate at the performance of the single strongest method
    2. Pruning produces the smaller student graph, distillation recovers its quality at the same parameter count, and quantization reduces numerical bit-width per parameter; because these operate on orthogonal resource axes, their compression ratios multiply (\(4\times \text{ structural} \times 4\times \text{ precision} \approx 16\times \text{ total}\))
    3. Applying quantization automatically converts the pruned network into a student model without requiring teacher supervision
    4. Multiplicative gains occur only when the pipeline starts with operator fusion on uncompressed weights

    Answer: The correct answer is B. The stipulated pruned graph has 27.5M parameters, one quarter of the 110M teacher. Distillation recovers quality at that count; INT8 then stores each weight in one byte instead of four. The raw payload falls from 440 MB to 27.5 MB (rounded to 28 MB), a 16× reduction. Fusion changes execution rather than supplying either weight-storage factor. These arithmetic savings do not guarantee latency gains.

    Learning Objective: Explain why combining orthogonal compression techniques across structural and numerical dimensions yields multiplicative compression ratios

  5. In a modeled scenario, one compression order loses \(0.6\%\) accuracy while the reversed order loses \(2.1\%\). Propose a plausible pruning-quantization interaction that could explain this gap, and state what a fair comparison should hold fixed before concluding the ordering matters.

    Answer: The modeled result illustrates one plausible interaction: pruning changes the surviving weight and activation distributions, so quantization ranges chosen earlier may no longer match the final artifact well. Quantizing first can also distort the fine-grained information used by importance scoring. Pruning first preserves full-precision information during structure selection, after which calibration or retraining can target the pruned model actually being deployed. The practical implication is not that one ordering is universally best, but that schedules should be compared under matched recovery and calibration budgets because pruning and quantization interact through shared distributions.

    Learning Objective: Analyze why pruning and quantization order can matter by changing the distributions seen by importance scoring and calibration

  6. A measured compression-quality curve shows a clear knee: before it, each extra compression step saves substantial resource with small quality loss; after it, additional compression yields much smaller resource savings for noticeably larger quality loss. Explain how an engineer should use that knee when choosing an operating point for a deployment with explicit quality and resource constraints.

    Answer: The knee marks the region where marginal savings start to shrink relative to the quality penalty, so it is a warning that the trade-off is worsening. For example, one deployment may stop near the knee if it already meets its memory or latency target there, while another may compress past it if stricter resource limits require that sacrifice. The practical implication is that the knee helps interpret the curve, but the chosen operating point must still be the one that satisfies the deployment’s stated quality and resource constraints.

    Learning Objective: Explain how the knee of a measured quality-efficiency curve informs operating-point selection under explicit deployment constraints

  7. An engineering team evaluates TensorFlow Model Optimization Toolkit (TFMOT) and PyTorch’s torch.ao APIs for a pipeline compressing hundreds of production models per month. What is the primary systems value these framework toolkits provide?

    1. They eliminate the need for engineers to benchmark or validate models on physical target hardware
    2. They automate the insertion and state management of complex compression primitives—such as fake-quantization observers, dynamic range trackers, and sparsity masking hooks—making compression scalable and reproducible across hundreds of models
    3. They automatically discover optimal hyperparameter architectures from scratch without compute overhead
    4. They guarantee identical execution performance across all CPU, GPU, and TPU backends without requiring hardware-specific compilers

    Answer: The correct answer is B. Production-grade model compression requires managing thousands of observer nodes, tracking dynamic activation ranges, inserting fake-quantization operators for QAT, and scheduling sparsity masks across training steps. Framework APIs (such as PyTorch torch.ao and TensorFlow Model Optimization Toolkit) automate this tedious and error-prone structural plumbing, enabling scalable, reproducible compression workflows. They do not replace empirical hardware benchmarking, eliminate search compute, or bypass the need for hardware-specific runtime lowering.

    Learning Objective: Explain how framework-level optimization toolkits automate structural compression workflows while preserving the need for hardware-aware validation

  8. A model is pruned and quantized inside a training framework, but the exported deployment shows almost no speedup on the target accelerator. Explain why a hardware-specific compiler or runtime is still needed, and why framework-level masks or fake-quant operations are not enough evidence of real acceleration.

    Answer: Framework-level pruning masks and fake-quant or graph annotations do not by themselves create a fast execution path. A hardware-specific runtime or compiler lowers the exported graph to supported kernels, fuses adjacent operators, chooses hardware-friendly layouts, and maps low-precision or sparse patterns onto the target’s actual execution units. Some deployment stacks integrate compiler and runtime functions, but the key requirement is still proof that the exported path really executes the compressed form efficiently. The practical implication is that compression inside the framework can remain only a logical transformation until the deployment runtime proves that the exported operators, layouts, and kernels really exploit it.

    Learning Objective: Explain why deployment compilers or runtimes are needed to convert framework-level compression into actual hardware acceleration

← Back to Questions

Self-Check: Answer
  1. A profile of a ViT-Base-sized model shows that the MLP blocks carry nearly two-thirds of FLOPs and the query, key, value, and output projections just under one-third, while layer normalization contributes almost no FLOPs yet claims a visible share of wall-clock latency. What is the primary systems lesson this profile teaches?

    1. Optimization should focus exclusively on layer normalization because its latency share exceeds its FLOP share
    2. A single global optimization technique (such as uniform pruning) must be applied equally across all layers to ensure balanced execution
    3. Theoretical FLOP count is perfectly correlated with wall-clock execution time across all transformer layer types
    4. Different components exhibit distinct physical bottlenecks, so optimization must be component-specific rather than uniform across the whole model

    Answer: The correct answer is D. The profile shows that FLOP-heavy components and latency-heavy components are not always the same. MLP and projection blocks dominate arithmetic work, while LayerNorm can consume noticeable time because it streams activations with low arithmetic intensity. The right response is heterogeneous optimization based on the bottleneck each component presents. A profiler showing high achieved arithmetic utilization in the heavy matmul region would further support a compute-focused intervention there, while LayerNorm may call for fusion or other memory-traffic reductions.

    Learning Objective: Use layerwise profiling to choose bottleneck-specific optimizations instead of assuming one metric or one tactic fits the whole model

  2. An engineering team reports that an INT8-quantized ResNet-50 model maintains top-1 validation accuracy within \(0.2\%\) of its FP32 baseline on ImageNet. Explain why this metric alone is insufficient to certify the model as deployment-ready, identifying at least three additional critical measurement axes required by the chapter.

    Answer: Near-baseline top-1 accuracy says little about whether the compressed model meets deployment constraints. The chapter also requires measuring on-target latency, peak runtime memory rather than just artifact size, and energy per inference in joules or sustained power in watts. It also calls for checking calibration drift, because confidence quality can degrade even when accuracy looks stable. For example, with a \(75.5\%\) minimum top-1 accuracy and a \(3.0\%\) maximum calibration error, the modeled INT8 profile passes accuracy but fails calibration. Acceptance requires satisfying each stated limit; resource gains cannot compensate for a failed quality requirement.

    Learning Objective: Identify the additional latency, memory, energy, and calibration measurements needed beyond top-1 accuracy to validate a compressed model

  3. True or False: If an INT8-quantized classifier achieves the exact same top-1 accuracy as its full-precision baseline, its output probability distributions and confidence calibration are guaranteed to be equally reliable for downstream safety thresholds.

    Answer: False. Top-1 accuracy counts correct argmax predictions; equal aggregate accuracy does not require the same examples to be correct. Even when every argmax prediction stays unchanged, quantization can alter logit magnitudes and output probabilities, changing confidence calibration. In safety-critical systems, an uncalibrated quantized model may output overconfident or miscalibrated probabilities despite maintaining identical top-1 accuracy.

    Learning Objective: Compare top-1 classification accuracy with confidence calibration and probability reliability in quantized models

  4. In PyTorch and TensorFlow quantization toolkits, ____ nodes are temporarily attached to tensor edges during calibration or Quantization-Aware Training (QAT) to collect running statistics (min/max or histograms) and compute scale and zero-point parameters without altering the forward-pass numerical values.

    Answer: observer. Observer nodes (or observers / quantization observers / observer nodes) monitor tensor value distributions during calibration passes or QAT epochs, calculating scale (\(S\)) and zero-point (\(Z\)) values before being removed or converted into fixed quantization parameters during final graph freezing.

    Learning Objective: Explain the role of observer nodes in collecting activation statistics and computing quantization parameters

← Back to Questions

Self-Check: Answer
  1. Which statement best captures the chapter’s analysis regarding the interaction between multiple model compression techniques?

    1. Compression techniques compose strictly linearly, so combining a \(2\times\) pruning gain and a \(2\times\) quantization gain always yields a \(4\times\) latency reduction regardless of hardware
    2. Quantization is the only technique that interacts with other methods, while pruning and distillation can always be designed in isolation
    3. Compression techniques interact nonlinearly through shared hardware bottlenecks (cache capacity, memory bandwidth) and competing accuracy budgets; their combined efficacy depends heavily on pipeline sequencing and joint on-target validation
    4. Applying more than one compression technique is never recommended because accuracy degradation is always strictly additive

    Answer: The correct answer is C. The chapter emphasizes that compression techniques do not operate in a vacuum: they share physical hardware resources (memory bandwidth, cache capacity, register pressure) and draw from the same underlying model error tolerance. For instance, aggressive pruning reduces the numerical headroom available for subsequent quantization, and uncoalesced sparse memory access can negate quantization bandwidth savings. Therefore, techniques interact nonlinearly and must be evaluated and validated jointly. Claiming linear composition ignores hardware realities, while declaring multi-technique pipelines unviable contradicts proven multiplicative compounding.

    Learning Objective: Analyze how compression techniques interact nonlinearly through shared physical resources and joint accuracy budgets

  2. True or False: If a neural network’s parameter count is reduced by \(4\times\) via magnitude pruning, its deployed end-to-end inference latency on a standard mobile CPU is guaranteed to improve by approximately \(4\times\).

    Answer: False. A \(4\times\) parameter reduction does not imply a \(4\times\) latency reduction because sparse execution depends on layout, kernel support, tensor shape, and device behavior. On a standard mobile CPU, unstructured sparsity may still incur dense-like traffic or sparse-format overhead, and end-to-end latency also includes work outside the pruned layers.

    Learning Objective: Reject the assumption that parameter-count reduction guarantees proportional end-to-end latency improvement

  3. Explain two distinct hidden runtime overheads—such as dynamic dequantization on unsupported hardware and uncoalesced memory access from unstructured sparsity—that can cause a model with an \(8\times\) theoretical compression ratio to exhibit virtually no wall-clock speedup when deployed in production.

    Answer: One hidden cost is conversion overhead: if an exported graph crosses unsupported low-precision boundaries, the runtime may insert extra quantize or dequantize work and additional launches, increasing traffic and synchronization instead of reducing them. A fused weight-only path may still save weight traffic, so the real question is what the deployed operator path actually does. A second cost is sparse-execution overhead: unstructured sparsity can require metadata, irregular memory access, and weak cache or SIMD utilization. The practical consequence is that theoretical compression must be validated against the actual exported kernel path, not inferred from bytes or nonzeros alone.

    Learning Objective: Analyze how conversion overhead and irregular sparse execution can erase theoretical compression gains in deployment

← Back to Questions

Back to top