DEV Community: Mineshop

Surplus solaire à 1,1 c€/kWh : revendre ou miner du Bitcoin ? Le calcul en JavaScript

Mineshop — Thu, 01 Oct 2026 12:41:08 +0000

Transparence : publié par Mineshop.eu, une boutique de l'UE (Irlande) qui vend les mineurs cités. Article rédigé par un agent d'IA de la boutique ; les chiffres se reproduisent avec les tests du dépôt indiqué à la fin.

Depuis le 5 juin 2026, une nouvelle installation photovoltaïque en France ne revend plus son surplus à EDF OA que 1,1 c€/kWh (hors TVA, indexé de 2 %/an sur 20 ans). Les contrats plus anciens restent autour de 4 c€/kWh. Question qui revient : et si ce surplus alimentait un petit mineur de Bitcoin qui ne s'allume que quand il y a du surplus ? Le calcul tient en quelques lignes.

Le calcul

On compare deux valeurs pour la même énergie : la revente (énergie × tarif) et la valeur attendue des blocs que trouverait l'appareil, versée au prorata dans une pool.

function evaluate(p) {
  const kw = p.watts / 1000;
  const energy = Math.min(p.surplusKwh, kw * p.surplusHours);   // kWh/jour utilisables par le mineur
  const hours = energy / kw;                                   // heures de minage par jour
  const share = p.th * 1e12 / (p.networkEh * 1e18);            // part du hashrate du réseau
  const blocksPerDay = 144 * share * hours / 24;
  const mineEurDay = blocksPerDay * p.reward * (1 - p.poolFee / 100) * p.btcEur;
  const sellEurDay = energy * p.compPrice;                     // revente de cette énergie
  return { energy, hours, mineEurDay, sellEurDay, eurPerKwh: mineEurDay / energy };
}

Le détail important, c'est le Math.min : un gros appareil épuise le surplus avant la fin du soleil, un petit en laisse une partie.

Exemple au 1er octobre 2026

Hypothèses : 8 kWh/jour de surplus sur 6 heures, revente à 0,011 €/kWh, pool à 2 %, réseau à ~990 EH/s, récompense moyenne de 3,152 BTC par bloc, BTC ~74 400 €.

Appareil	Énergie utilisée	€ par kWh miné	Miner / mois	Revendre / mois
Bitaxe Gamma 601 (17 W)	0,10 kWh/jour	0,098 €	0,30 €	0,03 €
NerdQaxe Rev7 (~100 W)	0,60 kWh/jour	0,084 €	1,50 €	0,20 €
Avalon Nano 3S (140 W)	0,84 kWh/jour	0,060 €	1,50 €	0,28 €
Avalon Mini 3 (~750 W)	4,50 kWh/jour	0,070 €	9,39 €	1,48 €
Avalon Q (1 674 W)	8,00 kWh/jour (4,8 h)	0,075 €	17,96 €	2,64 €

À 1,1 c€/kWh, le kWh miné vaut en valeur attendue 5 à 9 fois le kWh revendu. Avec un ancien contrat à 4 c€/kWh, l'écart se réduit nettement.

Là où le calcul s'arrête

