Watt oder Geldbörsen? Preisleistung und Softwarereichweite im AI Accelerator M&A

Einführung

AI Beschleuniger konkurrieren in den Bereichen Siliziumarchitektur, Speicher, Netzwerk, Paketierung, Systeme, Compiler, Bibliotheken, Frameworks, Orchestrierung und Entwicklerunterstützung. Öffentliche Einreichungen beschreiben den Wettbewerb auf der Grundlage von Leistung, Energieeffizienz, Integration, Benutzerfreundlichkeit, Arbeitslastoptimierung, Software-Ökosystemen, Roadmaps und Angebot [6-16]. Die Benchmark-Regeln von MLCommons zeigen, warum für den Vergleich definierte Modelle, Szenarien, Genauigkeitseinschränkungen, Systembeschreibungen und Verfügbarkeitsstatus erforderlich sind [1-5]. Eine einzelne Spitzenspezifikation kann dieses Betriebssystem nicht erfassen.

Das Transaktionsproblem ist daher wirtschaftlicher und technischer Natur. Ein Käufer muss wissen, welche Workloads das Ziel mit welcher Latenz und welchem ​​Durchsatz, mit welcher Genauigkeit, Leistung, Speicher und technischem Aufwand ausführen kann und ob diese Ergebnisse von Kunden reproduziert werden können. Es muss auch wissen, ob der Software-Stack neue Modelle unterstützt, ob Kunden von etablierten Plattformen migrieren können, ob Bereitstellungen über Cluster hinweg skalierbar sind und ob das Unternehmen seine Roadmap trotz Angebots- und Kapitalbeschränkungen umsetzen kann.

Dieses Dokument richtet sich an strategische Käufer, Private-Equity-Investoren, Unternehmensentwicklungsteams, Gründer, Kreditgeber und Investitionsausschüsse. Es bietet ein System für Sorgfalt, Bewertung, Geschäftsbedingungen und Integration. Es wird keine technische, rechtliche, steuerliche, buchhalterische, regulatorische oder Anlageberatung angeboten. Jede Transaktion erfordert eine aktuelle Fachprüfung von Produkten, Verträgen, Benchmarks, Quellcode, geistigem Eigentum, Liefervereinbarungen, Sicherheit, Exportkontrollen und Kundennachweisen.

1 Definieren Sie den Akquisitionsumfang, bevor Sie die Plattform bepreisen

Ein Beschleunigerziel kann Prozessorarchitektur, Chiplets, Speicherschnittstellen, Platinen, Systeme, Compilertechnologie, Kernel, Laufzeitsoftware, Modellserver-Tools oder vertikale Anwendungen besitzen. Die juristische Person darf nur einen Teil des vom Kunden genutzten Produkts kontrollieren. Der Käufer sollte das gesamte System abbilden und gleichzeitig die Vermögenswerte und Verpflichtungen identifizieren, die beim Abschluss übertragen werden.

Die Asset Map sollte Patente, Designdateien, Verifizierungsumgebungen, Firmware, Compiler, Bibliotheken, Modellintegrationen, Benchmark-Skripte, Telemetrie, Kundenverträge, Cloud-Images, Liefervereinbarungen und geschulte Teams verbinden. Jeder Vermögenswert sollte einen Eigentümer, eine Revision, eine Abhängigkeit und einen Nutzungsnachweis haben. Eine Leistungsdemonstration kann Potenzial zeigen. Es sollte sich von einer reproduzierbaren Kundenbereitstellung mit vertraglich vereinbarter Wirtschaftlichkeit unterscheiden.

Der Akquisitionsumfang sollte auch Produkte von Dienstleistungen unterscheiden. Technische Unterstützung, Modellkonvertierung, Kernel-Optimierung und Bereitstellungsunterstützung können die Einführung beschleunigen und gleichzeitig Softwarelücken verbergen. Einnahmen, die auf maßgeschneidertem Engineering basieren, haben eine andere Dauerhaftigkeit und Marge als Einnahmen, die über eine stabile Plattform generiert werden. Das Modell sollte die Arbeitskräfte, Werkzeuge und kundenspezifischen Arbeiten identifizieren, die für jeden Materialeinsatz erforderlich sind.

Vorgeschlagene Sorgfaltsstruktur; Technische Ansprüche sollten mit kontrollierten Repositories und Kundendatensätzen abgeglichen werden.

2 Benchmarken Sie Kunden-Workloads anstelle von Spitzenspezifikationen

Spitzenoperationen pro Sekunde beschreiben eine theoretische Rate unter definierten Präzisionen und Bedingungen. Der Kundennutzen hängt von der Arbeitslast, dem Modell, der Stapelgröße, der Sequenzlänge, dem Genauigkeitsziel, den Latenzanforderungen, der Parallelität, dem Speicherbedarf und der Softwarekonfiguration ab. Ein Benchmark sollte daher als kontrolliertes Experiment und nicht als universelle Aussage über den Produktwert betrachtet werden.

MLCommons unterscheidet Systemtypen, Verfügbarkeitskategorien, Benchmark-Modelle und Bereitstellungsszenarien [1-5]. In der Dokumentation werden Genauigkeitsvalidierung, Latenzverfolgung, Lastgenerierung und Ergebnisüberprüfung beschrieben. Diese Kontrollen bieten ein nützliches Sorgfaltsmuster. Der Käufer sollte die vollständige Systembeschreibung, den Benchmark-Code, die Compiler-Flags, die Modellversion, die Daten, die Leistungsgrenze, die Laufprotokolle und die Ergebnisprüfungen für jeden beanspruchten Vorteil aufbewahren.

Der Testplan sollte repräsentative Kunden-Workloads umfassen. Schulung, Batch-Inferenz, interaktive Inferenz, Abruf, Empfehlung, Vision und wissenschaftliches Rechnen können unterschiedliche Ressourcen beanspruchen. Die Leistung kann sich je nach Modellgröße, Sparsity, Präzision, Speicherbandbreite, Kommunikationsmuster und angefordertem Servicelevel ändern. Ein Ziel, das eine Arbeitslast anführt, kann kommerziell wertvoll bleiben, aber die Bewertung sollte sich an der relevanten adressierbaren Arbeitslast orientieren und nicht auf den gesamten AI-Markt extrapoliert werden.

Die Reproduzierbarkeit von Benchmarks ist eine Governance-Frage. Der Käufer sollte wesentliche Ansprüche an kontrollierten Systemen erneut prüfen, herstelleroptimierte und portable Implementierungen vergleichen und die Empfindlichkeit gegenüber Softwareversionen testen. Es sollte Aufwärmen, Caching, Quantisierung, Stapelverarbeitung und ausgeschlossene Fehler dokumentieren. Die Ergebnisse sollten als Bereich mit den für ihre Reproduktion erforderlichen Bedingungen dargestellt werden.

