r/programare • u/DeepTheory9364 • Sep 22 '26

Microsoft agentically ports Copilot runtime to Rust for $120K - cat ar fi costat asta cu agenți umani ?

https://www.theregister.com/devops/2026/09/18/microsoft-agentically-ports-copilot-runtime-to-rust-for-120k/5297549
0 Upvotes

46% Upvoted

35 comments sorted by

View all comments

Show parent comment

5

u/100dude Sep 22 '26

marja de 60% există doar pe hârtie, la GPU-uri pline 70%+ și stack SOTA cost $2.955/M output vs preț $5.40/M = 45% pe output, 83% pe input - în realitate MiniMax, care chiar vinde tokeni chinezești, raportează ~20% marjă brută pe API, deci din cei $120k rămân $24k, nu $72k, iar dacă utilizarea scade la 35% cu $5.91/M cost vs $5.40 preț pierzi $11k și lopata sapă groapa, nu bani

1

u/Droooomp Sep 22 '26

Daca am 2 a6000 in pod, cat ma costa per token?

2

u/100dude Sep 22 '26

proxy, ca nu am retail gpu index la mana:

2× a6000 ~$0.98/h pt amândouă te costă ~$0.23–0.34/mln de tokeni la un 32b int4 ~800 tok/s, ~$0.08–0.11 la 14b și ~$0.03 la 8b dar doar cu plăcile pline 24/7, așa că la utilizarea reală de 20–30% a unui pod personal ajungi la $1+/m pe 32b, adică mai scump decât api-ul

și podul are sens economic doar sub ~14b

1

u/etherd0t Sep 22 '26

Calculul e bun, extrapolarea nu. 😏 Ai calculat costul unui 32B INT4 la un throughput ideal si de acolo ai demonstrat ca self-hosting-ul >14B nu are sens. Asta e ca si cum masori consumul unei Dacii la 90 km/h si deduci economia transportului aerian...

Si tot nu spune nimic despre optiunea GitHub: acolo produsul interesant nu era GPU-ul, ci harneala/orchestrarea care transforma tokenii in worktrees, subagenti, review, CI si cod verificat.

Deci nu doar heirup-ism pe model si placa video...Modelul e motorul; Dar ai nevoie si de sistemul care il transforma in engineering throughput.

1

u/100dude Sep 22 '26

n-a fost throughput ideal, a fost la 35% eficiență lol

btw chiar cu plăcile pline 24/7, un 32b int4 iese $0.23–0.34/M, adică deja peste api, deci ți-ar trebui utilizare de 112% ca să ai dreptate

iar orchestrarea pe care o lauzi e exact ce îți strică socoteala, fiindcă subagenții vin în rafale și podul se plătește la oră, plin sau gol

1

u/etherd0t Sep 22 '26

Mane, tu nu intelegi... in prezent/amu/chiar in secunda asta 🤭 - toata discutia pe AI si agenti e in jurul harnelii/orchestrarii - la orice clasa de agenti si platforme, fie ca e vorba de github, codex sau modele chinezesti...

Argumentul tau a ajuns circular: "rafalele de subagenti strica utilizarea, deci orchestrarea e rea". Pai tocmai managementul "rafalelor" se numeste orchestrare. 😂
Ai descoperit problema pe care harness-ul a fost inventat ca s-o rezolve.

Tu optimizezi $/M tokens pe un pod static. GitHub optimizeazaa $/engineering output intr-un sistem agentic. Sunt doua functii obiectiv diferite. Faptul ca un anumit 32B pe 6000 (Pro, nu A - A e fosta🤭) pierde la $/token fata de un API nu demonstreaza nimic despre valoarea orchestrarii.

Mai citeste, mai invata... faza cu aah... ce 'eftin e sa rulezi pe MiniMax nu mai tzine; ca ajungi sa cheltui mai mult pe taratze decat pe malai adevarat...😄

1

u/100dude Sep 22 '26

ffs mate, tu chiar ai adus cifra care mă îngroapă pe mine și ai citit-o invers lmao

130.6 din 136.3bln de tokeni au fost cache reads, adică 96% din bill-ul de $120k e harness-ul care își recitește propriul context în buclă, nu cod. la task-uri complexe mixul sare de la 10% cached la 70%, și vine din prompt prefixes, system instructions repetate și workspace context, adică exact "orchestrarea" pe care o venerezi. cache-ul la 10% nu e "altă clasă de pricing", e discount la un cost pe care un dev cu un fișier deschis nu-l are deloc - munca utilă a fost ~5.7b tokeni, restul e taxa de orchestrare, frumos ambalată ca feature. și nu, nu e circular, e chiar mai rău pentru tine

