So, after I publicly challenged @luceboxai’s misleading marketing and questionable benchmark claims with specific technical evidence, @pupposandro decided to block me on X.
Interesting response.
I published my own measurements on Strix Halo + R9700. I documented discrepancies between their advertised performance and independently measured results. I linked their own synthetic benchmark prompts, public GitHub issues, and even a case where one of their maintainers acknowledged that a published performance figure likely came from an experimental branch that had never been merged.
I raised specific, verifiable technical questions.
They could have challenged my methodology. They could have published their exact benchmark configurations. They could have provided reproducible evidence supporting their claims. They could have pointed out mistakes in my analysis, and I would have been happy to correct them publicly.
Instead, I got blocked.
Until now, I was willing to consider that this recurring pattern of misleading claims, cherry-picked benchmarks, and questionable marketing practices might simply be the result of excessive enthusiasm, poor communication, or carelessness.
After this reaction, I no longer give them the benefit of the doubt.
To me, this looks like bad-faith behavior, not a genuine attempt to communicate technical results transparently.
Of course, blocking someone doesn’t prove that a benchmark is false. But when a company responds to detailed, evidence-based criticism by blocking the person asking the questions rather than addressing the substance, that tells me a great deal about its attitude toward accountability.
And frankly, I think this is especially disappointing from a company associated with @AIatAMD and @ycombinator
What makes this even more frustrating is that Strix Halo + R9700 is genuinely exciting hardware. It deserves to be represented by serious engineering and honest, reproducible performance claims, not marketing that creates expectations the available evidence doesn’t support.
I’m reposting my original analysis because I believe prospective customers deserve to see these questions and the evidence behind them.
You can block an account. You can’t make the technical questions disappear.
And until Lucebox provides verifiable answers, my criticism stands.
Lucebox, you have a serious problem with misleading marketing, and I think it's time someone called it out publicly.
What bothers me most is that @AMD Strix Halo + Radeon AI PRO R9700 is a genuinely interesting hardware platform. It deserves serious engineering, transparent benchmarks, and honest marketing. Instead, your communication repeatedly creates expectations that the underlying evidence does not adequately support.
Let's start with this image.
You advertise 192 GB of unified memory, a 32 GB R9700, up to 4 TB of storage, impressive DeepSeek performance multipliers, and a starting price of $5,999.
Except the configuration with those maximum specifications costs roughly $9,000, not $5,999.
And this is far from my biggest concern.
Your benchmark marketing is much more troubling.
Your homepage advertises DeepSeek V4 Flash performance of 788 tok/s prefill and 86 tok/s decode using DSpark on Strix Halo + R9700.
Yet the linked technical article describes a median decode throughput of 51.1 tok/s, a short-prompt ceiling case around 55 tok/s, and 45.5 tok/s on longer generations.
Where is the exact, reproducible protocol behind the 86 tok/s headline?
I actually have access to a Strix Halo + R9700 system, so I decided to measure it myself.
Using Lucebox ROCmFPX, top-6, with prefill excluded and finalization included, here is what I measured:
On prose workloads, with 128 generated tokens:
4K context: 30.75 tok/s ordinary decode, 24.87 with DSpark.
8K: 29.54 ordinary, 27.36 DSpark.
32K: 23.31 ordinary, 21.69 DSpark.
64K: 17.49 ordinary, 14.20 DSpark.
DSpark was slower than ordinary decoding in every prose test.
On an independent Python coding task, DSpark performed substantially better: 56.67 tok/s versus 32.92 tok/s ordinary decoding, with approximately 68.4% acceptance.
That's a good improvement. I'm not denying that the technology works.
But even on this coding task, I measured roughly 57 tok/s, not 86.
These are preliminary measurements, not an exact reproduction of your homepage benchmark. Prompt, expert count, context and measurement conditions matter. That's precisely why publishing a headline number without a clearly reproducible protocol is problematic.
Now let's look at one of the prompts in your own repository:
github.com/Luce-Org/lucebox/…
This is a synthetic, highly repetitive prompt containing dozens of nearly identical function descriptions.
On that prompt, I measured approximately 70 tok/s with 100% validator acceptance.
Compare that with approximately 57 tok/s and 68.4% acceptance on my independent Python task.
This is exactly why workload selection matters so much in speculative decoding.
A structurally predictable prompt can produce extremely favorable acceptance rates. That makes it useful for testing the upper limits of an implementation, but potentially unrepresentative of what people will experience on ordinary workloads.
I'm not claiming you used this particular prompt to generate the homepage's 86 tok/s. I don't have evidence of that.
I'm asking why customers are shown such an impressive headline number without the exact prompt, model configuration, acceptance rate, software commit and measurement procedure needed to reproduce it.
And why aren't realistic workloads shown alongside these best-case results?
At first, I thought I might simply be doing something wrong. So I investigated whether other people had experienced similar discrepancies.
What I found was concerning.
On Reddit, a post claiming Lucebox was 3.63x faster than NVIDIA DGX Spark was challenged over the comparability of the benchmark conditions. The author acknowledged the criticism, apologized for the misleading presentation and deleted the post.
reddit.com/r/LocalLLaMA/comm…
On GitHub issue #5, a developer tried to reproduce a published RTX 3090 prefill result of approximately 37,000 tok/s and obtained only 8,505 tok/s.
The maintainer initially suggested using a different benchmarking script. The developer tried it and reported that the results did not materially improve.
Later, maintainer davide221 acknowledged that the 37k figure most likely came from an experimental branch that had never been merged and needed retesting.
Think about that: a published performance figure that the maintainer himself subsequently suggested might have come from code not present in the public branch.
github.com/Luce-Org/lucebox/…
In GitHub issue #457, another developer documented Lucebox running at approximately 17.6 tok/s versus 36.4 tok/s for llama.cpp on an RX 7900 XTX, alongside speculative decoding failing to engage and long-context stability problems.
The maintainers provided guidance and integrated some fixes, but the documented discussion does not establish that the original performance gap was resolved.
A later independent report on the Radeon AI PRO R9700 also showed Lucebox prefill performance deteriorating substantially relative to llama.cpp as context length increased.
github.com/Luce-Org/lucebox/…
These cases are not all identical. Some concern reproducibility, others hardware-specific limitations, others benchmark methodology.
But taken together with my own measurements, they raise a serious question about how performance results are selected, documented and communicated.
How many customers are making purchasing decisions based on peak benchmark figures that they cannot realistically expect to reproduce without very specific conditions?
I am not alleging that every published benchmark is fabricated. I am saying that the gap between your marketing presentation and the publicly reproducible evidence deserves much greater scrutiny.
And frankly, I would expect better from a company publicly associated with @AMD @AIatAMD and @ycombinator .
Those associations carry credibility. They should also come with an expectation of technical transparency and responsible marketing.
There is one more issue, separate from the benchmarks, that I think deserves clarification.
Lucebox publicly identifies with Milan, Italy. Its team and activities have publicly documented connections to Italy, and there are indications that systems are assembled and shipped from Italy.
Yet when I attempt to purchase a machine from Italy, the contractual seller is AGMI AI, Inc., a Delaware corporation.
Why?
What legal and VAT structure is being used for Italian and EU sales? Where are these systems actually assembled and dispatched from? Where is the business effectively managed?
Operating through a US corporation is not inherently improper, and I'm not suggesting that the use of a Delaware entity alone establishes a tax violation.
But if the operational business is principally conducted from Italy, customers deserve clarity about the responsible legal entity and the applicable tax structure.
I run a business in Italy too. These are not abstract questions to me.
The bottom line is simple.
Strix Halo + R9700 is promising hardware. DSpark is an interesting technology. I have measured cases where it delivers real acceleration.
That's precisely why I'm frustrated.
You do not need to create inflated expectations to make this platform interesting.
What you need is transparent, reproducible benchmarking that distinguishes peak performance from realistic performance.
Publish the exact conditions behind your headline claims. Provide public scripts, prompts, model versions, commit hashes, expert configurations, acceptance rates and timer definitions.
Show results across representative coding, prose and long-context workloads, not only favorable cases.
Make the difference between starting prices and fully configured systems obvious.
And clarify the legal and tax structure behind your Italian operations.
Until those questions are answered, I think customers are entirely justified in treating Lucebox's headline performance claims with considerable skepticism.
Good engineering deserves better than marketing that makes the results look better than the evidence allows us to verify.
Marco Sala retweeted
Lucebox, you have a serious problem with misleading marketing, and I think it's time someone called it out publicly.
What bothers me most is that @AMD Strix Halo + Radeon AI PRO R9700 is a genuinely interesting hardware platform. It deserves serious engineering, transparent benchmarks, and honest marketing. Instead, your communication repeatedly creates expectations that the underlying evidence does not adequately support.
Let's start with this image.
You advertise 192 GB of unified memory, a 32 GB R9700, up to 4 TB of storage, impressive DeepSeek performance multipliers, and a starting price of $5,999.
Except the configuration with those maximum specifications costs roughly $9,000, not $5,999.
And this is far from my biggest concern.
Your benchmark marketing is much more troubling.
Your homepage advertises DeepSeek V4 Flash performance of 788 tok/s prefill and 86 tok/s decode using DSpark on Strix Halo + R9700.
Yet the linked technical article describes a median decode throughput of 51.1 tok/s, a short-prompt ceiling case around 55 tok/s, and 45.5 tok/s on longer generations.
Where is the exact, reproducible protocol behind the 86 tok/s headline?
I actually have access to a Strix Halo + R9700 system, so I decided to measure it myself.
Using Lucebox ROCmFPX, top-6, with prefill excluded and finalization included, here is what I measured:
On prose workloads, with 128 generated tokens:
4K context: 30.75 tok/s ordinary decode, 24.87 with DSpark.
8K: 29.54 ordinary, 27.36 DSpark.
32K: 23.31 ordinary, 21.69 DSpark.
64K: 17.49 ordinary, 14.20 DSpark.
DSpark was slower than ordinary decoding in every prose test.
On an independent Python coding task, DSpark performed substantially better: 56.67 tok/s versus 32.92 tok/s ordinary decoding, with approximately 68.4% acceptance.
That's a good improvement. I'm not denying that the technology works.
But even on this coding task, I measured roughly 57 tok/s, not 86.
These are preliminary measurements, not an exact reproduction of your homepage benchmark. Prompt, expert count, context and measurement conditions matter. That's precisely why publishing a headline number without a clearly reproducible protocol is problematic.
Now let's look at one of the prompts in your own repository:
github.com/Luce-Org/lucebox/…
This is a synthetic, highly repetitive prompt containing dozens of nearly identical function descriptions.
On that prompt, I measured approximately 70 tok/s with 100% validator acceptance.
Compare that with approximately 57 tok/s and 68.4% acceptance on my independent Python task.
This is exactly why workload selection matters so much in speculative decoding.
A structurally predictable prompt can produce extremely favorable acceptance rates. That makes it useful for testing the upper limits of an implementation, but potentially unrepresentative of what people will experience on ordinary workloads.
I'm not claiming you used this particular prompt to generate the homepage's 86 tok/s. I don't have evidence of that.
I'm asking why customers are shown such an impressive headline number without the exact prompt, model configuration, acceptance rate, software commit and measurement procedure needed to reproduce it.
And why aren't realistic workloads shown alongside these best-case results?
At first, I thought I might simply be doing something wrong. So I investigated whether other people had experienced similar discrepancies.
What I found was concerning.
On Reddit, a post claiming Lucebox was 3.63x faster than NVIDIA DGX Spark was challenged over the comparability of the benchmark conditions. The author acknowledged the criticism, apologized for the misleading presentation and deleted the post.
reddit.com/r/LocalLLaMA/comm…
On GitHub issue #5, a developer tried to reproduce a published RTX 3090 prefill result of approximately 37,000 tok/s and obtained only 8,505 tok/s.
The maintainer initially suggested using a different benchmarking script. The developer tried it and reported that the results did not materially improve.
Later, maintainer davide221 acknowledged that the 37k figure most likely came from an experimental branch that had never been merged and needed retesting.
Think about that: a published performance figure that the maintainer himself subsequently suggested might have come from code not present in the public branch.
github.com/Luce-Org/lucebox/…
In GitHub issue #457, another developer documented Lucebox running at approximately 17.6 tok/s versus 36.4 tok/s for llama.cpp on an RX 7900 XTX, alongside speculative decoding failing to engage and long-context stability problems.
The maintainers provided guidance and integrated some fixes, but the documented discussion does not establish that the original performance gap was resolved.
A later independent report on the Radeon AI PRO R9700 also showed Lucebox prefill performance deteriorating substantially relative to llama.cpp as context length increased.
github.com/Luce-Org/lucebox/…
These cases are not all identical. Some concern reproducibility, others hardware-specific limitations, others benchmark methodology.
But taken together with my own measurements, they raise a serious question about how performance results are selected, documented and communicated.
How many customers are making purchasing decisions based on peak benchmark figures that they cannot realistically expect to reproduce without very specific conditions?
I am not alleging that every published benchmark is fabricated. I am saying that the gap between your marketing presentation and the publicly reproducible evidence deserves much greater scrutiny.
And frankly, I would expect better from a company publicly associated with @AMD @AIatAMD and @ycombinator .
Those associations carry credibility. They should also come with an expectation of technical transparency and responsible marketing.
There is one more issue, separate from the benchmarks, that I think deserves clarification.
Lucebox publicly identifies with Milan, Italy. Its team and activities have publicly documented connections to Italy, and there are indications that systems are assembled and shipped from Italy.
Yet when I attempt to purchase a machine from Italy, the contractual seller is AGMI AI, Inc., a Delaware corporation.
Why?
What legal and VAT structure is being used for Italian and EU sales? Where are these systems actually assembled and dispatched from? Where is the business effectively managed?
Operating through a US corporation is not inherently improper, and I'm not suggesting that the use of a Delaware entity alone establishes a tax violation.
But if the operational business is principally conducted from Italy, customers deserve clarity about the responsible legal entity and the applicable tax structure.
I run a business in Italy too. These are not abstract questions to me.
The bottom line is simple.
Strix Halo + R9700 is promising hardware. DSpark is an interesting technology. I have measured cases where it delivers real acceleration.
That's precisely why I'm frustrated.
You do not need to create inflated expectations to make this platform interesting.
What you need is transparent, reproducible benchmarking that distinguishes peak performance from realistic performance.
Publish the exact conditions behind your headline claims. Provide public scripts, prompts, model versions, commit hashes, expert configurations, acceptance rates and timer definitions.
Show results across representative coding, prose and long-context workloads, not only favorable cases.
Make the difference between starting prices and fully configured systems obvious.
And clarify the legal and tax structure behind your Italian operations.
Until those questions are answered, I think customers are entirely justified in treating Lucebox's headline performance claims with considerable skepticism.
Good engineering deserves better than marketing that makes the results look better than the evidence allows us to verify.
Vedremo sempre più casi di questo tipo.
Serve in intervento urgente e vasto su tutti i sistemi informatici critici nazionali.
ft.com/content/2d4333d1-8119…
I modelli AI di frontiera hanno ormai superato chiaramente le capacità matematiche dei migliori matematici "umani".
I matematici stanno iniziando a chiedersi come cambierà, da ora in poi, il senso stesso della loro attività.
La matematica così come l'abbiamo conosciuta finora potrebbe essere finita: stiamo arrivando al punto in cui, in poche ore, un modello AI può produrre risultati su problemi che resistevano da anni o decenni.
Queste sono notizie da telegiornale, da prima pagina dei giornali. In Italia non se ne parla.
Quello che sta succedendo in matematica accadrà sicuramente sempre di più in altri settori, man mano che il reinforcement learning with verifiable rewards e tecniche analoghe verranno estesi nel post-training dei modelli AI di frontiera.
Bisogna iniziare SUBITO a pensare a come gestire questa transizione, perché molti lavori verranno travolti, con conseguenze sul mercato del lavoro enormi.
nitter.cf/OpenAI/status/21075967…
We’re releasing a broad range of new mathematical results produced by an internal frontier model.
We’ve been consulting with the independent Advisory Group on Mathematics and Artificial Intelligence at the Institute for Advanced Study, and we have drawn on their advice and public recommendations to inform how we release these results.
github.com/openai/math
Serve un intervento istituzionale rapido e considerare la questione un'emergenza nazionale.
L'attuale classe politica non sta capendo nulla della rivoluzione AI e non sta facendo nulla, si sveglierà in ritardo come al solito quando i danni ormai sono già fatti e irrecuperabili.
nitter.cf/WSJ/status/21074160557…
Hackers used a Chinese AI agent to attack South Korea’s biggest banks—one of the first such AI-powered intrusions into the global financial system on.wsj.com/4i5VwGg
Il coniglio è già fuori dal cilindro, gli attacchi sono già in corso.
Prima gli hacker malevoli utilizzavano vulnerabilità già conosciute verso chi non aggiornava i propri sistemi, con i nuovi modelli AI invece ne trovano di nuove in continuazione.
La situazione sta scappando di mano e provocherà seri problemi.
nitter.cf/a16z/status/2107565314…
Questo in Italia sarà un problema enorme, nessuno sta gestendo questi rischi nel modo adeguato. Vedremo problemi sempre più rilevanti, come quello di Revolut e la PEC della polizia.
Il settore più critico e a maggiore rischio è quello sanitario. I dati sanitari valgono MOLTO di più dei dati finanziari e la sicurezza è MOLTO più bassa rispetto al sistema finanziario.
nitter.cf/a16z/status/2107523804…
450+ tok/s of prefill on AMD Strix Halo.
DS4 Halo accelerates DeepSeek V4 Flash on a single Radeon 8060S integrated GPU, in Strix Halo 128 GB.
454.59 tokens/s measured on a complete 4K prompt.
Model: DeepSeek V4 Flash 0731, using asymmetric 2/8-bit quantization: IQ2_XXS + Q2_K, with selected Q8 tensors.
Bitwise quality checks passed against original DS4: token IDs, full logits and complete inference state match in the tested cases. Model weights and quantization remain unchanged.
The official DS4 Strix Halo report lists 295.27 tokens/s for a 2K→4K interval.
Both repositories are now public, with benchmark conditions and validation evidence:
Engine: github.com/MadRocK-AI/ds4
Linux installer and launcher: github.com/MadRocK-AI/ds4-on…
Thanks @antirez for creating and sharing DwarfStar 4. Feel free to upstream any changes you find useful!
🤖 Made with AI
L'AI sarà una rivoluzione tecnologia più impattante di internet e forse più importante delle grandi rivoluzioni come quella industriale, l'elettricità, le ferrovie etc...
Questo non significa che non ci saranno scossoni importanti nel percorso, l'aria di euforia è paragonabile alla fine degli anni 90 e in più è alle porte una crisi del debito in tutti paesi occidentali.
La gestione di questi due fenomeni da parte della classe politica avrà un impatto nelle nostre vite ad un livello che non si è mai visto nella storia recente.
Dipendenza software + dipendenza hardware = scegli di chi essere suddito.
Nell'AI la dipendenza non è solo software, ma anche hardware.
Diciamo che hai modelli open di frontiera e quindi puoi gestirli senza il rischio di essere tagliato fuori. Dove li fai girare? Devi avere l'hardware adeguato. Chi sono i fornitori di questo hardware?
- Stati Uniti (NVIDIA, AMD, Intel)
- Cina (Huawei, Xiaomi etc..)
La dipendenza software e hardware ti impone al sudditanza verso queste superpotenze, è necessario un serio percorso di indipendenza e sicurezza nazionale.
USA o CINA?
L'europa è ormai fuori dai giochi, il gap accumulato verso i modelli AI di frontiera di Stati Uniti e Cina è ormai irrecuperabile.
Questo è un serio problema, perchè stiamo parlando di sicurezza nazionale e supremazia tra nazioni.
Le nuove guerre si combatteranno con l'AI, la ricerca verrà trainata dall'AI cosi come la produttività.
In questo momento ci sonUSA o CINA?
L'Europa è ormai quasi fuori dai giochi sui modelli AI di frontiera. Il gap accumulato rispetto a Stati Uniti e Cina è enorme e rischia di essere difficilmente recuperabile.
Questo è un serio problema, perché stiamo parlando di sicurezza nazionale e competizione tra potenze.
Le nuove guerre si combatteranno sempre più con l'AI, la ricerca verrà trainata dall'AI, così come la produttività.
In questo momento, almeno nel breve periodo, sembrano esserci due opzioni:
1- USA: essere completamente dipendenti dagli Stati Uniti, diventando di fatto una succursale dell'impero americano.
I modelli di frontiera più avanzati sono prevalentemente chiusi e controllati dai provider: se ti danno accesso li usi, se per qualsiasi ragione politica o strategica decidono di limitartelo, sei fuori.
È già successo, per un periodo, con Fable di Anthropic, il cui accesso ai cittadini stranieri è stato limitato per decisione del governo americano.
2- CINA: diversi dei migliori modelli cinesi sono invece open-weight.
Questo significa che puoi scaricarne i pesi, eseguirli sulla tua infrastruttura e, una volta resi pubblici, nessuno può più revocartene l'accesso.
Ovviamente la Cina potrebbe decidere di non rendere open-weight i modelli successivi.
La dipendenza quindi rimane, ma è diversa: dipendi dalla Cina per continuare ad avere accesso alle generazioni future più potenti, non per continuare a utilizzare quelle che hai già.
La nostra classe politica sarà chiamata a fare scelte di questo tipo e temo che non abbia ancora compreso fino in fondo di cosa stiamo parlando.
Questo è un enorme rischio per il nostro futuro.o 2 opzioni:
1-USA: essere completamente dipendenti dagli Stati Uniti, una succursale dell'impero. I loro modelli sono chiusi, se vogliono te li aprono e se si svegliano male te li chiudono e sei fuori, come è successo per un periodo con Fable di Anthropic, disponibile solo agli americani.
2- CINA: i modelli sono aperti quindi puoi letteralmente farli tuoi e non ti possono mai chiudere la disponibilità dal momento che li hanno resi pubblici. Ovviamente potrebbe smettere di renderli open. Non sei dipende da loro quanto gli Stati Uniti, lo sei solo nella misura in cui se non rendono aperti i modelli successivi sempre più potenti rimani indietro, ma comunque non tagliato completamente fuori.
La nostra classe politica sarà chiamata a scegliere e non sa nemmeno di cosa stiamo parlando. Questo è un enorme rischio per il nostro futuro.
Nell'AI la dipendenza non è solo software, ma anche hardware.
Diciamo che hai modelli open di frontiera e quindi puoi gestirli senza il rischio di essere tagliato fuori. Dove li fai girare? Devi avere l'hardware adeguato. Chi sono i fornitori di questo hardware?
- Stati Uniti (NVIDIA, AMD, Intel)
- Cina (Huawei, Xiaomi etc..)
La dipendenza software e hardware ti impone al sudditanza verso queste superpotenze, è necessario un serio percorso di indipendenza e sicurezza nazionale.
L'infrastruttura tecnologica italiana corre un rischio altissimo.
Ho personalmente aperto una decina di Coordinated Vulnerability Disclosure (CVD) tramite l'Agenzia per la Cybersicurezza Nazionale (ACN / CSIRT Italia), relative a diversi produttori di software nel settore sanitario, individuando, tramite modelli e sistemi di AI progettati specificamente per questo tipo di analisi di sicurezza, centinaia di GRAVI vulnerabilità che potrebbero consentire l'accesso ai dati sensibili di milioni di cittadini.
Non sono ipotesi: sono fatti dimostrati che, in questo momento, sono obbligato a mantenere riservati sotto embargo. Non è possibile pubblicare queste ricerche per motivi di sicurezza, ma verranno rese pubbliche non appena le vulnerabilità saranno corrette.
Serve un intervento immediato, altrimenti gli incidenti saranno inevitabili.
Se un attore malevolo avesse fatto questo lavoro al posto mio, probabilmente oggi staremmo già parlando di un grave caso di cybersicurezza nazionale con furto di milioni di dati.
Senza un serio intervento questi eventi saranno inevitabili e saranno estremamente gravi.
Dopo 13 anni su Twitter/X praticamente solo in modalità read-only, credo sia arrivato il momento di iniziare a scrivere.
Non perché pensi di avere risposte definitive, ma perché vorrei confrontarmi con chi ha voglia di discutere seriamente di alcuni cambiamenti che, a mio avviso, vengono ancora largamente sottovalutati.
Siamo probabilmente all'inizio di una fase di trasformazione eccezionale. Almeno due fenomeni meritano molta più attenzione di quella che ricevono oggi.
1/ Intelligenza Artificiale
Sta diventando sempre più plausibile che l'AI avrà un impatto almeno paragonabile a quello di Internet e, potenzialmente, a quello delle grandi tecnologie general purpose della rivoluzione industriale e dell'elettrificazione.
Lavoro, produttività, istruzione, ricerca, difesa, politica e distribuzione della ricchezza potrebbero cambiare profondamente nel giro di pochi anni.
Eppure, rispetto alla portata di ciò che potrebbe accadere, il dibattito pubblico mi sembra ancora sorprendentemente limitato e spesso superficiale.
2/ Crisi del debito nel mondo occidentale
La situazione attuale mi sembra potenzialmente molto più seria della crisi del debito sovrano europeo del 2011, che aveva colpito soprattutto alcuni Paesi dell'Eurozona.
Oggi livelli elevati di debito, deficit strutturali e margini di intervento più limitati riguardano buona parte del mondo occidentale.
Anche questo potrebbe diventare uno di quegli eventi capaci di modificare profondamente gli equilibri attuali, fino a contribuire a un cambiamento dell'ordine mondiale nel senso descritto da Ray Dalio.
Marco Sala retweeted
The R9700 has an incredible price-to-performance ratio. Let’s hope it stays that way for a long time, unlike everything else.
Strix Halo + R9700 >> DGX Spark
Marco Sala retweeted
I've never read a dumber analysis. If you think 50% of hyperscaler capex goes to Nvidia chips, you clearly don't understand datacenter economics. Capex includes facilities, power, cooling, networking, servers—chips are maybe 15-20% max. Plus GOOG/META/AWS all use custom silicon.
Marco Sala retweeted
He has a tiny conflict of interest pushing this narrative,if depreciation drops to 2-3 years they're near bankruptcy, and Intrator still has plenty of shares to dump (already selling heavily). New contracts are shortening terms and adding exit clauses.CRWV is a scam for investors