Source: RT @Serantych: Kimi’s CEO Zhilin Yang: (build many agents, not one smarter one) · twitter

What this means for ThakiCloud

Paxis already does the thing this news describes. It orchestrates a crowd of agents like a conductor, so when one worker stalls another role steps in to route around the wall. Metis carries the inference that keeps the swarm running. But the real price of collaboration is infrastructure. More agents means more calls, more GPUs, more billing. Run that swarm inside your own facility, on-prem, and the math flips. Deploy as many agents as you like and the invoice never leaks to someone else’s ledger, while the wall you clear stays your own. A sovereign on-prem floor to release the crowd on: that’s the Paxis and Metis pitch.

An auto-generated comic riffing on this week’s industry news.

무엇이 화제였나

칭화대 MADSYS 연구실이 공개한 ktransformers(kvcache-ai/ktransformers, Apache 2.0, 별 1.7만 개)의 아이디어는 한 문장으로 요약됩니다. MoE 모델에서 실제로 호출되는 전문가(expert)만 GPU 근처에 두고, 대부분의 시간 놀고 있는 전문가는 CPU 메모리에 앉혀 두었다가 필요할 때 부릅니다. 이 배치로 24GB VRAM에서 DeepSeek-V3와 R1을 139K 컨텍스트로 돌리고, 표준 설정 대비 최대 28배 빠르다는 이야기가 퍼졌습니다.

트릭 자체는 거의 허무할 정도로 단순합니다. 그래서 오히려 의심스러웠습니다. 정말 공짜 점심인지, 아니면 어딘가에 청구서가 숨어 있는지 확인하려면 숫자를 직접 뽑아보는 수밖에 없었습니다.

실험 설계: 작은 모델로 메커니즘을 분리한다

DeepSeek-V3는 671B라 24GB 카드에 실을 수 없습니다. 그래서 같은 계열(MLA + fine-grained MoE)의 축소판인 Qwen3-30B-A3B(총 30B, 활성 3.3B)를 대리 모델로 삼았습니다. 목적은 벤더의 671B 숫자를 재현하는 게 아니라, “전문가를 CPU에 내려놓는다”는 메커니즘이 실제로 이득을 주는지, 준다면 그 이득이 어디서 오는지를 분해하는 것이었습니다.

측정은 두 단계로 나눴습니다. 첫째, 상용 AMD 박스에서 메커니즘 자체의 효과를 봅니다. 둘째, ktransformers가 성능의 원천이라 주장하는 Intel AMX 커널을 별도로 측정합니다.

1차: 상용 4090 + AMD에서 메커니즘을 측정하다

RunPod에서 RTX 4090(24GB)에 AMD Ryzen 9 7950X, 188GB RAM 구성을 빌렸습니다. 여기서 첫 번째 숨은 전제가 바로 드러났습니다. ktransformers의 CPU 전문가 커널은 Intel AMX 명령어에 최적화되어 있는데, 이 AMD CPU에는 AMX가 없었습니다. 그래서 ktransformers 고유 커널 대신, 완전히 같은 트릭을 구현한 llama.cpp의 --n-cpu-moe(전문가를 CPU에, 어텐션과 KV 캐시를 GPU에)로 메커니즘만 깨끗하게 쟀습니다.

Qwen3-30B-A3B를 Q4로 양자화해 세 가지 배치로 디코딩 속도를 비교했습니다.

여기서 두 가지가 보입니다. 메커니즘은 순수 CPU보다 1.62배 빠릅니다. 어텐션을 GPU로 올린 대가로 실제로 이득을 봤습니다. 그런데 모델이 VRAM에 통째로 들어가는 경우(Q4는 18GB라 24GB에 들어갑니다) full-GPU가 메커니즘을 22배 앞섰습니다. 다시 말해, 모델이 GPU에 들어가기만 하면 전문가를 CPU로 내려보내는 선택은 손해입니다. 이 트릭이 의미를 갖는 순간은 오직 모델이 VRAM을 넘칠 때입니다. 그때는 “12 tok/s로라도 돈다”가 가치이지, 속도 자체가 목적이 아닙니다.

2차: Intel AMX 커널의 진짜 배수를 재다

28배의 근거라는 AMX 커널을 정면으로 보려면 Sapphire Rapids 세대 Xeon이 필요했습니다. RunPod에서 H100 파드를 몇 번 띄워 CPU를 확인한 끝에, Intel Xeon Platinum 8470(AMX bf16/int8/tile 지원), 208 vCPU, 1TB RAM이 걸린 호스트를 잡았습니다.

kt_kernel 패키지는 백엔드별 커널을 모두 담고 있어서, 같은 프로세스 안에서 AMX 커널과 AVX2 커널을 동일한 BF16 가중치로 나란히 돌릴 수 있었습니다. DeepSeek-V3 규모(전문가 256개, 히든 7168)의 MoE 순전파를 두 커널로 측정했습니다.

AMX 커널은 AVX2보다 1.38배 빨랐습니다. 분명한 이득이지만, 28배와는 거리가 멉니다. INT8 전용 타일 연산까지 쓰면 이 배수는 더 벌어질 여지가 있으나(비용 때문에 이번엔 BF16 동일 정밀도 비교까지만 했습니다) 커널 하나가 28배를 만들어내지는 않습니다.

“28배”를 분해하면

두 실험을 합치면 벤더의 28배가 어떻게 구성되는지가 보입니다. 그 숫자는 커널의 마법이 아니라, 시스템 전체를 llama.cpp의 순수 CPU 실행과 비교한 값입니다. 분해하면 이렇게 나뉩니다.

어텐션과 KV 캐시를 GPU로 올린 것이 가장 큰 지렛대입니다. 상용 AMD에서도 이 배치만으로 순수 CPU 대비 1.62배가 났고, 모델이 GPU에 들어가면 35배까지 벌어졌습니다. 그 위에 AMX 전문가 커널이 AVX2 대비 약 1.4배를 더합니다. 여기에 INT8/INT4 양자화와 파이프라인 최적화가 얹힙니다. 각 요소는 소박한 배수지만, 특정 조건에서 이것들이 곱해지면 두 자릿수 배수가 만들어집니다. 그 조건이란 모델이 VRAM을 넘치고, CPU가 AMX를 지원하며, 비교 대상이 순수 CPU llama.cpp일 때입니다.

“40만 달러를 24GB로”의 진실

이 문구는 메모리를 없앤 게 아니라 옮긴 것입니다. 우리 파드는 각각 188GB와 1TB의 시스템 RAM을 갖고 있었습니다. DeepSeek-V3를 Q4로 돌리려면 CPU 쪽에 약 380GB의 DRAM이 필요합니다. 전문가 가중치는 사라지지 않고 VRAM에서 시스템 RAM으로 자리를 옮길 뿐입니다. 그러니 정확한 표현은 “24GB GPU 한 장 + 대용량 RAM 서버”입니다. 비싸진 GPU를 값싼 RAM으로 바꾼 것이지, 총 메모리 소요가 준 것은 아닙니다. 소비자용 24GB 카드 한 장이 데이터센터 랙을 대체한다는 그림과는 결이 다릅니다.

그래서 도입해야 하나

세 가지 조건을 먼저 확인하길 권합니다. 서빙 CPU가 Intel Sapphire Rapids 이상(AMX 지원)인가. 돌리려는 모델이 GPU VRAM을 실제로 넘치는 대형 MoE(V3, R1 급)인가. 그리고 그 대형 모델을 담을 대용량 시스템 RAM이 있는가. 세 조건이 모두 맞으면 ktransformers는 값비싼 다중 GPU 없이 대형 MoE를 서빙하는 현실적인 길을 열어줍니다. 하나라도 빠지면 이득은 빠르게 줄어듭니다. 특히 모델이 GPU에 들어간다면 고민할 필요도 없이 그냥 GPU에 통째로 올리는 편이 22배 빠릅니다.

우리 관점에서 ktransformers의 진짜 가치는 “28배”라는 헤드라인이 아닙니다. 다중 GPU를 사거나 빌릴 수 없는 팀이, 대용량 RAM을 갖춘 Intel 서버 한 대와 GPU 한 장으로 671B급 MoE를 아예 돌릴 수 있게 된다는 접근성에 있습니다. 속도 챔피언이 아니라 진입 장벽을 낮추는 도구로 읽어야 맞습니다.

재현 정보

두 실험 모두 RunPod에서 진행했고, GPU 총 사용 비용은 약 5달러였습니다. 벤치 하네스(llama.cpp --n-cpu-moe, kt_kernel MoE 커널 비교)와 원시 결과 JSON은 전부 공개했습니다. 직접 재현하거나 숫자를 검증하고 싶다면 github.com/sylvanus4/ktransformers-moe-offload-bench(Apache-2.0)를 보시면 됩니다. 다음 검증 후보는 AMX INT8 서빙 경로의 실제 종단 디코딩 속도와, 진짜 ktransformers balance_serve 스택을 Sapphire Rapids 위에서 끝까지 세워보는 것입니다.

소유의 값은 사상 최고로 오른다

먼저 오르는 쪽부터 보겠습니다. 디지털데일리의 ‘AI스택플레이션’ 연재는 메모리 쇼크가 대형 클라우드 사업자를 넘어 AI 스타트업의 서버실까지 도달했다고 전합니다. 질의응답 AI 기업 포티투마루의 신규 서버 도입 비용은 기존 대비 약 70% 뛰었습니다. 2주 전에 130만 원이던 4TB SSD 견적이 이번 주에는 280만 원으로 두 배를 넘겼습니다. 삼성전자와 SK하이닉스는 구글, 마이크로소프트 같은 큰 고객에게 서버 D램 계약가를 60~70% 올리겠다고 통보하면서 주문량의 70%만 공급하고 있습니다. 견적서의 유효기간이 몇 달에서 1~2주로 줄었으니, 기업은 값이 더 오르기 전에 물량을 앞당겨 잡거나 급하지 않은 도입을 미루는 식으로 움직입니다.

값이 오르자 짐이 가벼운 기업부터 움직였습니다. 검색 요약 서비스 라이너는 메모리 단가가 흔든 클라우드 비용 변동을 이유로 아예 다른 클라우드 프로바이더로 갈아탔습니다. 자체 서버실을 무겁게 짊어질수록 이 충격을 정면으로 맞고, 워크로드를 얹어 둔 기업일수록 발이 빠릅니다. 소유의 대가가 곧 경직성으로 돌아오는 순간입니다.

장비값만 오르는 게 아닙니다. 판을 대는 큰손들의 지갑도 닫히고 있습니다. UBS는 마이크로소프트와 아마존을 포함한 4대 하이퍼스케일러의 자본지출 증가율이 2026년 76%에서 2027년 25%, 2028년 6%로 급격히 꺾일 것으로 봤습니다. 뱅크오브아메리카의 7월 펀드매니저 설문에서는 응답자의 82%가 반도체를 지금 시장에서 가장 붐비는 트레이드로 꼽았는데, 이는 조사 사상 최고치입니다. 뉴욕주가 신규 데이터센터 건설에 1년 유예를 걸 만큼 전력난과 규제 리스크도 현실이 됐습니다. 무차별 증설의 시대가 끝나고, ‘지을 것인가’에서 ‘얼마를 벌 것인가’로 질문이 바뀌는 국면입니다. 인프라를 소유한다는 결정이 이렇게까지 비싸고 무거워진 적은 없었습니다.

쓰는 값은 사상 최저로 무너진다

이제 반대쪽 가격표를 보겠습니다. 한국경제는 이 상황을 ‘반도체 폭락의 역설’이라고 불렀습니다. 필라델피아반도체지수는 2분기에 89% 급등한 뒤 7월 들어 15% 내렸고, 4월 상장한 메모리 ETF는 석 달 만에 166% 폭등했다가 20% 넘게 빠졌습니다. 밑재료 시장이 이렇게 요동치는 동안, 정작 AI를 쓰는 단가는 조용히 바닥을 뚫고 있었습니다.

방아쇠는 중국 문샷AI가 이번 주 공개한 오픈웨이트 모델 ‘키미 K3’입니다. 2조8천억 개 파라미터를 얹은 전문가 혼합 구조로, 896개 전문가망 가운데 일부만 켜서 연산을 아낍니다. 100만 토큰 컨텍스트를 지원하고, 오픈AI SDK와 호환돼 기존 개발자가 갈아타는 문턱을 낮췄습니다. 눈길을 끄는 건 값입니다. 작업 하나를 처리하는 데 드는 비용이 0.94달러로, 앤스로픽 오퍼스 4.8의 1.80달러를 절반으로 깎았습니다. 딥시크 V4 플래시는 0.02달러, GLM 5.2는 0.37달러까지 내려갑니다.

