Ruka hadi maudhui makuu
Mafunzo ya AI

Endesha GLM-5.3-Flash kwenye RTX 3090 moja ya GB 24 kwa kutumia RAM ya kompyuta

Mafunzo haya yanaeleza jinsi glm53-flash-offload inavyounganisha kumbukumbu ya mwenyeji iliyobandikwa, akiba inayonyumbulika ya wataalamu kwenye GPU, ufikiaji wa PCIe bila kunakili, na ukokotoaji wa hiari wa CPU wa AVX2 ili kuendesha GLM-5.3-Flash kwenye GPU moja ya NVIDIA yenye GB 24. Utaweka picha ya Docker, uchague hali ya haraka au sahihi, uitishe API, uthibitishe utendaji, na urekebishe uwekaji.

Endesha GLM-5.3-Flash kwenye RTX 3090 moja ya GB 24 kwa kutumia RAM ya kompyuta

Muhtasari

glm53-flash-offload huendesha muundo wa GLM-5.3-Flash wenye ukubwa wa GB 125.3, EXL3 3.05-bpw, kwenye GPU moja ya NVIDIA yenye GB 24 pamoja na kumbukumbu ya mwenyeji ya DDR4. Hutoa API ya HTTP inayooana na OpenAI huku ikiweka uzani wa mixture-of-experts uliopangwa wa modeli hasa kwenye RAM ya mfumo iliyobandikwa.

Mradi huu ni mkusanyiko mwembamba wa monkeypatches juu ya exllamav3 1.5.1 ya kawaida, ukisaidiwa na kernels kadhaa ndogo maalum. Hauhitaji kuhariri msimbo wa exllamav3. Usanidi uliorekodiwa ulipimwa kwenye RTX 3090 iliyounganishwa kupitia PCIe 4.0 x16 kwenye mfumo wa AMD EPYC 7443P.

Wazo kuu ni kuweka wataalamu wanaotumiwa mara kwa mara kwenye akiba inayonyumbulika ya GPU. Wataalamu ambao hawapatikani kwenye akiba wanaweza kusomwa moja kwa moja kutoka kwenye kumbukumbu ya mwenyeji iliyobandikwa kupitia PCIe. Katika hali ya kasi, ukosefu wa akiba wa decode wenye ubaridi zaidi unaweza badala yake kuchakatwa na worker wa CPU wa AVX2.

Vipengele muhimu

  • Uendeshaji kwenye GPU moja: huendesha GLM-5.3-Flash kwa kutumia GPU moja ya daraja la RTX 3090 yenye GB 24.
  • API inayooana na OpenAI: inasaidia ukamilishaji wa mazungumzo, ukamilishaji wa maandishi, ugunduzi wa modeli, utiririshaji, maudhui ya hoja, na miito ya zana ya mtindo wa OpenAI.
  • Hifadhi iliyobandikwa isiyohitaji kunakili: wataalamu wote waliopangwa huhifadhiwa kwenye RAM ya mwenyeji iliyobandikwa na wanaweza kufikiwa kupitia CUDA unified virtual addressing.
  • Akiba nyumbulifu ya wataalamu kwenye GPU: wataalamu wanaotumika sana huchukua VRAM inayopatikana, huku nafasi ya akiba ikiweza kurejeshwa kwa muda kwa ajili ya uamilisho wa long-prefill na buffer za staging.
  • Staging ya prefill: wataalamu wasio kwenye akiba hunakiliwa safu moja mapema ili uhamishaji wa PCIe uende sambamba na ukokotoaji.
  • Tabaka la hiari la CPU: hali ya kasi hutuma baadhi ya ukosefu wa akiba wenye ubaridi wa decode kwenye kernel ya CPU ya AVX2.
  • Decode iliyopangwa kwa mafungu: hadi mitiririko minne inaweza kufanya decode pamoja kwa usanidi uliorekodiwa wa -ambs 4.
  • Usanidi unaoweza kurudiwa: marekebisho ya modeli, container digest, toleo la exllamav3, chaguo za Triton, vipimo, na paneli ya marejeo ya ubora vimebainishwa.

Chagua kati ya hali ya kasi na hali sahihi

Seva hutoa hali mbili za uendeshaji kupitia kigezo cha mazingira cha GLM53_MODE.

Hali ya kasi

