Connect with us

Künstliche Intelligenz

Interne Chats der DB: „Zug fällt zur Verbesserung der Statistik aus“


Ein Zug der ausfällt, kann sich nicht mehr verspäten: Offenbar eine Strategie, die bei der DB für eine bessere Pünktlichkeitsstatistik gefahren wird. So ist es zumindest in Nachrichten eines DB-internen Chats zu lesen, die dem Spiegel vorliegen. Jetzt räumt die DB ein: Die Chatnachrichten sind echt. Doch der Hintergrund sei ein anderer.

„Zug fällt zur Verbesserung der Statistik ab Köln aus“, war hier laut dem Bericht Anfang September zu lesen, als ein stark verspäteter ICE plötzlich in Köln endete – während die Bahn betroffene Fahrgäste wissen ließ, es handele sich um einen „kurzfristigen Personalausfall“. Bei einem anderen ICE mit Verspätung, der ebenfalls ungeplant in Köln endete, war in dem besagten Chat auch so eine Nachricht zu lesen. Sinn dieser Praxis soll sein, dass Zugausfälle nicht in der betrieblichen Pünktlichkeitsstatistik berücksichtigt werden.

Sie erfasst die Haltepunkte der Züge, die diese mit einer Verspätung von mindestens sechs Minuten erreichen. Im vergangenen Monat waren lediglich knapp 60 Prozent der Fernzüge pünktlich unterwegs. Ausgefallene Züge gehen nicht in diese Quote ein, bei Teilausfällen nur die Strecke, die der Zug bereits zurückgelegt hat.

Dagegen berücksichtigt werden sie bei der sogenannten Reisendenpünktlichkeit. Sie wird monatlich erhoben und misst den Anteil der Reisenden, die im jeweiligen Zeitraum pünktlich am Ziel ihrer Reise ankamen. Als pünktlich gilt ein Reisender bis zu einer Verzögerung von maximal 14 Minuten und 59 Sekunden. Im August lag diese Quote bei knapp 67 Prozent. Zugausfälle werden dabei berücksichtigt.

In Fällen wie den beiden vorliegenden lasse die Bahn die Züge danach oft leer durch die Gegend fahren, schreibt das Magazin unter Berufung auf einen ranghohen Mitarbeiter aus der DB-Disposition. In einem der beiden Fälle wurde der leere Zug demnach von einem anderen ICE an seinen eigentlichen Zielbahnhof gezogen.

Die Bahn räumte die Vorgänge ein. Bei dem Chat handele es sich um eine interne Plattform namens „BetriebLive“. „Über diese Plattform findet Austausch im Chat-Format statt, nicht jedoch Statistik-Erfassung.“ Die von einem Mitarbeiter gewählte Formulierung sei falsch. „Mit ihm ist bereits Kontakt aufgenommen worden“, hieß es. Warum der Mitarbeiter aber davon ausging, die Züge fielen zur Verbesserung der Statistik aus, sagte das Unternehmen nicht. Zu den Leerfahrten erklärt die Bahn, es seien „Überführungsfahrten“ und „fester Bestandteil des Eisenbahnbetriebs“. So solle sichergestellt werden, dass die Züge da sind, wo sie gebraucht werden.

Bei den vom Spiegel recherchierten Fällen sei es darum gegangen, auch die Verspätungen für andere Züge gering zu halten, äußert sich die Bahn in dem Spiegel-Bericht. „Daher ist es in beiden Fällen sinnvoll gewesen, die von Ihnen angesprochene dispositive Maßnahme umzusetzen“. Bei beiden Zügen hätten zudem „direkte und aufnahmefähige Alternativverbindungen“ bestanden, was „die Grundvoraussetzung für eine solche Maßnahme“ sei.


(nen)



Source link

Künstliche Intelligenz

Bericht: China soll funktionierendes EUV-Lithografie-System haben