한 모델의 파격이 아니라 흐름 전체가 기울었습니다. 뉴시스에 따르면 AI 모델 중개 플랫폼 오픈라우터의 주간 토큰 사용량 1위부터 5위를 텐센트, 샤오미, 딥시크, 미니맥스, 지푸AI 같은 중국 오픈웨이트 모델이 싹 쓸었습니다. 6월 마지막 주 기준 중국 모델의 점유율은 48%로 미국의 20%를 크게 앞섰는데, 1년 전 미국 74% 대 중국 20%였던 구도가 완전히 뒤집힌 셈입니다. 모질라 CTO 라피 크리코리안은 업무 성격에 따라 비용을 최상위 모델의 50분의 1까지 낮출 수 있다고 설명했습니다. 딥시크와 큐원 같은 모델의 API는 미국 최상위 모델보다 10배에서 150배까지 저렴합니다. 기업들은 일상 업무는 값싼 오픈웨이트에 맡기고 어려운 작업만 최상위 모델로 보내는 이원화로 갈아타고 있습니다.

다만 값이 싸다고 아무 데나 던질 수는 없습니다. 중국발 모델의 매력적인 단가 뒤에는 데이터 주권과 보안 검토라는 그늘이 따라붙어, 공공과 금융은 선뜻 손을 대지 못합니다. 키미 K3의 전체 가중치가 7월 27일 공개되면 기업은 이 모델을 내려받아 자기 인프라에서 직접 서빙할 수 있게 됩니다. 값의 매력과 통제의 안전을 동시에 쥐려면, 결국 오픈웨이트를 내 클러스터 위에서 돌리는 길로 이어집니다. 싸진 모델이 온프렘 수요를 죽이는 게 아니라 오히려 지피는 이유입니다.

가위가 벌어지면 승부처가 바뀐다

두 가격표를 겹쳐 놓으면 그림이 선명해집니다. 장비를 소유하는 값은 위로, AI를 쓰는 값은 아래로 벌어지는 가위입니다. 여기서 흔한 오해 하나를 짚고 싶습니다. 모델이 흔하고 싸졌으니 이제 인프라는 중요하지 않다는 결론입니다. 정반대입니다. 완성품이 헐값이 될수록, 그 완성품을 찍어내는 설비의 원가율이 수익의 전부를 결정합니다.

한국경제가 인용한 투자자 개빈 베이커의 말이 이 지점을 정확히 찌릅니다. 그는 저가 모델의 확산이 오히려 ‘AI 인프라에 대한 가장 강력한 초강세 시나리오’라고 봤습니다. 토큰이 싸지면 사람들은 토큰을 더 씁니다. 싸진 만큼 덜 쓰는 게 아니라, 싸졌기 때문에 훨씬 많이 씁니다. 제번스가 석탄에서 봤던 역설이 지금 GPU 위에서 반복되는 중입니다. 그렇다면 승부처는 ‘누가 더 좋은 모델을 가졌나’가 아니라 ‘가진 GPU에서 토큰을 얼마나 많이 짜내느냐’, 즉 활용률로 옮겨갑니다.

디지털데일리의 ‘모두의AI’ 기사가 이 문제를 국가 규모로 보여줍니다. 정부는 전 국민 대상 AI 챗봇에 엔비디아 B200 512장을 투입하면서, 사업자를 두세 곳으로 나눌지 한 곳에 몰아줄지를 두고 딜레마에 빠졌습니다. 나누면 각 서비스가 최대 트래픽을 못 견디고, 몰면 생태계 다양성을 잃습니다. 흥미로운 대목은 정부가 월간활성이용자수와 토큰 사용량을 근거로 임차 물량을 매달 사후 조정하겠다고 한 부분입니다. 카드가 한정된 곳에서는 결국 사용량에 맞춰 자원을 동적으로 재배분하는 통제 능력이 승패를 가릅니다. 512장이든 5만 장이든 본질은 같습니다.

그래서 무엇을 갖춰야 하는가

가위가 벌어질수록 남는 차별화는 세 가지로 좁혀집니다. 작업마다 알맞은 값의 모델로 자동으로 보내는 라우팅, 유휴 카드 없이 워크로드를 채우는 스케줄링, 그리고 그 모든 실행을 나중에 되짚어볼 수 있게 만드는 통제와 기록입니다. 타키클라우드의 에이전트 네이티브 클라우드 Paxis를 굳이 이 자리에서 꺼내는 이유가 여기 있습니다. Paxis는 Skills, Tools, Policies, Audit Logs를 일급 리소스로 다루고, 작업별 모델 선택을 담당하는 CostRouter로 저가 오픈웨이트와 최상위 모델을 나눠 태우는 이원화를 제품 안에 넣어 두었습니다. 위에서 본 기업들의 이원화 전략이 곧 이 기능의 사용 사례입니다.

스케줄링은 소버린 온프렘 K8s 위에서 Kueue로 처리하니, ‘모두의AI’가 겪는 사용량 기반 재배분 문제와 정확히 같은 결의 과제를 다룹니다. 통제 쪽은 정책 게이트와 감사 로그, 그리고 격리 샌드박스 실행이 맡습니다. 이 대목이 오늘 정책 뉴스와 맞물립니다. 7월 21일부터 시행되는 개정 AI기본법은 생성형 AI 표시 의무와 고영향 AI 관리기준을 실제로 요구하고, 공공조달에서는 확인받은 제품에 계약 요건 완화 같은 혜택을 줍니다. 국회입법조사처가 소버린 AI의 본질을 모델의 원산지가 아니라 ‘주권적 통제력’으로 다시 정의하라고 조언한 것도 같은 맥락입니다. 미국 상무부가 지난 6월 앤스로픽 모델의 해외 접근을 사흘 만에 끊었다가 3주 뒤 풀었던 사건은, 남의 API에 얹은 서비스가 얼마나 취약한지를 이미 보여줬습니다. 실행을 내 클러스터 안에서 하고, 정책으로 걸러내고, 로그로 증명하는 능력은 규제 준수인 동시에 통제권 그 자체입니다.

정리하면 이렇습니다. 소유는 비싸지고 모델은 흔해집니다. 그 사이에서 값을 만들어내는 건 좋은 모델을 손에 넣는 일이 아니라, 흔해진 모델을 싸게 라우팅하고 빈틈없이 스케줄링하며 감사 가능하게 통제하는 운영의 밀도입니다. 오늘 아침 반대로 움직이던 두 가격표는, 결국 같은 질문을 던지고 있었습니다. 당신은 가진 것을 얼마나 잘 굴리고 있습니까.

참고 자료

이 글은 아래 뉴스를 종합해 작성했습니다.

• 뉴스1, “K-NPU 써본 후 도입”…퓨리오사AI, 유럽서 ‘풀스택 실증 전략’ 속도
• 디지털데일리, [AI스택플레이션⑤] 메모리 쇼크, AI기업까지… “서버 구매비 70%↑”
• 한국경제, “싸지면 더 쓴다”…’가성비 AI’가 뒤흔든 반도체 폭락의 역설
• 위키트리, 에치드, 칩 출하 전인데 몸값 200억달러…제인스트리트·세쿼이아 동시 베팅
• 글로벌이코노믹, AI 투자 ‘확장’에서 ‘선별’로… 하이퍼스케일러 CAPEX 둔화에 반도체 여파
• 디지털데일리, [모두의AI④完] GPU 분배 딜레마…”多사업 확산vs선택과 집중”
• 지디넷코리아, 스페이스X, 美 펜타곤과 수십억달러 AI 컴퓨팅 공급 협상
• 지디넷코리아, 中 문샷, 신형 AI ‘키미 K3’ 공개…오픈AI·앤트로픽 턱밑 추격
• 지디넷코리아, ZTE, AI 에이전트 스마트폰 ‘나비X 울트라’ 공개
• 아이뉴스24, “이 아파트 실거주 후기는”…네이버 대화형 검색 AI탭, 맞춤 정보 고도화
• 더비즈, [위클리 뱅크이슈] “인공지능이 미래”…은행권 ‘AX’ 전방위 확산
• 뉴스1, “제미나이 할인해드려요”…통신3사, AI 필수재 시대 유치전
• 연합뉴스, [AI기본법] ① 개정안 21일 시행…한국 AI 법제, 준비 마쳤다
• 뉴시스, 반도체 이어 AI도 전략자산…”소버린AI 전략 다시 짜야” 입법처의 조언
• 뉴시스, AI 플랫폼 주간 사용량 1~5위 中 싹쓸이…美 고가 AI 흔든다
• 지디넷코리아, 美 데이터브릭스, 신규 투자 유치…몸값 1880억 달러
• 지디넷코리아, “생성형 AI 보안 정교화”…모니터랩, AI 보안 솔루션 고도화

리즈닝 모델은 표준이 됐고, 이제는 노력의 양을 고른다

OpenAI가 o1로 LLM 리즈닝 모델을 대중화한 지 약 2년이 지났고, 넉 달 뒤 DeepSeek-R1이 검증 가능한 보상을 쓰는 강화학습(RLVR) 레시피를 공개하며 학습 방법까지 열어젖혔습니다. 그 사이 리즈닝은 특별한 기능이 아니라 신규 모델 출시의 기본 구성 요소가 됐습니다. 지난주 공개된 GPT-5.6 계열은 세 가지 크기로 나오는데, 각 크기마다 대략 대여섯 개의 추론 노력 설정을 함께 제공합니다.

여기서 핵심 관찰이 하나 나옵니다. 리즈닝 모델을 만드는 것과, 그 모델이 얼마나 오래 생각할지를 사용자가 고르게 만드는 것은 별개의 문제라는 점입니다. 전자는 이미 많이 다뤄졌지만, 후자, 즉 “노력의 양을 조절 가능한 입력으로 만드는 법”은 상대적으로 덜 정리돼 있습니다. 실무에서 이 조절 능력은 곧 비용 손잡이입니다. 쉬운 질의는 저노력으로 흘려보내고 어려운 질의에만 고노력을 태우면, 같은 GPU에서 처리량과 품질을 동시에 끌어올릴 수 있기 때문입니다.

reasoning effort란 무엇인가

경험적으로 노력을 올리면 생성되는 토큰 수가 늘고, 벤치마크 성능도 함께 오릅니다. 다만 이 관계는 선형이 아니라서, 노력이 높은 구간으로 갈수록 추가 토큰당 성능 향상은 점점 줄어듭니다. Thinking Machines의 Inkling 발표 자료에서 노력 단계를 올릴 때 토큰과 성능이 함께 증가하되 상위 구간에서 이득이 둔해지는 곡선이 그대로 확인됩니다. 서빙 관점에서 보면, 최고 노력이 항상 최선의 선택은 아니라는 뜻입니다.

그렇다면 추론 시점에 노력은 어떻게 지정할까요. 놀랍도록 단순합니다. 대개 시스템 프롬프트 한 줄로 제어합니다. ChatGPT UI의 드롭다운 메뉴 선택도 내부적으로는 특정 시스템 프롬프트에 매핑되는 것으로 보입니다. 문제는 이 방식이 아무 모델에서나 통하지 않는다는 데 있습니다. 모델이 “노력: 낮음”이라는 지시를 받았을 때 실제로 더 짧게, 그러나 품질을 유지하며 생각하도록 학습돼 있어야 합니다. 즉 손쉬운 추론 시점 제어를 얻으려면 그 대가로 학습 파이프라인을 손봐야 합니다.

어떻게 학습시키는가: 두 개의 축

GPT-5.6이든 오픈소스 gpt-oss든 정확한 학습 세부는 공개돼 있지 않지만, 일반적으로 노력 라벨은 후처리(post-training) 단계의 프롬프트 안에 포함됩니다. 이를 구현하는 방법은 크게 두 갈래입니다.

첫째, RLVR 과정에서 시스템 프롬프트에 따라 길이 페널티를 다르게 주는 방식입니다. “노력: 낮음”일 때는 강한 길이 페널티를, “노력: 높음”일 때는 약하거나 없는 페널티를 적용하면, 모델은 지시된 노력에 맞춰 생각의 길이를 스스로 조절하도록 강화됩니다. 둘째, RLVR을 끝낸 뒤 SFT로 서로 다른 노력 지시를 따르게 미세조정하는 방식입니다. 이때 학습 데이터의 프롬프트에는 원하는 추론 분량을 담은 타깃 응답이 짝지어지고, 그 타깃은 사람이 쓰거나 다른 모델이 생성하거나 생성 후 필터링한 것일 수 있습니다.

두 방법의 큰 그림은 아래와 같습니다. 대다수 실제 레시피는 이 골격의 변주입니다.

flowchart LR
    A["베이스 / RLVR 리즈닝 모델"] --> B["1. SFT + chat template<br/>노력 모드를 입력으로 도입"]
    B --> C["2. mode-conditioned RL<br/>노력별 context window·length penalty 차등"]
    C --> D["3. 하드 예산 강건성 학습<br/>truncated trace·강제 중단 후 재개·budget toggle"]
    D --> E["추론: system prompt로 노력 선택<br/>+ 선택적 토큰 예산"]

오픈웨이트 6개 모델 딥다이브