Die Benchmark-Herkunft sollte sich auf die zugrunde liegenden Modelle und Daten erstrecken. Das Prüfungsteam sollte aufzeichnen, ob die Gewichte öffentlich, lizenziert oder vom Kunden kontrolliert sind; ob das Modell geändert wurde; welche Genauigkeits- oder Qualitätstests angewendet wurden; und ob Vorverarbeitungs- oder Nachverarbeitungsarbeiten im gemessenen Intervall enthalten sind. Es sollte Container-Images, Abhängigkeitsmanifeste, Firmware, Treiber, Compiler-Versionen und Maschinenkonfigurationen enthalten. Ein Ergebnis, das nach einem routinemäßigen Software-Update nicht wiederhergestellt werden kann, ist ein schwacher Transaktionsnachweis. Wo sinnvoll, sollte der Käufer auch eine neutrale Umsetzung testen. Vom Anbieter abgestimmter Code kann die erreichbare Leistung der Plattform aufzeigen, während eine portable Implementierung den dafür erforderlichen technischen Aufwand aufzeigen kann. Beide Ansichten sind wichtig, da die Kundenökonomie vom Weg von der normalen Bereitstellung zur optimierten Produktion abhängt.

3 Rekonstruieren Sie die Leistung unter Last und im Laufe der Zeit

AI Serviersysteme arbeiten kurvenübergreifend. Eine hohe Parallelität kann den Gesamtdurchsatz verbessern und gleichzeitig die Latenz pro Benutzer erhöhen. Eine geringe Latenz erfordert möglicherweise eine nicht ausgelastete Kapazität. Lange Eingabeaufforderungen, große Modelle, Abrufschritte und variable Ausgaben können das Gleichgewicht verändern. MLCommons Endpoints beschreibt die Messung von Durchsatz, Interaktivität, Zeit bis zum ersten Token und Parallelität ^[3]. Ein Transaktionsmodell sollte diese Kurve mit dem Kundenserviceniveau und dem realisierten Preis verknüpfen.

Das Management geht davon aus, dass ein beispielhaftes System 118.000 äquivalente Aufgaben pro Stunde bei einem Betriebspunkt mit hohem Durchsatz erledigt. Es wird von einer Reduzierung um 15 % für den Kundenmodellmix, weiteren 11 % für Latenzverpflichtungen, 8 % für die Betriebsverfügbarkeit und 6 % für Software- und Daten-Overhead ausgegangen. Der resultierende verkaufsfähige Durchsatz beträgt etwa 76.000 äquivalente Aufgaben pro Stunde. Diese Annahmen veranschaulichen die Methode und beschreiben kein identifiziertes Unternehmen.

Vorgeschlagene Klassifizierung; Der Käufer sollte zielspezifische Workloads, Systeme und Servicelevel nutzen.

Der Käufer sollte die Verschlechterung testen, wenn das System altert und sich die Software weiterentwickelt. Neue Modellarchitekturen können nicht unterstützte Operatoren, Speicherbeschränkungen oder Kommunikationsaufwand aufdecken. Treiber- und Framework-Updates können die Leistung verbessern und gleichzeitig ein Regressionsrisiko mit sich bringen. Leistungsnachweise sollten daher datiert, versioniert und mit der Produkt-Roadmap verknüpft werden.

Die Betriebsverfügbarkeit sollte Wartung, Ausfälle, Bereitstellungsfehler und Wiederherstellung umfassen. Ein System mit hoher Benchmark-Geschwindigkeit kann eine schwache Wirtschaftlichkeit liefern, wenn die Nutzung unterbrochen wird oder der Supportbedarf hoch ist. Das Modell sollte geplante Kapazität, erfolgreiche Aufträge, abrechenbare Einheiten, Servicegutschriften und Inkasso in Einklang bringen.

4 Preisleistung pro Dollar, pro Watt und pro Rack

Kunden kaufen nützliche Arbeit innerhalb bestimmter Grenzen. Die Leistung pro Dollar erfasst den Anschaffungs- oder Mietpreis. Die Leistung pro Watt erfasst Energiekosten und Stromverfügbarkeit. Die Leistung pro Rack erfasst die Anlagendichte, Vernetzung und Kühlung. Jede Maßnahme kann die bevorzugte Plattform ändern. Der Käufer sollte ermitteln, welche Einschränkungen für jedes Kundensegment und jeden Standort gelten.

Die Kostengrenze sollte Beschleuniger, CPUs, Speicher, Netzwerk, Speicher, Gehäuse, Stromumwandlung, Kühlung, Software, Support und Migration umfassen. Ein preisgünstigerer Chip kann höhere Systemkosten verursachen, wenn mehr Knoten, Technik oder Netzwerk erforderlich sind. Eine hochpreisige Plattform kann für den Kunden eine hohe Wirtschaftlichkeit bieten, wenn Auslastung, Softwareabdeckung und Bereitstellungszeit überlegen sind. Die Bewertung sollte auf der Gesamtwirtschaftlichkeit und nicht auf dem Listenpreis der Komponenten basieren.

Alle Werte sind Managementannahmen pro jährlich eingesetztem Beschleunigeräquivalent und dienen lediglich der Veranschaulichung der Methode.

Die Leistung sollte an der relevanten Grenze gemessen werden. Chipleistung, Platinenleistung, Serverleistung und Anlagenleistung sind unterschiedliche Maße. Kühlung, Netzwerk und Leerlaufkapazität können die Kosten erheblich beeinflussen. Der Käufer sollte die gemessenen Beweise und den Betriebspunkt, an dem sie aufgezeichnet wurden, untersuchen. Es sollte auch getestet werden, ob Leistungsverbesserungen auf aggressiven Energieeinstellungen beruhen, die Kunden nicht aufrechterhalten können.

Anlagenbeschränkungen können strategischen Wert schaffen. Ein Beschleuniger, der mehr akzeptierte Arbeit innerhalb eines vorhandenen Energierahmens liefert, kann die Investition in ein Rechenzentrum verschieben. Dieser Wert hängt von der Reproduzierbarkeit der Arbeitslast, der Systemverfügbarkeit und der Integration ab. Es gehört teilweise dem Kunden oder Käufer und sollte nicht automatisch in den Einzelwert des Zielunternehmens einbezogen werden.

5 Wert Compiler-Reife und Software-Reichweite als Betriebsvermögen