fast ndiyo chaguo-msingi. Inachanganya akiba ya wataalamu kwenye GPU, ukosefu wa akiba usiohitaji kunakili, uchakataji wa CPU wa AVX2 kwa baadhi ya ukosefu wa akiba wenye ubaridi wa decode, decode iliyopangwa kwa mafungu, na kernels zilizounganishwa za decode. Kwenye mwenyeji uliopimwa, ilitumia takriban GiB 218, au GB 234, za RAM ya mwenyeji.

Kampeni iliyochapishwa ilipima takriban tokeni 28.15 kwa sekunde kwa mtiririko mmoja wa decode, tokeni 31.57 kwa sekunde kwa jumla kwa mitiririko miwili, na tokeni 33.98 kwa sekunde kwa jumla kwa mitiririko minne. Jaribio la picha la smoke la digest ya sasa lilipima tokeni 28.88, 31.27, na 35.00 kwa sekunde kwa jumla mtawalia.

Onyo kuhusu ubora: prefill ni sahihi, lakini decode ya hali ya kasi si sawa kabisa kwa kila biti ikilinganishwa na exllamav3 ya kawaida. Ukaguzi wa decode uliooanishwa uliripoti KL wastani ya 0.0053 na makubaliano ya top-1 ya 0.977. Tumia hali sahihi wakati ulinganifu wa matokeo unahitajika.

Hali sahihi

exact huzima tabaka la CPU na kernels za decode za hali ya kasi pekee. Inahifadhi akiba ya wataalamu kwenye GPU na ukosefu wa akiba wa kumbukumbu ya mwenyeji usiohitaji kunakili. Paneli ya marejeo ilipima makubaliano ya top-1 ya 1.0000 na KL ya 0, huku matumizi ya kumbukumbu ya mwenyeji yakiwa takriban GiB 111, au GB 119.

Hali sahihi ni ya polepole zaidi lakini hutumia RAM kidogo sana. Kiwango kilichopimwa cha decode ya mtiririko mmoja kilikuwa tokeni 12.57 kwa sekunde katika muktadha mfupi uliopimwa, ikilinganishwa na takriban tokeni 7.5 hadi 8.4 kwa sekunde wakati exllamav3 ya kawaida iliweka wataalamu wasiotoshea kwenye worker wake wa CPU.

Mahitaji ya maunzi na programu

GPU na kiendeshi

  • GPU moja ya NVIDIA yenye VRAM ya GB 24.
  • GPU ya sm_86 kama RTX 3090 au A5000 ndiyo lengo lililopimwa.
  • Binari zilizojumuishwa za sm_86 pia hufanya kazi kwenye sm_89, ikiwemo RTX 4090, lakini usanidi huo haukupimwa.
  • Kiendeshi cha NVIDIA kinachoweza kutumia CUDA 13.0 kinahitajika kwa sababu image hutumia CUDA 13.0.3.
  • PCIe 4.0 x16 inapendekezwa. Ukosefu wa akiba hutumia takriban GB/s 25 kwenye kiungo kilichopimwa.

Kumbukumbu ya mwenyeji

  • Hali ya kasi: kumbukumbu ya jumla ya GiB 256 ndiyo kiwango cha chini kabisa wakati programu nyingine chache zinafanya kazi; GB 320 au zaidi inapendekezwa. Ikiwa vikomo vya kumbukumbu vya Docker vinatumika, ruhusu angalau 230g.
  • Hali sahihi: GiB 128 ndiyo kiwango cha chini, huku GB 160 au zaidi ikipendekezwa.

CPU na hifadhi

  • Hali ya kasi inahitaji CPU ya x86-64 yenye AVX2, FMA, na F16C.
  • Takriban cores 24 za kimwili na DDR4 ya njia nane au bora zaidi vinapendekezwa kwa tabia ya hali ya kasi iliyopimwa.
  • Checkpoint inachukua takriban GiB 117, au GB 125.3, kwenye diski.
  • Hifadhi ya NVMe inapendekezwa ili kupunguza muda wa kupakia modeli.
  • Docker, NVIDIA Container Toolkit, na Hugging Face CLI zinahitajika kwa usanidi uliorekodiwa.

Sakinisha na uanzishe seva kwa Docker

Hatua ya 1: Pakua checkpoint

