RAM kiasi gani inahitajika kwa coding agent kwenye VPS?

Je, wakala wa uandishi wa msimbo (coding agent) anahitaji kiasi gani cha RAM kwenye VPS?

Anza na 4 GB ya RAM na 2 vCPU kwa ajili ya wakala mmoja wa uandishi wa msimbo anayefanya kazi kila wakati kwenye hazina (repository). Hamia kwenye 8 GB na 4 vCPU mara tu seva ya lugha (language server) au ujenzi wa Docker (Docker build) unapoingia kwenye kikao, jambo ambalo kwa hazina nyingi hutokea siku ya kwanza. Mchakato wa wakala wenyewe ni mdogo, kwa hivyo kinachojaza seva ni mkusanyiko wa zana (toolchain) ambazo wakala anaziendesha kwa niaba yako.

[
  {
    "plan": "Minimum viable",
    "ram_gb": 4,
    "vcpu": 2,
    "disk_gb": 50
  },
  {
    "plan": "Comfortable",
    "ram_gb": 8,
    "vcpu": 4,
    "disk_gb": 100
  },
  {
    "plan": "Team, 4 sessions",
    "ram_gb": 16,
    "vcpu": 8,
    "disk_gb": 200
  }
]

Kila safu hapo juu inadhani kuwa modeli inaendeshwa mahali pengine, nyuma ya API unayoiita kupitia mtandao. Dhana hiyo ndiyo huamua swali zima la ukubwa wa rasilimali, kwa hivyo litatue kwanza.

Je, unaendesha wakala (agent), au unaendesha modeli?

Wakala wa uandishi wa msimbo (coding agent) unaoita modeli ya wingu (cloud model) ni mteja wa mtandao (network client) aliyeunganishwa na shell. Hutuma faili na mpango kwenye API, husubiri jibu, kisha huhariri faili na kuendesha amri ndani ya seva (locally). Wakati unasubiri, haitumii CPU karibu kabisa. Kumbukumbu yake hupimwa kwa mamia ya megabytes, ndiyo maana mashine yenye CPU ya kawaida ndiyo kifaa sahihi.

Kuendesha modeli wewe mwenyewe ni bidhaa tofauti kwenye maunzi (hardware) tofauti. Uzito (weights) hubaki kwenye kumbukumbu muda wote seva inapokuwa imewashwa. Modeli yenye vigezo bilioni 7 iliyopunguzwa ubora (quantised) hadi bits 4 inahitaji takriban 5 GB kwa ajili ya uzito pekee, kabla ya kuhesabu key/value cache inayokua kulingana na urefu wa muktadha (context). Kwenye CPU pekee, vCPU iliyoshirikiwa hutoa tokens chache kwa sekunde, na kazi moja ya wakala inaweza kutoa maelfu ya tokens, kwa hivyo kazi inayochukua chini ya dakika moja dhidi ya API itachukua karibu saa moja ukiifanya ndani ya seva. Ikiwa ndicho unachotaka, panga ukubwa kulingana na VRAM (kumbukumbu ya video kwenye GPU) na usome kile ambacho VPS yenye GPU inakupa kihalisi badala ya ukurasa huu.

Kila kitu hapa chini kinachukulia hali ya kutumia modeli ya wingu.

Ni nini hasa kinachotumia kumbukumbu

[
  {
    "label": "Agent CLI process, idle",
    "typical_mb": 250,
    "peak_mb": 600
  },
  {
    "label": "TypeScript language server",
    "typical_mb": 700,
    "peak_mb": 2000
  },
  {
    "label": "rust-analyzer, large workspace",
    "typical_mb": 1200,
    "peak_mb": 4000
  },
  {
    "label": "Headless Chrome, one tab",
    "typical_mb": 350,
    "peak_mb": 900
  },
  {
    "label": "Node test run, 4 workers",
    "typical_mb": 1600,
    "peak_mb": 3000
  },
  {
    "label": "Docker image build",
    "typical_mb": 800,
    "peak_mb": 2500
  }
]

Hizi ni takwimu za kawaida zilizochapishwa kwa miradi ya ukubwa wa wastani. Zichukulie kama mwongozo wa jumla, si kama ahadi kuhusu msimbo wako.

