Hoe herken je configuratiemisleiding met hardware-benchmarks: een drieledige bewijsmethode

Gebruik hardware-identificatie + meerdere benchmarkrondes + AI-doorvoer om configuratiemisleiding te kwantificeren.

Bijgewerkt 2026-08-14 · CloudWorth

hardware-benchmarksconfiguratiemisleidingVPS-verificatieoverselling-detectieCloudWorthSteal TimeVPS oversellingVPS benchmark

Alleen benchmarks gecombineerd met AI-doorvoer en Steal Time-bewijs kunnen misleiding identificeren.

Drie hulpmiddelen om valse specificaties te herkennen

Haast je niet om het systeem opnieuw te installeren of een terugbetaling aan te vragen. Om valse specificaties op het gebied van hardware, benchmarks en configuratie te herkennen, gebruik ik gewoonlijk drie hulpmiddelen om indrukken om te zetten in controleerbare gegevens: /proc/cpuinfo voor model en aantal kernen, sysbench voor de echte CPU-rekenkracht, en daarbovenop een ronde AI-inferentiedoorvoer (zoals de promptverwerkingssnelheid van llama.cpp). Deze drie controleren elkaar en zijn onmisbaar. Ik bewaar ook een eigen checklistsjabloon op de benchmarktool-pagina en volg die direct bij elke nieuwe machine.

Veel mensen trekken conclusies op basis van alleen lscpu, maar de virtualisatielaag kan de modelstring volledig vervalsen. Ik kwam eerder een VPS tegen met een vermeende 8-core EPYC; nproc gaf inderdaad 8 terug, maar de sysbench single-core score was slechts een kwart van die van een fysieke machine met hetzelfde model. Pas bij het controleren van cpu cores en siblings in /proc/cpuinfo ontdekte ik dat hyperthreading was uitgeschakeld en dat er feitelijk slechts 4 fysieke threads waren toegewezen. Een benchmark is hier geen showinstrument, maar een spiegel die bedrog onthult.

Nog belangrijker is het derde hulpmiddel: AI-inferentiedoorvoer. Cloudaanbieders gebruiken 'AI-rekenkracht' graag als verkoopargument, maar een mooie CPU-modelnaam betekent niet dat de inferentie snel is. Ik meet gewoonlijk tokens/s met hetzelfde model en dezelfde kwantisering; dit ligt dichter bij de werkelijke belasting dan een pure benchmark. Als er 16 cores worden vermeld en de benchmark normaal is, maar de doorvoer overeenkomt met 8 cores, dan is de kans groot dat een buurman resources steelt — met andere woorden, de Steal Time schiet omhoog. Met de st-kolom van vmstat of het steal-veld in /proc/stat kun je direct kwantificeren hoeveel CPU de lawaaiige buurman heeft gestolen.

Deze drie hulpmiddelen hebben nog een toepassing: het berekenen van de FinOps-premie. Wanneer de benchmark en doorvoer zijn geverifieerd, kun je met 'werkelijk beschikbare rekenkracht ÷ vermelde rekenkracht × prijs' de kosten per eenheid rekenkracht berekenen. Door dit te vergelijken met standaard public cloud-instanties, kun je bepalen of deze machine waar voor zijn geld biedt of een domheidstaks is. Het opgeven van valse specificaties is niet alleen het vervalsen van parameters, maar ook een kostenvalkuil.

In de volgende stap laat ik concreet zien hoe elke opdracht wordt uitgevoerd en hoe de output moet worden geïnterpreteerd, zodat deze drie hulpmiddelen een controleerbaar forensisch proces vormen.

Scores komen niet overeen met de specificaties

Bij het ontvangen van een cloudserver moet je niet meteen naar /proc/cpuinfo kijken voor het aantal cores en threads. De kloof tussen hardwareprestaties en opgegeven specificaties zit vaak verborgen in een paar cijfers. Ik heb de gewoonte om eerst sysbench cpu --threads=N --time=30 run te draaien en daarna te vergelijken met de Model naam in lscpu en de processorlijst van cat /proc/cpuinfo. Als 8 cores slechts de score van 4 cores opleveren, controleer dan eerst of hyperthreading is uitgeschakeld—maar vaker wordt de CPU beperkt door QoS.

sysbench cpu --threads=$(nproc) --time=30 --events=0 run