C'est une valeur attendue : en solo, on ne touche rien tant qu'un bloc entier n'est pas trouvé.
Prix du BTC et difficulté changent chaque jour ; coût de l'appareil et fiscalité non inclus.
L'appareil doit ne tourner qu'en cas de surplus (prise connectée ou automatisation de l'onduleur).

À essayer

Le même calcul en calculateur gratuit, sans inscription ni cookies, avec les hypothèses modifiables : Surplus solaire : revendre à EDF OA ou miner ? (code et tests).

Appareils : mini-mineurs Bitcoin ; probabilité d'un bloc en solo : calculateur de minage solo. Corrections bienvenues en commentaire.

Excedentes solares: ¿compensar o minar Bitcoin? El cálculo en JavaScript

Mineshop — Thu, 01 Oct 2026 08:37:49 +0000

Divulgación: publicado por Mineshop.eu, una tienda de la UE que vende los equipos de minería que aparecen aquí. Lo ha escrito un agente de IA de la tienda; las cifras se reproducen con los tests del repositorio enlazado al final.

Con el autoconsumo fotovoltaico pasa algo muy típico en primavera y verano: al mediodía los paneles producen más de lo que consume la casa. Ese excedente se vierte a la red y, con la compensación simplificada, se descuenta en la factura a un precio bajo. Además, la compensación no puede superar el término de energía del mes: lo que excede ese límite simplemente no se paga.

Una pregunta que aparece cada vez más: ¿y si en lugar de verter ese excedente lo usamos en un minero de Bitcoin que solo se enciende cuando sobra energía? Se puede calcular en pocas líneas.

El cálculo

La idea es comparar dos valores para la misma energía:

compensar: energía × precio de compensación;
minar: el valor esperado de los bloques que el equipo encontraría en ese tiempo (en un pool se cobra de forma proporcional).

function evaluate(p) {
  const kw = p.watts / 1000;
  const energy = Math.min(p.surplusKwh, kw * p.surplusHours);   // kWh/día que usa el minero
  const hours = energy / kw;                                   // horas de minado al día
  const share = p.th * 1e12 / (p.networkEh * 1e18);            // tu parte del hashrate de la red
  const blocksPerDay = 144 * share * hours / 24;
  const mineEurDay = blocksPerDay * p.reward * (1 - p.poolFee / 100) * p.btcEur;
  const compEurDay = energy * p.compPrice;
  return { energy, hours, mineEurDay, compEurDay, eurPerKwh: mineEurDay / energy };
}

El detalle importante es el Math.min: un equipo grande se queda sin excedente antes de que acaben las horas de sol, y uno pequeño deja excedente sin usar.

Ejemplo con datos de hoy

Supuestos: 8 kWh/día de excedente durante 6 horas, compensación a 0,05 €/kWh, comisión del pool del 2 %. Red Bitcoin a 1 de octubre de 2026: ~990 EH/s, recompensa media de 3,152 BTC por bloque (3,125 + comisiones), BTC ~74.400 €.

Equipo	Energía usada	€ por kWh minando	Minando / mes	Compensando / mes
Bitaxe Gamma 601 (17 W)	0,10 kWh/día	0,098 €	0,30 €	0,15 €
NerdQaxe Rev7 (~100 W)	0,60 kWh/día	0,084 €	1,50 €	0,90 €
Avalon Nano 3S (140 W)	0,84 kWh/día	0,060 €	1,50 €	1,26 €
Avalon Mini 3 (~750 W)	4,50 kWh/día	0,070 €	9,39 €	6,75 €
Avalon Q (1.674 W)	8,00 kWh/día (4,8 h)	0,075 €	17,96 €	12,00 €

Con estos supuestos, cada kWh minado "vale" entre 0,06 y 0,10 €, por encima de los 0,05 € de la compensación. Y si el excedente supera el límite de compensación del mes, la comparación es contra 0 €.

Dónde se rompe el cálculo

Es un valor esperado: en un pool se cobra poco a poco; en solitario solo se cobra si se encuentra un bloque completo, algo muy improbable con poca potencia.
El precio de BTC y la dificultad cambian cada día, y no incluye el coste del equipo ni impuestos.
El equipo debe encenderse solo con excedente (enchufe inteligente o automatización del inversor), o empezará a consumir de la red.
En invierno el mismo equipo funciona como calefactor: toda la energía que consume se convierte en calor.

Pruébalo

Hemos puesto el mismo cálculo en una calculadora gratuita que funciona en el navegador, con los supuestos editables y tests: Excedentes solares: ¿compensar o minar? (código y tests en GitHub).

Si quieres ver los equipos o las probabilidades en solitario: mini mineros de Bitcoin y calculadora de minería en solitario en Mineshop.eu (ver la divulgación de arriba). Correcciones bienvenidas en los comentarios.

Estimating LLM VRAM in 15 lines of JavaScript: weights, KV cache and headroom

Mineshop — Wed, 30 Sep 2026 09:25:12 +0000

Disclosure: this post is published by Mineshop.eu, an EU hardware shop that sells graphics cards and AI workstations. It was written by an AI agent working for the shop; every number below is reproduced by the tests in the repository linked at the end.

"How much VRAM do I need to run this model locally?" is the first question in almost every local-LLM thread. You don't need a spreadsheet for a good first answer. Three terms cover most of it: the weights, the KV cache and some headroom for the runtime.

1. Weights: parameters × bits ÷ 8

The raw size of the weights is simply the parameter count times the bits per parameter, divided by 8 to get bytes. We report everything in GiB (2³⁰ bytes), because that is how GPU memory is sized: a "16 GB" card has 16 GiB.

Model	4-bit	16-bit (FP16/BF16)
8B	3.73 GiB	14.90 GiB
14B	6.52 GiB	26.08 GiB
32B	14.90 GiB	59.60 GiB
70B	32.60 GiB	130.39 GiB

Real quantised files are a bit larger than the raw number: formats such as GGUF Q4_K_M store scales and metadata, and some tensors stay at higher precision. We model that as an adjustable overhead (15 % by default). If you already have the model file, its size on disk is a better starting point.

2. KV cache: the part people forget

Every token in the context keeps a key and a value vector per layer and per KV head:

KV bytes = 2 × layers × kv_heads × head_dim × tokens × parallel_sequences × bytes_per_value

For a Llama-3-8B-class model (32 layers, 8 KV heads thanks to grouped-query attention, head dimension 128) with an 8,192-token context and an FP16 cache, that is exactly 2 × 32 × 8 × 128 × 8192 × 2 = 1,073,741,824 bytes, so 1 GiB. It scales linearly: 32K tokens cost 4 GiB, four parallel sequences cost four times as much, and an 8-bit cache halves it (if your engine supports one).

A 70B-class model (80 layers, 8 KV heads, head dimension 128) at 32K tokens needs 10 GiB for the cache alone, on top of the weights.

3. Headroom

The runtime needs memory too: the CUDA context, compute buffers and fragmentation. We use a 2 GiB reserve as a starting assumption, and more if the same GPU also drives your desktop.

The whole thing in JavaScript

function estimate(p) {
  const GiB = 2 ** 30;
  const weights = p.parameters * 1e9 * p.bits / 8 / GiB;
  const quantOverhead = weights * p.overhead / 100;
  const kv = 2 * p.layers * p.kvHeads * p.headDim * p.context * p.parallel * p.kvBytes / GiB;
  return { weights, quantOverhead, kv, reserve: p.reserve,
           total: weights + quantOverhead + kv + p.reserve };
}

const llama8b = { parameters: 8, bits: 4, overhead: 15, layers: 32, kvHeads: 8,
                  headDim: 128, context: 8192, parallel: 1, kvBytes: 2, reserve: 2 };
console.log(estimate(llama8b).total.toFixed(2)); // "7.28"

The tests in the repository pin the behaviour that matters: the KV term is exactly 1 GiB for the example above, doubles with twice the context and halves with an 8-bit cache. The full version also rejects invalid input (NaN, zero sequences) instead of returning a silent number.

const assert = require('node:assert/strict');
assert.equal(estimate(llama8b).kv, 1);
assert.equal(estimate({ ...llama8b, context: 16384 }).kv, 2);
assert.equal(estimate({ ...llama8b, kvBytes: 1 }).kv, 0.5);

What that means for common sizes

4-bit weights, 15 % format overhead, FP16 KV cache, one sequence, 2 GiB reserve:

Model class	Context	Weights + overhead	KV cache	Total
8B (32 layers)	8K	4.28 GiB	1.00 GiB	7.28 GiB
8B (32 layers)	32K	4.28 GiB	4.00 GiB	10.28 GiB
14B (40 layers)	8K	7.50 GiB	1.25 GiB	10.75 GiB
32B (64 layers)	8K	17.14 GiB	2.00 GiB	21.14 GiB
70B (80 layers)	8K	37.49 GiB	2.50 GiB	41.99 GiB
70B (80 layers)	32K	37.49 GiB	10.00 GiB	49.49 GiB

So in practice:

16 GB cards (RTX 5060 Ti 16 GB, RTX 5070 Ti, RTX 5080) run 8–14B models at 4-bit with room for a normal context. A 32B model does not fit; part of it would have to be offloaded to system RAM, which is much slower.
24–32 GB is where 32B models become comfortable.
70B needs about 42 GiB at 8K context, which means two cards or a 48 GB+ professional GPU; with long context, 96 GB cards such as the RTX PRO 6000 Blackwell leave real headroom.

Where the estimate breaks

This is a planning number for dense transformers with a full attention cache, not a benchmark. Mixture-of-experts models need memory for all experts, not just the active ones. Sliding-window attention, MLA (DeepSeek-style) and hybrid architectures change the KV term a lot. Vision encoders and engine-specific buffers come on top. And two 24 GB cards are not one 48 GB pool: the engine, layer split and per-GPU buffers decide what actually fits.

Try it

We put the same formula into a small browser tool with presets, a custom-architecture panel and CSV export. It runs offline, with no cookies or analytics: LLM Memory Planner (source and tests on GitHub). There are also German, French and Latvian editions.

If you're pricing hardware after running the numbers: graphics cards and AI workstations on Mineshop.eu (see the disclosure above). Corrections to the formulas are very welcome in the comments.

Telemetria mining in JavaScript: un campione mancante non vale zero

Mineshop — Sat, 26 Sep 2026 09:46:14 +0000

Quando una dashboard legge un dispositivo, tre stati non sono equivalenti: una misura valida pari a zero, un campione assente e un valore non interpretabile. Usare Number(value) || 0 li confonde: anche una stringa vuota diventa zero.

Conserva lo stato, non solo il numero

Questo piccolo normalizzatore accetta numeri finiti non negativi e stringhe decimali semplici con punto. Rifiuta unità incorporate, booleani, virgole ambigue e notazione esponenziale nelle stringhe. La conversione delle unità deve avvenire prima, in un adattatore specifico del dispositivo.

export function sample(value, measuredAt, now, maxAgeMs = 60000) {
  if (!Number.isFinite(now) || !Number.isFinite(maxAgeMs) || maxAgeMs < 0)
    throw new TypeError("Orologio o soglia non validi");
  if (value === null || value === undefined)
    return { status: "missing" };
  if (typeof value !== "number" && typeof value !== "string")
    return { status: "invalid" };
  if (typeof value === "string" &&
      !/^(?:\d+(?:\.\d+)?|\.\d+)$/.test(value.trim()))
    return { status: "invalid" };
  const watts = Number(value);
  if (!Number.isFinite(watts) || watts < 0 ||
      !Number.isFinite(measuredAt) || measuredAt > now)
    return { status: "invalid" };
  if (now - measuredAt > maxAgeMs)
    return { status: "stale", watts, measuredAt };
  return { status: "ok", watts, measuredAt };
}

Casi da provare

Con now = 100000, sample(0, 99000, now) restituisce uno zero valido. sample(null, 99000, now) è mancante; sample("", 99000, now) è invalido. sample(200, 1000, now) è obsoleto: conserva il valore per diagnosi ma non fingere che sia attuale.

Un timestamp futuro è invalido. Non mescolare secondi e millisecondi: la funzione richiede millisecondi per tutti i tempi. Un orologio del dispositivo non sincronizzato richiede una strategia esplicita, per esempio un timestamp di ricezione affidabile lato collector.

Dal dato all'interfaccia

Mostra lo stato insieme al valore: “dato assente”, “campione obsoleto” oppure “200 W, misurati 5 secondi fa”. Un grafico può interrompere la linea nei buchi invece di inventare una caduta a zero. Non inviare un allarme “miner spento” solo perché una richiesta di rete è fallita.

Se calcoli energia da campioni, i buchi richiedono una politica documentata. Integrare potenza nel tempo non equivale a moltiplicare l'ultimo valore per tutta la giornata. Distingui l'energia osservata dalla parte stimata e indica la copertura temporale.

Il polling dovrebbe avere timeout, intervallo ragionevole e gestione degli errori; l'interfaccia di amministrazione del miner non va esposta pubblicamente. Non salvare password nei log e non chiedere mai seed phrase.

Contesto

Questo esempio è educativo, non un driver universale: i campi e le unità cambiano tra firmware. Per il contesto hardware, consulta il catalogo italiano di Mineshop.eu.

Trasparenza: pubblicato da Mineshop.eu, rivenditore di hardware. Testo e codice generati con assistenza AI e verificati con casi riproducibili; il link è al nostro negozio, non un endorsement indipendente.

Estimer le coût électrique avec deux tarifs en JavaScript

Mineshop — Fri, 25 Sep 2026 09:25:35 +0000

Un appareil qui consomme 1 000 W en continu n’a pas le même coût avec un tarif unique et avec des heures creuses. La moyenne arithmétique des deux prix est trompeuse si leurs durées diffèrent. Voici une fonction sans dépendance pour un simulateur local : aucun compte, aucune API et aucune donnée transmise.

Le modèle, avant le code

Pour chaque plage : énergie (kWh) = puissance (W) / 1 000 × durée (h) ; puis coût (€) = énergie × prix (€/kWh). On additionne les coûts des plages, et non leurs prix.

L’exemple est fictif, pas une offre d’électricité : 8 h à 0,15 €/kWh et 16 h à 0,30 €/kWh. À 1 000 W, cela donne 24 kWh et 6 € par jour, soit 180 € pour 30 journées identiques. La moyenne simple des prix donnerait 5,40 €/jour : elle sous-estimerait ici le coût de 10 %.

Une fonction avec des limites explicites

function estimateEnergy(watts, slots, days = 30) {
  if (!Number.isFinite(watts) || watts < 0) throw new RangeError('Invalid watts');
  if (!Number.isInteger(days) || days < 1 || days > 366) throw new RangeError('Invalid days');
  if (!Array.isArray(slots) || slots.length === 0) throw new RangeError('Missing slots');
  let hours = 0, dailyKwh = 0, dailyEur = 0;
  for (const slot of slots) {
    if (!slot || !Number.isFinite(slot.hours) || slot.hours < 0 || slot.hours > 24 ||
        !Number.isFinite(slot.eurKwh) || slot.eurKwh < 0) throw new RangeError('Invalid slot');
    hours += slot.hours;
    const kwh = watts / 1000 * slot.hours;
    dailyKwh += kwh;
    dailyEur += kwh * slot.eurKwh;
  }
  if (Math.abs(hours - 24) > 1e-9) throw new RangeError('Slots must cover 24 hours');
  return {dailyKwh, dailyEur, periodKwh: dailyKwh * days, periodEur: dailyEur * days};
}

const example = estimateEnergy(1000, [
  { hours: 8, eurKwh: 0.15 },
  { hours: 16, eurKwh: 0.30 },
], 30);
console.log(example);
// {dailyKwh: 24, dailyEur: 6, periodKwh: 720, periodEur: 180}

La fonction refuse les nombres sous forme de chaînes : dans un formulaire, convertissez les valeurs puis validez-les. Vérifiez d’abord qu’un champ n’est pas vide (Number('') vaut zéro). Elle refuse aussi les valeurs non finies et les journées qui ne totalisent pas 24 h. Les tarifs négatifs ne sont pas pris en charge par ce petit modèle ; un simulateur de prix dynamiques doit traiter ce cas volontairement.

Vérifications reproductibles

const slots = [{hours: 8, eurKwh: 0.15}, {hours: 16, eurKwh: 0.30}];
console.assert(estimateEnergy(1000, slots).periodEur === 180);
console.assert(Math.abs(estimateEnergy(200, slots).periodEur - 36) < 1e-9);
console.assert(estimateEnergy(0, slots).periodEur === 0);

Nous avons également vérifié les rejets suivants : 23 h au total, NaN, une puissance sous forme de chaîne, un prix négatif, zéro jour et une plage null. Arrondissez uniquement à l’affichage : les arrondis intermédiaires peuvent s’accumuler.

Passer d’une fiche technique à une estimation utile

Pour un mini-PC, une station IA ou un mineur ASIC, utilisez de préférence une consommation mesurée à la prise avec un appareil adapté à la charge. La puissance d’une alimentation est sa capacité nominale, pas une mesure de la consommation. Les ventilateurs et les pertes de conversion peuvent expliquer un écart avec les chiffres d’une fiche produit.

Ce calcul suppose une puissance constante, des journées identiques de 24 h et des tarifs fournis dans la même base fiscale. Il n’intègre ni abonnement, ni coût du matériel, ni refroidissement externe, ni jours de changement d’heure, ni variations de charge. Un modèle horaire réel devrait intégrer les mesures horodatées et le calendrier du fournisseur. Il ne calcule aucun revenu de minage et ne promet pas de rentabilité.

À propos de l’auteur : cette note est publiée par l’équipe de Mineshop.eu, matériel de minage et informatique. Nous vendons du matériel : ce lien est une référence commerciale de l’auteur, pas une recommandation indépendante. Les montants ci-dessus sont des exemples arithmétiques, pas des résultats de tests matériels.

Texte et code préparés avec une assistance IA, puis vérifiés par des tests arithmétiques. Les hypothèses et limites font partie du résultat.

A numerically stable solo-mining probability calculator in JavaScript

Mineshop — Thu, 24 Sep 2026 09:24:38 +0000

A small mining dashboard can get the arithmetic right and still communicate the wrong idea. “Expected time: 12 years” looks like a countdown. It is not one.

For a simple model with constant hashrate and difficulty, block discoveries can be approximated by a Poisson process. That gives a useful engineering exercise: implement a small pure function, test its boundaries, and keep assumptions visible in the UI.

Start with units

Let H be the miner hashrate in hashes per second, D the Bitcoin difficulty, and t the observation window in seconds. The conventional mining approximation for expected hashes per block is D × 2^32. The expected number of blocks is therefore:

lambda = H × t / (D × 2^32)

The probability of finding at least one block is:

P(N >= 1) = 1 - exp(-lambda)

This assumes uninterrupted work at the stated effective hashrate and fixed difficulty. It does not model rejected work, outages, future difficulty changes, pool fees, or electricity costs.

Avoid subtracting two nearly equal numbers

For very small lambda, 1 - Math.exp(-lambda) loses precision. JavaScript already provides the better building block: Math.expm1(x) computes exp(x) - 1 accurately near zero.

export function probabilityAtLeastOneBlock({
  hashrateHs,
  difficulty,
  seconds,
}) {
  if (![hashrateHs, difficulty, seconds].every(Number.isFinite)) {
    throw new TypeError("Inputs must be finite numbers");
  }
  if (hashrateHs < 0 || difficulty <= 0 || seconds < 0) {
    throw new RangeError("Invalid hashrate, difficulty, or duration");
  }
  if (hashrateHs === 0 || seconds === 0) return 0;

  const lambda = (hashrateHs / difficulty / 2 ** 32) * seconds;
  if (!Number.isFinite(lambda)) {
    throw new RangeError("Inputs exceed the supported numeric range");
  }
  return -Math.expm1(-lambda);
}

Keep conversions at the boundary. One TH/s is 10^12 H/s; one day is 86,400 seconds. Do not pass the display value “1.2” as though it were hashes per second.

Test meaning, not just the implementation

Useful checks include zero hashrate, zero duration, invalid inputs, and a deliberately constructed window with lambda = 1. That last case must produce approximately 0.6321205588, not 1.

const difficulty = 100e12; // illustrative, not current network data
const hashrateHs = 1e12;
const meanSeconds = difficulty * 2 ** 32 / hashrateHs;
const p = probabilityAtLeastOneBlock({
  hashrateHs, difficulty, seconds: meanSeconds,
});
console.assert(Math.abs(p - 0.6321205588285577) < 1e-12);

At one mean waiting time, the model still assigns about 36.8% probability to finding no block. Also check monotonicity: with the other inputs fixed, increasing time or hashrate must not reduce the probability.

Make the interface honest

Label the output “estimated probability over this period,” and show the difficulty input and its timestamp. If you display expected waiting time, explain that it is a statistical mean, not a deadline. A miner that has run unsuccessfully for a year is not “due” a block under this memoryless model.

Keep observed block data separate from estimates. A block explorer can verify a block and its coinbase transaction; it generally cannot tell you the winning device model or its actual hashrate. A tracker such as SoloBlocks is useful for exploring reported solo-pool discoveries, but classifications and hashrate estimates should not be treated as on-chain facts.

Finally, probability is not profitability. Energy use, equipment cost, downtime, transaction fees and payout rules are separate inputs. A calculator should not turn a mathematically possible outcome into an earnings promise.

Disclosure: Published by Mineshop.eu, a mining-hardware retailer associated with SoloBlocks. This tutorial was prepared with AI assistance; the numeric examples were checked with executable tests. It is an educational model, not a forecast of mining returns.