NVIDIA beschreibt CUDA und eine breite Palette von Bibliotheken, Frameworks, SDKs und APIs als Teil seines Technologie-Stacks [6–10]. AMD beschreibt ROCm, Kundensupport und ein wachsendes Rechenzentrumsportfolio [11–14]. OpenXLA, LLVM, ONNX und die wichtigsten Frameworks veranschaulichen die Bedeutung der Compiler-Infrastruktur, Modelldarstellung und Portabilität [21-25]. Diese Quellen zeigen die Dimensionen des Softwarewerts. Sie weisen nicht den gleichen Reifegrad auf allen Plattformen auf.

Die Sorgfalt des Compilers sollte Frontends, Zwischendarstellungen, Diagrammoptimierung, Codegenerierung, Kernelauswahl, Debugging, Profilerstellung, numerische Korrektheit und Hardwareplanung umfassen. Der Käufer sollte die unterstützten Operatoren, die Modellabdeckung, den Release-Takt, den Regressionsverlauf und die für die Aktivierung neuer Architekturen erforderliche Zeit überprüfen. Es sollte ermittelt werden, welche Leistung durch die Fähigkeit des wiederverwendbaren Compilers und welche durch handabgestimmte Kundenarbeit erzielt wird.

Die Softwarereichweite umfasst Dokumentation, Installation, Cloud-Images, Container, Orchestrierung, Sicherheitsupdates, Beobachtbarkeit und Support. Die Akzeptanz durch Entwickler sollte durch aktive Produktionsnutzung, Veröffentlichungen, Problemlösung, Qualität der Mitwirkenden und Kundenbindung nachgewiesen werden. Downloadzahlen, Repositories und Community-Aktivitäten können Kontext liefern. Sie sollten nicht als wiederkehrende Ökonomie ohne Kundennachweise behandelt werden.

Der Softwarereifegrad sollte durch messbare wirtschaftliche Auswirkungen in die Bewertung eingehen. Es kann die Zeit bis zur Bereitstellung, Nutzung, Kundenkonvertierung, Supportkosten und Erneuerung verbessern. Das Modell sollte eine breite Plattformprämie vermeiden, die nicht durch Programmnachweise gestützt wird. Es sollte jede Softwarefunktion mit einer Kundenkohorte, der verbleibenden Investition und dem beobachtbaren Ergebnis verknüpfen.

Bei der Quellcode-Diligence sollten Architektur, Wartbarkeit, Tests, Sicherheit, Release-Automatisierung und Verpflichtungen Dritter untersucht werden. Der Käufer sollte Code identifizieren, der Eigentum ist, permissiv lizenziert ist, restriktiv lizenziert ist, vom Kunden bereitgestellt wird oder von vertraulichen Schnittstellen abhängig ist. Die Reproduzierbarkeit des Builds sollte in einer sauberen Umgebung getestet werden. Kritische Komponenten sollten über benannte Betreuer, Überprüfungshistorie und Wiederherstellungspläne verfügen. Technische Schulden können wirtschaftlich erheblich sein, wenn jedes neue Modell oder jeder neue Chip umfangreiche manuelle Eingriffe erfordert. Bei der Bewertung sollte zwischen Sanierungsmaßnahmen, die zur Aufrechterhaltung der aktuellen Einnahmen erforderlich sind, und diskretionären Investitionen zur Erweiterung der Plattform unterschieden werden. Die Teilnahme an Open-Source-Lösungen kann die Akzeptanz und Rekrutierung stärken und gleichzeitig Compliance-, Offenlegungs- und Governance-Verpflichtungen schaffen, die einer gesonderten Prüfung bedürfen.

6 Messen Sie die Migrationskosten, bevor Sie von einer Kundenkonvertierung ausgehen

Bei der Migration geht es um mehr als nur um das Neukompilieren von Code. Kunden müssen möglicherweise Modelle konvertieren, nicht unterstützte Vorgänge ersetzen, Kernel neu abstimmen, die Präzision ändern, die Genauigkeit validieren, Container neu erstellen, Scheduler ändern, Teams neu schulen und die Überwachung neu gestalten. Möglicherweise müssen sie während des Übergangs auch die Infrastruktur duplizieren. Der Käufer sollte diese Belastung nach Arbeitsaufwand und Kunde bemessen.

Der Migrationsplan sollte mit einer Bestandsaufnahme von Modellen, Frameworks, benutzerdefinierten Operatoren, Datenpipelines, Bereitstellungssystemen, Sicherheitskontrollen und Servicelevels beginnen. Jeder Artikel sollte eine Portabilitätsbewertung, einen Sanierungsplan, einen verantwortlichen Eigentümer, einen Test und ein Abnahmetor erhalten. Das Kostenmodell sollte Kunden-Engineering, Zielunterstützung, verzögerte Nutzung und Parallelbetrieb umfassen.

Die Umstellungskosten können die Kundenbindung unterstützen und gleichzeitig das Wachstum begrenzen. Ein Ziel kann starke Kunden haben, weil es ein wertvolles Problem löst oder weil es teuer ist, das Unternehmen zu verlassen. Der Käufer sollte den Produktvorteil von der Abhängigkeit unterscheiden. Es sollte auch beurteilt werden, ob die Übernahme durch einen Plattformeigentümer das Vertrauen, die Neutralität oder die Bereitschaft der Kunden, Arbeitslasten zu teilen, verändert.

Migrationsanreize sollten als Anschaffungskosten behandelt werden, wenn sie zur Gewinnung von Geschäften erforderlich sind. Kostenloses Engineering, Gutschriften, Hardware-Rabatte und Kapazitätsgarantien können die Einführung beschleunigen und gleichzeitig den realisierten Preis senken. Die Einnahmenbrücke sollte Bruttobuchungen, Anreize, akzeptierte Nutzung und gesammeltes Bargeld anzeigen.

Die Migrationskapazität sollte als eingeschränktes Bereitstellungssystem modelliert werden. Spezialisierte Ingenieure, Zugriff auf Kundenmodelle, Validierungsumgebungen und Produktionsfenster können die Anzahl der Programme begrenzen, die gleichzeitig verschoben werden können. Eine große Pipeline kann daher langsam konvertieren, selbst wenn Kunden Interesse bekunden. Der Käufer sollte die Entwicklungsstunden, die verstrichene Zeit, die Abnahmezyklen und die Supportintensität je nach Art der Arbeitsbelastung schätzen. Es sollte wiederverwendbare Tools und Erkenntnisse identifizieren, die spätere Migrationskosten reduzieren. Die Prognose sollte die Konvertierung auf die nachgewiesene Lieferkapazität begrenzen, bis finanzierte Einstellungen, Automatisierung oder Partnerunterstützung verfügbar sind. Dieser Ansatz verhindert, dass eine Vertriebspipeline schneller in Umsatz umgewandelt wird, als das Ziel technisch liefern kann und die Kunden operativ akzeptieren können.