Pakua checkpoint ya 3.05-bpw iliyobainishwa kwenye saraka ya ndani:

hf download turboderp/GLM-5.3-Flash-exl3 \
  --revision 3.05bpw \
  --local-dir /data/GLM-5.3-Flash-exl3-3.05bpw

Badala yake unaweza kuweka saraka tupu kwenye /models. Ikiwa config.json haipo, container itapakua checkpoint iliyosanidiwa kwenye saraka hiyo.

Hatua ya 2: Anzisha hali ya kasi

Amri ifuatayo huanzisha seva kwenye GPU 0 na kuichapisha kwenye porti 30000. Inatumia image digest iliyo na marekebisho ya uwasilishaji wa utiririshaji.

docker run -d \
  --name glm53 \
  --gpus '"device=0"' \
  --ulimit memlock=-1 \
  --shm-size 16g \
  -p 30000:30000 \
  -v /data/GLM-5.3-Flash-exl3-3.05bpw:/models \
  ghcr.io/0xsero/glm53-flash-offload@sha256:bb633b0bcb85573ad40b6c408af5e1036ae062c593e42479f4e4d2ab521e551d

Mpangilio wa --ulimit memlock=-1 unapendekezwa kwa sababu seva inafunga kiasi kikubwa cha kumbukumbu ya mwenyeji. Picha iliyochapishwa pia ilipakiwa bila mpangilio huu kwenye kiendeshi kilichopimwa, lakini tabia hiyo haipaswi kudhaniwa kwa kila mwenyeji.

Hatua ya 3: Fuatilia uanzishaji

docker logs -f glm53

Subiri ujumbe unaojumuisha loaded in ... s. Uanzishaji huchukua takribani dakika mbili hadi tatu kwenye mfumo uliorekodiwa, kutegemea akiba na hali za mwenyeji.

Hatua ya 4: Thibitisha afya

curl -s http://localhost:30000/health

Endesha hali halisi

Ili kutanguliza ulinganifu wa matokeo na kupunguza matumizi ya kumbukumbu ya mwenyeji, ongeza -e GLM53_MODE=exact:

docker run -d \
  --name glm53-exact \
  --gpus '"device=0"' \
  --ulimit memlock=-1 \
  --shm-size 16g \
  -p 30000:30000 \
  -e GLM53_MODE=exact \
  -v /data/GLM-5.3-Flash-exl3-3.05bpw:/models \
  ghcr.io/0xsero/glm53-flash-offload@sha256:bb633b0bcb85573ad40b6c408af5e1036ae062c593e42479f4e4d2ab521e551d

Usiendeshe mifano ya haraka na halisi kwenye mlango mmoja kwa wakati mmoja. Simamisha na uondoe kontena la kwanza kabla ya kubadilisha hali:

docker rm -f glm53

Matumizi ya msingi ya API

Tuma ukamilishaji wa mazungumzo

curl -s http://localhost:30000/v1/chat/completions \
  -H 'content-type: application/json' \
  -d '{"model":"glm-5.3-flash","messages":[{"role":"user","content":"Explain zero-copy model offloading."}],"max_tokens":512}'

Jina chaguo-msingi la modeli inayotolewa ni glm-5.3-flash. Isipokuwa lisanidiwe wazi, max_tokens kwa chaguo-msingi hutumia muktadha uliosalia badala ya kuwekewa kikomo kidogo kisichobadilika.

Zima kufikiri

Ufikiri wa GLM hurudishwa katika reasoning_content. Ili kuzima kufikiri kwa ombi, pitisha chaguo la kiolezo cha mazungumzo:

curl -s http://localhost:30000/v1/chat/completions \
  -H 'content-type: application/json' \
  -d '{"model":"glm-5.3-flash","messages":[{"role":"user","content":"Reply with one sentence."}],"chat_template_kwargs":{"enable_thinking":false},"max_tokens":128}'

Tiririsha jibu

curl -N http://localhost:30000/v1/chat/completions \
  -H 'content-type: application/json' \
  -d '{"model":"glm-5.3-flash","messages":[{"role":"user","content":"Write a short explanation of mixture-of-experts models."}],"stream":true,"max_tokens":512}'

Tumia digest iliyobandikwa bb633b0b... iliyoonyeshwa hapo juu. Picha ya zamani ya 1159044a... ilizalisha kwa kasi kamili lakini iliwasilisha matukio ya utiririshaji kwa takribani nusu ya kasi kabla ya kusafisha foleni iliyokusanyika mwishoni.

