You are helping set up local Qwen3.8-27B on my Mac. I have the qwen27b-minimal.zip archive and the article describing the experiment. Perform the setup rather than only offering advice. First read README.md and the archive configuration.

The archive contains a patch, scripts and a local monitor; it contains neither weights nor a ready binary, which must be downloaded and built separately. After extraction, checksums and a dry run without a model were checked; a complete installation from scratch and long test of this exact minimal archive have not yet been confirmed. First check SHA256SUMS.txt, then record your own check results separately. By default the API and monitor are available only on this Mac. After checks, run.py may temporarily stop idle MTPLX on port 8000 and then try to restore it; tell me beforehand and do not stop busy or unverified processes.

The goal is to reproduce the described Kapitsa build and test it on my Mac. The original experiment used an M4 Max with 36 GB RAM. Record my chip, RAM, macOS, free disk space and installed tools. If the computer differs substantially, do not promise the same speed; suggest a suitable window and memory limit and explain the differences. If information is sufficient, make decisions yourself.

Build the engine from the specific Kapitsa commit and source.patch in the archive. Download the pinned Qwen3.8-27B-MTPLX-Bare-Speed Q4 and incoai/Qwen3.8-27B-DFlash2 using download_models.py; if compatible weights already exist on disk, use --model-dir and check their hashes first. Weights are downloaded separately; do not substitute another model or patch version without explanation. The package allows using my existing weights without overwriting them.

Run the dry check, start the server and connect a local OpenAI-compatible client. Before stopping or restarting any running server, tell me in advance; do not terminate other people's or busy processes. If a port is occupied, find out by what and stop if the required ports cannot be used safely. Do not delete existing applications' data, projects or settings. Do not print or transmit API keys or my file or log contents to third parties. For measurements using my project files, process them locally and do not modify them.

Check a short request and the monitor, then perform cold and repeated measurements at suitable context sizes. For each, report actual input tokens, tokens from cache, tokens recomputed, prefill time and generation time. Do not assess generation speed from an answer of 1–2 tokens. Compare identical inputs and parameters; distinguish native tok/s from an approximate window value. Test multiple turns, tool calls and cancellation. If the client changes the start of the history, explain the unavoidable recomputation.

Treat the article's profile as experimental: Q4 weights, Q8 KV cache, approximate prefill and DFlash2. All tokens are retained, but the restricted attention mask changes computation; dense decode does not make this prefill exact. The previous experiment includes a long test with an error and has no proven 1–2% quality-loss bound. Do not present 255/30 tok/s as guaranteed. Compare quality against a suitable control profile on my test tasks, recording errors and results separately; do not call matching results on a couple of tasks a general guarantee.

Test retrieval of multiple random facts at different depths and several context lengths; state how depths were measured and how many separate requests were made. If desired, test RULER and LongBench v2 following their authors' instructions: record the sample, template, response limit, scoring method and results for each task. Do not present a partial or adapted check as a complete official result. Do not execute generated code without suitable isolation and resource limits.

For cache, separately test a cold request, continuation, addition of new data and a change to an early part of context. Record time to first token and matching cached volume; check that the model does not return the old value after the change. If experimenting with SpecPrefill, measure selection time and main-model cache reuse separately. Do not call selected fragments a complete KV cache.

By default leave the API and monitor on localhost. Enable home-network access only if I ask: configure the correct private subnet and a new key, do not print it in logs or expose the service to the Internet. Test access and protection. Finally report the address, actual model, measured speeds, quality-test results, differences from the article and all remaining limitations. If something failed, show exactly where and what can be reproduced.