China soll Anfang 2025 den ersten grundsätzlich funktionierenden Prototyp eines EUV-Lithografie-Systems fertiggestellt haben. EUV steht für extrem-ultraviolettes Licht, das mit einer Wellenlänge von 13,5 Nanometern feinste Transistorstrukturen in Silizium-Wafern ermöglicht.

Weiterlesen nach der Anzeige

Über das Projekt berichtet die US-Nachrichtenagentur Reuters, die laut eigenen Angaben mit diversen beteiligten Personen gesprochen hat. Sie gibt erstmals seit Jahren einen realistischen Einblick, wie weit Chinas Chipindustrie ist. Häufig gibt es nämlich Falschmeldungen, unter anderem aufgrund von Übersetzungsfehlern oder auch Propaganda mit vermeintlich neuartigen Lasertechnologien.

Bisher ist EUV-Lithografie die einzige Technik, um komplexe Chips ab der 5-Nanometer-Generation wirtschaftlich sinnvoll in Masse herstellen zu können (solche Halbleiter haben keine echten 5-nm-Strukturen; die Namen sind seit vielen Jahren nur noch Marketing). ASML aus den Niederlanden ist weltweit die einzige Firma, die EUV-Lithografie-Systeme in Serie herstellen kann, weil deren Aufbau so komplex ist.

Ein EUV-System kostet 160 Millionen bis 200 Millionen Euro. Systeme mit der nochmals verbesserten Technik High-NA EUV (EUV mit hoher numerischer Apertur) landen bei circa 350 Millionen Euro. Chinesische Firmen sind aufgrund von Exporteinschränkungen von allen EUV-Systemen abgeschnitten und bekommen nur noch ältere Typen, die mit tief-ultraviolettem Licht (Deep Ultraviolet, DUV), also einer Wellenlänge von 193 statt 13,5 Nanometern arbeiten.


High-NA-EUV-System von ASML von vorn

High-NA-EUV-System von ASML von vorn

Ein offenes High-NA-EUV-System von ASML. Selbst durchoptimiert ist diese Generation so groß, dass sie neue Halbleiterwerke mit höheren Decken erfordert.

(Bild: ASML)

Die Exporteinschränkungen funktionieren offenbar gut, denn selbst, wenn China an Systeme von ASML gelangt, sind sie ohne ASML-Support nicht viel wert. Ingenieure der Firma helfen etwa bei der Einrichtung und der regelmäßigen Wartung innerhalb der Halbleiterwerke.

Weiterlesen nach der Anzeige

Laut Reuters steht Huawei im Kern der chinesischen Halbleiter-Bemühungen: vom Chipdesign über die Fertigungsausrüstung bis hin zur Herstellung und endgültigen Integration in Produkte wie Smartphones soll die Firma beteiligt sein.

Huawei soll auch seit mindestens 2020 versuchen, im großen Stil ASML-Ingenieure abzuwerben, mit Fokus auf chinesische Mitarbeiter. Ein Team ehemaliger ASML-Mitarbeiter soll in China unter Falschnamen arbeiten, um das Projekt möglichst geheim zu halten. ASML hat zwar Verschwiegenheitsklauseln in den eigenen Verträgen, die sich in China jedoch kaum durchsetzen lassen. Zu den abgeworbenen Ingenieuren zählt angeblich Lin Nan, früher bei ASML als Leiter der Lichtquellentechnologie bei ASML in hoher verantwortlicher Position.

Mittels Reverse-Engineering und Bauteilen sowohl aus DUV- als auch aus EUV-Systemen von ASML soll China den eigenen Prototyp gebaut haben. Ohne das Wissen der abgeworbenen ASML-Ingenieure wäre das nicht möglich gewesen, zitiert Reuters eine Quelle. Rund 100 Studienabsolventen sollen zudem am laufenden Band ASML-Komponenten zerlegen und wieder zusammenbauen, um deren Aufbau zu verstehen.

Der aktuelle Prototyp soll noch krude aussehen und viel mehr Platz beanspruchen als ASMLs EUV-Systeme. Auch könne China noch keine funktionierenden Chips damit herstellen.