7 Testdesign gewinnt, Kundenkonzentration und Nutzungsqualität

Ein gewonnener Accelerator-Design kann technische Bewertung, Status eines zugelassenen Anbieters, reservierte Kapazität, Erstbereitstellung oder zugesagtes Volumen bedeuten. Das Sorgfaltsvokabular sollte jedem Staat eine definierte Beweisanforderung zuordnen. Eine Pressemitteilung oder ein Memorandum of Understanding kann den strategischen Kontext unterstützen. Es sollte nicht als vertraglich vereinbartes Bargeld bewertet werden.

Der Käufer sollte Pipeline-Datensätze mit Verträgen, Bestellungen, Telemetrie, Rechnungen, Gutschriften und Inkasso abgleichen. Es sollte die Kundeneinheit, die Arbeitslast, die Produktversion, den Einsatzort, das Serviceniveau, den Preis, die Mindestverpflichtung, die Kündigungsrechte und die Annahmebedingungen angeben. Das prognostizierte Volumen sollte von der installierten, verfügbaren, verbrauchten und abrechnungsfähigen Kapazität getrennt werden.

Die Konzentration sollte über Kunden, Workloads, Cloud-Kanäle, Systempartner und gemeinsame Wirtschaftsträger hinweg gemessen werden. Mehrere Programme können von einem Hyperscaler oder einer Modellfamilie abhängen. Ein Kunde kann auch durch Qualifizierung, Kapazitätsfinanzierung oder Softwarebeiträge Einfluss nehmen. Bei der Bewertung sollte der Verlust, die Verzögerung oder die Neubewertung jeder wesentlichen Beziehung geprüft werden.

Vorgeschlagener Rahmen; Wahrscheinlichkeiten und Umrechnungszeiträume erfordern zielspezifische Nachweise.

Die Nutzungsqualität ist wichtig. Eine Bereitstellung kann unter der geplanten Auslastung liegen, weil Modelle, Daten oder Kundenanforderungen verzögert sind. Es kann bei hoher Auslastung und schwachen Margen laufen, da die Support- und Stromkosten unterbewertet sind. Der Investitionsausschuss sollte wirtschaftliche Daten auf Kundenebene und nicht nur eine einzelne installierte Kapazität erhalten.

8 Kartenerstellungs-, Speicher-, Verpackungs- und Netzwerkabhängigkeiten

Die Leistung des Beschleunigers hängt von der Herstellung, der Verpackung, dem HBM, den Substraten, der Vernetzung, der Systemintegration und der Stromversorgung ab. Die Spezifikationen des Open Compute Project veranschaulichen modulare Beschleuniger- und Systemschnittstellen ^[26]. UCIe-, Speicher- und Verbindungsstandards bieten zusätzlichen Kontext [27–29]. Öffentliche Offenlegungen zu Gießereien und Verpackungen beschreiben anhaltende Investitionen und technische Komplexität [30–32]. Die Roadmap des Ziels sollte anhand dieser Abhängigkeiten getestet werden.

Der Käufer sollte Wafer-Vereinbarungen, Verpackungszuteilung, Speicherversorgung, Platinenherstellung, Komponentenqualifizierung, Änderungskontrolle, Priorität, Preisgestaltung, Mindestbestellmenge, Garantie und Zweitquellenstatus prüfen. Der Name eines Anbieters in einem Plan stellt keine verfügbare Kapazität dar. Das Modell sollte ausgeführte Rechte, datierte Bereitschaft und nachgewiesene Erträge verwenden.

Vernetzung und Kommunikation können mit der Skalierung von Clustern zum Systemengpass werden. Der Testplan sollte den kollektiven Betrieb, die Überlastung, die Wiederherstellung nach Fehlern und die Skalierung der Arbeitslast messen. Ein Vorteil auf Chipebene kann verschwinden, wenn der Software- oder Fabric-Overhead steigt. Die Bewertung sollte daher die Leistung auf Systemebene und das für die versprochene Konfiguration erforderliche Kapital umfassen.

Lieferverpflichtungen können sowohl Wert als auch Haftung schaffen. Vorauszahlungen und Take-or-Pay-Verpflichtungen können Kapazitäten sichern und gleichzeitig Liquidität verbrauchen, wenn sich die Nachfrage ändert. Durch kundenfinanzierte Kapazitäten kann der Kapitalbedarf gesenkt und gleichzeitig Prioritäts-, Rückerstattungs- oder Exklusivitätsbedingungen geschaffen werden. Der Käufer sollte jede Verpflichtung nach Produkt, Zeitraum, Gegenpartei und Konsequenz des Kontrollwechsels aufschlüsseln.

9 Bewerten Sie die Roadmap als eine Abfolge von Beweispunkten

Accelerator-Roadmaps umfassen Architektur, Simulation, Tape-Out, erstes Silizium, Bereitstellung, Software-Aktivierung, Systemqualifizierung und Kundenakzeptanz. Jedes Tor hat unterschiedliche Wahrscheinlichkeiten, verbleibende Kosten und Zeitpunkte. Eine Roadmap-Folie sollte nicht den vollen Betriebswert erhalten, bevor keine Beweise für die Konvertierung vorliegen.

Der Käufer sollte eine integrierte Hardware- und Software-Roadmap pflegen. Die Bereitstellung von Silizium ohne Compiler-, Framework- und Systembereitschaft kann zu Umsatzverzögerungen führen. Die Software kann nach dem Start ausgereift sein und die Leistung verbessern. In der Prognose sollten die für jedes Kundenprogramm erforderliche Version und die für die Bereitstellung erforderlichen Ressourcen angegeben werden.

Der Roadmap-Wert kann als eine Reihe von Programmoptionen modelliert werden. Für jede Option sollten ein definiertes Produkt, eine Arbeitsbelastung, eine Kundenkohorte, ein erwarteter Cashflow, eine Wahrscheinlichkeit, eine verbleibende Investition und ein frühestes Entscheidungsdatum festgelegt sein. Geteilte Kosten und Abhängigkeiten sollten einmalig umgelegt werden. Das Modell sollte verhindern, dass die gleiche Zukunftsfähigkeit sowohl im Endwachstum als auch im separaten Optionswert auftritt.

