SearcharxivSearch

arXiv subjects

Hannah Atmer

Publications and source records attributed to Hannah Atmer.

3 recordsLinked to original sources

Who Needs DRAM? We Have Fiber

The rising pressure on DRAM availability and contract pricing reflects generative AI's massive high-performance memory requirements. This pressure is heavily compounded by hyperscale data center expansion, which now consumes a significant portion of global DRAM output. In this work, we propose a new architecture: Fiber Memory, which reimagines the role of optical fiber in a hyperscale data center, deploying it as an active, recirculating delay-line memory for immutable data, such as large language model weights. We present a data-parallel optical broadcast delay-line memory architecture that accounts for fiber's physical realities. By incorporating space-division multiplexed multi-core fibers, passive optical tap-and-amplify interfaces, co-packaged optics, and regional all-optical regeneration, our case study evaluation suggests that Fiber Memory can eliminate redundant weight storage across 10,000 AI accelerators and reduce weight-delivery energy by over 70% compared to traditional HBM3e configurations.

cs.AR

Prefill vs. Decode Bottlenecks: SRAM-Frequency Tradeoffs and the Memory-Bandwidth Ceiling

Energy consumption dictates the cost and environmental impact of deploying Large Language Models. This paper investigates the impact of on-chip SRAM size and operating frequency on the energy efficiency and performance of LLM inference, focusing on the distinct behaviors of the compute-bound prefill and memory-bound decode phases. Our simulation methodology combines OpenRAM for energy modeling, LLMCompass for latency simulation, and ScaleSIM for systolic array operational intensity. Our findings show that total energy use is predominantly determined by SRAM size in both phases, with larger buffers significantly increasing static energy due to leakage, which is not offset by corresponding latency benefits. We quantitatively explore the memory-bandwidth bottleneck, demonstrating that while high operating frequencies reduce prefill latency, their positive impact on memory-bound decode latency is capped by the external memory bandwidth. Counter-intuitively, high compute frequency can reduce total energy by reducing execution time and consequently decreasing static energy consumption more than the resulting dynamic power increase. We identify an optimal hardware configuration for the simulated workload: high operating frequencies (1200MHz-1400MHz) and a small local buffer size of 32KB to 64KB. This combination achieves the best energy-delay product, balancing low latency with high energy efficiency. Furthermore, we demonstrate how memory bandwidth acts as a performance ceiling, and that increasing compute frequency only yields performance gains up to the point where the workload becomes memory-bound. This analysis provides concrete architectural insights for designing energy-efficient LLM accelerators, especially for datacenters aiming to minimize their energy overhead.

cs.AR

Front-Running Protection for Distributed Exchanges using Tamper-Resistant Round Trip Time Measurements

In this paper we present ODIN, a front-running protection system that uses a novel algorithm to measure Round-Trip-Time (RTT) to untrusted servers. ODIN is the decentralized equivalent of THOR, a RTT-aware front-running protection system for trading on centralized exchanges. Unlike centralized exchanges, P2P exchanges have potentially malicious peers which makes reliable direct RTT measurement impossible. In order to prevent tampering by an arbitrarily malicious peer, ODIN performs an indirect RTT measurement that never interacts directly with the target machine. The RTT to the target is estimated by measuring the RTT to a randomized IP address that is known to be close to the target's IP address in the global routing network. We find that ODIN's RTT estimation algorithm provides an accurate, practical, and generic solution for collecting network latency data in a hostile network environment.

cs.DC