DE112020003742T5

DE112020003742T5 - Verfahren, systeme, erzeugnisse und vorrichtungen zur verbesserung von jobplanungseffizienz

Info

Publication number: DE112020003742T5
Application number: DE112020003742.8T
Authority: DE
Inventors: Ehsan Hosseinzadeh Khaligh; Michael Whitney; Nathaniel Sema; Kshitij A. Doshi
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2019-08-07
Filing date: 2020-08-07
Publication date: 2022-04-21
Also published as: KR20220044717A; US20220261661A1; WO2021026481A1

Abstract

Offenbart sind Verfahren, Vorrichtungen, Systeme und Erzeugnisse zum Verbessern von Jobplanungseffizienz. Eine beispielhafte Vorrichtung umfasst einen Merkmalgenerator zum Importieren von Standardwerten von Merkmalen, die einem ersten Modelltyp entsprechen, einen Kennzeichnungstrainer zum Trainieren von Kennzeichnungen, die dem ersten Modelltyp entsprechen, und einen Modellbewerter zum Bestimmen einer Genauigkeitsmetrik des ersten Modelltyps basierend auf einer ersten Vorhersage, die den Standardmerkmalen entspricht, und Aktualisieren der Merkmale von den Standardwerten auf aktualisierte Werte, wenn die Genauigkeitsmetrik einen Genauigkeitsschwellenwert nicht erfüllt.

Description

VERWANDTE ANMELDUNGEN
Dieses Patent beansprucht die Priorität der am 7. August 2019 eingereichten US-Provisional-Patentanmeldung Nr. 62/883,747 und beansprucht die Priorität der am 13. Dezember 2019 eingereichten US-Provisional-Patentanmeldung Nr. 62/947,802 . Die US-Provisional-Patentanmeldung Nr. 62/883,747 und die US-Provisional-Patentanmeldung Nr. 62/947,802 werden hiermit durch Bezugnahme in ihrer Gesamtheit aufgenommen. Die Priorität der US-Provisional-Patentanmeldungen Nr. 62/883,747 und 62/947,802 wird hiermit beansprucht.
GEBIET DER OFFENBARUNG
Diese Offenbarung betrifft allgemein Ressourcenbeanspruchungsverwaltung und insbesondere Verfahren, Systeme, Erzeugnisse und Vorrichtungen zum Verbessern von Jobplanungseffizienz.
HINTERGRUND
In den letzten Jahren hat der Bedarf an Datenverarbeitungsressourcen zugenommen. Datenverarbeitungsressourcen umfassen Personal Computer, Server, Serverfarmen und/oder Cloud-basierte Datenverarbeitungsdienste. Solche Ressourcen führen Aufgaben basierend auf Jobbeschreibungen durch, wobei die Datenverarbeitungsdienste einen Kunden basierend auf einer Menge beanspruchter Datenverarbeitungszyklen abrechnen könnten.
Figurenliste

1A ist eine schematische Darstellung eines beispielhaften Planungssystems.
1B ist eine schematische Darstellung beispielhafter Hardwareressourcen, für die Vorhersagen gemäß vorliegend offenbarten Beispielen getroffen werden sollen.
2A ist eine schematische Darstellung eines verbesserten Planungssystems zum Annehmen von Jobeingabeinformationen, wobei das verbesserte Planungssystem ein beispielhaftes Planungs-Framework umfasst.
2B ist eine alternative schematische Darstellung des beispielhaften Planungs-Framework.
3A ist eine schematische Darstellung eines zusätzlichen Details des Planungs-Framework aus 2A und 2B zur Verbesserung von Jobplanungseffizienz.
3B-3E sind Tabellen beispielhafter Informationen, die erzeugt und/oder anderweitig erfasst werden, um Hardwarenutzung und zugehörige Jobzuweisungen zu identifizieren.
4A ist eine schematische Darstellung von beispielhaften Maschinenlernmodell-Zuweisungen, die durch das beispielhafte Planungs-Framework aus 2A, 2B und 3A implementiert werden.
4B ist ein Flussdiagramm, das maschinenlesbare Anweisungen repräsentiert, die ausgeführt werden können, um die beispielhaften Maschinenlernmodell-Zuweisungen aus 4A zu implementieren.
4C ist eine alternative schematische Darstellung des beispielhaften Planungs-Framework.
5A1, 5A2, 5A3, 5B, 6A, 6B, 7, 8A-8E, 9 und 10 sind Flussdiagramme, die maschinenlesbare Anweisungen repräsentieren, die ausgeführt werden können, um das beispielhafte Planungs-Framework aus 2A, 2B, 3A und 4C zu implementieren.
11 ist ein Blockdiagramm einer beispielhaften Verarbeitungsplattform, die zum Ausführen der Anweisungen aus 5A1, 5A2, 5B, 6A, 6B, 7, 8A-8E, 9 und 10 strukturiert ist, um das beispielhafte Planungs-Framework aus 2A, 2B, 3A und 4C zu implementieren.
12 ist ein Blockdiagramm, das einen Überblick über eine andere Konfiguration für Edge Computing zeigt.
13 veranschaulicht Betriebsschichten zwischen Endpunkten, einer Edge Cloud und Cloud-Computing-Umgebungen.
14 zeigt Anfragen und Antworten, die zwischen Client-Endpunkten ausgetauscht werden.
15 veranschaulicht einen beispielhaften Einsatz und eine beispielhafte Orchestrierung für virtuelle Edge-Konfigurationen über ein Edge-Computing-System, das zwischen mehreren Edge-Knoten und mehreren Mandanten betrieben wird.
16 veranschaulicht zusätzliche Datenverarbeitungsanordnungen, die Container in einem Edge-Computing-System einsetzen.
17 zeigt einen vereinfachten Fahrzeugberechnungs- und Kommunikationsanwendungsfall, der Mobilzugriff auf Anwendungen in einem Edge-Computing-System beinhaltet, das eine Edge-Cloud implementiert.
18A-18B stellen Implementierungsbeispiele von Datenverarbeitungsknoten oder -einrichtungen dar, die unter Bezugnahme auf die Edge-Computing-Systeme und -Umgebung wie vorliegend offenbart und beschrieben erörtert werden.
Die Figuren sind nicht maßstabsgetreu. Grundsätzlich werden in allen Zeichnungen und in der zugehörigen schriftlichen Beschreibung dieselben Bezugszeichen verwendet, um auf dieselben oder ähnliche Teile Bezug zu nehmen.

Deskriptoren „erster“, „zweiter“, „dritter“ usw. werden vorliegend verwendet, wenn mehrere Elemente oder Komponenten identifiziert werden, auf die separat Bezug genommen werden kann. Soweit nicht anders angegeben oder basierend auf ihrem Verwendungszusammenhang verstanden, sollen derartige Deskriptoren nicht irgendeine Bedeutung von Priorität, physischer Reihenfolge oder Anordnung in einer Liste oder zeitlicher Ordnung zuschreiben, sondern werden lediglich als Kennzeichnungen verwendet, um sich zum leichteren Verständnis der offenbarten Beispiele auf mehrere Elemente oder Komponenten getrennt zu beziehen. In einigen Beispielen kann der Deskriptor „erster“ verwendet werden, um sich auf ein Element in der ausführlichen Beschreibung zu beziehen, während auf dasselbe Element in einem Anspruch mit einem anderen Deskriptor, wie „zweiter“ oder „dritter“, Bezug genommen werden kann. In derartigen Fällen versteht es sich, dass derartige Deskriptoren lediglich zur Vereinfachung der Bezugnahme auf mehrere Elemente oder Komponenten verwendet werden.
AUSFÜHRLICHE BESCHREIBUNG
Hardwareressourcen liefern Ergebnisse (Durchsatz) an Kunden, die Jobs übermitteln, die von solchen Hardwareressourcen verarbeitet werden sollen. Um Kundenanforderungen zu erfüllen und Nutzungsmetriken der Hardwareressourcen zu verbessern (z.B. zu erhöhen), müssen die Hardwareressourcen verwaltet werden. Beispielsweise teilen Hardwareressourcen, die eine beliebige Anzahl von Verarbeitungseinheiten aufweisen (z.B. individuelle Prozessoren, individuelle Server, individuelle Kerne auf jeweiligen Prozessoren, Verarbeitungsplattformen, die virtuelle Maschinen (VMs) zuteilen und/oder anderweitig verwalten, CPUs, Grafikverarbeitungseinheiten (GPUs), anwendungsspezifische integrierte Schaltungen (ASICs), frei programmierbare Gate-Arrays (FPGAs) usw.), Jobs auf eine Weise zu, die Durchsatzerwartungen von Kunden erfüllt und verhindert, dass irgendeine dieser Verarbeitungseinheiten unter Überlastung arbeitet. Verschiedene Branchen konzentrieren ihre Bemühungen auf Ressourcenbedarfsverwaltung, wie etwa Datenzentren, Cloud-Dienstanbieter und/oder Edge-Cloud-Dienste. Solche Industrien müssen Kundenerwartungen erfüllen und dennoch Ressourcen effizient verwalten, um Kosten und Energieverbrauch zu sparen. Wenn Jobs den Verarbeitungsressourcen auf verschwenderische Weise zugewiesen und/oder anderweitig verteilt werden, dann kann bei einigen Kunden zeitlich verzögerte Performanz auftreten, wenn Jobanfragen übermittelt werden, da solche Verarbeitungsressourcen von anderen Jobs beansprucht werden.
Planungssysteme versuchen, Jobzuweisungen an verfügbare Hardwareressourcen zu verwalten. In einigen Beispielen führen die Planungssysteme statistische Analyse an Jobeingabeanfragen durch, um zu identifizieren, wie jeweilige Jobs (vorliegend mitunter als Abbildung/Zuordnung (mapping) von Jobs zu/auf Ressourcen bezeichnet) bestimmten Ressourcen zuzuteilen sind. Einige kommerzielle Planungssysteme umfassen Kubernetes®, Docker Platform®, SLURM®, IBM Spectrum® usw. In einigen Beispielen unterstützt Ressourcen-Fingerprinting mit Best-Fit-Abgleichmethoden, wie etwa Bin Packing, Priorisierungsmethoden auf Grundlage einer kürzesten verbleibenden Zeit, statistischer Zugriffssteuerung und auf Deep Learning basierender Priorisierung. Aktuelle Systeme leiden jedoch unter Annahmen einer Arbeitslastkonsistenz und einer gewissen Starrheit, wenn diese Annahmen von Erwartungen abweichen. In einigen Beispielen sind sogar Systeme, die eine beliebige Anzahl unterschiedlicher Modelle aufnehmen können, problematisch, weil der Betreiber unabhängig von ihrer Wirksamkeit nach seinem Ermessen vorschreibt, welche Modelle angewendet werden. Erwägungen des Betreibers scheitern jedoch typischerweise daran, Zielsetzungen korrekt zu berücksichtigen, wenn entschieden wird, welche Modelle wann anzuwenden sind.
Vorliegend offenbarte Beispiele verbessern eine Ressourcenzuteilung von Jobs basierend auf einem Vorhersagen einer Gesamtanzahl von belegbaren und verfügbaren zusammenhängenden verbundenen Ressourcen in jeweiligen benutzerdefinierten Zeitrahmen. Vorliegend offenbarte Beispiele wenden Teile-und-herrsche-Methoden an, um Maschinenlernvorgänge und Planung zu vereinfachen und reagierende Anpassung zu erleichtern, wenn Telemetrieverhalten von Erwartungen abweicht. Ziele der Planungssysteme umfassen eine verbesserte Ressourcennutzungseffizienz, einen verbesserten Durchsatz und eine verbesserte Skalenelastizität, wenn Arbeitslastanforderungen schwanken. Solche Zielsetzungen ermöglichen eine Reduzierung von Gesamtinhaberschaftskosten für die Ressourcen sowie erhöhte Gewinne. Beispielhafte Einschränkungen, die durch die Planungssysteme verwaltet werden, umfassen Tail-Reaktionszeitverwaltung, Vermeidung thermischer Instabilität und Einhaltung von Service-Level-Agreements (SLAs). In einigen vorliegend offenbarten Beispielen wird eine Gesamtanzahl belegbarer und zusammenhängender verfügbarer Emulatorplatinen innerhalb einer Zeitspanne von einer Stunde vorhergesagt. Vorliegend offenbarte Beispiele verbessern (z.B. maximieren) eine Hardwareressourcennutzungsmetrik, reduzieren eine durchschnittliche Dauer für geplante Jobs in einer Warteschlange und verbessern mit einer solchen Hardwarenutzungsverwaltung verbundene Vorteile. Vorliegend offenbarte Beispiele erhöhen (z.B. maximieren) ferner eine Nutzung von Ressourcen, ohne SLA-Erwartungen zu verletzen, verfolgen Zuteilungseffektivität und passen sich an sich ändernde Bedingungen (z.B. Umstände, unter denen eine Ressourcenverfügbarkeit basierend auf Änderung(en) bei Arbeitslast-Jobanfragen schwankt) an. Vorliegend offenbarte Beispiele sind nicht auf zentralisierte Ressourcenpools beschränkt, wie Cloud-Zentren, die eine beliebige Anzahl von Serverfarmen verwalten. Das heißt, vorliegend offenbarte Beispiele ermöglichen eine verbesserte Edge-Netzwerk-Ressourcennutzung, sodass zugeteilte Arbeitslasten weniger fähige Edge-Ressourcen (z.B. IoT- (Internet der Dinge) Einrichtungen) nicht überfluten.
Zusätzlich ermöglichen vorliegend offenbarte Beispiele, dass eine beliebige Menge oder Vielfalt von Modellen angewendet wird, ohne vom Ermessen des Bedieners abhängig zu sein oder dieses zu überfordern. Modelle umfassen, ohne jedoch hierauf eingeschränkt zu sein, klassische Regressionsmodelle (z.B. Polynommodelle mit einstellbarem Grad) und Modelle neuronaler Netze. Vorliegend offenbarte Beispiele wählen Modelle teilweise auf Grundlage von Metadaten, die Jobanfragen entsprechen, Modellperformanz-Verfolgungsaufzeichnungen und/oder Modellmetadaten aus, die bestimmte Modellstärken angeben. Vorliegend offenbarte Beispiele ermöglichen, dass Modelltraining unabhängig von Modelllernaktivitäten (teile und herrsche) erfolgt. Vorliegend offenbarte Beispiele wählen zudem bestimmte Modelle basierend auf einer Analyse verfügbarer historischer Daten aus. Beispielsweise wird mehr Modellierungsaufwand mit polynomialen Modellen relativ höheren Grades betrieben, wenn weniger über Jobs/Anfragen bekannt ist, wohingegen LSTM-Modelle angewendet werden, wenn historische Job-/Anfragedaten verfügbar sind, wodurch die Systemeffizienz verbessert wird.
1A ist eine schematische Darstelleung eines beispielhaften Planungssystems 100. In dem veranschaulichten Beispiel aus 1A umfasst das Planungssystem 100 einen virtuellen Pool 102, der durch das Planungssystem 100 ermöglicht wird, um Jobeingabeinformationen von einer beliebigen Anzahl von Benutzern 104 zu akzeptieren. Die Jobeingabeinformationen können, ohne jedoch hierauf eingeschränkt zu sein, Jobtypinformationen, Jobprioritätsinformationen (z.B. numerische Bewertung der Jobwichtigkeit), erforderliche Computerverarbeitungseinheit- (CPU-) Ressourcen (z.B. eine Anzahl von CPU-Kernen, eine Anzahl von Prozessoren, eine Anzahl von Workstations usw.), erforderliche Speicherressourcen (z.B. Anzahl, Art und/oder Größe von Speicherressourcen) usw. umfassen. Das beispielhafte Planungssystem 100 aus 1A umfasst zudem einen beispielhaften physischen Pool 106, der eine beliebige Anzahl und Art von Hardwareressourcen zum Durchführen der Jobs und/oder Aufgaben, die jeweiligen Jobs zugeordnet sind, umfasst.
Traditionelle und/oder anderweitig bekannte Planungssysteme rufen Anfragen von Anfragenden (Benutzern 104) ab, die Jobs entsprechen. Solche Jobs werden in dem beispielhaften virtuellen Pool 102 eingereiht, der Screening- und Sortieraufgaben durchführt. In einigen Beispielen wird eine erforderliche Menge an Jobs akkumuliert, bevor diese Jobs an physische Ressourcen gesendet werden, während in anderen Beispielen Jobs in unterschiedliche virtuelle Pools klassifiziert werden. In einigen Beispielen sind die unterschiedlichen virtuellen Pools 102 gemäß ihren spezialisierten Hardwareanforderungen organisiert, wie etwa einer Notwendigkeit für kontinuierliche/verbundene Prozessorkerne, und in einigen Beispielen sind die virtuellen Pools 102 gemäß speziellen Softwareanforderungen, benutzerbasierten Prioritäten, projektbasierten Prioritäten, Sicherheitszielen usw. organisiert. Jobs aus den virtuellen Pools werden dann an bestimmte Hardwareressourcen des physischen Pools 106 gesendet und/oder anderweitig zugewiesen.
1B ist eine schematische Darstellung beispielhafter Hardwareressourcen 150, für die Vorhersagen getroffen werden sollen. In einigen Beispielen werden die Hardwareressourcen 150 als Cluster bezeichnet. In dem veranschaulichten Beispiel aus 1B umfasst der Cluster 150 zehn (10) Server 152, wobei die beispielhaften Server Emulatoren sind. Jeder beispielhafte Emulator (z.B. Server 152) in dem veranschaulichten Beispiel aus 1B umfasst eine beispielhafte Einheit 154, und jede Einheit 154 umfasst fünf beispielhafte Platinen 156. In einigen Beispielen werden Platinen als „Module“ bezeichnet. Dementsprechend beinhaltet das veranschaulichte Beispiel für 1B einen im großen Kasten dargestellten Emulator 150 mit 10 Einheiten oder 50 Platinen, wobei vorliegend offenbarte Beispiele jedoch nicht hierauf eingeschränkt sind.
2A ist eine schematische Darstellung hoher Ebene eines verbesserten Planungssystems 200 zum Annehmen von Jobeingabeinformationen von einer beliebigen Anzahl von Benutzern und zum Verbessern von Jobplanungseffizienz. Das beispielhafte Planungssystem 200 aus 2A umfasst ein Planungs-Framework 202, das Regressionsmodelle, neuronale Netze (NNs), rekurrente NNs (z.B. Long Short Term Memory (LSTMs)) und andere Arten von Modellen nutzt, um eine Vorhersagegenauigkeit zu verbessern (z.B. Vorhersage, welche Ressourcen (z.B. Platinen) belegbar sein werden, welche Ressourcen pro Zeiteinheit beansprucht werden). Das beispielhafte Planungs-Framework 202 aus 2A mischt zwei oder mehr Modelle und/oder Modellierungsansätze, um eine verbesserte Ausgabegenauigkeit zu erreichen. In dem veranschaulichten Beispiel aus 2A umfasst das Planungssystem 200 eine ähnliche Struktur wie in 1A gezeigt.
In dem veranschaulichten Beispiel aus 2A empfängt und/oder ruft das Planungs-Framework 202 anderweitig Daten aus einem Datenspeicher 250 ab und/oder füllt das beispielhafte Planungs-Framework 202 den beispielhaften Datenspeicher 250 basierend auf einer oder mehreren Datenerfassungsaufgaben. In einigen Beispielen wird der Datenspeicher 250 mit SQL- (Sequential Query Language) Systemen betrieben, und in einigen Beispielen wird der Datenspeicher 250 mit Hadoop® betrieben. Vorliegend offenbarte Beispiele können eine beliebige Art von Datenspeicher und/oder Datenbanksystem aufnehmen. Beispielhafte Daten, die in dem Datenspeicher 250 gespeichert sind, umfassen, ohne jedoch hierauf eingeschränkt zu sein, Informationen bezüglich Jobs und/oder Jobanfragen. Der beispielhafte Datenspeicher 250 umfasst Jobmetadaten 252, die beispielhafte Jobprioritätsinformationen (z.B. Informationen, die angeben, welche Jobs eine relativ höchste oder niedrigste Priorität aufweisen), Jobtypen (z.B. Informationen, die einen Jobtyp angeben), Hardwareanforderungen, die mit jeweiligen Jobs verbunden sind (z.B. eine Anzahl von erforderlichen CPU-Kernen zum Ausführen des Jobs, eine Speichermenge, die zum Ausführen des Jobs erforderlich ist, ob der Job aufeinanderfolgende Gruppen von Einheiten im Vergleich zu disparaten Platinen, die über verschiedene Einheiten verteilt sind, umfassen muss usw.). Im Betrieb erzeugt das beispielhafte Planungs-Framework 202 Modelle, die hinsichtlich ihrer Fähigkeit zu bewerten sind, belegbare Ressourcen (z.B. Platinen, Einheiten usw.) und beanspruchte Ressourcen (z.B. Platinen, Einheiten usw.) vorherzusagen. Im Gegensatz zu einer typischen Modellanwendung, wie etwa Maschinenlernmodelle oder Regressionsmodelle, erzeugt das beispielhafte Planungs-Framework 202 Modellkombinationen pro Ressource. Beispielhafte Modelle, die durch vorliegend offenbarte Beispiele in Betracht gezogen werden können, beinhalten K-Nächste-Nachbarn-Algorithmen, Entscheidungsbaum-Algorithmen, lineare Regressionsalgorithmen, Polynom-Regression, künstliche neuronale Netze, Zeitreihenmodelle und Support Vector Machines (SVMs). Vorliegend offenbarte Beispiele verwenden eine Kombination eines LSTM- (Long Short Term Memory) Modells und eines Polynom-Regressionsmodells. Innerhalb jedes LSTM-Modells und Regressionsmodells (z.B. Polynom-Regression) implementiert das beispielhafte Planungs-Framework 202 ein Trainingsmodell und ein Inferenzmodell. Das beispielhafte Inferenzmodell führt eine Echtzeitvorhersage zur Produktion durch und das Trainingsmodell trainiert kontinuierlich über einen Zeitraum. Falls das beispielhafte Trainingsmodell eine verbesserte Vorhersagegenauigkeitsrate entdeckt (z.B. zwei Tage ab jetzt), wird das Inferenzmodell aktualisiert. Zusätzliche Einzelheiten, die einer Modellauswahl, einem Modelltraining, einer Modellelastizitätsverwaltung, Modellgenauigkeitsberechnungen, Modellsicherheitsberechnungen und einer modellinternen Zustandsverwaltung entsprechen, sind nachstehend ausführlicher offenbart.
Das beispielhafte LSTM-Modell blickt für einen Zeitraum zurück. Die Kombination von Polynom-Regression und LSTM ist besonders hilfreich, weil unter Umständen, unter denen eine tiefe Historie zuvor gesammelter Daten nicht verfügbar ist, das beispielhafte Polynom-Regressionsmodell mit einem Attribut mit relativ hoher Komplexität implementiert wird. Wenn historische Daten jedoch verfügbar werden, kann die Komplexität des Polynom-Regressionsmodells mit einer größeren prädiktiven Abhängigkeit von der LSTM-Ausgabe reduziert werden (was die Recheneffizienz verbessert). Somit verbessert die Kombination von Modellen die Genauigkeit von Vorhersagen und die Recheneffizienz, um solche Vorhersagen zu bestimmen. Das genaueste Modell wird als Gewinner angesehen, das Beispiel aus 2A überwacht jedoch kontinuierlich die Modellkombinationen und neue Eingaben, um einen hohen Grad an Vorhersagegenauigkeit beizubehalten. Des Weiteren, und wie nachstehend ausführlich beschrieben, werden Verbesserungen an LSTM-Modellschichten realisiert, um die Effizienz zu erhöhen.
Nachdem das beispielhafte Planungs-Framework 202 Vorhersagen mit den jeweiligen Modellkombinationen (und entsprechenden Attributeinstellungen/Kombinationen) durchgeführt hat, setzt ein beispielhafter Optimierer einen oder mehrere Optimierungsalgorithmen ein, wie etwa eine kombinatorische Optimierung (z.B. Knapsack) und/oder einen Best-Fit-Jobauswahlalgorithmus, wie nachstehend ausführlicher beschrieben.
2B ist eine schematische Darstellung des beispielhaften Planungs-Frameworks 202 aus 2A. Das veranschaulichte Beispiel aus 2B ist auf funktioneller Ebene beschrieben, um unterschiedliche Betriebskonzepte zu vermitteln, und strukturelle Aspekte sind nachstehend in 3A beschrieben. In dem veranschaulichten Beispiel aus 2B werden Metadaten-Momentaufnahmen 254 für Jobs aus den Warteschlangen 256 und Servern 258 jederzeit während des Lernens, Planens oder der Jobzuteilung bezogen. Das beispielhafte Planungssystem 200 identifiziert einen Satz von Kandidatenmodellen 260, die in der Lage sind, eine künftige Belegbarkeit der beispielhaften Server 258 vorherzusagen. Belegbarkeits- oder Beanspruchungsvorhersagen 262 für entsprechende Kandidatenmodelle 260 werden in einer Auswahl-Engine 264 analysiert, um zu bestimmen, welches der Kandidatenmodelle 260 für zukünftige Vorhersageversuche beibehalten werden sollte.
Das beispielhafte Planungssystem 200 leitet die Vorhersagen teilweise basierend auf den abgerufenen Metadaten-Momentaufnahmen 254 ab, und der Bereich von Kandidatenmodellen 260 ist unbegrenzt und kann einfache bis hin zu komplexen Modellen umfassen. Auch wenn möglicherweise viele Modelle existieren, arbeiten unter aktuellen Umständen diese Modelle im Allgemeinen nicht sehr gut. Einige Modelle, die während eines ersten Satzes von Umständen (z.B. bestimmte Jobtypen) schlecht arbeiten, können jedoch in Verbindung mit einem zweiten Satz von Umständen besonders gut arbeiten. Auch wenn ferner anfängliche Berechnungen der Modellleistungsfähigkeit eine besonders gute Genauigkeit darstellen könnten, können solche Genauigkeitsmetriken irreführend sein, wenn entsprechende Modellabruffähigkeiten schlecht sind.
Wie nachstehend beschrieben, werden unterschiedliche Sicherheitsprüfungstechniken auf die beispielhaften Kandidatenmodelle in Echtzeit angewandt, um eine optimale Performanz des beispielhaften Planungssystems 200 beizubehalten. Da eines oder mehrere der Kandidatenmodelle 260 einander widersprechen können, was aufgrund der variierenden Techniken solcher Modelle 260 zu erwarten ist, wendet das Planungssystem unterschiedliche Modellvergleichsversuche an. In einigen Beispielen wendet das Planungssystem 200 begrenzte statistische Variationen an Modellparametern an, anstatt sich strikt auf trainierte feste Werte von Modellparametern zu berufen. Mit anderen Worten werden Modellparameter aus Verteilungen gezogen, die auf solche festen Werte zentriert sind, so dass Inferenzen bei mehreren Durchläufen auftreten können, um eine Streuung von Konfidenzschätzungen und Gewissheitsschätzungen zu erhalten. Somit ermöglicht das beispielhafte Planungssystem 200, wenn Konfidenz- und/oder Gewissheitsschätzungen von einem oder mehreren Schwellenwerten abweichen, einen selbstkorrigierenden und evolutionären Modellverwaltungsprozess durch Verwerfen, Beibehalten oder Neutrainieren entsprechender Modelle auf eine proaktive Weise. Anders ausgedrückt startet sich das beispielhafte Planungssystem 200 durch Ausprobieren und Auswählen unter verschiedenen Vorhersagen unter Verwendung verschiedener Auswahltechniken selbst und führt Modellgewichtungsvariationen (z.B. erzwungene Störungen um ein Mittel zum Ermöglichen evolutionärer/exploratorischer Modellanpassungen/-verbesserungen) auf eine iterative Weise ein. In einigen Beispielen umfassen die unterschiedlichen Auswahltechniken (manchmal als Gütezahlen bezeichnet), die durch die beispielhafte Auswahl-Engine 264 berechnet werden, ohne jedoch hierauf eingeschränkt zu sein, Klassifizierungsgenauigkeitsmetriken, logarithmische Verlustmetriken, Verwirrungsmatrixmetriken, Fläche-unter-der-Kurve-Metriken, F1-Bewertungsmetriken, die ein Gleichgewicht zwischen Genauigkeit und Abruf untersuchen, Metriken für mittlere absolute Fehler und Metriken für mittlere quadratische Fehler.
Das beispielhafte Planungssystem 200 wendet Best-Fit-Abbildungsalgorithmen 266 auf die Jobs an, um zu identifizieren, welche Hardwareressourcen bestimmte Jobs empfangen sollten. Best-Fit-Abbildungsalgorithmen umfassen unterschiedliche Variationen klassischer Bin-Packing-Techniken, wie etwa einen Largest-Best-Fit- (LBF-) Abgleichalgorithmus 268, einen Smallest-Best-Fit- (SBF-) Abgleichalgorithmus 270, einen Knapsack-Algorithmus usw. Zur Veranschaulichung versucht der beispielhafte Knapsack-Algorithmus gewichtete Jobs auf eine solche Weise auszuwählen, dass eine Gesamtgewichtung kleiner oder gleich einem vorhergesagten Gesamtpuffer für Jobs mit hoher Priorität ist. In einigen Beispielen versucht der beispielhafte LBF-Abgleichalgorithmus 268 angesichts eines vorhergesagten Puffers größte Gruppierungen disparater Jobs auszuwählen, um einen Mangel an relativ größeren Jobs zu verhindern. In weiteren Beispielen versucht der beispielhafte SBF-Abgleichalgorithmus 270 angesichts eines vorhergesagten Puffers kleinste Gruppierungen disparater Jobs auszuwählen, um einen Mangel an Jobs relativ niedrigerer Größe zu verhindern.
Das beispielhafte Planungssystem 200 reduziert auch einen Komplexitätsgrad, der mit herkömmlichen Planungsalgorithmen verbunden ist, die in dem Bestreben abbilden, eine Zielfunktion (Q) zu maximieren. Allgemein gesagt bilden traditionelle Planungssysteme Jobs auf eine Weise ab, die der beispielhaften Gleichung 1 entspricht. $R \times S \times T \to Q$
In dem veranschaulichten Beispiel von Gleichung 1 repräsentiert R einen Satz aktueller Jobs (z.B. Anfragen), S repräsentiert einen Satz Ressourcen (z.B. Server) und T repräsentiert Telemetriedaten, die von den Servern verfügbar sind. Die beispielhafte Zielfunktion (Q) repräsentiert einen Satz von Dienstgütezielen, und die Abbildung der beispielhaften Gleichung 1 erzeugt eine neue Verteilung von R x S. Um diese Abbildung durchzuführen, wenden die traditionellen Planungssysteme typischerweise einen Satz von Greedy-Heuristiken an, die mathematisch oder algorithmisch unlösbar werden.
Im Gegensatz zu solchen herkömmlichen Planungssystemen reduzieren vorliegend offenbarte Beispiele einen Grad an Abbildungskomplexität, indem der Aufwand in disparate Teile aufgeteilt wird, die sich auf die Vorhersage zukünftiger Hardwareressourcenverfügbarkeiten beziehen, Abbildungsanfragen und Durchführen später Zuweisungen, wenn Zuteilungslücken auftreten (z.B. infolge dynamischer Telemetrieinformationsänderungen). Das heißt, ein oder mehrere Teile des beispielhaften Planungssystems 200 arbeiten nicht isoliert.
3A ist eine schematische Darstellung des beispielhaften Planungs-Frameworks 202 aus 2A und 2B. In dem veranschaulichten Beispiel aus 3A weist das Planungs-Framework 202 einen beispielhaften Datenabrufer 204, einen beispielhaften Architekturanalysierer 206, einen beispielhaften Matrixgenerator 208 und einen beispielhaften Modellersteller 210 auf. Das veranschaulichte Beispiel aus 3A umfasst zudem einen beispielhaften Modellbewerter 212, der einen beispielhaften Merkmalgenerator 216, einen beispielhaften Kennzeichnungstrainer 218, einen beispielhaften Prioritätsmetrikmanager 230, einen beispielhaften Modellgenauigkeits- und Gewissheitsbewerter 232, einen beispielhaften Modellzustandsbeurteiler 236 und einen beispielhaften Pufferbewerter 234 umfasst. Das veranschaulichte Beispiel aus 3A umfasst zudem einen beispielhaften Optimierer 214, der einen beispielhaften Schlüsselbewerter 220 und einen beispielhaften Jobbewerter 224 und einen beispielhaften Klassifizierermanager 240 umfasst. In einigen Beispielen implementiert der beispielhafte Datenabrufer 204 Mittel zum Abrufen von Daten, die vorliegend mitunter als Datenabrufmittel bezeichnet werden. In einigen Beispielen implementiert der beispielhafte Architekturanalysierer 206 Mittel zum Analysieren einer Architektur, die vorliegend mitunter als Architekturanalysemittel bezeichnet werden. In einigen Beispielen implementiert der beispielhafte Matrixgenerator 208 Mittel zur Matrixerzeugung, die vorliegend mitunter als Matrixerzeugungsmittel bezeichnet werden. In einigen Beispielen implementiert der beispielhafte Modellersteller 210 Mittel zum Erstellen von Modellen, die vorliegend mitunter als Modellerstellungsmittel bezeichnet werden. In einigen Beispielen implementiert der beispielhafte Modellbewerter 212 Mittel zum Bewerten von Modellen, die vorliegend mitunter als Modellbewertungsmittel bezeichnet werden. In einigen Beispielen implementiert der beispielhafte Merkmalgenerator 216 Mittel zum Erzeugen von Merkmalen, die vorliegend mitunter als Merkmalserzeugungsmittel bezeichnet werden. In einigen Beispielen implementiert der beispielhafte Kennzeichnungstrainer 218 Mittel zum Trainieren von Kennzeichnungen, die vorliegend mitunter als Kennzeichnungstrainingsmittel bezeichnet werden. In einigen Beispielen implementiert der beispielhafte Prioritätsmetrikmanager 230 Mittel zum Verwalten von Prioritätsmetriken, die vorliegend mitunter als Prioritätsmetrikverwaltungsmittel bezeichnet werden. In einigen Beispielen implementiert der beispielhafte Modellgenauigkeits- und Gewissheitsbewerter 232 Mittel zum Bewerten von Modellgenauigkeit und -gewissheit, die vorliegend mitunter als Modellgenauigkeits- und - gewissheitsbewertungsmittel bezeichnet werden. In einigen Beispielen implementiert der beispielhafte Modellzustandsbeurteiler 236 Mittel zur Zustandsbeurteilung, die vorliegend mitunter als Zustandsbeurteilungsmittel bezeichnet werden. In einigen Beispielen implementiert der beispielhafte Pufferbewerter 234 Mittel zum Bewerten von Puffer, die vorliegend mitunter als Pufferbewertungsmittel bezeichnet werden. In einigen Beispielen implementiert der beispielhafte Optimierer 214 Mittel zum Optimieren, die vorliegend mitunter als Optimierungsmittel bezeichnet werden. In einigen Beispielen implementiert der beispielhafte Schlüsselbewerter 220 Mittel zum Bewerten von Schlüsseln, die vorliegend mitunter als Schlüsselbewertungsmittel bezeichnet werden. In einigen Beispielen implementiert der beispielhafte Jobbewerter 224 Mittel zum Bewerten von Jobs, die vorliegend mitunter als Jobbewertungsmittel bezeichnet werden. In einigen Beispielen implementiert der beispielhafte Klassifizierermanager 240 Mittel zum Verwalten von Klassifizierern, die vorliegend mitunter als Klassifiziererverwaltungsmittel bezeichnet werden.
Im Betrieb ruft der beispielhafte Datenabrufer 202 Daten aus einem Datenspeicher (z.B. die beispielhaften Jobmetadaten 252) ab und ruft der beispielhafte Architekturanalysierer 206 Ziel-Hardwarearchitekturinformationen wie etwa eine Architekturabbildung ab. In einigen Beispielen analysiert der Architekturanalysierer 206 kommunikativ verbundene Hardwareressourcen, wie etwa den beispielhaften Cluster 150 aus FIG. IB. Der beispielhafte Architekturanalysierer 206 bestimmt eine Anzahl verfügbarer Server 152, eine Anzahl zugehöriger Einheiten 154 und eine Anzahl entsprechender Platinen 156, die darin enthalten sind. Wie nachstehend ausführlicher beschrieben, koordiniert sich der beispielhafte Architekturanalysierer 206 mit dem beispielhaften Matrixgenerator 208, um jede verfügbare Ressource zu kennzeichnen, die bei der Jobaufgabenverarbeitung helfen kann. Der beispielhafte Matrixgenerator 208 entwirft eine Datensatzmatrix und der beispielhafte Architekturanalysierer 206 wählt eine oder mehrere Ressourcen (z.B. eine Serverressource, einen Satz von Serverressourcen, Edge-basierte Ressourcen (z.B. IoT-Einrichtungen)) aus, die für Beanspruchungsaktivität vorhergesagt werden sollen. Die beispielhafte Datensatzmatrix, die durch den beispielhaften Matrixgenerator 208 entworfen wird, kann (z.B. in Verbindung mit den beispielhaften Hardwareressourcen aus 1B) Folgendes umfassen:

• Eine Gesamtanzahl von Platinen, die jeweilige Jobtypen ausführen
• Eine Gesamtanzahl von Platinen zum Ausführen aller wartenden Jobtypen
• Eine Gesamtanzahl ausgeführter Einzeljobs
• Einer Gesamtanzahl wartender Einzeljobs
• Eine fünfstellige numerische Zahl, die im Gebrauch befindliche und freie/belegbare einzelne Platinen in jeweiligen Einheiten darstellt

3B bis 3E veranschaulichen beispielhafte Tabellen, die durch den beispielhaften Matrixgenerator 208 erzeugt werden, wobei die Tabellen Informationen einpflegen, die mit kommunikativ verbundenen Ressourcen eines oder mehrerer Cluster, wie etwa des beispielhaften Clusters 150 aus 1B, zusammenhängen. In dem veranschaulichten Beispiel aus 3B umfasst eine Jobverfolgungstabelle 302 eine Typ-A-Ausführungsspalte 304, eine Typ-B-Ausführungsspalte 306, eine Typ-C-Ausführungsspalte 308 und eine Typ-A-Wartespalte 310. Kurz gesagt und nachstehend ausführlicher beschrieben, sind unterschiedliche Jobanfragen unterschiedlichen Zielen/Typen zugeordnet. Ein beispielhafter erster Jobtyp (z.B. Typ A) kann bestimmte Ressourcenzuteilungsnuancen beinhalten, die sich von einem zweiten Jobtyp (z.B. Typ B) unterscheiden. Eine beispielhafte Jobnummernspalte 312 veranschaulicht eine Jobnummernkennung, die sich in dem veranschaulichten Beispiel aus 3B von Job null bis vierzehn erstreckt. Eine beispielhafte erste Zeile 314 der beispielhaften Jobverfolgungstabelle 302 umfasst Informationen, die einem ersten Job (Job null) zugeordnet sind, die angeben, dass es gegenwärtig 44 (vierundvierzig) Platinen gibt, die gegenwärtig einen Job des Typs A ausführen (z.B. laufen lassen) (siehe Bezugszeichen 316). Zudem gibt die beispielhafte erste Zeile 314 an, dass der Job Null null Platinen aufweist, die gegenwärtig einen Job vom Typ B ausführen (siehe Bezugszeichen 318), sechs Platinen, die gegenwärtig einen Job vom Typ C ausführen (siehe Bezugszeichen 320) und 348 Jobs, die auf eine Platinenzuteilung von Typ-A-Jobs warten (siehe Bezugszeichen 322).
Wie vorstehend beschrieben, können unterschiedliche Jobtypen unterschiedliche Anforderungen aufweisen, wenn sie ausgeführt werden. In einigen Beispielen wird ein erster Jobtyp (z.B. Jobtyp „A“) als eine relativ höhere Priorität als ein zweiter Jobtyp (z.B. Jobtyp „B“) angesehen. Somit erfolgen Versuche, jeweiligen Verarbeitungsressourcen einen relativ höheren Jobtyp zuzuteilen, bevor diesen Verarbeitungsressourcen ein relativ niedrigerer Jobtyp zugewiesen wird. In einigen Beispielen bestimmt jedoch die bloße Verfügbarkeit von Ressourcen nicht notwendigerweise, dass diese Ressourcen einem entsprechenden Job zugewiesen werden sollten. Das heißt, bestimmte Jobs können eindeutige Ressourcenbedingungen erfordern, wie etwa eine bestimmte Anzahl von Verarbeitungskernen, eine bestimmte Anzahl aufeinanderfolgender Platinen innerhalb einer Einheit, eine bestimmte Anzahl aufeinanderfolgender Einheiten, in denen alle zugehörigen Platinen für den Job dediziert sind usw. Solche Bedingungen werden durch den beispielhaften Matrixgenerator 208 erfasst und eingepflegt.
In dem veranschaulichten Beispiel aus 3C erzeugt der beispielhafte Matrixgenerator 208 zusätzliche Metriken/Details der beispielhaften Jobverfolgungstabelle 302. Allgemein gesagt können 3B bis 3E dieselbe Jobverfolgungstabelle 302 mit unterschiedlichen Typen von eingepflegten Informationen darstellen, die Jobs, Jobtypen, notwendigen Jobbedingungen und/oder zugeordneten Ressourcen, die jeweiligen Jobs zugeteilt wurden, zugeordnet sind. 3C veranschaulicht eine beispielhafte Typ-A-Job-Zählerspalte 324, die angibt, dass gegenwärtig vier Jobs vom Typ A ausgeführt werden (siehe Bezugszeichen 326). Es ist anzumerken, dass das veranschaulichte Beispiel aus 3B angibt, dass 44 Platinen für Jobs vom Typ „A“ dediziert sind, während 3C angibt, dass diese 44 Platinen auf vier separate Instanzen eines Jobs vom Typ „A“ verteilt sind.
In dem veranschaulichten Beispiel aus 3D erzeugt der beispielhafte Matrixgenerator 208 zusätzliche Metriken/Details der beispielhaften Jobverfolgungstabelle 302. 3D veranschaulicht eine beispielhafte Spalter 328 für eine Anforderung mehrerer Einheiten, die angibt, dass aktuell vier Jobs ausgeführt werden, die jeweils eine Zuteilung von zwei Einheiten erfordern (siehe Bezugszeichen 330). In einigen Beispielen muss die Mehrfachressourcenanforderung zudem aufeinanderfolgender Natur sein.
In dem veranschaulichten Beispiel aus 3E erzeugt der beispielhafte Matrixgenerator 208 zusätzliche Metriken/Details der beispielhaften Jobverfolgungstabelle 302. 3E veranschaulicht eine beispielhafte Binärfolgenspalte 332 von Einheit Null mit einer zugehörigen Binärfolge (siehe Bezugszeichen 334), die einen Platinenstatus für jede jeweilige Platine innerhalb der Einheit Null angibt. Da zum Beispiel die beispielhafte Binärfolge 334 fünf (5) ganzzahlige Werte umfasst, weist die Einheit Null fünf Platinen auf. Zusätzlich kann jede ganze Zahl innerhalb der beispielhaften Binärfolge 334 einen jeweiligen Wert zum Identifizieren eines Platinenstatus umfassen. In dem veranschaulichten Beispiel aus 3E repräsentiert ein Ganzzahlwert von „1“, dass eine Platine verwendet wird (und für einen anderen Job nicht verfügbar ist). Ein Ganzzahlwert von „2“ repräsentiert, dass eine Platine belegbar und somit in der Lage ist, einem Job zugewiesen zu werden (oder in der Lage ist, sich einen Job zuweisen zu lassen). Ein Ganzzahlwert von „3“ repräsentiert, dass eine Platine gesperrt ist, was ein Problem/einen Defekt der Platine angeben kann.
Die in den veranschaulichten Beispielen aus 3B bis 3E können als zeitliche Momentaufnahme der Hardware und zugehöriger Jobs betrachtet werden, die dieser zugewiesen sind. Momentaufnahmen der Hardware und zugehöriger Jobs können durch das beispielhafte Planungs-Framework 202 mit einer beliebigen Frequenz von Interesse durchgeführt werden, wie etwa einmal pro Minute, einmal pro Stunde usw. Zusätzlich, und wie vorstehend beschrieben, kann dieser bestimmte Aspekt des Planungs-Frameworks 202 isoliert und/oder anderweitig unabhängig von einer oder mehreren anderen Operationen arbeiten, die auf Modelltrainings-, Modellanalyse- und/oder Jobzuweisungsaufgaben ausgerichtet sind. Die zu jeder Momentaufnahme gehörigen Daten können in einem Speicher, wie etwa dem beispielhaften Datenspeicher 250 aus 2, gespeichert werden, in dem die Daten später in Vorhersageaufgaben verwendet werden. Insbesondere stellt die in 3B bis 3E gezeigte beispielhafte Jobverfolgungstabelle eine Eigenschaftsstruktur dar, die Verhaltensweisen des beispielhaften Planungssystems 200 aufzeigt. Mit anderen Worten erfassen typische Maschinenlernprozesse verfügbare Daten in einem Bestreben, Vorhersagen und/oder Zuordnungen zu treffen und/oder entstehende Muster zu identifizieren. Solche Maschinenlernansätze sind besonders hilfreich, wenn das Volumen zugehöriger Verhaltensdaten besonders groß ist und eine entsprechende Anzahl eindeutiger Eigenschaften relativ zahlreich ist. Die beispielhafte Jobverfolgungstabelle 302 erzeugt eine tiefere Eigenschaftsgranularität, um dem Maschinenlernprozess zu helfen, solche Vorhersagen, Zuordnungen und/oder entstehende Muster zu identifizieren. Ohne die beispielhafte Jobverfolgungstabelle 302 umfassen spätere Maschinenlernoperationen möglicherweise keine ausreichende Anzahl und/oder Vielfalt eindeutiger Systemeigenschaften, um solche entstehenden Muster zu identifizieren.
Unter erneuter Bezugnahme auf 3A lädt der beispielhafte Modellersteller 210 einen Teilsatz von Daten in das LSTM-Modell und lädt einen Teilsatz von Daten in das Polynom-Regressionsmodell, und der beispielhafte Modellbewerter 212 bewertet die Modelle, um Vorhersagemetriken zu erzeugen. Zusätzlich wendet der beispielhafte Optimierer 214 einen oder mehrere Optimierungsalgorithmen unter Verwendung von Vorhersagemetriken an.
In einigen Beispielen berücksichtigt das Planungs-Framework 202 die Umstände, unter denen viele verschiedene Arten von Eingaben bezogen und an Kandidaten-und ausgewählte Modelle weitergeleitet werden. Solche Eingaben können überwältigend sein und zum einen zu einer Instrumenten- und Datenverarbeitungsüberlastung führen und zum anderen zu einer Überanpassung aufgrund hoher Kollinearitäten von Beobachtungen führen. Um diese Effekte zu reduzieren, gruppieren vorliegend offenbarte Beispiele die Jobs basierend auf unterschiedlichen Kriterien (z.B. Quellen der Jobanfragen, Jobanfrage-Tags/Metadaten usw.) in unterschiedliche oder anderweitig diskrete Typen. Anders ausgedrückt erzeugen vorliegend offenbarte Beispiele Footprints als logische Untergruppierungen von Jobanfragen. Auf diese Weise können bestimmte Jobtypen an entsprechende Modelle geliefert werden, die in der Lage sind, zuverlässige Vorhersagen der Ressourcenverfügbarkeit anzuzeigen.
Im Betrieb erfasst der beispielhafte Datenabrufer 204 aus 3A (a) Jobtyp-Daten aktuell ausgeführter Jobs (auf Hardwareressourcen), (b) Jobtyp-Daten von Jobs, die noch nicht Hardwareressourcen zugewiesen sind, sondern sich in einer oder mehreren Warteschlangen befinden, und (c) aktuelle Hardwareverfügbarkeitsmetriken (z.B. eine Menge verfügbarer Hardwareressourcen, egal ob solche Ressourcen kontinuierlich sind, Ressourcentypen usw.). Der beispielhafte Jobbewerter 224 führt eine Jobtyp-Gruppierung basierend auf einem beliebigen Typ einer gewünschten Charakteristik durch, wie etwa Jobtypen, die eine spezifische Anzahl von Verarbeitungskernen erfordern, Jobtypen, die physisch benachbarte Hardwareressourcen erfordern, die mit bestimmten Busbandbreitenfähigkeiten miteinander verbunden sind usw. Der beispielhafte Klassifizierermanager 240 wendet einen oder mehrere Klassifizierungsalgorithmen (z.B. einen Entscheidungsbaum, einen Permutationsbaum usw.) an, um Kandidaten-Footprints zu erzeugen, und wendet einen Normalisierer an, um die Footprints an eine Verteilung anzupassen. In einigen Beispielen ist der Normalisierer eine Anpassungstransformationsfunktion, wie etwa beispielhafte SciKit-learn®-Algorithmen. Der beispielhafte Optimierer 214 weist dann Kandidatenmodelle zu, die Charakteristiken eines größten Teils der Verteilung entsprechen, wodurch bestimmte Jobs mit den Modellen abgeglichen werden, die am wahrscheinlichsten optimierte Vorhersagemetriken aufweisen.
Während der Operationen, die mit dem Bewerten von Modellen zum Erzeugen der Vorhersagemetriken verbunden sind, importiert der beispielhafte Merkmalgenerator 216 Linear-Regressions- und Polynom-Merkmale und legt Merkmalswerte entsprechend fest. Der beispielhafte Kennzeichnungstrainer 218 passt einen transformierten Datensatz an und trainiert die entsprechenden Kennzeichnungen. In einigen Beispielen passt der Kennzeichnungstrainer 218 in einem Funktionsaufruf den Datensatz an und transformiert diesen, der zum Beispiel Überlegungen zu Standardabweichung, Durchschnitt(en), Normalisierungen usw. beinhaltet. Der beispielhafte Modellbewerter 212 erzeugt Vorhersagen unter Verwendung des Polynom-Regressionsmodells und des LSTM-Modells und bestimmt, ob die Vorhersagewertgenauigkeit einen oder mehrere Schwellenwerte erfüllt, wie nachstehend ausführlicher beschrieben wird. Falls nicht, wird das Modell erneut trainiert. Falls ja, wird das Modell gespeichert und zur weiteren Optimierungsanalyse verwendet.
Während einer solchen Optimierung bezieht der beispielhafte Datenabrufer Eingaben, und der beispielhafte Schlüsselbewerter 220 initiiert eine Schleife, die mit einer Schlüsseljobgröße in umgekehrter Reihenfolge beginnt (z.B. unter Verwendung einer Wörterbuch-Datenstruktur mit einem oder mehreren Schlüsseln). Der beispielhafte Schlüsselbewerter 220 bestimmt, ob alle Schlüssel berücksichtigt oder anderweitig analysiert wurden, und bestimmt, falls nicht, ob der Schlüssel leer ist. Falls ja, wird ein nächster Schlüssel ausgewählt. Andernfalls bestimmt der beispielhafte Architekturanalysierer 206, ob eine Anzahl verfügbarer Ressourcen null ist. Falls nicht, geht der beispielhafte Schlüsselbewerter 220 in einer Schleife Jobkennungen (IDs) für den ausgewählten Schlüssel durch. Der beispielhafte Jobgrößenbewerter 224 bestimmt, ob die Jobgröße kleiner oder gleich einer Anzahl verfügbarer Ressourcen (z.B. einer Anzahl von Prozessoren einer Hardware-Suite) ist. Falls ja, dann wird die Job-ID angehängt, und der Jobgrößenbewerter 224 entfernt den angehängten Job aus der Liste, um eine Neuanalyse desselben zu verhindern. Der beispielhafte Jobgrößenbewerter 224 dekrementiert den Jobgrößenwert und bestimmt, ob er größer als eine Anzahl verfügbarer Ressourcen ist. Falls nicht, wird die nächste Job-ID durch den beispielhaften Schlüsselbewerter 220 ausgewählt. Falls ja, wählt der beispielhafte Schlüsselbewerter 220 jedoch einen nächsten Schlüssel aus.
In einigen Beispielen setzt das Planungs-Framework 202 eine Maschinenlernarchitektur ein, in der ein Benutzer einen Zeitrahmen entscheiden kann, für den Modelle verfügbare Ressourcen vorhersagen sollten. 4A ist eine schematische Darstellung beispielhafter Maschinenlernmodellzuweisungen 400, bei denen Maschinenlernmodelle auf einer Pro-Server-Basis (z.B. Pro-Ressourcen-Basis) 402 zugewiesen werden. In dem veranschaulichten Beispiel aus 4A ist eine beispielhafte zeitliche (z.B. eine Stunde) Vorhersagemodellarchitekturinstanz für Emulationsressourcen gezeigt. In dem veranschaulichten Beispiel aus 4A enthält jede Datenverarbeitungsressource 404 (z.B. Server) 24 Instanzen eines Modells 406 (z.B. eine für jede Stunde), wobei jedoch die beispielhaften zeitlichen Darstellungen aus 4A zu Beispielzwecken und nicht einschränkend verwendet werden. Eine Anzahl von Modellinstanzen ist gleich 24 geteilt durch eine gewünschte Zeitrahmenlänge in Stunden. In jedem beispielhaften zeitlichen (z.B. Stunde) Modell (z.B. eine erste Zeitrahmeninstanz 408, eine zweite Zeitrahmeninstanz usw.) gibt es 11 beispielhafte Instanzen von Modellen, die jede Einheit und die Datenverarbeitungsressource repräsentieren.
4 B ist ein beispielhaftes Flussdiagramm 410 der beispielhaften schematischen Darstellung aus 4A. In dem veranschaulichten Beispiel aus 4B werden Jobmetadaten 252 (z.B. aus dem beispielhaften Datenspeicher 250) und/oder Daten aus Momentaufnahmen der beispielhaften Jobverfolgungstabelle 302 als Eingaben bereitgestellt. In einigen Beispielen werden Daten auf eine parallele Weise bereitgestellt, um Modelle in einer zeitlichen Reihenfolge zu aktivieren, auf die eine oder mehrere Vorhersagen auf einer Pro-Einheit-Basis folgen.
Vorliegend offenbarte Beispiele verbessern zudem einen Grad an Resilienz des einen oder der mehreren Kandidatenmodelle, die zum Vorhersagen von Ressourcenverfügbarkeit verwendet werden. Insbesondere führen vorliegend offenbarte Beispiele eine Beurteilung einer Modellrisikoreduktion angesichts sich ändernder Prioritätsmetriken/-richtlinien durch. In einigen vorliegend offenbarten Beispielen beurteilt das Planungs-Framework 202 Modellgenauigkeit und Modellgewissheit, wodurch ermöglicht wird, dass bestimmte Gewichtungen auf Modelle basierend auf ihrer Performanz angewendet werden. In weiteren Beispielen beurteilt das Planungs-Framework 202 einen Puffer der Ressourcenzuteilung. Allgemein gesagt stellt Puffer einen gezielten Versuch dar, einen oder mehrere Teile verfügbarer Ressourcen für zukünftige Gelegenheiten auszulassen. Falls beispielsweise ein bestimmter Jobtyp eine Sequenz von zwei oder mehr kommunikativ verbundenen physisch benachbarten Hardwareressourcen erfordert, aber derzeit keine solche Verfügbarkeit besteht, behält das beispielhafte Planungs-Framework 202 die Zuweisung solcher physisch benachbarten Ressourcen zurück, bis sie einen aktuellen Job abschließen, um dann für den bestimmten Jobtyp zur Verfügung zu stehen. In weiteren Beispielen beurteilt das Planungs-Framework 202 interne Zustände von Modellen, um eine oder mehrere Schichten zu identifizieren, die möglicherweise nicht auf eine relevante Weise arbeiten. Die vorstehend erwähnten Modellresilienzmerkmale werden im Folgenden erörtert.
Um eine Modellrisikoreduktion zu beurteilen, überwacht der beispielhafte Prioritätsmetrikmanager 230 Änderungen auftretender Bedingungen und bestimmt, ob Prioritätsmetriken geändert wurden. Bestimmten Jobtypen werden unter bestimmten Umständen „fliegend“ dynamisch unterschiedliche Prioritäten zugewiesen. Falls sie unüberwacht gelassen werden, dann können diese dynamischen Anfragen (z.B. Änderungen, die von einem Benutzer des Planungssystems 200 eingegeben werden) von herkömmlichen Planungssystemen unberücksichtigt bleiben. Unter bestimmten Umständen existiert eine erste Latenzanforderung zu einem ersten Zeitpunkt, während eine zweite (andere) Latenzanforderung zu einem zweiten Zeitpunkt existiert (z.B. eine maximale Zeitdauer, die ein Job benötigen soll, wenn er durch zugewiesene Hardwareressourcen verarbeitet wird). Bei einer standardmäßigen/traditionellen LSTM-Implementierung werden starre oder anderweitig statische Berechnungen in Verbindung mit einer Kostenfunktion durchgeführt. Somit werden die zwei unterschiedlichen Latenzanforderungen nicht unterschiedlich gewichtet.
Der beispielhafte Prioritätsmetrikmanager 230 ermöglicht jedoch eine Bewertung (von Prioritätsmetriken) zu einem ersten Zeitpunkt und eine Auswahl zu einem zweiten Zeitpunkt, um mögliche Metrikänderungen zu berücksichtigen. Mit anderen Worten erfolgt eine flexible Risikoreduktion. Der beispielhafte Prioritätsmetrikmanager 230 ruft die Prioritätsmetriken periodisch, aperiodisch, geplant oder manuell ab und bestimmt, ob sich solche Prioritätsmetriken seit einer vorherigen Überprüfung geändert haben. In einigen Beispielen werden bestimmte Prioritätsmetriken mit einem Schwellenwert verglichen, der, falls erfüllt, bewirkt, dass der Prioritätsmetrikmanager 230 eine oder mehrere Gewichtungen einer Kostenfunktion anpasst. Somit kann die Kostenfunktion Belohnungen gemäß einer oder mehreren kürzlich geänderten Prioritäten bewerten.
Um eine Modellgenauigkeit und -gewissheit zu beurteilen, wählt der beispielhafte Modellgenauigkeits- und -gewissheitsbewerter 232 ein interessierendes Modell aus. Modellgenauigkeit und -gewissheit werden durch den beispielhaften Bewerter 232 berechnet, um relative Performanzmetriken zu bestimmen. Allgemein gesagt ist eine Genauigkeitsmetrik eines jeweiligen Modells eine Darstellung, wie gut dieses Modell ein Ergebnis korrekt vorhersagt (z.B. in den nächsten 30 Sekunden besteht eine Verfügbarkeit von 60 % in einer oder mehreren Ressourcen). Wenn solche Genauigkeitsmetriken bekannt sind, können entsprechende Gewichtungen an der durch dieses Modell erzeugten Ausgabe angepasst werden (z.B. eine relativ höhere Gewichtung, wenn das Modell relativ genauer arbeitet, und umgekehrt). Eine Gewissheitsmetrik eines jeweiligen Modells ist andererseits eine Darstellung der Konsistenz des interessierenden Modells. Die Gewissheit gibt Einsicht darüber, wie das Modell trainiert wurde. Beispielsweise könnte ein Modell die Fähigkeit aufweisen, für einen Eingabetyp mit einem Schwellengenauigkeitsgrad zu arbeiten, aber diese Modellperformanz könnte sich wesentlich ändern, falls die Eingabe von irgendeiner Betriebsnorm abweicht, wodurch die Konsistenz dieses Modells negativ beeinflusst wird. Mit anderen Worten könnte die Beobachtung, dass das Modell gut gearbeitet hat, als Zufall betrachtet werden, dass dieses Modell aber möglicherweise nicht konsistent arbeitet oder anderweitig in einer relativ diversen Eingabeeinstellung vertrauenswürdig ist.
Vorliegend offenbarte Beispiele berücksichtigen diese zwei Eigenschaften von Modellen und messen eine Modellgewissheit unter Verwendung einer oder mehrerer Bayes'scher Prozeduren/Analysen. In einigen Beispielen stört der Modellgenauigkeits- und - gewissheitsbewerter 232 Modelle und berechnet dann Genauigkeits- und Gewissheitsmetriken erneut, um genauer festzustellen, ob das Kandidatenmodell im Vergleich zu anderen Kandidatenmodellen mehr oder weniger fähig (oder vertrauenswürdig) ist. Auch hier können diese Bestrebungen, Modellkonfidenz zu nutzen, durch das beispielhafte Simulations-Framework 202 unabhängig von einer oder mehreren anderen Planungsaufgaben durchgeführt werden. Die resultierenden Genauigkeits-und Konsistenzmetriken, die durch den beispielhaften Modellgenauigkeits- und -gewissheitsbewerter 232 bestimmt werden, werden normalisiert, um eine aggregierte Bewertung zu erzeugen, die auf jedes Modell angewendet (gewichtet) werden kann.
Um Puffermetriken der verfügbaren Ressourcen zu beurteilen, berechnet der beispielhafte Pufferbewerter 234 eine Menge (z.B. eine Menge verfügbarer Kerne) nicht zugeteilter Ressourcen für einen interessierenden Zeitraum. Falls der beispielhafte Pufferbewerter 234 bestimmt, dass ein oder mehrere Jobs in einer Warteschlange angehalten werden, dann wird Puffer für zukünftige Gelegenheiten zugewiesen und die Kostenfunktion wird angepasst, um die Wichtigkeit einer oder mehrerer Prioritäten widerzuspiegeln, die den eingereihten Jobs zugeordnet sind.
Um interne Zustände von Modellen zu beurteilen, wählt der beispielhafte Modellzustandsbeurteiler 236 ein interessierendes Modell, wie etwa ein LSTM-Modell, aus. Eine der Schichten des ausgewählten LSTM-Modells wird durch den Modellzustandsbeurteiler 236 ausgewählt und eine Wahrscheinlichkeit, die dieser Schicht entspricht, wird berechnet. Allgemein gesagt treten manche Zustände im Vergleich zu anderen Zuständen relativ wahrscheinlicher auf. Unter Verwendung des Schachspiels als Analogie treten einige gegnerische Züge (die einer ersten Schicht entsprechen) wahrscheinlicher auf als andere gegnerische Züge (die einer zweiten Schicht entsprechen), wenn der Gegner versucht, das Spiel zu gewinnen. Somit repräsentieren jeweilige Züge, die weniger wahrscheinlich sind, Teile des LSTM-Modells, die während einer Inferenzaktivität weniger oder keine Aufmerksamkeit erfordern, wodurch Modellenergieanforderungen und Verbrauchsanforderungen von Datenverarbeitungsressourcen reduziert werden. Der beispielhafte Modellzustandsbeurteiler 236 vergleicht Schichtwahrscheinlichkeitswerte mit einem oder mehreren Schwellenwerten, die, falls erfüllt, bestimmen, ob diese spezielle Schicht beibehalten wird (für weitere Inferenzen) oder ausgesondert wird (um Datenverarbeitungsressourcen zu sparen).
Wie vorstehend besprochen, helfen Teile-und-herrsche-Techniken, die durch vorliegend offenbarte Beispiele implementiert werden, Maschinenlernoperationen zu vereinfachen, ohne einen linearen Planungsaufwand in Echtzeit zu erzwingen. Zur Veranschaulichung ist 4C eine schematische Darstellung eines beispielhaften High-Level-Planungssystems 420 zum Anwenden eines Teile-und-herrsche-Ansatzes auf Jobplanungsbestrebungen. In dem veranschaulichten Beispiel aus 4C umfasst das Planungssystem 420 einen Teil 422 erster Ebene, der einem Vorhersagen eines Gesamtgrads an Ressourcenbelegbarkeit entspricht, und einen Teil 424 zweiter Ebene, der einem Auffinden bester Jobs zur Planung für die Ressourcen entspricht. In Übereinstimmung mit dem Vorstehenden arbeiten diese Teile nicht notwendigerweise im Gleichtakt oder seriell, sondern können unabhängig nach Verfügbarkeit von Systemverarbeitungsbandbreite und/oder dynamischer Dateneingabe durchgeführt werden.
Der beispielhafte Modellersteller 210 erfasst eine Liste von Modellen 426 und der beispielhafte Modellgenauigkeits- und -gewissheitsbewerter 232 berechnet eine oder mehrere Vorhersagebewertungsmetriken 428 (z.B. Genauigkeitsberechnungen, Konfidenzberechnungen usw.). In einigen Beispielen entsprechen die Metriken F 1-Bewertungsberechnungen 430 (z.B. einer hybriden Bewertung basierend auf Modellgenauigkeitsfähigkeiten und Modellabruffähigkeiten) und/oder Berechnungen 432 mittlerer absoluter Fehler. Falls der Modellersteller 210 bestimmt, dass ein oder mehrere Schwellenwerte nicht erfüllt sind, wird ein alternatives Modell ausgewählt 434. Anders ausgedrückt lösen Schwellenwerte, die nicht erfüllt sind, einen oder mehrere Neutrainingsversuche und/oder alternative Modellauswahlen aus. Falls der eine oder die mehreren Schwellenwerte jedoch erfüllt sind, dann behält der beispielhafte Optimierer 214 das Modell zur Jobauswahl in einer Warteschlange 436 bei.
Mit fortschreitender Zeit baut sich die beispielhafte Warteschlange 436 auf und der beispielhafte Teil 424 zweiter Ebene fährt fort, wenn sich ausreichend Jobs in der beispielhaften Warteschlange 436 befinden oder wenn Jobs mit besonders hoher Priorität eine sofortige Aufmerksamkeit erfordern. Der beispielhafte Klassifizierungsmanager 240 wendet einen oder mehrere Greedy-Algorithmen auf eine Zielfunktion (z.B. die Kostenfunktion) in einem Versuch an, zu identifizieren, wo spezifische Jobs innerhalb der Warteschlange 436 zugewiesen werden sollten. Die Greedy-Algorithmen umfassen, ohne jedoch hierauf eingeschränkt zu sein, einen Smallest-Best-Fit- (SBF-) Algorithmus 438, einen Largest-Best-Fit- (LBF-) Algorithmus 440 und einen Knapsack-Algorithmus 442.
Die beispielhaften Greedy-Algorithmen der beispielhaften Warteschlange 436 gruppieren die Jobs auf unterschiedliche Weisen, die den jeweiligen Algorithmuszielen entsprechen, die in einer sekundären Warteschlange 444 gezeigt sind. Der beispielhafte Optimierer 214 weist dann die passenden Jobs verfügbaren Ressourcen 446 zu.
Auch wenn eine beispielhafte Art und Weise der Implementierung des verbesserten Planungssystems 200 und des beispielhaften Planungs-Framework 202 aus 2, 3A-3E, 4A und 4B in 2, 3A-3E, 4A und 4B veranschaulicht sind, können eines oder mehrere der in 2, 3A-3E, 4A und 4B veranschaulichten Elemente, Prozesse und/oder Einrichtungen kombiniert, aufgeteilt, umgeordnet, weggelassen, eliminiert und/oder auf eine beliebige andere Weise implementiert werden. Ferner können der beispielhafte Datenabrufer 204, der beispielhafte Architekturanalysierer 206, der beispielhafte Matrixgenerator 208, der beispielhafte Modellersteller 210, der beispielhafte Modellbewerter 212, der beispielhafte Merkmalgenerator 216, der beispielhafte Kennzeichnungstrainer 218, der beispielhafte Prioritätsmetrikmanager 230, der beispielhafte Modellgenauigkeits- und - gewissheitsbewerter 232, der beispielhafte Pufferbewerter 234, der beispielhafte Modellzustandsbeurteiler 236, der beispielhafte Optimierer 214, der beispielhafte Schlüsselbewerter 220, der beispielhafte Jobbewerter 224, der beispielhafte Klassifizierermanager 240 und/oder allgemeiner das beispielhafte Planungs-Framework 202 aus 2A, 2B und 3A durch Hardware, Software, Firmware und/oder eine beliebige Kombination von Hardware, Software und/oder Firmware implementiert werden. Somit können zum Beispiel beliebige des beispielhaften Datenabrufers 204, des beispielhaften Architekturanalysierers 206, des beispielhaften Matrixgenerators 208, des beispielhaften Modellerstellers 210, des beispielhaften Modellbewerters 212, des beispielhaften Merkmalgenerators 216, des beispielhaften Kennzeichnungstrainers 218, des beispielhaften Prioritätsmetrikmanagers 230, des beispielhaften Modellgenauigkeits- und - gewissheitsbewerters 232, des beispielhaften Pufferbewerters 234, des beispielhaften Modellzustandsbeurteilers 236, des beispielhaften Optimierers 214, des beispielhaften Schlüsselbewerters 220, des beispielhaften Jobbewerters 224, des beispielhaften Klassifizierermanagers 240 und/oder allgemeiner des beispielhaften Planungs-Framework 202 aus 2A, 2B und 3A durch eine oder mehrere analoge oder digitale Schaltung(en), Logikschaltungen, programmierbare Prozessor(en), programmierbare Steuerung(en), Grafikverarbeitungseinheit(en) (GPU(s)), Digitalsignalprozessor(en) (DSP(s)), anwendungsspezifische integrierte Schaltung(en) (ASIC(s)), programmierbare Logikvorrichtung(en) (PLD(s)) und/oder frei programmierbare Logikvorrichtung(en) (FPLD(s)) implementiert werden. Wenn zu lesen ist, dass beliebige der Vorrichtungs- oder Systemansprüche dieses Patents eine reine Software- und/oder Firmware-Implementierung abdecken, sind der beispielhafte Datenabrufer 204 und/oder der beispielhafte Architekturanalysierer 206 und/oder der beispielhafte Matrixgenerator 208 und/oder der beispielhafte Modellersteller 210 und/oder der beispielhafte Modellbewerter 212 und/oder der beispielhafte Merkmalgenerator 216 und/oder der beispielhafte Kennzeichnungstrainer 218 und/oder der beispielhafte Prioritätsmetrikmanager 230 und/oder der beispielhafte Modellgenauigkeits- und -gewissheitsbewerter 232 und/oder der beispielhafte Pufferbewerter 234 und/oder der beispielhafte Modellzustandsbeurteiler 236 und/oder der beispielhafte Optimierer 214 und/oder der beispielhafte Schlüsselbewerter 220 und/oder der beispielhafte Jobbewerter 224 und/oder der beispielhafte Klassifizierermanager 240 und/oder allgemeiner das beispielhafte Planungs-Framework 202 aus 2A, 2B und 3A vorliegend ausdrücklich so definiert, dass sie eine nicht transiente computerlesbare Speichereinrichtung oder Speicherplatte, wie etwa einen Speicher, eine DVD (Digital Versatile Disk), eine CD (Compact Disk), eine Blu-Ray-Disk usw., umfassen, die die Software und/oder Firmware umfasst. Ferner kann das beispielhafte Planungs-Framework 202 aus 2A, 2B und 3A ein oder mehrere Elemente, Prozesse und/oder Einrichtungen zusätzlich zu oder anstelle der in 2A, 2B und/oder 3A veranschaulichten umfassen und/oder kann mehr als eines von beliebigen oder allen der veranschaulichten Elemente, Prozesse und Einrichtungen umfassen. Vorliegend umfasst der Ausdruck „in Kommunikation“, einschließlich Varianten davon, direkte Kommunikation und/oder indirekte Kommunikation durch eine oder mehrere Zwischenkomponenten und erfordert keine direkte physische (z.B. drahtgebundene) Kommunikation und/oder konstante Kommunikation, sondern umfasst zusätzlich eine selektive Kommunikation in periodischen Intervallen, geplanten Intervallen, aperiodischen Intervallen und/oder einmaligen Ereignissen.
Flussdiagramme, die beispielhafte Hardwarelogik, maschinenlesbare Anweisungen, hardwareimplementierte Zustandsmaschinen und/oder eine beliebige Kombination davon zum Implementieren des Planungs-Frameworks 202 aus 2A, 2B und 3A darstellen, sind in 5A1, 5A2, 5A3, 5B, 6A, 6B, 7, 8A-8E, 9 und 10 gezeigt. Die maschinenlesbaren Anweisungen können ein oder mehrere ausführbare Programme oder Teil(e) eines ausführbaren Programms zur Ausführung durch einen Computerprozessor, wie etwa den Prozessor 812, der in der nachstehend in Verbindung mit 11 besprochenen beispielhaften Prozessorplattform 1100 gezeigt ist, sein. Das Programm kann in Software umgesetzt sein, die auf einem nicht transienten computerlesbaren Speichermedium gespeichert ist, wie etwa einer CD-ROM, einer Diskette, einer Festplatte, einer DVD, einer Blu-Ray-Disk oder einem dem Prozessor 1112 zugeordneten Speicher, aber das gesamte Programm und/oder Teile davon könnten alternativ dazu durch eine andere Einrichtung als der Prozessor 1112 ausgeführt werden und/oder in Firmware oder dedizierter Hardware umgesetzt sein. Auch wenn das beispielhafte Programm unter Bezugnahme auf die in 5A1, 5A2, 5A3, 5B, 6A, 6B, 7, 8A-8E, 9 und 10 veranschaulichten Flussdiagramme beschrieben ist, können alternativ viele andere Verfahren zum Implementieren des beispielhaften Planungs-Framework 202 verwendet werden. Zum Beispiel kann die Ausführungsreihenfolge der Blöcke geändert werden und/oder manche der beschriebenen Blöcke können geändert, eliminiert oder kombiniert werden. Zusätzlich oder alternativ dazu können beliebige oder alle der Blöcke durch eine oder mehrere Hardwareschaltungen (z.B. diskrete und/oder integrierte analoge und/oder digitale Schaltungen, ein FPGA, eine ASIC, einen Komparator, einen Operationsverstärker (OpAmp), eine Logikschaltung usw.) implementiert werden, die dazu strukturiert sind, die entsprechende Operation durchzuführen, ohne Software oder Firmware auszuführen.
Die vorliegend beschriebenen maschinenlesbaren Anweisungen können in einem komprimierten Format und/oder einem verschlüsselten Format und/oder einem fragmentierten Format und/oder einem kompilierten Format und/oder einem ausführbaren Format und/oder einem verpackten Format usw. gespeichert sein. Maschinenlesbare Anweisungen können vorliegend als Daten (z.B. Teile von Anweisungen, Code, Repräsentationen von Code usw.) gespeichert werden, die genutzt werden können, um maschinenausführbare Anweisungen zu erzeugen, herzustellen und/oder zu produzieren. Zum Beispiel können die maschinenlesbaren Anweisungen fragmentiert und auf einer oder mehreren Speichereinrichtungen und/oder Datenverarbeitungseinrichtungen (z.B. Servern) gespeichert werden. Die maschinenlesbaren Anweisungen können Installation und/oder Modifikation und/oder Anpassung und/oder Aktualisierung und/oder Kombinieren und/oder Ergänzen und/oder Konfigurieren und/oder Entschlüsseln und/oder Dekomprimieren und/oder Entpacken und/oder Verteilen und/oder Neuzuweisen und/oder Kompilieren usw. erfordern, um sie direkt lesbar, interpretierbar und/oder durch eine Datenverarbeitungseinrichtung und/oder eine andere Maschine ausführbar zu machen. Beispielsweise können die maschinenlesbaren Anweisungen in mehreren Teilen gespeichert sein, die einzeln komprimiert, verschlüsselt und auf separaten Datenverarbeitungseinrichtungen gespeichert sind, wobei die Teile, wenn sie entschlüsselt, dekomprimiert und kombiniert werden, einen Satz ausführbarer Anweisungen bilden, die ein Programm, wie etwa das vorliegend beschriebene, implementieren.
In einem anderen Beispiel können die maschinenlesbaren Anweisungen in einem Zustand gespeichert sein, in dem sie durch einen Computer gelesen werden können, aber Hinzufügen einer Bibliothek (z.B. einer Dynamic Link Library (DLL)), eines Softwareentwicklungskits (SDK), einer Anwendungsprogrammierungsschnittstelle (API) usw. erfordern, um die Anweisungen auf einer jeweiligen Datenverarbeitungseinrichtung oder einer anderen Einrichtung auszuführen. In einem anderen Beispiel müssen die maschinenlesbaren Anweisungen möglicherweise konfiguriert werden (z.B. Einstellungen gespeichert, Dateneingabe, Netzwerkadressen aufgezeichnet usw.), bevor die maschinenlesbaren Anweisungen und/oder das/die entsprechende(n) Programm(e) ganz oder teilweise ausgeführt werden können. Somit sollen die offenbarten maschinenlesbaren Anweisungen und/oder das (die) entsprechende(n) Programm(e) derartige maschinenlesbare Anweisungen und/oder Programm(e) ungeachtet des speziellen Formats oder Zustands der maschinenlesbaren Anweisungen und/oder Programm(e) einschließen, wenn sie gespeichert oder anderweitig im Ruhezustand oder im Transit sind.
Die vorliegend beschriebenen maschinenlesbaren Anweisungen können durch eine beliebige vergangene, gegenwärtige oder zukünftige Anweisungssprache, Skriptsprache, Programmiersprache usw. repräsentiert werden. Zum Beispiel können die maschinenlesbaren Anweisungen unter Verwendung von HyperText Markup Language (HTML) und/oder einer beliebigen der folgenden Sprachen dargestellt werden: C, C++, Java, C#, Perl, Python, JavaScript, Structured Query Language (SQL), Swift usw.
Wie vorstehend erwähnt, können die beispielhaften Prozesse aus 5A1, 5A2, 5A3, 5B, 6A, 6B, 7, 8A-8E, 9 und 10 unter Verwendung ausführbarer Anweisungen (z.B. computer- und/oder maschinenlesbarer Anweisungen) implementiert werden, die auf einem nicht transienten computer- und/oder maschinenlesbaren Medium gespeichert sind, wie etwa einem Festplattenlaufwerk, einem Flashspeicher, einem Nur-Lese-Speicher, einer Compact Disk, einer Digital Versatile Disk, einem Cache, einem Direktzugriffsspeicher und/oder einer beliebigen anderen Speichereinrichtung oder Speicherplatte, auf der Informationen für eine beliebige Dauer (z.B. für längere Zeiträume, permanent, für kurze Fälle, zum temporären Puffern und/oder zum Cachen der Informationen) gespeichert sind. Vorliegend ist der Ausdruck „nicht transientes computerlesbares Medium“ ausdrücklich so definiert, dass er eine beliebige Art von computerlesbarer Speichereinrichtung und/oder Speicherplatte umfasst und sich ausbreitende Signale ausschließt und Übertragungsmedien ausschließt.
„Umfassend“ (und alle Formen und Zeitformen davon) werden vorliegend als offene Ausdrücke verwendet. Wenn ein Anspruch eine beliebige Form von „umfassen“ (z.B. umfasst, umfassend, aufweisend usw.) als Präambel oder innerhalb einer Anspruchsaufzählung beliebiger Art einsetzt, versteht es sich somit, dass zusätzliche Elemente, Ausdrücke usw. vorhanden sein können, ohne außerhalb des Schutzumfangs des entsprechenden Anspruchs oder der entsprechenden Aufzählung zu fallen. Wenn vorliegend der Ausdruck „mindestens/zumindest“ als Übergangsausdruck in zum Beispiel einer Präambel eines Anspruchs verwendet wird, so ist dieser in gleicher Weise offen, in der auch der Ausdruck „umfassend“ offen ist. Der Ausdruck „und/oder“ bezieht sich, wenn er zum Beispiel in einer Form wie A, B und/oder C verwendet wird, auf eine beliebige Kombination oder Untermenge von A, B, C wie (1) A allein, (2) B allein, (3) C allein, (4) A mit B, (5) A mit C, (6) B mit C und (7) A mit B und mit C. Wie hierin im Zusammenhang mit der Beschreibung von Strukturen, Komponenten, Elementen, Objekten und/oder Dingen verwendet, soll sich die Formulierung „mindestens eines von A und B“ auf Implementierungen beziehen, die beliebige von (1) mindestens einem A, (2) mindestens einem B und (3) mindestens einem A und mindestens einem B beinhalten. Ähnlich, wie hierin im Kontext des Beschreibens von Strukturen, Komponenten, Elementen, Objekten und/oder Dingen verwendet, soll sich die Formulierung „mindestens eines von A oder B“ auf Implementierungen beziehen, die beliebige von (1) mindestens einem A, (2) mindestens einem B und (3) mindestens einem A und mindestens einem B beinhalten. Wie hierin im Kontext der Beschreibung der Leistungsfähigkeit oder Ausführung von Prozessen, Anweisungen, Aktionen, Aktivitäten und/oder Schritten verwendet, soll sich die Formulierung „wenigsten eines von A und B“ auf Implementierungen beziehen, die beliebige von (1) mindestens einem A, (2) mindestens einem B, und (3) mindestens einem A und mindestens einem B beinhalten. Ähnlich wie hierin im Zusammenhang mit der Beschreibung der Leistungsfähigkeit oder Ausführung von Prozessen, Anweisungen, Aktionen, Aktivitäten und/oder Schritten verwendet, soll sich die Formulierung „mindestens eines von A oder B“ auf Implementierungen beziehen, die beliebige von (1) mindestens einem A, (2) mindestens einem B und (3) mindestens einem A und mindestens einem B beinhalten.
Vorliegend schließen Bezugnahmen auf die Einzahl (z.B. „ein“, „eine“, „erste/r/s“, „zweite/r/s“ usw.) eine Vielzahl nicht aus. Der Ausdruck „eine“ oder „eine“ Entität bezieht sich vorliegend auf eine oder mehrere dieser Entität. Die Begriffe „ein“ (oder „eine“), „ein oder mehrere“ und „mindestens ein“ können vorliegend austauschbar verwendet werden. Auch wenn einzeln aufgelistet, können darüber hinaus mehrere Mittel, Elemente oder Verfahrenshandlungen z.B. durch eine einzige Einheit oder einen einzigen Prozessor implementiert werden. Darüber hinaus sind, wenngleich einzelne Merkmale in verschiedenen Beispielen oder Ansprüchen enthalten sein können, diese möglicherweise kombinierbar, und die Aufnahme in verschiedene Beispiele oder Ansprüche impliziert nicht, dass eine Kombination von Merkmalen nicht möglich und/oder vorteilhaft ist.
Das Programm 550 aus 5A1 stellt ein Flussdiagramm hoher Ebene des beispielhaften Planungs-Framework 202 aus 2A, 2B, 3A und 4C dar. Das beispielhafte Programm 550 kann durch das beispielhafte Planungs-Framework 202 und/oder die Struktur darin implementiert werden. Dementsprechend sind Bezugnahmen auf die Struktur des beispielhaften Planungs-Framework 202 nicht einschränkend. In dem veranschaulichten Beispiel aus 5A1 übermittelt das Planungs-Framework 202 einen oder mehrere Jobs zur Verarbeitung (Block 552) und leitet Jobs an einen oder mehrere virtuelle Pools zur Priorisierung (Block 554). Das beispielhafte Planungs-Framework 202 platziert Job(e) auf einem oder mehreren entsprechenden Servern (Block 556) und initiiert Jobs auf Hardware (Block 558). Das beispielhafte Planungs-Framework 202 bestimmt, ob die Modellmischzeit null ist (Block 560), und führt, falls ja, Hardwarecluster-Telemetrie durch (Block 562). Andernfalls speichert das beispielhafte Planungs-Framework 202 Daten und bereitet eine Binärmatrix vor (Block 564).
In dem veranschaulichten Beispiel aus 5A1 nimmt das Planungs-Framework 202 beim Training parallele Pfade. Insbesondere initiiert das beispielhafte Planungs-Framework 202 das Training eines Regressionsmodells (Block 566) und das Training eines LSTM-Modells (Block 568). Auch wenn das veranschaulichte Beispiel aus 5A1 eine Erörterung des Verwendens von Regressionsmodellen und LSTM-Modellen umfasst, dient eine solche Erörterung Beispielzwecken und vorliegend offenbarte Beispiele sind nicht hierauf eingeschränkt. Darüber hinaus sind, soweit vorliegend Regressionsmodelle und LSTM-Modelle insgesamt offenbart sind, solche Beispiele nicht auf Regressions- und/oder LSTM-Modelltypen beschränkt. Das veranschaulichte Beispiel aus 5A2 umfasst eine weitere Erläuterung des beispielhaften Programms, wobei das beispielhafte Planungs-Framework 202 bestimmt, ob eine Regressionsinferenz verfügbar ist (Block 570). Falls ja, bestimmt das beispielhafte Planungs-Framework 202, ob die Trainingsregression eine höhere Genauigkeit als ein Kandidaten-Regressionsmodell aufweist (Block 574). Falls ja, wird das Kandidaten-Regressionsmodell gefördert (Block 572). Falls nicht, erfolgen Vorhersagen unter Verwendung des Regressionskandidatenmodells (Block 576). Falls jedoch keine Regressionsinferenz verfügbar ist (Block 570), dann wird das Regressionsmodell zur Inferenz gefördert (Block 572), und eine Vorhersage erfolgt unter Verwendung des Regressionskandidatenmodells (Block 576).
Bevor ein Vergleich durchgeführt wird, welcher Modellierungsansatz (z.B. ein Regressionsmodellansatz, der rechenintensiver als ein LSTM-Modellansatz ist) genauer arbeitet, bestimmt das beispielhafte Planungs-Framework 202, ob eine LSTM-Inferenz verfügbar ist (Block 578). Falls ja, bestimmt das beispielhafte Planungs-Framework 202, ob ein Trainings-LSTM eine höhere Genauigkeit als ein Kandidaten-LSTM-Modell aufweist (Block 582). Falls ja, wird das Kandidaten-LSTM-Modell gefördert (Block 580), andernfalls erfolgt eine Vorhersage unter Verwendung eines LSTM-Kandidatenmodells (Block 584). Falls keine LSTM-Inferenz verfügbar ist (Block 578), dann wird das Kandidaten-LSTM-Modell gefördert (Block 580) und Vorhersagen erfolgen unter Verwendung des LSTM-Kandidatenmodells (Block 584).
Das beispielhafte Planungs-Framework 202 vergleicht den Regressions- und den LSTM-Ansatz, um eine Metrik mit relativ höchster Genauigkeit zu bestimmen und/oder eine Modellresilienzverwaltung durchzuführen (Block 586), wie vorstehend und nachstehend ausführlicher beschrieben. Das beispielhafte Planungs-Framework 202 bestimmt zudem, ob Datensatzmatrixattribute (z.B. Attribute aus der beispielhaften Datensatzmatrix aus 3B bis 3E) angeordnet werden sollten (Block 587). Falls eine Neuanordnung stattfinden sollte (Block 587), dann geht die Steuerung zu Block 590 über, bevor sie zu Block 564 aus 5A1 zurückkehrt. Allgemein gesagt kann eine Neuanordnung der beispielhaften Datensatzmatrix wünschenswert sein, um Maschinenlernaufgaben zu verbessern und einen Diversitätsgrad in den gekennzeichneten Daten, der für Trainingszwecke verwendet wird, zu erhöhen. Somit erleichtert die Datensatzmatrixumordnung Modellverbesserungen, wenn Maschinenlernoperationen mit gekennzeichneten Daten durchgeführt werden. In einigen Beispielen (z.B. parallel und/oder anderweitig unabhängig von Datensatzmatrixumordnungsversuchen) werden Jobs unter Verwendung von Teile-und-herrsche-Techniken (z.B. Modellanalyse- und Greedy-Algorithmusauswahltechniken (z.B. Best-Fit, Knapsack-Technik(en) usw.) ausgewählt (Block 588). Die Steuerung kehrt dann zu 5A1 zurück.
8A veranschaulicht ein zusätzliches Detail, das der Modellresilienzverwaltung von Block 586 entspricht. Bei dem veranschaulichten Beispiel aus 8A beurteilt der beispielhafte Prioritätsmetrikmanager 230 eine Risikoreduktion (Block 802), beurteilt der beispielhafte Modellgenauigkeits- und Gewissheitsbewerter 232 eine Genauigkeit und Gewissheit von Modellen (Block 804), beurteilt der beispielhafte Pufferbewerter 234 einen Puffer (Block 806) und beurteilt der beispielhafte Modellzustandsbeurteiler 236 interne Zustände von Modellen (Block 808). Auch wenn das veranschaulichte Beispiel aus 8A die vorstehend erwähnten Resilienzverwaltungsoperationen in Reihe zeigt, sind vorliegend offenbarte Beispiele nicht hierauf eingeschränkt.
8B veranschaulicht ein zusätzliches Detail, das mit dem Beurteilen einer Risikoreduktion von Block 802 verbunden ist. Bei dem veranschaulichten Beispiel aus 8B ruft der beispielhafte Prioritätsmetrikmanager 230 Prioritätsmetriken ab (Block 820). Wie vorstehend beschrieben, können bestimmten Jobtypen dynamisch unterschiedliche Prioritäten „fliegend“ zugewiesen werden. Der beispielhafte Prioritätsmetrikmanager 230 bestimmt, ob eine oder mehrere der Prioritätsmetriken geändert wurden (Block 822), wie etwa durch Vergleichen einer oder mehrerer Metriken mit einem Schwellenwert. Falls Änderungen aufgetreten sind, dann passt der Prioritätsmetrikmanager 230 eine oder mehrere Gewichtungen der Kostenfunktion an (Block 824) und die Steuerung kehrt zu Block 804 aus 8A zurück.
8C veranschaulicht ein zusätzliches Detail, das mit dem Beurteilen von Genauigkeit und Gewissheit des Blocks 804 verbunden ist. Bei dem veranschaulichten Beispiel aus 8C wählt der Modellgenauigkeits- und -gewissheitsbewerter 232 ein interessierendes Modell aus (Block 830). In einigen Beispielen führt der Modellgenauigkeits- und -gewissheitsbewerter 232 einen parallelen Prozess des Berechnens der Modellgenauigkeit (Block 832) und des Berechnens der Modellgewissheit (Block 834) durch. Ergebnisse aus den zuvor genannten Berechnungen werden auf das ausgewählte interessierende Modell angewendet (Block 836), was in einigen Beispielen eine Normalisierung oder Aggregation von Genauigkeits- und Gewissheitsberechnungen umfasst. Der beispielhafte Modellgenauigkeits- und -gewissheitsbewerter 232 bestimmt, ob zusätzliche Modelle von Interesse zu bewerten sind (Block 838), und falls ja, kehrt die Steuerung zu Block 830 zurück. Andernfalls kehrt das beispielhafte Programm 804 aus 8C zu Block 806 aus 8A zurück.
8D veranschaulicht zusätzliche Details, die mit dem Beurteilen eines Puffers von Block 806 verbunden sind. In dem veranschaulichten Beispiel aus 8D berechnet der beispielhafte Pufferbewerter 234 eine Menge an nicht zugewiesenen Ressourcen für einen Zeitraum von Interesse (Block 840) und bestimmt, ob ein oder mehrere Jobs in der Warteschlange angehalten sind (Block 842). Falls ja, teilt der beispielhafte Pufferbewerter 234 angesichts des angehaltenen Jobs Puffer zu (Block 844) und aktualisiert und/oder passt die Kostenfunktion anderweitig an, um die Priorität zum Reservieren von Ressourcen für den ausgewählten Job widerzuspiegeln (Block 846). In einigen Beispielen wendet der Pufferbewerter 234 Gewichtungen proportional zunehmend an, falls der bestimmte interessierende Job für einen Schwellenzeitraum wartet (z.B. der Job veraltet in der Warteschlange), wodurch ermöglicht wird, dass die Ergebnisse der Kostenfunktion aggressiver Zielressourcen für den Job auffinden. Die Steuerung kehrt dann zu Block 808 aus 8A zurück.
8E veranschaulicht zusätzliche Details, die mit dem Beurteilen interner Zustände von Block 808 verbunden sind. Bei dem veranschaulichten Beispiel aus 8E wählt der Modellzustandsbeurteiler 236 ein LSTM-Modell von Interesse aus (Block 850). Auch das veranschaulichte Beispiel aus 8E eine LSTM-Modellanalyse beschreibt, sind vorliegend offenbarte Beispiele hierauf jedoch nicht eingeschränkt. In einigen Beispielen kann eine beliebige andere Art von Modell, das zwei oder mehr Schichten beinhaltet, auf eine ähnliche Weise analysiert werden. Der beispielhafte Modellzustandsbeurteiler 236 wählt eine der Modellschichten aus (Block 852), berechnet eine Wahrscheinlichkeit der ausgewählten Schicht (Block 854) und bestimmt, ob der Wahrscheinlichkeitswert einen Schwellenwert erfüllt (Block 856). In einigen Beispielen wird der Schwellenwert als ein „Aussonderungs“-Schwellenwert bezeichnet, so dass, wenn der Aussonderungsschwellenwert erfüllt ist (Block 856), die jeweilige zu analysierende Schicht für Aussonderung, Entfernung oder Deaktivierung identifiziert wird (Block 858). Falls der Aussonderungsschwellenwert jedoch nicht erfüllt ist (Block 856), wird die jeweilige zu analysierende Schicht beibehalten (Block 860). Der beispielhafte Modellzustandsbeurteiler 236 bestimmt, ob zusätzliche zu analysierende Schichten vorhanden sind (Block 862), und falls ja, kehrt die Steuerung zu Block 852 zurück. Andernfalls bestimmt der Modellzustandsbeurteiler 236, ob zusätzliche Modelle zu analysieren sind (Block 864), und falls ja, kehrt die Steuerung zu Block 850 zurück. Andernfalls kehrt die Steuerung zu Block 587 aus 5A2 zurück.
5A3 veranschaulicht zusätzliche Details, die der Neuanordnung von Attributen entsprechen (Block 590). In dem veranschaulichten Beispiel aus 5A3 importiert der beispielhafte Modellauswerter 212 Standard-Datensatzmatrixattribute und erzeugt eine separate Instanz von LSTM-Modellen und/oder Regressionsmodellen (Block 591). Zum Beispiel kann die Datensatzmatrix fünfunddreißig Attribute (z.B. Anzahl von Jobs in der Warteschlange, Anzahl verfügbarer Einrichtungen usw.) aufweisen. Der beispielhafte Modellbewerter 212 bestimmt, ob diese Attribute zum Trainieren eines Modells von Interesse verwendet wurden (Block 592), und trainiert, falls nicht, das Modell (Block 594). Der beispielhafte Modellbewerter 212 kann iterative Trainingsversuche unter Verwendung des aktuellen Satzes von Attributen für einen Trainingsschwellenwert durchführen. Der beispielhafte Trainingsschwellenwert umfasst, ohne jedoch hierauf eingeschränkt zu sein, eine Schwellenanzahl von Trainingsiterationen unter Verwendung des aktuellen Satzes von Attributen, einen Schwellenzeitraum, eine Schwellenanzahl von Trainingsepochen usw. Trainingsraten werden gespeichert (Block 595) und der beispielhafte Modellbewerter 212 bestimmt, ob ein Zeitintervall beendet ist (Block 596). Falls nicht, kehrt die Steuerung zu Block 591 zurück.
Unter erneuter Bezugnahme auf Beispielblock 592 wählt der Modellbewerter 212, falls das Modell bereits einmal mit den existierenden Datensatzmatrixmerkmalen trainiert wurde, eine andere Kombination von Attributen aus (Block 593). Beispielsweise erzeugen manchmal Regressions- und/oder LSTM-Modelle keine Vorhersage mit höchster relativer Genauigkeit unter Verwendung des Standardsatzes von Attributen. Angesichts dieser Möglichkeit werden unterschiedliche Kombinationen von Attributen als Teilsatz der Gesamtanzahl von Attributen ausgewählt, die im Standardsatz verfügbar sind. In einigen Beispielen werden unterschiedliche Attribute und/oder Mengen dieser unterschiedlichen Attribute durch den Modellbewerter 212 ausgewählt, um bewertet zu werden. Entsprechende Genauigkeitsraten werden gespeichert, wie vorstehend in Verbindung mit Block 595 offenbart. In einigen Beispielen ruft der Modellbewerter 212 die beispielhaften Umordnungsoperationen des Programms (Block 590) basierend auf einem anfänglichen Genauigkeitsschwellenwert auf (z.B. Genauigkeitswerte von weniger als 40 % bewirken, dass die Umordnungsoperationen aufgerufen werden). In einigen Beispielen können die Umordnungsoperationen nach Ermessen eines Analysten initiiert werden.
9 veranschaulicht zusätzliche Details, die mit dem Auswählen von Jobs aus Block 588 verbunden sind. Bei dem veranschaulichten Beispiel aus 9 erfasst der beispielhafte Modellersteller 210 eine Liste von Modellen (Block 902) und wählt eines zur weiteren Bewertung aus (Block 904). Der beispielhafte Modellgenauigkeits- und - gewissheitsbewerter 232 berechnet eine oder mehrere Vorhersagebewertungsmetriken (Block 906) und bestimmt, ob ein oder mehrere Schwellenwerte erfüllt sind (Block 908). Falls der eine oder die mehreren Schwellenwerte nicht erfüllt sind (Block 908), wählt der beispielhafte Modellersteller 210 ein alternatives Modell aus (Block 910) und die Steuerung kehrt zu Block 904 zurück. Andernfalls behält der beispielhafte Optimierer 214 das Modell zur Verwendung für Ressourcenvorhersage und zum Erstellen einer Jobwarteschlange bei (Block 912). Der beispielhafte Modellersteller 210 bestimmt, ob mehr Modelle zu analysieren sind (Block 914), und falls ja, kehrt die Steuerung zu Block 904 zurück.
Wenn alle Modelle von Interesse analysiert wurden (z.B. analysiert für eine Iteration von Interesse, wie etwa einen Zeitraum von Interesse) (Block 914), ruft der beispielhafte Datenabrufer 204 Jobprioritätseigenschaften ab (Block 916). Der beispielhafte Klassifizierermanager 240 wendet einen oder mehrere Greedy-Algorithmen auf eine Zielfunktion wie etwa eine Kostenfunktion an (Block 918). Wie vorstehend beschrieben, können die Greedy-Algorithmen unter anderem einen Largest-Best-Fit-Algorithmus, einen Smallest-Best-Fit-Algorithmus oder einen Knapsack-Algorithmus umfassen. Der beispielhafte Optimierer 214 weist Jobwarteschlangen entsprechenden Optimierungsalgorithmen basierend auf der Kostenfunktion und entsprechenden Jobeigenschaften zu (Block 920), was in dem veranschaulichten Beispiel aus 4C grafisch gezeigt ist.
In einigen beispielhaften Operationen berücksichtigt das beispielhafte Planungs-Framework 202 Umstände, unter denen zahlreiche Eingaben und/oder zahlreiche Modellauswahloptionen einen Benutzer und/oder Datenverarbeitungsfähigkeiten des beispielhaften Framework 202 überfordern können. Um solche Umstände zu berücksichtigen, umfasst das Programm 500 aus 5B den Block 502, bei dem der beispielhafte Datenabrufer 204 Daten aus dem beispielhaften Datenspeicher 250 abruft. Der beispielhafte Architekturanalysierer 206 erfolgt ein Abrufen, Empfangen oder eine anderweitige Bestimmung einer Zielhardwareabbildung (Block 504) und der beispielhafte Matrixgenerator 208 entwirft eine Datensatzmatrix (Block 506). Um große Volumen an Eingangstelemetrie zu handhaben oder anderweitig effizient zu verwalten und bestimmte Jobs bestimmten Modellen zuzuordnen, die die Ressourcennutzung am besten vorhersagen können, führt das beispielhafte Planungs-Framework 202 eine Telemetrieverwaltung von Jobs, Servern und Modellen durch (Block 507). Weitere Einzelheiten, die der Telemetrieverwaltung von Jobs, Servern und Modellen entsprechen, sind in Verbindung mit 10 ausführlicher beschrieben. Der beispielhafte Architekturanalysierer 206 wählt eine vorherzusagende Ressource aus (z.B. eine prozentuale Wahrscheinlichkeit, dass die Ressource beansprucht wird oder verfügbar ist) (Block 508), und der beispielhafte Modellersteller 210 lädt einen Teilsatz von Daten in ein LSTM-Modell (Block 510) und lädt einen Teilsatz von Daten in ein Polynom-Regressionsmodell (Block 512). Der beispielhafte Architekturanalysierer 206 bestimmt, ob zusätzliche Ressourcen zu analysieren sind (z.B. eine beliebige Anzahl einzelner Prozessoren, Prozessorkerne, Emulatoren usw.) (Block 514). Falls ja, kehrt die Steuerung zu Block 508 zurück. Andernfalls bewertet der beispielhafte Modellbewerter 212 eine beliebige Anzahl von Modellen, um Vorhersagemetriken zu erzeugen (Block 516), wie in 6A und 6B ausführlicher erörtert wird. Der beispielhafte Optimierer 214 wendet einen oder mehrere Optimierungsalgorithmen unter Verwendung der Vorhersagemetriken an (Block 518), wie ausführlicher in 7 erörtert wird.
6A veranschaulicht zusätzliche Details in Verbindung mit dem Auswerten von Modellen, um Vorhersagemetriken zu erzeugen (Block 516 aus 5B). In dem veranschaulichten Beispiel aus 6A importiert der beispielhafte Merkmalgenerator 216 Linear-Regressions- und polynomiale Merkmale (Block 602). In einigen Beispielen sind die importierten Merkmale Standardmerkmale, die vor der Akkumulation historischer Trainings- und/oder Modellierungsdaten genutzt werden, die durch eine beliebige Anzahl von Systemepochen erfolgt. Auch wenn sich vorliegend offenbarte Beispiele auf einen ersten Modelltyp als ein oder mehrere Polynom-Regressionsmodelle und einen zweiten Modelltyp als ein oder mehrere LSTM-Modelle beziehen, sind Beispiele nicht hierauf eingeschränkt. Ein polynomialer Komplexitätsgrad kann (durch den Merkmalgenerator 216) auf unterschiedliche Werte eingestellt werden (Block 604), um eine Genauigkeitsrate des polynomialen Modells zu verbessern. In einigen Beispielen wird eine Standard-Komplexitätseigenschaft (z.B. ein Komplexitätsgradwert des Polynoms) durch den beispielhaften Merkmalgenerator 216 festgelegt. Beispielsweise kann eine erste Iteration des beispielhaften Flussdiagramms von Block 516 einen Standard-Polynomkomplexitätswert auf einen Grad von „2“ setzen. Eine solche Erhöhung von Komplexitätseinstellungen bewirkt jedoch tendenziell, dass ein größerer Grad an Datenverarbeitungsressourcen durch das Planungs-Framework 202 beansprucht wird, wenn Vorhersagemetriken der Ressourcennutzung erzeugt werden. Vorliegend offenbarte Beispiele helfen beim Einstellen von Werten der Polynomkomplexitätseinstellungen zum Beispiel hinsichtlich unterschiedlicher Mengen historischer Daten, die mit LSTM-Modellierung verwendet werden können, was eine Abhängigkeit von Polynom-Regressionstechniken effektiv reduzieren könnte, wenn Vorhersagen getroffen werden. Allgemein gesagt gibt es, wenn ein Modellierungsversuch anfänglich beginnt, keine historischen Daten, auf die Bezug genommen werden kann, wodurch die Verwendung von LSTM-Modellen behindert wird und eine Verwendung von polynomialen Modellen erforderlich ist. Um eine Komplexitätsgradeinstellung des einen oder der mehreren polynomialen Modelle anzupassen und/oder anderweitig zu bestimmen, passt der beispielhafte Kennzeichnungstrainer 218 einen Transformationsdatensatz an (Block 606) und trainiert entsprechende Kennzeichnungen (Block 608). Der beispielhafte Modellbewerter 212 erzeugt entsprechende Vorhersagewerte unter Verwendung der (polynomialen) Linearregression (Block 610) und bestimmt, ob die Vorhersagewertgenauigkeit einen oder mehrere Schwellenwerte erfüllt (Block 612). Falls nicht, kehrt die Steuerung zu Block 606 zurück, um das Modell nach dem ersten Inkrementieren eines Komplexitätsgrads des polynomialen Modells (Block 613) während einer anschließenden Iteration neu zu trainieren. Falls der Modellbewerter 212 jedoch bestimmt, dass die Vorhersagewertgenauigkeit einen oder mehrere Schwellenwerte erfüllt (Block 612), speichert der Modellbewerter 212 das trainierte Modell (Block 614) (das z.B. in dem beispielhaften Datenspeicher 250 gespeichert ist).
Das veranschaulichte Beispiel aus 6A führt seine erste Iteration unter der Annahme oder Erwartung durch, dass keine historischen Daten verfügbar sind, die ansonsten für LSTM-Modellierungsansätze vorteilhaft wären. Somit sind anfängliche Durchläufe durch das veranschaulichte Beispiel aus 6A vollständig auf Polynom-Regressionsmodellierungstechniken mit unterschiedlichen Komplexitätsgraden angewiesen. Während der anfänglichen Iteration des beispielhaften Programms 516 aus 6A setzt der Modellbewerter 212 einen polynomialen Aktivierungsgewichtungswert auf eins (z.B. 1,0), um anzugeben, dass Vorhersagen ausschließlich durch Polynom-Regressionsmodellierungsansätze erfolgen sollten, und verhindert die Nutzung jedes anderen Modelltyps (z.B. LSTM). Die beispielhafte polynomiale Aktivierungsgewichtung ist ein Wert zwischen null (0,0) und eins (1,0), um eine proportionale Menge an Vorhersageberechnungen darzustellen, die durch entweder polynomiale Modelle, LSTM-Modelle oder eine beliebige Kombination aus diesen durchgeführt werden sollten. Werte von eins (1,0) repräsentieren Umstände, unter denen 100 % der Vorhersageversuche mit polynomialen Modellen erfolgen sollen, Werte von null (0,0) repräsentieren Umstände, unter denen 100 % der Vorhersageversuche mit LSTM-Modellen erfolgen sollen, und Werte von 0,5 repräsentieren Umstände, unter denen 50 % der Vorhersageversuche mit polynomialen Modellen und 50% der Vorhersageversuche mit LSTM-Modellen erfolgen sollten.
Um einen Ausgleich zwischen Vorhersageversuchen über polynomiale Modelle und LSTM-Modelle herzustellen, zu aktualisieren und/oder anderweitig zu bestimmen, beurteilt der beispielhafte Modellersteller 210 LSTM-Beteiligungsmetriken (Block 616). 6B veranschaulicht ein zusätzliches Detail, das mit dem Beurteilen der LSTM-Beteiligung in Block 616 verbunden ist. In dem veranschaulichten Beispiel faus 6B bestimmt der beispielhafte Datenabrufer 204, ob historische Daten verfügbar sind (Block 620). Historische Daten umfassen, ohne jedoch hierauf eingeschränkt zu sein, historische Modelltrainingsdaten oder historische Jobabbildungsdaten (z.B. Instanzen zum Abbilden bestimmter Jobs auf bestimmte Hardwareressourcen). Der Datenabrufer 204 kann verfügbare historische Daten durch Bewerten von Zeitstempeln gesammelter Daten bestimmen, um zu bestätigen, ob diese einem kürzlich erfolgten Vorhersageversuch entsprechen, der mit speziellen Hardwareressourcen verbunden ist. Falls keine entsprechenden daten-/zeitgestempelten Datenpunkte vorhanden sind, die einem Zeitraum von Interesse oder speziellen Zielhardwareressourcen von Interesse entsprechen (z.B. Daten, die in dem beispielhaften Datenspeicher 250 gespeichert sind), behält der Modellersteller 210 einen aktuellen Polynom-Modellaktivierungsgewichtungswert (Block 621) bei und das Programm 616 aus 6B endet und Vorhersageversuche beruhen weiterhin auf Polynom-Regressionsmodellen.
Wenn andererseits der beispielhafte Datenabrufer 204 identifiziert, dass historische Daten verfügbar sind (Block 620), bewertet der beispielhafte Modellersteller 210 ferner diese verfügbaren historischen Datenpunkte, um eine Suffizienzmetrik zu bestimmen (Block 622). Beispielhafte Suffizienzmetriken können, ohne jedoch hierauf eingeschränkt zu sein, eine Schwellenanzahl relevanter Datenpunkte, einen Schwellenzeitraum, den ein aktueller Vorhersage versuch andauert, oder eine Anzahl von Trainingsepochen des beispielhaften Planungs-Frameworks 202 umfassen. Die beispielhaften Suffizienzmetriken können abgestuft sein, sodass zwei oder mehr Schwellenwerte zwei oder mehr polynomialen Aktivierungsgewichtungswerten entsprechen. Beispielsweise kann eine erste Schwellenanzahl relevanter Datenpunkte 10.000 betragen, was einer polynomialen Aktivierungsgewichtung von 0,80 entspricht (z.B. 80 % der Vorhersageversuche nutzen polynomiale Modelle und 20 % der Vorhersageversuche nutzen LSTM-Modelle). Da sich die beispielhaften Suffizienzmetriken jedoch verbessern und/oder anderweitig zunehmen (z.B. nehmen relevante Datenpunkte auf 20.000 zu), kann die polynomiale Aktivierungsgewichtung auf 0,60 angepasst werden, um die relative Zunahme historischer Daten widerzuspiegeln, die für LSTM-Modellierungsansätze hilfreich ist.
Der beispielhafte Modellersteller 210 nimmt eine Einstellung und/oder anderweitige Aktualisierung der polynomialen Aktivierungsgewichtung basierend auf den berechneten Suffizienzmetriken vor (Block 624). In einigen Beispielen passt der Modellersteller 210 einen Grad des Komplexitätsfaktors der polynomialen Modelle an und/oder reduziert diesen anderweitig (Block 626). Das Reduzieren des Grades des Komplexitätsfaktors dient auch dazu, Rechenlasten des beispielhaften Planungssystems 200 zu reduzieren, wenn historische Daten für LSTM-Modellierungsansätze verfügbar sind. Das beispielhafte Programm 616 endet dann.
7 veranschaulicht ein zusätzliches Detail in Verbindung mit dem Anwenden einer Optimierung (Block 518 aus 5B). In dem veranschaulichten Beispiel aus 7 bezieht der beispielhafte Datenabrufer 204 Eingaben (Block 702) und der beispielhafte Schlüsselbewerter 220 initiiert eine Schleife, wobei die Schleife mit der Jobgröße in umgekehrter Reihenfolge beginnt (Block 704). Der beispielhafte Schlüsselbewerter 220 verifiziert als Anfangsteil der Schleife (Block 704), ob alle Schlüssel berücksichtigt wurden (Block 706). Falls ja, sind wahrscheinlich eine oder mehrere Iterationen der beispielhaften Schleife (Block 704) erfolgt, und der beispielhafte Prozess aus Block 518 kehrt zurück. Falls nicht alle Schlüssel berücksichtigt wurden (Block 706), bestimmt der beispielhafte Schlüsselbewerter 220, ob ein ausgewählter Schlüssel leer ist (Block 708), und falls ja, wird ein nächster Schlüssel ausgewählt (Block 710), und die Steuerung kehrt zu Block 704 zurück. Falls der Schlüssel jedoch nicht leer ist (Block 708), dann bestimmt der beispielhafte Architekturanalysierer 206, ob die Anzahl verfügbarer Ressourcen null ist (Block 712). Falls ja, kehrt der beispielhafte Prozess aus Block 518 zurück, da alle Ressourcen analysiert wurden.
Falls verbleibende zu bewertende Ressourcen vorhanden sind (Block 712), initiiert der beispielhafte Schlüsselbewerter 220 eine Teilschleife, um Job-IDs für den ausgewählten Schlüssel durchzugehen (Block 714). Der beispielhafte Jobgrößenbewerter 224 bestimmt, ob eine aktuelle Jobgröße kleiner oder gleich einer Anzahl verfügbarer Ressourcen ist (Block 716), und falls ja, hängt der beispielhafte Jobgrößenbewerter 224 eine Job-ID an (Block 718), entfernt die angehängte Job-ID aus einer Liste (Block 720) und dekrementiert einen verfolgten Jobgrößenwert (Block 722). Falls der beispielhafte Jobgrößenbewerter 224 bestimmt, dass ein aktueller Jobgrößenwert größer oder gleich einer Anzahl verfügbarer Ressourcen ist (Block 724), wählt der beispielhafte Schlüsselbewerter 220 einen nächsten Schlüssel aus (Block 710), andernfalls wählt der beispielhafte Schlüsselbewerter 220 eine nächste Job-ID in der Liste aus (Block 726). Auch wenn das veranschaulichte Beispiel aus 7 einen schleifenbasierten Ansatz umfasst, sind vorliegend offenbarte Beispiele hierauf nicht eingeschränkt. In einigen Beispielen können Optimierungsversuche mittels Rekursion erfolgen. In einigen Beispielen kann der Rekursionsansatz zum Beispiel angesichts einer oder mehrerer bedingter Aussagen den oder die Optimierungsversuche unterbrechen.
Unter erneuter Bezugnahme auf Block 507 aus 5B veranschaulicht 10 zusätzliche Details, die mit dem Verwalten von Telemetrie von Jobs, Servern und Modellen verbunden sind. In dem veranschaulichten Beispiel aus 10 erfasst der beispielhafte Datenabrufer 204 (a) Jobtyp-Daten aktuell ausgeführter Jobs (auf Hardwareressourcen) (Block 1002), (b) Jobtyp-Daten von Jobs, die noch nicht Hardwareressourcen zugewiesen sind, sich aber in einer oder mehreren Warteschlangen (Block 1004) befinden, und (c) aktuelle Hardwareverfügbarkeitsmetriken (Block 1006) (z.B. eine Menge verfügbarer Hardwareressourcen, ob solche Ressourcen kontinuierlich sind, Ressourcentypen usw.). Der beispielhafte Jobbewerter 224 führt eine Jobtyp-Gruppierung (Block 1008) basierend auf einem beliebigen Typ einer gewünschten Eigenschaft durch, wie etwa Jobtypen, die eine spezifische Anzahl von Verarbeitungskernen erfordern, Jobtypen, die physisch benachbarte Hardwareressourcen erfordern, die mit bestimmten Busbandbreitenfähigkeiten miteinander verbunden sind usw. Der beispielhafte Klassifizierermanager 240 wendet einen oder mehrere Klassifizierungsalgorithmen an (Block 1010) (z.B. ein Entscheidungsbaum, ein Permutationsbaum usw.), um Kandidaten-Footprints zu erzeugen, und wendet einen Normalisierer an, um die Footprints an eine Verteilung anzupassen (Block 1012). In einigen Beispielen ist der Normalisierer eine Anpassungstransformationsfunktion, wie etwa beispielhafte SciKit-learn®-Algorithmen. Der beispielhafte Optimierer 214 weist dann Kandidatenmodelle zu, die mit Eigenschaften eines größten Teils der Verteilung übereinstimmen (Block 1014), wodurch jeweilige Jobs mit den Modellen abgeglichen werden, die am wahrscheinlichsten optimierte Vorhersagemetriken aufweisen.
11 ist ein Blockdiagramm einer beispielhaften Prozessorplattform 1100, die zum Ausführen der Anweisungen aus 5A1, 5A2, 5A3, 5B, 6A, 6B, 7, 8A-8E, 9 und 10 strukturiert ist, um das Planungs-Framework 202 aus 2A, 2B, 3A und 4C zu implementieren. Die Prozessorplattform 1100 kann zum Beispiel ein Server, ein Personal Computer, eine Workstation, eine selbstlernende Maschine (z.B. ein neuronales Netz), eine Mobileinrichtung (z.B. ein Mobiltelefon, ein Smartphone, ein Tablet wie etwa ein iPad™), ein Persönlicher Digitaler Assistent (PDA), ein Internetgerät, eine Spielekonsole, eine Set-Top-Box oder eine beliebige andere Art von Datenverarbeitungseinrichtung sein.
Die Prozessorplattform 1100 des veranschaulichten Beispiels umfasst einen Prozessor 1112. Bei dem Prozessor 1112 des veranschaulichten Beispiels handelt es sich um Hardware. Der Prozessor 1112 kann zum Beispiel durch eine oder mehrere integrierte Schaltungen, Logikschaltungen, Mikroprozessoren, GPUs, DSPs oder Steuerungen einer beliebigen gewünschten Modellfamilie oder eines beliebigen gewünschten Herstellers implementiert werden. Der Hardwareprozessor kann eine halbleiterbasierte (z.B. siliciumbasierte) Einrichtung sein. In diesem Beispiel implementiert der Prozessor den beispielhaften Datenabrufer 204, den beispielhaften Architekturanalysierer 206, den beispielhaften Matrixgenerator 208, den beispielhaften Modellersteller 210, den beispielhaften Modellbewerter 212, den beispielhaften Merkmalgenerator 216, den beispielhaften Kennzeichnungstrainer 218, den beispielhaften Prioritätsmetrikmanager 230, den beispielhaften Modellgenauigkeits- und -gewissheitsbewerter 232, den beispielhaften Pufferbewerter 234, den beispielhaften Modellzustandsbeurteiler 236, den beispielhaften Optimierer 214, den beispielhaften Schlüsselbewerter 220, den beispielhaften Jobbewerter 224, den beispielhaften Klassifizierermanager 240 und das beispielhafte Planungs-Framework 202.
Der Prozessor 1112 des veranschaulichten Beispiels umfasst einen lokalen Speicher 1113 (z.B. einen Cache). Der Prozessor 1112 des veranschaulichten Beispiels ist über einen Bus 1118 in Kommunikation mit einem Hauptspeicher, einschließlich eines flüchtigen Speichers 1114 und eines nichtflüchtigen Speichers 1116. Der flüchtige Speicher 1114 kann durch synchronen dynamischen Direktzugriffsspeicher (SDRAM: Synchronous Dynamic Random Access Memory), dynamischen Direktzugriffsspeicher (DRAM: Dynamic Random Access Memory), RAMBUS® Dynamic Random Access Memory (RDRAM ®) und/oder eine beliebige andere Art von Direktzugriffsspeichereinrichtung implementiert werden. Der nichtflüchtige Speicher 1116 kann durch Flashspeicher und/oder eine beliebige andere gewünschte Art von Speichereinrichtung implementiert werden. Der Zugriff auf den Hauptspeicher 1114, 1116 wird durch eine Speichersteuerung gesteuert.
Die Prozessorplattform 1100 des veranschaulichten Beispiels umfasst zudem eine Schnittstellenschaltung 1120. Die Schnittstellenschaltung 1120 kann durch eine beliebige Art von Schnittstellenstandard implementiert werden, wie etwa eine Ethernet-Schnittstelle, einen Universal Serial Bus (USB), eine Bluetooth-Schnittstelle, eine Nahfeldkommunikations- (NFC-) Schnittstelle und/oder eine PCI-express-Schnittstelle.
In dem veranschaulichten Beispiel sind eine oder mehrere Eingabeeinrichtungen 1122 mit der Schnittstellenschaltung 1120 verbunden. Die Eingabeeinrichtung(en) 1122 ermöglichen es einem Benutzer, Daten und/oder Befehle in den Prozessor 1112 einzugeben. Die Eingabeeinrichtung(en) kann(können) beispielsweise durch einen Audiosensor, ein Mikrofon, eine Kamera (Stand- oder Video), eine Tastatur, eine Taste, eine Maus, einen Touchscreen, ein Trackpad, einen Trackball, Isopoint und/oder ein Spracherkennungssystem implementiert sein.
Eine oder mehrere Ausgabeeinrichtungen 1124 sind ebenfalls mit der Schnittstellenschaltung 1120 des veranschaulichten Beispiels verbunden. Die Ausgabeeinrichtungen 1124 können zum Beispiel durch Anzeigeeinrichtungen (z.B. eine Leuchtdiode (LED), eine organische Leuchtdiode (OLED), eine Flüssigkristallanzeige (LCD), eine Kathodenstrahlröhren- (CRT-) Anzeige, eine In-Place-Switching- (IPS-) Anzeige, einen Touchscreen usw.), einen Drucker und/oder Lautsprecher implementiert werden. Die Schnittstellenschaltung 1120 des veranschaulichten Beispiels umfasst somit typischerweise eine Grafiktreiber-Karte, einen Grafiktreiber-Chip und/oder einen Grafiktreiber-Prozessor.
Die Schnittstellenschaltung 1120 des veranschaulichten Beispiels umfasst außerdem eine Kommunikationseinrichtung, wie einen Sender, einen Empfänger, einen Sendeempfänger, ein Modem, ein Residential Gateway, einen drahtlosen Zugangspunkt und/oder eine Netzwerkschnittstelle, um den Austausch von Daten mit externen Maschinen (z.B. Datenverarbeitungseinrichtungen beliebiger Art) über ein Netzwerk 1126 zu unterstützen. Die Kommunikation kann zum Beispiel über eine Ethernet-Verbindung, eine DSL-Verbindung (DSL: Digital Subscriber Line), eine Telefonleitungsverbindung, ein Koaxialkabelsystem, ein Satellitensystem, ein Drahtlosleitungssystem, ein Mobilfunksystem usw. erfolgen.
Die Prozessorplattform 1100 des veranschaulichten Beispiels umfasst zudem eine oder mehrere Massenspeichereinrichtungen 1128 zum Speichern von Software und/oder Daten. Beispiele für solche Massenspeichereinrichtungen 1128 umfassen Diskettenlaufwerke, Festplattendatenträger, Compact Disk-Laufwerke, Blu-ray-Festplattenlaufwerke, Redundant Array of Independent Disks-Systeme (RAID-Systeme) und Digital Versatile Disk-Laufwerke (DVD-Laufwerke).
Die maschinenausfiihrbaren Anweisungen 1132 aus 5A1, 5A2, 5A3, 5B, 6A, 6B, 7, 8A-8E, 9 und 10 können in der Massenspeichereinrichtung 1128, im flüchtigen Speicher 1114, im nichtflüchtigen Speicher 1116 und/oder auf einem entfernbaren nicht transienten computerlesbaren Speichermedium, wie etwa einer CD oder DVD, gespeichert sein.
Auch wenn vorstehend offenbarte Beispiele in einer Edge-Cloud-Umgebung realisiert werden können und 11 eine beispielhafte Verarbeitungsplattform 1100 veranschaulicht, auf der bestimmte Beispiele implementiert werden können, können bestimmte Beispiele in anderen Cloud-/Edge-Umgebungen mit anderen Verarbeitungskonfigurationen implementiert werden.
12 ist ein Blockdiagramm 1200, das einen Überblick über eine andere Konfiguration für Edge Computing zeigt, die eine Verarbeitungsschicht umfasst, die in vielen der folgenden Beispiele als „Edge-Cloud“ bezeichnet wird. Wie gezeigt, befindet sich die Edge-Cloud 1210 gemeinsam an einem Edge-Ort, wie etwa einem Zugangspunkt oder einer Basisstation 1240, einem lokalen Verarbeitungs-Hub 1250 oder einer Zentrale 1220, und kann somit mehrere Entitäten, Einrichtungen und Geräteinstanzen umfassen. Die Edge-Cloud 1210 befindet sich viel näher an den Endpunkt-Datenquellen 1260 (Verbraucher und Erzeuger) (z. B. autonome Fahrzeuge 1261, Endgerät 1262, Geschäfts- und Industriegerät 1263, Videoaufnahmevorrichtungen 1264, Drohnen 1265, Vorrichtungen für Smart Cities und Buildings 1266, Sensoren und IoT-Vorrichtungen 1267 usw.) als das Cloud-Rechenzentrum 1230. Rechen-, Speicher- und Speicherungsressourcen, die an den Edges in der Edge-Cloud 1210 angeboten werden, sind kritisch für das Bereitstellen von Antwortzeiten mit ultraniedriger Latenz für Dienste und Funktionen, die durch die Endpunktdatenquellen 1260 verwendet werden, sowie für das Reduzieren von Netzwerk-Rückverkehr aus der Edge-Cloud 1210 zum Cloud-Datenzentrum 1230, wodurch unter anderem Energieverbrauch und Gesamtnetzwerknutzung verbessert werden.
Berechnung, Speicher und Speicherung sind knappe Ressourcen und nehmen im Allgemeinen in Abhängigkeit vom Edge-Standort ab (wobei z.B. weniger Verarbeitungsressourcen an Verbraucherendpunkteinrichtungen verfügbar sind als an einer Basisstation, und dort weniger als an einer Zentrale). Je näher sich der Edge-Ort jedoch an dem Endpunkt (zum Beispiel UEs) befindet, desto mehr sind dieser Raum und diese Leistung häufig eingeschränkt. Somit versucht Edge Computing die Menge an Ressourcen, die für Netzwerkdienste benötigt werden, durch die Verteilung von mehr Ressourcen zu reduzieren, die sich sowohl geografisch als auch in der Netzwerkzugriffszeit näher befinden. Auf diese Weise versucht Edge Computing, die Datenverarbeitungsressourcen gegebenenfalls zu den Arbeitslastdaten zu bringen oder die Arbeitslastdaten zu den Datenverarbeitungsressourcen zu bringen.
Das Folgende beschreibt Aspekte einer Edge-Cloud-Architektur, die mehrere mögliche Einsätze abdeckt und Einschränkungen berücksichtigt, die einige Netzbetreiber oder Dienstanbieter in ihren eigenen Infrastrukturen aufweisen können. Diese beinhalten Konfigurationsschwankungen basierend auf dem Edge-Standort (weil Edges auf Basisstationsebene zum Beispiel mehr eingeschränkte Leistungsfähigkeit und Fähigkeiten in einem Multi-Mandanten-Szenario aufweisen können); Konfigurationen basierend auf der Art der Berechnung, des Speichers, der Speicherung, der Fabric, der Beschleunigung oder ähnlicher Ressourcen, die Edge-Standorten, Ebenen von Standorten oder Gruppen von Standorten zur Verfügung stehen; die Dienst-, Sicherheits- und Verwaltungs- und Orchestrierungsfähigkeiten; und verwandte Ziele zum Erreichen einer Nutzbarkeit und Leistung von Enddiensten. Diese Bereitstellungen können ein Verarbeiten in Netzwerkschichten bewerkstelligen, die in Abhängigkeit von Latenz-, Entfernungs- und Zeitgebungsmerkmalen als „Near Edge“-, „Close Edge“-, „Local Edge“-, „Middle Edge“- oder „Far Edge“-Schichten betrachtet werden können.
Edge Computing ist ein sich entwickelndes Paradigma, bei dem die Berechnung an oder näher an dem „Rand“ (edge) eines Netzwerks durchgeführt wird, typischerweise durch die Verwendung einer Datenverarbeitungsplattform (z.B. x86- oder ARM-Rechenhardwarearchitektur), die an Basisstationen implementiert ist, Gateways, Netzwerkrouter oder andere Einrichtungen, die sich viel näher an Endpunkteinrichtungen befinden, die Daten erzeugen und beanspruchen (z.B. an einer „lokalen Edge“, „angrenzenden Edge“ oder „nahen Edge“). Beispielsweise können Edge-Gatewayserver mit Beständen von Arbeitsspeicher- und Speicherungsressourcen ausgestattet sein, um eine Berechnung in Echtzeit für Anwendungsfälle mit niedriger Latenz (z. B. autonomes Fahren oder Videoüberwachung) für angebundene Clientvorrichtungen durchzuführen. Oder als ein Beispiel können Basisstationen mit Rechen- und Beschleunigungsressourcen erweitert werden, um Dienstarbeitslasten für angebundene Endgeräte direkt zu verarbeiten, ohne weiter Daten über Backhaul-Netzwerke zu kommunizieren. Oder als ein anderes Beispiel kann Zentralen-Netzwerkverwaltungshardware durch standardisierte Berechnungshardware ersetzt werden, die virtualisierte Netzwerkfunktionen durchführt und Berechnungsressourcen für die Ausführung von Diensten und Verbraucherfunktionen für verbundene Einrichtungen anbietet. Innerhalb von Edge-Computing-Netzwerken kann es Szenarien in Diensten geben, in denen die Berechnungsressource zu den Daten „verschoben“ wird, sowie Szenarien, in denen die Daten zu der Berechnungsressource „verschoben“ werden. Oder als ein Beispiel können Basisstationsberechnungs-, Beschleunigungs- und Netzwerkressourcen Dienste bereitstellen, um die Arbeitslastanforderungen nach Bedarf durch Aktivieren ruhender Kapazität (Subskription, Kapazität nach Bedarf) zu skalieren, um Eckfälle, Notfälle zu verwalten oder Langlebigkeit für eingesetzte Ressourcen über einen wesentlich längeren umgesetzten Lebenszyklus bereitzustellen.
13 veranschaulicht Betriebsschichten zwischen Endpunkten, einer Edge-Cloud und Cloud-Computing-Umgebungen. Insbesondere stellt 13 Beispiele für Rechenanwendungsfälle 1305 dar, die die Edge-Cloud 1210 unter mehreren veranschaulichenden Schichten der Netzwerkberechnung nutzen. Die Schichten beginnen bei einer Endpunktschicht (Einrichtungen- und Dinge-Schicht) 1300, die auf die Edge-Cloud 1210 zugreift, um Datenanlegungs-, Analyse- und Datenverbrauchsaktivitäten auszuführen. Die Edge-Cloud 1210 kann mehrere Netzwerkschichten überspannen, wie etwa eine Edge-Geräte-Schicht 1310, Gateways, Vor-Ort-Server oder Netzwerkgeräte (Knoten 1315), die sich in physisch nahen Edge-Systemen befinden; eine Netzwerkzugangsschicht 1320, einschließlich Basisstationen, Funkverarbeitungseinheiten, Netzwerk-Hubs, regionaler Datenzentren oder lokalem Netzwerkgerät (Gerät 1325); und beliebige Geräte, Einrichtungen oder Knoten, die dazwischen liegen (in Schicht 1312, nicht ausführlich veranschaulicht). Die Netzwerkkommunikationen innerhalb der Edge-Cloud 1210 und inmitten der verschiedenen Schichten können über eine beliebige Anzahl von drahtgebundenen oder drahtlosen Medien stattfinden, einschließlich über Konnektivitätsarchitekturen und Technologien, die nicht dargestellt sind.
Beispiele für Latenz, die aus Netzwerkkommunikationsentfernungs- und Verarbeitungszeiteinschränkungen resultieren, können von weniger als einer Millisekunde (ms), wenn unter der Endpunktschicht 1300, unter 5 ms an der Edge-Einrichtungsschicht 1310 (z.B. eine „nahe Edge“- oder „angrenzende Edge“-Schicht) bis sogar zwischen 10 und 40 ms reichen, wenn mit Knoten an der Netzwerkzugangsschicht 1320 (z.B. einer „mittleren Edge“-Schicht) kommuniziert wird. Jenseits der Edge-Cloud 1210 befinden sich die Schichten von Kernnetzwerk 1330 und Cloud-Datenzentrum 1340, jede mit zunehmender Latenz (z.B. zwischen 50 bis 60 ms auf der Kernnetzwerkschicht 1330 bis 100 oder mehr ms auf der Cloud-Datenzentrumsschicht, beide können als „Far Edge“-Schicht angesehen werden). Infolgedessen werden Operationen in einem Kernnetz-Rechenzentrum 1335 oder einem Cloud-Rechenzentrum 1345 mit Latenzen von mindestens 50 bis 100 ms oder mehr nicht in der Lage sein, viele zeitkritische Funktionen der Anwendungsfälle 1305 zu realisieren. Jeder dieser Latenzwerte wird zu Veranschaulichungs- und Kontrastzwecken bereitgestellt; es versteht sich, dass die Verwendung anderer Zugangsnetzwerkmedien und - technologien die Latenzen weiter reduzieren kann.
Die diversen Nutzungsfälle 1305 können aufgrund mehrerer Dienste, die die Edge-Cloud nutzen, auf Ressourcen unter Nutzungsdruck von eingehenden Strömen zugreifen. Um Ergebnisse mit niedriger Latenz zu erzielen, gleichen die Dienste, die innerhalb der Edge-Cloud 1210 ausgeführt werden, variierende Anforderungen in Bezug auf Folgendes aus: (a) Priorität (Durchsatz oder Latenz) und Dienstgüte (QoS: Quality of Service) (z.B. kann Verkehr für ein autonomes Auto eine höhere Priorität als ein Temperatursensor hinsichtlich der Antwortzeitvoraussetzung aufweisen; oder eine Performanzempfindlichkeit/-engstelle kann an einer Berechnungs-/Beschleuniger-, Speicher-, Speicherungs- oder Netzwerkressource in Abhängigkeit von der Anwendung existieren); (b) Zuverlässigkeit und Widerstandsfähigkeit (z. B. müssen manche Eingangsströme bearbeitet und der Verkehr mit missionskritischer Zuverlässigkeit geleitet werden, wohingegen manche anderen Eingangsströme je nach Anwendung einen gelegentlichen Ausfall tolerieren können); und (c) physikalische Beschränkungen (z. B. Leistung, Kühlung und Formfaktor).
Die Ende-zu-Ende-Dienstansicht für diese Anwendungsfälle beinhaltet das Konzept eines Dienstablaufs und ist mit einer Transaktion assoziiert. Die Transaktion gibt die Gesamtdienstanforderung für die Entität an, die den Dienst verbraucht, sowie die zugehörigen Dienste für die Ressourcen, Arbeitslasten, Arbeitsabläufe und Geschäftsfunktions- und Geschäftsebenenanforderungen. Die Dienste, die mit den beschriebenen „Bedingungen“ ausgeführt werden, können in jeder Schicht auf eine Weise verwaltet werden, dass eine Echtzeit- und Laufzeitvertragskonformität für die Transaktion während des Lebenszyklus des Dienstes sichergestellt wird. Wenn eine Komponente in der Transaktion ihre vereinbarte SLA verfehlt, kann das System als Ganzes (Komponente in der Transaktion) die Fähigkeit bereitstellen, (1) die Auswirkung des SLA-Verstoßes zu verstehen und (2) andere Komponenten in dem System zur Wiederaufnahme der gesamten Transaktions-SLA erweitern und (3) Schritte zur Behebung umsetzen.
Dementsprechend kann unter Berücksichtigung dieser Variationen und Dienstleistungsmerkmale Edge Computing innerhalb der Edge-Cloud 110 die Fähigkeit bereitstellen, mehrere Anwendungen der Verwendungsfälle 205 (z.B. Objektverfolgung, Videoüberwachung, verbundene Autos usw.) in Echtzeit oder nahezu Echtzeit zu versorgen und auf diese zu reagieren und Anforderungen an ultraniedrige Latenz für diese mehreren Anwendungen zu erfüllen. Diese Vorteile ermöglichen eine ganze neue Klasse von Anwendungen (virtuelle Netzwerkfunktionen - Virtual Network Functions - ), FaaS (Function as a Service), Edge as a Service (EaaS), Standardprozesse usw.), die ein herkömmliches Cloud-Computing aufgrund von Latenz oder anderer Einschränkungen nicht nutzen können.
Mit den Vorteilen des Edge Computing ergeben sich jedoch die folgenden Vorbehalte. Die an der Edge befindlichen Einrichtungen sind häufig ressourcenbeschränkt, und deshalb besteht Druck auf die Nutzung von Edge-Ressourcen. Typischerweise wird dies durch das Pooling von Speicher und Speicherungsressourcen zur Verwendung durch mehrere Benutzer (Mandanten) und Einrichtungen adressiert. Die Edge kann hinsichtlich Leistung und Kühlung eingeschränkt sein, sodass der Leistungsverbrauch durch die Anwendungen berücksichtigt werden muss, die die meiste Leistung verbrauchen. Es kann bei diesen gepoolten Speicherressourcen inhärente Leistung/Performanz-Kompromisse geben, da viele von ihnen wahrscheinlich entstehende Speichertechnologien verwenden, bei welchen mehr Leistung eine größere Speicherbandbreite benötigt. Gleichermaßen sind verbesserte Sicherheit von Hardware und vertrauenswürdigen Wurzelfunktionen auch erforderlich, da Edge-Orte unbemannt sein können und sogar erlaubten Zugriff benötigen können (z.B. wenn sie an einem Drittparteistandort untergebracht sind). Derartige Probleme werden in der Edge-Cloud 1210 in einer Multi-Mandanten-, Multi-Eigentümer- oder Multi-Zugriffssituation vergrößert, bei der Dienste und Anwendungen von vielen Benutzern angefordert werden, insbesondere, da die Netzwerknutzung dynamisch schwankt und sich die Zusammensetzung der mehreren Beteiligten, Anwendungsfälle und Dienste ändert.
Auf einer allgemeineren Ebene kann ein Edge-Computing-System so beschrieben werden, dass es eine beliebige Anzahl von Verwendungen an den zuvor erörterten Schichten umfasst, die in der Edge-Cloud 1210 arbeiten (Netzwerkschichten 1300-1340), die eine Koordination von Client- und verteilten Datenverarbeitungseinrichtungen bereitstellen. Ein oder mehrere Edge-Gateway-Knoten, ein oder mehrere Edge-Aggregationsknoten und ein oder mehrere Kernrechenzentren können über Schichten des Netzwerks verteilt sein, um eine Implementierung des Edge-Rechensystems durch oder im Auftrag eines Telekommunikationsdienstanbieters („Telco“ oder „TSP“), eines Internet-der-Dinge-Dienstanbieters, eines Cloud-Dienstanbieters (CSP), einer Unternehmens entität oder einer beliebigen anderen Anzahl von Entitäten bereitzustellen. Verschiedene Implementierungen und Konfigurationen des Edge-Rechensystems können dynamisch bereitgestellt werden, wie zum Beispiel, bei Orchestrierung, um Dienstziele zu erfüllen.
Im Einklang mit den vorliegend bereitgestellten Beispielen kann ein Client-Rechenknoten als eine beliebige Art von Endpunktkomponente, Einrichtung, Gerät oder Ähnliches ausgestaltet sein, das dazu in der Lage ist, als ein Produzent oder Verbraucher von Daten zu kommunizieren. Ferner bedeutet die Bezeichnung „Knoten“ oder „Einrichtung“, wie im Edge-Computing-System verwendet, nicht notwendigerweise, dass ein solcher Knoten oder eine solche Einrichtung in einer Client- oder Slave-Rolle arbeitet; vielmehr beziehen sich beliebige der Knoten oder Einrichtungen im Edge-Computing-System auf einzelne Entitäten, Knoten oder Teilsysteme, die diskrete oder verbundene Hardware- oder Softwarekonfigurationen beinhalten, um die Edge-Cloud 1210 zu ermöglichen oder zu verwenden.
Somit ist die Edge-Cloud 1210 aus Netzwerkkomponenten und funktionalen Merkmalen gebildet, die durch und innerhalb von Edge-Gateway-Knoten, Edge-Aggregationsknoten oder anderen Edge-Rechenknoten unter den Netzwerkschichten 1310-1330 betrieben werden. Die Edge-Cloud 1210 kann somit als eine beliebige Art von Netzwerk ausgebildet sein, das Edge-Rechen- und/oder Speicherungsressourcen bereitstellt, die sich in der Nähe von Funkzugangsnetzwerk- (RAN-) fähigen Endpunkteinrichtungen (z.B. Mobilrecheneinrichtungen, IoT-Einrichtungen, Smart-Einrichtungen usw.) befinden, die vorliegend behandelt werden. Mit anderen Worten kann man sich die Edge-Cloud 110 als ein „Edge“ vorstellen, das die Endpunkteinrichtungen und traditionelle Netzwerkzugangspunkte verbindet, das als ein Eintrittspunkt in Dienstanbieter-Kernnetzwerke, einschließlich Mobilträgernetzwerken (z. B. Global System for Mobile Communications-Netzwerken (GSM-Netzwerken), Long-Term Evolution-Netzwerken (LTE-Netzwerken), 5G/6G-Netzwerken usw.) dient, während auch Speicherungs- und/oder Rechenfähigkeiten bereitgestellt werden. Andere Arten und Formen des Netzwerkzugriffs (z. B. WiFi, drahtlose, verdrahtete Langstreckennetze einschließlich optischer Netzwerke) können auch anstatt oder in Kombination mit derartigen 3GPP-Trägernetzen eingesetzt werden.
Die Netzwerkkomponenten der Edge-Cloud 1210 können Server, Multi-Mandanten-Server, Gerätedatenverarbeitungseinrichtungen und/oder eine beliebige andere Art von Datenverarbeitungseinrichtungen sein. Zum Beispiel kann die Edge-Cloud 1210 eine Gerätedatenverarbeitungseinrichtung sein, die ein eigenständiges Verarbeitungssystem einschließlich eines Gehäuses, einer Hülle oder einer Verschalung ist. In einigen Fällen sind Edge-Einrichtungen Einrichtungen, die in dem Netzwerk für einen spezifischen Zweck (z.B. eine Ampel) präsentiert werden, die aber Verarbeitungs- oder andere Kapazitäten aufweisen, die für andere Zwecke genutzt werden können. Solche Edge-Einrichtungen können unabhängig von anderen vernetzten Einrichtungen sein und mit einem Gehäuse versehen sein, das einen Formfaktor aufweist, der für seinen primären Zweck geeignet ist, und dennoch für andere Rechenaufgaben verfügbar sein, die seine primäre Aufgabe nicht stören. Edge-Einrichtungen umfassen Einrichtungen des Internets der Dinge. Die Gerätedatenverarbeitungseinrichtung kann Hardware- und Softwarekomponenten beinhalten, um lokale Angelegenheiten, wie etwa Vorrichtungstemperatur, Vibration, Ressourcenausnutzung, Aktualisierungen, Stromangelegenheiten, physische und Netzwerksicherheit usw., zu verwalten. Beispielhafte Hardware zum Implementieren einer Gerätedatenverarbeitungseinrichtung ist in Verbindung mit 18B beschrieben. Die Edge-Cloud 1210 kann zudem einen oder mehrere Server und/oder einen oder mehrere multimandantenfähige Server umfassen. Ein solcher Server kann eine virtuelle Datenverarbeitungsumgebung implementieren, wie etwa einen Hypervisor zum Einsetzen virtueller Maschinen, ein Betriebssystem, das Container implementiert usw. Solche virtuellen Datenverarbeitungsumgebungen stellen eine Ausführungsumgebung bereit, in der eine oder mehrere Anwendungen ausgeführt werden können, während sie von einer oder mehreren anderen Anwendungen isoliert sind.
In 14 tauschen verschiedene Client-Endpunkte 1410 (in der Form von Mobileinrichtungen, Computern, autonomen Fahrzeugen, Geschäftsrechenanlagen, industriellen Verarbeitungsanlagen) Anfragen und Antworten aus, die für den Typ der Endpunktnetzwerkaggregation spezifisch sind. Beispielsweise können Computer, geschäftliche Datenverarbeitungsgeräte und Industrieverarbeitungsgeräte Netzwerkzugang über ein verdrahtetes Breitbandnetzwerk erhalten, indem Anfragen und Antworten 1422 durch ein Vor-Ort-Netzwerksystem 1432 ausgetauscht werden. Mobile Datenverarbeitungseinrichtungen können Netzwerkzugang über ein drahtloses Breitbandnetzwerk erhalten, indem sie Anfragen und Antworten 1424 durch einen Mobilfunkturm 1434 austauschen. Autonome Fahrzeuge können Netzwerkzugang für Anfragen und Antworten 1426 über ein drahtloses Fahrzeugnetzwerk durch ein Straßennetzwerksystem 1436 erhalten. Unabhängig von der Art des Netzwerkzugangs kann der TSP jedoch Aggregationspunkte 1442, 1444 innerhalb der Edge-Cloud 1210 einsetzen, um Verkehr und Anfragen zu aggregieren. Somit kann der TSP innerhalb der Edge-Cloud 1210 verschiedene Berechnungs- und Speicherungsressourcen einsetzen, wie etwa bei Edge-Aggregationsknoten 1440, um angeforderten Inhalt bereitzustellen. Die Edge-Aggregationsknoten 1440 und andere Systeme der Edge-Cloud 1210 sind mit einer Cloud oder einem Datenzentrum 1460 verbunden, die/das ein Backhaul-Netzwerk 1450 verwendet, um Anforderungen mit höherer Latenz von einer Cloud/einem Datenzentrum für Websites, Anwendungen, Datenbankserver usw. zu erfüllen. (Zusätzliche oder konsolidierte Instanzen der Edge-Aggregationsknoten 1440 und der Aggregationspunkte 1442, 1444, einschließlich jener, die auf einem einzigen Server-Framework eingesetzt sind, können auch innerhalb der Edge-Cloud 1210 oder anderer Bereiche der TSP-Infrastruktur vorhanden sein).
15 veranschaulicht Einsatz und Orchestrierung für virtuelle Edge-Konfigurationen über ein Edge-Computing-System, das zwischen mehreren Edge-Knoten und mehreren Mandanten betrieben wird. Insbesondere stellt 15 eine Koordination eines ersten Edge-Knotens 1522 und eines zweiten Edge-Knotens 1524 in einem Edge-Computing-System 1500 dar, um Anforderungen und Antworten für verschiedene Client-Endpunkte 1510 (zum Beispiel Smart Cities / Gebäudesysteme, Mobileinrichtungen, Recheneinrichtungen, Geschäfts-/Logistiksysteme, Industriesysteme usw.), die auf verschiedene virtuelle Edge-Instanzen zugreifen, zu erfüllen. Hier stellen die virtuellen Edge-Instanzen Edge-Computingsfähigkeiten und Verarbeitung in einer Edge-Cloud mit Zugriff auf ein Cloud/Datenzentrum 1540 für Anfragen mit höherer Latenz für Websites, Anwendungen, Datenbankserver usw. bereit. Die Edge-Cloud ermöglicht jedoch eine Koordination der Verarbeitung unter mehreren Edge-Knoten für mehrere Mandanten oder Entitäten.
In dem Beispiel aus 15 beinhalten diese virtuellen Edge-Instanzen: einen ersten virtuellen Edge 1532, der einem ersten Mandanten (Mandanten 1) angeboten wird, der eine erste Kombination von Edge-Speicherung, Computing und Diensten anbietet; und einen zweiten virtuellen Edge 1534, der eine zweite Kombination von Edge-Speicherung, Computing und Diensten anbietet. Die virtuellen Edge-Instanzen 1532, 1534 sind unter den Edge-Knoten 1522, 1524 verteilt und können Szenarien beinhalten, in denen eine Anforderung und Antwort von demselben oder unterschiedlichen Edge-Knoten erfüllt werden. Die Konfiguration der Edge-Knoten 1522, 1524 zum Arbeiten auf eine verteilte, aber koordinierte Weise erfolgt basierend auf Edge-Bereitstellungsfunktionen 1550. Die Funktionalität der Edge-Knoten 1522, 1524 zum Bereitstellen eines koordinierten Betriebs für Anwendungen und Dienste unter mehreren Mandanten findet basierend auf Orchestrierungsfunktionen 1560 statt.
Es versteht sich, dass einige der Einrichtungen in 1510 Multi-Mandanten-Einrichtungen sind, wobei Mandant 1 innerhalb eines Mandantl-„Slice“ funktionieren kann, während ein Mandant 2 innerhalb eines Mandant2-Slice funktionieren kann (und, in weiteren Beispielen können zusätzliche oder Unter-Mandanten existieren; und jeder Mandant kann sogar spezifisch berechtigt und transaktionell an einen spezifischen Satz von Merkmalen bis zu spezifischen Hardwaremerkmalen gebunden sein). Eine vertrauenswürdige Multi-Mandanten-Einrichtung kann ferner einen mandantenspezifischen kryptografischen Schlüssel enthalten, sodass die Kombination aus Schlüssel und Segment als eine „Stammvertrauenstellung“ (RoT) oder mandantenspezifische RoT angesehen werden kann. Eine RoT kann ferner dynamisch unter Verwendung einer DICE-Architektur (Device Identity Composition Engine) berechnet werden, sodass ein einzelner DICE-Hardwarebaustein verwendet werden kann, um geschichtete vertrauenswürdige Rechenbasiskontexte zur Schichtung von Einrichtungsfähigkeiten (wie etwa ein frei programmierbares Gate-Array (FPGA)) zu konstruieren. Die RoT kann ferner für einen vertrauenswürdigen Rechenkontext verwendet werden, um eine „Ausfächerung“ zu ermöglichen, die zum Unterstützen einer Multi-Mandantenfähigkeit nützlich ist. Innerhalb einer Multi-Mandanten-Umgebung können die jeweiligen Edge-Knoten 1522, 1524 als Sicherheitsmerkmaldurchsetzungspunkte für lokale Ressourcen arbeiten, die mehreren Mandanten pro Knoten zugewiesen sind. Zusätzlich können Mandantenlaufzeit- und Anwendungsausführung (z.B. in den Fällen 1532, 1534) als ein Durchsetzungspunkt für ein Sicherheitsmerkmal dienen, das eine virtuelle Edge-Abstraktion von Ressourcen erzeugt, die potenziell mehrere physische Hostingplattformen umspannen. Schließlich können die Orchestrierungsfunktionen 1560 an einer Orchestrierungsentität als ein Sicherheitsmerkmals-Durchsetzungspunkt zum Lenken von Ressourcen entlang Mandantengrenzen fungieren.
Edge-Rechenknoten können Ressourcen (Speicher, CPU, GPU, Interruptsteuerung, E/A-Steuerung, Speichersteuerung, Bussteuerung usw.) partitionieren, wobei jeweilige Partitionierungen eine RoT-Fähigkeit enthalten können und wobei Fan-Out und Schichtung gemäß einem DICE-Modell ferner auf Edge-Knoten angewendet werden können. Cloud-Rechenknoten, die aus Containern, FaaS-Engines, Servlets, Servern oder einer anderen Berechnungsabstraktion bestehen, können gemäß einer DICE-Schichtungs- und Ausfächerungsstruktur partitioniert werden, um für jede der Abstraktionen einen RoT - Kontext zu unterstützen. Dementsprechend können die jeweiligen Einrichtungen 1510, 1522 und 1540, die RoTs umspannen, die Einrichtung einer verteilten vertrauenswürdigen Rechenbasis (DTCB) koordinieren, sodass ein mandantenspezifischer virtueller vertrauenswürdiger sicherer Kanal, der alle Elemente durchgehend verbindet, eingerichtet werden kann.
Ferner versteht es sich, dass ein Container daten- oder arbeitslastspezifische Schlüssel aufweisen kann, die seinen Inhalt vor einem vorherigen Edge-Knoten schützen. Als Teil der Migration eines Containers kann eine Pod-Steuerung an einem Quell-Edge-Knoten einen Migrationsschlüssel von einer Ziel-Edge-Knoten-Pod-Steuerung erhalten, wobei der Migrationsschlüssel zum Verpacken der containerspezifischen Schlüssel verwendet wird. Wenn der Container/Pod zum Ziel-Edge-Knoten migriert wird, wird der Entpackungsschlüssel der Pod-Steuerung offenbart, die dann die verpackten Schlüssel entschlüsselt. Die Schlüssel können nun zur Durchführung von Operationen an containerspezifischen Daten verwendet werden. Die Migrationsfunktionen können durch korrekt bestätigte Edge-Knoten und Pod-Manager (wie oben beschrieben) angesteuert werden.
In weiteren Beispielen wird ein Edge-Computing-System erweitert, um Orchestrierung mehrerer Anwendungen durch die Verwendung von Containern (einer containerisierten, einsetzbaren Softwareeinheit, die Code und benötigte Abhängigkeiten bereitstellt) in einer Multi-Eigentümer-, Multi-Mandanten-Umgebung bereitzustellen. Ein Multi-Mandanten-Orchestrator kann verwendet werden, um Schlüsselverwaltung, Vertrauensanker-Verwaltung und andere Sicherheitsfunktionen in Bezug auf die Bereitstellung und den Lebenszyklus des vertrauenswürdigen ,Segment‘-Konzepts in 15 durchzuführen. Beispielsweise kann ein Edge-Computing-System ausgelegt sein, Anfragen und Antworten für verschiedene Client-Endpunkte von mehreren virtuellen Edge-Instanzen (und von einer Cloud oder einem entfernten Rechenzentrum) zu erfüllen. Die Verwendung dieser virtuellen Edge-Instanzen kann mehrere Mandanten und mehrere Anwendungen (z. B. erweiterte Realität (AR)/virtuelle Realität (VR), Unternehmens anwendungen, Inhaltslieferung, Gaming, Rechen-Auslagerung) gleichzeitig unterstützen. Ferner kann es mehrere Arten von Anwendungen innerhalb der virtuellen Edge-Instanzen geben (z.B. normale Anwendungen; latenzempfindliche Anwendungen; latenzkritische Anwendungen; Benutzerebenenanwendungen; Vernetzungsanwendungen usw.). Die virtuellen Edge-Instanzen können auch über Systeme mehrerer Eigentümer an unterschiedlichen geografischen Standorten (oder jeweilige Rechensysteme und Ressourcen, die von mehreren Eigentümern gemeinsam besessen oder gemeinsam verwaltet werden) verteilt sein.
Beispielsweise kann jeder Edge-Knoten 1522, 1524 die Verwendung von Containern implementieren, wie etwa unter Verwendung eines Container-„Pods“ 1526, 1528, der eine Gruppe aus einem oder mehreren Containern bereitstellt. In einer Einstellung, die eine oder mehrere Container-Pods verwendet, ist eine Pod-Steuerung oder ein Orchestrator für die lokale Steuerung und Orchestrierung der Container im Pod verantwortlich. Verschiedene Edge-Knotenressourcen (z. B. Speicherung, Berechnung, Dienste, dargestellt mit Hexagonen), die für die jeweiligen Edge-Segmente 1532, 1534 bereitgestellt werden, werden gemäß den Bedürfnissen jedes Containers partitioniert.
Bei der Verwendung von Container-Pods überwacht eine Pod-Steuerung die Partitionierung und Zuteilung von Containern und Ressourcen. Die Pod-Steuerung empfängt Anweisungen von einem Orchestrator (z.B. dem Orchestrator 1560), die die Steuerung darüber anweisen, wie physische Ressourcen am besten und für welche Dauer zu partitionieren sind, wie etwa durch Empfangen von Schlüsselperformanzkennzahl- (KPI-, key Performance indicator) Zielen basierend auf SLA-Verträgen. Die Pod-Steuerung ermittelt, welcher Container welche Ressourcen und wie lange benötigt, um die Arbeitslast abzuschließen und die SLA zu erfüllen. Die Pod-Steuerung verwaltet auch Containerlebenszyklusoperationen, wie etwa: Erzeugen des Containers, Versehen desselben mit Ressourcen und Anwendungen, Koordinieren von Zwischenergebnissen zwischen mehreren Containern, die gemeinsam an einer verteilten Anwendung arbeiten, Abbauen von Containern, wenn die Arbeitslast abgeschlossen ist, und dergleichen. Zusätzlich dazu kann eine Pod-Steuerung in einer Sicherheitsrolle dienen, die eine Zuordnung von Ressourcen verhindert, bis sich der richtige Mandant authentifiziert, oder eine Bereitstellung von Daten oder einer Arbeitslast an einen Container verhindert, bis ein Bestätigungsergebnis erfüllt ist.
Auch bei der Verwendung von Container-Pods können Mandantengrenzen immer noch existieren, aber im Kontext jedes Pods von Containern. Falls jeder mandantenspezifische Pod eine mandantenspezifische Pod-Steuerung aufweist, gibt es eine gemeinsam genutzte Pod-Steuerung, die Ressourcenzuweisungsanforderungen konsolidiert, um typische Ressourcenmangelsituationen zu vermeiden. Weitere Steuerungen können vorgesehen sein, um eine Bestätigung und Vertrauenswürdigkeit des Pods und der Pod-Steuerung zu gewährleisten. Beispielsweise kann der Orchestrator 1560 lokalen Pod-Steuerungen, die eine Bestätigungsprüfung durchführen, eine Bestätigungsprüfungsrichtlinie bereitstellen. Falls eine Bestätigung eine Richtlinie für eine erste Mandanten-Pod-Steuerung, aber nicht eine zweite Mandanten-Pod-Steuerung erfüllt, dann könnte der zweite Pod zu einem anderen Edge-Knoten migriert werden, der sie erfüllt. Alternativ dazu kann die Ausführung des ersten Pods erlaubt werden und eine andere gemeinsam genutzte Pod-Steuerung wird installiert und aufgerufen, bevor der zweite Pod ausgeführt wird.
16 veranschaulicht zusätzliche Datenverarbeitungsanordnungen, die Container in einem Edge-Computing-System einsetzen. Als ein vereinfachtes Beispiel stellen die Systemanordnungen 1610, 1620 Einstellungen dar, in denen eine Pod-Steuerung (z.B. Containermanager 1611, 1621, 1631) dazu ausgelegt ist, containerisierte Pods, Funktionen, und Functions-as-a-Service-Instanzen durch Ausführung über Rechenknoten (1615 in Anordnung 1610) oder separat containerisierte virtualisierte Netzwerkfunktionen durch Ausführung über Rechenknoten (1623 in Anordnung 1620) auszuführen. Diese Anordnung ist zur Verwendung mehrerer Mandanten in der Systemanordnung 1630 (unter Verwendung von Rechenknoten 1636) angepasst, wobei containerisierte Pods (z.B. Pods 1612), Funktionen (z.B. Funktionen 1613, VNFs 1622, 1636), und Functions-as-a-Service-Instanzen (z.B. FaaS-Instanz 1615) innerhalb virtueller Maschinen (z.B. VMs 1634, 1635 für Mandanten 1632, 1633) gestartet werden, die spezifisch für jeweilige Mandanten sind (abgesehen von der Ausführung virtualisierter Netzwerkfunktionen). Diese Anordnung ist ferner zur Verwendung in der Systemanordnung 1640 eingerichtet, die Container 1642, 1643 oder die Ausführung der verschiedenen Funktionen, Anwendungen und Funktionen auf den Rechenknoten 1644 bereitstellt, wie durch ein containerbasiertes Orchestrierungssystem 1641 koordiniert.
Die in 16 dargestellten Systemanordnungen stellen eine Architektur bereit, die VMs, Container und Funktionen gleichermaßen hinsichtlich der Anwendungszusammensetzung behandelt (und resultierende Anwendungen sind Kombinationen dieser drei Bestandteile). Jeder Bestandteil kann die Verwendung einer oder mehrerer Beschleuniger-Komponenten (FPGA, ASIC) als ein lokales Backend involvieren. Auf diese Weise können Anwendungen über mehrere Edge-Eigentümer aufgeteilt werden, koordiniert durch einen Orchestrator.
Im Kontext von 16 können die Pod-Steuerung/der Containermanager, der Containerorchestrator und einzelne Knoten einen Sicherheitsdurchsetzungspunkt bereitstellen. Die Mandantentrennung kann jedoch orchestriert werden, wo sich die Ressourcen, die einem Mandanten zugewiesen sind, von Ressourcen unterscheiden, die einem zweiten Mandanten zugewiesen sind, aber Edge-Eigentümer kooperieren, um sicherzustellen, dass Ressourcenzuweisungen nicht über Mandantengrenzen hinweg geteilt werden. Oder Ressourcenzuweisungen könnten über Mandantengrenzen hinweg isoliert werden, da Mandanten eine „Verwendung“ auf Abonnement- oder Transaktions-/Vertragsbasis ermöglichen könnten. In diesen Kontexten können Virtualisierungs-, Containerisierungs-, Enklaven- und Hardwarepartitionierungsschemata von Edge-Eigentümern verwendet werden, um einen Mandantenzustand durchzusetzen. Andere Isolationsumgebungen können beinhalten: (dedizierte) Bare-Metal-Geräte, virtuelle Maschinen, Container, virtuelle Maschinen auf Containern oder Kombinationen aus diesen.
In weiteren Beispielen können Aspekte von softwaredefinierter oder - gesteuerter Siliziumhardware und anderer konfigurierbarer Hardware mit den Anwendungen, Funktionen und Diensten ein Edge-Computing-System integrieren. Softwaredefiniertes Silizium kann verwendet werden, um die Fähigkeit sicherzustellen, dass irgendein Ressourcen- oder Hardwarebestandteil einen Vertrag oder eine Dienstgütevereinbarung erfüllt, basierend auf der Fähigkeit des Bestandteils, einen Abschnitt von sich selbst oder der Arbeitslast zu korrigieren (z. B. durch eine Hochrüstung, eine Neukonfiguration oder eine Bereitstellung neuer Funktionen innerhalb der Hardwarekonfiguration selbst).
Es versteht sich, dass die vorliegend behandelten Edge-Computing-Systeme und Anordnungen bei verschiedenen Lösungen, Diensten und/oder Anwendungsfällen anwendbar sein können, die Mobilität beinhalten. Als ein Beispiel zeigt 17 einen vereinfachten Fahrzeugberechnungs- und Kommunikationsanwendungsfall, der Mobilzugriff auf Anwendungen in einem Edge-Computing-System 1700 involviert, das eine Edge-Cloud 1210 implementiert. In diesem Anwendungsfall können die jeweiligen Client-Rechenknoten 1710 als fahrzeuginterne Rechensysteme (z.B. fahrzeuginterne Navigations- und/oder Infotainmentsysteme) ausgebildet sein, die sich in entsprechenden Fahrzeugen befinden, die mit den Edge-Gateway-Knoten 1720 während des Durchfahrens einer Straße kommunizieren. Beispielsweise können sich die Edge-Gateway-Knoten 1720 in einem Schrank am Straßenrand oder einer anderen Einhausung befinden, die in eine Struktur eingebaut ist, die einen anderen, separaten, mechanischen Nutzen aufweist und entlang der Straße, an Kreuzungen der Straße oder anderen Standorten nahe der Straße platziert werden kann. Wenn jeweilige Fahrzeuge entlang der Straße fahren, kann die Verbindung zwischen ihrem Client-Rechenknoten 1710 und einer bestimmten Edge-Gateway-Einrichtung 1720 propagieren, sodass eine konsistente Verbindung und ein konsistenter Kontext für den Client-Rechenknoten 1710 aufrechterhalten werden. Gleichermaßen können mobile Edge-Knoten an den Diensten mit hoher Priorität oder gemäß den Durchsatz- oder Latenzauflösungsanforderungen für den zugrundeliegenden Dienst bzw. die zugrundeliegenden Dienste aggregieren (z.B. im Fall von Drohnen). Die jeweiligen Edge-Gateway-Einrichtungen 1720 umfassen eine Menge an Verarbeitungs- und Speicherungsfähigkeiten, und daher können etwas Verarbeitung und/oder Speicherung von Daten für die Client-Rechenknoten 1710 auf einer oder mehreren der Edge-Gateway-Einrichtungen 1720 durchgeführt werden.
Die Edge-Gateway-Einrichtungen 1720 können mit einem oder mehreren Edge-Ressourcenknoten 1740 kommunizieren, die veranschaulichend als Rechenserver, -geräte oder -komponenten umgesetzt sind, die sich an oder in einer Kommunikationsbasisstation 1742 (z.B. einer Basisstation eines zellularen Netzwerks) befinden. Wie vorstehend besprochen, beinhalten die jeweiligen Edge-Ressourcenknoten 1740 eine Menge an Verarbeitungs- und Speicherungsfähigkeiten, sodass ein Teil der Verarbeitung und/oder Speicherung von Daten für die Client-Rechenknoten 1710 an dem Edge-Ressourcenknoten 1740 durchgeführt werden können. Zum Beispiel kann die Verarbeitung von Daten, die weniger dringend oder wichtig sind, durch den Edge-Ressourcenknoten 1740 durchgeführt werden, während die Verarbeitung von Daten, die eine höhere Dringlichkeit oder Wichtigkeit aufweisen, durch die Edge-Gateway-Einrichtungen 1720 durchgeführt werden kann (in Abhängigkeit beispielsweise von den Fähigkeiten jeder Komponente oder Informationen in der Anforderung, die Dringlichkeit oder Wichtigkeit angeben). Basierend auf Datenzugriff, Datenposition oder Latenz kann die Arbeit auf Edge-Ressourcenknoten fortgesetzt werden, wenn sich die Verarbeitungsprioritäten während der Verarbeitungsaktivität ändern. Gleichermaßen können konfigurierbare Systeme oder Hardwareressourcen selbst aktiviert werden (z.B. durch einen lokalen Orchestrator), um zusätzliche Ressourcen bereitzustellen, um den neuen Bedarf zu erfüllen (z.B. Anpassen der Rechenressourcen an die Arbeitslastdaten).
Der eine oder die mehreren Edge-Ressourcenknoten 1740 kommunizieren auch mit dem Kerndatenzentrum 1750, das Rechenserver, Geräte und/oder andere Komponenten umfassen kann, die sich an einem zentralen Standort (z.B. einer Zentrale eines zellularen Kommunikationsnetzwerks) befinden. Das Kernrechenzentrum 1750 kann ein Gateway zur globalen Netzwerk-Cloud 1760 (z.B. dem Internet) für die Operationen der Edge-Cloud 1210 bereitstellen, das durch den einen oder die mehreren Edge-Ressourcenknoten 1740 und die Edge-Gateway-Einrichtungen 1720 gebildet wird. Zusätzlich kann das Kernrechenzentrum 1750 in einigen Beispielen eine Menge an Verarbeitungs- und Speicherungsfunktionen beinhalten und somit kann ein Teil der Verarbeitung und/oder Speicherung von Daten für die Client-Recheneinrichtungen auf dem Kernrechenzentrum 1750 durchgeführt werden (z.B. Verarbeitung mit niedriger Dringlichkeit oder Wichtigkeit oder hoher Komplexität).
Der Edge-Gateway-Knoten 1720 oder die Edge-Ressourcenknoten 1740 können die Verwendung zustandsorientierter Anwendungen 1732 und einer geografischen verteilten Datenbank 1734 anbieten. Auch wenn die Anwendungen 1732 und die Datenbank 1734 als horizontal auf einer Schicht der Edge-Cloud verteilt veranschaulicht sind, versteht es sich, dass Ressourcen, Dienste oder andere Komponenten der Anwendung vertikal über den Edge-Cloud verteilt sein können (einschließlich eines Teils der Anwendung, die an dem Client-Rechenknoten 1710 ausgeführt wird, anderer Teile an dem Edge-Gateway-Knoten 1720 oder den Edge-Ressourcenknoten 1740 usw.). Zusätzlich dazu kann es, wie zuvor angegeben, Peer-Beziehungen auf einer beliebigen Ebene geben, um Dienstziele und Verpflichtungen zu erfüllen. Ferner können sich die Daten für einen bestimmten Client oder eine bestimmte Anwendung basierend auf sich ändernden Bedingungen (z.B. basierend auf Beschleunigungsressourcenverfügbarkeit, Folgen der Autobewegung usw.) von Edge zu Edge bewegen. Beispielsweise kann basierend auf der „Abklingrate“ des Zugangs eine Vorhersage getroffen werden, um den nächsten Eigentümer zum Fortsetzen zu identifizieren, oder wann die Daten oder der rechnerische Zugang nicht mehr praktikabel sein werden. Diese und andere Dienste können genutzt werden, um die Arbeit abzuschließen, die notwendig ist, um die Transaktion konform und verlustfrei zu halten.
In weiteren Szenarien kann ein Container 1736 (oder ein Pod von Containern) flexibel von einem Edge-Knoten 1720 zu anderen Edge-Knoten (z.B. 1720, 1740, 1750, 1760 usw.) migriert werden, so dass der Container mit einer Anwendung und Arbeitslast nicht rekonstituiert, rekompiliert, reinterpretiert werden muss, damit die Migration funktioniert. In derartigen Szenarien können jedoch einige abhelfende oder „Swizzling“-Übersetzungsoperationen angewendet werden. Zum Beispiel kann sich die physische Hardware am Knoten 1740 von 1720 unterscheiden und daher wird die Hardware-Abstraktionsschicht (HAL), die den unteren Rand des Containers bildet, erneut auf die physische Schicht des Ziel-Edge-Knotens abgebildet. Dies kann eine Form einer Spätbindungstechnik beinhalten, wie binäre Übersetzung der HAL von dem nativen Containerformat in das physische Hardwareformat, oder kann Abbildungsschnittstellen und - Operationen beinhalten. Eine Pod-Steuerung kann verwendet werden, um die Schnittstellenabbildung als Teil des Containerlebenszyklus zu lenken, was eine Migration zu/von verschiedenen Hardwareumgebungen beinhaltet.
Die von 17 umfassten Szenarien können verschiedene Arten von mobilen Edge-Knoten nutzen, wie etwa einen Edge-Knoten, der in einem Fahrzeug (Auto/Lastkraftwagen/Straßenbahn/Zug) gehostet ist, oder eine andere mobile Einheit, da sich der Edge-Knoten entlang der Plattform, die ihn hostet, zu anderen geografischen Orten bewegen wird. Bei Fahrzeug-zu-Fahrzeug-Kommunikationen können einzelne Fahrzeuge sogar als Netzwerk-Edge-Knoten für andere Autos fungieren (z.B. um Zwischenspeichern, Berichterstellung, Datenaggregation usw. durchzuführen). Somit versteht es sich, dass die Anwendungskomponenten, die in verschiedenen Edge-Knoten bereitgestellt sind, in statischen oder mobilen Szenarien verteilt sein können, einschließlich Koordination zwischen einigen Funktionen oder Operationen an einzelnen Endpunkteinrichtungen oder den Edge-Gateway-Knoten 1720, einigen anderen an dem Edge-Ressourcenknoten 1740 und anderen in dem Kernrechenzentrum 1750 oder der globalen Netzwerk-Cloud 1760.
In weiteren Konfigurationen kann das Edge-Computing-System FaaS-Rechenfähigkeiten durch die Verwendung jeweiliger ausführbarer Anwendungen und Funktionen implementieren. In einem Beispiel schreibt ein Entwickler Funktionscode (vorliegend z.B. „Computercode“), der eine oder mehrere Computerfunktionen repräsentiert, und der Funktionscode wird auf eine FaaS-Plattform hochgeladen, die zum Beispiel durch einen Edge-Knoten oder ein Rechenzentrum bereitgestellt wird. Ein Auslöser, wie beispielsweise ein Dienstanwendungsfall oder ein Edge-Verarbeitungsereignis, initiiert die Ausführung des Funktionscodes mit der FaaS-Plattform.
In einem Beispiel für FaaS wird ein Container verwendet, um eine Umgebung bereitzustellen, in der Funktionscode (z.B. eine Anwendung, die durch eine Drittpartei bereitgestellt werden kann) ausgeführt wird. Der Container kann eine beliebige Entität mit isolierter Ausführung sein, wie etwa ein Prozess, ein Docker- oder Kubernete-Container, eine virtuelle Maschine usw. Innerhalb des Edge-Rechensystems werden verschiedene Rechenzenten-, Edge- und Endpunkteinrichtungen (einschließlich Mobileinrichtungen) verwendet, um Funktionen „hochzufahren“ (z.B. Funktionsaktionen zu aktivieren und/oder zuzuweisen), die auf Abruf skaliert werden. Der Funktionscode wird auf der physischen Infrastruktureinrichtung (z.B. Edge-Rechenknoten) und darunterliegenden virtualisierten Containern ausgeführt. Schließlich wird der Container auf der Infrastruktur in Reaktion darauf, dass die Ausführung abgeschlossen ist, „heruntergefahren“ (z.B. deaktiviert und/oder freigegeben).
Weitere Aspekte von FaaS können Einsetzen von Edge-Funktionen als Dienst ermöglichen, einschließlich einer Unterstützung jeweiliger Funktionen, die Edge Computing als einen Dienst unterstützen (Edge-as-a-Service oder „EaaS“). Zusätzliche Merkmale von FaaS können beinhalten: eine granuläre Abrechnungskomponente, die Kunden (z. B. Computercodeentwicklern) ermöglicht, nur zu bezahlen, wenn ihr Code ausgeführt wird; gemeinsame Datenspeicherung zum Speichern von Daten zur Wiederverwendung durch eine oder mehrere Funktionen; Orchestrierung und Verwaltung zwischen einzelnen Funktionen; Funktionsausführungsverwaltung, Parallelität und Konsolidierung; Verwaltung von Container- und Funktionsspeicherplätzen; Koordination von Beschleunigungsressourcen, die für Funktionen verfügbar sind; und Verteilung von Funktionen zwischen Containern (einschließlich „warmer“ Container, die bereits eingesetzt oder betrieben werden, versus „kalter“ Container, die eine Initialisierung, Bereitstellung oder Konfiguration erfordern).
In weiteren Beispielen können beliebige der Rechenknoten oder Einrichtungen, die unter Bezugnahme auf die vorliegenden Edge-Rechensysteme und die vorliegende Umgebung erörtert wurden, basierend auf den Komponenten, die in 18A und 18B gezeigt sind, erfüllt werden. Jeweilige Edge-Rechenknoten können als ein Typ von Einrichtung, Gerät, Computer oder anderem „Ding“ umgesetzt sein, das bzw. der in der Lage ist, mit anderen Edge-, Netzwerk- oder Endpunktkomponenten zu kommunizieren. Zum Beispiel kann eine Edge-Recheneinrichtung als ein Smartphone, eine mobile Recheneinrichtung, ein Smartgerät, ein fahrzeuginternes Rechensystem (z.B. ein Navigationssystem), eine eigenständige Einrichtung mit einem Außengehäuse, einer Hülle usw. oder eine andere Einrichtung oder ein anderes System, die/das in der Lage ist, die beschriebenen Funktionen durchzuführen, umgesetzt sein.
In dem vereinfachten Beispiel, das in 18A dargestellt ist, umfasst ein Edge-Rechenknoten 1800 eine Rechen-Engine (vorliegend auch als „Rechenschaltungsanordnung“ bezeichnet) 1802, ein Eingabe/Ausgabe (E/A) -Teilsystem 1808, eine Datenspeicherung 1810, ein Kommunikationsschaltungsanordnungsteilsystem 1812 und wahlweise eine oder mehrere Peripherieeinrichtungen 1814. In anderen Beispielen können jeweilige Recheneinrichtungen andere oder zusätzliche Komponenten umfassen, wie diejenigen, die üblicherweise in einem Computer zu finden sind (z.B. eine Anzeige, periphere Einrichtungen usw.). Eine oder mehrere der illustrativen Komponenten können zusätzlich in einigen Beispielen in eine andere Komponente eingebunden sein oder anderweitig einen Teil dieser bilden.
Der Rechenknoten 1800 kann als eine beliebige Art von Engine, Einrichtung oder Sammlung von Einrichtungen umgesetzt sein, die in der Lage sind, verschiedene Rechenfunktionen durchzuführen. In einigen Beispielen kann der Rechenknoten 1800 als eine einzelne Einrichtung wie eine integrierte Schaltung, ein eingebettetes System, ein frei programmierbares Gate-Array (FPGA), ein Ein-Chip-System (SOC) oder ein anderes integriertes System oder eine andere integrierte Einrichtung ausgebildet sein. Im veranschaulichenden Beispiel weist der Rechenknoten 1800 einen Prozessor 1804 und einen Speicher 1806 auf oder ist als diese ausgebildet. Der Prozessor 1804 kann als ein beliebiger Typ von Prozessor ausgebildet sein, der die vorliegend beschriebenen Funktionen (z.B. Ausführen einer Anwendung) durchführen kann. Der Prozessor 1804 kann zum Beispiel als Mehrkernprozessor(en), Mikrocontroller oder anderer Prozessor oder Verarbeitungs-/Steuerschaltung umgesetzt sein. In einigen Beispielen kann der Prozessor 1804 als ein FPGA, eine anwendungsspezifische integrierte Schaltung (ASIC), eine neu konfigurierbare Hardware oder Hardwareschaltungsanordnung oder eine andere spezialisierte Hardware ausgebildet sein, diese enthalten oder an diese gekoppelt sein, um eine Durchführung der hierin beschriebenen Funktionen zu ermöglichen.
Der Hauptspeicher 1806 kann als eine beliebige Art flüchtiger (z.B. dynamischer Direktzugriffsspeicher (DRAM) usw.) oder nichtflüchtiger Speicher oder nichtflüchtiger Datenspeicher umgesetzt sein, der in der Lage ist, die vorliegend beschriebenen Funktionen durchzuführen. Flüchtiger Speicher kann ein Speichermedium sein, das Energie erfordert, um den Zustand von vom Medium gespeicherten Daten zu bewahren. Nicht einschränkende Beispiele von flüchtigem Speicher können verschiedene Arten von Direktzugriffsspeicher (RAM) wie DRAM oder statischen Direktzugriffsspeicher (SRAM) umfassen. Ein bestimmter Typ von DRAM, der in einem Speichermodul verwendet werden kann, ist synchroner dynamischer Direktzugriffsspeicher (SDRAM).
In einem Beispiel ist die Speichereinrichtung eine blockadressierbare Speichereinrichtung, wie etwa jene, die auf NAND- oder NOR-Technologien basieren. Eine Speichereinrichtung kann auch eine dreidimensionale Kreuzpunktspeichereinrichtung (z.B. Intel^®-3D-XPoint™-Speicher) oder andere byteadressierbare nichtflüchtige Speichereinrichtungen zum Schreiben an Ort und Stelle umfassen. Die Speichereinrichtung kann den Chip selbst und/oder ein verpacktes Speicherprodukt bezeichnen. In einigen Beispielen kann der 3D-Kreuzpunktspeicher (z.B. Intel®-3D-XPoint™-Speicher) eine transistorlose stapelbare Kreuzpunkt-Architektur umfassen, bei der Speicherzellen am Schnittpunkt von Wortleitungen und Bitleitungen sitzen und einzeln adressierbar sind und bei der die Bitspeicherung auf einer Änderung des Volumenwiderstands basiert. In einigen Beispielen kann der gesamte Hauptspeicher 1806 oder ein Teil davon in den Prozessor 1804 integriert sein. Der Hauptspeicher 1806 kann verschiedene Software und Daten speichern, die während des Betriebs verwendet werden, wie etwa eine oder mehrere Anwendungen, Daten, die durch die Anwendung(en) bearbeitet werden, Bibliotheken und Treiber.
Die Rechenschaltungsanordnung 1802 ist kommunikativ mit anderen Komponenten des Rechenknotens 1800 über das E/A-Teilsystem 1808 gekoppelt, das als Schaltungsanordnung und/oder Komponenten umgesetzt sein kann, um Eingabe/Ausgabe-Operationen mit der Rechenschaltungsanordnung 1802 (z. B. mit dem Prozessor 1804 und/oder dem Hauptspeicher 1806) und anderen Komponenten der Rechenschaltungsanordnung 1802 zu ermöglichen. Das E/A-Teilsystem 1808 kann beispielsweise als Arbeitsspeichersteuerungshubs, Eingabe/Ausgabe-Steuerungshubs, integrierte Sensorhubs, Firmwareeinrichtungen, Kommunikationsverbindungen (z. B. Punkt-zu-Punkt-Verknüpfungen, Busverbindungen, Drähte, Kabel, Lichtleiter, Bahnen auf gedruckten Leiterplatten usw.) und/oder andere Komponenten und Subsysteme ausgebildet sein oder diese anderweitig umfassen, um die Eingabe/Ausgabe-Operationen zu ermöglichen. In einigen Beispielen kann das E/A-Teilsystem 1808 einen Teil eines Ein-Chip-Systems (SoC) bilden und zusammen mit dem Prozessor 1804 und/oder dem Hauptspeicher 1806 und/oder anderen Komponenten der Rechenschaltungsanordnung 1802 in die Rechenschaltungsanordnung 1802 integriert sein.
Die eine oder die mehreren veranschaulichenden Datenspeicherungseinrichtungen 1810 können als eine beliebige Art von Einrichtungen umgesetzt sein, die zur Kurzzeit- oder Langzeitspeicherung von Daten konfiguriert sind, wie etwa zum Beispiel Speichereinrichtungen und Schaltungen, Speicherkarten, Festplattenlaufwerke, Festkörperlaufwerke oder andere Datenspeicherungseinrichtungen. Individuelle Datenspeicherungseinrichtungen 1810 können eine Systempartition beinhalten, die Daten und Firmwarecode für die Datenspeicherungseinrichtung 1810 speichert. Individuelle Datenspeicherungseinrichtungen 1810 können zudem eine oder mehrere Betriebssystempartitionen umfassen, die Dateien und ausführbare Dateien für Betriebssysteme in Abhängigkeit von zum Beispiel dem Typ des Rechenknotens 1800 speichern.
Die Kommunikationsschaltungsanordnung 1812 kann als eine beliebige Kommunikationsschaltung, -einrichtung oder -sammlung davon umgesetzt sein, die in der Lage ist, Kommunikationen über ein Netzwerk zwischen der Rechenschaltungsanordnung 1802 und einer anderen Recheneinrichtung (z. B. einem Edge-Gateway eines implementierenden Edge-Rechensystems) zu ermöglichen. Die Kommunikationsschaltungsanordnung 1812 kann ausgelegt sein, eine oder mehrere beliebige Kommunikationstechnologien (z. B. drahtgebundene oder drahtlose Kommunikationen) und assoziierte Protokolle (z. B. ein Mobilfunkvernetzungsprotokoll, wie etwa einen 3GPP-4G- oder 5G-Standard, ein drahtloses lokales Netzwerkprotokoll, wie etwa IEEE 802.11/Wi-Fi®, ein drahtloses Funkfernnetzprotokoll, Ethernet, Bluetooth®, Bluetooth Low Energy, ein IoT-Protokoll, wie etwa IEEE 802.15.4 oder ZigBee®, Niedrigenergieweitverkehrnetz(LPWAN)-oder Low-Power-Wide-Area(LPWA)-Protokolle usw.) zu verwenden, um eine derartige Kommunikation zu bewirken.
Die veranschaulichende Kommunikationsschaltungsanordnung 1812 beinhaltet eine Netzwerkschnittstellensteuerung (NIC) 1820, die auch als Host-Fabric-Schnittstelle (HFI) bezeichnet werden kann. Die NIC 1820 kann als eine oder mehrere Zusatzplatinen, untergeordnete Karten, Netzwerkschnittstellenkarten, Steuerchips, Chipsätze oder andere Einrichtungen ausgebildet sein, die vom Rechenknoten 1800 verwendet werden können, um an eine andere Recheneinrichtung (z.B. an einen Edge-Gateway-Knoten) anzubinden. In einigen Beispielen kann die NIC 1820 als Teil eines Ein-Chip-Systems (SoC) umgesetzt sein, das einen oder mehrere Prozessoren umfasst, oder auf einem Mehrchipgehäuse enthalten sein, das zudem einen oder mehrere Prozessoren umfasst. In einigen Beispielen kann die NIC 1820 einen lokalen Prozessor (nicht gezeigt) und/oder einen lokalen Speicher (nicht gezeigt) enthalten, die beide lokal zur NIC 1820 sind. In derartigen Beispielen kann der lokale Prozessor der NIC 1820 fähig sein, eine oder mehrere der Funktionen der vorliegend beschriebenen Rechenschaltungsanordnung 1802 durchzuführen. Zusätzlich oder alternativ kann der lokale Arbeitsspeicher der NIC 1820 in derartigen Beispielen in eine oder mehrere Komponenten des Client-Rechenknotens auf Platinenebene, Sockelebene, Chipebene und/oder anderen Ebenen integriert sein.
Zusätzlich kann in einigen Beispielen ein jeweiliger Rechenknoten 1800 eine oder mehrere Peripherieeinrichtungen 1814 umfassen. Derartige Peripherieeinrichtungen 1814 können eine beliebige Art von Peripherieeinrichtung umfassen, die in einer Recheneinrichtung oder einem Server gefunden wird, wie etwa Audioeingabeeinrichtungen, eine Anzeige, andere Eingabe/Ausgabeeinrichtungen, Schnittstelleneinrichtungen und/oder andere Peripherieeinrichtungen, in Abhängigkeit von der speziellen Art des Rechenknotens 1800. In weiteren Beispielen kann der Rechenknoten 1800 durch einen jeweiligen Edge-Rechenknoten (egal, ob ein Client, Gateway oder Aggregationsknoten) in einem Edge-Rechensystem oder ähnlichen Formen von Geräten, Computern, Subsystemen, Schaltungsanordnungen oder anderen Komponenten ausgebildet sein.
In einem ausführlicheren Beispiel veranschaulicht 18B ein Blockdiagramm eines Beispiels für Komponenten, die in einem Edge-Rechenknoten 1850 zum Implementieren der vorliegend beschriebenen Techniken (z.B. Operationen, Prozesse, Verfahren und Methodologien) vorhanden sein können. Dieser Edge-Rechenknoten 1850 stellt eine nähere Ansicht der jeweiligen Komponenten des Knotens 1800 bereit, wenn er als oder als Teil einer Recheneinrichtung (z. B. als eine Mobileinrichtung, eine Basisstation, ein Server, ein Gateway usw.) implementiert wird. Der Edge-Rechenknoten 1850 kann beliebige Kombinationen der hier referenzierten Hardware oder logischen Komponenten beinhalten und er kann eine beliebige Einrichtung umfassen oder an eine solche koppeln, die mit einem Edge-Kommunikationsnetzwerk oder einer Kombination derartiger Netzwerke verwendbar ist. Die Komponenten können als ICs, Teile davon, diskrete elektronische Einrichtungen oder andere Module, Befehlssätze, programmierbare Logik oder Algorithmen, Hardware, Hardwarebeschleuniger, Software, Firmware oder eine Kombination davon, die in dem Edge-Computing-Knoten 1850 angepasst sind, oder als Komponenten, die anderweitig in einem Chassis eines größeren Systems integriert sind, implementiert sein.
Die Edge-Computing-Einrichtung 1850 kann eine Verarbeitungsschaltungsanordnung in der Form eines Prozessors 1852 umfassen, der ein Mikroprozessor, ein Mehrkernprozessor, ein Multithreadprozessor, ein Ultraniederspannungsprozessor, ein eingebetteter Prozessor oder andere bekannte Verarbeitungselemente sein kann. Der Prozessor 1852 kann ein Teil eines Ein-Chip-Systems (SoC) sein, in dem der Prozessor 1852 und andere Komponenten in einer einzigen integrierten Schaltung oder einem einzigen Gehäuse gebildet sind, wie etwa die Edison™- oder Galileo™-SoC-Platinen von Intel Corporation, Santa Clara, Kalifornien. Als ein Beispiel kann der Prozessor 1852 einen auf Intel®-Architektur Core™ basierenden CPU-Prozessor, wie etwa einen Prozessor der Klasse Quark™, Atom™, i3, i5, i7, i9 oder MCU oder einen anderen derartigen Prozessor beinhalten, der von Intel® erhältlich ist. Eine beliebige Anzahl anderer Prozessoren kann jedoch verwendet werden, wie etwa von Advanced Micro Devices, Inc. (AMD®) in Sunnyvale, Kalifornien, erhältlich, ein MIPS®-basiertes Design der Firma MIPS Technologies, Inc. in Sunnyvale, Kalifornien, ein ARM®-basiertes Design, lizenziert von ARM Holdings, Ltd. oder einem Kunden davon, oder deren Lizenznehmern oder Anwendern. Die Prozessoren können Einheiten umfassen, wie etwa einen A5-A13-Prozessor von Apple® Inc., einen Snapdragon™-Prozessor von Snapdragon™ Technologies, Inc., oder einen OMAP™-Prozessor von Texas Instruments, Inc. Der Prozessor 1852 und die begleitende Schaltungsanordnung können in einem einzigen Sockelformfaktor, mehreren Sockelformfaktoren oder einer Vielfalt anderer Formate bereitgestellt sein, darunter in beschränkten Hardwarekonfigurationen oder Konfigurationen, die weniger als alle in 18 gezeigten Elemente umfassen.
Der Prozessor 1852 kann über eine Zwischenverbindung 1856 (z.B. einen Bus) mit einem Systemspeicher 1854 kommunizieren. Eine beliebige Anzahl an Speichereinrichtungen kann verwendet werden, um eine gegebene Menge an Systemspeicher bereitzustellen. Als Beispiele kann der Speicher Direktzugriffsspeicher (RAM) gemäß einem JEDEC- (Joint Electron Devices Engineering Council) Design sein, wie etwa den DDR- oder Mobil-DDR-Standards (z.B. LPDDR, LPDDR2, LPDDR3 oder LPDDR4). In bestimmten Beispielen kann eine Arbeitsspeicherkomponente einen von JEDEC veröffentlichten DRAM-Standard erfüllen, wie JESD79F für DDR-SDRAM, JESD79-2F für DDR2-SDRAM, JESD79-3F für DDR3-SDRAM, JESD79-4A für DDR4-SDRAM, JESD209 für Niedrigenergie-DDR (LPDDR), JESD209-2 für LPDDR2, JESD209-3 für LPDDR3 und JESD209-4 für LPDDR4. Derartige Standards (und ähnliche Standards) können als DDR-basierte Standards bezeichnet werden und Kommunikationsschnittstellen der Speicherungseinrichtungen, die derartige Standards implementieren, können als DDR-basierte Schnittstellen bezeichnet werden. In verschiedenen Implementierungen können die einzelnen Speichereinrichtungen aus einer beliebigen Anzahl von verschiedenen Gehäusetypen sein, wie ein Ein-Rohchip-Gehäuse (SDP), Doppel-Rohchip-Gehäuse (DDP) oder Quad-Rohchip-Gehäuse (Q17P). Diese Einrichtungen können in einigen Beispielen direkt auf eine Hauptplatine gelötet sein, um eine Lösung mit niedrigerem Profil zu bieten, während die Einrichtungen in anderen Beispielen als ein oder mehrere Speichermodule ausgelegt sind, die wiederum durch ein bestimmtes Verbindungsstück an die Hauptplatine koppeln. Eine beliebige Anzahl anderer Speicherimplementierungen kann verwendet werden, wie etwa andere Typen von Speichermodulen, z. B. Dual-Inline-Speichermodule (DIMMs) verschiedener Varianten, einschließlich unter anderem microDIMMs oder MiniDIMMs.
Um eine dauerhafte Speicherung von Informationen, wie etwa Daten, Anwendungen, Betriebssystemen und so weiter, bereitzustellen, kann ein Datenspeicher 1858 auch über die Zwischenverbindung 1856 mit dem Prozessor 1852 gekoppelt sein. Bei einem Beispiel kann die Speicherung 1858 über ein Festkörperplattenlaufwerk (SSDD) implementiert sein. Andere Einrichtungen, die für die Speicherung 1858 verwendet werden können, umfassen Flash-Speicherkarten, wie etwa SD-Karten, microSD-Karten, XD-Bildkarten und dergleichen, und USB-Flash-Laufwerke. In einem Beispiel kann die Speichereinrichtung Speichereinrichtungen sein oder solche enthalten, die Chalkogenglas, NAND-Flashspeicher mit mehreren Schwellenpegeln, NOR-Flashspeicher, Phasenwechselspeicher (PCM) mit einem oder mehreren Pegeln, einen resistiven Speicher, Nanodrahtspeicher, ferroelektrischen Transistorspeicher mit Direktzugriff (FeTRAM), antiferroelektrischen Speicher, magnetoresistiven Speicher mit Direktzugriff (MRAM), der Memristortechnologie einbindet, resistiven Speicher einschließlich Metalloxidbasis, Sauerstoffleerstellenbasis und Leiterbrückenarbeitsspeicher mit Direktzugriff (CB-RAM) oder Spin-Transfer-Torque(STT)-MRAM, eine Einrichtung auf Spintronik-Magnetübergang-Speicherbasis, eine Einrichtung auf Magnettunnelübergangsbasis (MTJ-Basis), eine Vorrichtung auf Domänenwand(DW)- und SOT(Spin-Orbit-Transfer)-Basis, eine Speichereinrichtung auf Thyristorbasis oder eine Kombination von beliebigen der obigen oder einen anderen Speicher einsetzen.
Bei Niedrigleistungsimplementierungen kann der Datenspeicher 1858 ein On-Die-Speicher oder Register sein, die dem Prozessor 1852 zugeordnet sind. In einigen Beispielen kann die Speicherung 1858 jedoch unter Verwendung eines Mikrofestplattenlaufwerks (HDD) implementiert sein. Ferner kann eine beliebige Anzahl neuer Technologien für die Speicherung 1858 zusätzlich zu oder anstelle der beschriebenen Technologien verwendet werden, wie unter anderem Widerstandsänderungsspeicher, Phasenwechselspeicher, holographische Speicher oder chemische Speicher.
Die Komponenten können über die Zwischenverbindung 1856 kommunizieren. Die Zwischenverbindung 1856 kann eine beliebige Anzahl von Technologien umfassen, darunter Industriestandardarchitektur (ISA), erweiterte ISA (EISA), Peripheral Component Interconnect (PCI), Peripheral Component Interconnect Extended (PCIx), PCI Express (PCIe) oder eine beliebige Anzahl anderer Technologien. Die Zwischenverbindung 1856 kann ein proprietärer Bus sein, der zum Beispiel in einem SoCbasierten System verwendet wird. Andere Bussysteme können enthalten sein, wie etwa unter anderem eine I2C-Schnittstelle, eine SPI-Schnittstelle, Punkt-zu-Punkt-Schnittstellen und ein Leistungsbus.
Die Zwischenverbindung 1856 kann den Prozessor 1852 mit einem Sendeempfänger 1866 zur Kommunikation mit den verbundenen Edge-Einrichtungen 1862 koppeln. Der Sendeempfänger 1866 kann eine beliebige Anzahl von Frequenzen und Protokollen verwenden, wie etwa unter anderem Übertragungen auf 2,4 Gigahertz (GHz) unter dem IEEE 802.15.4-Standard unter Verwendung des Bluetooth®-Niederenergie(BLE)-Standards, wie durch die Bluetooth® Special Interest Group definiert, oder des ZigBee®-Standards. Eine beliebige Anzahl von Funkgeräten, die für ein bestimmtes Drahtloskommunikationsprotokoll konfiguriert sind, kann für die Verbindungen mit den verbundenen Edge-Einrichtungen 1862 verwendet werden. Zum Beispiel kann eine Drahtlos-Lokalnetz- (WLAN-) Einheit verwendet werden, um Wi-Fi®-Kommunikationen gemäß dem 802.11-Standard des Institute of Electrical and Electronic Engineers (IEEE) zu implementieren. Außerdem können Funkfernnetzkommunikationen, z.B. in Übereinstimmung mit einem Mobilfunk- oder anderen Funkfernnetzprotokoll über eine Funkfernnetz- (WWAN-) Einheit stattfinden.
Der Drahtlosnetzwerk-Sendeempfänger 1866 (oder mehrere Sendeempfänger) kann unter Verwendung mehrerer Standards oder Funkgeräte für Kommunikationen in einer anderen Reichweite kommunizieren. Zum Beispiel kann der Edge-Rechenknoten 1850 mit nahen Einrichtungen, z.B. innerhalb von etwa 10 Metern, unter Verwendung eines lokalen Sendeempfängers basierend auf BLE oder eines anderen Niedrigleistungsfunkgeräts kommunizieren, um Leistung zu sparen. Entferntere verbundene Edge-Einrichtungen 1862, z.B. innerhalb von etwa 50 Metern, können über ZigBee® oder andere Funkgeräte mit mittlerer Leistung erreicht werden. Beide Kommunikationstechniken können über ein einziges Funkgerät mit unterschiedlichen Leistungspegeln erfolgen oder können über separate Sendeempfänger erfolgen, zum Beispiel einen lokalen Sendeempfänger, der BLE verwendet, und einen separaten vermaschten Sendeempfänger, der ZigBee® verwendet.
Ein Drahtlosnetzwerk-Sendeempfänger 1866 (z.B. ein Funksendeempfänger) kann enthalten sein, um mit Einrichtungen oder Diensten in der Edge-Cloud 1890 über Lokal- oder Weitverkehrsnetzprotokolle zu kommunizieren. Der Drahtlosnetzwerk-Sendeempfänger 1866 kann ein LPWA-Sendeempfänger sein, der unter anderem den Standards IEEE 802.15.4 oder IEEE 802.15.4g folgt. Der Edge-Rechenknoten 1850 kann über einen weiten Bereich unter Verwendung von LoRaWAN™ (Long Range Wide Area Network) kommunizieren, das von Semtech und der LoRa Alliance entwickelt wurde. Die vorliegend beschriebenen Techniken sind nicht auf diese Technologien beschränkt, sondern können mit einer beliebigen Anzahl von anderen Cloud-Sendeempfängern verwendet werden, die Kommunikationen mit großer Reichweite, niedriger Bandbreite implementieren, wie etwa Sigfox, und anderen Technologien. Ferner können andere Kommunikationstechniken verwendet werden, wie etwa Zeitschlitz-Kanalspringen, das in der IEEE 802.15.4e-Spezifikation beschrieben ist.
Eine beliebige Anzahl anderer Funkkommunikationen und Protokolle kann zusätzlich zu den für den Drahtlosnetzwerk-Sendeempfänger 1866 erwähnten Systemen verwendet werden, wie hier beschrieben. Der Sendeempfänger 1866 kann zum Beispiel einen Mobilfunk-Sendeempfänger beinhalten, der Frequenzspreiz (SPA/SAS-) Kommunikationen zum Implementieren von Hochgeschwindigkeitskommunikationen verwendet. Ferner kann eine beliebige Anzahl anderer Protokolle verwendet werden, wie etwa Wi-Fi®-Netzwerke für Mittelgeschwindigkeitskommunikationen und Bereitstellung von Netzwerkkommunikationen. Der Sendeempfänger 1866 kann Funkgeräte beinhalten, die mit einer beliebigen Anzahl von 3GPP-Spezifikationen (Third Generation Partnership Project) kompatibel sind, wie etwa Long-Term-Evolution(LTE)-Kommunikationssysteme und Kommunikationssysteme der 5. Generation (5G), die am Ende der vorliegenden Offenbarung ausführlicher besprochen werden. Eine Netzwerkschnittstellensteuerung (NIC) 1868 kann enthalten sein, um eine drahtgebundene Kommunikation zu Knoten der Edge-Cloud 1890 oder zu anderen Einrichtungen bereitzustellen, wie etwa den angebundenen Edge-Einrichtungen 1862 (die z.B. in einem vermaschten Netz arbeiten). Die drahtgebundene Kommunikation kann eine Ethernet-Verbindung bereitstellen oder kann auf anderen Arten von Netzwerken basieren, wie etwa Controller Area Network (CAN), Local Interconnect Network (LIN), DeviceNet, ControlNet, Data Highway+, PROFIBUS oder PROFINET unter vielen anderen. Eine zusätzliche NIC 1868 kann umfasst sein, um das Verbinden mit einem zweiten Netzwerk zu ermöglichen, wobei zum Beispiel eine erste NIC 1868 Kommunikationen mit der Cloud über Ethernet bereitstellt und eine zweite NIC 1868 Kommunikationen mit anderen Einrichtungen über einen anderen Typ von Netzwerk bereitstellt.
Angesichts der Vielfalt von Typen anwendbarer Kommunikationen von der Einrichtung zu einer anderen Komponente oder einem anderen Netzwerk kann eine anwendbare Kommunikationsschaltungsanordnung, die durch die Einrichtung verwendet wird, eine beliebige oder mehrere der Komponenten 1864, 1866, 1868 oder 1870 beinhalten oder durch diese umgesetzt sein. Dementsprechend können in verschiedenen Beispielen anwendbare Mittel zum Kommunizieren (z.B. Empfangen, Übertragen usw.) durch eine derartige Kommunikationsschaltungsanordnung ausgebildet sein.
Der Edge-Rechenknoten 1850 kann eine Beschleunigungsschaltungsanordnung 1864 umfassen oder mit dieser gekoppelt sein, die durch einen oder mehrere KI-Beschleuniger, einen neuronalen Rechenstick, neuromorphe Hardware, ein FPGA, eine Anordnung von GPUs, einem oder mehreren SoCs, einer oder mehreren CPUs, einem oder mehreren digitalen Signalprozessoren, dedizierten ASICs oder anderen Formen spezialisierter Prozessoren oder Schaltungsanordnungen, die dazu ausgelegt sind, eine oder mehrere spezialisierte Aufgaben zu erfüllen, umgesetzt sein kann. Diese Aufgaben können KI-Verarbeitung (einschließlich Maschinenlern-, Trainings-, Inferenz- und Klassifizierungsoperationen), visuelle Datenverarbeitung, Netzwerkdatenverarbeitung, Objekterkennung, Regelanalyse oder dergleichen umfassen.
Die Zwischenverbindung 1856 kann den Prozessor 1852 mit einem Sensor-Hub oder einer externen Schnittstelle 1870 koppeln, die zum Verbinden zusätzlicher Einrichtungen oder Teilsysteme verwendet wird. Die Einrichtungen können Sensoren 1872, wie etwa Beschleunigungsmesser, Pegelsensoren, Strömungssensoren, optische Lichtsensoren, Kamerasensoren, Temperatursensoren, Sensoren eines globalen Navigationssystems (z. B. GPS), Drucksensoren, barometrische Drucksensoren und dergleichen umfassen. Der Hub oder die Schnittstelle 1870 kann ferner verwendet werden, um den Edge-Rechenknoten 1850 mit Stellgliedern 1874, wie etwa Leistungsschaltern, Ventilstellgliedern, einem akustischen Tongenerator, einer visuellen Warnvorrichtung und dergleichen, zu verbinden.
In einigen optionalen Beispielen können verschiedene Eingabe/Ausgabe- (E/A-) Einrichtungen innerhalb des Edge-Rechenknotens 1850 vorhanden oder mit diesem verbunden sein. Beispielsweise kann eine Anzeige oder eine andere Ausgabeeinrichtung 1884 umfasst sein, um Informationen, wie etwa Sensorablesungen oder Stellgliedposition, zu zeigen. Eine Eingabeeinrichtung 1886, wie etwa ein Berührungsbildschirm oder eine Tastatur, kann umfasst sein, um eine Eingabe anzunehmen. Eine Ausgabeeinrichtung 1884 kann eine beliebige Anzahl von Formen akustischer oder optischer Anzeigen umfassen, einschließlich einfacher optischer Ausgaben, wie etwa binärer Statusindikatoren (z.B. LEDs) und optischer Mehrzeichenausgaben, oder komplexerer Ausgaben, wie etwa Anzeigebildschirme (z.B. LCD-Bildschirme), wobei die Ausgabe von Zeichen, Grafiken, Multimediaobjekten und dergleichen aus dem Betrieb des Edge-Rechenknotens 1850 erzeugt oder produziert wird. Eine Anzeige- oder Konsolenhardware kann im Kontext des vorliegenden Systems verwendet werden, um eine Ausgabe bereitzustellen und eine Eingabe eines Edge-Rechensystems zu empfangen; Komponenten oder Dienste eines Edge-Rechensystems zu verwalten; einen Zustand einer Edge-Rechenkomponente oder eines Edge-Dienstes zu identifizieren; oder eine beliebige andere Anzahl von Verwaltungs- oder Administrationsfunktionen oder Dienstanwendungsfällen durchzuführen.
Eine Batterie 1876 kann den Edge-Rechenknoten 1850 mit Strom versorgen, obwohl sie in Beispielen, in denen der Edge-Rechenknoten 1850 an einem festen Standort montiert ist, eine Stromversorgung aufweisen kann, die mit einem Stromnetz gekoppelt ist, oder die Batterie als Backup oder für temporäre Funktionen verwendet werden kann. Die Batterie 1876 kann eine Lithiumionenbatterie oder eine Metall-Luft-Batterie, wie etwa eine Zink-Luft-Batterie, eine Aluminium-Luft-Batterie, eine Lithium-Luft-Batterie und dergleichen, sein.
Eine Batterieüberwachungseinrichtung/Ladeeinrichtung 1878 kann in dem Edge-Rechenknoten 1850 umfasst sein, um den Ladezustand (SoCh) der Batterie 1876, falls enthalten, zu verfolgen. Die Batterieüberwachungseinrichtung/Ladeeinrichtung 1878 kann verwendet werden, um andere Parameter der Batterie 1876 zu überwachen, um Ausfallvorhersagen, wie etwa den Gesundheitszustand (SoH) und den Funktionszustand (SoF) der Batterie 1876 bereitzustellen. Die Batterieüberwachungs-/-ladeeinrichtung 1878 kann eine integrierte Batterieüberwachungsschaltung umfassen, wie etwa eine LTC4020 oder eine LTC2990 von Linear Technologies, eine ADT7488A von ON Semiconductor aus Phoenix, Arizona, oder eine IC der UCD90xxx-Familie von Texas Instruments aus Dallas, TX. Die Batterieüberwachungs-/-ladeeinrichtung 1878 kann die Informationen über die Batterie 1876 über die Zwischenverbindung 1856 an den Prozessor 1852 kommunizieren. Die Batterieüberwachungs-/-ladeeinrichtung 1878 kann zudem einen Analog-Digital-Wandler (ADC) umfassen, der es dem Prozessor 1852 ermöglicht, die Spannung der Batterie 1876 oder den Stromfluss von der Batterie 1876 direkt zu überwachen. Die Batterieparameter können verwendet werden, um Handlungen zu ermitteln, die der Edge-Rechenknoten 1850 durchführen kann, wie etwa Übertragungsfrequenz, vermaschten Netzbetrieb, Abtastfrequenz und dergleichen.
Ein Leistungsblock 1880 oder eine andere Leistungsversorgung, die mit einem Netz gekoppelt ist, kann mit der Batterieüberwachungs-/-ladeeinrichtung 1878 gekoppelt sein, um die Batterie 1876 zu laden. In einigen Beispielen kann der Leistungsblock 1880 durch einen Drahtlosleistungsempfänger ersetzt werden, um die Leistung drahtlos, zum Beispiel über eine Schleifenantenne im Edge-Rechenknoten 1850 zu beziehen. Eine Drahtlosbatterieladeschaltung, wie unter anderem ein LTC4020-Chip von Linear Technologies aus Milpitas, Kalifornien, kann in der Batterieüberwachungs-/-ladeeinrichtung 1878 umfasst sein. Die spezifischen Ladeschaltungen können basierend auf der Größe der Batterie 1876 und somit dem erforderlichen Strom ausgewählt werden. Das Laden kann unter anderem unter Verwendung des von der Airfuel Alliance veröffentlichten Standards Airfuel, des vom Wireless Power Consortium veröffentlichten Drahtlosladestandards Qi oder des von der Alliance for Wireless Power veröffentlichten Ladestandards Rezence durchgeführt werden.
Der Datenspeicher 1858 kann Anweisungen 1882 in Form von Software-, Firmware- oder Hardwarebefehlen zum Implementieren der vorliegend beschriebenen Techniken umfassen. Auch wenn derartige Anweisungen 1882 als Codeblöcke gezeigt sind, die in dem Speicher 1854 und der Speicherung 1858 enthalten sind, versteht es sich, dass beliebige der Codeblöcke durch festverdrahtete Schaltungen ersetzt werden können, die zum Beispiel in einer anwendungsspezifischen integrierten Schaltung (ASIC) eingebaut sind.
In einem Beispiel können die Anweisungen 1882, die über den Speicher 1854, die Speicherung 1858 oder den Prozessor 1852 bereitgestellt werden, als ein nicht transientes maschinenlesbares Medium 1860 umgesetzt sein, das Code umfasst, um den Prozessor 1852 anzuweisen, elektronische Operationen in dem Edge-Rechenknoten 1850 durchzuführen. Der Prozessor 1852 kann über die Zwischenverbindung 1856 auf das nicht transiente maschinenlesbare Medium 1860 zugreifen. Beispielsweise kann das nicht transiente maschinenlesbare Medium 1860 durch Einrichtungen ausgebildet sein, die für die Speicherung 1858 beschrieben sind, oder kann spezifische Speicherungseinheiten, wie etwa optische Platten, Flash-Laufwerke oder eine beliebige Anzahl anderer Hardwareeinrichtungen, umfassen. Das nicht transiente maschinenlesbare Medium 1860 kann Anweisungen umfassen, um den Prozessor 1852 anzuweisen, eine spezifische Sequenz oder einen spezifischen Fluss von Aktionen durchzuführen, wie zum Beispiel mit Bezug auf das Flussdiagramm bzw. die Flussdiagramme und das Blockdiagramm bzw. die Blockdiagramme von Operationen und Funktionalität, die oben dargestellt sind, beschrieben. Vorliegend sind die Ausdrücke „maschinenlesbares Medium“ und „computerlesbares Medium“ austauschbar.
In weiteren Beispielen umfasst ein maschinenlesbares Medium auch ein beliebiges greifbares Medium, das in der Lage ist, Anweisungen zur Ausführung durch eine Maschine zu speichern, zu codieren oder zu tragen, und die bewirken, dass die Maschine eins oder mehrere der Verfahren der vorliegenden Offenbarung durchführt, oder das in der Lage ist, Datenstrukturen zu speichern, zu codieren oder zu tragen, die durch solche Anweisungen genutzt werden oder mit diesen assoziiert sind. Ein „maschinenlesbares Medium“ kann dementsprechend unter anderem Festkörperspeicher und optische und magnetische Medien umfassen. Spezifische Beispiele maschinenlesbarer Medien umfassen nichtflüchtigen Speicher, darunter unter anderem beispielsweise Halbleiter-Speichereinrichtungen (z.B. elektrisch programmierbarer schreibgeschützter Speicher (EPROM), elektrisch löschbarer programmierbarer schreibgeschützter Speicher (EEPROM)) und Flashspeichereinrichtungen; Magnetplatten, wie z.B. interne Festplatten und Wechselplatten; magneto-optischen Platten; und CD-ROM- und DVD-ROM-Platten. Die durch ein maschinenlesbares Medium verkörperten Anweisungen können ferner über ein Kommunikationsnetzwerk unter Verwendung eines Übertragungsmediums über eine Netzwerkschnittstelleneinrichtung übertragen oder empfangen werden, die ein beliebiges einer Anzahl von Übertragungsprotokollen (z.B. HTTP) nutzt.
Ein maschinenlesbares Medium kann durch eine Speicherungseinrichtung oder eine andere Einrichtung bereitgestellt werden, die in der Lage ist, Daten in einem nicht transienten Format zu hosten. In einem Beispiel können Informationen, die auf einem maschinenlesbaren Medium gespeichert oder anderweitig bereitgestellt sind, Anweisungen repräsentieren, wie etwa Anweisungen selbst oder ein Format, aus dem die Anweisungen abgeleitet werden können. Dieses Format, aus dem die Anweisungen abgeleitet werden können, kann Quellcode, codierte Anweisungen (z.B. in komprimierter oder verschlüsselter Form), verpackte Anweisungen (z.B. in mehrere Pakete aufgeteilt) oder dergleichen umfassen. Die Informationen, die Anweisungen in dem maschinenlesbaren Medium repräsentieren, können durch eine Verarbeitungsschaltungsanordnung zu den Anweisungen verarbeitet werden, um beliebige der vorliegend behandelten Operationen zu implementieren. Zum Beispiel kann das Ableiten der Anweisungen aus den Informationen (z.B. Verarbeiten durch die Verarbeitungsschaltungsanordnung) Folgendes umfassen: Kompilieren (z.B. aus Quellcode, Objektcode usw.), Interpretieren, Laden, Organisieren (z.B. dynamisches oder statisches Linken), Codieren, Decodieren, Verschlüsseln, Entschlüsseln, Verpacken, Entpacken oder anderweitiges Manipulieren der Informationen in die Anweisungen.
In einem Beispiel kann das Ableiten der Anweisungen Assemblieren, Kompilieren oder Interpretieren der Informationen (z.B. durch die Verarbeitungsschaltungsanordnung) beinhalten, um die Anweisungen aus einem Zwischenformat oder einem vorverarbeiteten Format zu erzeugen, das durch das maschinenlesbare Medium bereitgestellt wird. Die Informationen können, wenn sie in mehreren Teilen bereitgestellt werden, kombiniert, entpackt und modifiziert werden, um die Anweisungen zu erzeugen. Die Informationen können sich zum Beispiel in mehreren komprimierten Quellcodepaketen (oder Objektcode oder ausführbarem Binär-Code usw.) auf einem oder mehreren entfernten Servern befinden. Die Quellcodepakete können verschlüsselt werden, wenn sie sich über ein Netzwerk bewegen, und entschlüsselt, entkomprimiert, bei Bedarf zusammengesetzt (z.B. gelinkt) und an einer lokalen Maschine kompiliert oder interpretiert (z.B. in eine Bibliothek, eigenständige ausführbare Datei usw.) und von der lokalen Maschine ausgeführt werden.
Aus dem Vorstehenden versteht es sich, dass beispielhafte Verfahren, Vorrichtungen und Erzeugnisse offenbart wurden, die Artefakte gewisser Modellierungsansätze reduzieren und wie solche Modelle eine Vorhersagegenauigkeit negativ beeinflussen können. Während traditionelle Ansätze zum Planen von Arbeitslasten auf ein ausgewähltes Modell (z.B. ein Modell, das nach Ermessen eines Analysten ausgewählt wird) angewiesen sind, wenden vorliegend offenbarte Beispiele Maschinenlernansätze an, um unterschiedliche Typen von Modellen und ihre entsprechende Fähigkeit, eine Ausgabe mit einem entsprechenden Genauigkeitsgrad vorherzusagen, zu bewerten. Diejenigen Modelle, die eine kombinatorische Verbesserung aufweisen, werden mit ihren entsprechenden Attributen beibehalten, um vorherzusagen, welche Ressourcen beansprucht werden und welche Ressourcen belegbar sind, wodurch Jobzuweisungen auf eine effizientere Weise ermöglicht werden. Infolgedessen wird die Einnahme von Clients erhöht, indem ermöglicht wird, dass Jobdienst-Zeitraumerwartungen mit weniger teuren Kapitalressourcen erfüllt werden, die zum Bereitstellen solcher Jobdienste benötigt werden.
Vorliegend offenbarte Beispiele verbessern zudem das Maschinenlerntraining von Modellen durch Erzeugen unterschiedlicher Datenmatrizen von Zielhardwareressourcen. Da vorliegend erzeugte beispielhafte gekennzeichnete Datenmatrizen unterschiedliche Kombinationen von Zielhardwaredetails umfassen, weisen insbesondere eine oder mehrere Maschinenlemtrainingsoperationen zusätzliche Eingabevariationen für den Lernprozess auf.
Vorliegend offenbarte Beispiele verbessern zudem eine jeweilige Modelleffizienz durch Entfernen einer oder mehrerer Schichten eines Modells, die nicht wesentlich zu Vorhersageversuchen beitragen. Insbesondere zeigen einige Schichten eines Modells nicht die gleiche Wahrscheinlichkeit einer Überhitzung wie andere Schichten dieses Modells. Somit tragen, falls eine oder mehrere Schichten dieses Modells eine Schwellenwahrscheinlichkeit der Aktivierung nicht erfüllen, diese speziellen Schichten zu Rechenineffizienzen bei, wenn Vorhersagen erzeugt werden. Dementsprechend entdecken vorliegend offenbarte Beispiele solche verschwenderischen Schichten und entfernen sie, wodurch eine Betriebs- und/oder anderweitige Recheneffizienz dieses Modells verbessert wird.
Wenngleich bestimmte beispielhafte Verfahren, Vorrichtungen und Erzeugnisse vorliegend offenbart wurden, ist der Schutzumfang der Abdeckung dieses Patents nicht hierauf eingeschränkt. Vielmehr deckt dieses Patent alle Verfahren, Vorrichtungen und Erzeugnisse ab, die innerhalb des Schutzumfangs der Ansprüche dieses Patents liegen.
Beispielhafte Verfahren, Vorrichtungen, Systeme und Erzeugnisse zum Verbessern von Jobplanungseffizienz sind vorliegend offenbart. Weitere Beispiele und Kombinationen umfassen Folgendes:
Beispiel 1 umfasst eine Vorrichtung zum Verbessern einer Jobressourcenplanungseffizienz, umfassend einen Merkmalgenerator zum Importieren von Standardwerten von Merkmalen, die einem ersten Modelltyp entsprechen, einen Kennzeichnungstrainer zum Trainieren von Kennzeichnungen, die dem ersten Modelltyp entsprechen, und einen Modellbewerter zum Bestimmen einer Genauigkeitsmetrik des ersten Modelltyps basierend auf einer ersten Vorhersage, die den Standardmerkmalen entspricht, und Aktualisieren der Merkmale von den Standardwerten auf aktualisierte Werte, wenn die Genauigkeitsmetrik einen Genauigkeitsschwellenwert nicht erfüllt.
Beispiel 2 umfasst die Vorrichtung nach Beispiel 1, wobei der Modellbewerter die Genauigkeitsmetrik des ersten Modelltyps durch Erhöhen eines Gradmerkmals des ersten Modelltyps erhöhen soll.
Beispiel 3 umfasst die Vorrichtung nach Beispiel 2, wobei der erste Modelltyp ein Polynom-Regressionsmodell ist.
Beispiel 4 umfasst die Vorrichtung nach Beispiel 1, wobei der Modellbewerter eine polynomiale Aktivierungsgewichtung einstellen soll, um eine proportionale Nutzung des ersten Modelltyps und eines zweiten Modelltyps zu bewirken, wenn Vorhersagen erzeugt werden.
Beispiel 5 umfasst die Vorrichtung nach Beispiel 4, wobei der Modellbewerter die polynomiale Aktivierungsgewichtung auf einen ersten Aktivierungswert einstellen soll, der den Standardwerten der Merkmale entspricht.
Beispiel 6 umfasst die Vorrichtung nach Beispiel 5, wobei der erste Aktivierungswert eine exklusive Nutzung des ersten Modelltyps und eine Verhinderung einer Nutzung des zweiten Modelltyps bewirkt.
Beispiel 7 umfasst die Vorrichtung nach Beispiel 4, die ferner einen Datenabrufer umfasst, um zu bestimmen, ob historische Daten verfügbar sind.
Beispiel 8 umfasst die Vorrichtung nach Beispiel 7, wobei die historischen Daten historischen Modelltrainingsdaten und/oder historischen Jobabbildungsdaten entsprechen.
Beispiel 9 umfasst die Vorrichtung nach Beispiel 1, ferner umfassend einen Modellersteller zum Berechnen einer Suffizienzmetrik historischer Daten, die früheren Jobzuteilungsinstanzen zu Ressourcen entsprechen.
Beispiel 10 umfasst die Vorrichtung nach Beispiel 9, wobei der Modellersteller eine polynomiale Aktivierungsgewichtung basierend auf der Suffizienzmetrik einstellen soll.
Beispiel 11 umfasst die Vorrichtung nach Beispiel 10, wobei die polynomiale Aktivierungsgewichtung bewirkt, dass der Modellbewerter den ersten Modelltyp und einen zweiten Modelltyp proportional nutzt, wenn Vorhersagen erzeugt werden.
Beispiel 12 umfasst die Vorrichtung nach Beispiel 11, wobei der zweite Modelltyp recheneffizienter als der erste Modelltyp ist.
Beispiel 13 umfasst die Vorrichtung nach Beispiel 10, wobei der Modellersteller die polynomiale Aktivierungsgewichtung einstellen soll, um einen zweiten Modelltyp mehr als den ersten Modelltyp zu nutzen, wenn eine proportionale Menge der historischen Daten zunimmt.
Beispiel 14 umfasst mindestens ein nicht transientes computerlesbares Medium, das Anweisungen umfasst, die bei Ausführung bewirken, dass mindestens ein Prozessor zumindest Standardwerte von Merkmalen, die einem ersten Modelltyp entsprechen, importiert, Kennzeichnungen trainiert, die dem ersten Modelltyp entsprechen, eine Genauigkeitsmetrik des ersten Modelltyps basierend auf einer ersten Vorhersage bestimmt, die den Standardmerkmalen entspricht, und die Merkmale von den Standardwerten auf aktualisierte Werte aktualisiert, wenn die Genauigkeitsmetrik einen Genauigkeitsschwellenwert nicht erfüllt.
Beispiel 15 umfasst das mindestens eine computerlesbare Medium nach Beispiel 14, wobei die Anweisungen bei Ausführung bewirken, dass der mindestens eine Prozessor die Genauigkeitsmetrik des ersten Modelltyps durch Erhöhen eines Gradmerkmals des ersten Modelltyps erhöht.
Beispiel 16 umfasst das mindestens eine computerlesbare Medium nach Beispiel 14, wobei die Anweisungen bei Ausführung bewirken, dass der mindestens eine Prozessor eine polynomiale Aktivierungsgewichtung einstellt, um eine proportionale Nutzung des ersten Modelltyps und eines zweiten Modelltyps zu bewirken, wenn Vorhersagen erzeugt werden.
Beispiel 17 umfasst das mindestens eine computerlesbare Medium nach Beispiel 16, wobei die Anweisungen bei Ausführung bewirken, dass der mindestens eine Prozessor die polynomiale Aktivierungsgewichtung auf einen ersten Aktivierungswert einstellt, der den Standardwerten der Merkmale entspricht.
Beispiel 18 umfasst das mindestens eine computerlesbare Medium nach Beispiel 17, wobei die Anweisungen bei Ausführung bewirken, dass der mindestens eine Prozessor ausschließlich den ersten Modelltyp nutzt und eine Nutzung des zweiten Modelltyps verhindert.
Beispiel 19 umfasst das mindestens eine computerlesbare Medium nach Beispiel 16, wobei die Anweisungen bei Ausführung bewirken, dass der mindestens eine Prozessor bestimmt, ob historische Daten verfügbar sind.
Beispiel 20 umfasst das mindestens eine computerlesbare Medium nach Beispiel 19, wobei die Anweisungen bei Ausführung bewirken, dass der mindestens eine Prozessor die historischen Daten als historische Modelltrainingsdaten und/oder historische Jobabbildungsdaten identifiziert.
Beispiel 21 umfasst das mindestens eine computerlesbare Medium nach Beispiel 14, wobei die Anweisungen bei Ausführung bewirken, dass der mindestens eine Prozessor eine Suffizienzmetrik historischer Daten berechnet, die früheren Jobzuteilungsinstanzen zu Ressourcen entsprechen.
Beispiel 22 umfasst das mindestens eine computerlesbare Medium nach Beispiel 21, wobei die Anweisungen bei Ausführung bewirken, dass der mindestens eine Prozessor eine polynomiale Aktivierungsgewichtung basierend auf der Suffizienzmetrik einstellt.
Beispiel 23 umfasst das mindestens eine computerlesbare Medium nach Beispiel 22, wobei die Anweisungen bei Ausführung bewirken, dass der mindestens eine Prozessor den ersten Modelltyp und einen zweiten Modelltyp proportional nutzt, wenn Vorhersagen erzeugt werden.
Beispiel 24 umfasst das mindestens eine computerlesbare Medium nach Beispiel 22, wobei die Anweisungen bei Ausführung bewirken, dass der mindestens eine Prozessor die polynomiale Aktivierungsgewichtung einstellt, um einen zweiten Modelltyp mehr als den ersten Modelltyp zu nutzen, wenn eine proportionale Menge der historischen Daten zunimmt.
Beispiel 25 umfasst eine Vorrichtung zum Verbessern einer Jobressourcenplanungseffizienz, umfassend Mittel zum Erzeugen von Merkmalen zum Importieren von Standardwerten von Merkmalen, die einem ersten Modelltyp entsprechen, Mittel zum Trainieren von Kennzeichnungen, um Kennzeichnungen zu trainieren, die dem ersten Modelltyp entsprechen, und Mittel zum Bewerten von Modellen zum Bestimmen einer Genauigkeitsmetrik des ersten Modelltyps basierend auf einer ersten Vorhersage, die den Standardmerkmalen entspricht, und Aktualisieren der Merkmale von den Standardwerten auf aktualisierte Werte, wenn die Genauigkeitsmetrik einen Genauigkeitsschwellenwert nicht erfüllt.
Beispiel 26 umfasst die Vorrichtung nach Beispiel 25, wobei das Modellbewertungsmittel die Genauigkeitsmetrik des ersten Modelltyps durch Erhöhen eines Gradmerkmals des ersten Modelltyps erhöhen soll.
Beispiel 27 umfasst die Vorrichtung nach Beispiel 26, wobei der erste Modelltyp ein Polynom-Regressionsmodell ist.
Beispiel 28 umfasst die Vorrichtung nach Beispiel 25, wobei das Modellbewertungsmittel eine polynomiale Aktivierungsgewichtung festlegen soll, um eine proportionale Nutzung des ersten Modelltyps und eines zweiten Modelltyps zu bewirken, wenn Vorhersagen erzeugt werden.
Beispiel 29 umfasst die Vorrichtung nach Beispiel 28, wobei das Modellbewertungsmittel die polynomiale Aktivierungsgewichtung auf einen ersten Aktivierungswert einstellen soll, der den Standardwerten der Merkmale entspricht.
Beispiel 30 umfasst die Vorrichtung nach Beispiel 29, wobei der erste Aktivierungswert eine exklusive Nutzung des ersten Modelltyps und eine Verhinderung einer Nutzung des zweiten Modelltyps bewirkt.
Beispiel 31 umfasst die Vorrichtung nach Beispiel 28, ferner umfassend Mittel zum Abrufen von Daten, um zu bestimmen, ob historische Daten verfügbar sind.
Beispiel 32 umfasst die Vorrichtung nach Beispiel 31, wobei die historischen Daten historischen Modelltrainingsdaten und/oder historischen Jobabbildungsdaten entsprechen.
Beispiel 33 umfasst die Vorrichtung nach Beispiel 25, ferner umfassend Mittel zum Erstellen von Modellen zum Berechnen einer Suffizienzmetrik historischer Daten, die früheren Jobzuteilungsinstanzen zu Ressourcen entsprechen.
Beispiel 34 umfasst die Vorrichtung nach Beispiel 33, wobei das Modellerstellungsmittel eine polynomiale Aktivierungsgewichtung basierend auf der Suffizienzmetrik einstellen soll.
Beispiel 35 umfasst die Vorrichtung nach Beispiel 34, wobei das Modellbewertungsmittel den ersten Modelltyp und einen zweiten Modelltyp basierend auf der polynomialen Aktivierungsgewichtung proportional nutzen soll, wenn Vorhersagen erzeugt werden.
Beispiel 36 umfasst die Vorrichtung nach Beispiel 35, wobei der zweite Modelltyp recheneffizienter als der erste Modelltyp ist.
Beispiel 37 umfasst die Vorrichtung nach Beispiel 34, wobei das Modellerstellungsmittel die polynomiale Aktivierungsgewichtung einstellen soll, um einen zweiten Modelltyp mehr als den ersten Modelltyp zu nutzen, wenn eine proportionale Menge der historischen Daten zunimmt.
Beispiel 38 umfasst ein computerimplementiertes Verfahren zum Verbessern einer Jobressourcenplanungseffizienz, umfassend durch Ausführen einer Anweisung mit mindestens einem Prozessor erfolgendes Importieren von Standardwerten von Merkmalen, die einem ersten Modelltyp entsprechen, durch Ausführen einer Anweisung mit dem mindestens einen Prozessor erfolgendes Trainieren von Kennzeichnungen, die dem ersten Modelltyp entsprechen, durch Ausführen einer Anweisung mit dem mindestens einen Prozessor erfolgendes Bestimmen einer Genauigkeitsmetrik des ersten Modelltyps basierend auf einer ersten Vorhersage, die den Standardmerkmalen entspricht, und durch Ausführen einer Anweisung mit dem mindestens einen Prozessor erfolgendes Aktualisieren der Merkmale von den Standardwerten auf aktualisierte Werte, wenn die Genauigkeitsmetrik einen Genauigkeitsschwellenwert nicht erfüllt.
Beispiel 39 umfasst das Verfahren nach Beispiel 38, ferner umfassend Erhöhen der Genauigkeitsmetrik des ersten Modelltyps durch Erhöhen eines Gradmerkmals des ersten Modelltyps.
Beispiel 40 umfasst das Verfahren nach Beispiel 38, ferner umfassend Einstellen einer polynomialen Aktivierungsgewichtung, um eine proportionale Nutzung des ersten Modelltyps und eines zweiten Modelltyps zu bewirken, wenn Vorhersagen erzeugt werden.
Beispiel 41 umfasst das Verfahren nach Beispiel 40, ferner umfassend Einstellen der polynomialen Aktivierungsgewichtung auf einen ersten Aktivierungswert, der den Standardwerten der Merkmale entspricht.
Beispiel 42 umfasst das Verfahren nach Beispiel 41, ferner umfassend exklusives Nutzen des ersten Modelltyps und Verhindern einer Nutzung des zweiten Modelltyps.
Beispiel 43 umfasst das Verfahren nach Beispiel 40, ferner umfassend Bestimmen, ob historische Daten verfügbar sind.
Beispiel 44 umfasst das Verfahren nach Beispiel 43, ferner umfassend Identifizieren der historischen Daten als historische Modelltrainingsdaten und/oder historische Jobabbildungsdaten.
Beispiel 45 umfasst das Verfahren nach Beispiel 38, ferner umfassend Berechnen einer Suffizienzmetrik historischer Daten, die vorherigen Jobzuteilungsinstanzen zu Ressourcen entsprechen.
Beispiel 46 umfasst das Verfahren nach Beispiel 45, ferner umfassend Einstellen einer polynomialen Aktivierungsgewichtung basierend auf der Suffizienzmetrik.
Beispiel 47 umfasst das Verfahren nach Beispiel 46, ferner umfassend proportionales Nutzen des ersten Modelltyps und eines zweiten Modelltyps, wenn Vorhersagen erzeugt werden.
Beispiel 48 umfasst das Verfahren nach Beispiel 46, ferner umfassend Einstellen der polynomialen Aktivierungsgewichtung, um einen zweiten Modelltyp mehr als den ersten Modelltyp zu nutzen, wenn eine proportionale Menge der historischen Daten zunimmt.
Beispiel 49 umfasst eine Vorrichtung zum Erzeugen gekennzeichneter Trainingsdaten für ein Jobplanungssystem, umfassend einen Modellbewerter zum Importieren eines ersten Satzes von Attributen, die Rechenressourcen des Jobplanungssystems entsprechen, Bestimmen, ob der erste Satz von Attributen zuvor zum Trainieren eines Modells von Interesse verwendet wurde, und in Reaktion auf das Bestimmen, dass der erste Satz von Attributen nicht zum Trainieren des Modells von Interesse verwendet wurde, Trainieren des Modells von Interesse basierend auf einem Trainingsschwellenwert.
Beispiel 50 umfasst die Vorrichtung nach Beispiel 49, wobei der Trainingsschwellenwert eine Schwellenanzahl von Trainingsiterationen des Modells von Interesse und/oder eine Schwellenzeitdauer beim Trainieren des Modells von Interesse und/oder eine Schwellenanzahl von Trainingsepochen umfasst.
Beispiel 51 umfasst die Vorrichtung nach Beispiel 49, wobei der erste Satz von Attributen zumindest eine Anzahl von Platinen, die einen ersten Jobtyp ausführen, und/oder eine Anzahl von Jobs, die aktuell ausgeführt werden, und/oder eine Anzahl wartender Jobs umfasst.
Beispiel 52 umfasst die Vorrichtung nach Beispiel 49, wobei der Modellbewerter in Reaktion auf Bestimmen, dass der erste Satz von Attributen zum Trainieren des Modells von Interesse verwendet wurde, einen zweiten Satz von Attributen auswählen soll, wobei sich der erste Satz von Attributen von dem zweiten Satz von Attributen unterscheidet.
Beispiel 53 umfasst die Vorrichtung nach Beispiel 49, ferner umfassend einen Architekturanalysierer zum Bestimmen des ersten Satzes von Attributen durch Analysieren kommunikativ verbundener Hardwareressourcen des Planungssystems.
Beispiel 54 umfasst die Vorrichtung nach Beispiel 53, wobei der Architekturanalysierer eine Anzahl von Servern der verbundenen Hardwareressourcen und/oder eine Anzahl von Einheiten innerhalb der Anzahl von Servern und/oder eine Anzahl von Platinen innerhalb der Anzahl von Einheiten bestimmen soll.
Beispiel 55 umfasst die Vorrichtung nach Beispiel 49, ferner umfassend einen Matrixgenerator zum Kennzeichnen jeweiliger des ersten Satzes von Attributen basierend auf einem Verwendungsstatus oder einem Sperrstatus.
Beispiel 56 umfasst die Vorrichtung nach Beispiel 55, wobei der Matrixgenerator eine Matrix gekennzeichneter Statusindikatoren erzeugen soll, die den Hardwareressourcen entsprechen.
Beispiel 57 umfasst mindestens ein nicht transientes computerlesbares Medium, das Anweisungen umfasst, die bei Ausführung bewirken, dass mindestens ein Prozessor zumindest einen ersten Satz von Attributen, die Rechenressourcen des Jobplanungssystems entsprechen, importiert, bestimmt, ob der erste Satz von Attributen zuvor zum Trainieren eines Modells von Interesse verwendet wurde, und in Reaktion auf das Bestimmen, dass der erste Satz von Attributen nicht zum Trainieren des Modells von Interesse verwendet wurde, das Modell von Interesse basierend auf einem Trainingsschwellenwert trainiert.
Beispiel 58 umfasst das mindestens eine computerlesbare Medium nach Beispiel 57, wobei die Anweisungen bei Ausführung bewirken, dass der mindestens eine Prozessor den Trainingsschwellenwert als eine Schwellenanzahl von Trainingsiterationen des Modells von Interesse und/oder eine Schwellenzeitdauer beim Trainieren des Modells von Interesse und/oder eine Schwellenanzahl von Trainingsepochen identifiziert.
Beispiel 59 umfasst das mindestens eine computerlesbare Medium nach Beispiel 57, wobei die Anweisungen bei Ausführug bewirken, dass der mindestens eine Prozessor den ersten Satz von Attributen als eine Anzahl von Platinen, die einen ersten Jobtyp ausführen, und/oder eine Anzahl von Jobs, die aktuell ausgeführt werden, und/oder eine Anzahl wartender Jobs identifiziert.
Beispiel 60 umfasst das mindestens eine computerlesbare Medium nach Beispiel 57, wobei die Anweisungen bei Ausführung bewirken, dass der mindestens eine Prozessor in Reaktion auf Bestimmen, dass der erste Satz von Attributen zum Trainieren des Modells von Interesse verwendet wurde, einen zweiten Satz von Attributen auswählt, wobei sich der erste Satz von Attributen von dem zweiten Satz von Attributen unterscheidet.
Beispiel 61 umfasst das mindestens eine computerlesbare Medium nach Beispiel 57, wobei die Anweisungen bei Ausführung bewirken, dass der mindestens eine Prozessor den ersten Satz von Attributen durch Analysieren kommunikativ verbundener Hardwareressourcen des Planungssystems bestimmt.
Beispiel 62 umfasst das mindestens eine computerlesbare Medium nach Beispiel 61, wobei die Anweisungen bei Ausführung bewirken, dass der mindestens eine Prozessor eine Anzahl von Servern der verbundenen Hardwareressourcen und/oder eine Anzahl von Einheiten innerhalb der Anzahl von Servern und/oder eine Anzahl von Platinen innerhalb der Anzahl von Einheiten bestimmt.
Beispiel 63 umfasst das mindestens eine computerlesbare Medium nach Beispiel 57, wobei die Anweisungen bei Ausführung bewirken, dass der mindestens eine Prozessor jeweilige des ersten Satzes von Attributen basierend auf einem Verwendungsstatus oder einem Sperrstatus kennzeichnet.
Beispiel 64 umfasst das mindestens eine computerlesbare Medium nach Beispiel 63, wobei die Anweisungen bei Ausführung bewirken, dass der mindestens eine Prozessor eine Matrix gekennzeichneter Statusindikatoren erzeugt, die den Hardwareressourcen entsprechen.
Beispiel 65 umfasst eine Vorrichtung zum Erzeugen gekennzeichneter Trainingsdaten für ein Jobplanungssystem, umfassend Mittel zum Analysieren einer Architektur zum Bestimmen eines ersten Satzes von Attributen durch Analysieren kommunikativ verbundener Hardwareressourcen des Jobplanungssystems, und Mittel zum Modellbewerten, um den ersten Satz von Attributen, die den Hardwareressourcen des Jobplanungssystems entsprechen, zu importieren, zu bestimmen, ob der erste Satz von Attributen zuvor zum Trainieren eines Modells von Interesse verwendet wurde, und in Reaktion auf das Bestimmen, dass der erste Satz von Attributen nicht zum Trainieren des Modells von Interesse verwendet wurde, das Modell von Interesse basierend auf einem Trainingsschwellenwert zu trainieren.
Beispiel 66 umfasst die Vorrichtung nach Beispiel 65, wobei der Trainingsschwellenwert eine Schwellenanzahl von Trainingsiterationen des Modells von Interesse und/oder eine Schwellenzeitdauer beim Trainieren des Modells von Interesse und/oder eine Schwellenanzahl von Trainingsepochen umfasst.
Beispiel 67 umfasst die Vorrichtung nach Beispiel 65, wobei der erste Satz von Attributen zumindest eine Anzahl von Platinen, die einen ersten Jobtyp ausführen, und/oder eine Anzahl von Jobs, die aktuell ausgeführt werden, und/oder eine Anzahl wartender Jobs umfasst.
Beispiel 68 umfasst die Vorrichtung nach Beispiel 65, wobei das Modellbewertungsmittel in Reaktion auf das Bestimmen, dass der erste Satz von Attributen zum Trainieren des Modells von Interesse verwendet wurde, einen zweiten Satz von Attributen auswählen soll, wobei sich der erste Satz von Attributen von dem zweiten Satz von Attributen unterscheidet.
Beispiel 69 umfasst die Vorrichtung nach Beispiel 65, wobei das Architekturanalysemittel eine Anzahl von Servern der verbundenen Hardwareressourcen und/oder eine Anzahl von Einheiten innerhalb der Anzahl von Servern und/oder eine Anzahl von Platinen innerhalb der Anzahl von Einheiten bestimmen soll.
Beispiel 70 umfasst die Vorrichtung nach Beispiel 65, ferner umfassend Mittel zum Matrixerzeugen, um jeweilige des ersten Satzes von Attributen basierend auf einem Verwendungsstatus oder einem Sperrstatus zu kennzeichnen.
Beispiel 71 umfasst die Vorrichtung nach Beispiel 70, wobei das Matrixerzeugungsmittel eine Matrix gekennzeichneter Statusindikatoren erzeugen soll, die den Hardwareressourcen entsprechen.
Beispiel 72 umfasst ein Verfahren zum Erzeugen gekennzeichneter Trainingsdaten für ein Jobplanungssystem, umfassend durch Ausführen einer Anweisung mit mindestens einem Prozessor erfolgendes Importieren eines ersten Satzes von Attributen, die Rechenressourcen des Jobplanungssystems entsprechen, durch Ausführen einer Anweisung mit dem mindestens einen Prozessor erfolgendes Bestimmen, ob der erste Satz von Attributen zuvor zum Trainieren eines Modells von Interesse verwendet wurde, und in Reaktion auf das Bestimmen, dass der erste Satz von Attributen nicht zum Trainieren des Modells von Interesse verwendet wurde, durch Ausführen einer Anweisung mit dem mindestens einen Prozessor erfolgendes Trainieren des Modells von Interesse basierend auf einem Trainingsschwellenwert.
Beispiel 73 umfasst das Verfahren nach Beispiel 72, ferner umfassend Identifizieren des Trainingsschwellenwerts als eine Schwellenanzahl von Trainingsiterationen des Modells von Interesse und/oder eine Schwellenzeitdauer beim Trainieren des Modells von Interesse und/oder eine Schwellenanzahl von Trainingsepochen.
Beispiel 74 umfasst das Verfahren nach Beispiel 72, ferner umfassend Identifizieren des ersten Satzes von Attributen als eine Anzahl von Platinen, die einen ersten Jobtyp ausführen, und/oder eine Anzahl von Jobs, die aktuell ausgeführt werden, und/oder eine Anzahl wartender Jobs.
Beispiel 75 umfasst das Verfahren nach Beispiel 72, ferner umfassend Auswählen eines zweiten Satzes von Attributen in Reaktion auf Bestimmen, dass der erste Satz von Attributen zum Trainieren des Modells von Interesse verwendet wurde, wobei sich der erste Satz von Attributen von dem zweiten Satz von Attributen unterscheidet.
Beispiel 76 umfasst das Verfahren nach Beispiel 72, ferner umfassend Bestimmen des ersten Satzes von Attributen durch Analysieren kommunikativ verbundener Hardwareressourcen des Planungssystems.
Beispiel 77 umfasst das Verfahren nach Beispiel 76, ferner umfassend Bestimmen einer Anzahl von Servern der verbundenen Hardwareressourcen und/oder einer Anzahl von Einheiten innerhalb der Anzahl von Servern und/oder einer Anzahl von Platinen innerhalb der Anzahl von Einheiten.
Beispiel 78 umfasst das Verfahren nach Beispiel 72, ferner umfassend Kennzeichnen jeweiliger des ersten Satzes von Attributen basierend auf einem Verwendungsstatus oder einem Sperrstatus.
Beispiel 79 umfasst das Verfahren nach Beispiel 78, ferner umfassend Erzeugen einer Matrix gekennzeichneter Statusindikatoren, die den Hardwareressourcen entsprechen.
Beispiel 80 umfasst eine Vorrichtung zum Verbessern einer Modelleffizienz, umfassend einen Modellzustandsbeurteiler zum Auswählen eines Modells von Interesse, Auswählen einer Schicht innerhalb des Modells von Interesse, Berechnen eines Wahrscheinlichkeitswerts, der der Schicht entspricht, Vergleichen des Wahrscheinlichkeitswerts mit einem Aussonderungsschwellenwert und Verbessern einer Effizienz des Modells durch Entfernen der Schicht aus dem Modell, wenn der Wahrscheinlichkeitswert den Aussonderungsschwellenwert erfüllt.
Beispiel 81 umfasst die Vorrichtung nach Beispiel 80, wobei der Modellzustandsbeurteiler die Schicht beibehalten soll, wenn der Wahrscheinlichkeitswert den Aussonderungsschwellenwert nicht erfüllt.
Beispiel 82 umfasst die Vorrichtung nach Beispiel 80, wobei der Modellzustandsbeurteiler eine zweite Schicht zur Bewertung auswählen soll, nachdem der Schichtwahrscheinlichkeitswert berechnet wurde.
Beispiel 83 umfasst die Vorrichtung nach Beispiel 80, wobei das Modell ein LSTM- (Long Short Term Memory) Modell umfasst.
Beispiel 84 umfasst ein nicht transientes computerlesbares Medium, das Anweisungen umfasst, die bei Ausführung bewirken, dass mindestens ein Prozessor zumindest ein Modell von Interesse auswählt, eine Schicht innerhalb des Modells von Interesse auswählt, einen Wahrscheinlichkeitswert berechnet, der der Schicht entspricht, den Wahrscheinlichkeitswert mit einem Aussonderungsschwellenwert vergleicht und eine Effizienz des Modells durch Entfernen der Schicht aus dem Modell verbessert, wenn der Wahrscheinlichkeitswert den Aussonderungsschwellenwert erfüllt.
Beispiel 85 umfasst das computerlesbare Medium nach Beispiel 84, wobei die Anweisungen bei Ausführung bewirken, dass der mindestens eine Prozessor die Schicht beibehält, wenn der Wahrscheinlichkeitswert den Aussonderungsschwellenwert nicht erfüllt.
Beispiel 86 umfasst das computerlesbare Medium nach Beispiel 84, wobei die Anweisungen bei Ausführung bewirken, dass der mindestens eine Prozessor eine zweite Schicht zur Bewertung auswählt, nachdem der Schichtwahrscheinlichkeitswert berechnet wurde.
Beispiel 87 umfasst das computerlesbare Medium nach Beispiel 84, wobei die Anweisungen bei Ausführung bewirken, dass der mindestens eine Prozessor das Modell als ein LSTM- (Long Short Term Memory) Modell implementiert.
Beispiel 88 umfasst eine Vorrichtung zum Verbessern von Modelleffizienz, umfassend Mittel zum Abrufen, um Daten abzurufen, die verfügbaren Modellen entsprechen, und Mittel zum Modellzustandsbeurteilen zum Auswählen eines Modells von Interesse, Auswählen einer Schicht innerhalb des Modells von Interesse, Berechnen eines Wahrscheinlichkeitswerts, der der Schicht entspricht, Vergleichen des Wahrscheinlichkeitswerts mit einem Aussonderungsschwellenwert und Verbessern einer Effizienz des Modells durch Entfernen der Schicht aus dem Modell, wenn der Wahrscheinlichkeitswert den Aussonderungsschwellenwert erfüllt.
Beispiel 89 umfasst die Vorrichtung nach Beispiel 88, wobei das Modellzustandsbeurteilungsmittel die Schicht beibehalten soll, wenn der Wahrscheinlichkeitswert den Aussonderungsschwellenwert nicht erfüllt.
Beispiel 90 umfasst die Vorrichtung nach Beispiel 88, wobei das Modellzustandsbeurteilungsmittel eine zweite Schicht zur Bewertung auswählen soll, nachdem der Schichtwahrscheinlichkeitswert berechnet wurde.
Beispiel 91 umfasst die Vorrichtung nach Beispiel 88, wobei das Modellzustandsbeurteilungsmittel das Modell als ein LSTM- (Long Short Term Memory) Modell implementieren soll.
Beispiel 92 umfasst ein Verfahren zum Verbessern von Modelleffizienz, umfassend durch Ausführen einer Anweisung mit mindestens einem Prozessor erfolgendes Auswählen eines Modells von Interesse, durch Ausführen einer Anweisung mit dem mindestens einen Prozessor erfolgendes Auswählen einer Schicht innerhalb des Modells von Interesse, durch Ausführen einer Anweisung mit dem mindestens einen Prozessor erfolgendes Berechnen eines Wahrscheinlichkeitswerts, der der Schicht entspricht, durch Ausführen einer Anweisung mit dem mindestens einen Prozessor erfolgendes Vergleichen des Wahrscheinlichkeitswerts mit einem Aussonderungsschwellenwert und durch Ausführen einer Anweisung mit dem mindestens einen Prozessor erfolgendes Verbessern einer Effizienz des Modells durch Entfernen der Schicht aus dem Modell, wenn der Wahrscheinlichkeitswert den Aussonderungsschwellenwert erfüllt.
Beispiel 93 umfasst das Verfahren nach Beispiel 92, ferner umfassend Beibehalten der Schicht, wenn der Wahrscheinlichkeitswert den Aussonderungsschwellenwert nicht erfüllt.
Beispiel 94 umfasst das Verfahren nach Beispiel 92, ferner umfassend Auswählen einer zweiten Schicht zur Bewertung, nachdem der Schichtwahrscheinlichkeitswert berechnet wurde.
Beispiel 95 umfasst das Verfahren nach Beispiel 92, ferner umfassend Implementieren des Modells als LSTM- (Long Short Term Memory) Modell.
Beispiel 96 ist ein computerlesbares Medium, das Anweisungen zum Durchführen eines der Beispiele 38-48 umfasst.
Beispiel 97 ist ein computerlesbares Medium, das Anweisungen zum Durchführen eines der Beispiele 72-79 umfasst.
Beispiel 98 ist ein computerlesbares Medium, das Anweisungen zum Durchführen eines der Beispiele 92-95 umfasst.
Beispiel 99 ist ein Edge-Computing-Gateway, das eine Verarbeitungsschaltungsanordnung zum Durchführen eines der Beispiele 38-48 umfasst.
Beispiel 100 ist ein Edge-Computing-Gateway, das eine Verarbeitungsschaltungsanordnung zum Durchführen eines der Beispiele 72-79 umfasst.
Beispiel 101 ist ein Edge-Computing-Gateway, das eine Verarbeitungsschaltungsanordnung zum Durchführen eines der Beispiele 92-95 umfasst.
Beispiel 102 umfasst eines der Beispiele 1-13, wobei Jobanfragen Metadaten umfassen, die Jobprioritätsinformationen und/oder Jobtypinformationen und/oder Hardwareanforderungsinformationen entsprechen.
Beispiel 103 umfasst eines der Beispiele 1-13, ferner umfassend Zuweisen einer Jobanfrage zu mindestens einer Ressource basierend auf einem Smallest-Best-Fit-Optimierungsalgorithmus und/oder einem Largest-Best-Fit-Optimierungsalgorithmus und/oder einem Knapsack-Optimierungsalgorithmus.
In Beispiel 104 umfasst der Gegenstand eines der Beispiele 1-13 wahlweise eine satellitenbasierte Verbindung zum Internet.
Beispiel 105 umfasst eines der Beispiele 1-13, ferner umfassend Anwenden einer Bayes'schen Analyse, um Modellgewissheitsmetriken zu erzeugen.
Beispiel 106 umfasst eines der Beispiele 49-56, wobei die Rechenressourcen Server und/oder Edge-Einrichtungen umfassen.
Beispiel 107 umfasst eines der Beispiele 49-56, wobei das Modell von Interesse ein Polynom-Regressionsmodell und/oder ein LSTM- (Long Short Term Memory) Modell umfasst.
Beispiel 108 umfasst eines der Beispiele 1-13, wobei das Verbessern der Jobressourcenplanungseffizienz durch Beurteilen von Risikoreduktion, Beurteilen von Genauigkeit und Gewissheit des ersten Modelltyps, Beurteilen eines Puffers zukünftiger Jobplanungen und Beurteilen interner Zustände des ersten Modelltyps bewirkt wird.
Beispiel 109 umfasst eines der Beispiele 14-24, wobei das Verbessern der Jobressourcenplanungseffizienz durch Beurteilen von Risikoreduktion, Beurteilen von Genauigkeit und Gewissheit des ersten Modelltyps, Beurteilen eines Puffers zukünftiger Jobplanungen und Beurteilen interner Zustände des ersten Modelltyps bewirkt wird.
Beispiel 110 umfasst eines der Beispiele 25-37, wobei das Verbessern der Jobressourcenplanungseffizienz durch Beurteilen von Risikoreduktion, Beurteilen von Genauigkeit und Gewissheit des ersten Modelltyps, Beurteilen eines Puffers zukünftiger Jobplanungen und Beurteilen interner Zustände des ersten Modelltyps bewirkt wird.
Beispiel 111 umfasst eines der Beispiele 38-48, wobei das Verbessern der Jobressourcenplanungseffizienz durch Beurteilen von Risikoreduktion, Beurteilen von Genauigkeit und Gewissheit des ersten Modelltyps, Beurteilen eines Puffers zukünftiger Jobplanungen und Beurteilen interner Zustände des ersten Modelltyps bewirkt wird.
Die folgenden Ansprüche werden hiermit durch diese Bezugnahme in diese detaillierte Beschreibung aufgenommen, wobei jeder Anspruch für sich allein als eine separate Ausführungsform der vorliegenden Offenbarung steht.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