Der Endwert sollte die Fähigkeit widerspiegeln, aufeinanderfolgende Produkte zu liefern, nicht eine vorteilhafte Generation. Der Käufer sollte die Wiederverwendung der Architektur, die Teamkontinuität, die Verifizierungsressourcen, die Softwareportabilität, den Lieferantenzugang und das Kundenvertrauen bewerten. Eine schnelle Kadenz kann den Wert steigern, wenn frühere Ziele mit kontrollierten Kosten und kontrollierter Qualität erreicht wurden.

10 Erstellen Sie die Bewertung auf der Grundlage anerkannter Arbeitsbelastungsökonomie

Die eigenständige Bewertung sollte mit den Cashflows auf Kundenebene beginnen. Der Umsatz sollte durch akzeptierte Bereitstellungen, verbrauchte oder vertraglich vereinbarte Einheiten, realisierten Preis und Verlängerung bestimmt werden. Die Kosten sollten Silizium, Speicher, Systeme, Software, Support, Migration, Garantie, Kapital und Betriebskapital umfassen. Die Szenarioanalyse sollte Leistung, Nutzung, Preis, Leistung und Roadmap-Timing kombinieren.

Das Management geht von fünf akzeptierten Kundenkohorten mit einem Barwert von USD 890 million, vier skalierten Bereitstellungsoptionen im Wert von USD 430 million, vier technischen Auswahlmöglichkeiten im Wert von USD 220 million und vier Roadmap-Optionen im Wert von USD 180 million aus. Anschließend werden USD 190 million für die Kundenkonzentration, USD 120 million für die Migrationsunterstützung und USD 270 million für das verbleibende Roadmap-Kapital abgezogen. Eine Plattformzulage von USD 540 million ergibt den angenommenen eigenständigen Unternehmenswert von USD 1.68 billion. Bei allen Beträgen handelt es sich um Annahmen des Managements.

Werte und Wahrscheinlichkeiten sind Annahmen des Managements, die lediglich der Methodendemonstration dienen.

Marktmultiplikatoren können eine Plausibilitätsprüfung ermöglichen, nachdem die Vergleichbarkeit hergestellt wurde. Umsatzqualität, Hardwareinhalt, Softwarereife, Bruttomarge, Kapitalintensität, Kundenkonzentration und Roadmap-Risiko unterscheiden sich erheblich zwischen den Accelerator-Unternehmen. Ein Plattformmultiple sollte nicht nur deshalb angewendet werden, weil das Ziel die AI-Terminologie verwendet.

Das Modell sollte den Einzelwert vom käuferspezifischen Wert trennen. Vertrieb, Lieferzugang, Cloud-Reichweite, Systemintegration und Softwareoptimierung können Synergien schaffen. Ihr Wert hängt von den Ressourcen des Käufers, den Implementierungskosten, der Kundenreaktion und den Wettbewerbsbeschränkungen ab. Der Verkäufer sollte nicht die volle Vergütung für Synergien erhalten, die nur der Käufer erzielen kann.

Die Finanzierungsanalyse sollte die Volatilität und den Kapitalbedarf der Plattform widerspiegeln. Die Schuldenkapazität sollte auf wiederkehrenden, akzeptierten Cashflows nach Lieferverpflichtungen, Garantie-, Support- und Roadmap-Investitionen basieren. Rückstände, Reservierungen und Kundenprognosen sollten nach Durchsetzbarkeit und Stornierungsrechten klassifiziert werden. Ein Kreditgeber benötigt möglicherweise Liquidität für Tape-Outs, Lagerbestände, Kapazitätseinlagen und Kundenmigration, bevor Einnahmen erzielt werden. Der Nachteil dürfte eine Kombination aus verzögerter Bereitstellung, schwächerem realisierten Preis, höheren Supportkosten und fortgesetzten Roadmap-Ausgaben sein, da diese Belastungen gemeinsam auftreten können. Die Akquisitionsfinanzierung sollte einen vertraglichen Spielraum und die Finanzierung des Integrationsplans umfassen und nicht davon ausgehen, dass die Überschrift EBITDA sofort ausschüttbar ist.

11 Schaffen Sie käuferspezifische Synergien mit verantwortungsvollen Lieferplänen

Synergien können durch Beschaffung, Verpackungszuteilung, Vernetzung, Cloud-Verteilung, Software-Integration, Kundenzugang und reduzierte Doppelkosten entstehen. Jede Initiative sollte eine Ausgangslage, einen Eigentümer, Ressourcen, einen Zeitplan, eine Abhängigkeit und ein messbares Cash-Ergebnis haben. Eine Bezeichnung wie „Ökosystem-Hebel“ reicht für die Bewertung nicht aus.

Technische Synergien sollten durch definierte Workloads getestet werden. Die Kombination eines Zielbeschleunigers mit einem Compiler, einer Verbindung oder einem System des Käufers kann die Leistung, Auslastung oder Bereitstellungszeit verbessern. Das Modell sollte die Integrationskosten und das Risiko berücksichtigen, dass Kunden eine geschlossene oder geänderte Plattform ablehnen. Die Ergebnisse sollten anhand der Unterzeichnungsbasislinie gemessen werden.

Umsatzsynergien erfordern Kundennachweise. Ein Käuferkanal kann den Zugang erweitern und gleichzeitig zu Konflikten mit Kunden führen, die mit dem Käufer konkurrieren. Das Modell sollte Kunden, Angebote, Verkaufszyklen, Migrationsunterstützung und Kapazität identifizieren. Breite prozentuale Steigerungen sollten außerhalb des zentralen Szenarios bleiben, sofern sie nicht durch Programmpläne unterstützt werden.

Durch Kostensynergien sollten kritische Fähigkeiten erhalten bleiben. Das Entfernen von dupliziertem Engineering ohne Verständnis für Compiler, Verifizierung, Support und Kundenabhängigkeiten kann der Plattform schaden. Der Integrationsplan sollte die entfernbaren Unternehmenskosten von der Produktarbeit unterscheiden, die für Roadmap und Zuverlässigkeit erforderlich ist.

12 Wählen Sie eine Transaktionsstruktur, die der Beweisreife entspricht

Eine vollständige Übernahme kann integrierte Produkt- und Vertriebsentscheidungen unterstützen und gleichzeitig das Roadmap- und Kundenrisiko auf den Abschluss konzentrieren. Eine gestaffelte Akquisition kann Eigentum und Gegenleistung mit Silizium, Software oder Kundeneingängen verknüpfen. Eine Minderheitsinvestition kann Lern- und kommerzielle Rechte sichern und gleichzeitig die Neutralität wahren. Ein Joint Venture kann komplementäre Vermögenswerte kombinieren und gleichzeitig eine komplexe Governance schaffen. Ein Lizenz- oder Liefervertrag kann den Zugang ermöglichen, ohne dass das Unternehmen erworben werden muss.

