# 2核2G服务器跑270M LLM模型\[测试\]

**URL:** <https://forum.rainyun.com/t/topic/13015>\
**Category:** 综合讨论\
**Tags:** 文档文章\
**Created:** [2026 年2 月 6 日 17:12 UTC](https://forum.rainyun.com/t/topic/13015 "2026-02-06T17:12:31Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

作者： ![MGS浪疯](https://forum.rainyun.com/user_avatar/forum.rainyun.com/mgs%E6%B5%AA%E7%96%AF/32/8285_2.png) [@MGS浪疯](https://forum.rainyun.com/u/MGS%E6%B5%AA%E7%96%AF)\
发布日期： [2026 年2 月 6 日 17:12 UTC](https://forum.rainyun.com/t/topic/13015/1 "2026-02-06T17:12:32Z")

</div>

**本文仅为技术测试用途。实际部署中存在诸多变量，结果可能因环境差异而不同，请勿将其视为生产环境的参考依据。**

本次测试旨在评估在 2 核 2GB 内存的服务器上运行轻量级 LLM 模型的可行性。

# 服务器配置

- **实例规格** ：标准型 SA5（SA5.MEDIUM2）
- **操作系统** ：Debian 12.10 64 位
- **CPU** ：2 核
- **内存** ：2 GiB
- **系统盘** ：50 GiB 通用型 SSD 云硬盘
- **公网带宽** ：200 Mbps

# 部署环境

- **推理框架** ：Ollama v0.15.5
- **测试模型** ：`gemma3:270m`
- **测试脚本** ：[GitHub - lework/llm-benchmark: LLM 并发性能测试工具，支持自动化压力测试和性能报告生成。 · GitHub](https://github.com/lework/llm-benchmark#)

# 普通测试结果

**再次提醒：实际部署中存在诸多变量，结果可能因环境差异而不同，请勿将其视为生产环境的参考依据。**

## 100请求1并发

\*\* 粗略总结\*\*  
在 2 核 2GB 的服务器上使用 Ollama 部署 `gemma3:270m` 模型，单并发下可稳定完成全部请求（100/100 成功）。  
平均 RPS 为 0.77，平均端到端延迟约 1.3 秒，平均 token 生成速度达 35.8 tokens/s，首 token 响应时间中位数为 0.32 秒。  
整体表现符合轻量模型预期，适合低频、非实时场景，但高百分位延迟和生成速度波动提示资源受限明显。

> 以下为本次测试的详细参数与完整指标：

```auto
基本信息:
总请求数: 100 个
成功请求数: 100 个
并发数: 1 个
请求超时: 60 秒
最大输出token数: 50
是否使用长文本: 否
总运行时间: 130.61 秒
每秒请求数 (RPS): 0.77
总输出token数: 4640
模型名称: gemma3:270m

延迟统计 (单位: 秒):
平均延迟: 1.306
延迟 P50: 1.273
延迟 P95: 1.917
延迟 P99: 2.392

Token生成速度 (tokens/sec):
平均速度: 35.81
速度 P50: 39.04
速度 P95: 14.93
速度 P99: 8.08

首token响应时间 (单位: 秒):
平均时间: 0.413
TTFT P50: 0.324
TTFT P95: 0.995
TTFT P99: 1.428

```

## 100请求5并发

**粗略总结**

在 2 核 2GB 服务器上以 **5 并发** 运行 `gemma3:270m`，100 个请求全部成功。  
尽管总运行时间缩短至约 104 秒（RPS 提升至 0.96），但系统资源明显过载：平均延迟飙升至 **5.08 秒** ，首 token 响应时间中位数达 **4.36 秒** ，token 生成速度从单并发时的 ~36 tokens/s 骤降至 **9.2 tokens/s** ，且高百分位性能严重退化（P95 生成速度仅 1.12 tokens/s）。  
表明该配置无法有效支撑 5 并发推理，存在显著排队与资源竞争。

> 以下为本次测试的详细参数与完整指标：

```auto
基本信息:
总请求数: 100 个
成功请求数: 100 个
并发数: 5 个
请求超时: 60 秒
最大输出token数: 50
是否使用长文本: 否
总运行时间: 103.67 秒
每秒请求数 (RPS): 0.96
总输出token数: 4607
模型名称: gemma3:270m

延迟统计 (单位: 秒):
平均延迟: 5.076
延迟 P50: 5.186
延迟 P95: 5.786
延迟 P99: 6.756

Token生成速度 (tokens/sec):
平均速度: 9.23
速度 P50: 9.26
速度 P95: 1.12
速度 P99: 1.06

首token响应时间 (单位: 秒):
平均时间: 4.134
TTFT P50: 4.361
TTFT P95: 4.764
TTFT P99: 5.737

```

## 100请求20并发

**粗略总结**

在 2 核 2GB 服务器上以 **20 并发** 运行 `gemma3:270m`，虽然 100 个请求全部成功且总耗时仅略增至 106.93 秒（RPS ≈ 0.94），但系统已严重过载：平均端到端延迟高达 **19.35 秒** ，首 token 响应时间中位数超过 **20 秒** ，token 生成速度暴跌至 **2.72 tokens/s** （P99 仅 0.19 tokens/s）。  
这表明 Ollama 在高并发下存在显著排队与资源争用，实际响应体验极差。该配置完全不适用于 20 并发场景，建议严格限制并发数（≤1）以保障可用性。

> 以下为本次测试的详细参数与完整指标：

```auto
基本信息:
总请求数: 100 个
成功请求数: 100 个
并发数: 20 个
请求超时: 60 秒
最大输出token数: 50
是否使用长文本: 否
总运行时间: 106.93 秒
每秒请求数 (RPS): 0.94
总输出token数: 4666
模型名称: gemma3:270m

延迟统计 (单位: 秒):
平均延迟: 19.349
延迟 P50: 21.245
延迟 P95: 21.987
延迟 P99: 22.510

Token生成速度 (tokens/sec):
平均速度: 2.72
速度 P50: 2.34
速度 P95: 1.09
速度 P99: 0.19

首token响应时间 (单位: 秒):
平均时间: 18.394
TTFT P50: 20.261
TTFT P95: 21.005
TTFT P99: 21.454

```

## 100请求50并发

**粗略总结**

在 2 核 2GB 服务器上以 **50 并发** 运行 `gemma3:270m`，尽管所有请求最终成功（100/100），系统已处于严重过载状态：平均延迟高达 **42.6 秒** ，中位数延迟超过 **50 秒** ，接近 60 秒超时阈值；首 token 响应时间 P99 达 **58 秒** ，几乎耗尽整个超时窗口。  
Token 生成速度进一步恶化至 **1.43 tokens/s** （P99 仅 0.05 tokens/s），表明模型几乎无法有效处理并发请求。虽然总吞吐（RPS ≈ 0.9）看似稳定，但这是以极长响应时间为代价的“虚假吞吐”。  
该配置完全不适用于实际交互场景，强烈建议避免高并发部署。

> 以下为本次测试的详细参数与完整指标：

```auto
基本信息:
总请求数: 100 个
成功请求数: 100 个
并发数: 50 个
请求超时: 60 秒
最大输出token数: 50
是否使用长文本: 否
总运行时间: 110.71 秒
每秒请求数 (RPS): 0.90
总输出token数: 4786
模型名称: gemma3:270m

延迟统计 (单位: 秒):
平均延迟: 42.607
延迟 P50: 50.951
延迟 P95: 54.631
延迟 P99: 58.089

Token生成速度 (tokens/sec):
平均速度: 1.43
速度 P50: 0.98
速度 P95: 0.87
速度 P99: 0.05

首token响应时间 (单位: 秒):
平均时间: 41.663
TTFT P50: 49.973
TTFT P95: 53.620
TTFT P99: 58.002

```

## 100请求100并发

**粗略总结**

在 **100 并发** 下，`gemma3:270m` 在 2 核 2GB 服务器上完全无法响应： **100 个请求全部失败（成功数为 0）** ，总输出 token 为 0，RPS 为 0。  
系统因资源耗尽导致所有请求超时或被拒绝，基准测试脚本甚至因缺乏有效数据而抛出格式化错误（`TypeError`）。  
这表明当前硬件配置远不足以支撑如此高的并发负载，Ollama 服务在此压力下已崩溃或无响应。

> 以下为本次测试的详细参数与完整指标：

```auto
基本信息:
总请求数: 100 个
成功请求数: 0 个
并发数: 100 个
请求超时: 60 秒
最大输出token数: 50
是否使用长文本: 否
总运行时间: 150.13 秒
每秒请求数 (RPS): 0.00
总输出token数: 0
模型名称: gemma3:270m

延迟统计 (单位: 秒):
平均延迟: 0.000
Traceback (most recent call last):
  File "/workspace/llm-benchmark/llm_benchmark.py", line 318, in <module>
    print_results(results, args.output_format)
  File "/workspace/llm-benchmark/llm_benchmark.py", line 277, in print_results
    print(f"延迟 P50: {results['latency']['p50']:.3f}")
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: unsupported format string passed to NoneType. __format__
root@98c9d86f4881:/workspace/llm-benchmark# 

```

（是的，他自己就崩了，无法测）

 ![image](https://forum.rainyun.com/uploads/default/original/2X/7/7da7212b844bf2abf37197ba978b589c94e59586.jpeg)

 ![image](https://forum.rainyun.com/uploads/default/original/2X/e/ee9bc2abfda08ccafc10a9014f9e3c4dc7044bb4.png)

# 稳定性测试

## 1000请求1并发

**粗略总结**

在 **1 并发、1000 请求** 的长时间压力测试中，`gemma3:270m` 在 2 核 2GB 服务器上保持了 **100% 成功率** ，验证了其在低并发下的稳定性。  
平均 RPS 为 **0.69** ，平均延迟 **1.45 秒** ，token 生成速度 **33.6 tokens/s** ，与 100 请求测试结果基本一致。  
但尾部延迟明显增加（P99 延迟达 4.47 秒，TTFT P99 达 3.55 秒），表明长时间运行下系统可能出现轻微资源累积压力或调度波动。  
整体仍适合低频、稳定推理任务，但对响应一致性要求高的场景需谨慎。

> 以下为本次测试的详细参数与完整指标：

```auto
基本信息:
总请求数: 1000 个
成功请求数: 1000 个
并发数: 1 个
请求超时: 60 秒
最大输出token数: 50
是否使用长文本: 否
总运行时间: 1451.98 秒
每秒请求数 (RPS): 0.69
总输出token数: 46130
模型名称: gemma3:270m

延迟统计 (单位: 秒):
平均延迟: 1.452
延迟 P50: 1.289
延迟 P95: 2.367
延迟 P99: 4.470

Token生成速度 (tokens/sec):
平均速度: 33.61
速度 P50: 38.46
速度 P95: 9.70
速度 P99: 4.45

首token响应时间 (单位: 秒):
平均时间: 0.560
TTFT P50: 0.335
TTFT P95: 1.401
TTFT P99: 3.549

```

## 1000请求10并发

粗略总结

在 **10 并发、1000 请求** 的压力测试中，`gemma3:270m` 仍保持 **100% 成功率** ，总耗时约 1030 秒（RPS ≈ 0.97），吞吐量接近单并发水平。然而，系统资源严重受限：平均延迟高达 **10.26 秒** ，首 token 响应时间中位数达 **9.29 秒** ，token 生成速度降至 **4.49 tokens/s** ，且高百分位性能急剧恶化（P95 生成速度仅 0.53 tokens/s）。  
这表明 Ollama 在 2 核 2GB 环境下虽能“完成”10 并发任务，但所有请求几乎完全串行化排队处理，实际响应体验极差。  
适用于对延迟不敏感的批量离线任务，但绝不适合交互式场景。

> 以下为本次测试的详细参数与完整指标：

```auto
基本信息:
总请求数: 1000 个
成功请求数: 1000 个
并发数: 10 个
请求超时: 60 秒
最大输出token数: 50
是否使用长文本: 否
总运行时间: 1030.26 秒
每秒请求数 (RPS): 0.97
总输出token数: 45910
模型名称: gemma3:270m

延迟统计 (单位: 秒):
平均延迟: 10.259
延迟 P50: 10.251
延迟 P95: 11.098
延迟 P99: 12.072

Token生成速度 (tokens/sec):
平均速度: 4.49
速度 P50: 4.74
速度 P95: 0.53
速度 P99: 0.32

首token响应时间 (单位: 秒):
平均时间: 9.315
TTFT P50: 9.286
TTFT P95: 10.085
TTFT P99: 11.018

```

# 结语

本次测试主要测试了270M量级模型在Ollama推理框架下在2核2g服务器测试的表现。结果清晰表明：

- **单并发（≤1）场景下** ，模型运行稳定、响应及时，可满足低频、非实时的本地推理需求；
- **一旦并发数 ≥5** ，系统资源迅速成为瓶颈，延迟急剧上升、生成速度断崖式下跌，用户体验显著恶化；
- **高并发（≥20）时** ，尽管部分请求仍能“成功”，但响应时间接近或逼近超时阈值，实际已丧失可用性；
- **极端并发（100）直接导致服务不可用** ，验证了该硬件配置的承载上限极低。  
（后在稳定性测试中，实际在50并发时就存在极大崩溃的概率。结果未写在文章中）

综上，在此类轻量级服务器上部署 LLM， **必须严格限制并发数（建议 ≤1）** ，并明确区分“能跑”和“能用”的边界。

> **再次强调** ：本文仅为技术探索性质的测试，实际生产环境受网络、系统负载、模型实现、操作系统调优等多重因素影响，切勿直接套用本结果做架构决策。

---

<div class="post-metadata">

作者： ![雪球Bqiu](https://forum.rainyun.com/user_avatar/forum.rainyun.com/%E9%9B%AA%E7%90%83bqiu/32/11785_2.png) [@雪球Bqiu](https://forum.rainyun.com/u/%E9%9B%AA%E7%90%83Bqiu)\
发布日期： [2026 年2 月 6 日 23:25 UTC](https://forum.rainyun.com/t/topic/13015/2 "2026-02-06T23:25:41Z")

</div>

😀 还可以，结合new api就起飞了