US 62883747 [0001]
US 62/947802 [0001]
US 62/883747 [0001]
US 62947802 [0001]

Claims

Vorrichtung zum Verbessern von Jobressourcenplanungseffizienz, umfassend: einen Merkmalgenerator zum Importieren von Standardwerten von Merkmalen, die einem ersten Modelltyp entsprechen; einen Kennzeichnungstrainer zum Trainieren von Kennzeichnungen, die dem ersten Modelltyp entsprechen; und einen Modellbewerter zum: Bestimmen einer Genauigkeitsmetrik des ersten Modelltyps basierend auf einer ersten Vorhersage, die den Standardmerkmalen entspricht; und Aktualisieren der Merkmale von den Standardwerten auf aktualisierte Werte, wenn die Genauigkeitsmetrik einen Genauigkeitsschwellenwert nicht erfüllt.
Vorrichtung nach Anspruch 1, wobei der Modellbewerter die Genauigkeitsmetrik des ersten Modelltyps durch Erhöhen eines Gradmerkmals des ersten Modelltyps erhöhen soll.
Vorrichtung nach Anspruch 2, wobei der erste Modelltyp ein Polynom-Regressionsmodell ist.
Vorrichtung nach Anspruch 1, wobei der Modellbewerter eine polynomiale Aktivierungsgewichtung einstellen soll, um eine proportionale Nutzung des ersten Modelltyps und eines zweiten Modelltyps zu bewirken, wenn Vorhersagen erzeugt werden.
Vorrichtung nach Anspruch 4, wobei der Modellauswerter die polynomiale Aktivierungsgewichtung auf einen ersten Aktivierungswert einstellen soll, der den Standardwerten der Merkmale entspricht.
Vorrichtung nach Anspruch 5, wobei der erste Aktivierungswert eine exklusive Nutzung des ersten Modelltyps und eine Verhinderung einer Nutzung des zweiten Modelltyps bewirkt.
Vorrichtung nach Anspruch 4, ferner umfassend einen Datenabrufer, um zu bestimmen, ob historische Daten verfügbar sind.
Vorrichtung nach Anspruch 7, wobei die historischen Daten historischen Modelltrainingsdaten und/oder historischen Jobabbildungsdaten entsprechen.
Vorrichtung nach Anspruch 1, ferner umfassend einen Modellersteller zum Berechnen einer Suffizienzmetrik historischer Daten, die früheren Jobzuteilungsinstanzen zu Ressourcen entsprechen.
Vorrichtung nach Anspruch 9, wobei der Modellersteller eine polynomiale Aktivierungsgewichtung basierend auf der Suffizienzmetrik einstellen soll.
Vorrichtung nach Anspruch 10, wobei die polynomiale Aktivierungsgewichtung bewirkt, dass der Modellbewerter den ersten Modelltyp und einen zweiten Modelltyp proportional nutzt, wenn Vorhersagen erzeugt werden.
Vorrichtung nach Anspruch 11, wobei der zweite Modelltyp recheneffizienter als der erste Modelltyp ist.
Vorrichtung nach Anspruch 10, wobei der Modellersteller die polynomiale Aktivierungsgewichtung einstellen soll, um einen zweiten Modelltyp mehr als den ersten Modelltyp zu nutzen, wenn eine proportionale Menge der historischen Daten zunimmt.
Mindestens ein nichtflüchtiges computerlesbares Medium, das Anweisungen umfasst, die bei Ausführung mindestens einen Prozessor zu zumindest Folgendem veranlassen: Importieren von Standardwerten von Merkmalen, die einem ersten Modelltyp entsprechen; Trainieren von Kennzeichnungen, die dem ersten Modelltyp entsprechen; Bestimmen einer Genauigkeitsmetrik des ersten Modelltyps basierend auf einer ersten Vorhersage, die den Standardmerkmalen entspricht; und Aktualisieren der Merkmale von den Standardwerten auf aktualisierte Werte, wenn die Genauigkeitsmetrik einen Genauigkeitsschwellenwert nicht erfüllt.
Mindestens ein computerlesbares Medium nach Anspruch 14, wobei die Anweisungen bei Ausführung bewirken, dass der mindestens eine Prozessor die Genauigkeitsmetrik des ersten Modelltyps durch Erhöhen eines Gradmerkmals des ersten Modelltyps erhöht.
Mindestens ein computerlesbares Medium nach Anspruch 14, wobei die Anweisungen bei Ausführung bewirken, dass der mindestens eine Prozessor eine polynomiale Aktivierungsgewichtung einstellt, um eine proportionale Nutzung des ersten Modelltyps und eines zweiten Modelltyps zu bewirken, wenn Vorhersagen erzeugt werden.
Mindestens ein computerlesbares Medium nach Anspruch 16, wobei die Anweisungen bei Ausführung bewirken, dass der mindestens eine Prozessor die polynomiale Aktivierungsgewichtung auf einen ersten Aktivierungswert einstellt, der den Standardwerten der Merkmale entspricht.
Mindestens ein computerlesbares Medium nach Anspruch 17, wobei die Anweisungen bei Ausführung bewirken, dass der mindestens eine Prozessor ausschließlich den ersten Modelltyp nutzt und eine Nutzung des zweiten Modelltyps verhindert.
Mindestens ein computerlesbares Medium nach Anspruch 16, wobei die Anweisungen bei Ausführung bewirken, dass der mindestens eine Prozessor bestimmt, ob historische Daten verfügbar sind.
Mindestens ein computerlesbares Medium nach Anspruch 19, wobei die Anweisungen bei Ausführung bewirken, dass der mindestens eine Prozessor die historischen Daten als historische Modelltrainingsdaten und/oder historische Jobabbildungsdaten identifiziert.
Mindestens ein computerlesbares Medium nach Anspruch 14, wobei die Anweisungen bei Ausführung bewirken, dass der mindestens eine Prozessor eine Suffizienzmetrik historischer Daten berechnet, die früheren Jobzuteilungsinstanzen zu Ressourcen entsprechen.
Mindestens ein computerlesbares Medium nach Anspruch 21, wobei die Anweisungen bei Ausführung bewirken, dass der mindestens eine Prozessor eine polynomiale Aktivierungsgewichtung basierend auf der Suffizienzmetrik einstellt.
Mindestens ein computerlesbares Medium nach Anspruch 22, wobei die Anweisungen bei Ausführung bewirken, dass der mindestens eine Prozessor den ersten Modelltyp und einen zweiten Modelltyp proportional nutzt, wenn Vorhersagen erzeugt werden.
Mindestens ein computerlesbares Medium nach Anspruch 22, wobei die Anweisungen bei Ausführung bewirken, dass der mindestens eine Prozessor die polynomiale Aktivierungsgewichtung einstellt, um einen zweiten Modelltyp mehr als den ersten Modelltyp zu nutzen, wenn eine proportionale Menge der historischen Daten zunimmt.
Vorrichtung zum Verbessern von Jobressourcenplanungseffizienz, umfassend: Mittel zum Erzeugen von Merkmalen zum Importieren von Standardwerten von Merkmalen, die einem ersten Modelltyp entsprechen; Mittel zum Trainieren von Kennzeichnungen, um Kennzeichnungen zu trainieren, die dem ersten Modelltyp entsprechen; und Mittel zum Bewerten von Modellen zum: Bestimmen einer Genauigkeitsmetrik des ersten Modelltyps basierend auf einer ersten Vorhersage, die den Standardmerkmalen entspricht; und Aktualisieren der Merkmale von den Standardwerten auf aktualisierte Werte, wenn die Genauigkeitsmetrik einen Genauigkeitsschwellenwert nicht erfüllt.
Vorrichtung nach Anspruch 25, wobei das Modellbewertungsmittel die Genauigkeitsmetrik des ersten Modelltyps durch Erhöhen eines Gradmerkmals des ersten Modelltyps erhöhen soll.
Vorrichtung nach Anspruch 26, wobei der erste Modelltyp ein Polynom-Regressionsmodell ist.
Vorrichtung nach Anspruch 25, wobei das Modellbewertungsmittel eine polynomiale Aktivierungsgewichtung einstellen soll, um eine proportionale Nutzung des ersten Modelltyps und eines zweiten Modelltyps zu bewirken, wenn Vorhersagen erzeugt werden.
Vorrichtung nach Anspruch 28, wobei das Modellbewertungsmittel die polynomiale Aktivierungsgewichtung auf einen ersten Aktivierungswert einstellen soll, der den Standardwerten der Merkmale entspricht.
Vorrichtung nach Anspruch 29, wobei der erste Aktivierungswert eine exklusive Nutzung des ersten Modelltyps und eine Verhinderung einer Nutzung des zweiten Modelltyps bewirkt.
Vorrichtung nach Anspruch 28, ferner umfassend Mittel zum Abrufen von Daten, um zu bestimmen, ob historische Daten verfügbar sind.
Vorrichtung nach Anspruch 31, wobei die historischen Daten historischen Modelltrainingsdaten und/oder historischen Jobabbildungsdaten entsprechen.
Vorrichtung nach Anspruch 25, ferner umfassend Mittel zum Erstellen von Modellen zum Berechnen einer Suffizienzmetrik historischer Daten, die früheren Jobzuteilungsinstanzen zu Ressourcen entsprechen.
Vorrichtung nach Anspruch 33, wobei das Modellerstellungsmittel eine polynomiale Aktivierungsgewichtung basierend auf der Suffizienzmetrik einstellen soll.
Vorrichtung nach Anspruch 34, wobei das Modellbewertungsmittel den ersten Modelltyp und einen zweiten Modelltyp basierend auf der polynomialen Aktivierungsgewichtung proportional nutzen soll, wenn Vorhersagen erzeugt werden.
Vorrichtung nach Anspruch 35, wobei der zweite Modelltyp recheneffizienter als der erste Modelltyp ist.
Vorrichtung nach Anspruch 34, wobei das Modellerstellungsmittel die polynomiale Aktivierungsgewichtung einstellen soll, um einen zweiten Modelltyp mehr als den ersten Modelltyp zu nutzen, wenn eine proportionale Menge der historischen Daten zunimmt.
Computerimplementiertes Verfahren zum Verbessern von Jobressourcenplanungseffizienz, umfassend: durch Ausführen einer Anweisung mit mindestens einem Prozessor erfolgendes Importieren von Standardwerten von Merkmalen, die einem ersten Modelltyp entsprechen; durch Ausführen einer Anweisung mit dem mindestens einen Prozessor erfolgendes Trainieren von Kennzeichnungen, die dem ersten Modelltyp entsprechen; durch Ausführen einer Anweisung mit dem mindestens einen Prozessor erfolgendes Bestimmen einer Genauigkeitsmetrik des ersten Modelltyps basierend auf einer ersten Vorhersage, die den Standardmerkmalen entspricht; und durch Ausführen einer Anweisung mit dem mindestens einen Prozessor erfolgendes Aktualisieren der Merkmale von den Standardwerten auf aktualisierte Werte, wenn die Genauigkeitsmetrik einen Genauigkeitsschwellenwert nicht erfüllt.
Verfahren nach Anspruch 38, ferner umfassend Erhöhen der Genauigkeitsmetrik des ersten Modelltyps durch Erhöhen eines Gradmerkmals des ersten Modelltyps.
Verfahren nach Anspruch 38, ferner umfassend Einstellen einer polynomialen Aktivierungsgewichtung, um eine proportionale Nutzung des ersten Modelltyps und eines zweiten Modelltyps zu bewirken, wenn Vorhersagen erzeugt werden.
Verfahren nach Anspruch 40, ferner umfassend Einstellen der polynomialen Aktivierungsgewichtung auf einen ersten Aktivierungswert, der den Standardwerten der Merkmale entspricht.
Verfahren nach Anspruch 41, ferner umfassend exklusives Nutzen des ersten Modelltyps und Verhindern einer Nutzung des zweiten Modelltyps.
Verfahren nach Anspruch 40, ferner umfassend Bestimmen, ob historische Daten verfügbar sind.
Verfahren nach Anspruch 43, ferner umfassend Identifizieren der historischen Daten als historische Modelltrainingsdaten und/oder historische Jobabbildungsdaten.
Verfahren nach Anspruch 38, ferner umfassend einen Modellersteller zum Berechnen einer Suffizienzmetrik historischer Daten, die früheren Jobzuteilungsinstanzen zu Ressourcen entsprechen.
Verfahren nach Anspruch 45, ferner umfassend Einstellen einer polynomialen Aktivierungsgewichtung basierend auf der Suffizienzmetrik.
Verfahren nach Anspruch 46, ferner umfassend proportionales Nutzen des ersten Modelltyps und eines zweiten Modelltyps, wenn Vorhersagen erzeugt werden.
Verfahren nach Anspruch 46, ferner umfassend Einstellen der polynomialen Aktivierungsgewichtung, um einen zweiten Modelltyp mehr als den ersten Modelltyp zu nutzen, wenn eine proportionale Menge der historischen Daten zunimmt.
Vorrichtung zum Erzeugen gekennzeichneter Trainingsdaten für ein Jobplanungssystem, umfassend: einen Modellbewerter zum: Importieren eines ersten Satzes von Attributen, die Rechenressourcen des Jobplanungssystems entsprechen; Bestimmen, ob der erste Satz von Attributen zuvor zum Trainieren eines Modells von Interesse verwendet wurde; und in Reaktion auf Bestimmen, dass der erste Satz von Attributen nicht zum Trainieren des Modells von Interesse verwendet wurde, Trainieren des Modells von Interesse basierend auf einem Trainingsschwellenwert.
Vorrichtung nach Anspruch 49, wobei der Trainingsschwellenwert eine Schwellenanzahl von Trainingsiterationen des Modells von Interesse und/oder eine Schwellenzeitdauer beim Trainieren des Modells von Interesse und/oder eine Schwellenanzahl von Trainingsepochen umfasst.
Vorrichtung nach Anspruch 49, wobei der erste Satz von Attributen zumindest eine Anzahl von Platinen, die einen ersten Jobtyp ausführen, und/oder eine Anzahl von Jobs, die aktuell ausgeführt werden, und/oder eine Anzahl wartender Jobs umfasst.
Vorrichtung nach Anspruch 49, wobei der Modellbewerter in Reaktion auf Bestimmen, dass der erste Satz von Attributen zum Trainieren des Modells von Interesse verwendet wurde, einen zweiten Satz von Attributen auswählen soll, wobei sich der erste Satz von Attributen von dem zweiten Satz von Attributen unterscheidet.
Vorrichtung nach Anspruch 49, ferner umfassend einen Architekturanalysierer zum Bestimmen des ersten Satzes von Attributen durch Analysieren kommunikativ verbundener Hardwareressourcen des Planungssystems.
Vorrichtung nach Anspruch 53, wobei der Architekturanalysierer eine Anzahl von Servern der verbundenen Hardwareressourcen und/oder eine Anzahl von Einheiten innerhalb der Anzahl von Servern und/oder eine Anzahl von Platinen innerhalb der Anzahl von Einheiten bestimmen soll.
Vorrichtung nach Anspruch 49, ferner umfassend einen Matrixgenerator zum Kennzeichnen jeweiliger des ersten Satzes von Attributen basierend auf einem Verwendungsstatus oder einem Sperrstatus.
Vorrichtung nach Anspruch 55, wobei der Matrixgenerator eine Matrix gekennzeichneter Statusindikatoren erzeugen soll, die den Hardwareressourcen entsprechen.
Mindestens ein nicht transientes computerlesbares Medium, das Anweisungen umfasst, die bei Ausführung mindestens einen Prozessor zu zumindest Folgendem veranlassen: Importieren eines ersten Satzes von Attributen, die Rechenressourcen des Jobplanungssystems entsprechen; Bestimmen, ob der erste Satz von Attributen zuvor zum Trainieren eines Modells von Interesse verwendet wurde; und in Reaktion auf Bestimmen, dass der erste Satz von Attributen nicht zum Trainieren des Modells von Interesse verwendet wurde, Trainieren des Modells von Interesse basierend auf einem Trainingsschwellenwert.
Mindestens ein computerlesbares Medium nach Anspruch 57, wobei die Anweisungen bei Ausführung bewirken, dass der mindestens eine Prozessor den Trainingsschwellenwert als eine Schwellenanzahl von Trainingsiterationen des Modells von Interesse und/oder eine Schwellenzeitdauer beim Trainieren des Modells von Interesse und/oder eine Schwellenanzahl von Trainingsepochen identifiziert.
Mindestens ein computerlesbares Medium nach Anspruch 57, wobei die Anweisungen bei Ausführug bewirken, dass der mindestens eine Prozessor den ersten Satz von Attributen als eine Anzahl von Platinen, die einen ersten Jobtyp ausführen, und/oder eine Anzahl von Jobs, die aktuell ausgeführt werden, und/oder eine Anzahl wartender Jobs identifiziert.
Mindestens ein computerlesbares Medium nach Anspruch 57, wobei die Anweisungen bei Ausführung bewirken, dass der mindestens eine Prozessor in Reaktion auf Bestimmen, dass der erste Satz von Attributen zum Trainieren des Modells von Interesse verwendet wurde, einen zweiten Satz von Attributen auswählt, wobei sich der erste Satz von Attributen von dem zweiten Satz von Attributen unterscheidet.
Mindestens ein computerlesbares Medium nach Anspruch 57, wobei die Anweisungen bei Ausführung bewirken, dass der mindestens eine Prozessor den ersten Satz von Attributen durch Analysieren kommunikativ verbundener Hardwareressourcen des Planungssystems bestimmt.
Mindestens ein computerlesbares Medium nach Anspruch 61, wobei die Anweisungen bei Ausführung bewirken, dass der mindestens eine Prozessor eine Anzahl von Servern der verbundenen Hardwareressourcen und/oder eine Anzahl von Einheiten innerhalb der Anzahl von Servern und/oder eine Anzahl von Platinen innerhalb der Anzahl von Einheiten bestimmt.
Mindestens ein computerlesbares Medium nach Anspruch 57, wobei die Anweisungen bei Ausführung bewirken, dass der mindestens eine Prozessor jeweilige des ersten Satzes von Attributen basierend auf einem Verwendungsstatus oder einem Sperrstatus kennzeichnet.
Mindestens ein computerlesbares Medium nach Anspruch 63, wobei die Anweisungen bei Ausführung bewirken, dass der mindestens eine Prozessor eine Matrix gekennzeichneter Statusindikatoren erzeugt, die den Hardwareressourcen entsprechen.
Vorrichtung zum Erzeugen gekennzeichneter Trainingsdaten für ein Jobplanungssystem, umfassend: Mittel zum Analysieren einer Architektur, um einen ersten Satz von Attributen durch Analysieren kommunikativ verbundener Hardwareressourcen des Jobplanungssystems zu bestimmen; und Modellbewertungsmittel zum: Importieren des ersten Satzes von Attributen, die den Hardwareressourcen des Jobplanungssystems entsprechen; Bestimmen, ob der erste Satz von Attributen zuvor zum Trainieren eines Modells von Interesse verwendet wurde; und in Reaktion auf Bestimmen, dass der erste Satz von Attributen nicht zum Trainieren des Modells von Interesse verwendet wurde, Trainieren des Modells von Interesse basierend auf einem Trainingsschwellenwert.
Vorrichtung nach Anspruch 65, wobei der Trainingsschwellenwert eine Schwellenanzahl von Trainingsiterationen des Modells von Interesse und/oder eine Schwellenzeitdauer beim Trainieren des Modells von Interesse und/oder eine Schwellenanzahl von Trainingsepochen umfasst.
Vorrichtung nach Anspruch 65, wobei der erste Satz von Attributen zumindest eine Anzahl von Platinen, die einen ersten Jobtyp ausführen, und/oder eine Anzahl von Jobs, die aktuell ausgeführt werden, und/oder eine Anzahl wartender Jobs umfasst.
Vorrichtung nach Anspruch 65, wobei das Modellbewertungsmittel in Reaktion auf Bestimmen, dass der erste Satz von Attributen zum Trainieren des Modells von Interesse verwendet wurde, einen zweiten Satz von Attributen auswählen soll, wobei sich der erste Satz von Attributen von dem zweiten Satz von Attributen unterscheidet.
Vorrichtung nach Anspruch 65, wobei das Architekturanalysemittel eine Anzahl von Servern der verbundenen Hardwareressourcen und/oder eine Anzahl von Einheiten innerhalb der Anzahl von Servern und/oder eine Anzahl von Platinen innerhalb der Anzahl von Einheiten bestimmen soll.
Vorrichtung nach Anspruch 65, ferner umfassend Mittel zum Matrixerzeugen zum Kennzeichnen jeweiliger des ersten Satzes von Attributen basierend auf einem Verwendungsstatus oder einem Sperrstatus.
Vorrichtung nach Anspruch 70, wobei das Matrixerzeugungsmittel eine Matrix gekennzeichneter Statusindikatoren erzeugen soll, die den Hardwareressourcen entsprechen.
Verfahren zum Erzeugen gekennzeichneter Trainingsdaten für ein Jobplanungssystem, umfassend: durch Ausführen einer Anweisung mit mindestens einem Prozessor erfolgendes Importieren eines ersten Satzes von Attributen, die Rechenressourcen des Jobplanungssystems entsprechen; durch Ausführen einer Anweisung mit dem mindestens einen Prozessor erfolgendes Bestimmen, ob der erste Satz von Attributen zuvor zum Trainieren eines Modells von Interesse verwendet wurde; und in Reaktion auf Bestimmen, dass der erste Satz von Attributen nicht zum Trainieren des Modells von Interesse verwendet wurde, durch Ausführen einer Anweisung mit dem mindestens einen Prozessor erfolgendes Trainieren des Modells von Interesse basierend auf einem Trainingsschwellenwert.
Verfahren nach Anspruch 72, ferner umfassend Identifizieren des Trainingsschwellenwerts als eine Schwellenanzahl von Trainingsiterationen des Modells von Interesse und/oder eine Schwellenzeitdauer beim Trainieren des Modells von Interesse und/oder eine Schwellenanzahl von Trainingsepochen.
Verfahren nach Anspruch 72, ferner umfassend Identifizieren des ersten Satzes von Attributen als eine Anzahl von Platinen, die einen ersten Jobtyp ausführen, und/oder eine Anzahl von Jobs, die aktuell ausgeführt werden, und/oder eine Anzahl wartender Jobs.
Verfahren nach Anspruch 72, ferner umfassend Auswählen eines zweiten Satzes von Attributen in Reaktion auf Bestimmen, dass der erste Satz von Attributen zum Trainieren des Modells von Interesse verwendet wurde, wobei sich der erste Satz von Attributen von dem zweiten Satz von Attributen unterscheidet.
Verfahren nach Anspruch 72, ferner umfassend Bestimmen des ersten Satzes von Attributen durch Analysieren kommunikativ verbundener Hardwareressourcen des Planungssystems.
Verfahren nach Anspruch 76, ferner umfassend Bestimmen einer Anzahl von Servern der verbundenen Hardwareressourcen und/oder einer Anzahl von Einheiten innerhalb der Anzahl von Servern und/oder einer Anzahl von Platinen innerhalb der Anzahl von Einheiten.
Verfahren nach Anspruch 72, ferner umfassend Kennzeichnen jeweiliger des ersten Satzes von Attributen basierend auf einem Verwendungsstatus oder einem Sperrstatus.
Verfahren nach Anspruch 78, ferner umfassend Erzeugen einer Matrix gekennzeichneter Statusindikatoren, die den Hardwareressourcen entsprechen.
Vorrichtung zum Verbessern von Modelleffizienz, umfassend: einen Modellzustandsbeurteiler zum: Auswählen eines Modells von Interesse; Auswählen einer Schicht innerhalb des Modells von Interesse; Berechnen eines Wahrscheinlichkeitswerts, der der Schicht entspricht; Vergleichen des Wahrscheinlichkeitswerts mit einem Aussonderungsschwellenwert; und Verbessern einer Effizienz des Modells durch Entfernen der Schicht aus dem Modell, wenn der Wahrscheinlichkeitswert den Aussonderungsschwellenwert erfüllt.
Vorrichtung nach Anspruch 80, wobei der Modellzustandsbeurteiler die Schicht beibehalten soll, wenn der Wahrscheinlichkeitswert den Aussonderungsschwellenwert nicht erfüllt.
Vorrichtung nach Anspruch 80, wobei der Modellzustandsbeurteiler eine zweite Schicht zur Bewertung auswählen soll, nachdem der Schichtwahrscheinlichkeitswert berechnet wurde.
Vorrichtung nach Anspruch 80, wobei das Modell ein LSTM- (Long Short Term Memory) Modell umfasst.
Nicht transientes computerlesbares Medium, das Anweisungen umfasst, die bei Ausführung mindestens einen Prozessor zu zumindest Folgendem veranlassen: Auswählen eines Modells von Interesse; Auswählen einer Schicht innerhalb des Modells von Interesse; Berechnen eines Wahrscheinlichkeitswerts, der der Schicht entspricht; Vergleichen des Wahrscheinlichkeitswerts mit einem Aussonderungsschwellenwert; und Verbessern einer Effizienz des Modells durch Entfernen der Schicht aus dem Modell, wenn der Wahrscheinlichkeitswert den Aussonderungsschwellenwert erfüllt.
Computerlesbares Medium nach Anspruch 84, wobei die Anweisungen bei Ausführung bewirken, dass der mindestens eine Prozessor die Schicht beibehält, wenn der Wahrscheinlichkeitswert den Aussonderungsschwellenwert nicht erfüllt.
Computerlesbares Medium nach Anspruch 84, wobei die Anweisungen bei Ausführung bewirken, dass der mindestens eine Prozessor eine zweite Schicht zur Bewertung auswählt, nachdem der Schichtwahrscheinlichkeitswert berechnet wurde.
Computerlesbares Medium nach Anspruch 84, wobei die Anweisungen bei Ausführung bewirken, dass der mindestens eine Prozessor das Modell als ein LSTM- (Long Short Term Memory) Modell implementiert.
Vorrichtung zum Verbessern von Modelleffizienz, umfassend: Mittel zum Abrufen, um Daten abzurufen, die verfügbaren Modellen entsprechen; und Mittel zur Modellzustandsbeurteilung zum: Auswählen eines Modells von Interesse; Auswählen einer Schicht innerhalb des Modells von Interesse; Berechnen eines Wahrscheinlichkeitswerts, der der Schicht entspricht; Vergleichen des Wahrscheinlichkeitswerts mit einem Aussonderungsschwellenwert; und Verbessern einer Effizienz des Modells durch Entfernen der Schicht aus dem Modell, wenn der Wahrscheinlichkeitswert den Aussonderungsschwellenwert erfüllt.
Vorrichtung nach Anspruch 88, wobei das Modellzustandsbeurteilungsmittel die Schicht beibehalten soll, wenn der Wahrscheinlichkeitswert den Aussonderungsschwellenwert nicht erfüllt.
Vorrichtung nach Anspruch 88, wobei das Modellzustandsbeurteilungsmittel eine zweite Schicht zur Bewertung auswählen soll, nachdem der Schichtwahrscheinlichkeitswert berechnet wurde.
Vorrichtung nach Anspruch 88, wobei das Modellzustandsbeurteilungsmittel das Modell als LSTM- (Long Short Term Memory) Modell implementieren soll.
Verfahren zum Verbessern von Modelleffizienz, umfassend: durch Ausführen einer Anweisung mit mindestens einem Prozessor erfolgendes Auswählen eines Modells von Interesse; durch Ausführen einer Anweisung mit dem mindestens einen Prozessor erfolgendes Auswählen einer Schicht innerhalb des Modells von Interesse; durch Ausführen einer Anweisung mit dem mindestens einen Prozessor erfolgendes Berechnen eines Wahrscheinlichkeitswerts, der der Schicht entspricht; durch Ausführen einer Anweisung mit dem mindestens einen Prozessor erfolgendes Vergleichen des Wahrscheinlichkeitswerts mit einem Aussonderungsschwellenwert; und durch Ausführen einer Anweisung mit dem mindestens einen Prozessor erfolgendes Verbessern einer Effizienz des Modells durch Entfernen der Schicht aus dem Modell, wenn der Wahrscheinlichkeitswert den Aussonderungsschwellenwert erfüllt.
Verfahren nach Anspruch 92, ferner umfassend Beibehalten der Schicht, wenn der Wahrscheinlichkeitswert den Aussonderungsschwellenwert nicht erfüllt.
Verfahren nach Anspruch 92, ferner umfassend Auswählen einer zweiten Schicht zur Bewertung, nachdem der Schichtwahrscheinlichkeitswert berechnet wurde.
Verfahren nach Anspruch 92, ferner umfassend Implementieren des Modells als LSTM- (Long Short Term Memory) Modell.