辛辛苦苦等地安装好 Proot-Distro 的容器，回过头来才发现其实可以更简单点安装 Ollama 的！

安装

这里安装就方便许多了，除了可以使用 Ollama 官网提供的脚本进行安装，除此之外还能使用在线存储库的源进行安装。

1. 安装有 Termux 的安卓手机
2. 在 Termux 里面进行操作：
   • 更新在线源的缓存：

     pkg update
     

   • 安装 Ollama ：

     pkg install ollama
     

   • 启动 Ollama ：

     ollama serve &
     

   • 运行模型：

     ollama run deepseek-r1:1.5b --verbose
     

3. 性能对比：
   • 在Proot-Distro 的容器里面：

     >>> 你的速度如何？ 
     您好！我是由中国的深度求索（DeepSeek）公司开发的智能助 手DeepSeek-R1。有关模型和产品的详细内容请参考官方文档。
     
     [GIN] 2026/05/25 - 09:08:24 | 200 | 12.299039587s | 127.0.0.1 | POST "/api/chat" 
     
     total duration: 12.298808764s 
     load duration: 237.548103ms 
     prompt eval count: 7 token(s) 
     prompt eval duration: 561.56024ms 
     prompt eval rate: 12.47 tokens/s 
     eval count: 38 token(s) 
     eval duration: 11.36346595s 
     eval rate: 3.34 tokens/s
     

   • 直接在 Termux 里直接运行：

     >>> 你的速度如何？ 
     您好！我是由中国的深度求索（DeepSeek）公司开发的智能助 手DeepSeek-R1 created in 2023年4月。有关模型和产品的详 细内容请参考官方文档。
     
     [GIN] 2026/05/25 - 09:14:50 | 200 | 13.802764953s | 127.0.0.1 | POST "/api/chat" 
     
     total duration: 13.802643151s 
     load duration: 188.753412ms 
     prompt eval count: 7 token(s) 
     prompt eval duration: 515.518299ms 
     prompt eval rate: 13.58 tokens/s 
     eval count: 48 token(s) 
     eval duration: 12.933170156s 
     eval rate: 3.71 tokens/s
     

   速度相差无几，基本排除第二次使用的缓存命中的原因。其实我也不清楚有没有缓存的？

4. 接口调用：
   虽然是在 Termux 里面运行的，但在软件外的浏览器中可以正常使用本地环回地址访问。
   API接口：https://127.0.0.1:11434
   就此可以使用 Ollama 的程序连接使用。

体验

Models

性能一览

deepseek-r1:1.5b

>>> 你的速度如何？ 
您好！我是由中国的深度求索（DeepSeek）公司开发的智能助 手DeepSeek-R1 created in 2023年4月。有关模型和产品的详 细内容请参考官方文档。

[GIN] 2026/05/25 - 09:14:50 | 200 | 13.802764953s | 127.0.0.1 | POST "/api/chat" 

total duration: 13.802643151s 
load duration: 188.753412ms 
prompt eval count: 7 token(s) 
prompt eval duration: 515.518299ms 
prompt eval rate: 13.58 tokens/s 
eval count: 48 token(s) 
eval duration: 12.933170156s 
eval rate: 3.71 tokens/s

granite4.1:8b

>>> 你的速度如何？ 
作为一个大型语言模型，我的处理和响应速度取决于多种因素 ，包括但不限于服务器负载、请求的复杂性以及网络延迟。通 常情况下，我能够在几百毫秒到一秒之间生成并返回对您问题 的回答。请注意，具体的响应时间可能会有所不同，但我的设 计目标是提供尽快且准确的信息。如果您有特定的查询或需要 实时处理大量数据，请告诉我，我将尽力满足您的需求。

[GIN] 2026/05/25 - 09:50:04 | 200 | 3m43s | 127.0.0.1 | POST "/api/chat" 

total duration: 3m43.078881491s 
load duration: 129.694639ms 
prompt eval count: 15 token(s) 
prompt eval duration: 5.145896872s 
prompt eval rate: 2.91 tokens/s 
eval count: 161 token(s) 
eval duration: 3m37.384439856s 
eval rate: 0.74 tokens/s

qwen3.5:4b

>>> 你的速度如何？ 
Thinking... 
嗯，用户问我的速度如何。首先，我需要确认他们想知道的是 响应速度还是处理速度。可能他们之前遇到了响应慢的情况， 或者听说我的速度很快，想确认一下。 作为 Qwen3.5，我的生成速度应该依赖于后端的技术架构。我 需要提到具体的优化点，比如混合注意力机制、多 token 预测 这些技术。但用户可能不太熟悉这些术语，需要用更易懂的语 言解释。 另外，用户可能关心实际使用时的体验，比如在网页或应用中 的响应时间。我需要强调在实际应用中，速度取决于服务器和 系统状态，但我会尽力优化。 可能还要比较不同模型的速度，但用户没要求比较，所以点到 为止。需要避免技术细节过多，保持回答友好，同时突出优势 。 还要注意用户可能关心并发请求的处理能力，比如高并发下的 稳定性。这时候要提到架构优化和分布式处理，但同样需要简 化。 最后，确保回答准确，不夸大，同时提供改进空间，比如建议 反馈，这样显得真诚。 