Ein Knackpunkt sind offenbar die benötigten optischen Bauelemente. Für einige notwendige Spiegel hat selbst ASML nur einen einzigen Zulieferer: Zeiss Semiconductor Manufacturing Technology (SMT) aus Deutschland. Stellt man sich einen runden EUV-tauglichen Spiegel wie die Oberfläche der Erdkugel vor, entspricht die größte Unebenheit einem Spielzeugauto auf der Erde. Chinesische Zulieferer sollen diese Reinheit bislang nicht replizieren können.

Interne Pläne sollen derweil vorsehen, dass chinesische Chipfertiger ab 2028 Halbleiter mit EUV-Lithografie herstellen. Das sehen laut Bericht allerdings selbst Projektbeteiligte nicht als realistisch an. Ein großes Problem: Die Hürde vom Prototypstatus zur Serienreife ist extrem hoch.

ASML hatte 2001 intern einen ersten funktionierenden Prototyp. 2006 begannen Installationen bei Forschungspartnern wie dem IMEC. Die ersten kommerziell nutzbaren EUV-Prozesse brachten 2018 beziehungsweise 2019 die asiatischen Chipauftragsfertiger Samsung mit 7LPP und TSMC mit N7+. In der Zwischenzeit wäre ASML beinahe das Geld ausgegangen. Heutzutage nutzen TSMC, Samsung, Intel und die Speicherhersteller SK Hynix sowie Micron EUV-Systeme von ASML in breiter Masse.

Selbst mit dem Vorwissen der abgeworbenen ASML-Ingenieure dürfte China noch einige Jahre benötigen, um eigene Lithografie-Systeme mit derart komplexer Technik serienreif zu bekommen. Und dann dürfte sich im Ausland schon High-NA EUV etabliert haben.


(mma)



Source link

Weiterlesen

Künstliche Intelligenz

Der beste Rechner für lokale KI, aber…


Sogenannte KI-Workstations wie Nvidias DGX Spark sind durch das Unified-Memory-Konzept gut für große lokale KI-Modelle geeignet. Diese Technik gibt es auch in Apple-Silicon-Macs und im direkten Vergleich arbeiten sie bei großen Sprachmodellen teils sogar schneller und extrem effizient. Bei Video- und Bildgenerierung sieht das anders aus. Wir haben zwei aktuelle Mac Studios gegen Nvidias DGX Spark und AMDs Strix Halo antreten lassen.

Weiterlesen nach der Anzeige

(Hinweis: Dieses Transkript ist für Menschen gedacht, die das Video oben nicht schauen können oder wollen. Der Text gibt nicht alle Informationen der Bildspur wieder.)

Guck mal hier, das bin ich, wie ich endlich mal KI-Zeug auf Apple-Rechnern teste. Und direkt Spoiler: Das große, sehr gute Modell gpt-oss-120B habe ich noch auf keinem Rechner, der hier auf meinem Schreibtisch stand, so schnell laufen sehen. Und da standen schon sehr viele und auch sehr teure. Interessant ist dabei: Ein Mac Studio M4 Max mit 128 GB geteiltem Speicher kostet mit knapp 4.200 Euro ungefähr genauso viel wie die Nvidia-DGX-Spark-Workstations, die mit gpt-oss-120B deutlich weniger Tokens pro Sekunde machen. Also Apple, denen man ja nachsagt, KI so ein bisschen zu verschlafen, performt viel besser als die OG-KI-Superfirma Nvidia mit ihrer KI-Workstation? Hä? Ja, beim Anzapfen von solchen großen Sprachmodellen wie gpt-oss-120B ist das auf jeden Fall ganz klar so. Aber bei anderen KI-Sachen, da sieht die Sache schon wieder ganz anders aus. Ich habe übrigens zusätzlich zu dem Mac Studio mit M4 Max auch noch einen M3 Ultra mit 512 GB RAM getestet und noch etliche andere Rechner. Bleibt dran, wird wirklich interessant.

