Strategi penghalaan model untuk ejen pengekodan

Kesan penghalaan berbilang model terhadap ejen pengekodan

Penghalaan berbilang model menghantar setiap permintaan kepada model paling murah yang mampu mengendalikannya. Bagi trafik sembang, kaedah ini berfungsi dengan baik. Bagi ejen pengekodan, kosnya biasanya lebih tinggi daripada penjimatan yang diperoleh kerana bil ejen didominasi oleh awalan prompt yang dicache bagi setiap model, dan penukaran model akan memadamkan cache tersebut.

Peraturan yang dihujahkan dalam catatan ini: lakukan penghalaan merentas penyedia untuk ketersediaan, lakukan penghalaan merentas peringkat untuk kos hanya pada sempadan tugasan, dan tetapkan satu model bagi setiap sesi untuk sebarang aktiviti ejen. Segala penjelasan di bawah merupakan alasan bagi peraturan tersebut.

Empat istilah, ditakrifkan sekali. Router memilih model bagi setiap permintaan. Gateway ialah proksi yang dilalui oleh permintaan, yang mungkin atau mungkin tidak melakukan penghalaan. Prompt cache ialah penyedia yang menyimpan awalan prompt anda yang telah diproses, supaya permintaan seterusnya yang mengulangi awalan tersebut dibilkan pada sebahagian kecil daripada harga input. KV cache (key value cache) ialah konsep yang sama di dalam pelayan yang anda jalankan sendiri.

Mengapa trafik sembang dihalakan dengan baik manakala trafik ejen tidak

Permintaan sembang adalah satu pusingan. Ia tiba, dikelaskan, dihantar ke model, dan dikembalikan. Tiada apa-apa yang dibawa ke pusingan seterusnya. Penghala (router) boleh menghantar soalan ini ke model kecil dan soalan seterusnya ke model besar, dan kedua-dua permintaan tidak mengetahui kewujudan satu sama lain. Ini adalah beban kerja yang diukur oleh hampir setiap penanda aras penghalaan, dan penghala yang baik memang cekap melakukannya.

Pusingan ejen bukanlah satu permintaan tunggal. Satu arahan seperti "fix the failing test" menjadi dua puluh hingga enam puluh panggilan API. Setiap panggilan menghantar semula keseluruhan perbualan: system prompt, setiap definisi tool, setiap fail yang telah dibaca oleh ejen, dan setiap output command yang telah dilihatnya. Konteksnya hanya terus berkembang. Menjelang panggilan ketiga puluh, awalan (prefix) yang berulang boleh mencecah puluhan ribu token, sedangkan kandungan yang benar-benar baharu dalam setiap panggilan hanyalah beberapa ratus token.

Bentuk ini mengubah maksud perkataan "mahal". Dalam sembang, kos secara kasarnya adalah harga model didarab dengan permintaan. Dalam gelung ejen, kosnya adalah awalan yang dibilkan semula pada setiap panggilan. Selebihnya catatan ini adalah berdasarkan fakta tersebut.

Cache prompt adalah mengikut model, dan ejen berada di dalamnya

Anthropic menetapkan harga bacaan cache pada 0.1 kali ganda harga input asas, dan penulisan cache lima minit pada 1.25 kali ganda. Ini adalah harga senarai yang diterbitkan, setakat Ogos 2026.

[
  {
    "label": "Opus 5",
    "uncached_input_usd": "5.00",
    "cache_read_usd": "0.50"
  },
  {
    "label": "Sonnet 5",
    "uncached_input_usd": "2.00",
    "cache_read_usd": "0.20"
  },
  {
    "label": "Haiku 4.5",
    "uncached_input_usd": "1.00",
    "cache_read_usd": "0.10"
  }
]

Baca siri kedua berbanding yang pertama, merentas baris dan bukannya ke bawah. Bacaan cache pada Opus 5 adalah 0.50 dolar bagi setiap juta token. Input tanpa cache pada Haiku 4.5, model termurah yang disenaraikan, adalah 1.00 dolar. Jadi, membaca semula awalan (prefix) yang sedia ada pada model paling mahal menelan kos yang lebih rendah bagi setiap token input berbanding membaca awalan yang sama secara sejuk pada model termurah.

Perbandingan tunggal itu membatalkan kebanyakan pelan penghalaan (routing). Penghala yang memindahkan kerja "ke bawah" satu peringkat sedang membandingkan harga senarai. Tetapi ejen di pertengahan sesi tidak membayar harga senarai pada model yang sedang digunakannya. Ia membayar harga bacaan cache, yang sudah pun berada di bawah kadar tanpa cache model murah.

