mosec

Modelldienste in der Cloud effizient gemacht.

Einführung

MOSEC ist ein Hochleistungs- und flexibler Modell, das das Modell für das Erstellen von ML-Modell-fähigen Backends und Microservices erstellt. Es überbrückt die Lücke zwischen allen von Ihnen geschulten maschinellen Lernmodellen und der effizienten Online -Service -API.

• Sehr leistungsstärkend : Webschicht und Aufgabenkoordination mit Rost? Er bietet zusätzlich zu einer effizienten CPU -Auslastung, die von Async I/O betrieben wird
• Benutzerfreundlichkeit : Benutzeroberfläche rein in Python? Dabei können Benutzer ihre Modelle auf ml Framework-agnostische Weise verwenden, indem sie denselben Code wie für Offline-Tests tun
• Dynamische Charge : Aggregate Anfragen verschiedener Benutzer für angegriffene Inferenz und Verteiler der Ergebnisse zurück
• Pipeline -Stufen : Laichen mehrere Prozesse für Pipelined -Stufen zur Verarbeitung von CPU/GPU/IO gemischte Workloads
• Cloud -freundlich : entwickelt in der Cloud mit den Metriken für Modellwärme, anmutiges Abschalten und Prometheus -Überwachung, die von Kubernetes oder Container -Orchestrierungssystemen problemlos verwaltet werden
• Machen Sie eins gut : Konzentrieren Sie sich auf den Online -Servierteil, Benutzer können auf die Modelloptimierung und die Geschäftslogik achten

Installation

Mosec benötigt Python 3.7 oder höher. Installieren Sie das neueste PYPI -Paket für Linux x86_64 oder macOS x86_64/arm64 mit:

pip install -U mosec
# or install with conda
conda install conda-forge::mosec

Um aus dem Quellcode zu erstellen, installieren Sie Rost und führen Sie den folgenden Befehl aus:

make package

Sie erhalten eine MOSEC -Raddatei im dist -Ordner.

Verwendung

Wir zeigen, wie MOSEC Ihnen helfen kann, ein vorgebildetes stabiles Diffusionsmodell als Dienst problemlos zu hosten. Sie müssen Diffusoren und Transformatoren als Voraussetzungen installieren:

pip install --upgrade diffusers[torch] transformers

Schreiben Sie den Server

Klicken Sie mich für Servercodes mit Erklärungen.

Zunächst importieren wir die Bibliotheken und richten einen grundlegenden Logger ein, um besser zu beobachten, was passiert.

 from io import BytesIO
from typing import List

import torch  # type: ignore
from diffusers import StableDiffusionPipeline  # type: ignore

from mosec import Server , Worker , get_logger
from mosec . mixin import MsgpackMixin

logger = get_logger ()

Anschließend erstellen wir eine API, damit Clients eine Textaufforderung abfragen und ein Bild basieren, das auf dem Modell der Stabil-Diffusion-V1-5 in nur 3 Schritten basiert.

1. Definieren Sie Ihren Dienst als eine Klasse, die mosec.Worker erbt. Hier erben wir auch MsgpackMixin , um das MSGPack -Serialisierungsformat ^(a) zu verwenden.

2. Initialisieren Sie Ihr Modell in der __init__ -Methode und legen Sie es auf das entsprechende Gerät. Optional können Sie self.example zuweisen. Beispiele mit einigen Daten zum Aufwärmen ^(b) das Modell. Beachten Sie, dass die Daten mit dem Eingabeformat Ihres Handlers kompatibel sein sollten, das wir als nächstes beschreiben.

3. Überschreiben Sie die forward , um Ihren Service -Handler ^(c) mit der Signatur forward(self, data: Any | List[Any]) -> Any | List[Any] . Das Empfangen/Rückgabe eines einzelnen Elements oder eines Tupels hängt davon ab, ob dynamisches Batching ^(d) konfiguriert ist.

 class StableDiffusion ( MsgpackMixin , Worker ):
    def __init__ ( self ):
        self . pipe = StableDiffusionPipeline . from_pretrained (
            "sd-legacy/stable-diffusion-v1-5" , torch_dtype = torch . float16
        )
        self . pipe . enable_model_cpu_offload ()
        self . example = [ "useless example prompt" ] * 4  # warmup (batch_size=4)

    def forward ( self , data : List [ str ]) -> List [ memoryview ]:
        logger . debug ( "generate images for %s" , data )
        res = self . pipe ( data )
        logger . debug ( "NSFW: %s" , res [ 1 ])
        images = []
        for img in res [ 0 ]:
            dummy_file = BytesIO ()
            img . save ( dummy_file , format = "JPEG" )
            images . append ( dummy_file . getbuffer ())
        return images