Liebe Hackerinnen, liebe Internetsurfer, herzlich willkommen hier bei …

Wenn ihr euch fragt: lokale KI, ja, was soll das eigentlich bringen? Lokale KI ist super interessant, weil man da nicht mehr auf irgendwelche Anbieter aus USA oder China angewiesen ist, die vielleicht klammheimlich irgendwas ändern an den KI-Modellen. Stellt euch mal vor, ihr habt so in mühsamer Kleinarbeit komplexe Workflows auf ein bestimmtes KI-Modell in der Cloud angepasst, und dann nimmt der Anbieter das aus dem Angebot oder ändert das, und dann läuft euer Kram nicht mehr. Mit lokalen Modellen seid ihr komplett safe, weil die liegen ja bei euch auf der SSD. Problem ist nur: Diese sogenannten Open-Weights-Modelle, Open Source werden die auch manchmal genannt, aber das sind die so gut wie nie, weil man nämlich die Trainingsdaten nicht kennt. Also Open Weights, ich nenne die ab jetzt einfach lokale Modelle. Die waren lange Zeit ziemlich schlecht, aber die holen auf. Die sind auf jeden Fall noch nicht auf dem Stand der State-of-the-Art-Cloud-Modelle wie Gemini 3 oder GPT 5.2, aber man kann damit auf jeden Fall schon arbeiten. Das habe ich hier in diesem Video auch schon mal anschaulicher gezeigt, was man da so machen kann.

Und es gibt natürlich auch Bild- und Videogenerierungsmodelle, die auch lokal laufen und die ziemlich gut sind und die man zum Beispiel auch selbst feintunen kann. Die man also selbst anpassen kann, dass da wirklich der Stil rauskommt, den man gerne haben will. Ganz aktuell ist da zum Beispiel Flux.2 für Bilder aus dem Schwarzwald oder WAN 2.2. für Videos. Das Problem ist nur, und das gilt vor allem für die LLMs: Je besser die Modelle, desto mehr schnellen Speicher brauchen die meistens. Und der schnelle Grafikspeicher von Grafikkarten ist dafür zwar sehr gut geeignet, aber man kriegt im Bereich bis, sagen wir mal, 2.000 Euro für eine Grafikkarte nur maximal 32 GB. Mein aktuelles Open-Weights-LLM, gpt-oss-120B, braucht ungefähr 63 GB Speicher. Ja, schwierig. Und man kann natürlich auch normales RAM verwenden, also statt Grafikspeicher einfach DDR5-RAM, wenn man es sich leisten kann. Aber nur auf DDR5 läuft wirklich kein Modell brauchbar schnell. Seht ihr später auch in den Benchmarks, wie das läuft. Lahm.

Aber es gibt ja auch immer mehr Spezialrechner, die für KI ausgelegt sind. Zum Beispiel die kleine Nvidia-KI-Workstation DGX Spark, die es von etlichen OEMs gibt. Haben wir auch schon mal ein Video zu gemacht, von der Gigabyte-Version. Oder auch die AMD-Halo-Strix-Rechner, zum Beispiel Framework Desktop, da gab es auch schon mal ein Video dazu. Und die nutzen alle Unified Memory, also CPU- und GPU-Speicher sind geteilt und schneller angebunden als normaler, zum Beispiel DDR5-Speicher.

Weiterlesen nach der Anzeige

Das Ding ist aber, dass Apple dieses Unified-Memory-Konzept schon lange nutzt. Also seit der Einführung von Apple Silicon vor fünf Jahren, also vor dem KI-Hype. Apple-Silicon-Rechner sind wegen des schnellen Speichers zumindest theoretisch super geeignet für KI. Und auch in der Praxis gilt das so langsam, da wird nämlich immer mehr Software richtig gut angepasst. Also zum Beispiel die zum Abzapfen von Sprachmodellen, also zum Beispiel für so ChatGPT-artige Anwendungen. Bild- und Videogenerierung, ja, da kommen wir später noch zu.

