feat(schema): skinny configs + techniques per measurement (MTP-ready)

[aistackdev]

Summary

• configs slims down: drops spec_method. The table now describes a deployment (model × hw × framework × precision × parallelism). Natural key shrinks 17 → 16 columns.
• Per-measurement techniques jsonb is added to benchmark_results and eval_results. It's a free-form bag for runtime knobs — first two keys are spec_method (string) and mtp_layers (number); future entries (kv_cache_dtype, chunked_prefill, prefix_cache, …) land here without further DDL.
• Gemma4 MTP regression fix falls out for free: the benchmark side encodes layer count in infmax_model_prefix (gemma4n4 / gemma4n6). Mapper now collapses those to model='gemma4' and writes techniques.mtp_layers ∈ {4,6}. The 40 rows that silently skipped on the 2026-05-25 ingest will land on the next dispatch.

Design background and reasoning are in design/database.md and design/intent-and-users.md; the same-day brainstorm in chat covered the fork-in-the-road (config dimension vs measurement metadata) — we picked measurement metadata.

Out of scope (PR2)

• UI filter chip for techniques.mtp_layers on /inference. Today the existing spec-method filter still works because every query derives spec_method server-side from techniques->>'spec_method'.
• New y-axis entries (median_acceptance_rate, median_tokens_per_step) in inference-chart-config.json. Metric keys are registered in constants; chart config wiring deferred.
• Lifting availability.spec_method denormalization (kept as a projection for date-picker ergonomics).

Migration mechanics

packages/db/migrations/006_skinny_configs.sql is a full-rewrite migration:

1. Alter configs (drop column, drop+recreate natural-key UNIQUE).
2. Add techniques jsonb default '{}' to benchmark_results and eval_results.
3. Add expression indexes on techniques->>'spec_method' and techniques->>'mtp_layers'.
4. Drop + recreate latest_benchmarks materialized view with techniques in row identity (otherwise two formerly-different configs sharing a new config_id would collide on the MV's PK).
5. Drop + recreate benchmark_results_seq_history_idx to include techniques.
6. TRUNCATE all data tables. Safe for our fork because the existing data is yesterday's failed gemma4 ingest + a handful of smoke runs; ingest is idempotent so a re-dispatch from auto-ingest restores everything cleanly. CI deploy will run the migration on master and the next auto-ingest.yml tick will repopulate.

Test plan

• pnpm typecheck clean
• pnpm test:unit — DB / mcp / constants 100%; app 1913/1914 (only pre-existing visit-tracking.test.ts timezone flake fails)
• pnpm lint && pnpm fmt clean
• On staging DB: run pnpm admin:db:migrate --yes --no-ssl, then pnpm admin:db:ingest:run https://github.com/vngcloud/InferenceX/actions/runs/26387431571 vngcloud/InferenceX --no-ssl. Verify:
  • SELECT model, count(*) FROM configs WHERE model='gemma4' GROUP BY model → one row
  • SELECT techniques, count(*) FROM benchmark_results GROUP BY techniques → buckets for {spec_method:mtp, mtp_layers:4} and {spec_method:mtp, mtp_layers:6}
  • No [SKIP] unmapped model lines in the ingest log for gemma4
• Spot-check the live dashboard after deploy: /inference shows gemma4 series; existing spec-method filter chip still works.

Follow-ups

• PR2: techniques filter chips on /inference + new chart-config metric entries
• Ship the matching artifact-side change on vngcloud/InferenceX so future runs emit techniques: {spec_method, mtp_layers} as a top-level object instead of relying on the legacy spec_decoding + prefix-encoded fallback path (which still works today)

🤖 Generated with Claude Code