...done thinking. 

你好！关于速度，我这边可以这么说： **作为 Qwen3.5，我的核心生成速度在技术层面经过全面优化 **： 

1. **生成效率**： - 采用了**混合注意力机制**与**多 token 预测**技术， 在复杂任务中仍能保持流畅的响应输出。 - 实际应用中，简单问题的响应通常在几秒内完成，复杂任 务也会通过后台异步优化确保体验。 

2. **实际体验**： - 具体速度取决于**服务器负载、网络状况**以及**任务复 杂度**（比如生成 1000 字 vs. 10000 字）。 - 如果是常规文本生成（如写文章、回答问题），速度非常 快；如果涉及长文本理解或复杂逻辑推理，可能会稍需时间优 化，但整体仍属流畅级别。 

3. **高并发支持**： - 架构设计支持**大规模并发请求**，即使多人同时使用， 也能保持响应稳定（这点在实际使用中很关键）。 

4. **实际对比**： - 相比早期版本，我在速度上提升了约 30%（具体数值视场 景而定），尤其是**多轮对话**和**长文本处理**的场景。 **需要调整速度的情况**： - 如果是超大规模数据（如生成数十万字内容），可能需要 分批次处理，但整体耗时仍在可控范围内。 - 如果遇到卡顿，建议检查网络或减少单次请求的复杂度（ 比如拆分任务）。 

总之，**速度是我的核心优势之一**，尤其在需要快速响应的 场景下，我的表现非常接近原生流畅体验。如果你有具体场景 （比如网页端、API 调用），可以告诉我，我会针对性说明优 化细节～


[GIN] 2026/05/25 - 10:10:54 | 200 | 12m40s | 127.0.0.1 | POST "/api/chat" 

total duration: 12m40.484470244s 
load duration: 349.087934ms 
prompt eval count: 14 token(s) 
prompt eval duration: 3.136495495s 
prompt eval rate: 4.46 tokens/s eval 
count: 586 token(s) 
eval duration: 12m34.290122095s 
eval rate: 0.78 tokens/s

gemma3:4b

>>> 你的速度如何？
 作为一个大型语言模型，我的速度取决于几个因素： 

* **请求的复杂性：** 简单的问题（例如“你好”）可以几乎即 时得到回复。复杂的请求，例如需要大量计算、深入的分析， 或者需要访问外部数据源，则需要更多的时间。 

* **服务器负载：** 我的运行在大型服务器集群上。当其他 用户同时使用我时，响应速度可能会变慢。 

* **网络连接：** 您的网络连接速度也会影响响应时间。 

* **模型大小和优化：** 我是一个非常大的模型，但谷歌一 直在持续地对模型进行优化，以提高速度和效率。 

**一般来说，以下是一些大致的响应时间：** 

* **简单问题:** 几百毫秒 (0.1-1 秒) 

* **中等问题:** 1-3 秒 

* **复杂问题 (需要计算、分析):** 3-10 秒 (甚至更长，取 决于具体情况) 

**我一直在努力提升我的速度。** 谷歌工程师们不断地改进我 的架构和算法，以让我能够更快速、更有效地回答您的提问。 

**为了更好地理解您的需求，您可以尝试：** 

* 提供更具体的问题。 * 将复杂的请求分解成更小的步骤。 

* 检查您的网络连接。 

您有什么问题想问我吗？ 我会尽力尽快回答！ 


[GIN] 2026/05/25 - 10:19:44 | 200 | 3m27s | 127.0.0.1 | POST "/api/chat" 

total duration: 3m27.627229429s 
load duration: 493.499992ms 
prompt eval count: 13 token(s) 
prompt eval duration: 2.124245576s 
prompt eval rate: 6.12 tokens/s 
eval count: 301 token(s) 
eval duration: 3m23.773644977s 
eval rate: 1.48 tokens/s

glm4:9b

>>> 你的速度如何？ 
我的回复速度取决于服务器的响应时间和网络条件。通常情况 下，我的回答应该是即时的。如果您觉得有延迟，可能是因为 您所在地区与服务器之间的网络状况不佳。请耐心等待，我会 尽快给您答复。

[GIN] 2026/05/25 - 11:15:17 | 200 | 1m24s | 127.0.0.1 | POST "/api/chat" 

total duration: 1m24.330914514s 
load duration: 204.532554ms 
prompt eval count: 10 token(s) 
prompt eval duration: 4.125569314s 
prompt eval rate: 2.42 tokens/s 
eval count: 47 token(s) 
eval duration: 1m19.775492174s 
eval rate: 0.59 tokens/s 

不知道准不准确，发现模型的大小与内存的大小有些相关的样子，比如7.2GB的模型在8GB的云手机上就内存不足。

不太满意的就是在这里不能使用systemctl、service拉起服务，只能用命令行的方式启动。

ChiuYut

2026年05月25日