Chati hii ina 6 safu na wakala huyu ndiye wa bei nafuu zaidi. Hukaa karibu na 250 MB wakati haufanyi kazi, kwa sababu unashikilia mazungumzo na akiba ndogo ya faili na hakuna kingine. Seva ya lugha ya TypeScript hufikia takriban 2000 MB wakati inafanya index, kwa sababu hujenga grafu ya aina (type graph) kwa kila faili inayoweza kufikiwa kutoka tsconfig.json yako na kisha kuhifadhi grafu hiyo kwenye kumbukumbu ili kujibu ombi linalofuata haraka. rust-analyzer kwenye workspace kubwa kwa kawaida hupita 4000 MB kwa sababu hiyo hiyo, katika kila crate iliyo kwenye workspace.

Headless Chrome hugharimu takriban 350 MB kwa kivinjari pamoja na tab moja, na kila tab ya ziada ni mchakato mwingine wa mfumo wa uendeshaji. Uendeshaji wa majaribio ya Node wenye wafanyakazi wanne ni michakato minne ya Node, hivyo hufikia kilele karibu na 3000 MB. Ujenzi wa Docker image hufikia kilele karibu na 2500 MB, kwa sababu ujenzi huo huendesha compiler ya mradi wako ndani ya container wakati daemon ikiandika layers.

sudo apt update && sudo apt install -y time
/usr/bin/time -v -o /tmp/build.rusage npm run build
grep "Maximum resident set size" /tmp/build.rusage

Soma safu ya available ya free -h, si safu ya free. Linux hutumia kila ukurasa wa ziada kwa ajili ya akiba ya diski, kwa hivyo free huwa ndogo kwenye seva yenye afya kabisa na haikupi taarifa yoyote muhimu. available ndiyo kiasi ambacho mchakato mpya unaweza kupata kihalisi.

Usanidi tatu zinazofanya kazi

Kiwango cha chini kinachokubalika: 4 GB RAM, 2 vCPU, 50 GB disk. Kikao kimoja cha agent, repository moja, language server moja, na build ambazo uko tayari kuzisubiri. Kiwango hiki hufanya kazi, lakini kitakutana na out-of-memory killer mara ya kwanza jaribio kubwa la test litakapopishana na language server inayofanya indexing. Ongeza swap na uweke kikomo kwa build workers wako.

Starehe: 8 GB RAM, 4 vCPU, 100 GB disk. Agent mmoja, pamoja na Docker, na headless browser kwa ajili ya test, huku kukiwa na nafasi ya ziada kwa ajili ya build spike moja. Hiki ndicho kiwango ambacho watengenezaji programu wengi wanaofanya kazi peke yao wanapaswa kununua. Kuongeza idadi ya vCPU mara mbili pia hupunguza muda wa kusubiri build kwa takriban nusu, na utahisi tofauti hiyo mara nyingi zaidi kuliko unavyohisi kumbukumbu (memory).

Timu: 16 GB RAM, 8 vCPU, 200 GB disk. Vikao vinne vinavyoendeshwa kwa wakati mmoja, kila kimoja kikiwa na checkout yake na toolchain yake. Panga ukubwa kulingana na kilele cha matumizi, kwa sababu agents wanne wasiofanya kazi hawagharimu chochote, wakati majaribio manne ya test yanayoendeshwa kwa wakati mmoja yanagharimu mara nne ya kilele cha safu iliyo hapo juu.

Kufikia Agosti 2026, hatua kutoka safu ya kwanza hadi ya mwisho ni takriban mara nne ya bei ya kila mwezi kwenye malipo ya mwaka ya VPS: dola za tarakimu moja kwa mwezi chini, na makumi ya dola juu. Angalia orodha ya sasa kabla ya kupanga, kwa sababu namba hizo hubadilika. Seva mara chache huwa ndiyo sehemu ya gharama kubwa. Kwa yeyote anayeendesha agent kila siku, bili ya model API huzidi bili ya seva haraka, kwa hivyo weka kikomo cha kile ambacho agent anaruhusiwa kutumia kabla ya kupunguza ukubwa wa seva. Kwa ajili ya build yenyewe, mwongozo wa kuendesha coding agent kwenye VPS unashughulikia usanidi wa akaunti na jinsi ya kuweka kikao kikiwa hai baada ya kukata muunganisho.

Kwa nini diski hujaa kabla ya RAM kuisha

[
  {
    "label": "Ubuntu 24.04 base and toolchain",
    "typical_gb": 6
  },
  {
    "label": "One JS monorepo checkout",
    "typical_gb": 3
  },
  {
    "label": "node_modules across 3 branches",
    "typical_gb": 4
  },
  {
    "label": "Docker images and build cache",
    "typical_gb": 20
  },
  {
    "label": "Agent logs and journal, 90 days",
    "typical_gb": 2
  }
]

