# torch is deliberately NOT pinned or listed. # # On ZeroGPU the CUDA build must match the platform's driver, and the Space image already provides # a matching one; asking pip for a different torch - in particular the cpu-only wheel that keeps a # non-GPU Space small - is the usual way a Space that works in a notebook fails on hardware. # # gradio is absent for the same class of reason: the Space installs the version pinned as # `sdk_version` in README.md, and listing it here as well is how the two end up disagreeing. # Leaving it unpinned in both places is what broke the first deploy - HF fell back to a gradio 3.x # default with no `show_copy_button`. # # llama-cpp-python is deliberately ABSENT, and the CPU runtime in `mimo.py` is therefore dormant # on this Space. Both ways of installing it were tried and both fail here: # # 1. abetlen's prebuilt wheel index. Those wheels are tagged plain `linux_x86_64` rather than # `manylinux`, and they are linked against musl. pip installs one happily and then every # import dies with `libc.musl-x86_64.so.1: cannot open shared object file`, because a Space # runs on glibc. # 2. the PyPI sdist, which is the only other option since PyPI publishes no binary wheel at all. # Compiling llama.cpp from source exceeded the Space build limit outright: `Job timeout`. # # The code path stays in `mimo.py` so the app still runs on a machine that does have a working # llama.cpp, but nothing here installs one. On this Space the GPU path is the only runtime, which # is also the one that reproduces Part B exactly - so the loss is a fallback, not a capability. spaces # the @spaces.GPU decorator; ZeroGPU refuses to serve a Space without one transformers>=4.45 accelerate # device_map for the 4-bit load bitsandbytes # the NF4 quantisation Part B measured sentencepiece einops # nomic-embed-v1.5's remote code imports it sentence-transformers>=3.0 huggingface_hub>=0.23 numpy pandas pyarrow # read the Part A embedding index