Qwen 3.6 Local Deployment in Practice: 35B Model Reverse-Engineers LTE Modem, Beating Claude

The Real Litmus Test for Local LLM Coding Ability

When it comes to the coding capabilities of local large language models, most benchmarks stop at "write a Snake game" or "build a TODO app." But when the task is reverse-engineering an LTE modem's web portal—extracting login logic and signal data from thousands of lines of obfuscated JavaScript—that's where models are truly put to the test.

After three consecutive video episodes of testing, one developer completed this challenge using Qwen 3.6 35B (A3B MoE architecture), while both Gemma 4 27B and Qwen 3.5 had previously failed on the same task. What's even more noteworthy is that this local model's implementation quality actually surpassed Claude Sonnet's solution.

Three-Tier Progressive Testing: From Basics to Reverse Engineering

The developer designed three progressively harder coding challenges to filter for real-world local LLM capabilities:

Level 1: Network Speed Monitor App — This is the "entry ticket" test. If a model can't handle this, there's no point continuing.

Level 2: Classic Doom Fire Effect — A terminal application requiring ANSI graphics and complex algorithm implementation. Qwen 3.5 started struggling at this level, but Gemma 4 performed excellently and passed with ease, which initially made the tester lean toward choosing Gemma.

Level 3: LTE Modem Scraper — Sounds simple, but it's actually a nightmare. It requires extracting real-time wireless signal strength data from the modem's web portal, where the logic is hidden in massive obfuscated and minified JavaScript files. These files quickly fill up the model's context window, causing severe hallucinations.

Web application JavaScript code typically undergoes obfuscation and minification: variable names are replaced with meaningless single characters or random strings, whitespace and comments are removed, multiple files are merged into a single file, and sometimes anti-debugging traps are added. This serves both to protect intellectual property and to reduce file size for faster loading. For LLMs, the control flow structure of obfuscated code becomes completely unreadable, easily triggering hallucinations—the model will "guess" function semantics rather than truly understanding the logic chain.

It was at Level 3 that Gemma 4 exposed the fatal flaw of its sliding window attention architecture. Sliding Window Attention (SWA) is an approximation method that reduces the computational cost of long contexts: each token only attends to tokens within a fixed window around it rather than all tokens globally, reducing standard Transformer O(n²) complexity to O(n·w). However, the trade-off is that the model cannot directly "see" information outside the window. When processing thousands of lines of obfuscated JavaScript, critical login logic may be scattered across different positions in the file, and the SWA architecture causes the model to "forget" key context read earlier when attending to new code segments, producing logical discontinuities—this is precisely the root cause of Gemma 4's failure at Level 3. The tester specifically created a memory quality benchmark to compare Gemma 4, Qwen 3.5, and the MoE and Dense variants of Qwen 3.6. Results showed that Qwen 3.6 35B A3B has a clear advantage in long-context memory.

The Full Hands-On Process: A Nearly 4-Hour Local Inference Marathon

Downloading and Beautifying Obfuscated JavaScript Files

The test was conducted on a MacBook with 36GB of RAM, with the model loaded at 128K context size and Q8 KV cache. From the initial phase, Qwen 3.6's performance was impressive: prefill speed reached 400 tokens/second, with generation speed approaching 40 tokens/second.

Here it's important to understand the two fundamentally different phases of LLM inference: The prefill phase processes all input tokens, computing the KV cache for each token in parallel—a compute-intensive operation. The decode phase generates output token by token autoregressively—a memory bandwidth-intensive operation. Apple Silicon's unified memory architecture excels in memory bandwidth (benefiting decoding), but still lags behind dedicated GPUs in large-batch matrix operations (constraining prefill)—this hardware characteristic becomes a key bottleneck in subsequent long-context scenarios.

The model was first asked to find and download all client-side JavaScript files from the modem portal. Even this step isn't trivial—imagine manually finding all JS dependencies from an unfamiliar web portal yourself. Subsequently, the tester had the model beautify these obfuscated and minified JS files in a new session to make the logic easier to understand.

js-beautify is a widely used open-source tool that reformats minified code: re-adding indentation, line breaks, and spaces to make the code structure readable again, though it cannot restore the semantic meaning of replaced variable names. While variable names remain garbled after beautification, control flow structures (if/else, function call chains, nested loops) become clearly visible, significantly reducing the comprehension difficulty for LLMs.

Qwen correctly invoked the js-beautify command and successfully processed all 19 files. The tester deliberately performed the beautification in a new session to avoid context contamination from previous steps—this "human-in-the-loop" strategy is crucial for working with local models.

Cracking the Login Flow: An Extreme Long-Context Understanding Challenge

This is the most brutal part of the entire challenge—a real long-context comprehension test. The model needs to progressively piece together the complete login logic from the beautified JS files.

Qwen 3.6's long-context advantage partly stems from its Gated Delta-Net attention mechanism. Delta-Net is a linear attention variant that uses a "Delta update rule" similar to memory write/erase operations