Helldez/BigMoeOnEdge

Two gaps in Apple support, one small and one large. Both are open to contributors, and both need a measurement, not just code. 1. macOS never bypasses the page cache core/src/io/platform_io.cpp defines O_DIRECT to 0 when the platform lacks it, which on Apple means open_read(..., direct=true) silently returns an ordinary buffered descriptor. The equivalent there is fcntl(fd, F_NOCACHE, 1) after the open, and it is never called. So on a Mac the expert stream reads through the page cache, which is precisely what the design exists to avoid. Second half of the same problem: the o_direct metrics field is filled from the requested configuration, so a macOS run reports o_direct=1 while running buffered. The field should record what the open actually achieved, on every platform. That half is worth fixing on its own, even if nobody touches the macOS path. What a PR needs F_NOCACHE applied on Apple where O_DIRECT would be used elsewhere, without disturbing the Linux, Android or Windows paths. o_

All the numbers in the README come from one phone and one laptop. That's the honest limit of what we can claim, and it's why we're asking. The engine streams a MoE model's experts from flash so a model larger than RAM runs on the device. What we'd like to know is what that does on storage and CPUs we don't have: a mini PC with an NVMe drive, an ARM board with a PCIe slot, a Mac, a desktop with a lot of unified memory, a phone other than ours. Anything works, really. The open question is whether a real NVMe queue makes the flash stall we see on UFS go away, but every machine adds a data point. Any MoE the engine supports, in whatever quant you already have. Paste the result into a benchmark report and the row goes into docs/community-benchmarks.md with your name. On a PC or laptop (Linux, macOS) One command, about ten minutes after the model download: git clone --recursive https://github.com/Helldez/BigMoeOnEdge.git cd BigMoeOnEdge scripts/bench-report.sh /path/to/any-moe-model.gguf It