Panel Optimizer

Panel Optimizer

Use the Optimize screen (/rust/optimize) to measure alternative settings, inspect repeat results and quality floors, save measured candidates as profiles, and apply only a selected candidate. Use Workload (/rust/workload) for real-traffic observations and auto-fit proposals. All settings remain subject to the existing owners' validation and capability gates.

Tune for coding or agentic work

1. Select the intended running, healthy instance in Instance controls. For a realistic comparison, make sure the service is idle and that the model and installed engine will remain unchanged during the trial.
2. Open the Measure coding or agentic performance and apply a profile guide at /rust/instances/guides/instances.tune-coding, or use Optimize directly. Select Optimization goal (the agentic goal is the coding-oriented preset) and Trial budget (quick, standard, or thorough). Larger budgets consume more runtime and generate more trial requests.
3. Choose Approve measured trials, then Run optimization. Actual measurements are subject to health, idle-traffic, temperature, quality and device checks. The runner does not automatically change the production configuration to a candidate.
4. Use Examine completed trial evidence to inspect completed candidates, measured speed, quality and reliability. Reject candidates with missing or failed quality checks. Enter the Completed run ID and Winning candidate ID only after the run is finished.
5. Use Save measured result as a named profile, then Review winning profile before activation. The named saved model profile does not itself activate new live settings.
6. Choose Approve applying the profile, then Apply measured profile. This writes measured values to saved parameters under the optimizer's durable rollback journal. Use Undo this step to invoke the matching optimizer rollback where eligible.
7. If the response says a restart is needed, use the guarded restart workflow and inspect the outcome. Saved data is not evidence that the running engine adopted the profile.

Changing the measured model after a run invalidates candidate application. Applying can be refused when a trial is active, a model changed, an unverified receipt is required, or a previous rollback remains unresolved. Preserve prior settings until the new state has been verified.

Validate candidate behavior without applying it

On Optimize (/rust/optimize), Golden-answer validation displays the current validation state, run identity, completed checks and failure information from GET /api/optimize/validation/status, independent of the optimizer's run history. Refresh to obtain another snapshot. An administrator may choose Validation duration (one pass, one hour, four hours or one day), enter Minimum pass score (%) from 0 through 100, acknowledge that test requests will be sent, and choose Start validation. The owner receives POST /api/optimize/validation/start; invalid durations, non-finite scores and out-of-range scores are refused before the call.

While validation runs, Stop validation requests POST /api/optimize/validation/stop after explicit acknowledgment. Validation does not apply an optimizer candidate; follow the trial evidence and separate guarded Apply workflow before changing saved settings. Readers can inspect progress but cannot start or stop a run.

Optimizer trial and history controls

Optimization evidence shows live progress and completed runs. Optimizer run details reads selected run evidence from GET /api/optimize/run; Optimizer task suite reads the measurement suite from GET /api/optimize/suite. Operators and administrators may use Start Optimize and Stop Optimize. Apply one measured candidate and Roll back the last Apply are administrator-only. These forms call the existing owner and require confirmation for disruptive operations. Candidate application changes saved settings only; a separate verified restart may be needed. The read-only view never offers those forms.

Auto-fit from real workloads

1. On Workload inspect the traffic envelope, findings and current auto-fit configuration.
2. Review proposed changes and their observed evidence. Run an experiment only when you can tolerate measured trial requests and any allowed service disruption.
3. Explicitly approve an eligible proposal; inspect the applied settings and verification result. Use the available rollback if observed behavior worsens.

Automatic selection is not a substitute for observed fit or actual device admission. A workload without enough samples should be interpreted as uncertain.

Workload observations and safely reversible proposals

On Workload (/rust/workload), the snapshot includes request distribution, observed concurrency, context depth, hours, findings, proposed fits and run history from GET /api/workload. Refresh to see new data. Administrators may save Workload settings and Rollback an applied workload change; operators and administrators may start an Auto-fit experiment, Stop an experiment, and Apply or Dismiss a measured proposal. These forms use /api/workload/settings, /api/workload/experiment, /api/workload/stop, /api/workload/proposal/apply, /api/workload/proposal/dismiss, and /api/workload/rollback, respectively; confirmation is required where the action changes live or saved state. An acknowledgment is not proof that a background experiment or rollback has finished; inspect its recorded outcome. Readers see data without mutation controls.