Raschka는 개념 증명에 그치는 연구 대신, 실제로 작동한다는 증거가 있는 최신 오픈웨이트 모델 여섯 개의 레시피를 골랐습니다. 리포트마다 공개 수준은 다르지만, 각각이 쓸모 있는 변주를 하나씩 보여줍니다.

DeepSeek V4: 노력 전문가를 분리한다

DeepSeek V4 기술 리포트는 세 가지 모드를 설명합니다. Non-think는 추론 흔적 없이 바로 답하고, Think High는 <think>와 </think> 사이에 추론 흔적을 두는 R1식 고전 방식이며, Think Max는 여기에 특별한 시스템 지시를 덧붙입니다. Think Max용 지시문은 “Reasoning Effort: Absolute maximum with no shortcuts permitted”로 시작합니다. 핵심은 서로 다른 노력 수준을 별개의 전문가처럼 다루고, 모드에 조건화된 RL로 다듬는다는 점입니다.

Nemotron 3 Ultra: 학습된 모드와 하드 예산의 결합

Nemotron 3 Ultra는 reasoning-off, regular, medium-effort 세 설정을 씁니다. medium-effort는 regular보다 저렴한 추론 모드인데, NVIDIA는 이 모드를 GPT-OSS-120B의 medium-effort 출력으로 SFT 단계에서 도입한 뒤 RLVR로 추가 최적화합니다. RLVR 프롬프트의 약 2.5%가 medium-effort에 해당하며, 여기에 길이 기반 보상 조정이 적용됩니다. 여기에 더해 추론 시점의 토큰 예산을 외부 정지 장치로 겹쳐 쓸 수 있습니다. 클라이언트가 지정한 한도 근처에서 추론을 끝내라고 요청하고, 모델이 스스로 </think>를 내지 않으면 클라이언트가 강제로 닫습니다. 이렇게 잘려도 답이 무너지지 않도록, 무작위로 잘린 흔적으로 학습해 강건성을 확보합니다.

Kimi K2.5: budgeted와 unconstrained를 번갈아 도는 Toggle

Kimi K2.5의 방법인 Toggle은, 고정 토큰 예산으로만 학습하면 모델이 짧은 해에 과적합해 추가 연산의 이득을 잃는다는 문제의식에서 출발합니다. 그래서 일정 학습 반복마다 두 국면을 번갈아 돕니다. budgeted 국면에서는 정답 해가 문제별 토큰 예산 안에 머물도록 유도하고, unconstrained 국면에서는 최대 생성 길이를 복원해 긴 해에서도 계속 배우게 합니다. 예산은 RLVR 정답 롤아웃 길이의 특정 백분위에서 추정하되, 해당 문제의 평균 정확도가 임계를 넘은 뒤에야 예산 제약을 켭니다. 토큰 효율은 크게 끌어올리면서 전체 벤치마크 성능은 비슷하게 유지하는 것이 목표입니다.

GLM-5: turn-level·interleaved·preserved thinking

GLM-5는 GLM-4.5의 이진 on/off 스위치를 멀티턴과 툴 사용 시나리오로 확장합니다. 세 가지 노력 수준이 아니라 세 가지 관련 동작을 정의하는 점이 특징입니다. interleaved thinking은 응답과 툴 호출마다 앞에 추론 블록을 넣고, preserved thinking은 이전 추론 블록을 여러 턴에 걸쳐 보존해 재사용하며, turn-level thinking은 대화 안에서 요청 단위로 추론을 켜고 끕니다. 추론 시점의 실제 스위치는 turn-level입니다. Z.ai API에서는 기본으로 켜져 있고 개별 요청에서 비활성화할 수 있습니다.

Qwen3: 모드 융합과 추론 시점 절단

Qwen3의 후처리 파이프라인은 long-CoT SFT, 리즈닝 RL, Thinking Mode Fusion, 일반 RL의 네 단계로 구성됩니다. 노력 on/off 스위치의 핵심은 Thinking Mode Fusion으로, thinking 예시와 non-thinking 예시를 섞은 SFT를 수행합니다. /think 예시는 추론 흔적을 담고, /no_think 예시는 빈 <think></think> 블록과 짧은 답으로 시작합니다. 이어지는 일반 RL이 두 동작 모두에서 지시·형식 준수를 강화합니다. Qwen3는 하드 thinking 예산도 지원하는데, 지정 임계에서 추론을 멈추고 정지 지시를 삽입한 뒤 최종 답으로 넘어갑니다. 흥미롭게도 이 부분 추론 동작은 명시적으로 학습된 것이 아니라 Thinking Mode Fusion 이후 창발했다고 리포트는 밝힙니다. DeepSeek V4나 Nemotron보다 단순하지만, 학습된 on/off 스위치와 추론 시점 예산을 함께 얻는 구성입니다.

Inkling: 시스템 프롬프트 노력과 모드 조건화 RL

Inkling은 시스템 프롬프트로 노력을 지정하고, 노력에 조건화된 RL로 뒷받침합니다. 앞서 본 대로 노력을 올리면 토큰과 성능이 함께 오르되 상위 구간에서 이득이 둔해지는 경향을 보여, 서빙 시 노력 상한을 어디에 둘지 판단하는 데 참고가 됩니다.

공통 골격: 라벨은 같아도 뼈대는 하나

여섯 모델을 나란히 놓으면 공유하는 프레임워크가 드러납니다. 첫째, SFT와 chat template로 노력 모드를 입력으로 도입합니다. Qwen3는 thinking·non-thinking 예시를 명시적으로 섞고, GLM-5는 interleaved·preserved·turn-level 패턴을 더합니다. 둘째, 모드에 조건화된 RL 단계에서 요청된 노력에 따라 컨텍스트 윈도우와 길이 페널티를 바꿉니다. DeepSeek V4, Nemotron 3 Ultra, Inkling이 이 접근을 씁니다. 셋째, 명시적 예산 아래에서의 강건성을 더합니다. Nemotron은 무작위로 잘린 흔적으로 학습하고, Qwen3는 강제로 멈춘 추론 지점에서 이어갈 수 있으며, Kimi는 budgeted와 unconstrained RL을 번갈아 돕니다. 이 장치들은 가용 추론 길이가 바뀌거나 도중에 잘려도 답 품질을 지켜줍니다.

여섯 리포트에 실제로 문서화된 내용을 표로 정리하면 다음과 같습니다.

결론과 ThakiCloud 관점

여섯 사례가 보여주는 것은, 비슷한 라벨이 별개의 전문가, 혼합 SFT 데이터, 모드 조건화 보상, 하드 토큰 예산, 또는 이들의 조합으로 각각 뒷받침될 수 있다는 사실입니다. 어느 방법이 가장 낫다고 단정하기는 어렵습니다. 모델마다 베이스 체크포인트, 학습 데이터, 후처리 연산량, 벤치마크, 서빙 목표가 다르고 리포트가 비교에 필요한 세부를 생략하기 때문입니다. 대화형 어시스턴트에 잘 맞는 방법이 장시간 도는 코딩 에이전트에는 나쁠 수도 있습니다.

궁극의 목표는 물론 노력의 자동 선택입니다. 한때 GPT-5의 Auto 모드가 그 방향을 시도했지만 성공보다 실패에 가까웠고, 결국 UI에서 사라졌습니다. 가까운 미래에는 노력이 여전히 명시적 모델 입력으로 남아 대개 시스템 프롬프트로 전달되되, LLM을 감싸는 에이전트 하네스나 내부 라우터가 작업 상태와 남은 예산으로부터 적절한 모드와 예산을 점점 더 자동으로 추론하는 방향이 유력합니다. 물론 지연이나 비용을 우선하거나 최대 성능을 노릴 때를 위해 사용자 오버라이드는 남겨두는 형태가 될 겁니다.

이 지점이 우리 플랫폼 운영과 정확히 맞닿습니다. 추론 예산을 손잡이로 다룰 수 있다면, GPU 서빙 비용과 지연을 질의 난이도에 맞춰 배분할 수 있습니다. 쉬운 요청에는 저노력을, 어려운 요청에만 고노력을 태우는 라우팅은 Kueue 기반 GPU 스케줄링과 결합해 같은 클러스터에서 처리량과 품질을 함께 끌어올리는 실질적 여지를 만듭니다. 실제로 에이전트 하네스를 운영해 보면, 비싼 추론은 검증·합성 같은 소수 단계에만 몰아주고 탐색·요약은 저노력으로 처리하는 편이 비용 대비 품질이 좋습니다. 노력 조절은 모델 자랑거리가 아니라, 추론 인프라를 운영하는 팀이 매일 돌리는 비용-품질 레버라는 관점에서 이 흐름을 읽는 편이 실용적입니다.

원문은 각 모델의 기술 리포트 링크와 도식을 풍부하게 담고 있으니, 특정 모델의 세부 레시피가 필요하면 Sebastian Raschka의 원글과 해당 리포트를 직접 확인하시길 권합니다.

원 뉴스: RT @Serantych: Kimi’s CEO Zhilin Yang: (build many agents, not one smarter one) · twitter

ThakiCloud 제품 적용 시사점

파시스는 원래 이 뉴스가 말하는 그 일을 합니다. 여러 에이전트를 지휘자처럼 오케스트레이션해서, 한 놈이 막히면 다른 역할의 일꾼을 붙여 벽을 우회시키는 구조입니다. 메티스는 그 떼거리가 돌아갈 추론을 받쳐 줍니다. 다만 대표가 말한 협업의 진짜 비용은 인프라입니다. 떼로 풀수록 호출도, GPU도, 요금도 함께 늘어납니다. 이걸 자기 시설 안, 곧 온프렘에서 굴리면 이야기가 달라집니다. 에이전트를 몇을 풀든 청구서가 남의 통장으로 새지 않고, 넘어야 할 벽도 내 벽으로 남습니다. 주권형 온프렘 위에서 떼로 푸는 것, 그게 파시스와 메티스가 권하는 방식입니다.

이 만화는 업계 뉴스를 바탕으로 자동 생성된 초안입니다.

هذا البرود هو الخبر الحقيقي لهذا اليوم. وفي الأسبوع نفسه، تزامن معه مشهد آخر في الاتجاه المعاكس تماما.

مشهدان يتعثران عند القمة

أجّلت جوجل نموذج جيميناي 3.5 برو، الذي أعلن الرئيس التنفيذي سوندار بيتشاي شخصيا في فعالية المطورين في مايو أنه سيصدر في يونيو، ثلاث مرات ليصل موعده إلى يوليو. وبحسب تقرير نيوز رود، تخلّت الشركة عن البنية القائمة وأعادت بناءها من الصفر بالكامل، وحُدد قصور أداء البرمجة عن الأهداف الداخلية كسبب رئيسي. وتراجع سعر السهم بنحو 4 بالمئة في وقت من الأوقات بعد خبر التأجيل، وانتقل أربعة من كبار باحثي جيميناي إلى أنثروبيك خلال الأيام الستة الأخيرة.

ولم تكتفِ نيوز رود بالإشارة إلى الصعوبة التقنية وحدها كخلفية للتأخير. بل أشارت إلى أن بنية تنظيمية تكرر فيها جهات متعددة، مثل جوجل كلاود وديب مايند وأندرويد، إنفاق الموارد ببناء أدوات برمجة منفصلة خاصة بكل منها، إضافة إلى ثقافة هندسية داخلية تفرض أن يكتب البشر الكود المهم بأنفسهم، هي ما أبطأ الوتيرة. وهذا يعني أنه حتى عند الحافة الأمامية للأداء، لم يُحسَم بعد إلى أي مدى يتدخل الإنسان وماذا يُترك للأتمتة.

من جهة، بلغ نموذج ناشئ مفتوح الأوزان قمة لوحة الصدارة، لكن السوق لم يفتح محفظته. ومن جهة أخرى، حتى الرائد في الحافة الأمامية أجّل إصداره التالي ثلاث مرات. يبدو المشهدان متناقضين، لكنهما يرويان القصة نفسها: عند ذروة منحنى الأداء، اتسعت الفجوة بين أرقام المعايير القياسية والنشر الفعلي أكثر من أي وقت مضى.

كلما انخفضت الأسعار، تغير السؤال

القدرة نفسها باتت أكثر شيوعا. وبحسب جدول أسعار النماذج الذي جمعته تشوسون إلبو، انتقل محور المنافسة فعليا من الأداء إلى القيمة مقابل السعر. فقد قسّمت أوبن إيه آي نموذج GPT-5.6 إلى تشكيلة تضم النسخة عالية الأداء سول، ونسختين أرخص هما تيرا ولونا، بينما يعرض ميوز سبارك من ميتا سعرا يقارب واحدا على اثني عشر من سعر فايبل 5 من أنثروبيك على أساس رمز الإخراج. وتدّعي سبيس إكس أن نموذجها جروك 4.5 يستهلك رموز إخراج أقل بأكثر من أربعة أضعاف مقارنة بالنماذج المنافسة في تقييمات البرمجة. وسعر واجهة كيمي K3 البرمجية الذي يبلغ نصف السعر هو أحد فروع هذا التيار أيضا.