[!NOTIZ]

(a) In diesem Beispiel geben wir ein Bild im binären Format zurück, das JSON nicht unterstützt (es sei denn, mit Base64 kodiert, was die Nutzlast größer macht). MSGPACK passt daher zu unserem Bedarf besser. Wenn wir MsgpackMixin nicht erben, wird JSON standardmäßig verwendet. Mit anderen Worten, das Protokoll der Serviceanforderung/Antwort kann entweder MSGPack, JSON oder ein anderes Format sein (überprüfen Sie unsere Mixins).

(b) Das Aufwärmen hilft normalerweise dabei, GPU-Speicher im Voraus zuzuweisen. Wenn das Aufwärmbeispiel angegeben ist, ist der Dienst erst fertig, nachdem das Beispiel über den Handler weitergeleitet wurde. Wenn jedoch kein Beispiel angegeben ist, wird erwartet, dass die Latenz der ersten Anfrage länger dauert. Das example sollte als einzelnes Element oder Tupel festgelegt werden, je nachdem, was forward erwartet wird. In dem Fall, in dem Sie sich mit mehreren verschiedenen Beispielen erwärmen möchten, können Sie multi_examples (Demo hier) festlegen.

(c) Dieses Beispiel zeigt einen einstufigen Dienst, bei dem der StableDiffusion direkt die Eingabeaufforderung des Kunden aufnimmt und das Bild beantwortet. Somit kann der forward als vollständiger Service -Handler betrachtet werden. Wir können jedoch auch einen mehrstufigen Service mit Arbeitnehmern entwerfen, die unterschiedliche Jobs (z. B. herunterladen, Bilder, Modellinferenz, Nachbearbeitung) in einer Pipeline erledigen. In diesem Fall wird die gesamte Pipeline als Service -Handler angesehen, wobei der erste Arbeiter die Anfrage aufnimmt und der letzte Arbeiter die Antwort aussendet. Der Datenfluss zwischen den Arbeitnehmern erfolgt durch die Kommunikation mit Inter-Process.

(d) Da in diesem Beispiel die dynamische Batching aktiviert ist, erhält die forward Wunsch eine Liste von String, z ['a cute cat playing with a red ball', 'a man sitting in front of a computer', ...]

Schließlich fügen wir den Arbeiter dem Server hinzu, um einen einstufigen Workflow zu erstellen (mehrere Stufen können pipeliert werden, um den Durchsatz weiter zu steigern, dieses max_batch_size=4 num=1 ) und geben die Anzahl der Prozesse an, von denen er parallel ausgeführt werden soll max_wait_time=10 in Millisekunden, was bedeutet, dass MOSEC die längste Zeit wartet, bis die Charge an den Arbeiter gesendet wird).

 if __name__ == "__main__" :
    server = Server ()
    # 1) `num` specifies the number of processes that will be spawned to run in parallel.
    # 2) By configuring the `max_batch_size` with the value > 1, the input data in your
    # `forward` function will be a list (batch); otherwise, it's a single item.
    server . append_worker ( StableDiffusion , num = 1 , max_batch_size = 4 , max_wait_time = 10 )
    server . run ()

Führen Sie den Server aus

Klicken Sie auf mich, um zu sehen, wie Sie den Server ausführen und abfragen.

Die obigen Ausschnitte werden in unserer Beispieldatei zusammengeführt. Sie können direkt auf der Projektstammebene ausgeführt werden. Wir sehen uns zuerst die Befehlszeilenargumente an (Erklärungen hier):

python examples/stable_diffusion/server.py --help

Dann starten wir den Server mit Debug -Protokollen:

python examples/stable_diffusion/server.py --log-level debug --timeout 30000