Jumlisha safu hizo na utaona diski ya 50 GB inakaribia kujaa kabla hata hujaandika mstari mmoja wa msimbo. Kitu kikubwa zaidi ni Docker kwa takriban 20 GB, kwa sababu BuildKit huhifadhi kila matabaka ya kati (intermediate layer) ya kila build hadi utakapoiambia iache.

docker system df
docker builder prune --filter until=168h

docker system df huonyesha nafasi inayoweza kurejeshwa kwa kila kategoria, kwa hivyo iendeshe kabla na baada ya kusafisha. Kichujio cha until=168h hufuta cache ya build iliyo na umri zaidi ya wiki moja na kuhifadhi ya wiki hii, ambayo ndiyo cache inayokuokoa muda. docker image prune -a huenda mbali zaidi na kuondoa kila image ambayo haina container inayotumia, kwa hivyo tarajia build inayofuata itapakua tena.

Miradi ya Node hushindwa kwa njia ya ajabu zaidi. npm install huandika mamia ya maelfu ya faili ndogo, kwa hivyo mfumo wa faili unaweza kuishiwa na inodes wakati df -h bado inaripoti gigabytes za nafasi iliyo wazi. Uandikaji hushindwa na kutoa kosa la No space left on device kwenye diski inayoonekana kuwa na nafasi ya nusu.

df -h /
df -i /

Ikiwa IUse% inasoma 100, futa saraka za node_modules za matawi (branches) ambayo hutumii tena, au hamia kwenye pnpm, ambayo huhifadhi kila toleo la kifurushi mara moja na kuliunganisha (hard-link) kwenye kila mradi.

Logs ni tatizo la kimya kimya. Wakala anayefanya kazi kila wakati huandika nakala za vikao, na journal ya systemd hukua na kuchukua sehemu kubwa ya diski kwa chaguo-msingi.

sudo journalctl --disk-usage
sudo journalctl --vacuum-size=200M
du -xh --max-depth=1 / 2>/dev/null | sort -h | tail

Weka SystemMaxUse=200M ndani ya /etc/systemd/journald.conf na uendeshe sudo systemctl restart systemd-journald ili kufanya kikomo hicho kuwa cha kudumu, kwa sababu kusafisha mara moja (vacuum) kunarejesha nafasi ya leo pekee.

Swap: faida zake na mambo yanayofichwa

Ni vyema kuongeza swap, kwa sababu inabadilisha matumizi makubwa ya kumbukumbu kuwa kazi ya polepole badala ya kusababisha mchakato kufa. Iweke kwa ukubwa wa nusu ya RAM, hadi kiwango cha juu cha 4 GB. Hakuna sababu ya kuongeza zaidi ya hapo kwenye seva ya ujenzi (build box).

sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
swapon --show

swapon --show sasa inapaswa kuonyesha /swapfile kwa ukubwa uliouomba. Bila mstari wa /etc/fstab, swap hupotea baada ya reboot inayofuata na seva inarudi kwenye tabia yake ya awali kimyakimya. Ikiwa fallocate itajibu Operation not supported, tengeneza faili hiyo kwa kutumia sudo dd if=/dev/zero of=/swapfile bs=1M count=4096 na uendelee kutoka chmod.

echo 'vm.swappiness = 10' | sudo tee /etc/sysctl.d/99-swappiness.conf
sudo sysctl --system

Swappiness ya chini huambia kernel irudishe disk cache kabla ya kusukuma kumbukumbu ya programu kwenye diski, jambo linalosaidia language server kubaki na mwitikio mzuri.

Sasa, sehemu ambayo swap huficha. Wakati kazi inahitaji kumbukumbu zaidi ya ile iliyopo kwenye seva, kernel hutumia muda wake kuhamisha kurasa (pages) kati ya RAM na diski badala ya kuendesha ujenzi wako. Hakuna kinachokwama. Kila kitu kinatembea kwa kusuasua, na load average hupanda wakati CPU haifanyi kazi.

vmstat 1 10

Namba zisizo sifuri zinazobaki thabiti kwenye safu za si na so zinamaanisha swapping inaendelea, kwa hiyo suluhisho ni kupunguza concurrency au kuongeza RAM, na si kuongeza swap zaidi. Kwenye seva ndogo, sudo apt install -y zram-tools hutoa swap iliyoshinikizwa (compressed) inayohifadhiwa kwenye RAM, inayoweza kusanidiwa kwenye /etc/default/zramswap. Ni haraka zaidi kuliko swap file, na hutumia RAM ili kuokoa RAM, kwa hiyo inasaidia kwenye kurasa zisizotumika (cold pages) na si kwenye ujenzi unaohitaji kumbukumbu halisi ya kufanyia kazi.

