ადამიანების უმეტესობა RAM-ს ვარაუდობს. ან «ყოველი შემთხვევისთვის» გაცილებით მეტს ყიდულობენ, ან ღამის 3 საათზე ეცნობიან OOM killer-ს. მეხსიერება სინამდვილეში ერთ-ერთი ყველაზე მარტივად შესარჩევი რამაა, რადგან დატვირთვები პროგნოზირებადია, როცა მიახლოებითი ციფრები იცით. აი ისინი, 1 GB ბოტის სერვერიდან 64 GB სერვერებამდე, რომლებსაც ადამიანები ეძებენ, როცა დიდი მოდელის ლოკალურად გაშვება სურთ.
მიახლოებითი ციფრები დატვირთვის მიხედვით
ეს ტიპიური დაყენების რეალური სტაბილური მაჩვენებლებია და არა მწარმოებლების მინიმუმები.
| დატვირთვა | რეალურად მოხმარებული RAM | შესაფერისი ტარიფი |
|---|---|---|
| Telegram/Discord ბოტი (Python, Node.js) | 100–300 MB | Nano 1 GB |
| სტატიკური საიტი + Caddy/Nginx | 50–150 MB | Nano 1 GB |
| WordPress + MariaDB, ჩვეულებრივი ტრაფიკი | 0.8–1.5 GB | Micro-IP 2 GB |
| PostgreSQL პატარა აპისთვის | 0.5–2 GB (თქვენ წყვეტთ shared_buffers-ით) | Micro / Small |
| n8n რამდენიმე workflow-ით | 0.5–1.5 GB | Micro 2 GB |
| Docker ჰოსტი 5–10 პატარა სერვისით | 2–4 GB | Small 4 GB |
| Coolify + build-ები + ბაზა | 3–4 GB | Small-IP 4 GB |
| 7–8B LLM, 4-bit, დასკვნა CPU-ზე | 5–6 GB | Medium 6 GB |
| 14B LLM, 4-bit | ~10 GB | Pro-32 |
| 32B LLM, 4-bit | ~20 GB | Pro-32 |
| 70B LLM, 4-bit | ~40–45 GB | Pro-48 / Pro-64 |
ორ რამეს მიაქციეთ ყურადღება. ჯერ ერთი, ნახტომი «ჩვეულებრივ» დატვირთვებსა და LLM-ებს შორის უზარმაზარია: ბოტი და 70B მოდელი ორასჯერ განსხვავდება. მეორეც, სერვისების უმეტესობა 1–4 GB-ზე კარგად მუშაობს; ადამიანები მეტს ყიდულობენ, რადგან იმ მომავლისთვის არჩევენ ზომას, რომელიც იშვიათად დგება.
LLM-ის ფორმულა
ენობრივი მოდელებისთვის არსებობს მარტივი შეფასება: პარამეტრები × ბიტი ყოველ წონაზე ÷ 8, პლუს ზედნადები. 8B მოდელი დაახლოებით 4.5 ბიტზე (ტიპიური Q4 კვანტიზაცია) ნიშნავს 8 × 4.5 ÷ 8 ≈ 4.5 GB წონებს. დაამატეთ 1–2 GB კონტექსტის ფანჯრისთვის (KV cache კონტექსტის სიგრძესთან ერთად იზრდება) და runtime-ისთვის და 5–6 GB-ზე მიხვალთ.
გულწრფელი ნაწილი: მხოლოდ CPU-იან სერვერებზე მეხსიერება ამბის ნახევარია. მოელით ერთნიშნა რაოდენობის ტოკენს წამში 7–8B მოდელებისთვის რამდენიმე vCPU-ზე და დაახლოებით ერთ ტოკენს წამში 70B-სთვის. ეს კარგია პაკეტური სამუშაოებისთვის, ფონური აგენტებისთვის და პირადი ექსპერიმენტებისთვის; ეს არ არის ჩატის გამოცდილება ბევრი ერთდროული მომხმარებლისთვის. თუ ძირითადად ჰოსტინგ მოდელების API-ებს იძახებთ, თქვენს აგენტს გაცილებით ნაკლები სჭირდება; იხილეთ VPS-ის ზომა AI აგენტებისთვის.
გაზომეთ ვარაუდის ნაცვლად
თუ სერვერი უკვე გაქვთ, ციფრები აქვეა:
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 უქმ RAM-ს დისკის ქეშად იყენებს, ამიტომ «free» ყოველთვის პატარაა და ეს ჯანსაღია. Available ის ციფრია, რომელიც მნიშვნელოვანია: მეხსიერება, რომელიც ბირთვს ახლავე შეუძლია პროგრამებს მისცეს. თუ თქვენს ყველაზე დატვირთულ საათში available ~25%-ზე მეტი რჩება, ზომა სწორია. თუ რეგულარულად ნულს აღწევს და swap იზრდება, გადადით უფრო დიდზე.
შეამოწმეთ წარსული OOM მკვლელობებიც:
journalctl -k | grep -i "out of memory"
Swap: უსაფრთხოების ღვედი და არა ძრავა
1–2 GB swap ფაილი პატარა სერვერზე იაფი დაზღვევაა: პაკეტის განახლება ან Docker build, რომელსაც წამით მეტი მეხსიერება სჭირდება, მოკვლის ნაცვლად გადარჩება. მაგრამ თუ სერვისი swap-ში ცხოვრობს, ყოველი მოთხოვნა დისკს ელოდება. swap ნახტომებისთვისაა. მუდმივი swapping ნიშნავს, რომ შემდეგი ტარიფი გჭირდებათ.
მაშ, რამდენი იყიდოთ?
- 1 GB: ერთი ბოტი, ერთი პატარა API, სტატიკური საიტი.
- 2 GB: გონივრული ნაგულისხმევი ყველაფრისთვის, რაშიც ბაზა ან Docker არის.
- 4–6 GB: რამდენიმე სერვისი ერთ მანქანაზე, build-ები სერვერზე, პატარა ლოკალური მოდელი.
- 32–64 GB: მხოლოდ მაშინ, როცა ერთი დიდი რამ მეხსიერებაში უნდა ცხოვრობდეს: 14B-ზე დიდი ლოკალური მოდელი, დიდი RAG ინდექსი, აგენტების ფლოტი. ამისთვისაა მაღალი მეხსიერების ტარიფები.
დაიწყეთ ერთი ზომით ნაკლებით, ვიდრე ინტუიცია გეუბნებათ, ერთი კვირა უყურეთ free -h-ს და გაზარდეთ, თუ ციფრები ამას ამბობენ. EQVPS-ზე ტარიფის გაზრდა თქვენს მონაცემებს ინარჩუნებს და მხოლოდ პროპორციულ სხვაობას იხდით (როგორ მუშაობს ტარიფის შეცვლა).
კომენტარები
ჯერ არ არის კომენტარები. იყავით პირველი.