Orodhesha modeli zinazopatikana

curl -s http://localhost:30000/v1/models

Kagua takwimu za wakati wa utekelezaji

curl -s http://localhost:30000/stats

Kiisho cha takwimu kinajumuisha taarifa za mipigo ya akiba ya wataalamu na vihesabu vya ngazi ya CPU. Vikiisho vya ziada vinajumuisha /v1/completions, /server_info, na njia zenye muundo wa SGLang za /generate na /tokenize.

Usambazaji huu ni wa maandishi pekee. Mnara wa kuona wa checkpoint haujapakiwa.

Tumia zana za mtindo wa OpenAI

Kiisho cha mazungumzo kinakubali sehemu ya tools. Vielezi vya zana vinavyotolewa katika muundo wa ndani wa GLM wa <tool_call> hubadilishwa kuwa tool_calls zinazoendana na OpenAI katika jibu. Kwa hiyo programu za mteja zinaweza kutumia mzunguko wa kawaida wa kuita zana: tuma ufafanuzi wa zana, kagua mwito wa zana wa msaidizi, tekeleza chaguo la kukokotoa, kisha tuma matokeo ya zana kama ujumbe mwingine.

Rekebisha muktadha na hoja za seva

Hoja zilizowekwa baada ya jina la picha huongezwa kwenye amri ya seva, na thamani ya mwisho ndiyo hutumika. Kwa mfano, tumia akiba ya KV ya tokeni 65,536 kwa:

docker run -d \
  --name glm53-64k \
  --gpus '"device=0"' \
  --ulimit memlock=-1 \
  --shm-size 16g \
  -p 30000:30000 \
  -v /data/GLM-5.3-Flash-exl3-3.05bpw:/models \
  ghcr.io/0xsero/glm53-flash-offload@sha256:bb633b0bcb85573ad40b6c408af5e1036ae062c593e42479f4e4d2ab521e551d \
  -cs 65536

Akiba ndogo ya KV inaweza kuacha nafasi ya nafasi zaidi za akiba ya wataalamu. Usanidi wa benchmark iliyochapishwa ulitumia akiba ya KV ya tokeni 131,072, ukubwa wa juu wa kundi wa nane, na ukubwa wa vipande wa tokeni 8,192.

Sakinisha bila Docker

Usakinishaji wa asili unahitaji exllamav3 1.5.1 iliyojengwa kwa GPU lengwa. Kutoka kwenye nakala ya mradi, endesha kisakinishi cha kiendelezi kisha uanzishe entrypoint iliyotolewa ukiwa umeweka njia za hifadhi na modeli:

scripts/install.sh
GLM53_ROOT=$PWD \
GLM53_MODEL_DIR=/path/to/model \
docker/entrypoint.sh

Kisakinishi hujenga viendelezi maalum vya mradi. Docker inasalia kuwa njia inayoweza kurudiwa kwa uhakika zaidi kwa sababu hufunga CUDA, PyTorch, Triton, SGLang, exllamav3, commit ya mradi, na usanidi wa seva uliopimwa.

Thibitisha ubora na utendaji

Pima paneli ya marejeo

Ukiwa kwenye nakala ya hifadhi, tumia mteja wa benchmark aliyejumuishwa unaotumia maktaba ya kawaida pekee:

python3 bench/score_ref_panel.py \
  --url http://127.0.0.1:30000 \
  --panel reference/glm-5.3-flash-exl3-ref-panel.json \
  --out score.json

Paneli inayolazimisha mwalimu inapaswa kuripoti makubaliano ya top-1 ya 1.0000 na KL 0 katika hali za haraka na halisi. Paneli hii hutathmini njia ya kujaza awali au kulazimisha mwalimu na haithibitishi kuwa usimbaji wa kujirudia wa hali ya haraka ni halisi.

Endesha majaribio ya kasi

python3 bench/sweep.py \
  --url http://127.0.0.1:30000 \
  --card rtx-3090-24gb/glm-5.3-flash-offload \
  --template glm \
  --config "bb633b0b fast" \
  --prefill 8192 32768 \
  --conc 1 2 4 \
  --reps 3 \
  --dec-reps 2 \
  --no-early-exit \
  --out sweep.json

