جزء كبير مما تنفقه على الذكاء الاصطناعي لا يذهب لأن النموذج ذكي. بل يذهب إلى القرار نفسه المكرَّر آلاف أو عشرات آلاف المرات يوميًا: “هل هذا الطلب آمن؟”، “إلى أي فئة ينتمي هذا المستند؟”، “هل نبرة هذه الجملة مناسبة؟” حين تستدعي نموذجًا خارجيًا من الطبقة العليا لهذا العمل المتكرر في كل مرة، تتضخّم التكلفة مع الحجم وتغادر البيانات الحسّاسة جدرانك عند كل استدعاء.
اقتراح ThakiCloud بسيط: افصل هذا العمل المتكرر وحده إلى نماذج صغيرة متخصّصة تعمل على بنيتك الخاصة (محليًا)، واحتفظ بالنموذج الأعلى المكلف للمهام القليلة التي تتطلب حكمًا فعليًا. تحقّقنا أن ذلك يعمل فعلًا — بالقياس لا بالتنبؤ — ونشرنا كل شيء. يصوغ هذا المقال قصة التكلفة تلك بلغة صنّاع القرار.
بمجرد إدخال الذكاء الاصطناعي التوليدي إلى التشغيل الفعلي، تنمو ثلاثة أمور معًا. التكلفة ترتفع خطيًا مع حجم الاستدعاءات. تعرّض البيانات يحدث في كل استدعاء لواجهة خارجية. والارتهان لمزوّد نموذج خارجي بعينه يزداد عمقًا. الثلاثة مخاطر يريد التنفيذيون السيطرة عليها.
وهنا الجوهر. عند تحليل ما يفعله الذكاء الاصطناعي لديك فعلًا، معظمه حُكم ضيّق ومتكرر، والحكم الإبداعي الحقيقي هو الأقلية. ومع ذلك يُسنَد كلاهما اليوم إلى النموذج الأعلى نفسه دون تمييز — كإسناد فرز مستندات بسيط إلى أعلى خبير أجرًا لديك.
للطريقة ثلاث خطوات. أولًا، صمّم سير العمل بنموذج كبير. ثانيًا، ثبّت ما يمكن اختزاله إلى قواعد كشيفرة. ثالثًا، خذ فقط القرارات المتكررة الضيقة التي تحتاج فعلًا إلى نموذج لغوي ودرّب نموذجًا صغيرًا متخصّصًا (أقل من مليار معامل، 4 بت) لها. عندها يعمل ذلك العمل على وحدة معالجة رسومية محلية شائعة واحدة، ويُنفَق النموذج الأعلى على ما يهم فعلًا فقط.
تحوّل منصّة ThakiCloud هذا السير بالضبط إلى منتج. فهي تُدرّب النموذج الصغير المتخصّص كخدمة مُدارة (دون أن تضطر للتعامل مع بنية وحدات المعالجة الرسومية) وتخدّمه على عتادك المحلي الخاص. التجربة في هذا المقال دليل على أن النمط يعمل؛ والمنصّة هي ما يجعله قابلًا للتكرار والتشغيل.
تجنّبًا للمبالغة، قِسنا ونشرنا كل رقم. البيئة بطاقة واحدة، دون أي استدعاء لواجهة خارجية في أي مرحلة من التدريب أو الاستدلال — تبقى السلسلة كاملة داخل بنيتك الخاصة. هكذا تبدو سيادة البيانات عمليًا.
التكلفة. محليًا، عالج النموذج الصغير المتخصّص 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.
opencode auth login، واختر Moonshot AI كمزوّد، ثم أدخل مفتاح API./models (أو opencode models moonshotai في الصدفة) لاختيار Kimi K3.opencode run "اشرح بنية مجلدات هذا المشروع وأوصِ بأول ثلاثة ملفات ينبغي قراءتها."
حقيقة تستحق التثبيت: بعد التثبيت مباشرةً، لم يتضمن كتالوج النماذج الافتراضي مزوّد Moonshot. أثناء
إعادة الإنتاج، أعادت تصفية opencode models بحثًا عن Moonshot/Kimi نتيجة فارغة، ما يعني أنه يجب
إضافة المزوّد صراحةً عبر auth login قبل ظهوره في الكتالوج. لذا فالخطوة 2 أعلاه ليست اختيارية بل
إلزامية.
نفصل القيم التي التقطناها مباشرةً عن الأرقام المنشورة للنموذج. تثبيت الأداة ومسار الاتصال قِيَما مُقاسة عمليًا؛ أما درجات القياس فهي أرقام مُبلَّغ عنها من Moonshot وطرف ثالث (Artificial Analysis).
النتائج المقاسة مباشرةً:
opencode-ai، رمز الخروج 0).auth)، وسرد النماذج (models)، والتنفيذ بلا واجهة
(run)، وإدارة MCP (mcp)، وإدارة الوكلاء (agent).auth login.لم نشغّل استدلال Kimi K3 المباشر. يتطلب استدعاء Kimi K3 مفتاح API مدفوعًا برصيد (لا يمكن استخدام قسائم التحقق للمستخدمين الجدد مع K3)، ولم يتوفّر مثل هذا المفتاح في بيئة إعادة الإنتاج. لذا نرسم الحد عند “تثبيت واتصال مُقاسان، وجودة توليد الشيفرة الفعلية مُقتبسة من أرقام منشورة”. لا نختلق أرقامًا لم نرصدها.
المقاييس المنشورة للنموذج أدناه. هذه الدرجات أرقام مُبلَّغ عنها وفق Artificial Analysis، ولأن الأوزان لم تُنشر بالكامل بعد، فإنها لم تُتحقق عبر إعادة إنتاج مستقلة.
| المقياس | Kimi K3 | الترتيب | النماذج الأعلى / للمقارنة |
|---|---|---|---|
| GDPval-AA v2 | 1,687 | الثالث | Fable 5 Max 1,815 · GPT-5.6 Sol Max 1,747.8 · (Opus 4.8 1,600) |
| AA-Briefcase | 1,527 | الثاني | Fable 5 Max 1,587 · GPT-5.6 Sol Max 1,495 |
بقراءة الأرقام كما هي، يقع Kimi K3 في النطاق أسفل النماذج الحدّية العليا مباشرةً. واحتلاله المركز الثاني في AA-Briefcase، الذي يقيس العمل المعرفي طويل الأمد، إشارة إلى أنه صالح لمهام الوكلاء متعددة الخطوات مثل البرمجة. مع ذلك، هذه أرقام مُبلَّغ عنها، ويبقى الإحساس الفعلي في سير عمل برمجي حقيقيًا أدق عند التحقق منه على قاعدة شيفرتك الخاصة.
يمسّ هذا الاقتران عدستَي منتجَي 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. لا تتوقع استخدامًا مجانيًا غير محدود لنموذج من الطبقة العليا. ومع ذلك، فإن الحرية البنيوية في اختيار الأداة والنموذج بشكل مستقل موقع أفضل على المدى الطويل من الارتباط بمزوّد واحد.
npm install -g opencode-ai): الأوامر والإصدار قيم إعادة إنتاج مُلتقطة مباشرةًA large share of what you spend on AI does not go toward the model being clever. It goes toward the same decision repeated thousands or tens of thousands of times a day: “is this request safe?”, “which category does this document belong to?”, “is the tone of this sentence appropriate?” When you call a top-tier external model for that repetitive work every time, cost scales with volume and sensitive data leaves your walls on every call.
ThakiCloud’s proposition is simple: peel off only that repetitive work into small specialized models running on your own infrastructure (on-prem), and reserve the expensive top-tier model for the few tasks that truly require judgment. We verified that this actually works — by measurement, not prediction — and published the whole thing. This post frames that cost story in the language of decision-makers.
The moment you put generative AI into real operations, three things grow at once. Cost rises linearly with call volume. Data exposure happens every time you call an external API. And lock-in to a specific external model vendor deepens. All three are risks executives want to control.
Here is the key. When you break down what your AI actually does, most of it is narrow, repetitive adjudication, and genuine creative judgment is the minority. Yet today both are handed to the same top-tier model without distinction — like assigning simple document sorting to your highest-paid expert.
The method has three steps. First, design the workflow with a large model. Second, freeze whatever can be reduced to rules as code. Third, take only the narrow repetitive decisions that genuinely need a language model and train a small specialized model (under one billion parameters, 4-bit) for them. That work then runs on a single commodity on-prem GPU, and the top-tier model is spent only on what truly matters.
The ThakiCloud platform productizes exactly this workflow. It fine-tunes the small specialized model as a managed service (without you having to wrangle GPU infrastructure) and serves it on your own on-premises hardware. The experiment in this post is the evidence that the pattern works; the platform is what makes it repeatable and operable.
To avoid overstatement, we measured and published every number. The environment is a single GPU, with no external API calls at any stage of training or inference — the entire pipeline stays inside your own infrastructure. That is what data sovereignty looks like in practice.
Cost. On-prem, the small specialized model handled 1,000 calls at roughly 3.6× lower cost than a top-tier external API. That figure is single-stream; batching the way real operations do widens the gap further.
Quality. On narrow repetitive decisions, the small model leapt. Korean tone classification rose from 38.6% before training to 99.1% after; news categorization went from near-random to over 80%. When re-checked on real sentences never seen in training, it still agreed with the true answer at about 88% on safety decisions and 89% on categorization.
Economics. Each specialized model is produced as a small attachment of about 5 megabytes per task. Its quality nearly matches retraining the entire model from scratch (99.1% vs 96.9%) at roughly 1/300th the size, and you can swap multiple tasks onto one shared base model. A single small model even handled four repetitive tasks at once. Operationally, this translates directly into “more work on less hardware.”
One point we state plainly: on a general task the top-tier model already did well, hastily adding specialized training actually made it worse. In other words, this approach is not something you apply to any task, but to repetitive, narrow tasks chosen deliberately. Knowing where to apply it and where not to is exactly where a platform and expertise earn their keep. We publish the good results and the bad ones together.
First, a large share of your AI operating cost is leaking into repetitive work, and that part can be cut structurally. Second, the way to cut it is to peel that repetitive work off into small specialized models running on-prem, which secures cost savings and data sovereignty at the same time. Third, the ThakiCloud platform delivers this as a managed service, so you adopt it without personally shouldering the complexity of GPU infrastructure and model training.
The full experiment code and measured results are public and reproducible: github.com/sylvanus4/tiny-skill-distill. We are happy to assess, with you, which of your AI workloads to move onto specialized models and how much that would lower your cost.
]]>Moonshot AI released Kimi K3 on July 16, 2026. Per the company, it is a 2.8-trillion-parameter Mixture-of-Experts model and among the largest open-weight models released to date. The interesting part is not just the scores. This model is not confined to a proprietary chatbot; it connects as a provider to an open-source coding agent that runs in the terminal. In other words, “which IDE you use” and “which model you code with” can now be decoupled.
From ThakiCloud’s vantage point, this pairing matters for two reasons. First, a coding agent that can freely swap models instead of being vendor-locked lines up with the core premise of agent-platform design. Second, a 2.8-trillion-parameter open-weight model has to be served on real GPUs by someone, and that serving cost and on-prem requirement come straight back as infrastructure questions. Below we install the tool first-hand to confirm the connection flow, then work through both perspectives.
OpenCode is an open-source coding agent that runs in the terminal. It reads files in a codebase, explains structure, edits code, reviews changes, and runs tasks through a connected LLM provider. Because it is not bound to a single model and instead swaps providers, you can keep the same workflow and change only the model underneath.
Kimi K3 is the model that goes in that provider slot. Per Moonshot AI’s announcement, the key specs are as follows. It is a 2.8-trillion-parameter MoE, with 16 of 896 experts activated per token. Attention uses Kimi Delta Attention (KDA), a hybrid linear attention scheme. On top of that it adds Attention Residuals (a replacement for residual connections), native vision understanding, and up to a 1-million-token context window. Full model weights are scheduled to release on July 27, 2026.
The flow that connects the two tools looks like this.
flowchart TB
A[Developer terminal<br/>OpenCode TUI or run] --> B[Provider layer<br/>opencode auth login]
B --> C{Model selection<br/>/models or opencode models}
C --> D[Moonshot AI provider<br/>Kimi K3]
D --> E[Kimi Delta Attention<br/>2.8T MoE · 896 experts · 16 active per token]
E --> F[Read · edit · review · run code<br/>up to 1M context]
F -.session loop.-> A
The difference from the usual approach is clear. A vendor’s GUI agent ships the model and the tool as one bundle. An open-source agent like OpenCode fixes the tool and swaps only the provider. A self-hosted model yesterday, Kimi K3 today, a different model tomorrow, all through the same command interface.
We verified the install and connection flow first-hand in an isolated sandbox. The commands and versions below are actual values captured during reproduction.
First install OpenCode. A global npm install worked immediately.
npm install -g opencode-ai
opencode --version
# 1.18.3
We checked the command surface the installed CLI exposes. From launching the TUI to headless execution, provider management, model listing, and MCP server management, it covers what a coding agent needs.
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
Provider authentication is handled by the opencode auth subcommands.
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
The order for wiring in Kimi K3 is as follows, per Moonshot AI’s official OpenCode guide.
opencode auth login, select Moonshot AI as the provider, and enter your API key./models (or opencode models moonshotai in the shell) to select Kimi K3.opencode run "Explain this project's folder structure and recommend the first three files I should read."
One fact worth pinning down: right after install, the default model catalog did not include the
Moonshot provider. During reproduction, filtering opencode models for Moonshot/Kimi returned nothing,
which means the provider has to be added explicitly via auth login before it shows up in the catalog.
So step 2 above is not optional; it is required.
We separate values we captured directly from the model’s published figures. The tool install and connection flow are measured first-hand; the benchmark scores are reported figures from Moonshot and a third party (Artificial Analysis).
Directly measured results:
opencode-ai, exit code 0).auth), model listing (models), headless run (run),
MCP management (mcp), and agent management (agent).auth login.We did not run live Kimi K3 inference. Calling Kimi K3 requires a paid API key with balance (vouchers from new-user verification cannot be used for K3), and this reproduction environment did not have such a key. So we draw the line at “install and connection flow measured, actual code-generation quality cited from public figures.” We do not invent numbers we did not observe.
The model’s published benchmarks are below. These scores are reported figures per Artificial Analysis, and because weights are not yet fully public, they have not been verified by independent reproduction.
| Benchmark | Kimi K3 | Rank | Top / comparison models |
|---|---|---|---|
| GDPval-AA v2 | 1,687 | 3rd | Fable 5 Max 1,815 · GPT-5.6 Sol Max 1,747.8 · (Opus 4.8 1,600) |
| AA-Briefcase | 1,527 | 2nd | Fable 5 Max 1,587 · GPT-5.6 Sol Max 1,495 |
Read at face value, Kimi K3 sits in the band just below the top frontier models. Placing 2nd on AA-Briefcase, which is meant to measure long-horizon knowledge work, is a signal that it can hold up on multi-step agent tasks like coding. That said, these are reported figures, and the actual feel in a real coding workflow is best verified against your own codebase.
This pairing touches both of ThakiCloud’s product lenses. One is the agent-platform lens, the other is the infrastructure serving lens.
Paxis lens (agents, tools, swappable models). Paxis is ThakiCloud’s Agent-Native Cloud control
plane that treats Skills, Tools, Policies, and Audit Logs as first-class resources. The “fix the tool,
swap the provider” structure that OpenCode demonstrates overlaps exactly with the Paxis design
philosophy. In Paxis, a coding agent selects from 960-plus skills via BM25, runs them in isolated
sandboxes, and passes every action through policy gates and audit logs. Attach an open-weight model like
Kimi K3 as the provider, and you can swap the agent’s brain by cost and performance while keeping
execution isolation and auditing intact. The fact that OpenCode has built-in MCP server management
(opencode mcp) also connects naturally to how Paxis treats MCP connectors as first-class resources.
ai-platform lens (serving a 2.8T model). Open-weight means someone has to serve this model on real GPUs. A 2.8-trillion-parameter MoE only activates 16 experts per token, so active parameters are far smaller than the total, but the structure still requires holding all 896 experts in memory, so the bar for on-prem serving is not low. This is where ThakiCloud’s ai-platform answers the question. When K8s- and Kueue-based GPU scheduling, vLLM/SGLang serving, and quantization for memory savings come together, large open models like this can run economically in a multi-tenant environment. Once the weights ship on July 27, the cost curve of self-hosting versus API calls can be compared for real. Lower serving cost translates into agent economics, which in turn lowers the per-run cost of agents running on Paxis. Both lenses point in the same direction.
A few sober counterpoints are worth stating.
First, benchmark scores and actual coding feel are different. A 2nd place on AA-Briefcase does not guarantee “best on my codebase.” A top-ranked model can be weaker on a specific language, framework, or in-house convention, so adoption should be verified against your real work.
Second, this post’s measurements go up to install and connection flow. Live Kimi K3 inference was not run because of the paid API key constraint. Actual generation quality, latency, and token cost remain things you have to re-measure with your own key.
Third, “open weight” does not mean “free” or “easy to operate.” Even with weights public, serving a 2.8T MoE stably requires substantial GPU resources and operational skill. The break-even between self-hosting and API calls depends on usage and latency requirements.
Fourth, the Kimi K3 API needs balance, and new-user vouchers cannot be used for K3. Do not expect unlimited free use of a top-tier model. Even so, the structural freedom to choose tool and model independently is a stronger long-term position than being locked to a single vendor.
npm install -g opencode-ai): commands and version are directly captured reproduction values이 냉담함이 오늘의 진짜 뉴스입니다. 그리고 같은 주에 정반대 방향의 장면이 하나 더 겹쳤습니다.
구글은 순다르 피차이 CEO가 5월 개발자 행사에서 6월 출시를 직접 공언했던 제미나이 3.5 프로를 세 번 연기해 7월로 밀었습니다. 뉴스로드 보도에 따르면 기존 아키텍처를 폐기하고 처음부터 다시 설계하는 전면 재구축을 단행했고, 코딩 성능이 내부 목표치에 미달한 것이 핵심 원인으로 지목됐습니다. 지연 소식 이후 주가가 한때 4%가량 빠졌고, 최근 6일 사이 제미나이 핵심 연구원 네 명이 앤트로픽으로 자리를 옮겼습니다.
뉴스로드는 지연의 배경으로 기술 난이도만 지목하지 않았습니다. 구글 클라우드와 딥마인드, 안드로이드 등 여러 조직이 각자 별도의 AI 코딩 도구를 만들며 자원을 중복 투입하는 구조, 그리고 중요한 코드는 사람이 직접 작성해야 한다는 내부 엔지니어링 문화가 속도를 늦췄다는 지적입니다. 성능의 최전선에서조차 사람이 어디까지 개입하고 무엇을 자동화에 맡길지가 아직 정리되지 않았다는 뜻입니다.
한쪽에서는 신생 오픈웨이트 모델이 리더보드 정상을 찍었는데 시장은 지갑을 열지 않고, 다른 한쪽에서는 프런티어 선두조차 다음 버전을 세 번이나 미룹니다. 두 장면은 모순처럼 보이지만 같은 이야기를 합니다. 성능 곡선의 정점에서, 벤치마크 숫자와 실제 배포 사이의 간극이 그 어느 때보다 크게 벌어졌다는 이야기입니다.
능력 자체는 오히려 흔해지고 있습니다. 조선일보가 정리한 모델 가격표를 보면 경쟁 축은 이미 성능에서 가성비로 넘어갔습니다. 오픈AI GPT-5.6은 고성능 솔과 중저가 테라, 루나로 라인업을 쪼갰고, 메타 뮤즈 스파크는 출력 토큰 기준으로 앤스로픽 페이블 5의 약 12분의 1 가격을 부릅니다. 스페이스X의 그록 4.5는 코딩 평가에서 경쟁 모델보다 출력 토큰을 4배 넘게 적게 쓴다고 주장합니다. 키미 K3의 반값 API도 이 흐름의 한 갈래입니다.
가격이 바닥을 향하면 질문이 바뀝니다. “가장 똑똑한 모델이 무엇인가”에서 “이 능력을 우리 데이터와 업무에서 안전하게, 통제된 채, 감사 가능하게 돌릴 수 있는가”로 옮겨갑니다. 리더보드 1위가 안 팔리는 이유가 여기 있습니다. 기업이 결제하는 대상은 지능지표가 아니라 배포 가능성입니다. 벤치마크는 능력을 증명하지만 신뢰를 증명하지는 못합니다.
이 간극을 가장 정직하게 증언하는 쪽은 회의론자가 아니라 이미 도입한 사람들입니다. 도입 자체는 폭발하고 있습니다. 하나투어는 멀티 AI 에이전트 하이(H-AI)를 카카오톡 안의 챗GPT 창과 연동해 별도 앱 설치 없이 여행 추천을 받게 했고, 생성형 AI 검색 최적화를 적용한 뒤 챗GPT를 통한 유입량이 약 850% 늘었습니다. 익숙한 메신저 표면으로 AI가 파고드는 속도는 이렇게 가파른데, 정작 그 결과를 조직이 얼마나 믿고 맡길지는 별개의 곡선을 그립니다.
유통 대기업들은 AI 에이전트를 실제 업무에 깔기 시작했습니다. 롯데칠성음료는 생성형 AI와 OCR, RAG를 결합해 제품 라벨 검토 시간을 절반 이상 줄였고, 동원그룹은 계열사에 AI 사원을 도입해 하반기까지 약 50개를 추가할 계획입니다. 그런데 주간한국이 전한 이 확산 기사에서 딜로이트가 덧붙인 권고가 핵심입니다. 확산 초기 단계에서는 사람이 결과를 검증하고 승인하는 휴먼 인 더 루프 체계를 유지하라는 것입니다.
경영진을 AI로 대체하는 실험을 공개한 뤼튼 박민준 대표의 고백은 더 날카롭습니다. 역할별 AI가 토론해 의견을 내면 대표가 종합해 결정하는 구조를 돌려봤더니, 처음엔 편했지만 한 달 뒤부터는 AI 답변을 재확인하는 데 시간이 더 걸렸다고 했습니다. 그는 AI를 똑똑한 신입사원에 비유하며 회사 데이터와 조직 문화를 충분히 학습시켜야 제 역할을 한다고 강조했습니다.
같은 통증을 시장으로 바꾼 회사도 있습니다. 지란지교소프트가 과기정통부와 KISA의 우수 정보보호 기술로 지정받은 솔루션은 임직원이 챗GPT나 클로드에 무언가를 입력할 때 엔드포인트 단에서 실시간으로 검사해 개인정보와 기업 기밀이 새어 나가는 것을 막고, 프롬프트 입력 이력과 메일 발송 기록을 통합 감사합니다. 능력을 파는 것이 아니라 능력을 안전하게 쓰는 틀을 팝니다. 세 사례가 가리키는 방향은 똑같습니다. 모델이 똑똑해지는 것과 그 모델을 조직이 믿고 맡기는 것은 완전히 다른 문제입니다.
기업 단위에서 보이는 이 신호는 국가 단위로 올라가면 소버린 AI라는 이름을 답니다. 배경훈 부총리는 업무보고에서 앤트로픽 미토스급 프런티어 모델 개발에는 GPU 약 1만 장이 필요하다며 국가 주도 컴퓨팅 확충을 예고했고, 정부는 12월 전 국민 무료 서비스 모두의 AI를 내놓기로 했습니다. LG AI연구원 컨소시엄은 독자 파운데이션 모델 1차 평가에서 벤치마크와 전문가, 사용자 평가 전 부문 1위를 기록하며 행정안전부 서비스에 실증 적용됐습니다. 일본은 소니와 소프트뱅크, 혼다 등 44개사가 출자한 노에트라 컨소시엄이 엔비디아 루빈 GPU 약 2만7500장을 확보해 국가 AI 인프라를 짓습니다.
이 흐름을 단순한 국가주의로 읽으면 절반만 본 셈입니다. 국가들이 막대한 돈을 자국 모델과 자국 컴퓨팅에 쏟는 진짜 이유는, 능력이 흔해질수록 정작 희소해지는 자원이 통제된 실행이기 때문입니다. 누구의 인프라 위에서, 어떤 정책 아래, 무엇이 기록된 채 모델이 도는가. 국가가 소버린 AI라 부르는 값어치와 기업이 감사 로그와 휴먼 인 더 루프라 부르는 값어치는 규모만 다를 뿐 같은 것입니다.
능력이 흔해지는 이 국면에서 무한정 쌓아 올리기만 하던 자본도 표정을 바꾸고 있습니다. 글로벌이코노믹이 짚은 대로, AI 설비투자를 지탱해온 하이퍼스케일러들의 신규 채권이 발행가 대비 평균 3.3포인트 하락하며 우량 IT 채권으로서는 이례적인 약세를 보였습니다. 골드만삭스 같은 대형 금융기관은 이들의 기초체력이 튼튼해 채무불이행 위험은 없다며 조기 거품론을 반박했지만, 북미 클라우드 사업자의 설비투자 증가율이 올해 83%에서 내년 23% 수준으로 둔화할 것이라는 전망이 함께 나옵니다. 무작정 짓는 시대가 끝나가고 선별의 시대가 열린다는 신호입니다.
그 비용은 이미 다른 곳으로 번지고 있습니다. 디지털투데이에 따르면 세계 2위 스마트폰 시장인 인도의 2분기 출하량이 6년 만에 최대 폭인 10% 감소했는데, 하이퍼스케일러의 AI 인프라 투자가 D램과 낸드 공급을 잠식해 저가 스마트폰의 메모리 원가를 밀어 올린 것이 원인으로 지목됐습니다. 능력을 원자재처럼 쓰는 세계의 청구서가 인도의 210달러짜리 스마트폰 소비자에게까지 도착한 셈입니다. 능력을 더 쌓는 방향의 수익은 얇아지고, 능력을 더 잘 다루는 방향의 수익이 두꺼워지는 전환이 이렇게 여러 지표에서 동시에 나타납니다.
메타가 광고 대신 자사 컴퓨팅을 앤트로픽에 100억 달러 규모로 임대하려는 협상까지 겹쳐 보면 그림이 선명해집니다. 컴퓨팅은 상품이 되고, 모델은 반값으로 흔해지고, 리더보드 1위는 매주 바뀝니다. 이렇게 능력이 원자재가 되는 세계에서 값어치는 능력 위가 아니라 능력을 감싸는 실행 계층으로 옮겨갑니다. 어떤 모델을 고르느냐가 아니라 그 모델을 누구의 통제 아래 돌리느냐가 경쟁력이 됩니다.
ThakiCloud의 Paxis는 정확히 그 실행 계층을 제품으로 만든 Agent-Native Cloud입니다. 스킬과 툴, 정책, 감사 로그를 일급 리소스로 두어, 뤼튼 대표가 겪은 재확인의 피로와 딜로이트가 권고한 휴먼 인 더 루프를 L0에서 L3까지의 자율도 거버넌스로 설계합니다. 사람이 어디까지 손을 떼도 되는지를 감으로 정하지 않고 정책과 게이트로 정합니다. 지란지교소프트가 판 감사 기능은 Paxis에서 모든 에이전트 실행에 붙는 기본값이고, 정책 게이트와 격리 샌드박스는 반값 오픈웨이트 모델을 도입하면서도 기밀이 새지 않게 막는 틀이 됩니다. 가성비로 넘어간 모델 경쟁은 작업마다 다른 모델을 붙이는 CostRouter로 흡수하고, 소버린 AI가 부르는 주권의 요구는 온프렘 쿠버네티스 기반 ai-platform이 받습니다.
리더보드 1위가 안 팔리는 이유를 다시 뒤집으면 답이 됩니다. 기업이 사는 것은 정점의 점수가 아니라 통제된 실행입니다. 벤치마크가 사주지 못하는 그 신뢰를, 실행 계층이 대신 만듭니다.
이 글은 아래 뉴스를 종합해 작성했습니다.
AI 도입 비용의 상당 부분은 모델이 똑똑한 판단을 하기 때문에 발생하는 것이 아닙니다. 같은 판정을 하루에 수천, 수만 번 반복하는 단순 작업에서 발생합니다. “이 요청이 안전한가”, “이 문서는 어느 범주인가”, “이 문장의 어투는 적절한가”와 같은 판정입니다. 이 반복 작업에까지 매번 최상위 외부 모델을 호출하면, 비용은 호출량에 비례해 늘어나고 민감한 데이터는 매번 외부로 나가게 됩니다.
타키클라우드의 제안은 단순합니다. 이 반복 작업만 작은 전용 모델로 떼어내 고객사의 자체 인프라, 곧 온프레미스에서 운영하고, 값비싼 최상위 모델은 정말 판단이 필요한 소수의 업무에만 사용하는 것입니다. 저희는 이 방식이 실제로 통하는지를 예측이 아니라 측정으로 확인했으며, 그 과정을 전부 공개했습니다. 이 글은 그 비용 이야기를 의사결정권자의 관점에서 정리한 것입니다.
생성형 AI를 실무에 도입하기 시작하면 세 가지가 동시에 커집니다. 비용은 호출량을 따라 선형으로 늘어나고, 데이터 노출은 외부 API를 호출할 때마다 발생하며, 특정 외부 모델 공급자에 대한 종속성은 점점 깊어집니다. 세 가지 모두 경영진이 통제하고자 하는 리스크입니다.
핵심은 다음과 같습니다. 여러분의 AI가 수행하는 일을 살펴보면 대부분은 좁고 반복적인 판정이며, 진짜 창의적 판단은 소수입니다. 그런데 현재는 이 둘을 구분하지 않고 전부 같은 최상위 모델에 맡기고 있습니다. 단순한 서류 분류까지 가장 높은 연봉의 전문가에게 맡기는 것과 다르지 않습니다.
방법은 세 단계입니다. 첫째, 업무 흐름은 최상위 모델로 설계합니다. 둘째, 규칙으로 굳힐 수 있는 부분은 코드로 고정합니다. 셋째, 언어모델이 실제로 필요한 좁은 반복 판정만 작은 모델(파라미터 10억 개 이하, 4비트)로 특화 학습하여 연결합니다. 그러면 그 작업은 흔한 온프레미스 GPU 한 장에서 처리되고, 최상위 모델은 정말 중요한 판단에만 투입됩니다.
타키클라우드 플랫폼은 바로 이 워크플로를 제품으로 제공합니다. 작은 전용 모델을 관리형으로 파인튜닝하고(고객사가 GPU 인프라를 직접 다룰 필요가 없습니다), 그 결과를 고객사의 온프레미스 환경에서 서빙합니다. 이 글의 실험은 그 패턴이 작동한다는 증거이며, 플랫폼은 그 패턴을 반복 가능하고 운영 가능한 형태로 만들어 드립니다.
과장을 피하기 위해 모든 수치를 직접 측정하고 공개했습니다. 실험 환경은 GPU 한 장이며, 학습과 추론 어느 단계에서도 외부 API를 호출하지 않았습니다. 즉 전 과정이 자체 인프라 안에서 완결됩니다. 이것이 데이터 주권의 실체입니다.
비용 측면입니다. 온프레미스에서 이 작은 전용 모델이 처리하는 1천 건당 비용은 최상위 외부 API 대비 약 3.6배 저렴했습니다. 이 수치는 단일 처리 기준이므로, 실제 운영처럼 묶어서 처리하면 격차는 더 벌어집니다.
품질 측면입니다. 좁은 반복 판정에서 작은 모델은 크게 향상되었습니다. 예를 들어 한국어 어투 판정은 학습 전 38.6퍼센트에서 학습 후 99.1퍼센트로, 뉴스 범주 분류는 거의 무작위 수준에서 80퍼센트 이상으로 올랐습니다. 학습에 사용하지 않은 실제 문장으로 다시 검증했을 때에도 안전 판정에서 88퍼센트, 범주 분류에서 89퍼센트 수준의 일치도를 보였습니다.
경제성 측면입니다. 이 전용 모델은 각 작업마다 약 5메가바이트의 작은 부착 파일로 만들어집니다. 전체 모델을 통째로 다시 학습하는 방식과 품질은 거의 같으면서(99.1퍼센트 대 96.9퍼센트) 크기는 약 300분의 1이며, 하나의 기본 모델 위에 여러 작업을 바꿔 끼울 수 있습니다. 하나의 작은 모델이 네 가지 반복 작업을 동시에 감당하기도 했습니다. 운영 관점에서 이는 적은 하드웨어로 더 많은 업무를 처리한다는 뜻으로 직결됩니다.
한 가지는 분명히 말씀드립니다. 최상위 모델이 이미 잘 처리하던 일반적인 작업에 성급하게 전용 학습을 적용했더니 오히려 성능이 떨어진 경우가 있었습니다. 즉 이 방식은 아무 작업에나 적용하는 것이 아니라, 반복적이고 좁은 작업을 선별하여 적용해야 효과가 납니다. 어디에 적용하고 어디에는 적용하지 않아야 하는지를 판단하는 일, 바로 그 지점에서 플랫폼과 전문성이 필요합니다. 저희는 좋은 결과와 좋지 않은 결과를 함께 공개합니다.
첫째, AI 운영비의 상당 부분은 반복 작업에서 새어나가고 있으며, 이 부분은 구조적으로 줄일 수 있습니다. 둘째, 그 방법은 반복 작업을 작은 전용 모델로 떼어내 온프레미스에서 운영하는 것이며, 이는 비용 절감과 데이터 주권을 동시에 확보해 줍니다. 셋째, 타키클라우드 플랫폼은 이 과정을 관리형으로 제공하여, 고객사가 GPU 인프라와 모델 학습의 복잡성을 직접 떠안지 않고도 도입하실 수 있게 합니다.
전체 실험 코드와 측정 결과는 누구나 재현할 수 있도록 공개해 두었습니다: github.com/sylvanus4/tiny-skill-distill. 여러분의 AI 워크로드 가운데 어느 부분을 전용 모델로 옮기면 비용이 얼마나 내려갈지, 저희가 함께 진단해 드리겠습니다.
]]>Moonshot AI는 2026년 7월 16일 Kimi K3를 공개했습니다. 회사 발표 기준으로 총 2.8조 파라미터의 Mixture-of-Experts 모델이며, 지금까지 나온 오픈 웨이트 모델 중 가장 큰 축에 듭니다. 흥미로운 점은 성능 지표만이 아닙니다. 이 모델은 프로프라이어터리 챗봇 안에만 갇혀 있지 않고, 터미널에서 도는 오픈소스 코딩 에이전트에 프로바이더로 연결됩니다. 즉 “어떤 IDE를 쓰느냐”와 “어떤 모델로 코딩하느냐”를 분리할 수 있게 됐습니다.
ThakiCloud 관점에서 이 조합은 두 가지 이유로 눈여겨볼 만합니다. 첫째, 코딩 에이전트가 벤더 종속을 벗어나 모델을 자유롭게 교체할 수 있다는 것은 에이전트 플랫폼 설계의 핵심 전제와 맞닿아 있습니다. 둘째, 2.8조 파라미터 오픈 웨이트 모델은 결국 누군가가 실제 GPU 위에서 서빙해야 하며, 그 서빙 비용과 온프렘 요구가 곧 인프라 사업의 질문으로 돌아옵니다. 이 글에서는 먼저 도구를 직접 설치해 연결 흐름을 확인하고, 그다음 이 두 관점을 정리합니다.
OpenCode는 터미널에서 도는 오픈소스 코딩 에이전트입니다. 코드베이스의 파일을 읽고, 구조를 설명하고, 코드를 편집하고, 변경을 리뷰하고, 연결된 LLM 프로바이더를 통해 작업을 실행합니다. 특정 모델에 묶이지 않고 프로바이더를 갈아 끼우는 구조라, 같은 워크플로 위에서 모델만 바꿔 가며 쓸 수 있습니다.
Kimi K3는 그 프로바이더 자리에 들어가는 모델입니다. Moonshot AI 발표 기준 핵심 사양은 다음과 같습니다. 총 2.8조 파라미터의 MoE 구조로, 896개의 전문가(expert) 중 토큰당 16개가 활성화됩니다. 어텐션은 Kimi Delta Attention(KDA)이라는 하이브리드 선형 어텐션 방식을 씁니다. 여기에 잔차 연결을 대체하는 Attention Residuals 기법, 네이티브 비전 이해, 그리고 최대 100만 토큰 컨텍스트를 갖췄습니다. 전체 모델 가중치는 2026년 7월 27일 공개 예정입니다.
두 도구가 연결되는 흐름을 그림으로 보면 다음과 같습니다.
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
기존 접근과의 차이는 명확합니다. 벤더가 제공하는 GUI 에이전트를 쓰면 모델과 도구가 한 묶음으로 딸려 옵니다. 반면 OpenCode 같은 오픈소스 에이전트는 도구를 고정한 채 프로바이더만 교체합니다. 어제는 자체 호스팅 모델, 오늘은 Kimi K3, 내일은 또 다른 모델을 같은 명령 인터페이스로 쓸 수 있습니다.
실제 설치와 연결 흐름을 격리된 샌드박스에서 직접 확인했습니다. 아래 명령과 버전은 재현 과정에서 캡처한 실제 값입니다.
먼저 OpenCode를 설치합니다. npm 전역 설치로 바로 잡혔습니다.
npm install -g opencode-ai
opencode --version
# 1.18.3
설치된 CLI가 제공하는 명령 표면을 확인했습니다. 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를 붙이는 순서는 다음과 같습니다. Moonshot AI 공식 OpenCode 가이드 기준입니다.
opencode auth login을 실행하고 프로바이더로 Moonshot AI를 선택한 뒤 API 키를 입력합니다./models(또는 셸에서 opencode models moonshotai)로 Kimi K3를 선택합니다.opencode run "이 프로젝트의 폴더 구조를 설명하고 먼저 읽어야 할 파일 세 개를 추천해 줘."
한 가지 확인해 둘 사실이 있습니다. 설치 직후 기본 모델 카탈로그에는 Moonshot 프로바이더가 잡혀
있지 않았습니다. 재현 중 opencode models를 Moonshot/Kimi로 필터링하면 결과가 비어 있었고, 이는
프로바이더를 auth login으로 명시적으로 추가해야 카탈로그에 노출된다는 뜻입니다. 즉 위 2번 단계는
선택이 아니라 필수입니다.
이번 재현에서 직접 캡처한 값과, 모델 자체의 공개 지표를 구분해 정리합니다. 도구 설치와 연결 흐름은 직접 확인한 실측값이고, 벤치마크 점수는 Moonshot과 제3자(Artificial Analysis)가 공개한 보고값입니다.
직접 확인한 실측 결과는 다음과 같습니다.
opencode-ai, 종료 코드 0).auth), 모델 조회(models), 헤드리스 실행(run), MCP 관리(mcp),
에이전트 관리(agent)를 모두 제공함을 확인.auth login으로 명시 추가 필요.라이브 Kimi K3 추론까지는 실행하지 않았습니다. Kimi K3 호출에는 잔액이 있는 유료 API 키가 필요하고 (신규 가입 검증으로 받은 바우처는 K3에 사용할 수 없습니다), 이번 재현 환경에는 해당 키가 없었습니다. 그래서 “설치와 연결 흐름은 실측, 실제 코드 생성 품질은 공개 지표 인용”으로 선을 긋습니다. 없는 수치를 지어내지 않습니다.
모델의 공개 벤치마크는 다음과 같습니다. 아래 점수는 Artificial Analysis가 공개한 보고값 기준이며, 가중치가 아직 완전 공개되지 않아 독립 재현으로는 검증되지 않았음을 함께 밝힙니다.
| 벤치마크 | Kimi K3 | 순위 | 상위/비교 모델 |
|---|---|---|---|
| GDPval-AA v2 | 1,687 | 3위 | Fable 5 Max 1,815 · GPT-5.6 Sol Max 1,747.8 · (Opus 4.8 1,600) |
| AA-Briefcase | 1,527 | 2위 | Fable 5 Max 1,587 · GPT-5.6 Sol Max 1,495 |
숫자를 그대로 읽으면, Kimi K3는 최상위 프런티어 모델 바로 아래 구간에 자리합니다. 특히 장기 지식 노동을 측정한다는 AA-Briefcase에서 2위를 기록했다는 점은, 코딩처럼 여러 단계를 오가는 에이전트 작업에서 쓸 만하다는 신호로 해석할 수 있습니다. 다만 이는 보고값이며, 실제 코딩 워크플로에서의 체감은 각자의 코드베이스로 검증하는 편이 정확합니다.
이 조합은 ThakiCloud의 두 제품 렌즈 모두와 맞닿습니다. 하나는 에이전트 플랫폼 관점, 다른 하나는 인프라 서빙 관점입니다.
Paxis 렌즈(에이전트·도구·모델 교체). Paxis는 ThakiCloud의 Agent-Native Cloud 제어 평면으로,
Skills·Tools·Policies·Audit Logs를 일급 리소스로 다룹니다. OpenCode가 보여 주는 “도구는 고정하고
프로바이더만 교체한다”는 구조는 Paxis의 설계 철학과 정확히 겹칩니다. Paxis에서 코딩 에이전트는
960개가 넘는 스킬을 BM25로 선택해 격리된 샌드박스에서 실행하고, 모든 행동을 정책 게이트와 감사
로그로 통과시킵니다. 여기에 Kimi K3 같은 오픈 웨이트 모델을 프로바이더로 붙이면, 에이전트의 두뇌를
비용과 성능에 따라 갈아 끼우면서도 실행 격리와 감사 체계는 그대로 유지할 수 있습니다. 또한 OpenCode가
MCP 서버 관리(opencode mcp)를 내장하고 있다는 점은, MCP 커넥터를 일급 리소스로 다루는 Paxis의
접근과 자연스럽게 연결됩니다.
ai-platform 렌즈(2.8T 모델 서빙). 오픈 웨이트라는 말은 결국 누군가가 이 모델을 실제 GPU 위에서 서빙해야 한다는 뜻입니다. 2.8조 파라미터 MoE는 토큰당 16개 전문가만 활성화되므로 활성 파라미터는 전체보다 훨씬 작지만, 896개 전문가 전체를 메모리에 올려야 하는 구조라 온프렘 서빙의 문턱은 낮지 않습니다. 여기서 ThakiCloud의 ai-platform이 답하는 질문이 등장합니다. K8s와 Kueue 기반 GPU 스케줄링, vLLM/SGLang 서빙, 그리고 양자화를 통한 메모리 절감이 결합될 때 이런 대형 오픈 모델을 멀티테넌트 환경에서 경제적으로 돌릴 수 있습니다. 가중치가 7월 27일 공개되면, 자체 호스팅 대비 API 호출의 비용 곡선을 실제로 비교해 볼 수 있습니다. 낮은 서빙 비용은 곧 에이전트 경제성으로 이어지고, 이는 다시 Paxis 위에서 도는 에이전트의 단가를 낮춥니다. 두 렌즈가 한 방향을 가리키는 셈입니다.
몇 가지 냉정한 반론을 함께 적습니다.
첫째, 벤치마크 점수와 실제 코딩 체감은 다릅니다. AA-Briefcase 2위가 곧 “내 코드베이스에서 최고”를 보장하지 않습니다. 리더보드 상위 모델이 특정 언어나 프레임워크, 사내 컨벤션에서 오히려 약할 수 있으므로, 도입 판단은 자신의 실제 작업으로 검증해야 합니다.
둘째, 이 글의 실측은 도구 설치와 연결 흐름까지입니다. 라이브 Kimi K3 추론은 유료 API 키 제약으로 실행하지 못했습니다. 실제 생성 품질, 지연 시간, 토큰 비용은 각자의 키로 직접 재 봐야 하는 영역으로 남습니다.
셋째, “오픈 웨이트”가 곧 “공짜”나 “쉬운 운영”을 의미하지는 않습니다. 가중치가 공개돼도 2.8T MoE를 안정적으로 서빙하려면 상당한 GPU 자원과 운영 역량이 필요합니다. 자체 호스팅과 API 호출 사이의 손익분기는 사용량과 지연 요구에 따라 갈립니다.
넷째, Kimi K3 API에는 잔액이 필요하며 신규 바우처로는 K3를 쓸 수 없습니다. 무료로 최상위 모델을 무제한 쓴다는 기대는 접어야 합니다. 그럼에도 도구와 모델을 분리해 선택할 수 있다는 구조적 자유는, 특정 벤더에 묶이는 것보다 장기적으로 유리한 위치입니다.
npm install -g opencode-ai): 본문 명령과 버전은 직접 재현 캡처값هناك سؤال يتجاهله الناس عند اختيار أداة مراجعة الكود: كم من المراجعة يحتاجها هذا التغيير فعلًا؟ إن تشغيل الشدة نفسها من المراجعة على تصحيح خطأ مطبعي من سطر واحد وعلى إعادة كتابة منطق الدفع يكون إما هدرًا أو نقصًا. معظم أدوات المراجعة الآلية لا تترك هذا الخيار للمستخدم وتعمل بشدة ثابتة واحدة.
عالج Claude Code هذا الأمر مباشرة في الإصدار v2.1.101. ففي إصدار 11 أبريل 2026 أعاد تسمية الأمر /simplify إلى /code-review وأضاف علامة مستوى الجهد التي تحكم مدى عمق تفكير النموذج قبل الإجابة. هناك خمسة مستويات، هي low وmedium وhigh وmax وultra، وتُعاد كتابة المراجعة نفسها عند كل مستوى. تُرجع المستويات الضحلة نتائج سريعة عالية الثقة، بينما تنفق المستويات العميقة وقتًا أطول وتمسح الحالات الطرفية والانحدارات الدقيقة.
يقرأ هذا المقال ذلك التصميم من منظور ThakiCloud التي تُشغّل وكلاء برمجة بالذكاء الاصطناعي. ننظر في سبب كون مستوى الجهد هو المحور الصحيح لفصل التكلفة عن الجودة في مراجعة الكود، ومتى نختار كل مستوى عمليًا، وكيف تتداخل الفكرة مع حزمة المهارات وحلقة التحقق في Paxis، منصتنا للوكلاء. المُدد والتكاليف المذكورة أدناه كلها قيم مُبلَّغ عنها من وثائق Anthropic العامة وملاحظات الإصدار، وليست أرقامًا قاسها ThakiCloud.
/code-review أمر خط مائل يقرأ الفرق (diff) في شجرة العمل الحالية، ويجد المشكلات ويُبلّغ عنها. التغيير الجوهري أنه بإمكانك إلحاق مستوى بالأمر. تحديد مستوى مثل /code-review low يجعل محرك المراجعة يضبط نطاق استكشافه وعمق تفكيره ليطابق ذلك المستوى. حذف المستوى يشغّل القيمة الافتراضية.
المهم أن المستوى ليس مجرد «إطالة المخرجات أو تقصيرها». وفقًا للوثائق، يعيد low وmedium مجموعة صغيرة من النتائج عالية الثقة، بينما يعيد high وmax نتائج غير مؤكدة إلى جانب النتائج الواثقة. بعبارة أخرى، تفضّل المستويات الضحلة الدقة (precision) وتفضّل المستويات العميقة الاستدعاء (recall)؛ فطبيعة المراجعة نفسها تتغير. وهذا يوافق أيضًا نفسية من يتلقى المراجعة. في رقعة صغيرة، حفنة من النتائج المؤكدة أفضل من قائمة طويلة محشوة بالإيجابيات الكاذبة؛ وقبيل الدمج، عدم تفويت أي شيء أفضل.
flowchart TB
A[تغيير الكود<br/>فرق شجرة العمل] --> B{اختيار مستوى الجهد}
B -->|low / medium| C[الدقة أولًا<br/>نتائج قليلة عالية الثقة]
B -->|high / max| D[الاستدعاء أولًا<br/>يشمل نتائج غير مؤكدة]
B -->|ultra| E[صندوق رملي سحابي<br/>مراجعة وكلاء متوازية]
C --> F[استجابة بمقياس الثواني<br/>رقعة صغيرة، تغيير إعداد]
D --> G[استكشاف بمقياس الدقائق<br/>قبيل الدمج، حالة معقدة]
E --> H[التحقق من كل نتيجة مستقلًا<br/>5-10 دقائق، طبقة مدفوعة]
F --> I[--comment: تعليق داخل PR]
G --> I
H --> I
I --> J[--fix: التطبيق على شجرة العمل]
اختيار المستوى مسألة موازنة بين خطورة التغيير والوقت المتبقي لديك. ترجمةً للطبيعة التي تصفها الوثائق إلى حدس عملي:
يُستخدم low وmedium للفحص السريع للسلامة. استخدمهما قبل دفع تعديل إعداد أو رقعة صغيرة حين تريد فقط تصفية أخطاء الصحة الواضحة. تعود الاستجابات خلال ثوانٍ، فيمكنك تشغيلهما بشكل معتاد قبيل الالتزام دون أن يقطع ذلك انسيابك.
يُستخدم high وmax لمسارات الكود قبيل الدمج أو التي تحمل حالة معقدة. دمج فرع ميزة في main، أو ملامسة مناطق مثل التزامن والمعاملات حيث تختبئ الانحدارات الدقيقة، يقع هنا. تنفق هذه المستويات وقتًا أطول في التحقق من الافتراضات ونبش الحالات الطرفية، فتظهر نتائج موسومة بـ«قد لا تكون مشكلة لكن تحقّق منها» إلى جانب النتائج المؤكدة. سواء عاملت ذلك اللايقين كضجيج أم كشبكة أمان يعتمد على الموقف. قبيل الدمج، تكون شبكة الأمان القراءة الصحيحة.
أما ultra فأداة من نوع مختلف. نتناوله على حدة أدناه.
إذا ضغطت هذا السُّلَّم في جملة واحدة، فهو يقول: طابِق شدة المراجعة مع خطورة التغيير. وهذا بالضبط المبدأ الذي نتبعه عند تشغيل المهارات المجدولة. ابدأ رخيصًا، وارفع فقط المهمة الفاشلة إلى طبقة أغلى. تشغيل كل مراجعة بأقصى شدة يهدر التكلفة، وتشغيل كل مراجعة بأدنى شدة يزرع بذرة حادثة.
بمعزل عن مستويات الجهد، تدمج علامتان المراجعة في سير عمل فعلي. تنشر --comment النتائج كتعليقات مضمّنة على الـPR، وتطبّق --fix النتائج مباشرة على شجرة العمل.
# مراجعة واسعة قبل الدمج مع تعليقات PR إضافةً إلى التطبيق المحلي
/code-review high --comment --fix
# مراجعة سحابية عميقة، ثم تطبيق النتائج على شجرة العمل
/code-review ultra --fix
سير عمل المطوّر الفردي الذي تعرضه الوثائق يجري هكذا. اجمع --comment --fix لترك النتائج على الـPR وتطبيقها محليًا، ثم عايِن الفرق وادفع. إنها طريقة لتمرير أول تمريرة مراجعة تلقائيًا دون انتظار مراجِع. مع ذلك، لأن --fix تلامس الكود، يجب على إنسان مراجعة الفرق المُطبَّق. التطبيق التلقائي ليس بديلًا عن المراجعة؛ بل هو تحضير لها.
مستوى ultra مختلف عن المستويات الأربعة التي تعمل محليًا. تشغيل /code-review ultra يحزم حالة مستودعك، ويرفعها إلى صندوق رملي بعيد، ويترك وكلاء مراجعة متخصصين يحللون الكود بالتوازي هناك. يركّز كل وكيل على صنف مختلف من المشكلات، ويُتحقَّق من النتائج مستقلةً واحدةً تلو الأخرى. وفقًا للوثائق، يستغرق التشغيل من خمس إلى عشر دقائق، وبعد ثلاث تشغيلات مجانية لمشتركي Pro وMax، يكلّف كل تشغيل من خمسة إلى عشرين دولارًا.
يبرز هنا قراران تصميميان. أولًا، تُعالَج المراجعة كتوزّع (fan-out) لعدة وكلاء متخصصين بدل وكيل واحد. وبما أن مراجِعًا واحدًا يصعب عليه التقاط كل صنف من العيوب بالكفاءة نفسها، فإن تقسيم المنظورات حسب نوع المشكلة يوسّع التغطية. ثانيًا، يُتحقَّق من كل نتيجة مستقلةً. التوزّع بذاته يخاطر بتراكم الهلوسات، فلا بد من إغلاقه بمرحلة تحقق قبل الدمج. يُطبّق ultra كلا المبدأين كميزة منتج.
تتداخل مبادئ تصميم هذه الميزة بشكل لافت مع ما مارسناه في تشغيل منصة وكلاء. نقسّمه على منتجَينا.
عدسة Paxis. إن Paxis هي السحابة الأصيلة للوكلاء (Agent-Native Cloud) من ThakiCloud، وتتعامل مع المهارات (Skills) والأدوات (Tools) والسياسات (Policies) وسجلات التدقيق (Audit Logs) كموارد من الدرجة الأولى. السؤال الذي يطرحه /code-review هو نفسه الذي تحلّه حزمة مهارات Paxis كل يوم: أي شدة وكيل تُلحقها بأي مهمة؟ تختار Paxis من أكثر من 960 مهارة عبر BM25 وتشغّلها في صناديق رملية معزولة، وتعمل الفكرة نفسها المتمثلة في مستويات الجهد هنا. يذهب العمل الخفيف مثل الاستكشاف والبحث إلى طبقة رخيصة؛ ويذهب العمل الثقيل مثل الحكم المعماري والتحقق إلى طبقة أغلى. تتشارك مراجعة ultra المتوازية متعددة الوكلاء والتحقق المستقل لكل نتيجة البنية نفسها مع طريقة إغلاق Paxis لنتائج التوزّع بمرحلة تحقق. توزّع بلا تحقق يراكم الهلوسات، وبوابة تحقق توقفه. إذا جرت مراجعة الكود كمهارة وكيل معزولة تمرّ نتائجها عبر بوابات السياسة وسجلات التدقيق، فتلك بالضبط نموذج التشغيل الذي تهدف إليه Paxis.
عدسة ai-platform. إن كون ultra يحمّل المراجعة إلى صندوق رملي سحابي ويحاسب لكل تشغيل يؤكد مجددًا أن أعباء عمل الوكلاء تعمل في النهاية على بنية تحتية للـGPU والتنفيذ المعزول. توفّر منصة ai-platform من ThakiCloud جدولة GPU قائمة على K8s وKueue، وعزلًا متعدد المستأجرين، وخدمة داخل المؤسسة (on-premises). إن عبء عمل يشغّل أسطولًا من وكلاء المراجعة بالتوازي هو بالضبط نوع العمل الذي تستهدفه هذه البنية. وللمؤسسات المتحفظة على رفع الشيفرة المصدرية إلى سحابة خارجية خصوصًا، يصبح خيار تشغيل نمط المراجعة نفسه متعدد الوكلاء داخل بنيتها التحتية مهمًا. ولأن اقتصاديات الوكلاء لا تصح إلا حين تتوفّر خدمة منخفضة التكلفة وتنفيذ معزول، تُكمّل العدستان إحداهما الأخرى.
مستويات الجهد ليست دواءً لكل داء. بعض الاعتراضات الصادقة.
أولًا، اختيار المستوى نفسه يعتمد على حكم المستخدم. سوء قراءة الخطورة يمرّر تغييرًا مهمًا بمستوى low، أو يهدر ultra على تغيير تافه. توفّر الأداة المحور؛ أما تحديد موقعك الصحيح عليه فيبقى من شأن الإنسان.
ثانيًا، النتائج غير المؤكدة التي ينتجها high وmax سلاح ذو حدين. قد تعمل كشبكة أمان، لكن إن تراكمت الإيجابيات الكاذبة سبّبت إرهاق المراجعة وانتهى بك الأمر إلى تجاهل القائمة. مقدار الثقة في نتيجة غير مُتحقَّق منها يعتمد على انضباط الفريق.
ثالثًا، يرفع ultra المستودع إلى صندوق رملي بعيد. وللمؤسسات ذات المصدر الحساس، يشكّل ذلك وحده عائق تبنٍّ. كما أن تكلفة الخمسة إلى العشرين دولارًا لكل تشغيل ثقيلة للتشغيل المتكرر، فعلى الفريق أن يحسب اقتصادياته الخاصة بعد التشغيلات المجانية الثلاث.
رابعًا، لا يحلّ --fix التلقائي محل المراجعة. الدفع دون فحص الفرق المُطبَّق يدع الأتمتة التي تبدو مريحة تدسّ أخطاءً صامتة بدلًا من ذلك. الأتمتة أداة تساعد التفكير، لا أداة تحلّ محله.
مع ذلك، تشير فكرة مستويات الجهد إلى الاتجاه الصحيح. مطابقة شدة المراجعة مع خطورة التغيير هي بالضبط توازن التكلفة والجودة الذي تعلّمناه من تشغيل الوكلاء.
أول جدار يصطدم به أي فريق عند خدمة نموذج كبير على بنيته التحتية الخاصة ليس الحوسبة بل الذاكرة. يتطلّب تحميل نموذج بحجم 295B بدقة FP16 نحو 598GB من الأوزان مقيمة في ذاكرة وحدة المعالجة الرسومية، وهو حجم يكاد لا يتّسع إلا عبر ثماني بطاقات H100 بسعة 80GB. لهذا ظلّت النماذج الرائدة مفتوحة الأوزان في موضع محرج: مُعلنة، لكن يصعب علينا خدمتها فعلياً.
تستهدف نسخ Hy3 بصيغة GGUF بدقة 1-bit و4-bit التي أصدرتها Tencent Hunyuan في 14 يوليو 2026 هذه النقطة مباشرةً. فهي تضغط نموذج MoE بحجم 295B إلى صيغة منخفضة البتّات ليعمل على بطاقة واحدة، وتُنشر الأوزان برخصة Apache 2.0. عرّفت Tencent النموذج على منصة X بأنه «نموذج بحجم رائد 295B يمكن خدمته على وحدة معالجة رسومية واحدة»، مع ذكر llama.cpp وMTP معاً.
تقرأ هذه المقالة نسخ Hy3 المكمّمة من منظور ThakiCloud بوصفنا فريقاً يخدم نماذج منخفضة البتّات في بيئة متعددة المستأجرين. نستعرض ما تغيّره الضغطة فعلياً، ولماذا يجب قراءة عبارة «وحدة واحدة» بحذر، وماذا يعني هذا الاتجاه لبنية الاستدلال المحلية لدينا. ولنكن واضحين منذ البداية: كل أرقام الحجم والأداء أدناه قيَم أبلغت عنها Tencent والمجتمع، وليست أرقاماً أعادت ThakiCloud إنتاجها.
Hy3 نموذج Mixture-of-Experts بإجمالي 295B معامل، لكن ما يُفعَّل لمعالجة رمز واحد نحو 21B فقط. يدعم سياقاً طويلاً بحجم 256K رمز، ويستهدف المهام الوكيلة والبرمجة واستدعاء الأدوات. الجديد هنا ليس نموذجاً جديداً بل تمثيلاً منخفض البتّات بصيغة GGUF لأوزان Hy3 القائمة. صدرت نسختان.
تُقلّص نسخة 1-bit النموذج من نحو 598GB إلى 85.5GiB. بهذا الحجم تتّسع الأوزان على بطاقة واحدة من فئة 96GB. تشغل نسخة 4-bit مساحة 169.9GiB وتحتاج إلى الامتداد عبر بطاقتين، لكنها بالمقابل تحافظ على جودة أقرب بكثير إلى الأصل وفق ما أُبلغ. تعمل النسختان مع llama.cpp، وصُمِّمتا لتفعيل MTP (التنبؤ متعدد الرموز) لرفع إنتاجية توليد الرموز.
flowchart TB
A[Hy3 295B MoE<br/>FP16 نحو 598GB] --> B{تكميم GGUF منخفض البتّات}
B -->|1-bit| C[85.5GiB<br/>بطاقة 96GB واحدة]
B -->|4-bit| D[169.9GiB<br/>بطاقتان]
C --> E[التشغيل عبر llama.cpp]
D --> E
E --> F[تفعيل MTP<br/>تنبؤ متعدد الرموز لزيادة الإنتاجية]
F --> G[21B معامل مُفعَّل<br/>بعض الخبراء فقط يحسبون لكل رمز]
G --> H[مهام وكيلة وبرمجة واستدعاء أدوات<br/>سياق طويل 256K]
بنية MoE هي ما يجعل هذه الضغطة جذّابة بوجه خاص. فمن أصل 295B، لا يشارك في الحساب لكل رمز سوى خبراء بحجم 21B، لذا فالحوسبة نفسها في حدود نموذج كثيف بحجم 21B. يكمن عنق الزجاجة كلياً في «أين تُقيم كل أوزان الخبراء». والضغط منخفض البتّات يهاجم تحديداً تكلفة الإقامة تلك.
هذه أسهل عبارة يُساء فهمها في التسويق. «الخدمة على وحدة واحدة» صحيحة، لكن المقصود بالوحدة هنا جهاز بذاكرة موحّدة من فئة 128GB. فكّر في DGX Spark، أو Mac Studio بسعة 128GB، أو Strix Halo. إن تخيّلت بطاقة RTX 3060 واحدة بسعة 16GB، فهذا التوقع بعيد.
يهمّ هذا التمييز لأن الحساب العملي يتغيّر كلياً. يتطلّب تحميل 85.5GiB من الأوزان بطاقة سعتها 96GB على الأقل، وبمجرد إضافة ذاكرة KV cache وذاكرة التنشيط وحالة الانتباه لسياق طويل، يتقلّص الهامش الفعلي أكثر. حتى على جهاز من فئة 128GB يكون العبء ضيّقاً مع عبء عمل يملأ سياق 256K فعلاً. «بطاقة واحدة» تشير إلى عدد المنافذ الفيزيائية، لا إلى عتاد رخيص.
ومع ذلك، فهذا الإصدار مهم لأن مرجع المقارنة عقدة H100 من ثماني بطاقات. فإذا استُبدلت العقدة متعددة البطاقات التي كانت خدمة FP16 تتطلّبها ببطاقة واحدة عالية السعة، تنخفض الطاقة والمساحة وتعقيد الربط البيني بشكل حادّ. لا تنخفض التكلفة المطلقة بقدر ما يصبح شكل النظام المطلوب أبسط جوهرياً.
تمثّل النسختان خيارين مختلفين. نسخة 1-bit مُحسّنة لدفع النموذج إلى أقل عتاد ممكن. حجم 85.5GiB نتيجة ضغط شديد، وتقبل في المقابل خسارة جودة مقابل الأصل. أما نسخة 4-bit فتطلب ضعف الذاكرة تقريباً عند 169.9GiB، لكن تقارير المجتمع تقول إنها تحافظ على أداء قريب من الأصل.
هنا تبرز قاعدة قرار عملية. في مهام الوكلاء حيث تتراكم استدعاءات الأدوات وسلاسل الاستدلال الطويلة، تتراكم تراجعات الجودة الصغيرة وتميل إلى إفساد النتيجة النهائية. تبدو الأسئلة القصيرة سليمة حتى مع 1-bit، لكن في العمل الوكيل المتعدد الخطوات يعمل هامش 4-bit الإضافي كحاجز أمان. إن سمحت ميزانية العتاد، فتفضيل 4-bit لخدمة الوكلاء هو الخيار الافتراضي المعقول.
يندرج ذكر MTP في هذا السياق أيضاً. فالتنبؤ متعدد الرموز يقترح ويتحقّق من عدة رموز من تمريرة أمامية واحدة، ما يرفع إنتاجية مرحلة فك التشفير المقيّدة بعرض نطاق الذاكرة. ولأن النماذج منخفضة البتّات أوزانها أصغر، فهي تحرّر هامشاً نسبياً من عرض نطاق الذاكرة يتناسب جيداً مع تقنيات الإنتاجية مثل MTP.
بما أنها ملفات GGUF قائمة على llama.cpp، فمسار الخدمة نفسه مألوف. تجلب ملف GGUF، وتحمّله عبر llama.cpp، وتفعّل خيار MTP، ثم تعرضه كخادم متوافق مع OpenAI. من الناحية المفاهيمية تبدو البنية هكذا.
# تحميل نسخة 1-bit GGUF (مثال مفاهيمي، راجع مستودع الإصدار لأسماء الملفات والرايات الدقيقة)
./llama-server \
--model hy3-295b-1bit.gguf \
--ctx-size 262144 \
--n-gpu-layers 999 \
--draft-max 4 # تنبؤ متعدد الرموز على طراز MTP
إن أردت إعطاء الأولوية للإنتاجية عند FP8 أو دقة أعلى بدلاً من ذلك، فقد وثّق المجتمع أيضاً مساراً يخدم عبر بطاقات متعددة باستخدام vLLM أو SGLang مع Expert Parallelism. يستهدف مسار GGUF منخفض البتّات الخدمة من عقدة واحدة على أقل عتاد، بينما يستهدف مسار vLLM الإنتاجية وعدد المستخدمين المتزامنين.
لم ننزّل فعلياً نسخة 85.5GiB ولم نشغّل الاستدلال لأجل هذه المقالة. فمتطلّب العتاد بذاكرة موحّدة 96GB أو أكثر يقع خارج نطاق بيئة هذا التصريف. وعليه فالأرقام أعلاه كلها قيَم أبلغت عنها Tencent والمجتمع، ونذكر بصدق غياب إعادة الإنتاج. على أي جهة تقيّم التبنّي أن تدرج خطوة للتحقق من الجودة والإنتاجية بقياساتها الخاصة على العتاد المستهدف.
يهمّ هذا الإصدار خصوصاً من منظور ai-platform لدى ThakiCloud. تجدول ai-platform وحدات المعالجة الرسومية عبر K8s وKueue وتخدم النماذج عبر بيئات عملاء متنوعة بالاعتماد على vLLM. تشغيل نموذج بحجم رائد على عقدة واحدة عالية السعة يعني أن وحدة توزيع العقد للخدمة متعددة المستأجرين تصبح أبسط. فبدلاً من جدولة مبنية على عقد H100 من ثماني بطاقات، تصبح معالجة بطاقة واحدة من فئة 128GB كوحدة خدمة واحدة تجعل إدارة الطوابير وتوزيع الأولويات في Kueue أكثر قابلية للتنبؤ.
في سياق الاستضافة المحلية والذكاء الاصطناعي السيادي، يكون هذا الاتجاه أكثر مباشرةً. فالعملاء الذين لا يمكنهم إرسال بياناتهم المحلية إلى الخارج مضطرون لتشغيل النماذج على عتادهم الخاص، وعقدة بثماني بطاقات حاجز مرتفع في التوريد والمساحة والطاقة. فإذا أمكن خدمة نموذج رائد على جهاز واحد من فئة 128GB، تنخفض عتبة العتاد للنشر السيادي بوضوح. مع ذلك، فإن التحقق مما إذا كانت خسارة الجودة منخفضة البتّات مقبولة لعبء عمل العميل مسؤولية يجب أن نتحمّلها.
من منظور أعباء عمل الوكلاء، يتّصل هذا بـ Paxis أيضاً. Paxis هي Agent-Native Cloud التي تعمل فوق ai-platform، تنفّذ المهارات في بيئات معزولة وتمرّر كل إجراء عبر بوّابات السياسات وسجلات التدقيق. فإذا أمكن خدمة نموذج متخصص في الوكلاء واستدعاء الأدوات مثل Hy3 بتكلفة عتاد منخفضة، تنخفض تكلفة التشغيل لكل وكيل، وهذا بدوره يعني إمكانية تشغيل مزيد من التدفقات المستقلة اقتصادياً. الخدمة منخفضة التكلفة هي البنية التي تصنع اقتصاديات الوكلاء.
أكبر اعتراض هو حقيقة «الوحدة الواحدة». فجهاز بذاكرة موحّدة من فئة 96GB إلى 128GB لا يزال باهظاً وليس عتاداً سائداً بحق. قراءة هذا الإصدار على أنه «يمكن للجميع الآن تشغيل 295B على حاسوب محمول» سوء فهم. الأدقّ هو أن «عبء عمل كان يتطلّب عقدة متعددة البطاقات نزل إلى بطاقة واحدة عالية السعة».
ثانياً، قد تكون خسارة جودة نسخة 1-bit قاتلة حسب عبء العمل. تقول ملخّصات القياس «قريب من الأصل»، لكن هذا يُقاس عادةً مقابل 4-bit أو على تقييمات تغلب عليها المهام القصيرة. أما كيف تصمد 1-bit تحت سلاسل استدلال طويلة واستدعاءات أدوات دقيقة متكرّرة في المهام الوكيلة فلا يتأكّد إلا على أعباء العمل الحقيقية.
ثالثاً، لم تُتحقّق هذه الأرقام بعد على نطاق واسع وبشكل مستقل. فهي تعتمد على تقارير من Tencent والمجتمع المبكر، وإلى أن تتراكم نتائج إعادة الإنتاج عبر عتاد ومهام متنوعة، يبقى التعامل معها بحذر الموقف الأكثر أماناً. ونحن أيضاً سنستخدم الأرقام المنشورة نقطة انطلاق فقط عند تقييم التبنّي، ونتّخذ قياساتنا الخاصة على البيئة المستهدفة مرجعاً.
ومع ذلك، فالاتجاه نفسه واضح. انتقال وحدة الخدمة للنماذج الرائدة مفتوحة الأوزان من عقدة متعددة البطاقات إلى بطاقة واحدة عالية السعة إشارة مرحّب بها لأي بنية تحتية تتعامل مع الاستضافة المحلية والذكاء الاصطناعي السيادي.
صمدت طويلًا فكرة أن النماذج الصغيرة ليست ذكية. لذلك ألقى الممارسون كل مهمة تقريبًا على النماذج الكبيرة، ودفعوا ثمن ذلك كمونًا وتكلفةً وخطرَ خروج البيانات من الجهاز. لكن إن حصرت المهمة بشكل ضيّق جدًا تتغير الحكاية. تخلَّ عن العمومية واضبط نموذجًا صغيرًا ليُتقن شيئًا واحدًا بالضبط، وضمن ذلك المجال الضيّق لا يبقى سبب لاستدعاء نموذج كبير.
يستهدف عرض «From 46% to 90%: Fine-Tuning Tiny LLMs for On-Device Agents»، الذي قدّمه Cormac Brick، المهندس الرئيسي في Google AI Edge، هذه النقطة بالضبط. رفع ضبطُ نموذج FunctionGemma بحجم 270 مليون معامل على مهمة وكيل محددة الدقةَ من 46% إلى 90%، وهذا هو عنوان العرض وخلاصته معًا. ويُبلَّغ أن هذا النموذج يحقق نحو 2000 رمز في الثانية من إنتاجية المعالجة المسبقة (prefill) على Pixel 7. كل ذلك يحدث داخل الهاتف، بلا استدعاء خادم.
يقرأ هذا المقال ذلك العرض من منظور ThakiCloud التي تُشغّل بنية استدلال متعددة المستأجرين. ننظر في سبب كون نموذج صغير متخصص منطقيًا على الجهاز، وماذا يغيّر الضبط فعلًا، وكيف يبسّط زمن تشغيل مثل LiteRT-LM النشرَ، وما المعنى العملي الذي يحمله هذا الاتجاه لبنية الخدمة ومنصة الوكلاء لدينا. أرقام الدقة والإنتاجية والمدة المذكورة أدناه كلها قيم مُبلَّغ عنها من العرض والتغطية المرتبطة، وليست قيمًا أعاد ThakiCloud إنتاجها.
الفيديو أعلاه هو عرض Cormac Brick الأصلي كاملًا. والتحليل أدناه مبني على ذلك العرض والتغطية العامة.
FunctionGemma نموذج بحجم 270 مليون معامل من عائلة Gemma متخصص في استدعاء الدوال (function calling). استدعاء الدوال هو السلوك الجوهري لوكيل على الجهاز، لأنه يحوّل طلب المستخدم بلغة طبيعية إلى استدعاء أداة مُهيكل يستطيع التطبيق تنفيذه. تحويل «اضبط منبّهًا للتاسعة صباح الغد» إلى استدعاء مثل setAlarm(time="09:00", date="tomorrow") مثال على ذلك. وما دام هذا التحويل دقيقًا، فلا حاجة لاستدعاء نموذج عام بمليارات المعاملات.
المشكلة أن نموذجًا صغيرًا منشورًا بشكل عام تكون دقته منخفضة على مخطط أدوات تطبيق محدد. الـ46% التي يذكرها العرض هي تلك النقطة بالضبط. وهنا يدخل الضبط. اضبط النموذج بشكل ضيّق على مخطط الدوال الفعلي وأنماط الطلبات في التطبيق المستهدف، فيرتفع النموذج نفسه بحجم 270 مليون إلى 90%.
flowchart TB
A[طلب المستخدم بلغة طبيعية<br/>منبّه للتاسعة غدًا] --> B[وكيل على الجهاز]
B --> C{FunctionGemma 270M}
C -->|نشر عام| D[دقة نحو 46%<br/>مخطط التطبيق غير محاذى]
C -->|ضبط خاص بالمهمة| E[دقة نحو 90%<br/>محاذى لمخطط الدوال الفعلي]
E --> F[استدعاء دالة مُهيكل<br/>setAlarm 09:00 tomorrow]
F --> G[التطبيق ينفّذ مباشرة<br/>بلا استدعاء خادم]
E --> H[زمن تشغيل LiteRT-LM<br/>Pixel 7 نحو 2000 tok/s]
فهم طبيعة هذه الفجوة مهم. يستدلّ النموذج الكبير عبر حتى مخطط غير مألوف بفضل معرفة عامة هائلة. أما النموذج الصغير فيفتقر إلى ذلك الفائض. لكن ركّزه على توزيع ضيّق، فيصبح ضمن ذلك التوزيع دقيقًا بقدر نموذج كبير تقريبًا. الضبط أقرب إلى توجيه السعة التي يملكها النموذج أصلًا نحو المهمة المستهدفة منه إلى حقن ذكاء جديد فيه.
وفقًا للعرض، ينتهي هذا الضبط في زمن قصير على نحو لافت. تُبلّغ التغطية المرتبطة بأن التدريب يكتمل في نحو 21 دقيقة. وبفضل الحجم الصغير البالغ 270 مليون، يكون التدريب نفسه خفيفًا وقابلًا للإدارة حتى على عتاد استهلاكي. ويحمل هذا دلالات مباشرة لممارسة علم البيانات. فهو يعني أن نموذج تشغيل يكون فيه لكل تطبيق ولكل مجموعة أدوات نموذجه الصغير المتخصص، ويُدرَّب كلٌّ منها بإيجاز، هو نموذج واقعي. فبدل تغطية كل تطبيق بنموذج عام واحد ضخم، تحتفظ بعدة نماذج متخصصة مُقسَّمة بدقة حسب المهمة.
تلامس هذه الفكرة أيضًا مبدأً حافظنا عليه في عملنا الدُّفعي على المحتوى. حلٌّ متخصص يملأ هيكلًا ضيّقًا مُتحقَّقًا منه يتفوق على حلٍّ عام عالي درجة الحرية في متوسط الجودة. وضبط نموذج صغير يطبّق ذلك المبدأ على مستوى النموذج.
يشدّد العرض على التشغيل على الجهاز لأربعة أسباب.
ينخفض الكمون. لأن الطلب لا يقطع رحلة ذهاب وإياب عبر الشبكة، ينتهي تحويل استدعاء الدالة فورًا داخل الهاتف. ولواجهة يجب أن يتفاعل فيها الوكيل مع أفعال المستخدم في الزمن الحقيقي، يكون هذا الفارق حاسمًا.
تُصان الخصوصية. لا تغادر طلبات المستخدم وبياناته الشخصية الجهاز أبدًا. وفي سياقات حساسة كالصحة والمال والمراسلة، تصبح حقيقة عدم ذهاب البيانات إلى خادم بحد ذاتها متطلبًا للمنتج.
يعمل دون اتصال. يؤدي الوكيل وظيفته حتى بلا شبكة. النموذج السحابي عاجز حين ينقطع الاتصال؛ أما النموذج على الجهاز فلا.
تختفي التكلفة. لأن الاستدلال يجري على الجهاز، لا توجد محاسبة API لكل رمز. وكلما زاد استخدام التطبيق، كبُر هذا التوفير.
تدريب نموذج صغير ونشره على أجهزة لا تُحصى مشكلتان منفصلتان. يعرض العرض LiteRT-LM كزمن تشغيل للنشر. LiteRT-LM زمن تشغيل يتيح لك وضع نماذج مثل Gemma 4 على طيف واسع من العتاد من المحمول إلى الأنظمة المدمجة. وبدمجه مع AI Core، كما يشرح العرض، يمكنك تشغيل مهارات وكيل على الجهاز.
الجوهر أن ثمة مسارًا لنشر نموذج واحد باتساق عبر عتاد متنوع. فدون عناء إعادة تركيب نموذج متخصص مُدرَّب على مُسرِّع كل جهاز، يمتص زمن التشغيل ذلك التغاير. وهذا هو الشرط العملي الذي يرفع الوكلاء على الجهاز من مستوى التجربة إلى مستوى المنتج.
قد يبدو اتجاه النماذج المتخصصة على الجهاز إشارةً معاكسة لنا نحن مُشغِّلي الخدمة السحابية، لكنه في الواقع يحمل دلالات مباشرة لكلا المنتجين.
عدسة ai-platform. يزيح صعود النماذج الصغيرة المتخصصة تركيز بنية الخدمة. توفّر منصة ai-platform من ThakiCloud جدولة GPU قائمة على K8s وKueue، وعزلًا متعدد المستأجرين، وخدمة داخل المؤسسة. السؤال الذي يطرحه الضبط على الجهاز هنا ليس «إذا انتقل كل شيء إلى الجهاز، فهل يصبح الخادم غير ضروري؟» بل العكس. فلتدريب نموذج متخصص منفصل بإيجاز لكل تطبيق، تحتاج بنية تحتية تشغّل تلك المهام التدريبية بتكلفة منخفضة وعلى نطاق واسع. إن عبء عمل يكرّر ضبطًا بحجم 270 مليون يستغرق 21 دقيقة عبر مئات مجموعات الأدوات هو بالضبط ما تستهدفه بنية تصفّ الـGPU عبر Kueue وتعزل حسب المستأجر. التدريب على الخادم والاستدلال على الجهاز هو الخلاصة الطبيعية.
في الوقت نفسه، لا تكتفي كل مؤسسة بالاستدلال على الجهاز وحده. فحين يلزم سياق أكبر أو استدلال أعقد، يتدخّل نموذج خادم. وللمؤسسات المتحفظة على إرسال بيانات المصدر إلى سحابة خارجية، تصبح الخدمة داخل المؤسسة والاستضافة الذاتية مهمة. والتنافسية على تكلفة خدمة منخفضة هي مفتاح الاحتفاظ بتلك المؤسسات.
عدسة Paxis. جوهر FunctionGemma هو تحويل اللغة الطبيعية إلى استدعاء أداة مُهيكل. وهذا نسخة مصغّرة مما تفعله Paxis. إن Paxis هي السحابة الأصيلة للوكلاء من ThakiCloud، تختار من أكثر من 960 مهارة عبر BM25، وتشغّلها في صناديق رملية معزولة، وتمرّر كل فعل عبر بوابات السياسة وسجلات التدقيق. إذا عالج وكيل على الجهاز استدعاءات الدوال لمجموعة أدوات ضيّقة على الهاتف، فإن Paxis تعالج توجيه الأدوات عبر فضاء مهارات أوسع بكثير في السحابة. الطبقتان لا تتنافسان؛ بل تتكاملان. تنشأ بنية طبقية يتولى فيها الجهاز تفسير النية المحلي الخفيف، وتتولى Paxis العمل الذي يتطلب تنسيقًا معقدًا متعدد الوكلاء وتدقيقًا.
لهذا النهج حدود واضحة أيضًا.
أولًا، ثمن التخصص هو العمومية. ذلك النموذج الذي رفع 46% إلى 90% قويٌّ فقط في المهمة الضيّقة التي دُرِّب عليها. غيّر مخطط الأدوات أو انتقل إلى مجال تطبيق جديد وعليك الضبط من جديد. وفي بيئة تتغير فيها التطبيقات والأدوات كثيرًا، يكبُر عبء الصيانة تبعًا لذلك.
ثانيًا، هل تكفي الـ90% يعتمد على المهمة. إن الخطأ في استدعاء دالة يعني تنفيذ فعل خاطئ، ففي المجالات التي تكون فيها كلفة الفشل عالية قد يكون خطأ بنسبة 10% قاتلًا. وفي تلك الحالة تحتاج بنية مزدوجة يتحقق فيها نموذج خادم من نتيجة الجهاز.
ثالثًا، رقم الـ21 دقيقة للتدريب يعتمد بشدة على الحجم والعتاد. فالتكلفة التشغيلية الحقيقية بما فيها إعداد البيانات ومحاذاة المخطط والتقييم لا يمكن الحكم عليها بزمن التدريب وحده. وينبغي أخذ أرقام العرض المبهرة كقيم في ظروف مُرتَّبة جيدًا.
رابعًا، يواجه النشر على الجهاز تجزئة الأجهزة. فحتى لو امتص LiteRT-LM التغاير، يبقى الأداء الفعلي وقيود الذاكرة لكل جهاز يطلبان تحققًا فرديًا.
مع ذلك، اتجاه تشغيل نموذج صغير متخصص على الجهاز مقنع. إنه النقطة التي تتحقق فيها الفوائد الأربع، الكمون والخصوصية والعمل دون اتصال والتكلفة، في آنٍ واحد. وبالنسبة لنا، هذا الاتجاه ليس إشارة إلى أن الخادم يصبح غير ضروري، بل إشارة تجعلنا نعيد رسم أين ينبغي أن يقع الفصل بين التدريب والاستدلال.