Halkali Merkez Viertel Fatih Str. Ozgur Apt. No. 46, Kucukcekmece, Istanbul, 34303, TR
Wir haben OpenAI GPT-OSS 20B mit LM Studio 0.4.21 auf einem echten Windows-PC ausgeführt. Vom Modelldownload und den Hardware-Reglern bis zu einer technischen Antwort mit 2489 Token und dem Vergleich Max Concurrent Predictions 4 gegen 1 ist der gesamte Ablauf mit 23 echten Screenshots dokumentiert.
Context 8192 GPU Offload 24 CPU Threads 6 Eval / Physical 2048 / 512 Concurrent 1 Reasoning Low
Die Werte wurden nur auf diesem Gerät, mit dieser LM-Studio-Version und in dieser Sitzung gemessen. Trotz identischem Prompt kann das Modell unterschiedlich lange Antworten erzeugen; kleine Geschwindigkeitsunterschiede sind daher keine allgemeine Leistungsgarantie.
In LM Studio zeigt openai/gpt-oss-20b eine bereits heruntergeladene GGUF-Option mit 12,11 GB. Auf derselben Modellseite sind Reasoning und Tool Use als Funktionen markiert.
Laut offizieller OpenAI Model Card besitzt gpt-oss-20b 20,9 Mrd. Gesamtparameter, 3,6 Mrd. aktive Parameter pro Token und 24 Layer in einer Mixture-of-Experts-Architektur.
Die 12,11 GB Downloadgröße ist kein Minimum für RAM oder VRAM. Kontext, KV-Cache, Runtime-Puffer und Betriebssystem benötigen zusätzlichen Speicher.
12,11 GB ist die Dateigröße dieses GGUF-Pakets in LM Studio, nicht der gesamte Laufzeitspeicher.
Alle Messungen erfolgten auf demselben Windows-PC: Intel Core i7-10875H, 63,84 GB System-RAM und NVIDIA GeForce RTX 2070 8 GB. LM Studio erkennt die GPU über CUDA.
„Limit Model Offload to Dedicated GPU Memory“ und „Offload KV Cache to GPU Memory“ blieben aktiv. Das Dedicated-Memory-Limit soll verhindern, dass Modellgewichte unnötig in Windows Shared GPU Memory ausgelagert werden.
Wichtig: Das Modell lief mit 8 GB VRAM, aber gleichzeitig standen rund 64 GB System-RAM zur Verfügung, um nicht in VRAM passende Modellteile aufzunehmen.
Dieser Guide behauptet nicht, dass ausschließlich 8 GB VRAM ausreichen; das reale System kombiniert 8 GB VRAM mit 63,84 GB RAM.
Verwendet wurden 8192 Kontext, 24 GPU-Offload, 6 CPU-Threads, Evaluation Batch 2048, Physical Batch 512 und Max Concurrent Predictions 4. Unified KV Cache blieb aktiv.
Obwohl LM Studio maximal 131072 Kontext-Token für das Modell anzeigt, wurde für den Benchmark 8192 gewählt. Maximaler Kontext ist nicht für jeden Desktop-Workflow sinnvoll und erhöht Cache- und Speicherbedarf.
Der GPU-Offload-Regler endet bei 24, passend zu den 24 Layern des Modells. Mit Dedicated-GPU-Memory-Limit warnt LM Studio, dass die tatsächlich ausgelagerte Layer-Zahl abweichen kann.
Context Length: 8192 GPU Offload: 24 CPU Thread Pool Size: 6 Evaluation Batch Size: 2048 Physical Batch Size: 512 Max Concurrent Predictions: 4 Unified KV Cache: ON Dedicated GPU Memory Limit: ON KV Cache -> GPU: ON Reasoning: Low
Statt einer kurzen Begrüßung wurde ein fixer Prompt verwendet, der mehrere Minuten technische Ausgabe erzeugt. Er verlangt PHP 8.3, MySQL, Redis, Sessions, Queues, Sicherheit und Backups in einer Architektur.
Low Reasoning war aktiv. Die Antwort umfasste Datenbank, Redis Cache/Session, Queue, Sicherheit, Backup und DevOps über mehrere Tausend Token. Sie ist Benchmark-Workload und keine validierte Produktionsarchitektur.
Durch die lange Antwort ist Token/s aussagekräftiger als bei einer 10–20-Token-Begrüßung und es bleibt genug Zeit, Hardware-Werte aufzuzeichnen.
Schlage für einen kleinen E-Commerce-Shop eine skalierbare Systemarchitektur mit PHP 8.3, MySQL und Redis vor. Erkläre Datenbank, Cache, Session, Queue, Sicherheit und Backup technisch.
Nach dem ersten langen Lauf zeigte LM Studio 10,85 Token/s und 2489 Output-Token. Daneben standen 1,56 s; bei LM Studio ist dies die Time to First Token, also die Verzögerung bis zum ersten Token.
Während der Generierung zeigte der Hardware Resource Monitor 11,61 GB RAM + VRAM und ungefähr 35,27 % CPU. Das ist die kombinierte Anzeige von LM Studio zu diesem Zeitpunkt, nicht nur Modellgewicht oder nur VRAM.
Am Ende waren 2614 / 8192 Kontext-Token belegt, rund 31,9 %. Für diesen Lauf blieb der gewählte Kontext damit ausreichend.
Vor der Änderung von Max Concurrent Predictions wurde der Chat als Markdown exportiert, damit Antwort und Benchmark-Prompt separat erhalten bleiben.
Danach wurden Clear all messages und zusätzlich der komplette Delete-Ablauf dokumentiert. So wird der Chatverlauf zurückgesetzt und der nächste Lauf beginnt sauberer.
Bei Benchmarks sollte möglichst nur eine Variable geändert werden. Alte Nachrichten verändern Kontextgröße und Prompt-Verarbeitungsaufwand.
Im zweiten Lauf wurde nur Max Concurrent Predictions von 4 auf 1 reduziert. 8192 Kontext, 24 GPU-Offload, 6 CPU-Threads, 2048 Evaluation Batch, 512 Physical Batch, Unified KV Cache, Dedicated GPU Memory Limit und KV-Cache-GPU-Offload blieben gleich.
LM Studio beschreibt Max Concurrent Predictions als Anzahl parallel verarbeitbarer Prediction-Anfragen. Für einen einzelnen Desktop-Chat ist 1 berechenbar; bei mehreren API-Clients sollten höhere Werte auf Durchsatz geprüft werden.
Derselbe lange E-Commerce-Prompt wurde erneut mit Low Reasoning gesendet.
Context Length: 8192 GPU Offload: 24 CPU Thread Pool Size: 6 Evaluation Batch Size: 2048 Physical Batch Size: 512 Max Concurrent Predictions: 1 Unified KV Cache: ON Dedicated GPU Memory Limit: ON KV Cache -> GPU: ON Reasoning: Low
Während der zweiten Antwort zeigte RAM + VRAM erneut 11,61 GB, die CPU etwa 33,05 %. Am Ende wurden 11,14 Token/s, 2237 Output-Token und 1,78 s First-Token-Zeit angezeigt.
Der Unterschied von 10,85 auf 11,14 Token/s entspricht in dieser Sitzung rund 2,7 %. Da die zweite Antwort 2237 statt 2489 Token hatte, ist „Concurrent 1 ist immer 2,7 % schneller“ keine zulässige Verallgemeinerung.
Praktisch lief Concurrent 1 für den Einzelbenutzer stabil, mit etwas niedrigerer CPU-Anzeige und ohne Geschwindigkeitsverlust. Server mit mehreren Clients müssen parallelen Durchsatz separat testen.
Token/s misst die Geschwindigkeit der eigentlichen Ausgabe. Das ist nicht die vollständige wahrgenommene Antwortzeit, weil Prompt Processing, Reasoning und First-Token-Latenz hinzukommen.
LM Studio stellt Time to First Token separat bereit. 1,56 s oder 1,78 s sind daher nicht die Gesamtdauer für 2489 oder 2237 Token. Rein aus Output-Token geteilt durch Token/s ergeben sich ungefähr 229 bzw. 201 Sekunden Generierungszeit, ohne weiteren Overhead.
Die Kontextanzeige zeigt, wie viel des geladenen Kontextbudgets die aktuelle Unterhaltung belegt. Längere Verläufe erhöhen Prompt-Verarbeitung und Cache-Bedarf.
Nach den beiden Läufen blieb unser Einzelbenutzer-Profil bei 8192 Kontext, 24 GPU-Offload, 6 CPU-Threads, 2048 Evaluation Batch, 512 Physical Batch, Concurrent Predictions 1, Unified KV Cache an, Dedicated GPU Memory Limit an, KV-Cache-GPU-Offload an und Low Reasoning.
Dies ist kein universelles „bestes RTX-2070-Profil“. System-RAM, Treiber, LM-Studio-Runtime, Hintergrundprogramme und die konkrete Modelldatei können das Optimum verändern.
GPT-OSS unterstützt auch Medium und High Reasoning für schwierigere Mathematik-, Planungs- oder Coding-Aufgaben. In diesem Guide wurde nur Low gemessen; für andere Stufen werden keine erfundenen Werte angegeben.
Context: 8192 GPU Offload: 24 CPU Threads: 6 Evaluation Batch: 2048 Physical Batch: 512 Concurrent Predictions: 1 Unified KV Cache: ON Dedicated GPU Memory Limit: ON KV Cache GPU Offload: ON Reasoning Effort: Low
Der Benchmark-Prompt war bewusst breit und erzeugte Tausende Token zu PHP, MySQL, Redis, Queue, Backup und Sicherheit. Das eignet sich gut, um lange türkische technische Ausgabe zu beobachten.
LLM-Ausgaben können dennoch Versionskonflikte, unrealistische Kapazitätsangaben, fehlende Sicherheitsdetails oder unpassende Technologieentscheidungen enthalten. Die Screenshots zeigen daher Benchmark-Ausgabe und keine von OpenAI oder EKA Sunucu validierte Architektur.
Eine reale E-Commerce-Kapazitätsplanung muss auf Traffic, Query-Profilen, Datenmenge, Backup-Zielen, RPO/RTO, Zahlungsflüssen und Lasttests basieren.
Ja, in genau diesem Setup: GPT-OSS 20B erzeugte mit LM Studio 0.4.21 auf RTX 2070 8 GB und 63,84 GB RAM lange türkische technische Antworten. Gemessen wurden 10,85 und 11,14 Token/s.
Das Modell nutzt nicht nur 8 GB VRAM; die Verteilung von LM Studio auf GPU, CPU und System-RAM ermöglicht diese Konfiguration. Mit mehr VRAM, längerem Kontext oder mehreren gleichzeitigen Benutzern ist anderes Verhalten zu erwarten.
Für eigene Tests sollte derselbe lange Prompt fixiert, pro Lauf nur eine Einstellung geändert und Token/s, TTFT, Kontext, RAM/VRAM sowie CPU gemeinsam protokolliert werden.
GPU-Server für lokale LLM-Inferenz, Bildgenerierung und AI-Workloads mit höherem VRAM-Bedarf ansehen. Hardware nach Modellgröße, Kontextlänge und gleichzeitigen Benutzern planen.
GPT-OSS 20B ist ein von OpenAI veröffentlichtes Open-Weight-Mixture-of-Experts-Reasoning-Modell. Die offizielle Model Card nennt 20,9 Mrd. Gesamtparameter, 3,6 Mrd. aktive Parameter pro Token und 24 Layer.
In diesem Test zeigt LM Studio für die heruntergeladene GGUF-Datei 12,11 GB. Dateigröße und gesamter Laufzeitspeicher sind nicht identisch, da Kontext, KV-Cache, Runtime-Puffer und Betriebssystem zusätzlichen Speicher benötigen.
Das Modell lief auf einer RTX 2070 mit 8 GB, der PC hatte aber zusätzlich rund 64 GB System-RAM. Das Ergebnis bedeutet deshalb nicht, dass ausschließlich 8 GB VRAM genügen.
OpenAI gibt an, dass gpt-oss-20b auf Geräten mit etwa 16 GB Speicher laufen kann. Quantisierung, Kontext, Runtime und weitere Anwendungen verändern den tatsächlichen Bedarf.
Bei diesem Modell endet der Regler bei 24 Layern. Mit aktiviertem Dedicated-GPU-Memory-Limit weist LM Studio darauf hin, dass die tatsächliche Zahl ausgelagerter Layer abweichen kann.
LM Studio begrenzt damit Modellgewichte auf dedizierten GPU-Speicher und RAM; Kontext kann weiterhin Shared Memory nutzen. Laut LM Studio kann die Aufteilung zwischen VRAM und System-RAM schneller sein als Shared GPU Memory.
Die Einstellung steuert parallele Prediction-Anfragen. Für einen einzelnen Desktop-Benutzer ist 1 berechenbarer; für mehrere API-Clients sollten höhere Werte auf Durchsatz getestet werden.
In dieser Sitzung wurden mit 4 Concurrent Predictions 10,85 Token/s und mit 1 Concurrent Prediction 11,14 Token/s gemessen, rund 2,7 % Unterschied. Wegen unterschiedlicher Antwortlängen ist das keine allgemeine Garantie.
LM Studio stellt Time to First Token (TTFT) als eigene Inferenzmetrik bereit. Sie beschreibt die Zeit bis zum ersten Token, nicht die gesamte Dauer einer Antwort mit mehreren Tausend Token.
Low ist ein guter Ausgangspunkt, wenn geringe Latenz wichtig ist. GPT-OSS unterstützt zusätzlich Medium und High für schwierigere Aufgaben.
Nein. Der lange Architektur-Prompt dient als Benchmark-Workload. Architektur, Code und Kapazitätsangaben müssen vor Produktiveinsatz fachlich, sicherheitstechnisch und per Lasttest geprüft werden.
Vorherige Nachrichten verändern Kontext und Prompt-Verarbeitung. Der Chat wurde als Markdown exportiert, geleert und neu gestartet, um den zweiten Lauf möglichst sauber zu beginnen.
GPU-Server für lokale LLM-Inferenz, Bildgenerierung und AI-Workloads mit höherem VRAM-Bedarf ansehen. Hardware nach Modellgröße, Kontextlänge und gleichzeitigen Benutzern planen.
Aktualisiert: 16.08.2026 · LM Studio 0.4.21
Türkei (Türkisch)
Germany (German)
Worldwide (English)