Erst mal Sprachmodelle, zum Beispiel das erwähnte gpt-oss-120B. Ja, und das habe ich auf zwei Apple-Rechnern getestet: einmal auf dem Mac Studio M4 Max mit 128 GB gemeinsamem Speicher für 4174 Euro. Und einmal dem Mac Studio M3 Ultra mit 512 GB gemeinsamem Speicher für 11.674 Euro. Tatsächlich sind beides aktuelle Geräte, denn wenn ihr euch jetzt wundert: Hä, M3: ist das nicht alt? Ne, tatsächlich sind beides aktuelle Geräte, denn wenn man mehr als 128 GB haben will, gibt es kein Gerät mit M4 Max, sondern dann gibt es nur den M3 Ultra. Und Ultra bedeutet in diesem Fall, dass da zwei M3-Einheiten zusammengebacken wurden, das nennt Apple Ultra Fusion. Ja, und obwohl die M4-Generation eine bessere Speicherbandbreite hat, nämlich beim M4 Max 546 GB/s, kriegt man mit dem M3 Ultra trotzdem mehr, weil es sind ja zwei M3-Einheiten, was hier insgesamt 819 GB/s entspricht.

Und was habe ich da nun genau drauf getestet? Ja, drei Sprachmodelle: ein ganz kleines Qwen3-4B, Q4 quantisiert, 2,5 GByte groß, ein mittleres Mistral Small 3.2 24B, auch Q4 quantisiert, das ist 15,2 GByte groß, und ein recht großes gpt-oss-120B mit im MXFP4-Format, 63,4 GByte groß.

So, und ich habe ja bislang die Benchmarks mit LM Studio manuell gemacht. Aber da haben mehrere Leute angemerkt, dass man noch ein bisschen mehr Tokens pro Sekunde mit der llama.cpp-Bibliothek rausholen kann. Die wird zwar von LM Studio intern auch verwendet, aber ist da trotzdem oft langsamer. Außerdem ein großer Vorteil: llama.cpp hat auch einen Benchmark eingebaut, und der differenziert zwischen dem Verstehen des Prompts, also dem Prompt Processing, PP oder Prefill, und der reinen Inferenz, also Decode oder Token-Generation, TG. Ja, und weil ich letzte Woche mehr Zeit hatte als sonst, weil ja kein Video kam, bin ich da richtig reingegangen und habe auf sechs unterschiedlichen Plattformen nicht nur llama.cpp installiert, also über die vorkompilierten Binarys, sondern ich habe llama.cpp auf jeder der Plattformen mit möglichst optimalen Compiler-Flags kompiliert. Das macht keinen riesigen Unterschied, aber bei meinem Test konnte ich da schon ein paar Prozent nachweisen, also im Vergleich zu den einfach runtergeladenen Binarys. Man kann mir also auf jeden Fall nicht vorwerfen, dass ich hier nicht fair getestet habe.

Und jetzt endlich die Ergebnisse, worauf ihr wahrscheinlich schon die ganze Zeit wartet: Tatsächlich haben mit gpt-oss-120B die beiden Apple-Rechner die besten Prompt-Processing-Ergebnisse erzielt, die ich jemals gemessen habe, mit gpt-oss-120B: 86 und 82 Token pro Sekunde. Also wie erwartet etwas mehr beim M3 Ultra, weil höhere Speicherbandbreite als beim M4 Max. Aber eigentlich ist der M4 Max die eigentliche Überraschung, weil der beim Generieren nur eine Leistungsaufnahme von 120 Watt hatte. Und 82 Token pro Sekunde bei 120 Watt, das ist wirklich krass effizient. Der M3 Ultra braucht fast das Doppelte, aber ist immer noch viel effizienter als die Konkurrenz. Also richtig doll ineffizient ist mein Desktop-Rechner mit zugeschalteter RTX4090-Grafikkarte. Der macht tatsächlich 14-mal weniger Token pro Watt als der M4 Max. Die beiden Spezialrechner mit Nvidia DGX Spark und AMD Strix Halo, die liegen im Mittelfeld. Bei den kleineren Modellen, die halt in den superschnellen Videospeicher meiner Grafikkarte passen, ja, da kommen M3 Ultra und M4 Max nur auf Platz 2 und 3. Ich habe übrigens, wie am Anfang schon erwähnt, testweise mal die GPU deaktiviert und geguckt, wie weit man nur mit der CPU kommt. Nicht weit, bei allen den drei Sprachmodellen schon sehr langsam, wie ihr hier sehen könnt.