Cache dikunci pada hash awalan prompt, dan ia adalah mengikut model. Permintaan kepada model yang berbeza akan melakukan hash terhadap stor yang tidak pernah melihatnya, jadi ia tidak menemui apa-apa dan membayar harga penuh. Cache juga merupakan satu hierarki: alatan dahulu, kemudian sistem, seterusnya mesej. Perubahan pada mana-mana tahap akan membatalkan tahap tersebut dan segala-galanya selepasnya, yang bermaksud menyunting satu definisi alatan akan membuang cache prompt sistem yang berada di belakangnya. Ejen yang mendaftarkan alatan semasa runtime akan mengalami perkara ini tanpa perlu menyentuh penghala sama sekali.

Kos sebenar pertukaran di pertengahan sesi

Bayangkan satu sesi dengan awalan (prefix) stabil sebanyak 40,000 token, saiz biasa setelah ejen membaca beberapa fail. Di bawah ialah kos awalan bagi satu pusingan (turn), dikira berdasarkan harga senarai di atas.

[
  {
    "label": "Opus 5, cache warm",
    "prefix_cost_usd": "0.020"
  },
  {
    "label": "Sonnet 5, turn after switch",
    "prefix_cost_usd": "0.100"
  },
  {
    "label": "Opus 5, cache re-warmed",
    "prefix_cost_usd": "0.250"
  }
]

Kekal menggunakan Opus 5 dengan cache yang sedia ada (warm cache) menelan kos 0.020 dolar untuk awalan pusingan tersebut. Pusingan pertama selepas beralih (routing) ke Sonnet 5 menelan kos 0.100 dolar, kerana Sonnet tidak mempunyai entri untuk awalan ini dan perlu menulis entri baharu. Kembali semula ke Opus 5 menelan kos 0.250 dolar, kerana entri asal telah tamat tempoh semasa sesi berada di tempat lain.

Oleh itu, perjalanan pergi balik membayar dua kos penulisan cache untuk mengelakkan dua kos bacaan cache. Sebagai ganti, pertukaran tersebut memberikan satu pusingan output pada harga output Sonnet dan bukannya harga Opus. Blok perincian di bawah mengira keseluruhan perjalanan: penjimatan yang diperoleh hanyalah dalam pecahan sen, manakala penalti cache mencecah puluhan sen. Penalti tersebut adalah lebih besar sebanyak lebih satu magnitud, dan ia meningkat mengikut panjang awalan manakala penjimatan tidak berbuat demikian.

Opus 5, warm read     40,000 x $0.50 / 1e6  = $0.020
Sonnet 5, cache write 40,000 x $2.50 / 1e6  = $0.100   (1.25 x $2 base)
Opus 5, cache write   40,000 x $6.25 / 1e6  = $0.250   (1.25 x $5 base)

800 x ($25 - $10) / 1e6 = $0.012

Format panggilan alat tidak sama merentas penyedia

Ejen ialah gelung panggilan alat, jadi format panggilan alat adalah penting dengan cara yang tidak pernah berlaku untuk sembang. Messages API Anthropic mengembalikan blok kandungan tool_use dan menjangkakan blok tool_result sebagai balasan. API yang serasi dengan OpenAI mengembalikan tatasusunan tool_calls yang mana function.arguments merupakan rentetan berkod JSON dan bukannya objek bersarang. Gerbang menterjemah antara kedua-duanya, dan untuk panggilan biasa, terjemahannya adalah bersih.

Masalah muncul pada bahagian pinggir. Panggilan alat selari, di mana model mengeluarkan beberapa panggilan dalam satu respons, diwakili secara berbeza dan tidak disokong secara sama rata di mana-mana. Penguatkuasaan skema yang ketat ialah ciri khusus penyedia, jadi model yang menjamin argumen yang sah mengikut skema pada satu titik akhir hanya cenderung ke arah argumen yang sah pada titik akhir yang lain. Ejen melihat perbezaan tersebut sebagai hasil alat yang mengandungi ralat penghuraian, yang kemudiannya cuba dibaiki dengan menggunakan satu lagi pusingan. Pusingan pembaikan tersebut dibilkan pada harga awalan penuh, jadi ketidakpadanan format akan kelihatan pada invois serta dalam transkrip.