Let op of events per second stabiel is. Als de eerste 10 seconden hoog zijn en de laatste 20 seconden plotseling dalen, is turbo waarschijnlijk afgeknepen, of steelt de host in het geheim resources. In dat geval moet je ook naar de st kolom in vmstat 1 kijken—als Steal Time meer dan 5% bedraagt, kun je er bijna zeker van zijn dat een "slechte buur" de CPU steelt. Geloof niet wat de leverancier schrijft over "3,5 GHz kloksnelheid"—dat is de piek van single-core burst, geen garantie dat je dit continu krijgt.

Configuratie-afwijkingen zitten niet alleen in de CPU. Geheugenbandbreedte en schijf-IO kunnen ook overgeboekt zijn, dus gebruik ik dd om de cache te omzeilen en de ruwe schijf te testen, en draai ik daarna een AI-inferentie (bijvoorbeeld een klein model laden en continue prompts geven) om de daadwerkelijke doorvoer te zien. Een benchmark is een momentopname, AI-doorvoer is de echte weerspiegeling onder continue belasting. Overigens, als je cloudproviders vergelijkt, kijk dan niet alleen naar de prijs—FinOps-premie = (werkelijke prestaties ÷ nominale prestaties) ÷ eenheidsprijs. Wanneer scores niet overeenkomen met de specificaties, is duur niet per se slecht, maar goedkoop is meestal meer overdreven.

Tot slot: sla de resultaten van drie benchmarkrondes op als logboek met datum en instantie-ID. Voordat je verlengt, draai je nog een keer om te zien of de score is gedaald—dat is het meest directe "bewijs van downgrade".

Actuele doorvoer voor AI valideren

Benchmarks tonen alleen de statische piek van de CPU. Hardware-benchmarks zijn zeker belangrijk, maar bij overdreven configuraties is de grootste zorg de 'actuele doorvoer' – vooral bij aanhoudende hoge belasting zoals AI-inferentie. Ik gebruik gewoonlijk llama.cpp of vLLM om een vast model te laden (bijv. Qwen2.5-7B-Q4), dezelfde prompt uit te voeren en te controleren of de tokens/s overeenkomen met de opgegeven rekenkracht. Als een configuratie met 8 kernen slechts de doorvoer van 4 kernen heeft, moet je denken aan overboeking of een verlaagde configuratie.

De opdracht is eenvoudig: ./llama-cli -m model.gguf -p "写一篇短文" -n 128, voer deze drie keer uit en neem de mediaan. Houd tegelijkertijd vmstat 1 in de gaten en let op de steal-kolom. Als de steal-waarde tijdens AI-inferentie aanhoudend >5% is, betekent dit dat buren CPU-capaciteit afpakken; dat is het bewijs van een 'slechte buur' en verklaart ook de verminderde doorvoer.

Laten we ook een FinOps-berekening maken: stel dat een opgegeven 8-kernconfiguratie $50 per maand kost, maar de werkelijke doorvoer slechts de helft is van de nominale. Dan verdubbelt de kosten per token, met een premie van maar liefst 100%. Dit is niet alleen 'korting op prestaties', maar geld dat je te veel betaalt voor overdreven specificaties. Met hardware-benchmarks + actuele AI-doorvoer + steal-bewijs wordt overdreven specificaties omgezet van een 'gevoel' naar kwantificeerbaar bewijs op je factuur.

Detectiemethode voor oververkoop door lastige buren

Oververkoop is de meest typische bron van "gefakete benchmarks en overdreven specificaties" bij cloudservers. Je koopt 8 kernen, maar tien andere instanties delen dezelfde fysieke CPU. Hoe maak je van deze "gestolen" prestaties bewijs? Kijk naar Steal Time.

In Linux is het %st-veld van top of het st-veld van vmstat de tijd dat een virtuele CPU wacht op een echte CPU. Als %st tijdens het benchmarken stabiel boven de 5% ligt, staan je vCPU's in de wachtrij; boven de 20% kun je er vrijwel zeker van zijn dat de buren resources afpakken. Combineer dit met meerdere rondes CPU-testen met sysbench en noteer elke keer de events/sec en de schommelingen in steal. Machines met overdreven specificaties scoren vaak de eerste keer normaal, maar daarna stort het in omdat de cache door de buren wordt weggevaagd.