Thibitisha uwasilishaji wa mtiririko

python3 bench/stream_rate.py --url http://127.0.0.1:30000

Matokeo yanayofaulu yanapaswa kuonyesha maandishi yakifika kwa mtiririko sawa, badala ya takriban nusu ya jibu kuonekana katika mlipuko wa mwisho.

Urekebishaji wa hali ya juu

Panga ukubwa wa kiwango cha CPU

Kwa chaguo-msingi, GLM53_CT_CPUS=auto huchagua CPU moja ya kimantiki kwa kila kiini halisi na kuacha viini viwili vya kwanza vya kimwili vipatikane kwa mfumo wa uendeshaji na nyuzi ya Python inayoendesha GPU. Kwenye mwenyeji aliyepimwa wenye viini 24, hii ilisababisha CPU 2 hadi 23 na nyuzi 22 za wafanyakazi.

Kwa upangaji wa wazi, weka thamani kama hizi:

-e GLM53_CT_CPUS=2-23 \
-e GLM53_CT_THREADS=22

Muundo wa gharama ya CPU hutumia GLM53_CT_B, iliyopimwa kuwa milisekunde 0.104 kwa mtaalamu mmoja kwa nyuzi 22. Kwa N nyuzi za wafanyakazi, README inapendekeza kuikadiria kama 0.104 x 22 / N. Kwa mfano, mwenyeji wenye viini 16 unaoacha viini viwili huru ungetumia nyuzi 14 za wafanyakazi na thamani iliyo karibu na 0.16.

Kwa chini ya takriban viini 12 vya kimwili, misses nyingi zinatarajiwa kurudi kwenye njia ya PCIe, na hivyo kufanya utendaji ukaribie hali sahihi. Katika hali hiyo, hali sahihi inaweza kuwa chaguo bora.

Dhibiti mpangilio wa kumbukumbu wa kiwango cha CPU

GLM53_CT_SWZ=1 hufanya kiwango cha CPU kitumie nakala tofauti yenye wataalamu waliopangwa kwa vizuizi mfululizo. Huu ndio usanidi wa kasi uliopimwa na huongeza takriban GB 114.2 za matumizi ya RAM. Kuiweka kuwa 0 hufanya kiwango cha CPU kisome moja kwa moja nakala ya nyumbani iliyobandikwa, hivyo kupunguza matumizi ya kumbukumbu kwa kiasi kikubwa, lakini mradi unaripoti kuwa kipimo cha kernel ya mtaalamu wa CPU huwa polepole kwa takriban 40%. Utendaji wa mwisho hadi mwisho wa mpangilio huu haukupimwa.

Rekebisha akiba zilizotengwa

GLM53_EC_RESERVE_GB huacha VRAM ikiwa huru baada ya kutenga akiba ya wataalamu. Chaguo-msingi ni GB 1.5 katika hali ya kasi na GB 1.0 katika hali sahihi. Weka akiba ya hali ya kasi kuwa GB 1.5 isipokuwa prefill ndefu zikose kumbukumbu.

GLM53_EC_ELASTIC_GB kwa chaguo-msingi ni GB 10. Kiasi hiki cha kumbukumbu ya akiba kinaweza kutolewa kwa ajili ya uamilisho wa prefill na uwekaji wa muda, kisha kudaiwa tena kwa decode. GLM53_EC_STAGE_GB kwa chaguo-msingi ni GB 2.6 kwa kila bafa ya uwekaji wa muda, huku bafa mbili zikitumika kwa mwingiliano.

Tumia GPU kubwa zaidi

Akiba ya wataalamu hujiweka ukubwa kulingana na VRAM inayopatikana baada ya kupakia modeli na akiba iliyosanidiwa. Kwa hivyo, kadi ya GB 32 au GB 48 hupokea nafasi zaidi za wataalamu, jambo linalopaswa kuongeza kiwango cha hits na kuboresha utendaji wa decode. Matokeo ya kadi hizi kubwa hayajatolewa kwenye README.

RTX 4090 inaweza kuendesha build iliyojumuishwa ya sm_86, ingawa haikupimwa. Blackwell inahitaji kujengwa upya kwa:

TORCH_CUDA_ARCH_LIST="8.6;12.0"