وحين تتجه الأسعار نحو القاع، يتغير السؤال. من “ما هو أذكى نموذج” إلى “هل يمكننا تشغيل هذه القدرة بأمان، وبشكل محكوم، وقابل للتدقيق، على بياناتنا ومهامنا”. وهنا يكمن سبب عدم بيع النموذج الأول في لوحة الصدارة. فما تدفع المؤسسات ثمنه ليس مؤشر الذكاء، بل إمكانية النشر. المعيار القياسي يثبت القدرة، لكنه لا يثبت الثقة.

من تبنّى الذكاء الاصطناعي هم من يتحدثون أولا

أصدق شاهد على هذه الفجوة ليس المتشككين، بل من تبنّى الذكاء الاصطناعي فعليا. والتبني نفسه يتوسع بشكل متفجر. فقد ربطت هانا تور وكيلها متعدد الذكاء الاصطناعي إتش إيه آي (H-AI) بنافذة تشات جي بي تي داخل كاكاو توك، ليحصل المستخدمون على توصيات سفر من دون تثبيت أي تطبيق منفصل، وبعد تطبيق تحسين البحث للذكاء الاصطناعي التوليدي، ازداد حجم الزيارات القادمة عبر تشات جي بي تي بنحو 850 بالمئة. وبهذه الوتيرة الحادة يخترق الذكاء الاصطناعي واجهات المحادثة المألوفة، لكن مدى ثقة المؤسسة في تسليم نتائجه يرسم منحنى مختلفا تماما.

بدأت شركات التوزيع الكبرى بنشر وكلاء الذكاء الاصطناعي في العمل الفعلي. فقد جمعت لوتيه تشيلسونغ بيفريج بين الذكاء الاصطناعي التوليدي وتقنية التعرف الضوئي على الحروف OCR وتقنية RAG لتخفض زمن مراجعة ملصقات المنتجات بأكثر من النصف، بينما أدخلت مجموعة دونغ وون “موظفي ذكاء اصطناعي” في شركاتها التابعة وتخطط لإضافة نحو خمسين منهم بحلول نهاية النصف الثاني من العام. غير أن التوصية التي أضافتها ديلويت في تقرير ويكلي كوريا عن هذا الانتشار هي الجوهر: الحفاظ على نظام الإنسان في الحلقة الذي يتحقق فيه الإنسان من النتائج ويوافق عليها في المراحل الأولى من الانتشار.

واعتراف بارك مين جون، الرئيس التنفيذي لشركة رايتن، الذي كشف عن تجربة استبدال الإدارة التنفيذية بالذكاء الاصطناعي، أكثر حدة. فقد شغّل بنية يتناقش فيها ذكاء اصطناعي مخصص لكل دور ثم يقدم رأيه، ليجمّع الرئيس التنفيذي الآراء ويتخذ القرار، وقال إن الأمر بدا مريحا في البداية، لكن بعد شهر بات التحقق من إجابات الذكاء الاصطناعي يستغرق وقتا أطول. وشبّه الذكاء الاصطناعي بموظف جديد ذكي، مؤكدا أنه لا يؤدي دوره كما ينبغي إلا بعد تدريبه بما يكفي على بيانات الشركة وثقافتها التنظيمية.

وهناك شركة حوّلت الألم نفسه إلى سوق. فالحل الذي طورته جيرانجيجيو سوفت، والذي حصل على تصنيف من وزارة العلوم وتكنولوجيا المعلومات والاتصالات وهيئة كوريا لأمن الإنترنت KISA كتقنية متميزة لحماية المعلومات، يفحص في الوقت الفعلي عند نقطة النهاية ما يدخله الموظفون في تشات جي بي تي أو كلود، ليمنع تسرب المعلومات الشخصية والأسرار التجارية، ويدقق بشكل موحد سجل إدخال الأوامر وسجل إرسال البريد الإلكتروني. فهي لا تبيع القدرة، بل تبيع إطار الاستخدام الآمن لتلك القدرة. والاتجاه الذي تشير إليه الحالات الثلاث واحد: أن يصبح النموذج أذكى، وأن تثق المؤسسة بذلك النموذج وتسلّمه المهام، مسألتان مختلفتان تماما.

الدول تسمي القيمة نفسها باسم مختلف

هذه الإشارة الظاهرة على مستوى الشركات تحمل اسم الذكاء الاصطناعي السيادي حين ترتفع إلى مستوى الدولة. فقد أعلن نائب رئيس الوزراء باي كيونغ هون، في تقريره للعمل، أن تطوير نموذج رائد بمستوى ميثوس من أنثروبيك يتطلب نحو عشرة آلاف وحدة معالجة رسومية، مبشرا بتوسيع الحوسبة بقيادة الدولة، وقررت الحكومة إطلاق خدمة “الذكاء الاصطناعي للجميع” المجانية لكل المواطنين في ديسمبر. وسجّل ائتلاف معهد أبحاث الذكاء الاصطناعي التابع لإل جي المرتبة الأولى في جميع المجالات، من المعايير القياسية إلى تقييم الخبراء والمستخدمين، في التقييم الأول لنموذجه التأسيسي الخاص، وطُبّق تجريبيا في خدمات وزارة الإدارة العامة والأمن. وفي اليابان، يبني ائتلاف نويترا، الذي موّلته 44 شركة منها سوني وسوفت بنك وهوندا، بنية تحتية وطنية للذكاء الاصطناعي بتأمين نحو 27500 وحدة معالجة رسومية من طراز روبن من إنفيديا.

وقراءة هذا التيار كنزعة قومية بسيطة تعني رؤية نصف الصورة فقط. فالسبب الحقيقي وراء ضخ الدول أموالا هائلة في نماذجها وحوسبتها الخاصة هو أن المورد الذي يزداد ندرة كلما شاعت القدرة هو التنفيذ المحكوم بالذات. على بنية تحتية من يعمل النموذج، وتحت أي سياسة، وما الذي يُسجَّل أثناء ذلك. والقيمة التي تسميها الدول ذكاء اصطناعيا سياديا، والقيمة التي تسميها المؤسسات سجلات تدقيق وإنسانا في الحلقة، هما الشيء نفسه، يختلفان فقط في الحجم.

المال بدأ هو الآخر يتحلى بالحذر

في هذه المرحلة التي تشيع فيها القدرة، بدأ رأس المال أيضا، الذي كان يتراكم من دون حدود، يغيّر تعبيره. وكما أشارت غلوبال إيكونوميك، تراجعت السندات الجديدة لشركات الحوسبة الفائقة التي دعمت الاستثمار في منشآت الذكاء الاصطناعي بمعدل 3.3 نقطة في المتوسط دون سعر الإصدار، في ضعف غير معتاد لسندات تقنية معلومات عالية الجودة. وردّت مؤسسات مالية كبرى مثل غولدمان ساكس على نظرية الفقاعة المبكرة، قائلة إن قوتها الأساسية متينة ولا خطر تعثر عليها، لكن في الوقت نفسه ظهرت توقعات بتباطؤ معدل نمو الاستثمار الرأسمالي لدى مزودي السحابة في أمريكا الشمالية من 83 بالمئة هذا العام إلى نحو 23 بالمئة العام المقبل. وهي إشارة إلى أن عصر البناء بلا تمييز يقترب من نهايته، وأن عصر الانتقاء يبدأ.

وهذه التكلفة تمتد بالفعل إلى أماكن أخرى. فبحسب ديجيتال توداي، تراجعت شحنات الهواتف الذكية في الهند، ثاني أكبر سوق للهواتف الذكية في العالم، بنسبة 10 بالمئة في الربع الثاني، وهو أكبر انخفاض في ست سنوات، وحُدد استثمار شركات الحوسبة الفائقة في البنية التحتية للذكاء الاصطناعي كسبب، إذ التهم إمدادات ذاكرة DRAM وNAND ورفع تكلفة الذاكرة في الهواتف الذكية الرخيصة. أي أن فاتورة عالم يستخدم القدرة كمادة خام وصلت حتى إلى مستهلك هاتف ذكي بسعر 210 دولارات في الهند. وهذا التحول، حيث يتراجع العائد من مواصلة تكديس القدرة ويزداد سمكا العائد من إحسان التعامل معها، يظهر في مؤشرات عدة في الوقت نفسه.

من عصر اختيار النموذج إلى عصر امتلاك طبقة التنفيذ

وحين نضيف إلى الصورة مفاوضات ميتا لتأجير حوسبتها الخاصة لأنثروبيك بقيمة عشرة مليارات دولار، بدلا من الإعلانات، تتضح الصورة تماما. الحوسبة تتحول إلى سلعة، والنماذج تشيع بنصف السعر، والمرتبة الأولى في لوحة الصدارة تتغير كل أسبوع تقريبا. وفي عالم تصبح فيه القدرة مادة خام على هذا النحو، تنتقل القيمة لا إلى فوق القدرة، بل إلى طبقة التنفيذ التي تحيط بها. والتنافسية لا تكمن في اختيار النموذج، بل في تحت سيطرة من يعمل ذلك النموذج.

يلخّص المخطط أدناه هذا التحول في صورة واحدة. ويوضح لماذا لا يمكن للقدرة التي أصبحت سلعة أن تُنشر بذاتها، ولماذا يجب أن تمر عبر بوابة طبقة التنفيذ لتصبح نشرا محكوما تدفع المؤسسات ثمنه.

flowchart TB
    subgraph CAP[Capability is now a commodity]
        M1[Kimi K3 tops the coding leaderboard at half-price API]
        M2[GPT-5.6 and Muse Spark up to 12x cheaper]
        M3[The rank-1 model changes almost weekly]
    end
    CAP -->|a benchmark score is not deployment trust| GAP{Can we run it safely, controlled and audited on our own data}
    GAP -->|without governance| RISK[Adopted but not trusted, re-verification fatigue]
    GAP -->|through an execution layer| EXEC
    subgraph EXEC[Paxis Agent-Native execution layer]
        P1[Policy gate and isolated sandbox]
        P2[Audit logs on every agent run]
        P3[L0 to L3 autonomy with human in the loop]
        P4[CostRouter picks a model per task]
        P5[On-prem Kubernetes for sovereignty]
    end
    EXEC --> VALUE[What enterprises actually pay for is controlled deployment]

وPaxis من ThakiCloud هو بالضبط تلك السحابة الأصيلة للوكلاء (Agent-Native Cloud) التي جعلت من طبقة التنفيذ هذه منتجا فعليا. فهو يضع المهارات والأدوات والسياسات وسجلات التدقيق كموارد من الدرجة الأولى، ليصمم عبر حوكمة الاستقلالية من L0 إلى L3 كلا من إرهاق إعادة التحقق الذي عاشه الرئيس التنفيذي لرايتن، والإنسان في الحلقة الذي أوصت به ديلويت. فلا يُترك تحديد إلى أي مدى يمكن للإنسان أن يرفع يده للحدس، بل يُحدَّد عبر السياسات والبوابات. ووظيفة التدقيق التي باعتها جيرانجيجيو سوفت هي القيمة الافتراضية المرفقة بكل تشغيل وكيل في Paxis، وتصبح بوابة السياسات وصندوق العزل المعزول إطارا يمنع تسرب الأسرار حتى مع تبني نماذج مفتوحة الأوزان بنصف السعر. وتُستوعب منافسة النماذج التي انتقلت إلى القيمة مقابل السعر عبر CostRouter الذي يربط نموذجا مختلفا بكل مهمة، بينما يستقبل متطلبات السيادة التي تطلبها الدول ai-platform القائمة على كوبرنيتيس المحلي (on-prem).

وإذا قلبنا سبب عدم بيع النموذج الأول في لوحة الصدارة، نصل إلى الجواب. فما تشتريه المؤسسات ليس الدرجة القصوى، بل التنفيذ المحكوم. والثقة التي لا يستطيع المعيار القياسي شراءها، تصنعها طبقة التنفيذ بدلا منه.

المصادر

كُتب هذا المقال بتجميع الأخبار التالية.