Öffnen Sie in Ihrem Browser http://127.0.0.1:8000/openapi/swagger/ , um den OpenAPI -Doc zu erhalten.

Und in einem anderen Terminal testen Sie es:

python examples/stable_diffusion/client.py --prompt " a cute cat playing with a red ball " --output cat.jpg --port 8000

Sie erhalten ein Bild mit dem Namen "Cat.jpg" im aktuellen Verzeichnis.

Sie können die Metriken überprüfen:

curl http://127.0.0.1:8000/metrics

Das war's! Sie haben gerade Ihr Stall-Diffusion-Modell als Service gehostet!

Beispiele

Weitere nutzende Beispiele finden Sie im Beispielabschnitt. Es enthält:

• Pipeline: Eine einfache Echo -Demo auch ohne ML -Modell.
• Anfrage Validierung: Validieren Sie die Anforderung mit Typ Annotation und generieren Sie eine OpenAPI -Dokumentation.
• Multiple Route: Servieren Sie mehrere Modelle in einem Dienst
• Einbettungsdienst: OpenAI -kompatibler Einbettungsdienst
• Umlesedienste: Weiterleiten Sie eine Liste von Passagen an, die auf einer Abfrage basieren
• Shared Memory IPC: Inter-Process-Kommunikation mit gemeinsamem Speicher.
• Customized GPU -Zuordnung: Bereitstellen mehrerer Replikate mit jeweils unterschiedlichen GPUs.
• Angeeinten Metriken: Nehmen Sie Ihre eigenen Metriken für die Überwachung auf.
• JAX JIDT Inference: Just-in-Time Compilation beschleunigt die Inferenz.
• Komprimierung: Anforderung/Antwortkomprimierung aktivieren.
• Pytorch Deep Learning Models:
  • Sentimentanalyse: Schließen Sie das Gefühl eines Satzes ab.
  • Bilderkennung: kategorisieren Sie ein bestimmtes Bild.
  • Stabile Diffusion: Erzeugen Sie Bilder basierend auf Texten mit MSGPack -Serialisierung.

Konfiguration

• Dynamisches Chargen
  • max_batch_size und max_wait_time (millisecond) sind konfiguriert, wenn Sie append_worker aufrufen.
  • Stellen Sie sicher, dass die Inferenz mit dem Wert max_batch_size das nicht ausgelöste in der GPU nicht verursacht.
  • Normalerweise sollte max_wait_time geringer sein als die Stapel -Inferenzzeit.
  • Wenn es aktiviert ist, wird eine Stapel entweder eingewiesen, wenn die Anzahl der angesammelten Anforderungen max_batch_size erreicht oder wenn max_wait_time verstrichen ist. Der Service wird von dieser Funktion profitieren, wenn der Verkehr hoch ist.
• Überprüfen Sie die Argumente doc auf andere Konfigurationen.

Einsatz

• Wenn Sie nach einem GPU -Basisbild mit installiertem mosec suchen, können Sie das offizielle Bild mosecorg/mosec überprüfen. Für den komplexen Anwendungsfall schauen Sie sich Envd an.
• Dieser Service benötigt kein Gunicorn oder Nginx, aber Sie können den Eingangscontroller bei Bedarf sicherlich verwenden.
• Dieser Service sollte der PID 1 -Prozess im Container sein, da er mehrere Prozesse steuert. Wenn Sie mehrere Prozesse in einem Container ausführen müssen, benötigen Sie einen Vorgesetzten. Sie können Supervisor oder Horust wählen.
• Denken Sie daran, die Metriken zu sammeln.
  • mosec_service_batch_size_bucket Zeigt die Stapelgrößenverteilung an.
  • mosec_service_batch_duration_second_bucket Zeigt die Dauer der dynamischen Charge für jede Verbindung in jeder Phase an (beginnt damit, die erste Aufgabe zu empfangen).
  • mosec_service_process_duration_second_bucket Zeigt die Verarbeitungsdauer für jede Verbindung in jeder Phase an (einschließlich der IPC -Zeit, jedoch ohne mosec_service_batch_duration_second_bucket ).
  • mosec_service_remaining_task Zeigt die Anzahl der derzeit verarbeitenden Aufgaben an.
  • mosec_service_throughput zeigt den Service -Durchsatz.