Titik akhir yang dihoskan sendiri memerlukan perkara ini dikonfigurasikan secara eksplisit. Pelayan yang serasi dengan OpenAI daripada vLLM memerlukan --enable-auto-tool-choice bersama-sama dengan --tool-call-parser yang dipadankan dengan keluarga model (hermes, mistral, llama3_json dan lain-lain), serta templat sembang yang mengendalikan mesej peranan alat. Dokumentasi vLLM menyatakan secara terus tentang had laluan ini: dengan tool_choice="auto" dan tanpa kekangan skema yang ketat, vLLM mengekstrak panggilan alat daripada teks mentah, jadi argumen mungkin sekali-sekala menjadi cacat atau melanggar skema parameter fungsi. Memilih penghurai yang salah untuk model anda ialah ralat konfigurasi yang muncul sebagai ejen yang tidak dapat memanggil alat, yang perlu diketahui sebelum anda menghalakan trafik kepadanya. Perbezaan antara Ollama dan vLLM untuk menghidangkan model sendiri adalah penting di sini, kerana kedua-duanya mendedahkan panggilan alat pada terma yang berbeza.

Fallback tugasan pertengahan mengubah kelakuan tanpa ralat

Penghalaan fallback (fallback routing) ialah ciri yang paling kerap diaktifkan secara tidak sengaja. Gateway dikonfigurasikan untuk mencuba semula pada model lain apabila model pertama mengembalikan had kadar (rate limit) atau ralat 5xx, kemudian meletakkan model yang gagal itu dalam tempoh bertenang (cooldown) selama beberapa saat. Bagi trafik sembang, ini adalah tindakan yang tepat. Namun, dalam tugasan ejen yang panjang, ini bermakna separuh kedua tugasan anda dijalankan pada model yang tidak anda pilih.

Tiada apa-apa yang melaporkan perkara ini. Tugasan tidak gagal, ejen tidak memberi amaran, dan status keluar (exit status) adalah berjaya. Apa yang anda perolehi ialah tugasan di mana pelan ditulis oleh satu model dan suntingan dibuat oleh model lain, dengan nada dan tabiat yang berubah di pertengahan jalan. Satu-satunya isyarat yang boleh dipercayai ialah medan model dalam log permintaan gateway atau metadata respons. Oleh itu, jika anda menggunakan fallback, log medan tersebut bagi setiap permintaan dan semak ia apabila hasil yang diperoleh mengejutkan anda. Menyahpepijat kelakuan tanpa mengetahui model mana yang menghasilkannya membuang lebih banyak masa berbanding penjimatan yang diberikan oleh fallback.

Perangkap yang sama juga berlaku pada pemampatan konteks (context compression). Banyak ejen meringkaskan sejarah yang panjang dengan memanggil model kecil. Jika panggilan itu membawa model yang berbeza atau prompt sistem yang berbeza, ia akan menulis entri cache sendiri dan tidak menyegarkan cache sesi utama. Akibatnya, pusingan penuh seterusnya akan mengalami kelewatan kerana cache tidak digunakan (cold prefix). Pemampatan tersebut menjimatkan token tetapi menyebabkan kehilangan cache.

Overhed penghalaan memang wujud, tetapi latensi bukanlah punca masalah utama

Penghala (router) memang menambah beban kerja bagi setiap permintaan, dan adalah penting untuk kita tepat mengenai jumlah beban tersebut. DigitalOcean melaporkan bahawa model Arch-Router mereka menyelesaikan niat penghalaan dalam kira-kira 51 milisaat, dengan ketepatan penghalaan sebanyak 93.17% berdasarkan penilaian mereka sendiri. Itu adalah angka mereka, daripada pengukuran dan penanda aras mereka, bukan angka kami dan bukan hasil yang universal. Ambil angka tersebut pada nilai muka dan kesimpulannya melegakan: 51 milisaat merentasi empat puluh panggilan ejen adalah kira-kira dua saat yang ditambah kepada tugas yang berjalan selama beberapa minit.

Dua saat bukanlah perkara yang menjadikan penghalaan mahal di sini. Overhed yang benar-benar membebankan ialah penghala yang mengelaskan dengan panggilan model penuh, kerana itu merupakan inferens kedua pada setiap permintaan, yang dibilkan dan diletakkan dalam baris gilir seperti mana-mana permintaan lain. Di bawah kedua-duanya terletak aritmetik cache di atas, yang sebenarnya bukanlah overhed. Ia adalah kos bagi perkara yang sepatutnya dioptimumkan oleh penghalaan.