• ويكي تري، ميتا تبيع الحوسبة بدل الإعلانات… مفاوضات أولية لتأجير حوسبتها لأنثروبيك بقيمة 10 مليارات دولار
• ويكي تري، سبيس إكس تتفاوض على توريد حوسبة الذكاء الاصطناعي للبنتاغون بحجم مليارات الدولارات
• غود مورنينغ إيكونومي، رهان بـ550 تريليون وون على البنية التحتية للذكاء الاصطناعي… إعادة تشكيل من شبكة الكهرباء إلى أشباه الموصلات
• أيه آي تايمز، اليابان تبني بنيتها التحتية الوطنية للذكاء الاصطناعي بوحدات روبن من إنفيديا… رهان على الذكاء الاصطناعي الفيزيائي
• نيوز رود، تأجيل إطلاق جيل جوجل التالي من الذكاء الاصطناعي ‘جيميناي 3.5 برو’ أشهرا
• ديجيتال توداي، ‘ربح المعيار القياسي، لكن ماذا بعد’… نظرة وادي السيليكون إلى كيمي K3 الصيني
• تشوسون إلبو، منافسة نماذج الذكاء الاصطناعي تتحول من ‘الأداء الأعلى’ إلى ‘القيمة مقابل السعر’
• هانز إيكونومي، ذكاء اصطناعي لتوصيات السفر داخل كاكاو توك… هانا تور توسّع الخدمة
• ويكلي كوريا، ‘ابتكار العمل’ قطاع التوزيع يسرّع تبني ‘وكلاء الذكاء الاصطناعي’
• دونغ آ إيلبو، بارك مين جون، الرئيس التنفيذي لرايتن: ‘سنستبدل الإدارة التنفيذية بالذكاء الاصطناعي أولا’
• إي ديلي، ‘استثمار جريء في ذكاء اصطناعي بمستوى ميثوس’… نائب رئيس الوزراء باي كيونغ هون يوسّع البنية التحتية المتقدمة
• تشونجي إيلبو، [منتخب كوريا للذكاء الاصطناعي ①] معهد أبحاث الذكاء الاصطناعي لدى إل جي يتجاوز حاجز شركات التقنية الكبرى بسيادة الذكاء الاصطناعي ‘K-إكساون’
• ماي إيل كيونغجيه، ‘الذكاء الاصطناعي لكل المواطنين’ بلا حدود للتكلفة أو السعة يصدر في ديسمبر… مصدر التمويل مسألة أخرى
• ماي إيل كيونغجيه، اليابان تطلق مشروع الذكاء الاصطناعي السيادي بمشاركة 44 جهة منها سوفت بنك… كشف النموذج الأساسي هذا العام
• غلوبال إيكونوميك، مؤشرات على التقاط الأنفاس في استثمارات الذكاء الاصطناعي… عبء تمويل شركات التقنية الكبرى يجعل الطلب على HBM ‘متغير سرعة’
• نيوز رود، مايكرون تستهدف ‘عقل السيارة’ بتحالف ذاكرة لمدة 3 إلى 5 سنوات مع هيونداي موبيس وكوالكوم
• ديجيتال توداي، شحنات الهواتف الذكية في الهند تنخفض 10 بالمئة بفعل الطلب على ذاكرة الذكاء الاصطناعي… أكبر انخفاض في 6 سنوات
• ماي إيل إيلبو، ‘الوقاية من تسرب معلومات الشركات الصغيرة والمتوسطة بتقنية أمن الذكاء الاصطناعي’… جيرانجيجيو سوفت وأمن الذكاء الاصطناعي

أي فريق قام بنشر نموذج لغوي كبير في خدمة حقيقية يدرك سريعا حقيقة واحدة: ما يحدد سرعة استجابة الخدمة وتكلفتها ليس النموذج الذي اخترته، بل ما تستخدمه لتشغيله. على نفس بطاقة GPU، وبنفس النموذج، يمكن أن تختلف الإنتاجية في الثانية بعدة أضعاف حسب محرك الاستدلال المستخدم. واختلاف الإنتاجية بعدة أضعاف يعني اختلاف عدد وحدات GPU اللازمة لتحمل نفس حجم الحركة بعدة أضعاف أيضا، وهذا ينعكس مباشرة على حجم فاتورة البنية التحتية.

يتناول هذا المقال vLLM، الذي أصبح اليوم المعيار الفعلي لخدمة النماذج اللغوية الكبيرة في بيئة الإنتاج. سنستعرض بالترتيب المشكلة التي ظهر vLLM لحلها، وما تفعله فعليا تقنياته الأساسية PagedAttention والتجميع المستمر (continuous batching)، وما الذي يجب الانتباه إليه لتشغيله بثبات فوق Kubernetes. تدير ThakiCloud هذا المحرك في كل من البيئات المحلية (on-premise) والبيئات المُدارة لعملائها، لذا سنتجاوز الشرح النظري البسيط ونكتب هذا من منظور المشغّل الفعلي.

ما هو vLLM

vLLM محرك استدلال مفتوح المصدر أطلقه باحثون من جامعة كاليفورنيا بيركلي عام 2023. الهدف بسيط وواضح: جعل استدلال النماذج اللغوية الكبيرة أسرع وأرخص. انتشر بسرعة بعد إطلاقه، وأصبح اليوم الخيار الافتراضي الذي يقوم عليه استدلال الإنتاج لدى منظمات عديدة مثل Meta وMistral وCohere وIBM.

ما يستهدفه vLLM هو نوعان من الهدر المختبئان في أساليب الاستدلال التقليدية. الأول هو تجزؤ الذاكرة (memory fragmentation)، والثاني هو وقت خمول GPU. لا يظهر أي منهما بوضوح على السطح، لكن مجتمعين يتركان جزءا كبيرا من GPU الباهظة الثمن في حالة خمول دون أي عمل. تستهدف التقنيتان الأساسيتان في vLLM، وهما PagedAttention والتجميع المستمر، كل واحدة نوعا من هذين النوعين من الهدر بشكل مباشر.

لنرسم أولا الهيكل العام.

flowchart TB
    A[طلبات مستخدمين متعددة] --> B[المجدول]
    B --> C{تجميع مستمر<br/>إعادة بناء في كل خطوة}
    C --> D[PagedAttention<br/>إدارة صفحات ذاكرة KV]
    D --> E[تنفيذ GPU<br/>تمرير أمامي]
    E --> F{الطلبات المكتملة<br/>تُعاد فورا}
    F -->|تسلسل غير مكتمل| C
    F -->|مكتمل| G[بث الاستجابة]
    D -.جدول الكتل.-> H[(كتل فيزيائية غير متجاورة<br/>ذاكرة GPU)]

PagedAttention: القضاء على هدر الذاكرة

أثناء توليد النموذج اللغوي للرموز (tokens) واحدا تلو الآخر، يخزّن المفاتيح والقيم التي حسبها سابقا. يُسمى هذا ذاكرة KV المؤقتة (KV cache)، وكلما طالت الجملة، زاد حجم هذه الذاكرة المؤقتة في ذاكرة GPU. تكمن المشكلة في أن الأسلوب التقليدي يحجز لكل طلب مسبقا مقدارا من الذاكرة يعادل الطول الأقصى المتوقع، وذلك كقطعة كبيرة متجاورة. فإذا كانت الاستجابة الفعلية أقصر من ذلك، يُهدر جزء كبير من الذاكرة المحجوزة ببساطة. وعندما تصل طلبات متعددة في وقت واحد، يتراكم هذا الهدر، حتى تصل الحالة إلى أن GPU لديه ذاكرة فارغة لكنه لا يستطيع استقبال طلب جديد.

استعار PagedAttention فكرته مباشرة من طريقة أنظمة التشغيل في التعامل مع الذاكرة العشوائية (RAM)، أي الذاكرة الافتراضية والترقيم (paging). فبدلا من حجز ذاكرة KV المؤقتة كقطعة واحدة كبيرة، يقسّمها إلى صفحات صغيرة قابلة لإعادة الاستخدام. تُربط الكتل المنطقية لكل تسلسل، عبر جدول كتل (block table)، بكتل فيزيائية غير متجاورة داخل ذاكرة GPU. وبهذا لا يُخصَّص إلا العدد الفعلي اللازم من الصفحات، ما يقلل هدر الذاكرة بشكل كبير. وبحسب مصادر مشروع vLLM نفسه، يمكن لهذا الأسلوب أن يقلل هدر الذاكرة بنسبة تصل إلى 90 بالمئة.

وله أيضا فائدة جانبية كبيرة. ففي عمليات فك ترميز معقدة تتفرع من موجّه (prompt) واحد إلى مسارات متعددة، مثل أخذ العينات المتوازي (parallel sampling) أو بحث الحزمة (beam search)، لا يحتاج vLLM إلى تكرار ذاكرة KV المؤقتة الخاصة بالموجّه. يمكن لكتل منطقية متعددة أن تشير إلى نفس الكتلة الفيزيائية، ولا تُنشأ نسخة إلا عندما تحتاج إحداها إلى تعديل تلك الكتلة، وهو أسلوب النسخ عند الكتابة (copy-on-write). وبذلك تتمكن الطلبات التي تشترك في نفس السياق البادئ من التعايش مع توفير في الذاكرة.

التجميع المستمر: إبقاء GPU مشغولا دائما

النوع الثاني من الهدر هو هدر الوقت. يجمّع التجميع الثابت التقليدي (static batching) الطلبات في دفعة (batch) ويعالجها معا، ولا يبدأ الدفعة التالية حتى تنتهي جميع الطلبات في الدفعة الحالية. تكمن المشكلة في أن عدد الرموز التي يولّدها كل طلب يختلف من طلب لآخر. فالطلب الذي ينتج إجابة قصيرة ينتهي مبكرا، لكنه يظل بحاجة إلى الانتظار حتى ينتهي أطول طلب في الدفعة. وخلال ذلك، يبقى مكان GPU الذي كان يشغله الطلب المنتهي خاملا.

يزيل التجميع المستمر هذا الانتظار. يتخذ المجدول قراراته على مستوى التكرار (iteration) وليس على مستوى الدفعة، أي في كل تمرير أمامي (forward pass). فبمجرد انتهاء أي طلب في تلك الخطوة، يُملأ مكانه فورا بطلب جديد من قائمة الانتظار. وبما أن الطلبات الجارية والطلبات الجديدة تُمزج ديناميكيا في كل خطوة، فإن GPU لا يخمل تقريبا أبدا. ويُذكر أن هذا الأسلوب يرفع الإنتاجية على نفس العتاد بمقدار 3 إلى 10 أضعاف.

عند تطبيق PagedAttention والتجميع المستمر معا، الملاحظة الشائعة هي أن الإنتاجية تتحسن بمقدار يتراوح تقريبا بين ضعفين وأربعة أضعاف مقارنة بتنفيذ ساذج للخدمة. تكمّل التقنيتان بعضهما البعض. فلكي يتمكن التجميع المستمر من إدراج طلب جديد في كل خطوة، يحتاج إلى مرونة مماثلة في ربط الذاكرة وفصلها، وهذه المرونة هي بالضبط ما يوفره PagedAttention.

الأرقام أعلاه مأخوذة من مشروع vLLM ومصادر قياس أداء (benchmark) متعددة، والتحسن الفعلي يختلف باختلاف حجم النموذج، وتوزيع أطوال التسلسلات، والعتاد المستخدم. يجب قياس الأرقام الدقيقة الخاصة ببيئتك عبر حمل العمل الفعلي لديك.

كيف يُستخدم في بيئة الإنتاج

بعد فهم المفاهيم، يصبح التشغيل الفعلي بسيطا بشكل مفاجئ. يوفر vLLM خادما متوافقا مع OpenAI بشكل افتراضي، لذا فإن الشيفرة التي كانت تستدعي واجهة برمجية خارجية غالبا ما تعمل دون تعديل بمجرد تغيير عنوان نقطة النهاية (endpoint) فقط.

أبسط شكل لتشغيل الخادم كالتالي.

# تثبيت vLLM (بيئة CUDA)
pip install vllm

# تشغيل خادم متوافق مع OpenAI
vllm serve meta-llama/Llama-3.1-8B-Instruct \
  --tensor-parallel-size 1 \
  --max-model-len 8192 \
  --gpu-memory-utilization 0.90

الاستدعاء يستخدم عميل OpenAI الحالي كما هو.

from openai import OpenAI

client = OpenAI(base_url="http://localhost:8000/v1", api_key="EMPTY")
resp = client.chat.completions.create(
    model="meta-llama/Llama-3.1-8B-Instruct",
    messages=[{"role": "user", "content": "اشرح vLLM في جملة واحدة"}],
)
print(resp.choices[0].message.content)

النقطة التي تتطلب فعليا اهتماما في بيئة الإنتاج ليست أمر تشغيل الخادم نفسه، بل المعاملات التشغيلية المحيطة به. على وجه الخصوص، يجب الانتباه إلى التالي.

• --gpu-memory-utilization: نسبة ذاكرة GPU المخصصة لذاكرة KV المؤقتة. رفعها كثيرا يؤدي إلى تجاوز الذاكرة لحظيا، وخفضها كثيرا يقلل عدد الطلبات التي يمكن استقبالها في وقت واحد.
• --tensor-parallel-size: حجم التوازي على مستوى المصفوفات (tensor parallel) الذي يوزع النموذج على عدة وحدات GPU. ضروري عند خدمة نموذج كبير لا يتسع في GPU واحدة.
• --max-model-len: الطول الأقصى للسياق (context). كلما زاد هذا الرقم، كبرت ذاكرة KV المؤقتة لكل طلب، ما يخلق مفاضلة تقلل الإنتاجية المتزامنة.