Achtung, Achtung, jetzt kommt ein kurzer Super-Nerd-Einschub, geht gleich wieder nochmal weiter.

Ja, ich weiß, llama.cpp nutzt GGUF-Modelle. Bei Apple kann man ja auch MLX mit vorkonfigurierten MLX-Modellen verwenden. MLX ist das Apple-Machine-Learning-Framework, also quasi der PyTorch-Konkurrent. Ich habe das mit LM Studio getestet, und tatsächlich waren da meine Ergebnisse mit gpt-oss-120B mit MLX schlechter als mit llama.cpp. Und MLX lief auch auf dem M4 Max mit gpt-oss-120B auch gar nicht, sondern nur mit GGUF. Bei den kleineren Modellen war MLX aber tatsächlich ein ganzes Stück schneller, siehe hier meine Werte. Also das solltet ihr tatsächlich bedenken, und das ist auch die Erklärung dafür, dass LM Studio auf macOS bei den meisten Modellen immer beide Varianten, also GGUF oder GGUF und MLX, anbietet. Nerd-Einschub ist vorbei.

So, das war jetzt alles die Token-Generation. Jetzt kommt noch kurz das Prompt Processing, wo es weniger auf die Speicherbandbreite ankommt. Jetzt ist der M3 Ultra zumindest mit dem großen Sprachmodell gpt-oss-120B immer noch Spitzenreiter. Bei den kleineren Modellen, da gewinnt ganz klar wieder die Nvidia-Grafikkarte, und auf dem zweiten Platz ist der Nvidia-DGX-Spark-Rechner. Einfach weil die Nvidia-Kerne mehr rohe Compute-Pferdestärken mitbringen.

So, aber es gibt ja nun auch noch andere KI-Anwendungsbereiche als LLMs, zum Beispiel Bild-, Videobearbeitung, Generierung und so weiter. Das machen die meisten Menschen heutzutage wohl mit ComfyUI, dieser node-basierten Open-Source-Software. Hier gelten Nvidia-GPUs als de-facto Standard, einfach weil das alles sehr CUDA-fokussiert ist, also CUDA, die Nvidia-exklusive Programmierschnittstelle. Ich war deshalb schon ziemlich positiv überrascht, dass ich auf der ComfyUI-Website direkten macOS-Installer für die Desktop-Variante gefunden habe. Da habe ich mich auf mehr Frickeln eingestellt, und es lief alles super, also zumindest die Installation. Aber als ich dann für meine Tests einfach mal das Flux.2-Template aufgerufen habe und die Modelle runtergeladen hatte, bekam ich dann einfach ganz lapidar diese Fehlermeldung. Ja, und stellt sich raus: Apple Silicon kann nicht mit FP8 umgehen, also dem 8-Bit-Gleitkomma-Format, in dem aber dummerweise so gut wie alle ComfyUI-Modelle vorliegen. Also sowohl für Bildgenerierung als auch für Videogenerierung. Man kann sich damit behelfen, Modelle im FP16-Format zu verwenden, aber das verbraucht deutlich mehr Speicher und ist auch langsamer als FP8. Also wenn man denn auch ein FP16-Modell überhaupt findet. Also man will, also ich will das, auch vielleicht einfach nur die Templates anklicken, und dann funktioniert das, und will da jetzt nicht in den Nodes dann noch so viel rumfummeln. Na ja, bei einigen Workflows reichte das in meinen Tests auch einfach aus, in der Konfiguration von ComfyUI einfach auf FP16 hier umzuschalten. Aber auch nicht immer. Na ja, ich habe auf jeden Fall Flux-Dev stabil laufend bekommen und konnte da die Geschwindigkeit messen. Ja, die Geschwindigkeit auf dem Max war nicht berauschend. Ganz grob kann man sagen: 110 Sekunden für ein Standard-Preset-Flux-Dev-Bild auf dem M4 Max. 65 Sekunden hat der M3 Ultra gebraucht. 35 Sekunden, zum Vergleich, die DGX Spark und nur 12 Sekunden meine RTX 4090.