Vorgeschlagener Entscheidungsrahmen; Rechtliche, steuerliche, buchhalterische und regulatorische Konsequenzen bedürfen einer fachkundigen Beratung.

Eine bedingte Gegenleistung kann Unsicherheiten überbrücken, wenn die Kennzahl messbar ist und die Kontrolle des Käufers berücksichtigt wird. Relevante Gates können Benchmark-Reproduzierbarkeit, Compiler-Abdeckung, akzeptierte Bereitstellung, Nutzung, Bruttomarge oder Roadmap-Lieferung sein. Die Vereinbarung sollte Konfiguration, Nachweise, Messzeitraum, Kundenänderungen, Kapitalzusagen, Buchhaltung, Prüfung und Streitbeilegung festlegen.

Governance sollte den Vermögenswert vor der vollständigen Kontrolle schützen. Informationsrechte, Finanzierungspflichten, Roadmap-Entscheidungen, IP-Nutzung, Kundenneutralität und Transaktionen mit verbundenen Parteien sollten zur Struktur passen. Der Käufer sollte es vermeiden, wettbewerbsrelevante Kundeninformationen zu erhalten, die über seine legitimen Rechte hinausgehen.

13 Befassen Sie sich mit Wettbewerb, Interoperabilität und Plattformneutralität

In den US-Fusionsrichtlinien werden Transaktionen mit Plattformen, Ergänzungen, Interoperabilität und Zugang zu Inputs erörtert [37–39]. Eine Accelerator-Akquisition kann sich auf Entwickler, Cloud-Anbieter, Kunden, Systempartner und konkurrierende Hardware auswirken. Der Käufer sollte ermitteln, wo das Ziel die Multiplattform-Nutzung unterstützt und ob die Transaktion die Anreize zur Aufrechterhaltung dieser Unterstützung ändern könnte.

Bei der Wettbewerbsprüfung sollten Marktdefinition, Kundenalternativen, Wechselkosten, Roadmap-Timing, Angebotszugang, Entwicklertools und Daten untersucht werden. Eine kleine aktuelle Umsatzbasis beseitigt nicht zukunftsgerichtete Probleme, wenn das Ziel die Abhängigkeit von einer etablierten Plattform verringern könnte. Die Analyse sollte von einem qualifizierten Berater unter Berücksichtigung aktueller Gesetze und Fakten durchgeführt werden.

Abhilfemaßnahmen oder Verpflichtungen können den Wert beeinflussen. Anforderungen hinsichtlich Interoperabilität, Lizenzierung, Informationstrennung, Versorgung, Kundenneutralität oder Nichtdiskriminierung können die geplante Integration oder Synergie einschränken. Die Bewertung sollte die Kosten, Verzögerungen und strategischen Auswirkungen glaubwürdiger Ergebnisse berücksichtigen und die Genehmigung nicht als binäres Ereignis behandeln.

Plattformneutralität kann an sich schon ein Vorteil sein. Kunden schätzen möglicherweise einen Compiler, eine Orchestrierungsschicht oder ein Modelltool, weil es mehrere Beschleuniger unterstützt. Die Übernahme durch einen Hardwarelieferanten kann dieses Angebot schwächen. Der Käufer sollte die Kunden- und Partnerbindung testen und eine Governance beibehalten, bei der Neutralität den Cashflow unterstützt.

Daten-, Sicherheits- und Exportkontrollen können den Integrationsumfang prägen. Kunden-Workloads können vertrauliche Modelle, Schulungsmethoden, personenbezogene Daten oder regulierte Informationen enthalten. Benchmark-Artefakte und Telemetrie können vertraglich eingeschränkt sein. Quellrepositorys können kontrollierte technische Informationen, kryptografisches Material oder Code von Drittanbietern enthalten. Der Käufer sollte darlegen, wo diese Vermögenswerte gespeichert sind, wer darauf zugreifen kann, wie sie Grenzen überschreiten und welche Genehmigungen gelten. Integrationspläne sollten den Least-Privilege-Zugriff, die Protokollierung, die Trennung und die Reaktion auf Vorfälle gewährleisten. Jeder geplante Transfer von Teams, Werkzeugen oder Technologie sollte anhand der aktuellen Export- und Sanktionsregeln überprüft werden. Kosten und Verzögerungen, die durch erforderliche Kontrollen entstehen, gehören in das Transaktionsmodell und den Abschlussplan.

14 Bringen Sie Investitionen, Betriebskapital und Supportverpflichtungen in Einklang

Die Beschleunigerentwicklung erfordert Design, Verifizierung, Tape-out, Software, Systeme, Inventar, Qualifizierung und Support. Der Käufer sollte Wartung, festgelegte Roadmap, diskretionäres Wachstum und kundenfinanzierte Investitionen trennen. Das angekündigte Kapital sollte mit Bestellungen, Verträgen, Meilensteinen, Zahlungen und nutzbarer Leistung abgeglichen werden.

Bei Generationswechseln kann das Bestandsrisiko steigen. Chips, Platinen und Systeme können an Wert verlieren, wenn Software, Kundenpläne oder neue Produkte verschoben werden. Das Diligence-Team sollte den Bestand nach Version, Kunde, Qualifikation, Wiederherstellbarkeit und Stornierungsrechten klassifizieren. Kaufverpflichtungen und Lieferanteneinlagen sollten bei zentraler und abwärts gerichteter Nachfrage getestet werden.

Das Betriebskapital sollte Forderungen, Kredite, Garantien, Supportverpflichtungen, Vorauszahlungen und Kapazitätsreservierungen umfassen. Der Versand der Hardware ist nicht immer gleichbedeutend mit der endgültigen Abnahme. Das Cashflow-Modell sollte Installation, Akzeptanz, Nutzung, Servicegutschriften und Inkasso widerspiegeln.

Aktivierte Software- und Entwicklungskosten erfordern eine buchhalterische Prüfung. Der Käufer sollte das wirtschaftliche Leben mit der Produktfrequenz und der Kundennutzung in Einklang bringen. Die Einkaufsbuchhaltung sollte erworbene Technologie, Kundenbeziehungen, Verträge und Goodwill anhand aktueller Standards identifizieren [43–47]. Bilanzielle Klassifizierungen ersetzen nicht die Betriebsbewertung.

15 Schützen Sie das Vertrauen der Kunden und die technische Kontinuität durch Integration