Optimize and workload control reference

Control (feature ID)	Effect and cost	Native page	Routes	Command-line flag
Start answer validation (instances.optimizer-validation)	Runs golden-answer checks or timed soaks, without applying a candidate.	/rust/optimize	GET /api/optimize/validation/status, POST /api/optimize/validation/start	—
Stop answer validation (instances.optimizer-validation-stop)	Requests that active validation stop while preserving completed checks.	/rust/optimize	POST /api/optimize/validation/stop	—
Optimizer run details (instances.optimizer-run)	Reads trial details for a selected run; no settings are applied by reading.	/rust/optimize	GET /api/optimize/run	—
Optimizer task suite (instances.optimizer-suite)	Shows the tasks and weights used for optimizer evaluation.	/rust/optimize	GET /api/optimize/suite	—
Workload observations (instances.workload-evidence)	Reads request observations and measurements without mutation.	/rust/workload	GET /api/workload	—
Stop workload experiment (instances.workload-stop)	Stops an active fit experiment and requests settings restoration.	/rust/workload	POST /api/workload/stop	—
Optimization goal (instances.optimizer-goal)	Chooses coding or agentic evaluation; a mismatched goal can optimize the wrong behavior.	/rust/optimize	POST /api/optimize/start	—
Optimization budget (instances.optimizer-budget)	Controls the search effort; larger budgets take longer and can cause repeated restarts.	/rust/optimize	POST /api/optimize/start	—
Optimizer phases (instances.optimizer-phases)	Selects launch, cache, sampling or specification trials; extra phases require more testing time.	/rust/optimize	POST /api/optimize/start	—
Quality tolerance (instances.optimizer-quality)	Limits acceptable quality regression; stricter limits reject more candidates and take longer.	/rust/optimize	POST /api/optimize/start	—
Thermal safeguards (instances.optimizer-thermal)	Pauses or aborts trials at chosen temperatures; conservative limits can extend testing time.	/rust/optimize	POST /api/optimize/start	—
Start optimization (instances.optimizer-start)	Runs measured candidate trials; this can restart inference repeatedly and delay normal requests.	/rust/optimize	POST /api/optimize/start	—
Stop optimization (instances.optimizer-stop)	Stops further trials and restores saved settings; the current measurement may need to finish.	/rust/optimize	POST /api/optimize/stop	—
Optimization evidence (instances.optimizer-status)	Shows measured candidates and progress; readings are snapshots and may change.	/rust/optimize	GET /api/optimize/status, GET /api/optimize/runs	—
Apply winning candidate (instances.optimizer-apply)	Saves a selected measured candidate; new launch settings may need restart and can be rolled back.	/rust/optimize	POST /api/optimize/apply	—
Revert optimization (instances.optimizer-rollback)	Restores pre-optimization settings; active serving may need a safe restart.	/rust/optimize	POST /api/optimize/rollback	—
Workload settings (instances.workload-settings)	Sets the observation window and guardrails; narrow windows can reduce confidence in recommendations.	/rust/workload	POST /api/workload/settings	—
Workload experiment (instances.workload-experiment)	Measures workload-fit candidates; testing can restart the service and consume processing time.	/rust/workload	POST /api/workload/experiment	—
Apply workload proposal (instances.workload-apply)	Applies a measured proposal; a restart may be needed and can interrupt work.	/rust/workload	POST /api/workload/proposal/apply	—
Dismiss workload proposal (instances.workload-dismiss)	Hides a recommendation; the proposal will no longer be available to apply.	/rust/workload	POST /api/workload/proposal/dismiss	—
Rollback workload change (instances.workload-rollback)	Restores previous workload settings; a restart may be needed to take effect.	/rust/workload	POST /api/workload/rollback	—
Save tuning profile (instances.tuning-profile)	Persists a benchmark-informed profile; applying it later can change speed or memory use.	/rust/optimize	POST /api/tuning/profile/save	—
Runtime governor (instances.governor)	Chooses runtime guardrails; stricter limits may reduce throughput or trigger fallback.	/rust/optimize	POST /api/governor/settings	—

For device selection, launch presets and safe restart safeguards, see Panel-Instances.