Und ja, mit Videos fange ich gar nicht erst an, das ist alles noch frickeliger gewesen. Und leider haben bei den ComfyUI-Standard-Workflows auch der riesige Speicher der Apple-Rechner keine Vorteile. Einfach weil die Modelle, die ich da gesehen habe und die ich so kenne, also auch die Videogenerierungsmodelle, die sind so gut wie alle für Grafikkarten-Speichergrößen optimiert. Ja, meistens so im Bereich bis 16 GB, ganz selten mal zwischen 16 und 24 GB.

Also auf jeden Fall: Wenn man hauptsächlich ComfyUI-Sachen machen will, dann ist man mit einem dieser Apple-Rechner nicht wirklich gut bedient. Aber ganz wichtig: Das kann sich natürlich alles ändern. Es sind ja jetzt auf jeden Fall schon Anflüge von einem Aufbrechen des CUDA-Monopols zu spüren. Warten wir das mal ab. Als reine LLM-Abzapfmaschine sind die Mac Studios und eigentlich alle Macs mit genügend Speicher beeindruckend gut geeignet. Und eine Eins mit Sternchen kriegen die wirklich in Sachen Effizienz. Will man allerdings nur Modelle laufen lassen, die in den Speicher einer normalen Grafikkarte passen, also maximal 32 GB, dann fährt man nach wie vor günstiger und meistens auch schneller mit einem x86-Rechner mit einer dedizierten Grafikkarte.

Aber bei Modellen wie gpt-oss-120B mit 63 GB, und meiner Meinung nach fängt das in diesen Speicherbereichen oft erst an, wirklich interessant zu werden, dann gibt es zurzeit nichts Besseres als ein Mac. Also auch in Sachen Preis-Leistung. Also zumindest, wenn man einfach was kaufen will. Klar, man kann sich irgendwelche krassen Rechner frankensteinen mit gebrauchten Grafikkarten, aber das gibt es auf jeden Fall nicht von der Stange. Zumindest nicht zu den Preisen.

Bei anderen KI-Anwendungen als LLMs, ja, also zum Beispiel bei ComfyUI, ja, da ist man auf jeden Fall immer noch mit Nvidia-Hardware besser und vor allem auch unkomplizierter bedient. Mit AMD-Hardware ist es fast noch schwieriger als mit Apple-Hardware. Aber wer weiß, wie lange das alles noch so ist.

Leider, und das muss ich auch sagen, habe ich jenseits von gpt-oss-120B, also jenseits der 63 GB, keine Sprachmodelle gefunden, die deutlich besser sind, also für die sich jetzt 128 oder sogar 512 GB lohnen würden. So Sachen wie DeepSeek und Kimi K2, die sind auf jeden Fall besser, aber die brauchen halt noch mehr als 512 GB. Da muss man dann vielleicht mal mit so Clustern rumexperimentieren. Habe ich schon auf der To-do-Liste, das kommt bald, eventuell. Aber wir wissen auf jeden Fall: In der KI-Welt kann alles sehr schnell gehen. Mal sehen, was sich da in den nächsten Monaten tut. Tschüss!

c’t 3003 ist der YouTube-Channel von c’t. Die Videos auf c’t 3003 sind eigenständige Inhalte und unabhängig von den Artikeln im c’t Magazin. Die Redakteure Jan-Keno Janssen, Lukas Rumpler, Sahin Erengil und Pascal Schewe veröffentlichen jede Woche ein Video.


