Modellruttning: Sluta använda en modell för allt

Att köra en modell med 70 miljarder parametrar för att sammanfatta ett 200-ord långt e-postmeddelande är slöseri. Att köra en 3-miljarders modell för att granskas produktionskod är slarvigt. De flesta system hamnar någonstans emellan — och det är här modellruttning kommer in i bilden.

Den matchar uppgiftens komplexitet med modellens kapacitet. Kompromisserna är verkliga, men besparingarna är det också.

Ruttproblemet

De flesta börjar med en modell och håller fast vid den. Det fungerar tills du märker kostnaden, eller latensen, eller båda. Alternativet är att bygga en router — något som bestämmer vilken modell som hanterar vilken begäran.

Fyra strategier fungerar i praktiken:

1. Kapacitetsbaserad — rutt baserat på vad modellen kan göra
2. Kostnadsmedveten — rutt baserat på vad du är villig att betala
3. Latensmedveten — rutt baserat på hur snabbt du behöver det
4. Hybrid — kombinera dem

Var och en optimerar något annat. Att välja en är oftast ett beslut om vad som gör mest ont.

Kapacitetsbaserad ruttning

Det enklaste tillvägagångssättet. Klassificera uppgiften, skicka den till modellen som hanterar den.

Om uppgiften inte behöver den större modellen, använd den inte. En 1,5B-modell hanterar sentimentklassificering bra. Den skriver inte en sammanhängande essay.

Implementeringen är rak:

ROUTING_RULES = {
    "classify": {"model": "qwen3-1.7B", "max_tokens": 100},
    "summarize": {"model": "qwen3-8B", "max_tokens": 500},
    "code_review": {"model": "qwen2.5-coder-7b", "max_tokens": 2000},
    "reason": {"model": "qwen3-32b", "max_tokens": 4000},
    "creative": {"model": "claude-sonnet-4", "max_tokens": 8000},
}

def route_request(task_type: str) -> dict:
    return ROUTING_RULES.get(task_type, ROUTING_RULES["reason"])

Fällan är klassificeringen i sig. Om du får fel uppgiftstyp, ruttar du till fel modell. Jag har sett system klassificera kodgranskning som “sammanfattning” och förlora kvalitet tyst.

Kostnadsmedveten ruttning

Lokal inferens lyser här. Lokala modeller är effektivt gratis efter att hårdvaran amorterats. En RTX 5080 betalar för sig själv på cirka sex månader vid måttlig API-användning.

Om du bearbetar tusentals begäran per session, slår även $0,05 i elkostnad $15/M tokens.

Budgetbaserad ruttning faller tillbaka när du spenderar:

class CostAwareRouter:
    def __init__(self, budget_per_session: float = 0.10):
        self.budget = budget_per_session
        self.spent = 0.0
        self.models = {
            "cheap": {"model": "qwen3-8B", "cost": 0.0},
            "medium": {"model": "qwen3-32b", "cost": 0.0},
            "expensive": {"model": "claude-sonnet-4", "cost": 0.000015},
        }

    def route(self, task: str) -> str:
        ratio = self.spent / self.budget
        if ratio < 0.5:
            return self.models["expensive"]["model"]
        elif ratio < 0.8:
            return self.models["medium"]["model"]
        return self.models["cheap"]["model"]

Kvaliteten försämras när du faller tillbaka. Du börjar med Claude, går över till Qwen3-32B, sedan till Qwen3-8B. Mot slutet av en lång session är utdata märkbart sämre. Om det spelar roll beror på vad du bygger.

Latensmedveten ruttning

Interaktiva verktyg behöver snabba första tokens. Batchjobb kan vänta. Skillnaden är oftast en faktor fem i modellstorlek.

När du streamar tokens till en användare är det latensen för den första token som de känner. En 32B-modell som tar halva sekunden för att starta känns seg jämfört med en 1,5B-modell som avfyrar direkt.

class LatencyAwareRouter:
    def __init__(self):
        self.model_latencies = {
            "qwen3-1.7b": {"first_token": 0.05, "complete": 0.5},
            "qwen3-8B": {"first_token": 0.15, "complete": 2.0},
            "qwen3-32b": {"first_token": 0.5, "complete": 10.0},
            "claude-sonnet-4": {"first_token": 0.3, "complete": 5.0},
        }

    def route(self, target_latency: float) -> str:
        for model, latencies in sorted(
            self.model_latencies.items(),
            key=lambda x: x[1]["complete"]
        ):
            if latencies["complete"] <= target_latency:
                return model
        return "qwen3-1.7b"

Latenssiffrorna är ungefärliga — de beror på din hårdvara, kvantisering och batchstorlek. Mät på din egen miljö.

Återhämtningsstrategier

Modeller misslyckas. APIs sätter hastighetsbegränsningar. Timeout händer. Mönstret som fungerar är en återhämtningskedja, sorterad från bäst till mest pålitlig:

class FallbackRouter:
    def __init__(self):
        self.fallback_chain = [
            {"model": "claude-sonnet-4", "timeout": 30},
            {"model": "qwen2.5-72b", "timeout": 60},
            {"model": "qwen3-32b", "timeout": 120},
            {"model": "qwen3-8b", "timeout": 300},
        ]

    def route_with_fallback(self, prompt: str) -> str:
        for config in self.fallback_chain:
            try:
                return self.call_model(
                    config["model"], prompt,
                    timeout=config["timeout"]
                )
            except (TimeoutError, APIError) as e:
                log.warning(f"Model {config['model']} failed: {e}")
                continue
        raise RuntimeError("All fallback models failed")

Den sista modellen i kedjan bör vara lokal. Den är långsammare, men den kommer inte att misslyckas på grund av ett nätverksproblem eller en API-nyckel.

När ruttning hjälper

Ruttning är meningsfull när din arbetsbelastning är blandad. Om du gör klassificering, sammanfattning och resonemang i samma system, sparar en router pengar och latens.

Det är inte meningsfullt när allt du gör har samma komplexitet. Använd bara modellen som är bra på den uppgiften. Routern lägger till komplexitet du inte behöver.

Tidig prototypering är en annan anledning att hoppa över det. Få uppgiften att fungera med en modell, och lägg till ruttning när kostnad eller latens faktiskt blir ett problem.

Kompromisser

Varje ruttstrategi optimerar något och offrar något annat:

• Enkel modell — enklast, dyrast, konsekvent kvalitet
• Kapacitetsbaserad — bättre kostnad, högre kvalitet per uppgift, måttlig komplexitet
• Kostnadsmedveten — billigast, varierande kvalitet, måttlig komplexitet
• Latensmedveten — snabbast, kan offra kvalitet, måttlig komplexitet
• Hybrid — bäst av allt, mest komplex att implementera

Produktionssystem konvergerar oftast mot hybrid. Börja med kapacitetsbaserad ruttning, lägg till kostnadsmedvetenhet när räkningen kommer, lägg till latensmedvetenhet när användare klagar över långsamhet.

Relaterat

• Kostnadsoptimering för LLM-system — tokenbudgetering, cachning, återhämtningsmodeller
• LLM-värdar i praktiken — indatavalidering, utdatafiltrering, säkerhet
• Design av multimodellsystem — arkitektur för flera modeller
• LLM-arkitektur — systemdesignpelare: ruttning, kostnad, värdar och orkestrering