Durch die Integration sollten Roadmaps, Release-Qualität, Kundenvertraulichkeit, Sicherheit, Bereitstellung und verantwortungsvolle Entscheidungsrechte gewahrt bleiben. Kunden befürchten möglicherweise, dass ein strategischer Käufer seine eigenen Produkte bevorzugt, die Preise ändert, die Portabilität verringert oder auf sensible Workloads zugreift. Die Kommunikation sollte sich mit Kontinuität, Support, Interoperabilität und Governance befassen und dabei Zusagen nutzen, die das zusammengeschlossene Unternehmen einhalten kann.

Das Risiko von Schlüsselpersonen geht über die Führungskräfte hinaus. Architektur, Verifizierung, Compiler, Kernel, Framework, Support und Kundenwissen können in kleinen Teams liegen. Die Bindung sollte mit Rolle, Autorität, Roadmap und Wissenstransfer verbunden sein. Die Dokumentation sollte Entwurfsentscheidungen, Quellverlauf, Build-Systeme, Benchmark-Artefakte, Testabdeckung und bekannte Fehler umfassen.

Vorgeschlagener Kontrollplan; Der Zeitpunkt sollte an die Transaktionsgenehmigungen und Kundenpflichten angepasst werden.

Die Integrationssequenzierung sollte dem Kunden- und Releaserisiko folgen. Unmittelbare Änderungen an Compiler, Treibern, Repositorys, Build-Systemen oder Telemetrie können zu Regressionen führen. Der Käufer sollte festlegen, welche Systeme sich am ersten Tag ändern können, welche kontrollierte Tests erfordern und welche bis zum Produkt- oder Kundeneingang getrennt bleiben sollten.

16 Verwenden Sie ein Steuerungsmodell, bei dem die Bereitstellung von der Signatur bis zur akzeptierten Bereitstellung erfolgt

Der Zeitraum zwischen der Unterzeichnung und der akzeptierten Nutzung durch den Kunden kann zu erheblichen Wertschwankungen führen. Produktpläne, Software-Releases, Benchmark-Ergebnisse, Lieferzuteilung und Kundenprogramme ändern sich ständig. Das Kontrollmodell sollte die letzte Sorgfaltsprüfung bis hin zum Abschluss, der Integration und mindestens dem ersten geprüften Zyklus akzeptierter Bereitstellungen und Sammlungen abdecken.

Das Modell sollte mit einer eingefrorenen Unterzeichnungsbasislinie beginnen. Darin sollten jedes Programm, jede Arbeitslast, jede Konfiguration, jeder Benchmark, jedes Serviceniveau, jeder Preis, jeder Lieferweg, das erforderliche Personal, das Kapital und die prognostizierte Liquidität aufgeführt sein. Änderungen sollten gegenüber der Grundlinie aufgezeichnet werden. Eine Software-Regression, eine verzögerte Ausmusterung, ein geringeres Angebot, eine Neugestaltung durch den Kunden oder eine Preisanpassung können sich auf den Wert auswirken, bevor er im ausgewiesenen Umsatz erscheint.

Vorläufige Vereinbarungen sollten materielle Vermögenswerte und Programme schützen und gleichzeitig die gesetzliche Betriebsverantwortung wahren. Der Verkäufer muss über Teams, Quellenspeicher, Freigabekontrollen, Lieferrechte, Kundenbeziehungen und Stammkapital verfügen. Wesentliche IP-Gewährungen, Exklusivität, Roadmap-Änderungen, Stornierungen oder ungeplante Verpflichtungen erfordern möglicherweise eine Zustimmung, vorbehaltlich geltender Gesetze und ausgehandelter Schwellenwerte.

Die Abschlussbereitschaft sollte getesteten Zugriff auf Repositorys, Build-Systeme, Signierschlüssel, Benchmark-Artefakte, Support-Systeme, Lieferantenkontakte und Kundeneskalation umfassen. Der Käufer sollte wissen, welche Anmeldeinformationen und Daten übertragen werden können, welche einer Einwilligung bedürfen und welche getrennt bleiben müssen. Jede ungelöste Abhängigkeit sollte einen Eigentümer und eine datierte Aktion haben.

17 Übersetzen Sie die Ergebnisse der Sorgfaltsprüfung in Preise, Konditionen und Integrationsmaßnahmen

Sorgfalt schafft Wert, wenn Erkenntnisse eine Entscheidung ändern. Jede wesentliche Feststellung sollte als Preisanpassung, Strukturelement, Abschlussbedingung, Vertragsschutz, Integrationsmaßnahme oder überwachtes Risiko klassifiziert werden. Die Klassifizierung sollte Beweise, finanzielles Risiko, Zeitpunkt, Eigentümer und Entscheidung identifizieren.

Eine Preisanpassung kann sich auf eine schwächere akzeptierte Nutzung, nicht unterstützte Leistung, Migrationskosten oder erforderliches Kapital auswirken. Eine Abschlussbedingung kann eine Kundenfreigabe, eine Lieferzustimmung oder eine Finanzierung betreffen. Eine Zusicherung, Entschädigung oder ein Treuhandkonto kann eine identifizierte Belastung abdecken. Ein Vertrag kann Teams, Repositorys, Freigaberegeln oder Lieferungen schützen. Eine Integrationsmaßnahme kann eine kontrollierbare Schwachstelle nach dem Schließen beheben.

Zusicherungen und Gewährleistungen sollten der Art und Dauer des Risikos entsprechen. Sie können IP-Eigentum, Open-Source-Compliance, Benchmark-Erklärungen, Kundenverträge, Lieferrechte, Sicherheit, Exportkontrollen und Finanzberichte abdecken. Versicherungen können einige vertragliche Risiken abdecken. Es ersetzt keine technischen Tests, Kundennachweise oder einen finanzierten Integrationsplan.

Im endgültigen Investitionspapier sollten Gesamtpreis, Nettoverschuldung, Betriebskapital, bedingte Gegenleistung, Selbstbehalt, Transaktionskosten und Integrationsfinanzierung in Einklang gebracht werden. Es sollte den eigenständigen Wert, den käuferspezifischen Wert und die Gegenleistung auf derselben Grundlage darstellen. Es sollte zeigen, wie sich bei jeder größeren Sorgfaltsprüfung das Modell oder die Bedingungen verändert haben.

Abschluss

AI Accelerator-Transaktionen kombinieren Halbleiter-, Software-, System-, Kunden- und Plattformökonomie. Eine glaubwürdige Bewertung folgt einer reproduzierbaren Kette von kontrollierten Rechten und Lieferungen über gemessenes Silizium, ausgereifte Software, Kundeneinsatz, akzeptierte Nutzung und gesammeltes Geld. Spitzenspezifikationen und ausgewählte Benchmarks liefern Kontext. Sie erfordern Arbeitslast, Genauigkeit, Latenz, Leistung und Systemnachweise, bevor sie den Betriebswert unterstützen.