Pini mpya ya Triton inaweza pia kuhitajika kwenye usanifu mwingine. Ukiunda moja, thibitisha kuwa paneli ya marejeo bado iko kwenye top-1 1.0000 na KL 0.

Linda chaguo sahihi za Triton

Image huweka chaguo za kernel za prefill za umakini wa mstari wa KDA kupitia data/triton_pin_exact.json. Kuiruhusu Triton kuchagua usanidi tofauti kunaweza kubadilisha mzunguko wa makadirio ya namba za kuelea. Weka GLM53_TRITON_PIN kwenye chaguo-msingi lake wakati tabia ya prefill inayolingana na marejeo ni muhimu.

Jinsi mfumo wa offloading unavyofanya kazi

  1. Pakia wataalamu walioelekezwa kwenye kumbukumbu ya mwenyeji iliyobandikwa. Kila safu hupokea eneo la kumbukumbu lililobandikwa lenye ukubwa halisi, na vielekezi vya wataalamu vya exllamav3 hurejelea lakabu za CUDA UVA.
  2. Jaza akiba ya CLOCK inayonyumbulika kwenye VRAM. Chaguo za router huondolewa marudio, hits za akiba huwekwa alama, na waathiriwa huchaguliwa kwa misses zilizokubaliwa.
  3. Soma wataalamu wasiokuwa kwenye akiba kupitia PCIe. Kernels za exllamav3 zinaweza kufikia uwakilishi uliobandikwa wa mwenyeji bila nakala ya kusawazisha upande wa mwenyeji.
  4. Weka prefill ndefu kwa hatua. Kwa idadi kubwa ya kutosha ya chaguo kwa kila safu, wataalamu wanaokosekana hunakiliwa kwenye bafa ya uwekaji wa muda safu moja mbele huku safu iliyotangulia ikihesabu.
  5. Gawanya misses zilizochaguliwa za decode katika hali ya kasi. Muundo wa gharama hutuma misses zenye joto zaidi kupitia utekelezaji wa GPU usio na nakala, na misses baridi zilizochaguliwa kwenye kiwango cha CPU.
  6. Unganisha matokeo ya CPU na GPU. CPU huchapisha kazi yake kupitia kumbukumbu iliyopachikwa na iliyobandikwa, na GPU huongeza sehemu ya FP32 inayotokana baada ya kusubiri alama ya upande wa kifaa badala ya usawazishaji wa mwenyeji.

Maonyo ya kiutendaji

  • Tumia GLM53_MODE=exact wakati matokeo ya decode lazima yalingane na exllamav3 ya kawaida.
  • Epuka image ya zamani ya sha256:1159044a... ikiwa muda wa kusubiri wa mtiririko ni muhimu. Tumia digest iliyoandikwa sha256:bb633b0b....
  • Hali ya kasi kwa sasa huhifadhi nakala mbili za wataalamu kwenye RAM ya mwenyeji. Hakikisha kuna kumbukumbu ya kutosha kabla ya kuanzisha kontena.
  • Usichukulie kuwa throughput iliyopimwa kwenye RTX 3090 itapatikana kwenye viungo vya PCIe vya polepole. Kasi ya decode huathiriwa na trafiki ya misses za akiba.
  • Fuatilia /stats, kumbukumbu ya mfumo, na kumbukumbu ya GPU unapobadilisha ukubwa wa muktadha, akiba iliyotengwa, mwingiliano, au mipangilio ya uwekaji wa muda.
  • Seva hushughulikia maandishi pekee; ingizo la picha halitumiki katika deployment hii.

Hitimisho

glm53-flash-offload hufanya checkpoint kubwa isiyo ya kawaida ya mchanganyiko wa wataalamu iweze kutumika kwenye GPU moja ya GB 24 kwa kuchanganya hifadhi ya mwenyeji iliyobandikwa, usomaji wa PCIe usio na nakala, akiba ya VRAM inayonyumbulika, uhamishaji wa prefill kwa hatua, na kiwango cha hiari cha CPU cha AVX2. Anza na Docker image iliyowekwa pini, chagua hali sahihi kwa uaminifu wa matokeo au hali ya kasi kwa throughput, kisha thibitisha usakinishaji kwa ukaguzi wa ubora, kasi, na mtiririko uliojumuishwa kabla ya kurekebisha mipangilio ya akiba au CPU.