(sahe)



Source link

Weiterlesen

Künstliche Intelligenz

Hubble erfasst Kollision von zwei Himmelskörpern in relativ nahem Sternsystem


Das Weltraumteleskop Hubble hat mutmaßlich den Zusammenprall zweier Himmelskörper im System des Sterns Fomalhaut detektiert – und das schon zum zweiten Mal in zwei Jahrzehnten. Wissenschaftler glaubten bisher, dass solche Ereignisse deutlich seltener stattfinden.

Weiterlesen nach der Anzeige

Fomalhaut ist ein Stern im Sternbild Piscis Austrinus oder Südlicher Fisch und einer der hellsten Sterne am Himmel. Der nur etwa 25 Lichtjahre entfernte Stern ist mit 440 Millionen Jahren noch vergleichsweise jung – die Sonne ist etwa 4,57 Milliarden Jahr alt. Fomalhaut gehört mit zwei Zwergsternen einem Dreifachsystem an, das von Staubringen umgeben ist, in denen Planeten entstehen.

2004 und 2006 entdeckten Astronomen ein Objekt in einem dieser Gürtel, das sie für einen Exoplaneten hielten und das sie als Fomalhaut B bezeichneten. 2023 wollten sie den Planeten erneut mit dem Hubble-Teleskop betrachten, stellten aber fest, dass er nicht dort war, wo sie ihn erwarteten.

Sie fanden aber einen Lichtpunkt an einer anderen Stelle, nahe der ersten. Beim Vergleich der Bilder habe sich jedoch gezeigt, dass die beiden Lichtpunkte nicht aus derselben Quellen stammen konnten, sagte Jason Wang von der Northwestern University. Sie haben Fomalhaut b umbenannt in Fomalhaut Circumstellar Source 1 (CS1), der zweite Lichtpunkt hat die Bezeichnung Fomalhaut CS2 bekommen.

Die Forscher erklären das Auftreten und das Verschwinden der Lichtpunkte als Trümmerwolken, die durch die Kollision von Planetesimale, also Bausteinen von Planeten, entstanden. Aus der Helligkeit der Lichtpunkte CS1 und CS2 schlossen sie, dass die kollidierten Objekte selbst um die 60 Kilometer groß gewesen sein müssen – und damit zu klein, um selbst auf den Bildern des Weltraumteleskops sichtbar zu sein. Die sich ausbreitenden Trümmerwolken hingegen werden vom Zentralgestirn angeleuchtet.

„Eine neue Lichtquelle im Staubgürtel, um einen Stern zu entdecken, hat uns überrascht. Das hatten wir nicht erwartet“, sagte Wang. „Unsere Hypothese ist, dass wir innerhalb von zwei Jahrzehnten zwei Kollisionen von Planetesimalen – kleinen Gesteinsobjekten, ähnlich wie Asteroiden – beobachtet haben. Kollisionen von Planetesimalen sind sehr seltene Ereignisse, und das ist das erste Mal, dass wir eine außerhalb unseres Sonnensystems gesehen haben.“

Die Forscher waren zudem erstaunt, dass sie in etwa 20 Jahren gleich zwei solcher Kollisionen beobachtet haben: „Laut der Theorie sollte eine solche Kollision einmal in 100.000 Jahren oder noch seltener auftreten“, sagte Paul Kalas, Astronom an der University of California in Berkeley und Erstautor der Studie in der Fachzeitschrift Science. Die zwei Sichtungen in 20 Jahren könnten seiner Ansicht nach Zufall gewesen sein, oder die theoretischen Modelle müssten angepasst werden.

Weiterlesen nach der Anzeige

Die Forscher wollen das Fomalhaut-System künftig mit dem James-Webb-Weltraumteleskop betrachten und erhoffen sich davon neue Erkenntnisse über CS 2 sowie über die Beschaffenheit der kollidierten Planetesimalen – und möglicherweise auch, neue Kollisionen zu beobachten.


(wpl)



Source link

Weiterlesen

Beliebt