Die stärkste Plattform liefert nützliche Arbeit wirtschaftlich unter allen relevanten Kundenbedingungen. Es kombiniert reproduzierbare Leistung, Compiler- und Bibliotheksreife, überschaubare Migration, zuverlässige Bereitstellung, Kundenvertrauen und eine finanzierte Roadmap. Seine Prämie ergibt sich aus der wiederholbaren Akzeptanz und dauerhaften Kontrolle und nicht aus einem Testergebnis oder einem Produktzyklus.

Die Transaktionsdisziplin ist praktisch. Definieren Sie das Asset. Rekonstruieren Sie die Leistung unter Last. Preis-Gesamtsystemökonomie. Testen Sie die Reichweite und Migration der Software. Überprüfen Sie die Nutzung durch den Kunden. Kartenangebot und Roadmap-Abhängigkeiten. Wertprogramme aus akzeptiertem Bargeld. Separate Käufersynergie. Wählen Sie Begriffe, die der Beweisreife entsprechen. Behalten Sie eine kontrollierte Baseline durch den Abschluss und die akzeptierte Bereitstellung bei.

Quellen

1. MLCommons, MLPerf Inference Benchmark Suite, Lesen Sie die Primärquelle
2. MLCommons, MLPerf Inference Submission Guide, Lesen Sie die Primärquelle
3. MLCommons, MLPerf Endpoints Benchmark, Lesen Sie die Primärquelle
4. MLCommons, MLPerf Inferenzleistungsmessung, Lesen Sie die Primärquelle
5. MLCommons, MLPerf Inference v5 Sprachmodell-Benchmarks, Lesen Sie die Primärquelle
6. NVIDIA, Jahresbericht 2026 auf Formular 10-K, Lesen Sie die Primärquelle
7. NVIDIA, Jahresbericht 2026 und Proxy-Materialien, Lesen Sie die Primärquelle
8. NVIDIA, Ergebnisse des vierten Quartals des Geschäftsjahres 2026, Lesen Sie die Primärquelle
9. NVIDIA, CUDA-Plattformdokumentation, Lesen Sie die Primärquelle
10. NVIDIA, TensorRT-Dokumentation, Lesen Sie die Primärquelle
11. Advanced Micro Devices, Jahresbericht 2025 auf Form 10-K, Lesen Sie die Primärquelle
12. Advanced Micro Devices, ROCm-Dokumentation, Lesen Sie die Primärquelle
13. Offenlegungen zu Advanced Micro Devices, Rechenzentren und Instinct-Produkten, Lesen Sie die Primärquelle
14. Advanced Micro Devices, Jahresberichte und Einreichungen, Lesen Sie die Primärquelle
15. Intel, Jahresbericht 2024 auf Form 10-K, Lesen Sie die Primärquelle
16. Intel, Gaudi-Beschleunigerdokumentation, Lesen Sie die Primärquelle
17. Google Cloud, TPU-Dokumentation, Lesen Sie die Primärquelle
18. Amazon Web Services, Trainium-Dokumentation, Lesen Sie die Primärquelle
19. Microsoft, Maia AI Beschleunigerübersicht, Lesen Sie die Primärquelle
20. Meta Engineering, MTIA-Acceleratorprogramm, Lesen Sie die Primärquelle
21. OpenXLA, Compiler-Projektdokumentation, Lesen Sie die Primärquelle
22. LLVM-Projekt, Dokumentation der Compiler-Infrastruktur, Lesen Sie die Primärquelle
23. ONNX, offene Modellaustauschdokumentation, Lesen Sie die Primärquelle
24. PyTorch, Compiler-Dokumentation, Lesen Sie die Primärquelle
25. TensorFlow, XLA-Dokumentation, Lesen Sie die Primärquelle
26. Open Compute Project, Basisspezifikation des OCP Accelerator-Moduls, Lesen Sie die Primärquelle
27. UCIe-Konsortium, Spezifikationsressourcen, Lesen Sie die Primärquelle
28. PCI-SIG, Compute Express Link-Ressourcen, Lesen Sie die Primärquelle
29. JEDEC, Speicherstandardressourcen mit hoher Bandbreite, Lesen Sie die Primärquelle
30. Taiwan Semiconductor Manufacturing Company, Jahresbericht 2025, Lesen Sie die Primärquelle
31. Amkor Technology, Jahresberichte und Einreichungen, Lesen Sie die Primärquelle
32. ASE Technology Holding, Jahresberichte, Lesen Sie die Primärquelle
33. National Institute of Standards and Technology, AI Risikomanagement-Rahmenwerk, Lesen Sie die Primärquelle
34. National Institute of Standards and Technology, AI Standardisierungsplan, Lesen Sie die Primärquelle
35. US-Handelsministerium, CHIPS für Amerika, Lesen Sie die Primärquelle
36. US Bureau of Industry and Security, Exportverwaltungsvorschriften, Lesen Sie die Primärquelle
37. US-Justizministerium und Federal Trade Commission, Fusionsrichtlinien 2023, Lesen Sie die Primärquelle
38. US-Justizministerium, Richtlinie 6 zur Festigung oder Ausweitung einer marktbeherrschenden Stellung, Lesen Sie die Primärquelle
39. US-Justizministerium, Richtlinie 9 zu mehrseitigen Plattformen, Lesen Sie die Primärquelle
40. Federal Trade Commission, Hart-Scott-Rodino-Benachrichtigungsprogramm vor dem Zusammenschluss, Lesen Sie die Primärquelle
41. Europäische Kommission, horizontale Fusionsrichtlinien, Lesen Sie die Primärquelle
42. Europäische Kommission, Gesetz über digitale Märkte, Lesen Sie die Primärquelle
43. IFRS-Stiftung, IFRS 3 Unternehmenszusammenschlüsse, Lesen Sie die Primärquelle
44. IFRS-Stiftung, IAS 38 Immaterielle Vermögenswerte, Lesen Sie die Primärquelle
45. IFRS-Stiftung, IAS 36 Wertminderung von Vermögenswerten, Lesen Sie die Primärquelle
46. IFRS-Stiftung, IFRS 13 Bemessung des beizulegenden Zeitwerts, Lesen Sie die Primärquelle
47. Financial Accounting Standards Board, Thema 805 Unternehmenszusammenschlüsse, Lesen Sie die Primärquelle
48. Weltorganisation für geistiges Eigentum, IP-Bewertung, Lesen Sie die Primärquelle
49. OECD, Wettbewerb in der digitalen Wirtschaft, Lesen Sie die Primärquelle
50. MLCommons, Benchmark-Arbeitsgruppen und Governance, Lesen Sie die Primärquelle