TL;DR

Before you orderOffer from Amazon

Get the latest gadgets delivered free with Prime

• Fast, free delivery on millions of items
• Prime Video, Amazon Music and more included
• Member-only deals all year

Start your free Prime trial →Free trial for eligible customers · Cancel anytime

As an affiliate, we earn on qualifying purchases.Hide

An XDA writer tested local language models on an Exynos Galaxy S23 FE with 8 GB of RAM. Models ran through PocketPal and Termux, but Termux generation fell to roughly 0.1 tokens per second in the background and rose to about 11.4 tokens per second when foregrounded; the writer linked the gap to Android’s reduced CPU allocation for background apps.

An XDA writer found that a Galaxy S23 FE could run local language models, but performance depended heavily on whether the hosting app stayed visible: Termux generation rose from about 0.1 tokens per second in the background to 11.39 tokens per second in the foreground. The test suggests an older phone can handle some local AI tasks, while also showing that Android’s background resource limits can make a command-line setup impractical when left unattended.

The writer tested an Exynos 2200 Galaxy S23 FE with 8 GB of RAM, of which Android showed 7.3 GB as available. With about 4.6 GB already in use, a Gemma 4 E2B model initially crashed repeatedly while loading in PocketPal, an app that provides a model library and chat interface. The smaller Gemma 3 1B ran without throttling, but the writer did not assess its answer quality in that first check.

Using Termux and llama.cpp, the writer loaded an Unsloth Q4_K_M build of Gemma 4 E2B, listed at 2.8 GB and approximately 4.65 billion parameters including embeddings. The model started a server at localhost:8080, but initial generation was extremely slow. A short test produced eight tokens at 0.11 tokens per second; a longer summary request generated 68 tokens at 0.09 tokens per second, taking 11 minutes and 56 seconds.

In later llama-bench tests, the writer found that keeping Termux in the foreground substantially changed the results. Qwen 3.5 2B generation measured 0.17 tokens per second when Termux was not in front and 13.33 tokens per second in a short foreground test. Gemma 4 E2B reached 11.39 tokens per second in the foreground. Separately, PocketPal ran Qwen 3.5 2B at about 9 tokens per second in the writer’s real-world tests, though the writer reported frequent hallucinations and invented facts.

Foreground Use Makes the Difference

The result matters to people considering an old phone as a private, on-device AI host: having enough storage to load a model does not guarantee a usable experience. In this test, a model that appeared nearly stalled in Termux became responsive when the app was brought to the foreground, making app visibility a practical part of performance rather than a minor setting.

That also limits the phone’s usefulness as an unattended home server. The writer’s measurements suggest that a command-line model process may lose access to CPU cores when Android places its app in the background. For an everyday chat interface, PocketPal offered a simpler route and usable speed in these tests, but the reported answer quality was uneven. The report is a single-device experiment, not a broad benchmark of Galaxy phones or local models.

Two Ways to Run Models

The writer compared a dedicated client, PocketPal, with a command-line setup using Termux and llama.cpp. PocketPal offered a built-in chat screen and suggested models it considered suitable for the phone. Termux provided a local server and more direct control over model loading, but its measured performance changed when the app was no longer visible.

The device’s memory headroom was limited: Android reported 7.3 GB visible, and 4.6 GB was already occupied before testing. The writer also checked whether power settings explained the slow results. Termux was set to Unrestricted battery use, unused-app sleep was disabled, and power saving was off. Those checks narrowed the writer’s investigation toward background CPU access, though they do not establish how every Android device or software version will behave.

“The 103-token prefill ran at 1.27 tok/s, and the actual generation was 0.11 tok/s.”

— Shekhar Vaidya, writing for XDA

The CPU Cause Is Still a Hypothesis

Vaidya inspected CPU availability and reported that all eight cores were available while Termux was active, while the background case showed cores 0–2 in the allowed list. The writer proposed that Android restricts CPU access for apps without a visible window. That is an explanation based on this device’s observations, not a confirmed account of the operating system’s full scheduling behavior.

The supplied report ends while discussing a possible role for Samsung’s system software, so it does not establish whether Samsung-specific controls contributed or how the issue might vary by One UI or Android version. It also does not provide repeated tests across devices, temperatures, model formats or longer sessions. The benchmark figures should be read as results from this particular phone and setup, not guaranteed performance for other Galaxy models.

Testing Beyond One Phone

The immediate practical takeaway from the reported tests is to keep Termux in the foreground while measuring or using a model through that setup. Further testing would be needed to separate Android’s general background restrictions from Samsung-specific behavior, and to establish whether the same performance gap appears on other Galaxy devices.

Anyone trying the approach should also check model fit and output quality, not just whether a model loads. In this test, PocketPal avoided the repeated loading crashes for the selected model and delivered faster everyday generation, but the writer found its answers prone to errors. The report does not identify a single model that was both reliably accurate and consistently usable for the writer’s general tasks.

Key Questions

Can a Galaxy S23 FE run a local language model?

In the XDA test, an Exynos Galaxy S23 FE with 8 GB of RAM loaded models through PocketPal and Termux. Results varied by app, model and whether Termux was in the foreground.

Why was Termux so slow in the background?

The writer observed a sharp speed difference and found fewer CPU cores available to Termux when it was not visible. The proposed link to Android background CPU limits remains a hypothesis from a single-device test.

Which setup performed better in the reported tests?

Termux ran much faster with the app in the foreground, reaching 11.39 tokens per second for Gemma 4 E2B in a short benchmark. PocketPal also ran Qwen 3.5 2B at about 9 tokens per second in the writer’s real-world tests.

Were the model responses reliable?

Not consistently, according to the writer. PocketPal’s Qwen 3.5 2B responses often contained hallucinations and invented facts, so speed alone did not make it a dependable replacement for cloud AI.

Source: XDA Developers