عند التشغيل فوق Kubernetes، تُضاف إلى ذلك طبقة الجدولة وإدارة الموارد. GPU مورد باهظ الثمن ومحدود، لذا فبمجرد أن تشترك عدة فرق وعدة نماذج في عنقود (cluster) واحد، ينشأ تنافس على الموارد فورا. وهنا تأتي الحاجة إلى الجدولة الدفعية القائمة على قوائم الانتظار (queue-based batch scheduling). تضع ThakiCloud Kueue في هذه الطبقة لإدارة أي حمل عمل يشغل كم من GPU ومتى، كسياسة واضحة.

الآثار المترتبة على منتجات ThakiCloud

منصة ai-platform الخاصة بـ ThakiCloud هي بنية تحتية لخدمات الذكاء الاصطناعي وتعلم الآلة كخدمة (SaaS) قائمة على Kubernetes، وتُعد خدمة النماذج في بيئات متنوعة لدى العملاء قدرتها الأساسية. يمثّل vLLM المحرك الافتراضي في طبقة الخدمة هذه. تنعكس مكاسب الإنتاجية التي يحققها PagedAttention والتجميع المستمر مباشرة على خفض تكلفة الخدمة، وهذا ما يمكّننا من تقديم تكلفة خدمة منخفضة لعملائنا.

وتزداد قيمة هذا المزيج بشكل خاص في البيئات المحلية (on-premise) والبيئات ذات السيادة (sovereign). فالعملاء الذين لا يمكنهم إخراج بياناتهم إلى الخارج مضطرون لتشغيل النماذج داخل بنيتهم التحتية الخاصة من GPU، وفي هذه الحالة، يصبح رفع الإنتاجية التي تتحملها كل بطاقة GPU إلى أقصى حد ممكن هو ما يحدد إمكانية التبني نفسها. فإذا استخدم محرك الاستدلال GPU بكفاءة أعلى بمقدار الضعف، فهذا يعني أن نفس الخدمة يمكن تشغيلها بنصف العتاد.

من الناحية التشغيلية، القيمة التي تضيفها ThakiCloud ليست المحرك نفسه، بل الهيكل المحيط به: إدارة قوائم انتظار GPU عبر Kueue، والعزل بين المستأجرين المتعددين (multi-tenant isolation)، والتوسع التلقائي والمراقبة (observability)، وطبقة السياسات التي تتيح لعدة نماذج التعايش بأمان في عنقود واحد. إذا كان vLLM مسؤولا عن كفاءة خادم واحد، فإن المنصة مسؤولة عن جعل عشرات من هذه الخوادم قابلة للمشاركة بثبات عبر المؤسسة بأكملها.

القيود والحجج المضادة

vLLM ليس حلا سحريا شاملا. لديه بعض القيود الصادقة التي يجب ذكرها.

أولا، تتألق قوة vLLM في الإنتاجية، أي عند استقبال عدد كبير من الطلبات في وقت واحد. وعلى العكس، في حالات الحمل المنخفض حيث تصل الطلبات نادرا وواحدا تلو الآخر، لا تكون ميزة التجميع المستمر كبيرة، وقد يكون نهج آخر متخصص في تحسين زمن الاستجابة (latency) أفضل. يجب أولا فهم نمط حركة المرور الخاص بك، هل هو طلبات متزامنة بكميات كبيرة أم طلبات متفرقة أحادية.

ثانيا، الأرقام التي يقدمها PagedAttention والتجميع المستمر تعتمد بشدة على حمل العمل. ففي حالات أطوال التسلسل الطويلة جدا أو القصيرة جدا، أو على عتاد معين، قد لا تتكرر نسب التحسن المُبلَّغ عنها كما هي. يجب أن يستند قرار التبني إلى اختبار حمل فعلي يمثّل حمل العمل الخاص بك، ولا ينبغي افتراض أن المضاعف الذي أبلغ عنه طرف آخر سيكون هو نفسه لديك.

ثالثا، كلما تحسنت كفاءة المحرك، ينتقل عنق الزجاجة فعليا إلى مستوى أعلى، أي إلى الجدولة والتشغيل متعدد المستأجرين. مهما بلغت درجة تحسين خادم واحد، فإن مشكلة تنافس عدة فرق على GPU يجب حلها في طبقة المنصة وليس في طبقة المحرك. vLLM نقطة انطلاق ممتازة، لكنه ليس نقطة النهاية، والتحديات الحقيقية في بيئة الإنتاج تبدأ بعده مباشرة.

المصادر

• vLLM Explained: PagedAttention and Continuous Batching (RunPod)
• LLM Serving Optimization: Continuous Batching, PagedAttention, and Chunked Prefill (Spheron)
• vLLM Production Deployment (Introl)
• vLLM: Deploying LLMs at Scale (LearnOpenCV)

في 16 يوليو 2026، أطلقت شركة Moonshot AI الصينية نموذج Kimi K3. بإجمالي 2.8 تريليون معلمة، يُعد هذا أكبر نموذج مفتوح الأوزان تم الإفصاح عنه حتى الآن. وصفت وسائل إعلام عديدة هذا الإطلاق بأنه اللحظة التي وصل فيها معسكر النماذج المفتوحة الأوزان إلى مستوى الأداء المتقدم (frontier).

الجانب الذي لفت الانتباه أكثر من غيره كان الواجهة الأمامية (frontend). في اختبار من منصة تقييم الذكاء الاصطناعي Arena يقيس القدرة على بناء واجهات الويب، احتل Kimi K3 المرتبة الأولى، وفي اختبارات عمياء فضّل المطورون Kimi على Fable 5 من Anthropic وGPT-5.6 من OpenAI في برمجة الواجهات الأمامية. وقد عرضت Moonshot ذلك من خلال عرض توضيحي بنى لعبة ثلاثية الأبعاد بعالم مفتوح داخل متصفح الويب باستخدام Three.js وWebGPU.

بدلاً من تكرار ترتيب نتائج الاختبارات، تركز هذه المقالة على السؤال الذي يلي ذلك. مفتوح الأوزان يعني أن بإمكان أي شخص تشغيل هذا النموذج على بنيته التحتية الخاصة. فماذا يتطلب فعلياً تشغيل نموذج بـ 2.8 تريليون معلمة. بما أن ThakiCloud تعتبر تشغيل النماذج في البيئات المحلية (on-premise) لدى العملاء قدرة أساسية لديها، سنقرأ هذا الإطلاق من منظور المشغّل.

ما هو Kimi K3

Kimi K3 هو نموذج بمعمارية خليط الخبراء (Mixture of Experts، أو MoE). يمتلك إجمالي 2.8 تريليون معلمة، لكن ليست جميعها تُفعّل عند معالجة كل رمز (token). وفقاً للمعلومات المُعلنة، يُفعّل النموذج 16 خبيراً من أصل 896 خبيراً، ويُقدَّر عدد المعلمات النشطة المستخدمة فعلياً في الحساب بنحو 50 مليار [تقديري]. لم تُفصح Moonshot رسمياً عن عدد المعلمات النشطة.

من الناحية المعمارية، جرى تقديم ابتكارين. الأول هو Kimi Delta Attention (KDA)، والثاني هو Attention Residuals (AttnRes). تشرح Moonshot أن هذين العنصرين معاً يرفعان الكفاءة وجودة الاستدلال في آن واحد. يبلغ طول السياق مليون رمز، وهو تصميم يُقرأ على أنه موجّه نحو أعباء عمل الوكلاء (agent) التي تتعامل مع سياقات طويلة.

يجب توخي الحذر فيما يتعلق بالترخيص. صدرت السلسلة السابقة، Kimi K2، بترخيص MIT معدّل في يوليو 2025، لكن شروط ترخيص K3 نفسها لم تكن قد تأكدت أو أُعلنت بشكل نهائي وقت كتابة هذا المقال. تصف Moonshot النموذج K3 بأنه مفتوح، وأعلنت أنها ستنشر كامل الأوزان بحلول 27 يوليو 2026، لكن حتى وقت النشر لم تكن نقاط التحقق (checkpoints) الرسمية قد ظهرت بعد على حساب Moonshot التنظيمي في Hugging Face. لذلك، فإن أي جهة تفكر في اعتماد النموذج فعلياً يجب أن تتحقق بنفسها من نص الترخيص النهائي ومن حالة توفر الأوزان.

لماذا يهم هذا الإطلاق

لم يعد أمراً نادراً أن يتفوق نموذج مفتوح الأوزان على أفضل النماذج المغلقة في مهمة ضيقة محددة. لكن أن يحتل هذا الموقع في مجال يستخدمه المطورون يومياً، وهو برمجة الواجهات الأمامية، وبأكبر مجموعة أوزان مفتوحة في العالم، أمر يحمل دلالة مختلفة. فهذا إشارة إلى ظهور بديل يمكن تشغيله ذاتياً، بعد أن كانت الحاجة إلى الأداء وحدها تفرض الارتباط بواجهات برمجية مغلقة.

الواجهة الأمامية وتوليد واجهات المستخدم تحديداً مجال يمكن فيه رؤية النتيجة بالعين مباشرة. وفي هذا السياق يأتي تأكيد Moonshot على ما تسميه الرؤية داخل الحلقة (vision in the loop)، وهي دورة يرى فيها النموذج ما ولّده ثم يصححه. الادعاء هو أن هذه الحلقة مفيدة بشكل خاص في المهام البصرية مثل تطوير الألعاب وتصميم واجهات المستخدم والتصميم بمساعدة الحاسوب. إنه تجاوز لمجرد توليد الكود كنص، نحو اعتماد النتيجة المعروضة فعلياً كتغذية راجعة.

ماذا يعني فعلياً تشغيل نموذج بـ 2.8 تريليون معلمة

هنا يبدأ مجال المشغّل. هناك مسافة كبيرة بين حقيقة أن النموذج مفتوح الأوزان وحقيقة أن بإمكانك تشغيله ذاتياً.

الذاكرة أولاً. تحميل كامل 2.8 تريليون معلمة بدقتها الأصلية يتطلب عدة تيرابايت من ذاكرة GPU. هذا مستوى يصعب على GPU واحد التعامل معه، بل حتى على خادم واحد يحتوي عدة وحدات GPU، مما يجعل التشغيل الموزّع عبر عقد (nodes) متعددة أمراً مفروضاً مسبقاً. غير أن بنية MoE تخفف العبء إلى حد ما. بما أن جزءاً فقط من الخبراء يُفعّل لكل رمز وليس النموذج بأكمله، يبقى حجم الحساب الفعلي قريباً من حجم المعلمات النشطة. ومع ذلك، يجب أن تبقى أوزان جميع الخبراء مقيمة في الذاكرة كي يمكن استدعاؤها في أي وقت، لذا يبقى عبء التخزين مرتبطاً بإجمالي عدد المعلمات.

لهذا السبب تصبح تقنيتان شبه إلزاميتين للتشغيل الذاتي الواقعي. الأولى هي التكميم (quantization). خفض دقة الأوزان إلى 8 بت أو 4 بت يقلل استهلاك الذاكرة ويخفض بشكل كبير عدد وحدات GPU المطلوبة. والثانية هي التوازي (parallelism). يقسّم التوازي الموتري (tensor parallelism) طبقات النموذج عبر عدة وحدات GPU، وبالنسبة لنماذج MoE، يضيف التوازي بين الخبراء (expert parallelism) توزيع الخبراء عبر عدة أجهزة. مسار التشغيل يمكن تصويره كما يلي.

flowchart TB
    A[طلب المستخدم] --> B[بوابة التوجيه<br/>اختيار الخبراء لكل رمز]
    B --> C{الخبراء النشطون فقط<br/>16 of 896}
    C --> D[التوازي الموتري<br/>تقسيم الطبقات عبر GPU]
    C --> E[توازي الخبراء<br/>توزيع الخبراء عبر العقد]
    D --> F[أوزان مكمَّمة<br/>4-bit أو 8-bit]
    E --> F
    F --> G[تنفيذ الاستدلال الموزّع]
    G --> H[بث الاستجابة]
    H -.ترحيل ذاكرة التخزين المؤقت KV.-> I[(ذاكرة GPU<br/>متعددة العقد)]

هذه هي النقطة الجوهرية. مفتوح الأوزان يعني أن الأوزان مجانية، لا أن التشغيل مجاني. تشغيل نموذج بهذا الحجم بشكل موثوق على بنيتك التحتية الخاصة يتطلب عنقود GPU متعدد العقد، وخط أنابيب للتكميم، ومحرك استدلال موزّع، وطبقة جدولة ومراقبة تربط كل ذلك معاً. هنا بالضبط تظهر قيمة المنصة.

دلالات على منتجات ThakiCloud

يوضح هذا الإطلاق في آن واحد سبب الحاجة إلى منتجين من منتجات ThakiCloud.