Kwa nini wakala wako wa kuandika msimbo (coding agent) anaonekana kuganda

Hii ndiyo hitilafu inayotafsiriwa vibaya zaidi kwenye seva ndogo za wakala. Amri haitoi matokeo yoyote, wakala anasubiri, na kipindi (session) kinaonekana kuganda. Mchakato huo uliua na kernel kupitia utaratibu wa out-of-memory (OOM) killer. Ulipewa SIGKILL, kwa hivyo haukuweza kuchapisha hitilafu, kusafisha logi, au kumjulisha wakala kilichotokea. Wakala anaona matokeo matupu na ujumbe wa kutoka haupo.

Kernel inarekodi tukio hilo:

sudo dmesg -T | grep -iE "out of memory|killed process"
sudo journalctl -k -b | grep -i oom

Mstari halisi unaonekana hivi:

[Thu Aug  6 11:02:14 2026] Out of memory: Killed process 4711 (node) total-vm:4210880kB, anon-rss:3820104kB, file-rss:0kB, shmem-rss:0kB, UID:1000 pgtables:8236kB oom_score_adj:0

anon-rss ni kiasi gani mchakato huo ulishikilia ulipokufa. Angalia ni mchakato upi ulichaguliwa: kernel hutoa alama kulingana na kumbukumbu inayotumika, kwa hivyo mara nyingi huua seva ya lugha (language server) au wakala badala ya mchakato wa build uliosababisha tatizo. Hiyo ndiyo sababu dalili inaonekana kama "wakala amevunjika".

Ndani ya Docker tukio lilelile huacha alama iliyo wazi zaidi. Kontena linatoka na code 137, ambayo ni 128 jumlisha signal 9.

docker ps -a
docker inspect "$(docker ps -lq)" | grep -i oomkilled

"OOMKilled": true inathibitisha kuwa kontena lilifikia kikomo chake cha kumbukumbu badala ya kuacha kufanya kazi lenyewe.

Suluhisho ni kuipa amri inayotumia rasilimali nyingi kikomo chake, ili mchakato wa build ufe badala ya wakala:

systemd-run --user --scope -p MemoryMax=4G -- npm run build

Mchakato wa build sasa unauawa kwenye 4 GB na wakala anabaki hai, jambo linalobadilisha kuganda kwa ajabu kuwa amri iliyoshindwa ya kawaida yenye exit code inayosomeka. Hii inahitaji systemd user session, kwa hivyo endesha loginctl enable-linger $USER kwenye seva unayofikia kupitia SSH pekee. MemoryHigh= hupunguza kasi ya mchakato kwenye kikomo hicho badala ya kuuua, ambayo mara nyingi ni mpangilio mzuri zaidi kwa build ambayo ungependa imalize kazi polepole.

Weka kikomo cha kumbukumbu kwa kutumia Compose mara moja

Ikiwa zana za agent zinaendeshwa ndani ya containers, weka ukomo katika faili la Compose ili utumike kila wakati unapoanzisha huduma.

services:
  agent:
    image: node:22-bookworm
    deploy:
      resources:
        limits:
          memory: 2g
          cpus: "1.5"

Docker Compose v2 hutumia deploy.resources.limits kwenye docker compose up ya kawaida, kwa hivyo swarm mode haihusiki. Ufunguo wa zamani wa mem_limit: 2g bado unafanya kazi. Mwongozo kamili wa vikomo vya kumbukumbu vya Compose unaelezea kuhusu reservations na nini hutokea wakati container inafikia ukomo wake. Ikiwa Docker haipo kwenye seva bado, sakinisha Docker kwenye VPS kwanza.

Mtego mmoja huwapa watu wakati mgumu. Container iliyowekewa kikomo cha 2 GB bado inasoma /proc/meminfo ya host na idadi ya CPU za host, kwa sababu hakuna kati ya hizi iliyo na namespace yake. Kijaribu programu (test runner) kinachochagua idadi ya wafanyakazi (workers) kulingana na idadi ya CPU kitaanzisha wafanyakazi wanane ndani ya container ya 2 GB kwenye host yenye vCPU nane, kisha kitakufa kwa error 137. Weka namba hizi kwa mkono:

npx jest --maxWorkers=2
export NODE_OPTIONS=--max-old-space-size=1536