Pada pelayan yang anda kendalikan sendiri, peraturan yang sama terpakai dengan ruang pergerakan yang lebih kecil. Setara tempatan bagi cache prompt ialah caching awalan dalam KV cache, yang berada dalam memori GPU. Mengehoskan dua model pada satu GPU membahagikan memori tersebut antara keduanya, jadi setiap satu menyimpan KV cache yang lebih kecil dan menyingkirkan awalan dengan lebih cepat. Oleh itu, penghalaan antara dua model tempatan boleh mengurangkan kadar hit cache bagi kedua-duanya serentak. Jika anda sedang menentukan saiz perkakasan untuk tujuan ini, memori dan CPU yang sebenarnya diperlukan oleh ejen pengekodan pada VPS adalah titik permulaan yang lebih berguna berbanding penghala.

Peraturan keputusan

• Halakan trafik merentasi penyedia untuk ketersediaan. Apabila alternatifnya ialah permintaan yang gagal, sebarang kos adalah kos yang berbaloi. Tetapkan fallback kepada model dengan format panggilan alat (tool call) yang sama supaya gelung ejen terus berfungsi, dan catatkan model mana yang melayani setiap panggilan.
• Halakan merentasi tier untuk kos hanya pada sempadan tugasan. Memilih Haiku untuk penamaan semula dan Opus untuk refactor adalah keputusan yang baik jika dibuat sekali, sebelum sesi bermula. Ia menjadi keputusan yang buruk jika dibuat pada giliran ke-30 sesi tersebut.
• Tetapkan satu model bagi setiap sesi untuk sebarang tugasan ejen. Nilai sesuatu sesi terletak pada cache panasnya. Anggap penukaran model seperti tindakan mengosongkan cache tersebut, kerana itulah kesan sebenarnya.
• Halakan subejen secara bebas. Subejen yang bermula dengan konteks baharu yang kecil tidak mempunyai cache panas untuk hilang, jadi ia boleh dijalankan pada mana-mana model yang sesuai dengan tugasnya. Ini adalah satu-satunya tempat di dalam ejen di mana penghalaan hampir tidak menelan kos.

Untuk cara membina sistem ini, gateway melakukan kerja tersebut: alias model dan senarai fallback eksplisit. Konfigurasi proksi LiteLLM yang minimum kelihatan seperti ini.

model_list:
  - model_name: agent-primary
    litellm_params:
      model: anthropic/claude-opus-5
      api_key: os.environ/ANTHROPIC_API_KEY
  - model_name: agent-standby
    litellm_params:
      model: anthropic/claude-sonnet-5
      api_key: os.environ/ANTHROPIC_API_KEY

router_settings:
  fallbacks: [{"agent-primary": ["agent-standby"]}]
  num_retries: 2
  cooldown_time: 30

Halakan ejen ke agent-primary dan ia akan kekal pada satu model sehingga model tersebut tidak dapat dicapai. Kedua-dua entri berada pada penyedia yang sama, jadi format panggilan alat tidak berubah apabila fallback diaktifkan. Anda masih menerima perubahan tier pada saat itu, yang merupakan pertukaran berbaloi hanya kerana alternatifnya ialah permintaan yang gagal. Itu adalah penghalaan ketersediaan tanpa penghalaan kos, iaitu kombinasi yang diingini oleh kebanyakan ejen pengekodan. Binaan penuh, termasuk kunci dan bajet, diliputi dalam menjalankan gateway LiteLLM yang dihoskan sendiri pada VPS anda, dan hantaran ini sengaja tidak mengulanginya.

Apabila satu model yang dipilih dengan teliti mengatasi mana-mana router

Routing merupakan penyelesaian kepada varians dalam kesukaran permintaan. Ejen pengekodan mempunyai varians yang kurang daripada yang disangka, kerana bahagian yang mahal bagi setiap panggilan adalah awalan (prefix) yang sama, tidak kira apa yang diminta oleh panggilan tersebut. Apabila awalan mendominasi, perbezaan antara tier murah dan tier mahal anda mengecil ke arah perbezaan harga output, dan output hanyalah sebahagian kecil daripada token ejen.

Oleh itu, pilihan lalai yang jujur adalah satu model, dipilih sekali, dengan caching diaktifkan dan TTL (time to live) yang cukup panjang untuk menampung jurang masa apabila anda berhenti untuk membaca diff. Anthropic menawarkan penulisan cache selama satu jam pada 2 kali ganda input asas, yang akan memberikan pulangan modal selepas dua kali bacaan, dan ini sering kali menjadi tuil (lever) yang lebih baik daripada mana-mana router. Pilih tier secara sengaja menggunakan perbandingan terus antara Opus, Sonnet dan Haiku, dan jika bil masih menjadi masalah, kurangkannya dengan bajet dan konteks yang lebih kecil seperti dalam mengawal kos ejen AI pada VPS dan bukannya dengan penukaran model di tengah sesi.

