npu: a pack that declares rope_type: "llama3" is served plain RoPE — 17 of 32 dim pairs run up to 32x fast

Every Llama-3.x Ryzen AI pack declares RoPE scaling and gets none of it. rope_scaling is parsed by neither the
forward nor the semantics layer, so the model is served with inv_freq = theta^(-i/half) while the checkpoint it was
quantised from used the llama3 low/high-frequency interpolation.

Measured on Llama-3.2-1B-Instruct_rai_1.8.0_npu_4K (imported container, ctr-llama), config
{rope_theta 500000, rope_scaling {rope_type llama3, factor 32, high_freq_factor 4, low_freq_factor 1, original_max_position_embeddings 8192}}. The importer carries that block into the container's config.json
verbatim, so the information reaches us and is then dropped:

• npu/forward/src/q4nx_forward.cpp — the rope table is 1.0 / pow(theta, i/half); the file reads LongRoPE
  short_factor and freq_factors and has no llama3 branch.
• npu/forward/include/q4nx_semantics.h — rope_theta, rotary_dim, rope_type_named, per_layer_rope,
  rope_theta_sliding; no scaling parameters of any kind.

Size of the defect

rope_gap.py (in the lane's evidence dir). The formula was ported and checked against transformers' own
inv_freq before it was used: max|diff| 4.2e-8 (vs 9.8e-4 if plain RoPE is used instead), so the numbers below
come from the right formula.

• 17 of 32 dim pairs are scaled, by up to 32x — i.e. those frequencies advance 32x too fast.
• max absolute angle error: 0.126 rad at position 128, 1.008 at 1024, 2.017 at 2048 (10 dim pairs over 0.1 rad
  at 2048).
• logits, same prompt, scaled vs plain RoPE on the same bf16 checkpoint:
  KL 0.0058 at ctx 104, 0.0107 at 754, 0.0252 at 1497 (corr 0.999 / 0.995 / 0.992; argmax unchanged in all three).

So it is small at short context and grows with position; it will dominate at this pack's real range (context_length
32768 in the pack's genai_config.json, max_position_embeddings 131072). It is not the cause of the single
per-prompt coin flips tracked in #1044 — those are 1.9-3.2 logit gaps at positions 5-12, where a 0.01 rad angle
error cannot act — and that is exactly why this is its own issue.

What a fix needs

1. Read rope_scaling (or rope_parameters) at load, i.e. in npu/pack_import.cpp / npu/model.cpp / the forward's
   config path, into the semantics struct.

2. Build the table with the three-branch rule (transformations' _compute_llama3_parameters):
   wavelen = 2*pi/inv_freq; original_max/low_freq_factor and original_max/high_freq_factor bound the band;
   outside it divide by factor, inside it interpolate by smooth = (original_max/wavelen - low)/(high - low).

   out = where(wavelen > orig_max/low, inv/factor, inv)
   smooth = (orig_max/wavelen - low)/(high - low)
   out = where((wavelen >= orig_max/high) & (wavelen <= orig_max/low),
               (1 - smooth)*out/factor + smooth*out, out)

3. A test that fails on the old table: the llama3 inv_freq for (d=64, theta=500000, factor 32, high 4, low 1,
   orig_max 8192) is fixed data — 17 of 32 entries differ from plain, the ratios are integers up to 32, and the
   three entries inside the band must be interpolated, not switched.

4. Prove it on the container rather than on the table: a long-context prompt (ctx ~1500) through
   1bit forward-serve --dump-logits against this checkpoint's reference logits, before and after. The before value
   is KL 0.0252 at 1497 above.

Related

• npu: the Llama-3.2-1B pack imports whole and then drifts immediately — its first EOS is served as text #1044 — the Llama third-family import/forward issue this was found under (import verified correct; the flips there
  are per-position coin flips on identical context).
• Other packs affected by the same gap: any rope_type other than default that is not LongRoPE — Llama-3.1/3.2/3.3
  (llama3), and proportional partial-rotary (only recorded as rope_type_named today).