--max-old-space-size iko katika MB na huweka ukomo wa V8 heap. Iweke chini ya kikomo cha container ili Node itoe error unayoweza kuisoma badala ya kupotea ghafla:

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory

Ujumbe huo ni msaada mkubwa, kwa sababu unataja kikomo kilichofikiwa na mchakato uliokifikia. OOM killer haifanyi hivyo kamwe.

Kuendesha vipindi vingi vya wakala kwenye seva moja

Panga kulingana na kipindi, si kulingana na mtu. Vipindi viwili kwenye hazina (repository) moja bado inamaanisha seva mbili za lugha, seti mbili za akiba ya ujenzi (build caches) kwenye kumbukumbu, na majaribio mawili ya utendaji ikiwa mawakala wote wawili wataanza kufanya kazi kwa wakati mmoja. Hii ndiyo sababu safu ya timu inaruka hadi 16 GB.

Weka kikomo kigumu kwa kila mtumiaji ili kipindi kimoja kisichodhibitiwa kisiweze kusababisha seva nzima kuzima:

id -u alice
sudo mkdir -p /etc/systemd/system/user-1001.slice.d
printf '[Slice]\nMemoryMax=6G\n' | sudo tee /etc/systemd/system/user-1001.slice.d/limit.conf
sudo systemctl daemon-reload
systemctl show user-1001.slice -p MemoryMax

Badilisha 1001 na UID ambayo id -u ilichapisha. systemctl show inapaswa kutoa MemoryMax=6442450944 pindi mtumiaji atakapoingia kwenye mfumo. Wakati kila kitu katika kipindi cha mtumiaji huyo kinapozidi 6 GB, kernel huua mchakato ndani ya slice yake na kila kipindi kingine kinaendelea kufanya kazi. Kwa wakala anayeendesha kama huduma badala ya terminal, weka MemoryMax= kwenye faili yake ya unit badala yake, ambayo ndiyo muundo wa kufuata unapofanya self-host wakala kama huduma inayowaka kila wakati.

FAQ

Je, 2 GB ya RAM inatosha kwa coding agent?

Kwa mchakato wa agent, ndiyo. Kwa kazi inazofanya, mara chache sana. Agent hutumia takriban 250 MB, lakini language server moja ya TypeScript inaweza kufikia 2000 MB kwenye repository ya ukubwa wa wastani, na hilo pekee linaweza kusukuma seva ya 2 GB kwenye swap. 2 GB inatosha kwa kuhariri faili za usanidi na script ndogo. Tumia 4 GB kama kiwango cha chini kwa chochote kinachokusanya (compile) au kuendesha test suite.

Je, nahitaji GPU ili kuendesha coding agent kwenye VPS?

Hapana, ikiwa agent inaita cloud model kupitia API. Mzigo huo wa kazi unategemea mtandao, kwa hivyo VPS ya CPU ya kawaida ndiyo mashine sahihi na GPU itabaki bila kazi kwa bei ya juu zaidi. Unahitaji GPU tu wakati model yenyewe inaendeshwa kwenye mashine hiyo hiyo, na hapo swali hubadilika kutoka RAM kwenda VRAM na ukubwa wa model.

Ni kiasi gani cha swap ninapaswa kuongeza kwenye VPS ya agent?

Nusu ya RAM, hadi kiwango cha juu cha 4 GB. Swap inakulinda dhidi ya matumizi ya muda mfupi ya kumbukumbu kupita kiasi, kwa sababu kernel inaweza kuhamisha kurasa zisizotumika kwenda kwenye diski badala ya kuua mchakato (process). Haiongezi kumbukumbu inayoweza kutumika. Ikiwa vmstat 1 inaonyesha trafiki ya mara kwa mara kwenye safu za si na so, mashine inafanya kazi kupita kiasi (thrashing), na suluhisho ni kupunguza idadi ya wafanyakazi (workers) wanaofanya kazi kwa wakati mmoja au kupandisha mpango wa seva.

Kwa nini coding agent yangu huganda katikati ya build?

Build hiyo karibu kila mara imeuawa na OOM killer ya kernel, ambayo hutuma SIGKILL, kwa hivyo hakuna kinachochapishwa na agent husubiri kwenye pipe ambayo haijai. Endesha sudo dmesg -T | grep -i "killed process" na uangalie jina la mchakato na thamani yake ya anon-rss. Tatua hili kwa kupunguza kasi ya build kwa kutumia systemd-run --user --scope -p MemoryMax=4G na kupunguza idadi ya wafanyakazi, au kwa kupandisha kiwango cha RAM.