Watu wengi wanakisia RAM. Aidha wananunua nyingi mno «ikiwa tu» au wanakutana na OOM killer saa 9 usiku. Kumbukumbu kwa kweli ni moja ya vitu rahisi zaidi kupima ukubwa, kwa sababu kazi zinatabirika mara unapojua takwimu za makadirio. Hizi hapa, kutoka seva ya bot ya 1 GB hadi seva za 64 GB ambazo watu wanazitafuta wanapotaka kuendesha modeli kubwa ndani.
Takwimu za makadirio kwa kila kazi
Hizi ni takwimu halisi za hali thabiti kwa usanidi wa kawaida, si viwango vya chini vya watengenezaji.
| Kazi | RAM inayotumika kweli | Mpango unaofaa |
|---|---|---|
| Bot ya Telegram/Discord (Python, Node.js) | 100–300 MB | Nano 1 GB |
| Tovuti tuli + Caddy/Nginx | 50–150 MB | Nano 1 GB |
| WordPress + MariaDB, trafiki ya kawaida | 0.8–1.5 GB | Micro-IP 2 GB |
| PostgreSQL kwa programu ndogo | 0.5–2 GB (unaamua kupitia shared_buffers) | Micro / Small |
| n8n yenye workflows chache | 0.5–1.5 GB | Micro 2 GB |
| Host ya Docker yenye huduma ndogo 5–10 | 2–4 GB | Small 4 GB |
| Coolify + builds + hifadhidata | 3–4 GB | Small-IP 4 GB |
| LLM ya 7–8B, 4-bit, inference kwenye CPU | 5–6 GB | Medium 6 GB |
| LLM ya 14B, 4-bit | ~10 GB | Pro-32 |
| LLM ya 32B, 4-bit | ~20 GB | Pro-32 |
| LLM ya 70B, 4-bit | ~40–45 GB | Pro-48 / Pro-64 |
Mambo mawili ya kuzingatia. Kwanza, pengo kati ya kazi «za kawaida» na LLMs ni kubwa: bot na modeli ya 70B zinatofautiana mara mia mbili. Pili, huduma nyingi ziko sawa kwenye 1–4 GB; watu wananunua zaidi kwa sababu wanapima kwa ajili ya siku zijazo ambazo mara chache zinafika.
Fomula ya LLM
Kwa modeli za lugha kuna makadirio rahisi: vigezo × biti kwa kila uzito ÷ 8, pamoja na mzigo wa ziada. Modeli ya 8B kwa takriban biti 4.5 (quantization ya kawaida ya Q4) ni 8 × 4.5 ÷ 8 ≈ 4.5 GB za uzito. Ongeza 1–2 GB kwa dirisha la context (KV cache inakua kulingana na urefu wa context) na runtime, na unafika 5–6 GB.
Sehemu ya uwazi: kwenye seva za CPU pekee, kumbukumbu ni nusu tu ya hadithi. Tarajia tokens za tarakimu moja kwa sekunde kwa modeli za 7–8B kwenye vCPU chache na takriban token moja kwa sekunde kwa 70B. Hilo ni sawa kwa kazi za kundi, agents wa nyuma na majaribio binafsi; si uzoefu wa chat kwa watumiaji wengi kwa wakati mmoja. Ikiwa mara nyingi unaita APIs za modeli zinazopangishwa, agent wako anahitaji kidogo sana; angalia ukubwa wa VPS kwa AI agents.
Pima badala ya kukisia
Ikiwa tayari una seva, takwimu ziko hapo:
free -h # look at "available", not "free"
ps aux --sort=-rss | head -n 8 # the biggest processes, by resident memory
docker stats --no-stream # per-container usage
Linux inatumia RAM isiyotumika kama cache ya disk, kwa hivyo «free» daima ni ndogo na hiyo ni afya. Available ndiyo takwimu muhimu: kumbukumbu ambayo kernel inaweza kuwapa programu sasa hivi. Ikiwa available inabaki juu ya ~25% wakati wa saa yako yenye shughuli nyingi zaidi, ukubwa ni sahihi. Ikifika sifuri mara kwa mara na swap ikikua, panda mpango.
Angalia pia mauaji ya OOM ya zamani:
journalctl -k | grep -i "out of memory"
Swap: mkanda wa usalama, si injini
Faili ya swap ya 1–2 GB kwenye seva ndogo ni bima ya bei nafuu: sasisho la kifurushi au build ya Docker inayohitaji kumbukumbu zaidi kwa muda mfupi inasalimika badala ya kuuawa. Lakini huduma ikiishi kwenye swap, kila ombi linasubiri disk. Swap ni kwa ongezeko la ghafla. Swapping ya kudumu inamaanisha unahitaji mpango unaofuata.
Kwa hivyo ununue kiasi gani?
- 1 GB: bot moja, API ndogo moja, tovuti tuli.
- 2 GB: chaguo-msingi la busara kwa chochote chenye hifadhidata au Docker.
- 4–6 GB: huduma kadhaa kwenye mashine moja, builds kwenye seva, modeli ndogo ya ndani.
- 32–64 GB: tu wakati kitu kimoja kikubwa lazima kiishi kwenye kumbukumbu: modeli ya ndani iliyo juu ya 14B, faharasa kubwa ya RAG, kundi la agents. Hiyo ndiyo kazi ya mipango ya kumbukumbu kubwa.
Anza na ukubwa mmoja chini ya unaohisi, tazama free -h kwa wiki moja, na panda ikiwa takwimu zinasema hivyo. Kwenye EQVPS kupandisha mpango kunahifadhi data yako na kunatoza tofauti ya uwiano tu (jinsi mabadiliko ya mpango yanavyofanya kazi).
Maoni
Bado hakuna maoni. Kuwa wa kwanza.