Die Speicherhierarchie des Conroe war extrem einfach und Intel konnte sich auf die Leistung des geteilten L2-Cache konzentrieren, was die beste Lösung für eine Architektur war, die hauptsächlich auf die Dual-Core-Implementierungen abzielte. Aber mit Nehalem haben die Ingenieure wieder bei null angefangen und sind zu den gleichen Schlussfolgerungen gekommen wie ihre Konkurrenten: Ein geteilter Cache auf zweiter Ebene war für eine native Quad-Core-Architektur nicht geeignet: Die verschiedenen Kerne konnten die für einen anderen notwendigen Daten zu häufig verdrängen und es ist wahrscheinlich, dass dies auf der Ebene des internen Bus und der Arbitration zahlreiche Probleme stellte, die vier Kerne mit einer ausreichenden Bandbreite zu versorgen und dabei eine ausreichend niedrige Latenz zu bewahren. Um diese harte Nuss zu knacken, haben die Ingenieure dann die verschiedenen Kerne mit einem privaten Cache-Speicher auf zweiter Ebene ausgerüstet. Da dieser nur für einen einzigen Kern gedacht und relativ klein (256 KB) ist, konnten die Ingenieure ihn extrem leistungsstark machen. Insbesondere die Latenz sei im Vergleich zum Penryn von 15 Zyklen auf ca. 10 Zyklen deutlich verbessert worden.

Man findet dann noch einen riesigen Cache-Speicher der dritten Ebene (8 MB) vor, um die Kommunikation zwischen den Kernen zu verwalten. Wenn die Cache-Hierarchie des Nehalem auf den ersten Blick an die des Barcelona erinnert, so unterscheidet sich die Funktionsweise des Cache auf der dritten Ebene sehr von der seines Konkurrenten: Er umfasst nämlich alle Ebenen der vorangehenden Caches. Das bedeutet, dass wenn ein Kern versucht, auf Daten zuzugreifen und diese Daten sich nicht im Cache der Ebene 3 befinden, es unnötig ist, sie in den privaten Caches der anderen Kerne zu suchen: Diese Daten müssen sich dort jedoch nicht unbedingt finden lassen. Wenn diese Daten jedoch da sind, geben vier mit jeder Zeile des Speichercache verbundene Bits (ein Bit pro Kern) an, ob die Daten potentiell im Cache einer tieferen Ebene eines anderen Kerns präsent sind und in welchem.

Diese Technik ist effizient, um die Kohärenz der privaten Caches sicherzustellen und den Datenverkehr zwischen den Kernen zu begrenzen, aber ihr Nachteil ist, dass sie einen Teil des Cachespeichers mit Daten vergeudet, die bereits auf anderen Ebenen präsent sind. Das wird jedoch dadurch in Grenzen gehalten, dass die L1- und L2-Caches im Vergleich zum L3-Cache relativ klein sind und die Gesamtheit der L1- und L2-Daten nur maximal 1,25 MB von 8 MB belegen. Genau wie auf dem Barcelona arbeitet der Cache der Ebene 3 nicht mit der gleichen Frequenz wie der restliche Chip und folglich ist die Zugriffslatenz auf dieser Ebene variabel, sollte aber im Bereich von 40 Zyklen liegen.

Letzten Endes ist die einzige Enttäuschung bei der neuen Cache-Hierarchie des Nehalem der Cache der ersten Ebene. So wurde die Durchlassbreite des Anweisungscaches nicht vergrößert. Sie beträgt immer noch nur 16 Bytes pro Zyklus im Vergleich zu 32 beim Barcelona. Das könnte sich für eine serverorientierte Architektur als Engpass erweisen, da 64-Bit-Anweisungen voluminöser sind als 32-Bit-Anweisungen. Hinzu kommt auch noch, dass der Nehalem einen Decoder mehr als der Barcelona hat, was noch mehr Druck auf den Cache ausübt. Der Datencache seinerseits verzeichnet eine Erhöhung seiner Latenz auf vier Zyklen im Vergleich zu drei beim Conroe, um eine höhere Taktfrequenz zu erzielen. Um zum Schluss noch einen positiven Punkt zu erwähnen: Die Ingenieure von Intel haben die Anzahl der Cachefehler der ersten Ebene erhöht, die ihre Architektur parallel verarbeiten kann.