• Stoppen Sie den Dienst mit SIGINT ( CTRL+C ) oder SIGTERM ( kill {PID} ), da er die anmutige Stillschadenlogik hat.

Leistungsstimmung

• Finden Sie die besten max_batch_size und max_wait_time für Ihren Inferenzdienst heraus. Die Metriken zeigen die Histogramme der realen Chargengröße und der Stapeldauer. Dies sind die wichtigsten Informationen, um diese beiden Parameter anzupassen.
• Versuchen Sie, den gesamten Inferenzprozess in separate CPU- und GPU -Stufen aufzuteilen (Ref Distilbert). In einer Datenpipeline werden verschiedene Stufen ausgeführt, wodurch die GPU beschäftigt ist.
• Sie können auch die Anzahl der Arbeiter in jeder Phase einstellen. Wenn Ihre Pipeline beispielsweise aus einer CPU-Stufe für die Vorverarbeitung und einer GPU-Stufe für die Modellinferenz besteht, kann die Erhöhung der Anzahl der CPU-Stufe dazu beitragen, mehr Daten zu erstellen, die für die Modellinferenz in der GPU-Stufe angegriffen werden können. Durch Erhöhen der Mitarbeiter der GPU-Stufe kann die GPU-Speicher- und Rechenleistung vollständig genutzt werden. Beide Möglichkeiten können zu einer höheren GPU -Nutzung beitragen, was folglich zu einem höheren Service -Durchsatz führt.
• Beachten Sie bei mehrstufigen Diensten, dass die Daten, die durch verschiedene Stadien gehen, von den Methoden serialize_ipc/deserialize_ipc serialisiert/deserialisiert werden, sodass extrem große Daten die gesamte Pipeline langsamer machen können. Die serialisierten Daten werden standardmäßig durch Rost an die nächste Stufe übergeben. Sie können es gemeinsam ermöglichen, dass der gemeinsame Speicher die Latenz möglicherweise reduziert (RefusShmipcmixin).
• Sie sollten entsprechende serialize/deserialize -Methoden auswählen, mit denen die Benutzeranforderung dekodiert und die Antwort codiert. Standardmäßig verwenden beide JSON. Bilder und Einbettungen werden jedoch von JSON nicht gut unterstützt. Sie können MSGPack auswählen, das schneller und binär kompatibel ist (ref stabile Diffusion).
• Konfigurieren Sie die Threads für Openblas oder MKL. Es kann möglicherweise nicht den am besten geeigneten CPUs auswählen, der vom aktuellen Python -Prozess verwendet wird. Sie können es für jeden Arbeiter mithilfe der ENV (Ref Custom GPU -Zuordnung) konfigurieren.
• Aktivieren Sie HTTP/2 von der Client -Seite. mosec passt sich automatisch an das Benutzerprotokoll (z. B. HTTP/2) seit V0.8.8 an.

Adoptierter

Hier sind einige Unternehmen und einzelne Benutzer, die MOSEC verwenden:

• Modellz: Serverlose Plattform für ML -Inferenz.
• MOSS: Ein offenes Konversationssprachmodell wie Chatgpt.
• TencentCloud: Tencent Cloud Machine Learning Platform mit MOSEC als Core Inference Server -Framework.
• Tensorchord: Cloud Native AI Infrastructure Company.
• Hafer: Prämienmodelle für die Online -LLM -Ausrichtung bedienen.

Zitat

Wenn Sie diese Software für Ihre Forschung nützlich finden, sollten Sie sich angeben

 @software{yang2021mosec,
  title = {{MOSEC: Model Serving made Efficient in the Cloud}},
  author = {Yang, Keming and Liu, Zichen and Cheng, Philip},
  url = {https://github.com/mosecorg/mosec},
  year = {2021}
}

Beitragen

Wir begrüßen jeden Beitrag. Bitte geben Sie uns Feedback, indem Sie Probleme aufwerfen oder auf Zwietracht diskutieren. Sie können Ihren Code auch direkt beitragen und Anfrage ziehen!

Um sich zu entwickeln, können Sie Envd verwenden, um eine isolierte und saubere Python & Rust -Umgebung zu schaffen. Weitere Informationen finden Sie in den Envd-Docs oder Build.envd.