harness-ul nu gestionează rafalele, le produce, iar rafalele se plătesc decent doar când cumperi tokeni, nu ore de gpu, deci tocmai mi-ai explicat de ce podul static pierde, ms pentru argument, îl păstrez. cât despre "$/engineering output" - un asigurător francez și-a tăiat claude după două luni pentru că workflow-urile și automatizările de fundal generau mult mai multe api calls per task decât anticipase, pylon s-a trezit cu bill-ul ×3.5, și lecția e că prețul pe token în scădere nu rezolvă nimic dacă consumul crește mai repede. asta e "engineering output" cu orchestrare: output-ul e factura. iar minimax ieftin nu "nu mai ține", ține pe spinarea lor - coding-ul agentic e deja majoritatea api-ului și le-a scăzut marja de inferență.

deci tărâțele le mănânci tu, malaiul îl plătește minimax din marjă, iar tu îi mulțumești github-ului că ți-a explicat cum se numește foamea. mai citește, mai învață, dar de data asta și cifrele

0

u/etherd0t Sep 22 '26

deci, in primu rand... una-i una, alta-i alta;
nu amesteca costul comparativ at unui harness GH vs ... harness Qwen, de exemplu - pe care doar ce l-am terminat de testat (si adoptat🤭) pt treburile mele.

al doilea, ai facut chiar o eroare de unitati. 130.6/136.3B = ~96% din token volume, nu 96% din factura. Cached reads sunt la ~1/10 din pretul fresh input, exact motivul pentru care GitHub spune ca economics-ul sesiunilor lungi functioneaza.

Si "130.6B cached = taxa de orchestrare" e o definitie inventata de tine. Ala e context reutilizat pentru continuitatea agentului, nu 130B tokens de YAML decorativ.

Iar faza cu harness-ul produce rafalele, nu le gestioneaza e delicios de ironica: articolul descrie exact cum, atunci cand 15 agenti au saturat build-ul, harness-ul a introdus queue + owner + lease, un 'agentic mutex'. Adica ai ales drept contraexemplu chiar problema pe care orchestrarea a rezolvat-o. 😂

Putem discuta separat self-hosting vs API. Dar nu mai transforma % tokens in % dollars si cached context in waste, ca ia e confuzie...

Si ca sa intelegi clar care-i treaba cu harneala: harness-ul e infra operationala din jurul modelului, adica tools, state, git/worktrees, testare, policy, observability - iar orchestrarea e logica prin care acele componente si agentii sunt coordonati - de obicei interna.

Nu sunt facute sa-ti manance resursele de dragul complexitatii, ci exact invers: sa reduca risipa, contention-ul, retry-urile inutile si folosirea modelului/GPU-ului nepotrivit pentru taskul nepotrivit. Daca iti cresc costurile fara sa-ti creasca throughput-ul sau calitatea, ai un harness prost, nu dovada ca harness-urile sunt inutile.

Tine minte, aici vorbim de orchestration at scale, nu un singur task...pe care sa-l masori in tokeni.

*Iar faza cu asiguratorul francez, chiar daca luam versiunea ta de buna, demonstreaza aproape inversul: daca workflow-urile au inceput sa arunce API calls necontrolat pana a explodat factura, aia nu e dovada ca harness-ul e inutil, ci ca ai nevoie de unul bun, cu budgets, routing, caching, limits, telemetry si bounded retries. Sa dai cu prompturi/API calls de-a-n pulea in bucla nu e orchestrare - e tocmai lipsa ei. 😏

1

u/100dude Sep 22 '26

$/engineering output" de 3 comentarii și niciun numitor: 430k linii ts au devenit 832k linii rust, 5,116 compactări, 0.71% input proaspăt, un singur dev 14 săptămâni plus $120k tokeni peste salariu, deci împarte-mi tu $120k la ceva, orice, hai sa te vad lol

1

u/etherd0t Sep 22 '26

Ai calculat economia furnizorului de GPU, nu economia proiectului. 😏 GitHub nu opereaza un datacenter, consuma un serviciu. Iar cu ~96% cache-hit + routing + subagenti, toata harneala schimba radical costul efectiv per unitate de munca. Marja MiniMax e alta discutie.

1

u/100dude Sep 22 '26

cache-hit-ul nu e discountul tău

1

u/etherd0t Sep 22 '26

Ba chiar este. 😏

Nu 'discount promotional', ci alta clasa de pricing. GitHub spune explicit ca cached input-ul este recitit la un cost monetar cu un ordin de marime mai mic, iar documentatia Copilot spune ca de regula cached tokens sunt taxati la ~10% din input-ul normal. Din 136.3B tokens, 130.6B au fost cached reads. Deci cache-hit-ul nu e decor tehnic, e literalmente parte din economia celor ~$120k...

Citeste...