22 次送往 DeepSeek 的請求裡，只有 6 次真的是路由器認為任務該升級；另外 16 次，只因 Nemotron 的 32K context window 裝不下。這是 Techno Tim 測試 NVIDIA Switchyard 時最關鍵的發現：如果沒有把模型選擇、容量限制與後端失敗分開，路由紀錄很容易把設定問題誤看成能力判斷。

先排除 serving 設定，才談模型能力

Tim 把 Switchyard 放在 GitHub Copilot 與兩個本機模型之間：RTX 3090 跑 Nemotron 3.5 Lightning，兩台 GX10 跑 DeepSeek V4 Flash。NVIDIA model card 列出 Nemotron 為 30B 總參數、每個 token 約 3B active parameters。

Nemotron 初測只有約 44 tok/s。Tim 回頭檢查 vLLM，發現自己開了 `--enforce-eager`，使 CUDA graphs 沒有生效；移除後速度升到約 198.5 tok/s。這次差距首先證明的不是哪個模型比較強，而是 serving 設定足以讓同一個模型看起來慢上數倍。

路由選擇和 context fallback 是兩回事

Stage routing 會參考近期工具結果與 agent 進度，逐回合決定使用 efficient model 或 capable model。Tim 設定最近三次工具結果作為判斷窗口，並關掉額外的 LLM classifier。

最初一輪共有 48 次決策：26 次由 Nemotron 回答、22 次由 DeepSeek 回答；但後者只有 6 次是 Stage 主動選擇，另外 16 次是請求超過 Nemotron 的 32K 上限。Tim 將上限調到 128K 後，圖表顯示 48 次裡有 45 次留在 Nemotron、3 次由 Stage 選 DeepSeek，context fallback 歸零；輸出速度則從 32K 的約 183 tok/s 降到 128K 的約 174 tok/s。

黑底圖表顯示 48 次決策中，45 次交給 Nemotron、3 次交給 DeepSeek；3 次由 Stage 選擇，context fallback 為 0。