Add search playbook blog

[shaahji]

Add search playbook blog

Blog detailing practical search strategies/playbook for optimizing large models.

Checklist before requesting a review

• Add unit tests for this change.
• Make sure all tests can pass.
• Update documents if necessary.
• Lint and apply fixes to your code by running lintrunner -a
• Is this a user-facing change? If yes, give a description of this change to be included in the release notes.

(Optional) Issue link

[Copilot]

🟡 Changes recommended

The blog contains unresolved accuracy and configuration issues in its examples and guidance.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

Adds a practical Olive search-strategy blog covering quantization workflows, samplers, staged searches, and dataset reduction.

Changes:

• Adds the search playbook with mixed-precision and GPTQ examples.
• Documents search-space sizing, sampling, and optimization guidance.
• Registers the blog in documentation navigation.

File summaries

File	Description
docs/source/blogs/search-playbook.md	New search and quantization workflow guide.
docs/source/blogs/index.md	Registers the blog in the gallery and toctree.

Review details

Suppressed comments (9)

docs/source/blogs/search-playbook.md:123

• max_samples is a limit on the sampler for each SearchSpace, not always a workflow-wide cap: pass-by-pass creates one sampler per pass space. The 30-trial claim is safe for this joint example, but this general description should qualify staged searches.

- **``max_samples``** — hard cap on the number of configurations actually evaluated. With ``tpe``, 30 well-chosen samples out of 6,300 effective configurations can get you very close to the best one — without the cost of trying all 6,300.

docs/source/blogs/search-playbook.md:127

• stop_when_goals_met is ignored for pass-by-pass by SearchStrategyConfig validation (olive/search/search_strategy.py:66-77), so this lever needs a joint-only qualification.

- **``stop_when_goals_met``** — stop early once a target metric (e.g. accuracy or size) is satisfied, rather than spending the full ``max_samples`` budget.

docs/source/blogs/search-playbook.md:145

• As written, this HuggingfaceContainer has no text-generation task or preprocessing parameters, so it selects the generic huggingface_pre_process (which requires model_name and input_cols) and does not produce the tokenized input_ids/attention_mask that GPTQ validates. The sample workflow will fail during calibration; configure the text-generation preprocessor and sample limit here.

        "load_dataset_config": {
            "data_name": "wikitext",
            "subset": "wikitext-2-raw-v1",
            "split": "train"
        }

docs/source/blogs/search-playbook.md:205

• The coordinate-sweep snippets omit four other searchable SelectiveMixedPrecision fields. With search active, high_bits, high_group_size, high_sym, and ratio fall back to their search defaults, so the first snippet can generate 8×2×6×3×4 points and score-based choices need ratio; it is not an 8-trial sweep. Pin these fields in each snippet before claiming 8/3/5 trials.

1. **``algorithm`` first.** This is the parameter most likely to make or break your accuracy/size trade-off, and it's cheap to compare because you fix everything else (e.g. ``bits``=4, ``group_size``=128, ``sym``=False) and run all 8 candidates:

docs/source/blogs/search-playbook.md:304

• max_time and max_iter are only honored for joint execution; SearchStrategyConfig resets them for pass-by-pass. Qualify this budget advice or recommend sampler max_samples for staged searches.

- **Set ``max_samples`` or ``max_time``** so a search has a hard budget instead of running indefinitely.

docs/source/blogs/search-playbook.md:142

• The repository's working Wikitext configuration uses the dataset id Salesforce/wikitext (olive/cli/optimize.py:813-817), but this example sends wikitext to Hugging Face. Use the same fully qualified id so the calibration dataset resolves to the intended dataset.

            "data_name": "wikitext",

docs/source/blogs/search-playbook.md:257

• For the example winner high_precision_mlp_down_qkv, GPTQ's group_size and sym are independent, as the heuristic row above states. Omitting those sweeps means this procedure never evaluates two independent GPTQ knobs, so the 21-trial total is not a complete sweep; add those stages or explicitly state that they remain fixed.

4. Repeat the same pattern for whatever remains independent on the GPTQ side — ``damp_percent`` (3 trials), and ``lm_head`` (2 trials) if you care about it — each time locking in everything decided so far.

Total: roughly 8 + 3 + 5 + 3 + 2 = **21 trials**, run in a strict sequence, instead of 30 (still fairly cheap) or 6,300 (exhaustive) trials explored jointly. For a model where each trial takes hours, that difference is the difference between finishing in a day versus not finishing at all.

docs/source/blogs/search-playbook.md:311

• OnnxGraphSurgery is not a registered Olive pass; the pass used in Olive's options and workflow examples is GraphSurgeries. Keeping the current name sends readers to a nonexistent pass.

Everything above happens entirely on the PyTorch model — ``SelectiveMixedPrecision`` and ``Gptq`` are PyTorch-side passes, and the search finds the best PyTorch quantization recipe. Once you have that best search point, converting the winning model to ONNX Runtime is a separate, deterministic step (no search needed): run it through Olive's export passes, e.g. ``capture-onnx-graph`` (or the ``ModelBuilder``/``DynamoExporter`` passes it wraps) to produce the ONNX graph, followed by ``OnnxGraphSurgery`` or ``auto-opt`` to apply ONNX-level graph optimizations. See the [CLI how-to guides](../how-to/cli/cli-optimize.md) for the exact commands.

docs/source/blogs/search-playbook.md:212

• This line has trailing whitespace, which can fail the repository's formatting/lint checks; remove the space after the comma.

        "high_precision_mlp_down_qkv", 

• Files reviewed: 2/2 changed files
• Comments generated: 6
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.