1\section{Introduction}2\label{sec:intro}34High-frequency financial econometrics is computationally repetitive in a particular way. The same small estimator---a sum of squared returns, a bipower product, a four-regressor regression, a GARCH recursion---is evaluated on thousands of series, thousands of days, and thousands of bootstrap or Monte Carlo replicas. The established toolchains that practitioners trust for correctness (\texttt{highfrequency} in R, \citealp{BoudtKleenSjorup2022}; \texttt{rugarch}, \citealp{Ghalanos2024rugarch}; \texttt{arch} and \texttt{statsmodels} in Python, \citealp{Sheppard2025arch,Seabold2010}) are organised around one series at a time and double-precision CPU arithmetic. Meanwhile the hardware on most researchers' desks has changed: Apple Silicon machines couple a multicore CPU with a wide GPU in a single unified memory space. The GPU, however, has no 64-bit floating-point unit \citep{AppleMetal2026}, and econometric estimators are not obviously tolerant of single precision.56This paper studies whether that hardware can be used for high-frequency econometrics \emph{without} giving up what makes the established toolchains trustworthy: estimator accuracy, valid inference and reproducibility. We frame the question as three falsifiable research questions and build the software needed to answer them.78\begin{description}[leftmargin=1.2em]9\item[RQ1 (break-even).] At what data and batch sizes does Metal beat an optimised multicore CPU once I/O, shader compilation, synchronisation and host--device transfer are counted?10\item[RQ2 (batching and inference).] Does batched estimation raise throughput while preserving coverage, convergence and the numerical agreement with FP64 references?11\item[RQ3 (pipeline).] Can an Arrow/Parquet-to-estimator pipeline materially reduce copies, memory pressure and end-to-end latency relative to the columnar engines researchers use today?12\end{description}1314\raid{} (Research Architecture for Intraday Data) is the instrument: an open C++20 library with (i) an FP64 CPU backend that serves as the reference implementation of every method, (ii) an optional Metal backend in which every accumulator is carried as a compensated double-float pair \citep{Dekker1971,Neumaier1974} and chunked partial sums are combined in FP64 on the CPU, (iii) a method registry that pins the exact convention of each estimator and the reference software it is compared with, (iv) nanobind Python bindings and a command-line tool, and (v) a secure client for the FinData~OS lakehouse that serves FirstRate Data 1-minute bars with dataset versions, request identifiers and checksums.1516Our contributions are deliberately engineering and measurement contributions, not new econometric methodology. First, a precision strategy for FP32-only GPUs that keeps realized measures within $10^{-6}$ of FP64, regression sufficient statistics within $10^{-6}$ and GARCH likelihoods within $2\times10^{-5}$, with bitwise reproducibility. Second, a validation protocol: every Tier~A method is compared with at least one established implementation under identical conventions, with tolerances recorded in the registry and reproduced by the test suite. Third, a benchmark protocol with randomised order, warm-ups, repeated measurements, bootstrap confidence intervals of medians, explicit cold and cached shader compilation, and manifests recording hardware, compiler, load and thermal state. Fourth, measured answers to RQ1--RQ3 on an M5~Max laptop and on eleven Apple Silicon generations, including the cases where the CPU wins.1718The remainder of the paper is organised as follows. Section~\ref{sec:lit} positions the work relative to the econometric and systems literatures. Section~\ref{sec:arch} describes the architecture and API, Section~\ref{sec:est} the estimator definitions and conventions, Section~\ref{sec:metal} the Metal execution and precision strategy, Section~\ref{sec:correct} the statistical correctness evidence. Sections~\ref{sec:setup}--\ref{sec:apps} present the experimental setup, microbenchmarks, end-to-end benchmarks and financial applications. Sections~\ref{sec:threats}--\ref{sec:concl} discuss threats to validity, reproducibility and licensing, and conclude.19