أولاً، من منظور البنية التحتية: ai-platform. منصة ai-platform لدى ThakiCloud هي بنية تحتية للذكاء الاصطناعي وتعلّم الآلة قائمة على Kubernetes، توفر جدولة GPU عبر Kueue، وعزلاً متعدد المستأجرين (multi-tenant)، وتشغيلاً موزّعاً، وقابلية مراقبة. بالنسبة لعميل يرغب في تشغيل نموذج ضخم مفتوح الأوزان مثل Kimi K3 على بنيته التحتية الخاصة، هذه الطبقة ليست خياراً بل شرطاً مسبقاً. إدارة موارد GPU عبر عقد متعددة وفق سياسات محددة، وتحويل التشغيل المكمَّم والموازي إلى شكل قابل للتشغيل الفعلي، هو ما يحدد إمكانية الاعتماد من الأساس. في بيئة ذات سيادة بيانات (sovereign) لا يمكن فيها إخراج البيانات إلى الخارج، تصبح القدرة على تشغيل نموذج مفتوح الأوزان بمستوى متقدم ذاتياً مبرراً قوياً بحد ذاته للاعتماد على المنصة.

ثانياً، من منظور الوكلاء (agents): Paxis. قوة Kimi K3 في برمجة الواجهات الأمامية والتوليد البصري ترتبط مباشرة بوكلاء البرمجة. Paxis هي السحابة الأصلية للوكلاء (Agent-Native Cloud) لدى ThakiCloud، وتتعامل مع المهارات (skills) والأدوات والسياسات وسجلات التدقيق كموارد من الدرجة الأولى. تُشغّل المهارات داخل صناديق رملية (sandbox) معزولة، وتنسّق وكلاء متعددين على شكل رسم بياني موجّه غير دوري (DAG)، وتُمرر كل إجراء عبر بوابات سياسات وسجلات تدقيق. بالنسبة لمنظمة ترغب في تشغيل وكيل برمجة يعتمد على الرؤية داخل الحلقة، أي يولّد كوداً ويتحقق من نتيجته ويصححه، ضمن حدود تنفيذ آمنة، تصبح طبقة التحكم هذه ضرورة. وعندما يلتقي نموذج برمجة قوي مفتوح الأوزان مع بيئة تنفيذ آمنة للوكلاء، تكتمل صورة وكيل برمجة عملي يعمل على البنية التحتية الخاصة بك.

المنظوران يكمّلان بعضهما البعض. التشغيل الذاتي منخفض التكلفة (ai-platform) هو ما يجعل تشغيل الوكلاء بشكل مستمر أمراً مجدياً اقتصادياً (Paxis)، وعبء عمل الوكلاء القوي (Paxis) هو ما يمنح بنية التشغيل هذه (ai-platform) سبب وجودها.

حدود وحجج مضادة

بمعزل عن الحماس السائد، هناك نقاط تستحق نظرة باردة.

أولاً، حتى وقت كتابة هذا المقال، قد لا تكون كامل الأوزان قد نُشرت بشكل كامل بعد، ولم تُحسم شروط الترخيص النهائية. نتيجة اختبار الأداء وحصولك الفعلي على نموذج يمكن تشغيله تجارياً أمران مختلفان. من يفكر في الاعتماد على النموذج يجب أن يبني قراره على الأوزان المنشورة فعلياً ونص الترخيص، لا على مواد الإعلان.

ثانياً، احتلال المرتبة الأولى في اختبار أداء لا يعني تفوقاً في كل الحالات. اختبار تفضيل الواجهة الأمامية هو تقييم نسبي في مهمة محددة، ويجب التحقق مباشرة من كيفية أداء النموذج في عبء العمل الفعلي لديك. افتراض أن نتيجة أعلنها آخرون تنطبق على نتائجك الخاصة أمر محفوف بالمخاطر.

ثالثاً، التكلفة الإجمالية للتشغيل الذاتي ليست صغيرة على الإطلاق. عند احتساب وحدات GPU والطاقة والكوادر التشغيلية اللازمة لتشغيل نموذج بـ 2.8 تريليون معلمة عبر عقد متعددة، قد يكون استخدام واجهة برمجية مغلقة في الواقع أرخص للمنظمات ذات حركة المرور المنخفضة. الميزة الحقيقية للنماذج مفتوحة الأوزان ليست منخفضة التكلفة بشكل مطلق، بل تكمن في سيادة البيانات، وتجنب الارتباط بمزوّد واحد، وإمكانية التحكم في التكلفة عند الحجم الكافي. يجب حساب حجم حركة المرور ومتطلبات البيانات الخاصة بك أولاً، ثم اتخاذ القرار.

المصادر

• China’s Moonshot AI releases Kimi K3, the largest open-source model ever (VentureBeat)
• Moonshot AI Releases Kimi K3: A 2.8 Trillion Parameter Open MoE Model With Kimi Delta Attention (MarkTechPost)
• China’s open-weight Kimi model stuns AI world with frontier-level results (Axios)
• China’s Moonshot throws down the gauntlet with Kimi K3 (SiliconANGLE)

جزء كبير مما تنفقه على الذكاء الاصطناعي لا يذهب لأن النموذج ذكي. بل يذهب إلى القرار نفسه المكرَّر آلاف أو عشرات آلاف المرات يوميًا: “هل هذا الطلب آمن؟”، “إلى أي فئة ينتمي هذا المستند؟”، “هل نبرة هذه الجملة مناسبة؟” حين تستدعي نموذجًا خارجيًا من الطبقة العليا لهذا العمل المتكرر في كل مرة، تتضخّم التكلفة مع الحجم وتغادر البيانات الحسّاسة جدرانك عند كل استدعاء.

اقتراح ThakiCloud بسيط: افصل هذا العمل المتكرر وحده إلى نماذج صغيرة متخصّصة تعمل على بنيتك الخاصة (محليًا)، واحتفظ بالنموذج الأعلى المكلف للمهام القليلة التي تتطلب حكمًا فعليًا. تحقّقنا أن ذلك يعمل فعلًا — بالقياس لا بالتنبؤ — ونشرنا كل شيء. يصوغ هذا المقال قصة التكلفة تلك بلغة صنّاع القرار.

لماذا يهم هذا الآن

بمجرد إدخال الذكاء الاصطناعي التوليدي إلى التشغيل الفعلي، تنمو ثلاثة أمور معًا. التكلفة ترتفع خطيًا مع حجم الاستدعاءات. تعرّض البيانات يحدث في كل استدعاء لواجهة خارجية. والارتهان لمزوّد نموذج خارجي بعينه يزداد عمقًا. الثلاثة مخاطر يريد التنفيذيون السيطرة عليها.

وهنا الجوهر. عند تحليل ما يفعله الذكاء الاصطناعي لديك فعلًا، معظمه حُكم ضيّق ومتكرر، والحكم الإبداعي الحقيقي هو الأقلية. ومع ذلك يُسنَد كلاهما اليوم إلى النموذج الأعلى نفسه دون تمييز — كإسناد فرز مستندات بسيط إلى أعلى خبير أجرًا لديك.

نهجنا: العمل المتكرر إلى نماذج متخصّصة، محليًا

للطريقة ثلاث خطوات. أولًا، صمّم سير العمل بنموذج كبير. ثانيًا، ثبّت ما يمكن اختزاله إلى قواعد كشيفرة. ثالثًا، خذ فقط القرارات المتكررة الضيقة التي تحتاج فعلًا إلى نموذج لغوي ودرّب نموذجًا صغيرًا متخصّصًا (أقل من مليار معامل، 4 بت) لها. عندها يعمل ذلك العمل على وحدة معالجة رسومية محلية شائعة واحدة، ويُنفَق النموذج الأعلى على ما يهم فعلًا فقط.

تحوّل منصّة ThakiCloud هذا السير بالضبط إلى منتج. فهي تُدرّب النموذج الصغير المتخصّص كخدمة مُدارة (دون أن تضطر للتعامل مع بنية وحدات المعالجة الرسومية) وتخدّمه على عتادك المحلي الخاص. التجربة في هذا المقال دليل على أن النمط يعمل؛ والمنصّة هي ما يجعله قابلًا للتكرار والتشغيل.

flowchart TD
    A[AI workflow requests] --> B{Repetitive narrow judgment?}
    B -->|Yes: safety check, doc class, tone check| C[Small specialized SLM<br/>under 1B params, 4-bit<br/>~5MB LoRA adapter per task]
    B -->|No: genuine judgment| D[Top-tier external model<br/>reserved for the few]
    C --> E[On-prem GPU<br/>data never leaves your walls]
    E --> F[~3.6x cheaper per 1k calls<br/>tone accuracy 38.6% to 99.1%]
    D --> G[Higher per-call cost<br/>used sparingly]
    subgraph BUILD [Build pipeline]
        H[1. Design flow with top model] --> I[2. Freeze rules as code]
        I --> J[3. Fine-tune small SLM<br/>for narrow judgments]
    end
    J -. provisions .-> C

وجّه القرارات المتكررة الضيقة إلى نموذج صغير متخصّص محلي لخفض التكلفة لكل استدعاء وإبقاء البيانات داخليًا، واحتفظ بالنموذج الأعلى للمهام القليلة التي تحتاج حكمًا فعليًا. كل نموذج متخصّص مُرفق بنحو 5 ميغابايت لكل مهمة، فتتبدّل عدة مهام على نموذج أساس واحد مشترك.

ما الذي قِسناه

تجنّبًا للمبالغة، قِسنا ونشرنا كل رقم. البيئة بطاقة واحدة، دون أي استدعاء لواجهة خارجية في أي مرحلة من التدريب أو الاستدلال — تبقى السلسلة كاملة داخل بنيتك الخاصة. هكذا تبدو سيادة البيانات عمليًا.

التكلفة. محليًا، عالج النموذج الصغير المتخصّص 1000 استدعاء بتكلفة أقل بنحو 3.6 مرة من واجهة خارجية من الطبقة العليا. هذا الرقم بتيار مفرد؛ والمعالجة على دفعات كما في التشغيل الحقيقي توسّع الفارق أكثر.

الجودة. في القرارات المتكررة الضيقة قفز النموذج الصغير. ارتفع تصنيف النبرة الكورية من 38.6% قبل التدريب إلى 99.1% بعده؛ وانتقل تصنيف الأخبار من شبه العشوائي إلى أكثر من 80%. وعند إعادة الفحص على جمل حقيقية لم تُرَ في التدريب، بقي متوافقًا مع الإجابة الصحيحة بنحو 88% في قرارات الأمان و89% في التصنيف.

الاقتصاد. يُنتَج كل نموذج متخصّص كمُرفق صغير بنحو 5 ميغابايت لكل مهمة. تكاد جودته تطابق إعادة تدريب النموذج بالكامل من الصفر (99.1% مقابل 96.9%) بنحو جزء من 300 من الحجم، ويمكنك تبديل عدة مهام على نموذج أساس واحد مشترك. بل تولّى نموذج صغير واحد أربع مهام متكررة في آن. تشغيليًا، يُترجَم هذا مباشرة إلى “عمل أكثر بعتاد أقل”.

الحدود، بصدق

نقطة نذكرها بوضوح: في مهمة عامة كان النموذج الأعلى يتقنها أصلًا، أدى التدريب المتخصّص المتسرّع إلى إضعافها. بمعنى آخر، هذا النهج ليس شيئًا تطبّقه على أي مهمة، بل على مهام متكررة وضيقة تُنتقى بعناية. ومعرفة أين تطبّقه وأين لا، هي بالضبط حيث تثبت المنصّة والخبرة قيمتهما. ننشر النتائج الجيدة والسيئة معًا.

لصانع القرار، باختصار

أولًا، جزء كبير من تكلفة تشغيل الذكاء الاصطناعي لديك يتسرّب إلى العمل المتكرر، وهذا الجزء يمكن خفضه هيكليًا. ثانيًا، طريقة الخفض هي فصل ذلك العمل المتكرر إلى نماذج صغيرة متخصّصة تعمل محليًا، ما يؤمّن توفير التكلفة وسيادة البيانات معًا. ثالثًا، تقدّم منصّة ThakiCloud هذا كخدمة مُدارة، فتتبنّاه دون أن تتحمّل شخصيًا تعقيد بنية وحدات المعالجة الرسومية وتدريب النماذج.

الشيفرة الكاملة للتجربة والنتائج المقيسة متاحة وقابلة لإعادة الإنتاج: github.com/sylvanus4/tiny-skill-distill. ويسعدنا أن نقيّم معك أي أحمال عمل الذكاء الاصطناعي لديك يمكن نقلها إلى نماذج متخصّصة وكم سيخفض ذلك تكلفتك.

نظرة عامة

أصدرت Moonshot AI نموذج Kimi K3 في 16 يوليو 2026. وفق الشركة، فهو نموذج Mixture-of-Experts بحجم 2.8 تريليون معامل ومن بين أكبر النماذج مفتوحة الأوزان الصادرة حتى الآن. الجزء المثير للاهتمام ليس النتائج فحسب. فهذا النموذج غير محصور داخل روبوت محادثة مملوك؛ بل يتصل كمزوّد بوكيل برمجة مفتوح المصدر يعمل في الطرفية. بعبارة أخرى، أصبح بالإمكان الفصل بين “أي بيئة تطوير تستخدم” و”أي نموذج تبرمج به”.