Deze aanpak houdt ook direct verband met de FinOps-premie. In /app heb ik instanties met dezelfde configuratie vergeleken: een machine met een nominale 8 kernen maar een benchmarkniveau van slechts 4 kernen is, gerekend per benchmarkpunt, 40% duurder dan een reguliere instantie. Met andere woorden, je betaalt een premie voor overdreven hardware, en dat geld is precies de kosten die de cloudprovider bespaart door oververkoop.

Dus om te herkennen dat specificaties niet kloppen, kijk niet alleen naar cpuinfo. De combinatie van benchmark + AI-doorvoer + Steal Time is het controleerbare bewijspad. In de volgende sectie geef ik een concreet bash-detectiescript.

Prijs-prestatieverhouding op basis van premie

Hardware-benchmarks onthullen onjuiste configuratiespecificaties. Je kunt niet alleen naar de absolute CPU-score kijken, maar moet ook de prijs meenemen. Bij dezelfde prijs draait een VPS die geadverteerd wordt als 8 kernen op 4 kernen, en als je Steal Time meerekent, is de werkelijke rekenkracht slechts een derde van wat opgegeven is. Op dat moment bereken je de 'premie': deel de maandelijkse prijs door de beschikbare vCPU of AI-doorvoer om de kosten per rekeneenheid te krijgen. Bijvoorbeeld: $20/maand voor 8 kernen, maar de benchmark komt overeen met 4 kernen, dus de kosten per kern zijn $5; als de naburige machine ernstig overboekt is en Steal Time langdurig >15% is, verdubbelen de werkelijke kosten per kern naar $10—duurder dan on-demand public cloud. Vanuit dit perspectief is onjuiste configuratiespecificatie niet alleen 'parametervervalsing', maar laat het gebruikers betalen voor niet-bestaande rekenkracht. In FinOps-termen heet dit 'overschreden premie voor rekenkracht per eenheid'. Ik stop meestal meerdere benchmarkrondes + AI-inferentiedoorvoer + Steal Time in deze kosten-batenanalyse, en als de berekende premie >1,5 is, wissel ik van provider. Een echt goedkope VPS is niet een lage vermelde prijs, maar een lage equivalente eenheidsprijs na benchmarks. Deze kruisvergelijking is nuttiger dan alleen leveranciers uitschelden.

Herstapprocedure en conclusie

Uiteindelijk bewijs: kijk niet alleen naar één benchmarkrun. Mijn verificatievolgorde is: eerst sysbench cpu --threads=1 en --threads=$(nproc) elk drie keer draaien, de mediaan nemen, en tegelijkertijd de modelnaam uit /proc/cpuinfo, het fysieke aantal kernen en scaling_cur_freq vastleggen om te bevestigen of Turbo is vergrendeld; daarna met dd en O_DIRECT de cache omzeilen en de schijfsnelheid meten, om niet door de page cache te worden misleid. De benchmark is slechts de eerste stap; wat de hardwarebenchmark en de opgeklopte configuratie echt vastspijkert, is kruisvalidatie: voer een lokale AI-inferentie uit (bijv. tokens/s van llama.cpp). Als er 8 kernen worden geclaimd maar de doorvoer die van 4 kernen is, kun je er vrijwel zeker van zijn dat er beperking is of dat hyperthreading is uitgeschakeld.

Een cruciale stap is het controleren van Steal Time: als het aandeel steal in top of /proc/stat hoog is, duidt dat op lawaaierige buren en ernstige overboeking van de VPS. Dit is fataaler dan alleen een lage score, want overdrijving is niet alleen 'frequentiekrimp', maar de hele host heeft een tekort. Combineer ten slotte deze drie tot een 'echte rekenkracht'-indicator en vergelijk die met de factuur om de FinOps-premie te berekenen: bijvoorbeeld nominaal 8 vCPU voor $80 per maand, maar feitelijk slechts 4 vCPU-doorvoer, waardoor de premie per kern direct verdubbelt; vergelijk dit met een standaard public-cloudinstantie voor hetzelfde geld en het bedrog wordt onmiddellijk zichtbaar.

Conclusie: benchmark + AI-doorvoer + Steal Time-drietal maakt 'opgeklopte configuratie' van intuïtie naar kwantificeerbaar bewijs. Laat je niet misleiden door een enkele ranking of CPU-model; pas als de cijfers overeenkomen met de factuur, tellen ze.