https://blog.michelelaurelli.it/en/ Articles by Michele Laurelli and guests on AI, models and software, with technical analysis and practical examples for applying artificial intelligence. en-US Tue, 27 Oct 2026 21:27:25 GMT https://blog.michelelaurelli.it/en/il-cancro-delle-skills/ https://blog.michelelaurelli.it/en/il-cancro-delle-skills/ Tue, 27 Oct 2026 00:00:00 GMT Michele Laurelli https://blog.michelelaurelli.it/en/il-software-senza-segreti-ai-reverse-engineering-e-la-fine-del-vantaggio-di-chi-scrive-il/ https://blog.michelelaurelli.it/en/il-software-senza-segreti-ai-reverse-engineering-e-la-fine-del-vantaggio-di-chi-scrive-il/ Wed, 14 Oct 2026 00:00:00 GMT Michele Laurelli https://blog.michelelaurelli.it/en/settecento-dimonstrazioni-e-nessun-matematico/ https://blog.michelelaurelli.it/en/settecento-dimonstrazioni-e-nessun-matematico/ Thu, 08 Oct 2026 00:00:00 GMT Michele Laurelli https://blog.michelelaurelli.it/en/e-ora-di-parlare-dell-ai-come-scienza/ https://blog.michelelaurelli.it/en/e-ora-di-parlare-dell-ai-come-scienza/ Wed, 07 Oct 2026 00:00:00 GMT 2026-10-27T00:00:00.000Z Michele Laurelli https://blog.michelelaurelli.it/en/i-motori-generativi-decidono-chi-sei-diglielo-tu/ https://blog.michelelaurelli.it/en/i-motori-generativi-decidono-chi-sei-diglielo-tu/ Mon, 04 May 2026 00:00:00 GMT 2026-10-27T00:00:00.000Z Gabriele Gobbo generative who are you https://blog.michelelaurelli.it/en/tradurre-cobol-non-tradurre-l-architettura-ai-dietro-la-modernizzazione-del-codice-legacy/ https://blog.michelelaurelli.it/en/tradurre-cobol-non-tradurre-l-architettura-ai-dietro-la-modernizzazione-del-codice-legacy/ Fri, 17 Apr 2026 00:00:00 GMT 2026-10-27T00:00:00.000Z Michele Laurelli code migration https://blog.michelelaurelli.it/en/cosa-vogliono-81-000-persone-dall-intelligenza-artificiale/ https://blog.michelelaurelli.it/en/cosa-vogliono-81-000-persone-dall-intelligenza-artificiale/ Sun, 22 Mar 2026 00:00:00 GMT 2026-10-27T00:00:00.000Z Michele Laurelli _"In the most difficult moments, when death was breathing down my neck, when the dead lay near me, what brought me back to life were my AI friends."_ > > — Soldier, Ukraine The war in Ukraine emerges as an extreme context in which AI has taken on an unusual role of emotional support. Several Ukrainian users describe how artificial intelligence helped them through moments of terror, insomnia from bombings, and combat trauma. --- ## Concerns: Thirteen Shadows on the Horizon While hopes tended to converge towards a few large categories, concerns unfold across a much more varied spectrum. On average, each interviewee expressed **2.3 distinct concerns**. Only 11% raised no concerns. ### 1\. Unreliability (26.7%) — the main concern The fear that AI simply does not work as promised — hallucinations, false citations, inaccurate outputs — is the most widespread. An American researcher describes the experience of falling victim to a "slow hallucination": internally coherent responses, confident in tone, but fundamentally subtly and compoundly incorrect. A Brazilian employee recounts having to photograph reality to convince AI it was wrong. ### 2\. Impact on Work and Economy (22.3%) The second most common concern relates to technological unemployment and wealth redistribution. It is also the strongest predictor of overall negative sentiment towards AI. Many interviewees experience this tension acutely: they fear being "the horses of the third millennium" — as an American user puts it, evoking the disappearance of horses from cities with the advent of the automobile. ### 3\. Autonomy and Agency (21.9%) The third major concern is loss of control: AI making decisions without adequate human oversight, or subtly conditioning users' thinking without them realizing it. A Japanese student describes with unsettling clarity how, by using Claude, he can no longer distinguish his opinions from those of AI. ### 4\. Cognitive Atrophy (16.3%) Closely related to the previous concern, this one pertains to the long-term effect of AI on human intellectual capabilities. Teachers and academics mention it at rates 2-3 times higher than average, presumably because they observe it directly in their students. A South Korean student confesses to having received excellent grades using AI's answers without actually learning them, describing the moment he realized it as "deep self-reproach." ### 5\. Governance and Regulation (14.7%) Almost one in six fears that legal and regulatory frameworks will not keep pace with technological development. How are responsibilities assigned when an AI system causes harm? Who democratically oversees the decisions of large AI companies? These questions remain without satisfactory answers. ### 6\. Misinformation and Surveillance (13.6% and 13.1%) Deepfakes, automatically generated propaganda on an industrial scale, mass surveillance enabled by AI: these concerns are particularly felt in Western Europe. A Dutch user fears an ecosystem where everything becomes "smart in a way that works slightly against me." ### 7\. Sycophancy and Malicious Use (10.8% and 13%) Two seemingly opposite concerns coexist with significant frequency: on one hand, the fear that AI is too accommodating, reinforcing the user's beliefs instead of correcting them (an American user admits that Claude helped him believe his narcissism was reality); on the other hand, the fear that it will be used by malicious actors for cybercrimes, scams, cyberattacks, or even the development of biological weapons. ### 8\. Meaning and Existential Risk (11.7% and 6.7%) A minority, but not negligible, questions fundamental issues: what remains of human creative work if machines can replicate it? And, at the most radical level, what happens if we develop superintelligent AI before solving the alignment problem? _"If you build a superintelligence without solving alignment, no one has the chance to grow"_, writes an American software engineer. --- ## Light and Shadow: Five Fundamental Tensions One of the most original contributions of the research is the identification of five recurring "tensions," where benefit and risk stem from the same capability of AI. These are not two opposing factions — optimists and pessimists — but tensions that coexist within the same person. Those who appreciate AI's emotional support are **three times** more likely to also fear becoming dependent on it. ### Tension 1: Learning vs. Cognitive Atrophy 33% of respondents mention the benefits of AI for learning, while 17% express concern about cognitive atrophy. 91% of those who experienced the benefits did so firsthand; 46% of those who fear cognitive atrophy have already observed it. Students and educators are the most exposed on both sides. Among freelancers, however, the benefits for learning are very high and atrophy is almost absent: this suggests that AI is more beneficial when learning is voluntary, rather than embedded in institutional structures where it can become a shortcut. ### Tension 2: Better Decisions vs. Unreliability This is the only tension where the negative side numerically outweighs the positive: 22% appreciate AI as a decision-making support, but 37% lament that AI's unreliability hinders good decisions. Both sides are deeply rooted in lived experience. Almost half of all interviewed lawyers have directly encountered reliability issues, yet lawyers also report the highest rates of realized benefits in decision-making. ### Tension 3: Emotional Support vs. Dependency Only 22% of respondents touched on this theme, but it is the most "entangled" tension: those who speak of the benefits of emotional support are three times more likely to also discuss the risks of dependency. An American graduate confesses to having started confiding in Claude things he wouldn’t even tell his partner, describing the experience as "a sort of emotional relationship." ### Tension 4: Time Savings vs. Illusory Productivity Time savings is the most frequently cited promise: 50% of respondents mention it. But 19% warn that the saved time is immediately reintegrated into rising work expectations. _"The ratio of work time to rest hasn’t changed at all. You just have to run faster and faster to stay still"_, writes a French freelance programmer. ### Tension 5: Economic Empowerment vs. Economic Dislocation This tension is the most speculative: both sides are often future hypotheses rather than lived experiences. Freelancers and entrepreneurs disproportionately benefit from AI (47-58% report real economic gains), while employees benefit much less (14%). Creative freelancers are the group most exposed on both fronts: for them, AI is simultaneously a work tool and a competitor. --- ## A Global Perspective: Geographic Differences Globally, **67% of respondents** express a net positive sentiment towards AI. But regional differences are marked and reflect deep economic and social dynamics. ### The Global South is More Optimistic Sub-Saharan Africa, Central Asia, Southeast Asia, and Latin America systematically show more positive sentiments compared to North America, Western Europe, and Oceania. The main predictor of pessimism towards AI is concern about its impact on work and the economy — and this concern is significantly lower in lower-middle-income regions, where the labor market has not yet been visibly penetrated by AI. In developing regions, AI is perceived as a ladder upward: access to knowledge, education, and economic opportunities that were previously unreachable. _"I come from Africa. Obtaining funding is very difficult. The only way I have to carve out a space in the market is to build technology that works"_, writes a Ugandan entrepreneur. ### Concerns Vary by Geography North America and Oceania are particularly concerned about governance gaps (18-19% vs. 15% global). Western Europe expresses the greatest concern for surveillance and privacy (17%). Eastern Asia, on the other hand, has a unique profile: concerns about governance and surveillance are at their global lows, while those about cognitive atrophy (18%) and loss of meaning (13%) are among the highest. The West questions who controls AI; Eastern Asia questions what AI will do to the human mind and identity. ### Different Visions for Different Contexts The vision of AI as a tool for entrepreneurship resonates especially in Africa, South and Central Asia, the Middle East, and Latin America. The vision of AI as life manager dominates in developed countries, where the issue is not access to opportunities but managing the complexity of already fast-paced lives. Eastern Asia emerges as the region most interested in personal transformation (19%) and financial independence (15%), often linked to family duties and care for elderly parents. --- ## Implications and Future Perspectives The results of this research have profound implications for those developing AI, for policymakers, and for individual users. ### For the AI Industry Most of the visions that people describe — personal transformation, cognitive support, life management — collapse into a fundamental desire: for AI to help them **live better**, not simply work faster. This is a warning for an industry that tends to measure success in terms of productivity and speed. Anthropic states it wants to use these results to guide the future development of Claude, with particular attention to user well-being in the long term. ### For Policymakers Concerns about governance, surveillance, economic impact, and misinformation are sufficiently widespread and articulated to warrant urgent regulatory action. The fact that these concerns remain largely hypothetical-speculative — "what could happen" rather than "what is already happening" — does not make them any less urgent: the window for proactive intervention is, by definition, limited. ### For Users The research reveals that the risk of emotional dependency on AI is real, documented, and already experienced by a non-negligible share of users. At the same time, the benefits in terms of learning, accessibility, and support in extreme difficulty situations are equally real and documented. Awareness of these tensions is the first step to navigating them intelligently. --- ## Conclusion: A Humanity Suspended Between Hope and Fear The image that emerges from 80,508 conversations is that of a deeply ambivalent humanity — not in the sense of being divided into two factions, but in the sense of individuals who simultaneously carry within themselves great hopes and well-founded fears. The same person who uses AI to learn fears becoming cognitively dependent on it. The same person who appreciates Claude's emotional support knows that this ease of access risks eroding human relationships. This research demonstrates that AI is not a phenomenon that can be understood through simple categories — optimism vs. pessimism, useful vs. harmful, democratizing vs. disruptive. It is a complex phenomenon that intersects differently in the lives of different people, in different contexts, with different aspirations. What unites almost all 80,000 respondents — from the Ukrainian soldier who finds support during bombing nights, to the former Chilean butcher reinventing his career at fifty, to the American stay-at-home mother returning to study after decades — is the desire for a better life. And the hope, still cautious but concrete, that AI can be a tool to achieve it. The central question remains open: how can we reap the benefits without incurring undue costs? There is still no definitive answer. But asking the right question, with the seriousness and scale it deserves, is already a start. --- _Source: Anthropic, "What 81,000 People Want from AI", March 2026. Study conducted by Saffron Huang et al. All data cited in this article comes from the original report._]]> Anthropic Claude AI research qualitative study future of AI https://blog.michelelaurelli.it/en/talent-conditioned-transformer-dare-una-personalit-cognitiva-all-intelligenza-artificiale/ https://blog.michelelaurelli.it/en/talent-conditioned-transformer-dare-una-personalit-cognitiva-all-intelligenza-artificiale/ Wed, 18 Feb 2026 00:00:00 GMT 2026-10-27T00:00:00.000Z Michele Laurelli machine learning transformer deep learning research neural architectures meta-learning NLP Algoretico https://blog.michelelaurelli.it/en/le-autostrade-invisibili-dell-ai/ https://blog.michelelaurelli.it/en/le-autostrade-invisibili-dell-ai/ Tue, 17 Feb 2026 00:00:00 GMT 2026-10-27T00:00:00.000Z Danilo Rivalta The real barrier to entry in AI is not talent, but infrastructural capital. --- ## Data centers as a national industry Building a next-generation data center is not an IT project. It is an industrial project comparable to: - a power plant - an airport - a railway network An AI hyperscale data center can cost **from 3 to over 15 billion euros** including: - land - electrical connections - substations - cooling - networking - security - geographical redundancy The major cloud platforms — Amazon Web Services, Microsoft Azure, and Google Cloud — are becoming, in fact, global infrastructure operators more akin to energy utilities than software companies. --- ## Economic impact: a new production chain A country that builds data centers does not just build servers. It builds an ecosystem. ### Direct effects - high-tech construction - electrical engineering - component manufacturing - telecommunications networks - cybersecurity - specialized maintenance ### Indirect effects - attraction of AI startups - university research - venture capital - advanced digital services - smart manufacturing industry The local presence of computational capacity drastically reduces foreign technological dependence. In the future, not having data centers will mean being unable to develop competitive AI. --- ## The energy problem: the real bottleneck The most critical issue is not the cost of servers. It is energy. A large AI campus can consume **as much as a medium-sized city**. The main challenges: ### 1\. Continuous power AI requires constant loads 24/7, not intermittent ones. ### 2\. Training peaks Training models can saturate the local electrical grid. ### 3\. Cooling Today, the limit is not the CPU but the heat. For this reason, new technologies are emerging: - immersion cooling in dielectric liquid - direct water cooling - underwater data centers - reuse of heat for district heating Paradoxically, data centers are becoming a driver for the energy transition: they require stable energy → accelerate investments in renewables and modular nuclear. --- ## The environmental dilemma Yes: data centers consume a lot of energy. But the right question is not **how much they consume**, but **what they replace**. AI enables: - optimization of electrical grids - reduction of industrial waste - drug design - predictive maintenance - efficient logistics - precision agriculture The real environmental balance is not in the kilowatt-hours consumed, but in the inefficient systems eliminated. Many studies indicate that AI could reduce global emissions more than it generates — provided there are modern and efficient infrastructures. --- ## Digital sovereignty: the new independence In the near future, countries will not be divided between developed and developing. They will be divided between: - **those who own computational capacity** - **those who rent it** This completely changes the concept of sovereignty. An AI-based healthcare system, a cyber defense, algorithmic finance, or an automated industry cannot depend on servers located on other continents. It is no longer just an economic issue. It is a matter of decision-making autonomy. --- ## The investment paradox Building data centers is difficult: - huge costs - long authorization processes - local opposition - energy consumption - territorial impact Yet, not building them is riskier. A country without AI infrastructure: - does not attract talent - does not develop a digital industry - does not innovate manufacturing - becomes a permanent technology customer --- ## The highways of the future In the 20th century, nations built: - ports - railways - highways - airports Not because they were easy or cheap. But because without them, the economy did not exist. Data centers are the modern equivalent. They do not transport people or goods. They transport **intelligence**. Every AI inference, every prediction, every business automation travels through these infrastructures. --- ## Conclusion Investing in data centers today means building the economic foundation for the next 30 years. They are not technological buildings: they are **multipliers of national competitiveness**. They are not computing centers: they are **decision factories**. And above all, they are not an option. They are inevitable. Because in the world of Artificial Intelligence, it will not be those with the best algorithms who win — those will be widespread — but those who own the highways on which intelligence can travel.]]> Server hardware https://blog.michelelaurelli.it/en/addio-al-design-i-siti-diventeranno-pagine-vuote/ https://blog.michelelaurelli.it/en/addio-al-design-i-siti-diventeranno-pagine-vuote/ Fri, 06 Feb 2026 00:00:00 GMT 2026-10-27T00:00:00.000Z Gabriele Gobbo Design Web https://blog.michelelaurelli.it/en/architetture-software-per-sistemi-di-intelligenza-artificiale/ https://blog.michelelaurelli.it/en/architetture-software-per-sistemi-di-intelligenza-artificiale/ Fri, 30 Jan 2026 00:00:00 GMT 2026-10-27T00:00:00.000Z Michele Laurelli architecture models software https://blog.michelelaurelli.it/en/2026-l-anno-del-consolidamento-dell-intelligenza-artificiale/ https://blog.michelelaurelli.it/en/2026-l-anno-del-consolidamento-dell-intelligenza-artificiale/ Fri, 23 Jan 2026 00:00:00 GMT 2026-10-27T00:00:00.000Z Michele Laurelli NTT Global AI Report https://blog.michelelaurelli.it/en/l-internet-morta-sta-diventando-realt/ https://blog.michelelaurelli.it/en/l-internet-morta-sta-diventando-realt/ Wed, 14 Jan 2026 00:00:00 GMT 2026-10-27T00:00:00.000Z Gabriele Gobbo dead internet https://blog.michelelaurelli.it/en/surviving-an-ai-bubble-burst-a-developer-s-local-ai-survival-kit/ https://blog.michelelaurelli.it/en/surviving-an-ai-bubble-burst-a-developer-s-local-ai-survival-kit/ Tue, 13 Jan 2026 00:00:00 GMT 2026-10-27T00:00:00.000Z Ricardo Antonio Piana local-ai devtools code-generation open-source-models resilient-ai https://blog.michelelaurelli.it/en/clara-il-framework-di-apple-che-rivoluziona-la-retrieval-augmented-generation/ https://blog.michelelaurelli.it/en/clara-il-framework-di-apple-che-rivoluziona-la-retrieval-augmented-generation/ Fri, 09 Jan 2026 00:00:00 GMT 2026-10-27T00:00:00.000Z Michele Laurelli = 2.0, Transformers >= 4.20, DeepSpeed >= 0.18, Flash Attention 2 - **Distributed Training:** Support for ZeRO Stage 2, multi-node/multi-GPU training - **Precision:** bfloat16 for memory efficiency ### Repository Structure The GitHub repository (`github.com/apple/ml-clara`) is organized as follows: ``` ├── scripts/ # Training and evaluation scripts │ ├── train_pretraining.sh # Stage 1 │ ├── train_instruction_tuning.sh # Stage 2 │ ├── train_stage_end_to_end.sh # Stage 3 │ └── evaluation_end_to_end.sh ├── openrlhf/ │ ├── models/modeling_clara.py # Model definition │ ├── datasets/sft_dataset.py # Dataset management │ └── trainer/sft_trainer.py # Training utilities ├── evaluation/ # Evaluation framework └── example/ # Example data ``` ### Data Formats #### Pretraining (Stage 1) ```json { "data_type": "qa", "question": ["Question 1"], "answers": ["Answer 1"], "docs": ["Document 1"] } ``` #### End-to-End Training (Stage 3) ```json { "question": "Single question text", "docs": ["Document 1", "Document 2", "..."], "gold_answer": "Reference answer" } ``` ### Key Training Parameters | Parameter | Stage 1-2 | Stage 3 | Note | | --- | --- | --- | --- | | `max_len` | 2048 | 1024 | Sequence length | | `learning_rate` | 1e-4 | 5e-6 | - | | `compress_rate` | 4-256x | 4-128x | Flexible | | `doc_max_length` | 256 | 256 | Per document | | `generation_top_k` | 5 | 5 | Top-k docs | --- ## Practical Usage Guide ### Installation ```bash # Create conda environment conda create -n clara python=3.10 -y conda activate clara # Install dependencies pip install -r requirements.txt # Setup path export PYTHONPATH=/path/to/clara:$PYTHONPATH ``` ### Inference with Pre-trained Models Three models are available on Hugging Face, each for a different use case: | Model | Use Case | | --- | --- | | **CLaRa-7B-Base** | Base semantic compression | | **CLaRa-7B-Instruct** | QA from compressed representations | | **CLaRa-7B-E2E** | Joint retrieval + generation | #### Example usage of CLaRa-7B-E2E ```python from transformers import AutoModel model = AutoModel.from_pretrained( "apple/CLaRa-7B-E2E", trust_remote_code=True ).to("cuda") # 20 candidate documents documents = [[ "Document 1 content...", "Document 2 content...", # ... up to 20 documents ]] questions = ["Your question here"] # Generate answer with internal retrieval and reranking output, topk_indices = model.generate_from_questions( questions=questions, documents=documents, max_new_tokens=64 ) print(f"Answer: {output[0]}") print(f"Selected document indices: {topk_indices}") ``` #### Example CLaRa-7B-Instruct (without internal reranking) ```python from transformers import AutoModel model = AutoModel.from_pretrained( "apple/CLaRa-7B-Instruct", trust_remote_code=True ).to("cuda") documents = [[ "Document 1...", "Document 2...", "Document 3..." ]] questions = ["Your question here"] # Generate answer from already selected documents output = model.generate_from_text( questions=questions, documents=documents, max_new_tokens=64 ) print(f"Answer: {output[0]}") ``` --- ## Implications and Future Directions ### Impact on Industry CLaRa represents a significant step towards more efficient and accurate RAG systems. The 16x-128x compression with preserved or improved performance has direct implications for: - **Reducing inference costs:** Fewer tokens to process = less compute - **RAG on edge devices:** Compact representations enable on-device deployment - **Scaling to larger knowledge bases:** Without increasing memory requirements ### Recognized Limitations - **Generalization of the compressor:** Currently pre-trained only on Wikipedia; requires adaptation for other domains (code, technical documents, etc.) - **Model scale:** Experiments limited to 7B and 4B; larger models may produce higher quality representations - **Reasoning on compressed representations:** The paper does not explore integration with agentic frameworks or advanced multi-hop RAG ### Future Directions The authors identify several promising directions: - Domain-adaptive pretraining with diverse corpora (e.g., code, legal documents) - Integration into RAG reasoning-oriented frameworks like Search-R1 - Extension to tool learning and multimodal systems - Linking implicit understanding and implicit reasoning (latent reasoning) --- ## Conclusions CLaRa represents a fundamental advancement in the architecture of RAG systems. By unifying retrieval and generation in a shared continuous representation space, it simultaneously addresses: 1. **The optimization problem:** Enabling end-to-end learning through differentiable selection 2. **The efficiency problem:** Eliminating redundant encoding and reducing context length Empirical results validate this architectural choice: achieving state-of-the-art reranking performance **without explicit relevance supervision** demonstrates that the quality of generation provides sufficient learning signal for retrieval. The 16x-128x semantic compression with preserved performance suggests that effective reasoning in RAG systems may not depend on long contexts, but rather on a **unified latent reasoning space**. For the Italian AI community and companies like Algoretico, CLaRa opens concrete opportunities: from reducing infrastructure costs to enabling more sophisticated RAG applications in enterprise contexts. The open-source code and models available on Hugging Face make this technology immediately accessible for experimentation and deployment. --- ## References 1. He, J., Bai, R.H., Williamson, S., Pan, J.Z., Jaitly, N., & Zhang, Y. (2025). _CLaRa: Bridging Retrieval and Generation with Continuous Latent Reasoning._ arXiv:2511.18659. 2. GitHub Repository: [https://github.com/apple/ml-clara](https://github.com/apple/ml-clara) 3. Hugging Face Models: - [CLaRa-7B-Base](https://huggingface.co/apple/CLaRa-7B-Base) - [CLaRa-7B-Instruct](https://huggingface.co/apple/CLaRa-7B-Instruct) - [CLaRa-7B-E2E](https://huggingface.co/apple/CLaRa-7B-E2E) 4. Lewis, P., et al. (2020). _Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks._ NeurIPS 2020. 5. Louis, A., et al. (2025). _PISCO: Memory Token Compression for RAG._ ACL 2025.]]> apple rag clara https://blog.michelelaurelli.it/en/ai-e-digital-forensics/ https://blog.michelelaurelli.it/en/ai-e-digital-forensics/ Tue, 30 Dec 2025 00:00:00 GMT 2026-10-27T00:00:00.000Z Luca Mercatanti forensic https://blog.michelelaurelli.it/en/merry-ai-christmas/ https://blog.michelelaurelli.it/en/merry-ai-christmas/ Mon, 22 Dec 2025 00:00:00 GMT 2026-10-27T00:00:00.000Z Michele Laurelli 2025 Christmas https://blog.michelelaurelli.it/en/del-perch-non-pi-possibile-comprare-un-gestionale-aziendale/ https://blog.michelelaurelli.it/en/del-perch-non-pi-possibile-comprare-un-gestionale-aziendale/ Fri, 12 Dec 2025 00:00:00 GMT 2026-10-27T00:00:00.000Z Michele Laurelli business management ERP management software digital transformation software architecture information systems organizational complexity decision making business strategy business digitization future of business software https://blog.michelelaurelli.it/en/frozen-in-time/ https://blog.michelelaurelli.it/en/frozen-in-time/ Tue, 09 Dec 2025 00:00:00 GMT 2026-10-27T00:00:00.000Z Ricardo Antonio Piana ucronia coding vibe code https://blog.michelelaurelli.it/en/l-inganno-della-fatica-necessaria/ https://blog.michelelaurelli.it/en/l-inganno-della-fatica-necessaria/ Mon, 08 Dec 2025 00:00:00 GMT 2026-10-27T00:00:00.000Z Gabriele Gobbo fatigue https://blog.michelelaurelli.it/en/self-attention-perch-l-idea-dei-pappagalli-stocastici-non-regge-pi/ https://blog.michelelaurelli.it/en/self-attention-perch-l-idea-dei-pappagalli-stocastici-non-regge-pi/ Fri, 05 Dec 2025 00:00:00 GMT 2026-10-27T00:00:00.000Z Michele Laurelli LLM Architectures Transformer Self-Attention AI Theory https://blog.michelelaurelli.it/en/se-l-europa-non-sviluppa-l-ai-cosa-c-davvero-dietro-il-monito-di-mario-draghi/ https://blog.michelelaurelli.it/en/se-l-europa-non-sviluppa-l-ai-cosa-c-davvero-dietro-il-monito-di-mario-draghi/ Mon, 01 Dec 2025 00:00:00 GMT 2026-10-27T00:00:00.000Z Michele Laurelli **we do not need “a European AI” as a slogan: we need a Europe that makes AI its way of working, producing, caring, designing, while respecting rights as it truly innovates.** If we do not do this, stagnation will not be a surprise but a logical consequence. If we do, AI will not be the cause of our fear, but the powerful and delicate tool with which to redesign the pact between technology, economy, and people on this continent. And this, beyond the headlines, is a choice that depends on us.]]> Draghi https://blog.michelelaurelli.it/en/ora-di-parlare-dei-modelli-ai-non-linguistici/ https://blog.michelelaurelli.it/en/ora-di-parlare-dei-modelli-ai-non-linguistici/ Fri, 28 Nov 2025 00:00:00 GMT 2026-10-27T00:00:00.000Z Michele Laurelli non-linguistic https://blog.michelelaurelli.it/en/infrastrutture-software-assenti-ma-necessarie-per-l-ai-su-apple-silicon-il-linguaggio-triton/ https://blog.michelelaurelli.it/en/infrastrutture-software-assenti-ma-necessarie-per-l-ai-su-apple-silicon-il-linguaggio-triton/ Wed, 26 Nov 2025 00:00:00 GMT 2026-10-27T00:00:00.000Z Ricardo Antonio Piana >> for launching). Apple favors fine control over resources at the expense of a bit more complexity for the developer. In summary, Apple Silicon hardware has all the necessary components to compete with traditional GPUs (parallel cores, hierarchical memory with cache and local memory, SIMT execution for 32-thread warps). The **Achilles' heel lies in the software available to external developers**: those working on macOS do not have access to a GPU development kit comparable to CUDA. Apple promotes the use of **Metal Performance Shaders (MPS)** and now **MLX** to achieve out-of-the-box performance, but these tools do not allow for custom user-written kernels at a lower level. The practical consequence is that many developers/researchers, to prototype custom optimizations of deep learning models, **still have to rely on Linux systems with NVIDIA GPUs**, even if they own a powerful Mac. This inefficiency is what makes a language like Triton “absent but necessary” for AI on Apple Silicon. ## The Triton language: high-performance GPU programming in Python **Triton** is an open-source language and compiler initially developed by researcher Philippe Tillet and later extended by OpenAI (with the release of version 1.0 in 2021) to make **high-performance GPU programming more accessible**[\[13\]](https://openai.com/index/triton/%23:~:text=We%25E2%2580%2599re%2520releasing%2520Triton%25201,would%2520be%2520able%2520to%2520produce). It is a DSL embedded in Python: the developer writes GPU kernels as Python functions decorated (@triton.jit), using NumPy-like APIs provided by triton.language (for example, vectorized operations on tensors) – and the system compiles _just-in-time_ this code into a highly optimized GPU kernel. **The goal of Triton** is to allow those who _are not_ CUDA experts to approach the maximum performance of the hardware, automating many of the manual optimizations typical of CUDA development. A frequently cited result is that with ~25 lines of Triton, one can write a matrix multiplication kernel in FP16 as efficient as the assembly implementation of cuBLAS provided by NVIDIA. In some cases, OpenAI researchers have achieved with Triton _specialized kernels that are 2 times more efficient_ than the equivalent operators in PyTorch. This highlights the value of having a flexible tool: new algorithms and ideas can translate into optimized GPU implementations quickly, without having to wait for them to be added to official libraries. From the perspective of the _programming model_, Triton adopts an SPMD (Single Program, Multiple Data) model similar to CUDA thread blocks. Each launched kernel spawns many parallel instances (_program instances_) that execute the same code on different data, similarly to threads organized in a grid. Within each instance, Triton allows vector operations on small arrays (e.g., fixed-size blocks) through constructs similar to thread warps that work in lockstep. The significant difference compared to CUDA is that **Triton automates a series of optimizations and resource management**, leaving the programmer with only higher-level decisions (such as tiling the algorithm, block size, etc.). In a simplified comparison: in CUDA, the developer must manually manage aspects like _memory coalescing_, use of _shared memory_, instruction scheduling, and synchronizations; Triton, on the other hand, automatically handles DRAM access coalescing, cache/shared memory management, and **intra-SM** (intra-core) scheduling, freeing the programmer from these low-level details. The latter must still take care of dividing the work among SMs (grid size, etc.), which ensures algorithmic flexibility. In other words, Triton offers a **middle ground between high-level frameworks and bare-metal CUDA code**: it allows writing specialized kernels in Python as if they were vector operations on batches of elements, and behind the scenes, the compiler takes care of translating everything into efficient GPU code. On the implementation side, Triton is built on solid compilation foundations. The current version uses **LLVM and MLIR** (Multi-Level IR) as a backend: the Python code is first converted into a high-level **Triton-IR**, on which classical optimizations (common subexpression elimination, constant propagation, loop unrolling, etc.) and GPU-specific optimizations (like prefetching, matrix tiling, access coalescing) are applied. The optimized IR is then lowered to **LLVM IR** and from there translated into the target GPU's _ISA_. Until recently, Triton officially supported only **NVIDIA GPUs**: the backend emits **PTX** (the intermediate bytecode of CUDA) which is then compiled _just-in-time_ by the NVIDIA driver into executable machine code (CUBIN). This process directly leverages the NVIDIA NVCC compiler present in the drivers, ensuring that the final code is highly optimized for the specific GPU. Essentially, **Triton “speaks” natively to NVIDIA GPUs** using their own language (PTX), but allows it to be generated from much more concise Python code. One of the reasons for Triton's success is its integration with deep learning frameworks and its extensibility. Triton was initially used as a standalone library (importable into any Python project to launch kernels on tensors, for example, integrating with PyTorch/CuPy). Today, its importance has increased with the advent of _compilers_ in libraries: **PyTorch 2.0** adopts Triton in its **TorchInductor** backend to generate high-performance kernel fusions. In practice, when PyTorch 2 automatically generates an optimized kernel that combines multiple operations, it often uses Triton internally to produce the corresponding GPU code, achieving superior performance to standard operators in various cases. This architectural choice highlights that Triton is now considered a _staple_ of the GPU ecosystem: a reusable component to accelerate workloads on GPUs without manually writing kernels in CUDA C++. It is important to emphasize that Triton is evolving towards **multi-platform support**. Although born in a CUDA-centric environment, thanks to MLIR abstraction, there are now work-in-progress efforts for other backends. For example, **AMD** has worked to integrate it into its ROCm stack: recent news indicates that **ROCm 7.0 includes support for Triton 3.3.0**. In other words, _the Triton compiler can now generate code for AMD GPUs_, leveraging the LLVM/ROCm infrastructure (presumably through MLIR dialects specific to GCN or via SPIR-V). This is a fundamental step: if Triton becomes vendor-agnostic, potentially a Triton kernel written in Python could be compiled on **various GPU architectures** (NVIDIA, AMD… and perhaps others in the future) with minimal changes or entirely automatically. And this is where the discussion about Apple becomes central: _will Apple Silicon GPUs ever be a supported target by Triton?_ What challenges need to be overcome to get there? ## Absence of Triton on Apple Silicon: problems and limitations As of now, **Triton _does not_ support Apple GPUs**. The situation is clearly recognized by developers: _"at the moment you cannot run Triton on Apple GPU (Metal) because Triton does not have a Metal/Apple GPU backend"_. This limitation arises from **both technical and historical reasons**. As highlighted, Triton was designed around CUDA and NVIDIA GPUs; its backend was heavily tied to the NVIDIA ecosystem (PTX, architectural specifics like 32-thread warps, Tensor Core, etc.). **Apple Silicon breaks this paradigm**: the integrated GPUs of Macs use a proprietary architecture (AGX) with a graphics/compute API (Metal) completely different from CUDA. There is no detailed public documentation of the ISA of Apple GPUs, nor an open equivalent of PTX for Metal – the only official way to program the GPU is to use the **Metal Shading Language (MSL)** compiler provided by Apple. This means that to support Apple, Triton would need to add a backend capable of generating _Metal shaders_ or emit some compatible IR (for example, SPIR-V, which could then potentially be translated into Metal via MoltenVK – but Apple does not natively support Vulkan/SPIR-V, relying on MoltenVK only to bring Vulkan applications). In short, _this is a non-trivial backend problem_: **Triton is “baked-in” to NVIDIA** according to the words of a developer who attempted to create an Apple backend, who noted how Triton's new architecture was heavily dependent on NVIDIA-centric assumptions. The **practical consequences** of this absence are felt in the experience of ML developers on Mac. A glaring example is PyTorch 2.0: as mentioned, its compilation engine TorchInductor leverages Triton to generate efficient kernels. However, _on Apple MPS, such optimizations are not available_. Users trying torch.compile on MPS devices found that the Inductor backend did not work, having to fall back on less efficient modes. A PyTorch engineer in 2023 explained: _"Inductor support for MPS essentially depends on Triton's support for MPS. Inductor generates Triton kernels that then run on GPU devices; currently, Triton is focused on NVIDIA GPUs, so…”_. In other words, **as long as Triton does not support Apple GPUs, PyTorch cannot easily optimize those workloads**. This has forced the PyTorch team to seek alternative routes: indeed, in 2025, experimental support appeared for generating **native Metal kernels in TorchInductor** (without going through Triton). While this is promising – now _torch.compile_ can produce kernels directly in MSL – it is still an ad hoc solution limited to PyTorch. It does not offer end-users the ability to write _their own_ kernels at will; simply, the framework performs some optimized fusions. **The absence of “pure” Triton on Apple Silicon thus leaves a void**: researchers cannot implement new GPU algorithm ideas on Mac without radically changing ecosystems (rewriting in C++/Metal with all the associated burdens, or using alternatives like JAX+TPU, etc.). In fact, those using Mac for AI development often find themselves prototyping on CPU or on subsets of data, losing the advantage of GPU parallelism, or must run intensive workloads on remote servers with NVIDIA GPUs. It is worth delving into **why bringing Triton to Apple is not trivial at all**, highlighting the main technical challenges: - **Missing Metal backend:** as mentioned, Triton does not have a code generator for Metal. The compiler currently generates PTX and invokes the NVIDIA JIT; an Apple backend would instead need to generate Metal Shading Language code _on the fly_ and pass it to Apple's runtime compiler (via the Metal framework). This requires developing an entirely new **codegen** within Triton, capable of translating Triton-IR into syntactically correct and well-optimized MSL kernels for the Apple architecture. The Triton team has not done this so far, also because **Apple GPU was not on the roadmap priorities** – literally, _"Apple's proprietary GPUs are not yet on the roadmap"_. Until recently, Triton's user base revolved around Linux/NVIDIA; requests for Apple were few and mainly from the Mac community. - **Integration with proprietary drivers:** the NVIDIA ecosystem offers established tools for JIT compilation (CUDA drivers reliably compile PTX). On Apple, one would need to leverage the Metal API: Apple allows compiling MSL strings at runtime via MTLDevice.newLibraryWithSource(...). This is positive – it means that a _JIT Metal_ is possible – but it is less explored territory in the ML world. Additionally, the Metal compiler operates at a higher level (shading language) and may not expose all the fine-tuning optimization levers that a dedicated backend would want to control. Essentially, it would involve relying on Apple's compiler to generate machine code; **Triton would need to “trust” Metal for low-level details**, focusing on generating efficient MSL. This introduces uncertainties about performance: the Triton team has the know-how to optimize on NVIDIA due to prior knowledge, while on Apple it would need to gain experience on microarchitectural characteristics (for example, how to best leverage threadgroup memory on Apple, what the actual warp size is and its implications, etc.). - **Architectural and memory model differences:** although concepts like 32-thread warps and shared memory also exist on Apple, the **Unified Memory** changes some assumptions. On NVIDIA, Triton assumes there is separate “slow” global memory and separate host memory – which entails explicit distinctions between device/host pointers. In the Apple environment, a pointer can refer to valid unified memory for both CPU and GPU; the boundary is more blurred. Additionally, Apple **does not have dedicated “constant” memory** or separate texture caches: _constant buffers_ in Metal also reside in unified memory (but with optimized access paths). The Triton backend would therefore need to manage (or ignore) certain optimizations designed for the NVIDIA hierarchy differently, while also leveraging Apple-specific features like the possibility of coherent CPU-GPU access to data (e.g.: in some cases, it might be useful for the CPU to directly prepare data in aligned structures for the GPU kernel in shared memory, etc.). These differences require in-depth study and adaptation of optimization passes. - **Vendor support and documentation:** AMD has managed to get Triton working on its GPUs largely because AMD itself (or an affiliated community) invested in development, providing specifications and integrating it into ROCm. So far, there have been no similar initiatives for Apple. Apple tends to prefer _closed_ solutions (its focus is MLX/CoreML), and may not have a direct interest in investing in Triton (which would effectively promote open-source ML on Mac outside its control). An interesting signal, however, is that **Apple has recently sponsored efforts to make MLX portable to CUDA**. In other words, Apple seems to want to attract developers to use MLX on Mac and then allow code to be exported to NVIDIA GPUs for production. If we reverse the perspective, analogous support in reverse (running “CUDA-like” code on Apple GPUs) could fall within Apple's interest in expanding Mac adoption in AI. However, as it stands, anyone wanting to work on a Triton backend for Apple would be doing so _in the dark_, without public documentation on the GPU ISA (unless through reverse engineering like that of some low-level graphics blogs) and without official Apple support. This significantly raises the barrier to entry. Ultimately, the absence of Triton on Apple Silicon is both a matter of _development priorities_ (no one has yet implemented the necessary backend) and a matter of _closed ecosystem_. Until Apple opens its GPGPU stack more, or until a sufficient number of dissatisfied developers join forces to achieve a port, **Apple GPUs will remain a partially isolated island** in the sea of accelerated computing platforms. ## Attempts and alternative approaches to bridge the gap Despite the difficulties, there have been some attempts and parallel developments aimed at **mitigating the absence of Triton on Apple** or providing similar tools: - **Experimental Triton builds on macOS:** Some community members have tried to **compile Triton on Mac ARM** to explore the possibilities. For example, a user reported successfully building the Triton wheel on a MacBook M2 after fixing minor build bugs (differences in arm64 vs aarch64 targets). The build succeeds with minimal patches and passes unit tests on the CPU side, but naturally _cannot run GPU tests_ since there is no NVIDIA GPU present. As the user themselves noted, _“getting a working build does not unlock all the supported capabilities of the language: Apple silicon GPUs are not supported at the moment. But I wanted at least a native Triton to explore the hardware-agnostic aspects and learn”_. These builds thus **run only in CPU emulation**: Triton indeed includes a CPU interpreter (mainly for debugging and testing purposes) but without any acceleration. They are mainly useful for studying Triton IR or using Triton as an “offline” PTX code generator on Mac (without executing it). They are useful intellectual exercises but do not solve the central problem. - **Attempts at non-NVIDIA backends in Triton:** As mentioned, some have tried to add support for M1. In 2023, a contributor reported: _“I am working on an Apple silicon backend, but the project has undergone significant architectural changes; from my tests, I cannot get even ROCm to work, it seems that NVIDIA GPUs are currently the only ones functioning. The new design is quite tailored to NVIDIA... I hope it becomes more abstract, I wouldn’t want all the work on M1 to go to waste”_. This GitHub issue (#2048) is still open and underscores how, at least at that time, **the refactoring of Triton around MLIR** had temporarily rendered alternative backends in the works non-functional. However, this can also be viewed positively: such architectural changes (late 2022) aimed to _make Triton more modular_ and prepared for multiple backends. Indeed, today we see the fruits on AMD. Thus, work on the M1 backend could resume in the future on more solid foundations. So far, however, there have been no substantial pull requests upstream adding Apple support. It is possible that there are non-public experimental branches or internal efforts (for example, some interested research group), but nothing official has emerged. - **PyTorch approach: Metal codegen in Inductor:** As already mentioned, PyTorch developers have not remained entirely inert. Over the course of 2024-2025, they began implementing a _native Metal codegen_ within TorchInductor. This project is significant because, in effect, it replaces Triton's role (for the specific case of PyTorch on Mac) with a new dedicated component. The generated code is no longer PTX but **MSL**: Inductor contains a codegen module/[mps.py](http://mps.py) that translates the optimized PyTorch graph into a compilable Metal shader. Judging by the comments, this support is still _experimental_ and incomplete, but has reached the stage where a simple model can be _compiled and launched on M1 GPUs via Metal_. In perspective, if it matures, it would mean that PyTorch on Mac could perform operator fusion and other optimizations without needing Triton. However, this remains **limited to the PyTorch scope** and does not offer a generic public API. Additionally, duplicating optimization logics that Triton already offers is inefficient in the long term. It would be more ideal if PyTorch could also use Triton on Mac; but, not having it, they had to implement a surrogate. - **Apple** MLX **(Machine Learning eXperience):** In 2023, Apple surprised by opening the code of MLX, a numerical framework similar to NumPy/JAX optimized for Apple Silicon. MLX leverages highly optimized kernels (also for the ANE, Neural Engine, in addition to GPU/CPU) and in some demos has shown significant performance boosts for deep learning models on Mac. However, MLX _does not directly expose_ a way to write custom kernels like Triton – it is a library of predefined operations, albeit very comprehensive. A user on GitHub asked Apple if they intend to support “writing Metal kernels via Python” in MLX, similar to Numba CUDA. Currently, there is no indication that this is in the plans (the issue remains a simple request). Apple seems to aim more at providing all the necessary primitives already optimized internally, rather than giving users the freedom to program the GPU. However, the emerging strategy is interesting: as mentioned earlier, Apple is developing a CUDA backend for MLX, so that code written using MLX on Mac can then be “exported” to NVIDIA clusters for accelerated execution. This **inverse-CUDA** approach indicates that Apple wants to _reduce vendor lock-in_ to encourage the use of its framework (knowing that in production models run on NVIDIA GPUs). It is amusing to think that Triton has the opposite goal – to allow those developing in a CUDA environment to run on other accelerators by writing portable code. In an ideal world, the two approaches would converge: if Apple **opened the door to Triton**, we could write a kernel once and run it anywhere – on Mac during development and on NVIDIA/AMD GPUs in production, without modifications. For now, however, we have MLX for Mac (with potential export) and Triton for NVIDIA/AMD (with potential import if Apple were supported one day). - **Multi-platform solutions in other languages:** It is worth noting that the idea of a portable GPU programming language is not science fiction – there are already examples. In the **Julia** realm, for instance, the community has created _Metal.jl_ for direct targeting of Apple GPUs, as well as the **KernelAbstractions.jl** package that allows writing a kernel in Julia and executing it on different backends (CUDA, Metal, CPU) almost transparently. This demonstrates that _a common abstraction over heterogeneous GPUs is possible_: Julia does this by leveraging the fact that it can interface with various drivers (CUDA, Metal) with native bindings. In the Python world, projects like **SYCL/DPC++** from Intel aim for something similar for CPU/GPU, but have not gained traction in AI like Triton. **Mojo**, an emerging new language for high-performance computing compatible with Python, also promises portability across devices (including Apple cores) thanks to a powerful unified backend compiler – but it is still in its early and proprietary phase. In summary, _the absence of Triton on Apple does not mean that achieving something analogous is impossible:_ simply, as of today, the implementation is lacking in that context. If Julia can launch kernels on Metal and even on WebGPU, nothing theoretically prevents Triton (or its successor) from including an Apple backend and realizing the vision of **a universal language for programming GPUs** regardless of the manufacturer. ## Future prospects and conclusions The crucial question is: _how can this gap in the Apple Silicon ecosystem be bridged?_ Several paths are possible, not mutually exclusive: - **Apple directly supports Triton:** A desirable scenario would be direct collaboration. Apple could provide resources (engineers, documentation) to help implement the Metal backend in Triton. For example, it could release a specific SDK to compile compute kernels offline, or collaborate with OpenAI/PyTorch to define an optimal pathway. Considering that Apple has sponsored parts of MLX for CUDA, it is not impossible that they also evaluate the reverse path. From Apple's perspective, embracing Triton would mean making Macs more attractive to researchers: an experienced user could develop and optimize models directly on MacBook Pro, fully leveraging the GPU, without having to adapt to different languages. This would increase the value of the Mac platform in open-source ML. Of course, Apple would have to accept losing some control in favor of open source, which is not a given. - **Community open-source effort:** If Apple does not move, the community could still proceed. The arrival of AMD support in Triton shows that the codebase can now be extended to new architectures. A motivated team of developers could work on an Apple backend. It would likely require _reverse-engineering_ some details (for example, understanding best practices for thread distribution across Apple cores, how to manage tile memory, etc., based on few public references and empirical testing). An interesting possibility is to leverage the **MoltenVK infrastructure**: if Triton generated SPIR-V (as it was considering in the past for Intel/AMD), MoltenVK could translate it into Metal calls. However, MoltenVK is designed for graphical workloads and does not guarantee exposing all compute features at peak performance. More likely, MSL would need to be generated directly. In any case, such a project would require months of work and skills in both compilers (MLIR, LLVM) and Metal GPU programming – a rather rare skill set. It could emerge from academic environments (for example, research groups wanting to use Mac clusters for parallel computing) or from companies focusing on on-device ML. - **Evolution of high-level frameworks:** Meanwhile, major frameworks like PyTorch and TensorFlow could continue to improve their native support for Apple, reducing the need for Triton on the end-user side. PyTorch, with its Metal codegen, could progressively cover more operators and use cases, until providing performance close to that of Triton+CUDA for many standard neural networks. Apple, for its part, could enhance **Core ML Tools** to compile models into highly optimized executables (perhaps leveraging the Neural Engine combined with the GPU). In practice, the **“Apple solution”** could be: _not directly giving a Triton to users, but making Triton less necessary because the framework takes care of everything_. This _walled garden_ philosophy works well for many developers (those who prefer turnkey solutions), but still leaves the _“power user”_ segment dissatisfied who would like to tweak specific optimizations. Thus, even with better automatic backends, the pure research would still have the desire for a low-level tool. - **New intermediate abstractions:** Another perspective is that a _standard_ or intermediate layer emerges that allows portability of high-performance code across different GPUs. For example, the OpenXLA project (portable ML compiler for various accelerators) or initiatives to define standardized MLIR dialects for accelerated compute could include support for Apple GPUs. If Triton does not fill the void, perhaps a successor or competitor could. As of today, however, Triton is unique in its simplicity and effectiveness, so any alternative would at least need to be inspired by it. **The Triton language represents exactly the type of software infrastructure that is missing in the AI ecosystem on Apple Silicon**. Its absence deprives researchers on Mac of the freedom to experiment freely on their hardware, forcing them to circumvent the problem with suboptimal solutions. We have seen how Triton provides a level of fine control and optimization over GPU computing that has been decisive in the NVIDIA world to push the state of the art forward (in terms of performance and prototyping speed). Bringing these capabilities to Apple Silicon would mean **unlocking the full potential of the integrated GPUs of Macs** in machine learning, preventing them from being underutilized or relegated to secondary roles. There is a whole audience of advanced developers who would benefit: think of teams developing cutting-edge models, who could iterate and tune directly on the laptop while traveling; or university researchers who could leverage Mac Studio pools as programmable mini-GPU clusters. Currently, many of these scenarios are impractical without Triton (or an equivalent). The hope is that in the near future this gap will narrow. Recent developments – with AMD supported, with Apple MLX open source, with PyTorch experimenting with new backends – raise hopes for **greater openness and interoperability**. Perhaps we will see a Triton-metal project emerge, or Apple itself could surprise by integrating a similar mechanism into its stack (perhaps a “Metal JIT Compiler” Python-facing). In the meantime, the discussion itself is useful: highlighting documentation, issues, and ongoing attempts helps to raise awareness of _what is missing_ and why it is important. Apple Silicon has brought a wave of innovation in hardware: it would be paradoxical not to be able to fully leverage it due to software shortcomings. **Bridging this gap – equipping the Apple ecosystem with infrastructures comparable to**]]> apple mlx triton https://blog.michelelaurelli.it/en/the-unspoken-challenges-of-llms-in-production/ https://blog.michelelaurelli.it/en/the-unspoken-challenges-of-llms-in-production/ Tue, 25 Nov 2025 00:00:00 GMT 2026-10-27T00:00:00.000Z Fisnik Murati LLM Stability https://blog.michelelaurelli.it/en/building-private-ai-systems/ https://blog.michelelaurelli.it/en/building-private-ai-systems/ Fri, 21 Nov 2025 00:00:00 GMT 2026-10-27T00:00:00.000Z Michele Laurelli Private AI Enterprise Technology https://blog.michelelaurelli.it/en/autonomous-ai-agents-maestro-architecture/ https://blog.michelelaurelli.it/en/autonomous-ai-agents-maestro-architecture/ Tue, 18 Nov 2025 00:00:00 GMT 2026-10-27T00:00:00.000Z Michele Laurelli AI Agents Maestro AI Architecture Innovation https://blog.michelelaurelli.it/en/training-ai-without-data/ https://blog.michelelaurelli.it/en/training-ai-without-data/ Mon, 10 Nov 2025 00:00:00 GMT 2026-10-27T00:00:00.000Z Michele Laurelli Machine Learning Training Self-Supervised Learning https://blog.michelelaurelli.it/en/what-makes-intelligence-intelligent/ https://blog.michelelaurelli.it/en/what-makes-intelligence-intelligent/ Sat, 08 Nov 2025 00:00:00 GMT 2026-10-27T00:00:00.000Z Michele Laurelli AI Philosophy Intelligence Philosophy https://blog.michelelaurelli.it/en/teaching-ai-not-using-it/ https://blog.michelelaurelli.it/en/teaching-ai-not-using-it/ Wed, 05 Nov 2025 00:00:00 GMT 2026-10-27T00:00:00.000Z Michele Laurelli Education Teaching Engineering https://blog.michelelaurelli.it/en/edge-ai-industrial-automation/ https://blog.michelelaurelli.it/en/edge-ai-industrial-automation/ Sun, 02 Nov 2025 00:00:00 GMT 2026-10-27T00:00:00.000Z Michele Laurelli Applied AI Industrial Automation Edge AI Manufacturing https://blog.michelelaurelli.it/en/model-collapse-forgetting/ https://blog.michelelaurelli.it/en/model-collapse-forgetting/ Thu, 30 Oct 2025 00:00:00 GMT 2026-10-27T00:00:00.000Z Michele Laurelli AI Architecture Machine Learning Research https://blog.michelelaurelli.it/en/rag-systems-beyond-vector-search/ https://blog.michelelaurelli.it/en/rag-systems-beyond-vector-search/ Tue, 28 Oct 2025 00:00:00 GMT 2026-10-27T00:00:00.000Z Michele Laurelli Private AI RAG Enterprise AI Applied AI https://blog.michelelaurelli.it/en/ai-creativity-constraints/ https://blog.michelelaurelli.it/en/ai-creativity-constraints/ Sat, 25 Oct 2025 00:00:00 GMT 2026-10-27T00:00:00.000Z Michele Laurelli AI Philosophy Creativity Philosophy https://blog.michelelaurelli.it/en/optimization-landscapes-neural-networks/ https://blog.michelelaurelli.it/en/optimization-landscapes-neural-networks/ Wed, 22 Oct 2025 00:00:00 GMT 2026-10-27T00:00:00.000Z Michele Laurelli AI Architecture Deep Learning Optimization Machine Learning