← Alla nyheter
ARTIKEL
22 september 2026 Uppdaterad den 28 oktober 2026 3 min läsning

SoL-Pi: färre token för kodagenter, men mät den verkliga besparingen

SoL-Pi minskar tokentrafiken i författarnas benchmark. Vad som behöver mätas i kostnad, kvalitet och datahantering före användning på företagets kod.

I den här artikeln
  1. Fyra mekanismer, ett ramverk
  2. Vad riktmärket visade
  3. Vad det betyder för utvecklingsteam
  4. Varför det spelar roll: mät avslutat arbete

SoL-Pi ändrar hur kodagenter arbetar: i författarnas benchmark minskar tokentrafiken med jämförbara resultat mot referenssystemet. Den här analysen, uppdaterad den 28 oktober 2026, utgår från artikeln som publicerades den 17 september och skiljer forskningsresultaten från de kontroller som behövs före användning på ett företags kod.

Händer som skriver på ett laptoptangentbord med källkod på skärmen och en mörk mugg i bakgrunden
Foto: Free-Photos from Pixabay (CC0), Wikimedia Commons. Beskuren till 16:9.

Fyra mekanismer, ett ramverk

SoL-Pi paketerar fyra tekniker som enligt forskarna klarade tester i en växande uppsättning utvecklingsmiljöer: Action Fusion, ObservationPack, Evidence-Preserving Reducer och Online Context Compact. Tillsammans riktar de in sig på hur en agent utför åtgärder, komprimerar kontext, hanterar verktygsutdata och avgör vad den behöver läsa om, snarare än att ändra den underliggande språkmodell som står för resonerandet.

Vad riktmärket visade

I EdgeBench, en utvärdering med 51 uppgifter, rapporterar författarna att SoL-Pi matchar prestandan hos referensramverket Pi med två olika underliggande modeller, samtidigt som den registrerade tokentrafiken minskar med 44,7–49,0 procent och API-kostnaden med ungefär en tredjedel. Det är artikelns egna siffror från dess eget riktmärke – en användbar signal om vad som är möjligt, inte en garanti för samma besparingar i en annan kodbas eller verktygskedja.

Vad det betyder för utvecklingsteam

Koden är publicerad som öppen källkod på github.com/NVlabs/SoL-Pi, så team som kör kodagenter i stor skala kan testa ramverket mot sina egna kodarkiv och sin egen verktygskedja i stället för att ta artikelns riktmärkessiffror för givna. Tidigt intresse på GitHub är inte samma sak som produktionsanvändning, och en effektivitetsvinst på ramverksnivå förändrar inte vad den underliggande modellen kan eller inte kan göra – den förändrar hur billigt du kan köra den. Den som bygger vidare på detta bör mäta token- och kostnadsbesparingar i sina egna arbetsbelastningar innan man citerar artikelns siffror i ett kundförslag.

Varför det spelar roll: mät avslutat arbete

Välj uppgifter som teamet faktiskt utför för ett användbart försök: rätta en bugg, lägga till en liten funktion eller uppdatera ett beroende tillsammans med testerna. Upprepa jämförelsen med samma modell, kodarkiv, instruktioner och acceptanskriterier. Räkna även misslyckade försök, väntetid och manuella rättelser: en session som använder färre token men lämnar arbetet halvfärdigt är ingen besparing. Spara utgångsläget så att ändringar kan jämföras och återställas utan att ursprungliga underlag går förlorade.

Registrera in- och utgående token, fakturerad kostnad, tidsåtgång och uppgifter som godkänts efter granskning som separata mått. Priset beror på modellen och leverantörens villkor: mindre trafik ger inte automatiskt samma procentuella sänkning av fakturan. En MSP bör skilja mätningarna per projekt och inte kopiera en kunds innehåll till en annan kunds loggar eller försök. Jämförelsen ska kunna upprepas efter en uppdatering, med tydligt dokumenterad konfiguration och samma kriterier för att bedöma resultatet.

Hanteringen av observationer behöver en egen kontroll. Säkerställ att ett kompileringsfel, ett misslyckat test eller en säkerhetsvarning fortfarande går att hitta efter att kontexten minskats. Bestäm var arkiven sparas, vem som får läsa dem och när de ska raderas. Kontrollera datavägen och berörda inloggningsuppgifter innan en extra modell aktiveras för att sammanfatta loggar. En användbar sammanfattning måste behålla de underlag som granskaren behöver, även när de motsäger ett slutligt svar som verkar lyckat.

Börja med en isolerad kopia av kodarkivet och testdata, utan produktionsbehörigheter. Bestäm en kostnadsgräns och ett stoppvillkor och utöka först när kvalitet och genomförandetid är acceptabla. Beslutet gäller kostnaden för en slutförd och verifierad uppgift, inte en enskild räknare. Utgå från Altovars tjänster inom artificiell intelligens för att sätta utvärderingen i ett företagssammanhang, med tydliga mål, ansvar för granskning och dokumenterade kriterier innan verktygen väljs.

Källor: arXiv, GitHub.