من منظور ThakiCloud، يهمّ هذا الاقتران لسببين. أولًا، وكيل برمجة قادر على تبديل النماذج بحرية بدلًا من الارتباط بمزوّد يتوافق مع الفرضية الأساسية لتصميم منصات الوكلاء. ثانيًا، نموذج مفتوح الأوزان بحجم 2.8 تريليون معامل يجب أن يخدمه أحدهم على وحدات GPU حقيقية، وتكلفة تلك الخدمة ومتطلبات التشغيل المحلي تعود مباشرةً كأسئلة بنية تحتية. فيما يلي نثبّت الأداة عمليًا للتحقق من مسار الاتصال، ثم نعالج المنظورين.

ما هي هذه الأدوات

OpenCode هو وكيل برمجة مفتوح المصدر يعمل في الطرفية. يقرأ ملفات قاعدة الشيفرة، ويشرح البنية، ويحرّر الشيفرة، ويراجع التغييرات، وينفّذ المهام عبر مزوّد LLM متصل. ولأنه غير مرتبط بنموذج واحد بل يبدّل المزوّدين، يمكنك الاحتفاظ بسير العمل نفسه وتغيير النموذج تحته فقط.

Kimi K3 هو النموذج الذي يشغل خانة المزوّد تلك. وفق إعلان Moonshot AI، المواصفات الأساسية كالتالي. إنه نموذج MoE بحجم 2.8 تريليون معامل، يُفعَّل منه 16 خبيرًا من أصل 896 لكل رمز (token). ويستخدم الانتباه آلية Kimi Delta Attention (KDA)، وهي انتباه خطي هجين. يُضاف إلى ذلك تقنية Attention Residuals (بديل عن الوصلات المتبقية)، وفهم بصري أصيل، ونافذة سياق تصل إلى مليون رمز. ومن المقرر إصدار أوزان النموذج الكاملة في 27 يوليو 2026.

يبدو مسار ربط الأداتين كالتالي.

flowchart TB
  A[طرفية المطوّر<br/>OpenCode TUI أو run] --> B[طبقة المزوّد<br/>opencode auth login]
  B --> C{اختيار النموذج<br/>/models أو opencode models}
  C --> D[مزوّد Moonshot AI<br/>Kimi K3]
  D --> E[Kimi Delta Attention<br/>2.8T MoE · 896 خبيرًا · 16 مُفعَّل لكل رمز]
  E --> F[قراءة · تحرير · مراجعة · تشغيل الشيفرة<br/>سياق حتى 1M]
  F -.دورة الجلسة.-> A

الفرق عن النهج المعتاد واضح. وكيل الواجهة الرسومية لمزوّد ما يأتي بالنموذج والأداة كحزمة واحدة. أما وكيل مفتوح المصدر مثل OpenCode فيثبّت الأداة ويبدّل المزوّد فقط. نموذج ذاتي الاستضافة بالأمس، و Kimi K3 اليوم، ونموذج آخر غدًا، عبر واجهة الأوامر نفسها.

التثبيت والتكامل

تحققنا من مسار التثبيت والاتصال عمليًا في بيئة معزولة. الأوامر والإصدارات أدناه قيم فعلية التقطناها أثناء إعادة الإنتاج.

أولًا ثبّت OpenCode. نجح التثبيت العام عبر npm فورًا.

npm install -g opencode-ai
opencode --version
# 1.18.3

فحصنا سطح الأوامر الذي توفّره الأداة المثبّتة. من تشغيل واجهة TUI إلى التنفيذ بلا واجهة، وإدارة المزوّدين، وسرد النماذج، وإدارة خوادم MCP، فهي تغطي ما يحتاجه وكيل البرمجة.

opencode --help
# opencode [project]        start opencode tui              [default]
# opencode run [message..]  run opencode with a message
# opencode providers        manage AI providers and credentials   [aliases: auth]
# opencode models [provider]  list all available models
# opencode mcp              manage MCP (Model Context Protocol) servers
# opencode agent            manage agents
# opencode serve            starts a headless opencode server

تتولّى الأوامر الفرعية opencode auth مصادقة المزوّد.

opencode auth --help
# opencode auth list    list providers and credentials   [aliases: ls]
# opencode auth login   log in to a provider
# opencode auth logout  log out from a configured provider

ترتيب ربط Kimi K3 كالتالي، وفق دليل OpenCode الرسمي من Moonshot AI.

1. أنشئ مفتاح API على منصة Kimi المفتوحة واحتفظ به بشكل خاص.
2. شغّل opencode auth login، واختر Moonshot AI كمزوّد، ثم أدخل مفتاح API.
3. داخل OpenCode، استخدم /models (أو opencode models moonshotai في الصدفة) لاختيار Kimi K3.
4. تحقق من الاتصال بمهمة منخفضة المخاطر.

opencode run "اشرح بنية مجلدات هذا المشروع وأوصِ بأول ثلاثة ملفات ينبغي قراءتها."

حقيقة تستحق التثبيت: بعد التثبيت مباشرةً، لم يتضمن كتالوج النماذج الافتراضي مزوّد Moonshot. أثناء إعادة الإنتاج، أعادت تصفية opencode models بحثًا عن Moonshot/Kimi نتيجة فارغة، ما يعني أنه يجب إضافة المزوّد صراحةً عبر auth login قبل ظهوره في الكتالوج. لذا فالخطوة 2 أعلاه ليست اختيارية بل إلزامية.

النتائج الفعلية

نفصل القيم التي التقطناها مباشرةً عن الأرقام المنشورة للنموذج. تثبيت الأداة ومسار الاتصال قِيَما مُقاسة عمليًا؛ أما درجات القياس فهي أرقام مُبلَّغ عنها من Moonshot وطرف ثالث (Artificial Analysis).

النتائج المقاسة مباشرةً:

• نجح تثبيت OpenCode، الإصدار 1.18.3 (npm opencode-ai، رمز الخروج 0).
• تأكدنا أن الأداة توفّر مصادقة المزوّد (auth)، وسرد النماذج (models)، والتنفيذ بلا واجهة (run)، وإدارة MCP (mcp)، وإدارة الوكلاء (agent).
• بعد التثبيت مباشرةً، لم يتضمن الكتالوج الافتراضي مزوّد Moonshot، فوجب إضافته صراحةً عبر auth login.

لم نشغّل استدلال Kimi K3 المباشر. يتطلب استدعاء Kimi K3 مفتاح API مدفوعًا برصيد (لا يمكن استخدام قسائم التحقق للمستخدمين الجدد مع K3)، ولم يتوفّر مثل هذا المفتاح في بيئة إعادة الإنتاج. لذا نرسم الحد عند “تثبيت واتصال مُقاسان، وجودة توليد الشيفرة الفعلية مُقتبسة من أرقام منشورة”. لا نختلق أرقامًا لم نرصدها.

المقاييس المنشورة للنموذج أدناه. هذه الدرجات أرقام مُبلَّغ عنها وفق Artificial Analysis، ولأن الأوزان لم تُنشر بالكامل بعد، فإنها لم تُتحقق عبر إعادة إنتاج مستقلة.

بقراءة الأرقام كما هي، يقع Kimi K3 في النطاق أسفل النماذج الحدّية العليا مباشرةً. واحتلاله المركز الثاني في AA-Briefcase، الذي يقيس العمل المعرفي طويل الأمد، إشارة إلى أنه صالح لمهام الوكلاء متعددة الخطوات مثل البرمجة. مع ذلك، هذه أرقام مُبلَّغ عنها، ويبقى الإحساس الفعلي في سير عمل برمجي حقيقيًا أدق عند التحقق منه على قاعدة شيفرتك الخاصة.

دلالات على منصة ThakiCloud

يمسّ هذا الاقتران عدستَي منتجَي ThakiCloud معًا. الأولى عدسة منصة الوكلاء، والثانية عدسة خدمة البنية التحتية.

عدسة Paxis (الوكلاء والأدوات والنماذج القابلة للاستبدال). Paxis هو مستوى التحكم في سحابة ThakiCloud الأصلية للوكلاء (Agent-Native Cloud)، ويعامل Skills و Tools و Policies و Audit Logs كموارد من الدرجة الأولى. البنية التي يظهرها OpenCode، أي “ثبّت الأداة وبدّل المزوّد”، تتطابق تمامًا مع فلسفة تصميم Paxis. في Paxis، يختار وكيل البرمجة من أكثر من 960 مهارة عبر BM25، ويشغّلها في صناديق رمل معزولة، ويمرّر كل إجراء عبر بوابات السياسات وسجلات التدقيق. اربط نموذجًا مفتوح الأوزان مثل Kimi K3 كمزوّد، وستتمكن من تبديل دماغ الوكيل حسب التكلفة والأداء مع الحفاظ على عزل التنفيذ والتدقيق. كما أن احتواء OpenCode على إدارة مدمجة لخوادم MCP (opencode mcp) يتصل بطبيعة الحال بمعاملة Paxis لموصّلات MCP كموارد من الدرجة الأولى.

عدسة ai-platform (خدمة نموذج بحجم 2.8T). مفتوح الأوزان يعني أن على أحدهم خدمة هذا النموذج على وحدات GPU حقيقية. نموذج MoE بحجم 2.8 تريليون معامل يُفعّل 16 خبيرًا فقط لكل رمز، فالمعاملات النشطة أصغر بكثير من الإجمالي، لكن البنية ما تزال تتطلب إبقاء جميع الخبراء الـ896 في الذاكرة، لذا فعتبة الخدمة المحلية ليست منخفضة. هنا تجيب منصة ThakiCloud ai-platform عن السؤال. عندما تجتمع جدولة GPU المبنية على K8s و Kueue، وخدمة vLLM/SGLang، والتكميم (quantization) لتوفير الذاكرة، يمكن تشغيل نماذج مفتوحة كبيرة كهذه اقتصاديًا في بيئة متعددة المستأجرين. وحين تصدر الأوزان في 27 يوليو، يمكن مقارنة منحنى تكلفة الاستضافة الذاتية مقابل استدعاءات API فعليًا. وتكلفة الخدمة المنخفضة تُترجَم إلى اقتصاديات الوكلاء، وهذا بدوره يخفّض تكلفة تشغيل الوكلاء العاملين على Paxis. كلتا العدستين تشيران إلى الاتجاه نفسه.

الحدود والاعتراضات

نذكر بعض الاعتراضات الرصينة معًا.

أولًا، درجات القياس تختلف عن الإحساس الفعلي بالبرمجة. المركز الثاني في AA-Briefcase لا يضمن “الأفضل على قاعدة شيفرتي”. فقد يكون النموذج الأعلى ترتيبًا أضعف في لغة أو إطار عمل أو عُرف داخلي بعينه، لذا يجب التحقق من التبنّي على عملك الفعلي.

ثانيًا، تصل قياسات هذا المقال إلى التثبيت ومسار الاتصال. لم يُشغَّل استدلال Kimi K3 المباشر بسبب قيد مفتاح API المدفوع. تبقى جودة التوليد الفعلية والكمون وتكلفة الرموز أمورًا عليك إعادة قياسها بمفتاحك الخاص.

ثالثًا، “مفتوح الأوزان” لا يعني “مجاني” أو “سهل التشغيل”. حتى مع نشر الأوزان، فإن خدمة نموذج MoE بحجم 2.8T بثبات تتطلب موارد GPU كبيرة وكفاءة تشغيلية. ونقطة التعادل بين الاستضافة الذاتية واستدعاءات API تعتمد على الاستخدام ومتطلبات الكمون.

رابعًا، تحتاج واجهة Kimi K3 إلى رصيد، ولا يمكن استخدام قسائم المستخدمين الجدد مع K3. لا تتوقع استخدامًا مجانيًا غير محدود لنموذج من الطبقة العليا. ومع ذلك، فإن الحرية البنيوية في اختيار الأداة والنموذج بشكل مستقل موقع أفضل على المدى الطويل من الارتباط بمزوّد واحد.

المصادر

• MarkTechPost, “Moonshot AI Releases Kimi K3: A 2.8 Trillion Parameter Open MoE Model With Kimi Delta Attention and 1M Context” (2026-07-16)
• Fortune, “Moonshot’s Kimi K3 pushes Chinese AI into Fable-level territory” (2026-07-16)
• Artificial Analysis, صفحة نموذج “Kimi K3” (مصدر أرقام معياري GDPval-AA v2 و AA-Briefcase في هذا المقال)
• Kimi API Platform, “Use Kimi Models in OpenCode”
• OpenCode (sst/opencode), إصدار v1.18.3
• Simon Willison, “Kimi K3, and what we can still learn from the pelican benchmark” (2026-07-16)
• VentureBeat, “China’s Moonshot AI releases Kimi K3, the largest open-source model ever” (المقال موجود، لكن لم يتم التحقق من استجابة الرابط في هذه الجلسة)
• OpenCode 1.18.3 (npm install -g opencode-ai): الأوامر والإصدار قيم إعادة إنتاج مُلتقطة مباشرةً