Lakukan routing apabila permintaan adalah bebas dan pendek, atau apabila sub-ejen bermula dengan konteks baharu. Lakukan pinning apabila anda mempunyai satu sesi panjang yang melakukan satu tugasan. Kebanyakan kerja ejen pengekodan adalah jenis yang kedua, itulah sebabnya router yang menjimatkan wang pada produk sembang anda akan secara senyap-senyap merugikan anda di sini. Jika anda belum menetapkan ejen itu sendiri, perbandingan Claude Code dengan Cursor, Codex dan Copilot merangkumi cara setiap satunya mengendalikan pemilihan model, dan sesetengah daripadanya membuat keputusan ini untuk anda.

FAQ

Adakah menukar model di pertengahan sesi benar-benar menghilangkan cache prompt?

Ya. Cache prompt dikunci berdasarkan hash awalan prompt dan disimpan mengikut model, jadi permintaan yang dihantar kepada model berbeza akan membuat semakan hash terhadap storan yang tidak pernah melihat awalan tersebut. Ia tidak menemui apa-apa dan perlu membayar harga input penuh tanpa cache, kemudian membayar kos penulisan cache jika caching diaktifkan. Menukar kembali kepada model asal juga tidak memulihkan entri tersebut, kerana tempoh hayat lalai selama lima minit biasanya sudah tamat pada ketika itu. Semak medan cache_read_input_tokens dan cache_creation_input_tokens dalam objek penggunaan respons: giliran yang membaca sifar token cache pada sesi yang panjang adalah petanda perkara ini berlaku.

Adakah penghalaan ke model yang lebih murah sentiasa menjimatkan kos bagi ejen?

Hanya apabila tiada cache panas yang akan hilang. Bacaan cache pada Anthropic berharga 0.1 kali ganda input asas, yang menjadikan bacaan panas pada Opus 5 lebih rendah daripada kadar input tanpa cache pada Haiku 4.5. Apabila sesuatu sesi mempunyai awalan cache yang besar, model sedia ada sebenarnya sudah menjadi pilihan yang murah dari segi input. Penghalaan memberikan penjimatan apabila konteks masih baharu dan kecil: pada permulaan tugasan, atau dalam sub-ejen yang hanya membawa konteks yang diperlukan.

Mengapa ejen saya berkelakuan berbeza di pertengahan tugasan?

Semak sama ada mekanisme fallback gateway telah diaktifkan. Had kadar atau ralat 5xx pada model utama menyebabkan gateway mencuba semula pada model sandaran dan meletakkan model utama dalam tempoh cooldown selama beberapa saat, jadi baki tugasan dijalankan di tempat lain. Ini tidak menghasilkan ralat atau amaran, dan tugasan masih melaporkan kejayaan. Medan model dalam log permintaan gateway atau metadata respons adalah satu-satunya rekod yang boleh dipercayai, jadi log perkara ini bagi setiap permintaan jika anda menggunakan fallback.

Adakah panggilan alat (tool calls) berfungsi sama merentas setiap penyedia?

Tidak tepat. Messages API daripada Anthropic menggunakan blok kandungan tool_use dan tool_result, manakala API yang serasi dengan OpenAI menggunakan tatasusunan tool_calls yang mana function.arguments adalah rentetan berkod JSON. Gateway menterjemahkan kes-kes biasa dengan baik, tetapi panggilan alat selari dan penguatkuasaan skema yang ketat berbeza mengikut penyedia. Pada vLLM yang dihoskan sendiri, anda mesti menetapkan --enable-auto-tool-choice dan --tool-call-parser yang sepadan dengan keluarga model anda, dan dokumentasi vLLM menyatakan bahawa tanpa kekangan skema yang ketat, pelayan akan mengekstrak panggilan alat daripada teks mentah, jadi argumen mungkin kadangkala menjadi tidak sempurna (malformed).

Berapa lamakah saya perlu menetapkan TTL cache untuk sesi pengekodan?

Gunakan tempoh hayat lalai selama lima minit untuk kerja berterusan, dan pilihan satu jam apabila manusia membaca diff antara giliran. Anthropic meletakkan harga penulisan lima minit pada 1.25 kali ganda input asas dan penulisan satu jam pada 2 kali ganda, berbanding bacaan pada 0.1 kali ganda. Kos penulisan lima minit dibayar balik dengan satu bacaan, dan penulisan satu jam dengan dua bacaan, jadi bagi mana-mana sesi yang anda jangka akan kembali dan menyambung kerja, tempoh hayat yang lebih lama biasanya menelan kos yang lebih rendah berbanding membayar untuk awalan sejuk (cold prefix).