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

ما هو GPT-5.6 Sol ولماذا يُركَّز على الأمن السيبراني

GPT-5.6 هو عائلة نماذج كشفت عنها OpenAI في 9 يوليو 2026. تضم ثلاث فئات مرتبة حسب القدرة: لونا (Luna)، تيرا (Terra)، وسول (Sol)، حيث يُعد Sol النموذج الرائد الأقوى. وأوضحت OpenAI أنها تُشغِّل Sol فوق بنية Cerebras بمعدل يصل إلى 750 رمزاً في الثانية، مؤكدة أنها رفعت سرعة المعالجة إلى جانب القدرة نفسها.

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

هناك نقطة يجب توضيحها بأمانة. النص الأصلي للتغريدة هو إعلان صادر عن OpenAI نفسها، بينما التقييم المستقل لساحة “The Last Ones” التي سنتناولها لاحقاً (من قِبل معهد سلامة الذكاء الاصطناعي البريطاني AISI) كان حتى وقت النشر يقتصر على GPT-5.5. لذا فإن ادعاء Sol بـ”الرقم القياسي الجديد” هو رقم قدمته OpenAI نفسها، ومن الأسلم قراءته كادعاء من الجهة المعلنة إلى حين اكتمال نشر نتائج إعادة الإنتاج من طرف ثالث. يقتبس هذا المقال الأرقام القابلة للتحقق مع تمييزها بوضوح عن الجهة التي أعلنتها.

“The Last Ones”: ما تقيسه ساحة الاختبار السيبرانية ذات الـ32 خطوة

“The Last Ones” هو سيناريو اختراق محاكى لشبكة شركة افتراضية تديره AISI. يتكون من 32 خطوة إجمالاً، ويُقدَّر أن إنجازه من البداية إلى النهاية على يد خبير بشري متمرس يستغرق نحو 20 ساعة. وليس مجرد حل مسائل منفصلة، بل بنية يجب فيها ربط عدة قدرات ضرورية للاختراق الفعلي في خيط واحد لاجتيازه. يتعين على الوكيل أن يستولي على النظام، وأن يفكك البروتوكولات والمصادقة المشفرة عبر الهندسة العكسية، وأن يتلاعب بوحدات التحكم، كل ذلك عبر سلسلة من القرارات المستقلة المتصلة.

عدد النماذج التي أكملت هذه الساحة حتى النهاية حتى الآن قليل جداً. كان Claude Mythos preview أول من نجح، حيث أكمل ثلاث مرات من أصل عشر محاولات (3/10)، تلاه GPT-5.5 كثاني نموذج ينجزها حتى النهاية بمعدل مرتين من أصل عشر (2/10). قد يبدو معدل النجاح منخفضاً مقارنةً بعدد المحاولات، لكن مجرد إتمام هجوم متعدد المراحل يستغرق 20 ساعة دون تدخل بشري ولو مرة واحدة يُعد إشارة على تجاوز عتبة حرجة. وتشير دراسة ذات صلة (arXiv 2603.11214) إلى أن هذه القدرة تتناسب لوغاريتمياً وخطياً مع حجم الحساب في وقت الاستدلال، ولم يُلاحَظ بعد أي مستوى استقرار لها. وتحمل النتيجة القائلة إن رفع ميزانية الرموز من عشرة ملايين إلى مئة مليون يمكن أن يرفع الأداء بنسبة تصل إلى 59% دلالة مقلقة، مفادها أن احتمال إتمام الهجوم يستمر في الارتفاع كلما زاد المال والوقت المستثمَران فيه.

القفزة في القدرات كما تظهرها المقاييس المرجعية

تظهر هذه القفزة في القدرات أيضاً في المقاييس المرجعية الفردية. وفقاً لـ OpenAI، سجل GPT-5.6 نسبة 73.5% في ExploitBench2، وهو مقياس تقييم قدرات الاستغلال، متفوقاً بفارق كبير على نسبة 47.9% التي حققها GPT-5.5 بميزانية رموز إخراج مماثلة تقريباً. أي ارتفاع بأكثر من 25 نقطة مئوية في جيل واحد فقط. لكن هناك تفصيلاً هنا أيضاً. تشير اختبارات OpenAI نفسها إلى أن GPT-5.6 أكثر براعة في اكتشاف الثغرات وإصلاحها منه في تنفيذ الهجوم الفعلي حتى النهاية بشكل موثوق. أي أن ميزان القدرة لا يزال، حتى الآن، يميل لصالح الدفاع.

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

الدفاع قبل الهجوم: حزمة الأمان متعددة الطبقات من OpenAI

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

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

flowchart TB
    A[طلب المستخدم] --> B[قيود على مستوى النموذج<br/>حظر الدعم السيبراني الممنوع]
    B --> C[مصنِّف التفعيل<br/>مراقبة أثناء التوليد وتدخل في المنتصف]
    C --> D[مراقبة فورية للمخرجات<br/>مصنِّف إساءة الاستخدام]
    D --> E[مراجعة نظام الاستدلال الثانوي<br/>إيقاف مؤقت قبل التسليم]
    E --> F[تحليل سلوكي على مستوى الحساب<br/>رصد الأنماط الخبيثة]
    F --> G[تسليم الاستجابة أو حظرها]
    F -.نمط غير طبيعي.-> H[مراجعة وحظر وإجراء على الحساب]

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

دلالات التطبيق على منتجات ThakiCloud

خبر ارتفاع القدرة الهجومية للنماذج المتقدمة يصب، بشكل مفارق، في صالح الذكاء الاصطناعي المحلي والسيادي. فكلما أصبح الهجوم المستقل واقعاً، تسعى الشركات والجهات الحكومية إلى وضع الإجابة على سؤال “من استدعى هذا النموذج، وماذا طلب منه، وأي مخرجات تلقى” تحت سيطرتها الخاصة. منصة ai-platform من ThakiCloud تتماشى تماماً مع هذا المطلب. فهي، فوق جدولة GPU قائمة على K8s وKueue، تُبقي النموذج داخل عنقود العميل، وتقدمه بعزل متعدد المستأجرين، وتدعم النشر المحلي والسيادي بحيث لا تتجاوز البيانات الحدود الخارجية. وكلما كان عبء العمل الأمني أكثر حساسية، ازدادت قيمة الاستضافة الذاتية التي تُبقي أوزان النموذج وحركة الاستدلال داخل بنيتك التحتية الخاصة. وانخفاض تكلفة التقديم يشكل أيضاً شرطاً عملياً يتيح للمدافع تشغيل مهام متكررة بكميات كبيرة، مثل فحص الثغرات، بميزانية يمكن تحملها.

على مستوى الوكلاء، يتشابه تصميم Paxis بشكل لافت مع حزمة الأمان متعددة الطبقات التي رأيناها أعلاه. Paxis هو طبقة تحكم Agent-Native Cloud تعمل فوق ai-platform، وتعامل المهارات (Skills) والأدوات (Tools) والسياسات (Policies) وسجلات التدقيق (Audit Logs) كموارد من الدرجة الأولى. تُنفَّذ المهارة التي يشغِّلها الوكيل داخل صندوق رمل معزول دون تلويث بيئة المضيف، ولا يُنفَّذ أي إجراء إلا بعد اجتياز بوابة سياسات، وتُسجَّل كل هذه العملية في سجل تدقيق. تماماً كما وضعت OpenAI شبكة مراقبة متداخلة عبر داخل النموذج وخارجه وعلى مستوى الحساب، يفصل Paxis اختيار المهارة (هارنس BM25)، والتنفيذ (عزل صندوق الرمل)، والتحكم (بوابة السياسات)، والتتبع (سجل التدقيق) إلى طبقات منفصلة. هذه البنية تمنع الوكيل المستقل من استخدام أداة خاطئة على هدف خاطئ، وتتيح، إن وقع حادث، تتبع أين ومتى حدث الخلل.

كلا المنظورين يكمّل الآخر. إذا كان ai-platform يمثل ضبطاً مادياً يُبقي النموذج داخل حدودك، فإن Paxis يمثل ضبطاً منطقياً يقيّد سلوك الوكيل الذي يستخدم ذلك النموذج بالسياسات والسجلات. في عصر ينجز فيه الذكاء الاصطناعي اختراقاً من 32 خطوة بشكل مستقل، لا تكمن أساسيات الدفاع في اختيار نموذج قوي، بل في تشغيل أي نموذج داخل بيئة خاضعة للرقابة مع ترك أثر لسلوكه. هذا هو السبب في أن طبقة تحكم الذكاء الاصطناعي المحلي والوكلاء تزداد أهمية الآن.

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

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

ثانياً، ملاحظة أن القدرة تميل حالياً لصالح الدفاع ليست سبباً كافياً للاطمئنان. فإذا استمر التوسع اللوغاريتمي الخطي دون توقف، يمكن أن ينقلب التوازن الحالي المؤاتي للدفاع في أي لحظة لمجرد زيادة حجم الحساب. عبارة “الآن هو أكثر براعة في الدفاع منه في الهجوم” وصف للحظة راهنة، وليست ضماناً دائماً للسلامة.

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

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

المصادر

• التغريدة الأصلية (RT @OpenAI)

• [GPT-5.6: Frontier intelligence that scales with your ambition

  OpenAI](https://openai.com/index/gpt-5-6/)

• [Previewing GPT-5.6 Sol: a next-generation model

  OpenAI](https://openai.com/index/previewing-gpt-5-6-sol/)

• [GPT-5.6 Preview System Card

  OpenAI Deployment Safety Hub](https://deploymentsafety.openai.com/gpt-5-6-preview)

• Introducing Aardvark: OpenAI’s agentic security researcher

• [Our evaluation of OpenAI’s GPT-5.5 cyber capabilities

  AISI](https://www.aisi.gov.uk/blog/our-evaluation-of-openais-gpt-5-5-cyber-capabilities)

• [OpenAI Previews GPT-5.6 Sol With Restricted Access and Stronger Cyber Safeguards

  The Hacker News](https://thehackernews.com/2026/06/openai-limits-gpt-56-rollout-as-sol.html)

• [Measuring AI Agents’ Progress on Multi-Step Cyber Attack Scenarios

  arXiv 2603.11214](https://arxiv.org/html/2603.11214v2)

نظرة عامة

ظلت نماذج توليد الصور لفترة طويلة منقسمة إلى مسارين. في جانب، هناك نموذج لغوي يفهم النص. وفي الجانب الآخر، هناك نموذج انتشار (diffusion) يرسم البكسلات. وتُعد سلسلة Stable Diffusion المثال الأبرز على ذلك. يفسّر مشفر النص التوجيه (prompt)، ثم يزيل UNet أو DiT الضوضاء في الفضاء الكامن، ثم يعيد VAE (المشفر التلقائي التبايني) بناء تلك القيم الكامنة إلى بكسلات من جديد. إنها بنية يحدث فيها الفهم والتوليد في وحدتين مختلفتين وبتمثيلين مختلفين.

أما 日日新 SenseNova U1 من SenseTime (سنسه‌تايم)، الذي أُطلق بشكل تدريجي ابتداءً من أبريل 2026، فيرفض هذا الانفصال جملة وتفصيلاً. فهو يلغي كلاً من المشفر البصري و VAE، ويطرح بدلاً منهما بنية NEO-Unify التي تعالج المعلومات اللغوية والبصرية حتى النهاية داخل فضاء تمثيل واحد. يتولى النموذج المفرد معالجة الفهم والتوليد والتحرير، وصولاً إلى التوليد المتشابك (interleave) الذي يبثّ النص والصورة بالتناوب. أُتيحت الأوزان برخصة Apache 2.0، وبحجم يقارب 8B فإنها تعمل على بطاقة RTX 5090 واحدة. وهذا يعني إمكانية الاستضافة الذاتية لأغراض تجارية.

يستعرض هذا المقال حقائق SenseNova U1، وما يمكننا فعلياً تشغيله في بيئتنا المحلية (on-premise)، بصراحة تامة، بما في ذلك سبب استحالة تشغيله مباشرة على أدوات شائعة كـ Automatic1111 كما قد يتوقع البعض. وبما أن ThakiCloud تعمل على تقديم النماذج ضمن بيئات عملاء متنوعة، فإن جوهر هذا المقال هو سدّ الفجوة بين عنوان “صدرت أوزان مفتوحة” وواقع “يمكن تشغيلها على مجموعتنا الحاسوبية”.

ما هو SenseNova U1: معنى التخلي عن VAE

تنطلق NEO-Unify من ملاحظة بسيطة: البكسلات والكلمات مترابطة بعمق في جوهرها، لكن خطوط الأنابيب (pipelines) التقليدية أجبرتها على الانفصال. لذلك يزيل U1 محوّلين وسيطين كاملين. لا يوجد مشفر بصري (VE) كان يضغط الصورة إلى سمات، ولا يوجد VAE كان يعيد القيم الكامنة إلى بكسلات. بدلاً من ذلك، يدمج المعلومات اللغوية والبصرية في تمثيل مركّب واحد ويعالجه من البداية إلى النهاية. وتوضح SenseTime أن هذا يعمل فوق بنية MoT (خليط من المحولات، Mixture-of-Transformers) أصيلة، مما يتيح استنتاجاً كفؤاً بلا تعارض بين الوسائط المختلفة.

من منظور المستخدم، يتجلى هذا الفرق في “نموذج واحد يقوم بكل شيء”. فهو يفهم الصور (الإجابة عن أسئلة بصرية، VQA)، ويولّد الصور، ويحرّرها، ويولّد النص والصورة بالتناوب ضمن تدفق واحد. ويُطرح كمثال بارز إنتاج محتوى يتناوب فيه الشرح مع الرسوم التوضيحية، كدروس الطهي أو يوميات السفر، وذلك في عملية توليد واحدة. كما تشدد SenseTime على قدرته في مجال الذكاء المكاني (spatial intelligence) على فهم التخطيطات المعقدة والعلاقات بين الأجسام، وهو ما يمهد لمستقبل يكتمل فيه الإدراك والاستدلال والتنفيذ في نموذج واحد ضمن الذكاء الاصطناعي المتجسّد (embodied AI) للروبوتات.

فيما يلي مخطط مفاهيمي يضع خط أنابيب سلسلة SD التقليدي جنباً إلى جنب مع خط الأنابيب الموحد لـ U1.

flowchart TB
    subgraph SD["سلسلة SD التقليدية (منفصلة)"]
        direction TB
        A1["توجيه نصي"] --> A2["مشفر النص (CLIP)"]
        A2 --> A3["UNet / DiT (انتشار كامن)"]
        A3 --> A4["مفكّك VAE"]
        A4 --> A5["صورة بكسلية"]
    end
    subgraph U1["SenseNova U1 (موحد عبر NEO-Unify)"]
        direction TB
        B1["مدخل نصي · صورة"] --> B2["فضاء تمثيل موحد واحد<br/>(بلا VE · بلا VAE)"]
        B2 --> B3["محوّل MoT أصيل<br/>فهم · توليد · تحرير مشترك"]
        B3 --> B4["مخرج نصي · صورة · متشابك"]
    end
    SD -.->|"3 وحدات، نوعا تمثيل"| GAP["كلفة الانفصال:<br/>تمثيل مختلف للفهم والتوليد"]
    U1 -.->|"وحدة واحدة، نوع تمثيل واحد"| WIN["فائدة التوحيد:<br/>حفظ الارتباط بين البكسل والكلمة"]

الجوهر هو أن U1 ليس نقطة تفتيش انتشارية (diffusion checkpoint)، بل محوّل موحد يعمل كنموذج لغوي كبير. وهذه الحقيقة الواحدة هي ما يحدد بالكامل طريقة التقديم وتوافقية الأدوات التي سنتناولها لاحقاً.

ما أُتيح ليس U1 Pro بل سلسلة U1 Lite

هنا يجب التنويه بتمييز جوهري. U1 Pro الظاهر على صفحة منصة SenseTime (sensenova.cn) هو النسخة التجارية الرائدة المستضافة. ورغم أن أمثلة توليد الرسوم البيانية والملصقات عالية الكثافة مثيرة للإعجاب، فإن أوزان هذه الفئة “Pro” غير متاحة على HuggingFace. فمن الصواب اعتباره طبقة تجارية يُصار إليها عبر واجهة برمجية (API) فقط.

أما ما يمكن استضافته ذاتياً فهي سلسلة U1 Lite. وفيما يلي أهم الأوزان المتاحة:

تمر نماذج SFT بمراحل: إحماء الفهم ← التدريب المسبق للتوليد ← التدريب المتوسط الموحد ← الضبط الدقيق الموحد (SFT)، ويُحصل على النموذج النهائي بإضافة تعلم معزز (RL) للتحويل من نص إلى صورة (T2I) فوق ذلك. وتشير SenseTime إلى أن ما صدر اليوم هو نسخة “Lite”، مع الإعلان عن نسخة أكبر حجماً قادمة. أي أن النموذجين 8B/A3B الحاليين نسخة مدمجة نسبياً، والسقف ما زال مفتوحاً.

باختصار، إذا قيل في مدونة أو عرض توضيحي “لقد شغّلنا U1 Pro”، فهذا غير دقيق. النموذج المفتوح الذي نضعه في بيئتنا المحلية هو U1-8B-MoT (أو A3B).

الموقع على المعايير القياسية

تدّعي SenseTime أن U1 هو “أفضل أداء (SoTA) ضمن المعسكر مفتوح المصدر في كل من الفهم والتوليد معاً”. أُجري التقييم على معايير OneIG (بالإنجليزية/الصينية)، LongText (بالإنجليزية/الصينية)، BizGenEval (سهل/صعب)، CVTG، IGenBench، ومعايير الرسوم البيانية. وتُبرز بطاقة النموذج مخطط المفاضلة بين الأداء وزمن استجابة التوليد (latency)، مع التركيز على تحقيق الجودة نفسها بسرعة أكبر.

بدلاً من نقل الأرقام كما هي، ينبغي النظر إلى طبيعتها. يُقدَّم U1 Lite بوصفه قادراً على تحقيق نتائج بمستوى تجاري في توليد الرسوم البيانية المعقدة تحديداً، أي في المجالات التي تكون فيها اتساقية التخطيط ودقة عرض النص أموراً حاسمة. وتذكر بعض المصادر الإعلامية أن جودة مخرجات U1 Lite تضاهي Qwen-Image 2.0 Pro أو Seedream 4.5، لكن هذا مستند إلى مصادر البائع أو مصادر ثانوية، لذا يبقى مصنّفاً بـ[تقدير] ويحتاج إلى تحقق فعلي. معيارنا واحد فقط: نثق بالأرقام التي نحصل عليها من تشغيله فعلياً ببياناتنا وتوجيهاتنا على معالجاتنا الرسومية (GPU).

التثبيت والتقديم: مساران

حقيقة أن U1 ليس نقطة تفتيش انتشارية بل محوّل موحد تنعكس مباشرة على طريقة تقديمه. فبدلاً من وضعه فوق واجهة انتشار (diffusion UI)، يُقدَّم كما يُقدَّم أي نموذج لغوي كبير.

المسار الأول: transformers الأصيل. يوفر المستودع الرسمي تثبيت التبعيات عبر uv وسكربتات أمثلة مخصصة لكل مهمة، منها: تحويل النص إلى صورة، وتحرير الصور، والتوليد المتشابك.

# مثال على تحرير صورة (يمكن التحرير على مستوى البكسل حتى بلا VAE)
python examples/editing/inference.py \
  --model_path sensenova/SenseNova-U1-8B-MoT \
  --prompt "Change the animal's fur color to a darker shade." \
  --image examples/editing/data/images/1.webp \
  --cfg_scale 4.0 --img_cfg_scale 1.0 --num_steps 50 \
  --output output_edited.png --profile --compare

# التوليد المتشابك (شرح + رسوم توضيحية في تدفق واحد)
python examples/interleave/inference.py \
  --model_path sensenova/SenseNova-U1-8B-MoT \
  --prompt "أنشئ دليلاً مصوراً للمبتدئين لطبق البيض المقلي بالطماطم." \
  --resolution "16:9" --output_dir outputs/interleave/ --stem demo

المسار الثاني: التقديم عبر vLLM-Omni. لإلحاق النموذج بعرض توضيحي أو منتج، يلزم وجود نقطة نهاية متوافقة مع OpenAI. يدعم vLLM-Omni نموذج U1 رسمياً، ويوفر أمثلة لكل من الاستدلال دون اتصال (offline) والتقديم عبر الشبكة (online). ولتخفيف الضغط على ذاكرة VRAM، توجد إمكانية نقل الحمل إلى المعالج المركزي (CPU offload) على مستوى الوحدات. يطبّق خط الأنابيب اكتشاف المكونات (component discovery)، فينقل النموذج اللغوي إلى المعالج المركزي أثناء مراحل ترميز النص/الرؤية، وينقل المشفر البصري إلى المعالج المركزي أثناء حلقة الانتشار، لتقليل الأوزان المقيمة على معالج الرسوميات إلى الحد الأدنى.

# vLLM-Omni: تحويل نص إلى صورة مع تفعيل نقل الحمل إلى المعالج المركزي
python end2end.py \
  --prompt "A cute cat sitting on a windowsill" \
  --width 2048 --height 2048 \
  --enable-cpu-offload --think

خيارات لذاكرة VRAM المحدودة. يوفر المستودع الرسمي نمط نقل الطبقات (layer offload) على معالج رسوميات واحد (--vram_mode full|low|balanced) إلى جانب تحميل التكميم GGUF. تشير التوجيهات إلى أن الجمع بين Q4 GGUF ووضع balanced يتيح التشغيل حتى على بطاقات استهلاكية بذاكرة تقارب 10 إلى 12 جيجابايت. أي أن النشر ينقسم إلى ثلاث مستويات: للحصول على أقصى سرعة استخدم full مع 24 جيجابايت فأكثر، وإن لم تتوفر تلك الموارد فاستخدم GGUF مع balanced، وللتقشف الشديد استخدم low.

أي الأدوات تُستخدم: ComfyUI نعم، A1111 لا

أكثر توقع شائع هو “لنحمّل النموذج كنقطة تفتيش في Stable Diffusion WebUI (Automatic1111)”. والخلاصة أن ذلك غير ممكن. صُمم A1111 لتحميل نقاط تفتيش سلسلة SD المكوّنة من UNet/DiT + VAE + مشفر نص CLIP حصراً. وبما أن U1 محوّل MoT موحد لا يحوي VAE، فإن وضع ملف .safetensors في مجلد نقاط التفتيش لا يؤدي حتى إلى نجاح عملية التحميل. إنه عدم توافق جوهري ناتج عن اختلاف البنية.

إن أردت إدخال التوجيهات يدوياً بطريقة تفاعلية، فإن البديل الفعلي لـ A1111 هو ComfyUI. توفر عقدة مخصصة أنشأها المجتمع (smthemex/ComfyUI_SenseNova_U1) دعماً أصيلاً لنموذج U1، وتتعامل مع 8B-MoT و A3B-MoT وLoRA بثماني خطوات وGGUF جميعاً.

باختصار، محوران: الواجهة التفاعلية التي يستخدمها الأشخاص يدوياً هي ComfyUI، والخلفية البرمجية للعروض التوضيحية والمنتجات التي يستدعيها البرنامج هي vLLM-Omni (متوافق مع OpenAI). من كان يتوقع A1111 فعليه تغيير اختيار الأداة.

منظور ThakiCloud في التقديم

يعمل ai-platform لدى ThakiCloud فوق Kubernetes على تقديم النماذج ضمن بيئات عملاء متنوعة. ويُعد SenseNova U1 مرشحاً جيداً للتناول من هذا المنظور تحديداً.

أولاً، الحجم ملائم للبيئة المحلية (on-premise). فبحجم 8B، يقيم النموذج في نحو 16 إلى 20 جيجابايت وفق دقة fp16، ما يسمح ببناء حاوية تقديم (serving pod) على بطاقة واحدة من RTX 4090 أو 5090 أو A6000، بينما نموذج A3B أخف من ذلك. وهذا ينسجم تماماً مع طريقتنا في وضع معالجات الرسوميات في طابور عبر Kueue وتوزيعها متعددة المستأجرين. فبخلاف النماذج الحدودية الضخمة التي تتطلب 8 وحدات H200، يمكن لعبء عمل فعلي أن يقوم على بطاقة أو بطاقتين من معالجات رسوميات العميل نفسه.

ثانياً، تخفض نقطة النهاية المتوافقة مع OpenAI في vLLM-Omni تكلفة التكامل. وبما أن طبقة التقديم Metis وخطوط أنابيب العروض التوضيحية لدينا مبنية أصلاً على افتراض واجهة متوافقة مع OpenAI، يمكن إلحاق U1 دون الحاجة إلى مكدس انتشار (diffusion stack) منفصل. وتوحيد واجهة توليد الصور مع النموذج اللغوي النصي تحت نظام واحد للمراقبة وقياس التكلفة ميزة عملية حقيقية.

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

كما ينفتح منظور الوكلاء (agents). فـ Paxis، سحابة ThakiCloud الأصيلة للوكلاء (Agent-Native Cloud)، تنفّذ المهارات في بيئات معزولة (sandboxes) وتُخضع كل سلوك لبوابات سياسات وسجلات تدقيق، ونموذج صور موحد مستضاف ذاتياً كـ U1 مناسب تماماً للتسجيل بوصفه “أداة توليد صور” يستدعيها الوكيل. فحين تُستكمل عملية توليد الرسوم البيانية والملصقات في حاويات داخلية دون واجهة برمجية خارجية، فإن التقديم منخفض التكلفة (ai-platform) يرفع مباشرة من جدوى اقتصاديات سير عمل الوكلاء (Paxis).

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

للحفاظ على التوازن، لا بد من النظر إلى الجانب الآخر أيضاً. أولاً، ما هو مُتاح الآن هو النسخة Lite (8B/A3B)، ومن المرجح أن تكون الجودة الفائقة محصورة في نسخة U1 Pro المستضافة. فتعبير “أفضل أداء مفتوح” هو مقارنة ضمن المعسكر مفتوح المصدر، وليس ضماناً لمساواته بأفضل النماذج التجارية.

ثانياً، ميزة البنية الموحدة هي في الوقت نفسه نقطة ضعف في النظام البيئي. فبما أن U1 ليس نموذج SD، فإنه لا يرث أصول سير عمل A1111/SD المتراكمة على مدى سنوات، كـ ControlNet ومكتبات LoRA المجتمعية الضخمة وامتدادات إعادة الرسم (inpainting). ونقل خطوط الأنابيب القائمة إلى U1 يتطلب إعادة بناء منظومة الأدوات من الصفر. صحيح أن عقد ComfyUI ومدرّب LoRA الخاص متاحان، لكن نضج النظام البيئي لا يزال في مراحله الأولى.

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

رابعاً، وضع ذاكرة VRAM المنخفضة ليس مجانياً. فنقل الحمل إلى المعالج المركزي وتسلسل الطبقات (layer streaming) يوفّران ذاكرة VRAM لكن على حساب زيادة زمن الاستجابة بسبب النقل بين المعالج المركزي ومعالج الرسوميات. وإذا كانت الاستجابة اللحظية أمراً حاسماً للخدمة، فالأفضل التشغيل بوضع full على بطاقة بذاكرة 24 جيجابايت فأكثر دون نقل حمل، وهذا ينعكس بدوره على تكلفة معالج الرسوميات.

الخاتمة

يمثّل SenseNova U1 تحقيقاً فعلياً لاتجاه “الوسائط المتعددة الموحدة بلا VAE” عبر أوزان مفتوحة. ورغم أن مدى ما يمكن أن يبلغه نهج دمج الفهم والتوليد في تمثيل واحد لن يتضح إلا مع صدور نسخة أكبر، فإن النسختين الحاليتين 8B/A3B جذابتان بما يكفي بوصفهما مرشحتين للتقديم المحلي. في المقال القادم، سنضع هذا النموذج فعلياً على RunPod وخط أنابيب العروض التوضيحية لدينا، ونشغّل تقديم vLLM-Omni وسير عمل ComfyUI جنباً إلى جنب، ونستعرض النتائج مدعومة بالأرقام.

روابط مرجعية

• بطاقة النموذج: sensenova/SenseNova-U1-8B-MoT
• الكود/التوثيق: OpenSenseNova/SenseNova-U1 (GitHub)
• الورقة البحثية: SenseNova-U1: Unifying Multimodal Understanding and Generation with NEO-unify (arXiv:2605.12500)
• التقديم: مثال vLLM-Omni لنموذج SenseNova-U1
• عقدة ComfyUI: smthemex/ComfyUI_SenseNova_U1
• نسخة U1 Pro المستضافة: SenseNova U1 Pro

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.

The reason this news can’t be a non-issue for an infrastructure company like ThakiCloud is clear. As frontier models’ attack capabilities rise, the center of gravity for defense shifts from “which model is smarter” to “where that model runs, under whose control, and what audit trail it leaves behind.” Models will only keep getting stronger regardless. If that’s the case, the decisive battleground becomes the isolation of the execution environment, policy gates, and post-hoc traceability. Today’s post first lays out what GPT-5.6 Sol has actually demonstrated, sticking strictly to confirmed facts, and then turns to why this capability actually increases demand for on-premises sovereign AI and an agentic control plane.

What GPT-5.6 Sol Is, and Why Cybersecurity Is the Focus

GPT-5.6 is a model family OpenAI released on July 9, 2026. It comes in three tiers by capability: Luna, Terra, and Sol, with Sol as the most powerful flagship. OpenAI stated that it serves Sol on Cerebras infrastructure at up to 750 tokens per second, emphasizing that the leap applies not just to capability but to serving speed as well.

The most prominent axis of this announcement is cybersecurity. OpenAI describes Sol as its most capable cybersecurity model to date, explaining that it has shifted the performance-and-efficiency frontier for long-horizon security work, including vulnerability research and exploitation. The core claim is “go further with fewer tokens.” A reduction in the reasoning tokens consumed to reach the same outcome also means the same budget can now automate more attack attempts. In the regime where capability gains translate directly into cost reductions, the barrier to entry drops for both defenders and attackers.

One thing deserves an honest caveat. The original tweet is OpenAI’s own announcement, and the independent evaluation of the “The Last Ones” range discussed below, run by the UK AI Safety Institute (AISI), covered only up through GPT-5.5 as of publication. So Sol’s “new record” claim is a figure OpenAI itself presented, and until third-party reproduction results are fully public, it’s safer to read it as the claim of the party making the announcement. This piece takes care to distinguish verifiable numbers from the party asserting them.

“The Last Ones”: What a 32-Step Cyber Range Measures

“The Last Ones” is a simulated enterprise network intrusion scenario operated by AISI. It consists of 32 steps in total, and a skilled human expert is estimated to need roughly 20 hours to complete it start to finish. It isn’t a simple problem set; it’s structured so that passing requires stringing together the many capabilities a real breach demands into a single continuous chain. The agent has to autonomously seize systems, reverse-engineer protocols and cryptographic authentication, and manipulate controllers, all while judging its own next move at each step.

Very few models have completed this range from start to finish so far. Claude Mythos preview was the first to succeed, completing it three times out of ten attempts (3/10), and GPT-5.5 was the second to make it all the way through, at two out of ten (2/10). The success rate looks low relative to the number of attempts, but the fact that a 20-hour multi-stage attack was completed even once without human intervention is itself a signal that a threshold has been crossed. Related research (arXiv 2603.11214) reports that this capability scales log-linearly with inference-time compute, with no plateau observed yet. The finding that performance can rise by as much as 59% when the token budget is scaled from 10 million to 100 million carries an uncomfortable implication: the more money and time you’re willing to burn, the higher the probability of completing an attack keeps climbing.

What the Benchmarks Reveal About the Capability Leap

This capability leap also shows up in individual benchmarks. According to OpenAI, GPT-5.6 scored 73.5% on ExploitBench2, an exploitation-capability evaluation, sharply outpacing GPT-5.5’s 47.9% at a comparable output token budget. That’s a jump of more than 25 percentage points in a single generation. Still, there’s nuance here too. OpenAI’s own testing suggests that GPT-5.6 is more skilled at finding and fixing vulnerabilities than at reliably carrying out an actual attack from start to finish. In other words, it’s fair to read this as the balance of capability still tilting toward defense for now.

This distinction matters for policy. The same model becomes a tool for mass vulnerability discovery and patching in a defender’s hands, and an intrusion automation engine in an attacker’s hands. Aardvark, an agentic security researcher that OpenAI separately unveiled, targets exactly this defensive use case. Aardvark was introduced as an autonomous agent that helps developers and security teams automatically find and fix vulnerabilities, and OpenAI made explicit that this capability should reach defenders first, above all else.

Defense Over Offense: OpenAI’s Layered Safety Stack

It’s in this same context that OpenAI didn’t open Sol to everyone from day one, instead releasing it in a limited way to a select set of trusted partners. Access is initially restricted to a curated group of customers, a decision OpenAI says came out of close coordination with the US government on a cybersecurity framework. It’s a signal that the more a capability is judged to have crossed a critical threshold, the more conservatively deployment gets throttled.

Multiple layers of defense have also been added on the technical side. According to the announcement, Sol and Terra now carry activation classifiers focused on sensitive domains that monitor the model during generation and intervene mid-stream to stop it the moment it starts producing a dangerous response. On top of that sits a model-level restriction that blocks prohibited cyber assistance at the source, real-time output monitoring via a misuse classifier, and account-level behavioral analysis that catches malicious patterns. Output isn’t delivered directly; it passes through review by a secondary reasoning system before it ever reaches the user. Below is a diagram summarizing this layered defense flow.

flowchart TB
    A[User request] --> B[Model-level restriction<br/>Block prohibited cyber assistance]
    B --> C[Activation classifier<br/>Monitor during generation, intervene mid-stream]
    C --> D[Real-time output monitoring<br/>Misuse classifier]
    D --> E[Secondary reasoning system review<br/>Pause before delivery]
    E --> F[Account-level behavioral analysis<br/>Detect malicious patterns]
    F --> G[Deliver response or block]
    F -.Anomalous pattern.-> H[Review, block, account action]

What stands out is that this structure isn’t a single filter. The inside of the model (activation classifier), the output boundary (misuse classifier), and the account layer (behavioral analysis) all watch from different vantage points, layered on top of one another. It’s defense in depth, designed so that if one layer misses something, the next layer catches it. And this exact idea transplants directly onto infrastructure providers.

Implications for ThakiCloud’s Products

The news that frontier models’ attack capability keeps rising, paradoxically, makes the case for on-premises and sovereign AI. As autonomous attacks become a reality, enterprises and public institutions want to keep “who called this model, what did they ask it to do, and what output did it return” under their own control. ThakiCloud’s ai-platform meets this need directly. On top of K8s- and Kueue-based GPU scheduling, it keeps models within the customer’s own cluster, serves them with multi-tenant isolation, and supports on-premises and sovereign deployment so that data never crosses an external boundary. The more sensitive the security workload, the greater the value of self-hosting, keeping model weights and inference traffic locked inside your own infrastructure. Lower serving costs are also a practical precondition that lets defenders run bulk, repetitive work like vulnerability scanning within an affordable budget.

At the agentic layer, Paxis’s design turns out to look strikingly similar to the layered safety stack described above. Paxis is the Agent-Native Cloud control plane that runs on top of ai-platform, treating Skills, Tools, Policies, and Audit Logs as first-class resources. Skills that an agent executes run in an isolated sandbox that doesn’t contaminate the host environment, every action passes through a policy gate before it’s carried out, and the entire process is recorded in an audit log. Just as OpenAI layered monitoring across the inside of the model, its output boundary, and the account level, Paxis separates skill selection (BM25 harness), execution (sandbox isolation), control (policy gates), and traceability (audit logs) into distinct layers. This structure prevents an autonomous agent from applying the wrong tool to the wrong target, and even if an incident does occur, it lets you trace back exactly what went wrong and where.

The two lenses complement each other. If ai-platform is the physical control that keeps the model inside your own boundary, Paxis is the logical control that binds the agent using that model to policy and logs. In an era where AI can autonomously execute a 32-step intrusion, the fundamentals of defense are no longer about picking the strongest model, but about running whatever model you use inside a controlled environment and keeping a record of its actions. That’s why on-premises deployment and an agentic control plane matter more now than ever.

Limitations and Counterarguments

In the interest of balance, let’s look at the other side too. First, Sol’s cybersecurity edge rests substantially on OpenAI’s own announcements, and because access is restricted, independent reproduction and verification remain insufficient. Benchmark numbers are shaped by the measurement conditions of whoever is presenting them, so until third-party evaluations accumulate, it’s safer to treat them only as directional signals.

Second, the observation that capability currently tilts toward defense is not grounds for reassurance. If log-linear scaling continues without a plateau, today’s defense-favoring balance could flip at any time simply from an increase in compute. The statement “it’s currently more skilled at defense than offense” is a snapshot of the present state, not a permanent safety guarantee.

Third, on-premises deployment, isolation, and policy gates aren’t free. Operating your own infrastructure demands upfront investment, specialized personnel, and an ongoing patching burden. For smaller organizations, the convenience of managed cloud may still be the rational choice. The point isn’t that on-premises is always the right answer, but that as workload sensitivity rises, the point at which the value of control and auditability outweighs the cost of convenience arrives sooner.

Finally, policy gates and audit logs are themselves imperfect. A defense stack becomes a target for bypass attempts, and jailbreak research against Sol is already underway. The meaning of defense in depth isn’t a promise of never being breached, it’s making sure that even if one layer is breached, the next layer catches it and the incident can be traced afterward. That modest goal is, in fact, the realistic defense design for this era.

Sources

• Original tweet (RT @OpenAI)

• [GPT-5.6: Frontier intelligence that scales with your ambition

  OpenAI](https://openai.com/index/gpt-5-6/)

• [Previewing GPT-5.6 Sol: a next-generation model

  OpenAI](https://openai.com/index/previewing-gpt-5-6-sol/)

• [GPT-5.6 Preview System Card

  OpenAI Deployment Safety Hub](https://deploymentsafety.openai.com/gpt-5-6-preview)

• Introducing Aardvark: OpenAI’s agentic security researcher

• [Our evaluation of OpenAI’s GPT-5.5 cyber capabilities

  AISI](https://www.aisi.gov.uk/blog/our-evaluation-of-openais-gpt-5-5-cyber-capabilities)

• [OpenAI Previews GPT-5.6 Sol With Restricted Access and Stronger Cyber Safeguards

  The Hacker News](https://thehackernews.com/2026/06/openai-limits-gpt-56-rollout-as-sol.html)

• [Measuring AI Agents’ Progress on Multi-Step Cyber Attack Scenarios

  arXiv 2603.11214](https://arxiv.org/html/2603.11214v2)

Overview

Image generation models have long been split into two camps. On one side sits a language model that understands text; on the other, a diffusion model that paints pixels. The Stable Diffusion family is the archetype: a text encoder interprets the prompt, a UNet or DiT strips noise away in latent space, and a VAE (variational autoencoder) reconstructs that latent back into pixels. Understanding and generation happen in different modules, in different representations.

日日新 SenseNova U1, which SenseTime has been rolling out since April 2026, flatly rejects that split. It removes both the visual encoder and the VAE, and instead pushes a NEO-Unify architecture that carries language and visual information through a single representation space end to end. Understanding, generation, editing, and interleaved generation - alternating between text and images in one stream - are all handled inside a single model. The weights are released under Apache 2.0, and at roughly 8B parameters the model runs on a single RTX 5090, which means commercial self-hosting is fair game.

This post lays out what SenseNova U1 actually is, what we can realistically deploy on-premise, and - just as important - why you can’t drop it straight into a familiar tool like Automatic1111. Since serving models across varied customer environments is ThakiCloud’s core business, the gap between the headline “open weights are out” and the reality of “we can put this on our cluster” is exactly what matters here.

What SenseNova U1 Is: What Dropping the VAE Actually Means

NEO-Unify starts from a simple observation: pixels and words are inherently deeply entangled, yet conventional pipelines force them apart. So U1 removes two intermediate converters entirely. There’s no visual encoder (VE) compressing images into features, and no VAE converting latents back into pixels. Instead, language and visual information are woven into a single composite representation and modeled end to end. SenseTime describes this as running on a native Mixture-of-Transformers (MoT), enabling efficient cross-modal reasoning without conflicts between modalities.

For users, this difference shows up as “one model does it all.” It understands images (VQA), generates images, edits images, and alternates between text and images within a single flow. A cooking tutorial or a travel diary - content that interleaves explanation and illustration - can be produced in one generation pass, which is the flagship example SenseTime highlights. On the spatial intelligence side, the model is said to understand complex layouts and object relationships, laying groundwork for embodied AI, where a robot completes perception, reasoning, and action within a single model down the line.

Below is a conceptual diagram placing the conventional SD-family pipeline side by side with U1’s unified pipeline.

flowchart TB
    subgraph SD["Conventional SD Family (Split)"]
        direction TB
        A1["Text prompt"] --> A2["Text encoder (CLIP)"]
        A2 --> A3["UNet / DiT (latent diffusion)"]
        A3 --> A4["VAE decoder"]
        A4 --> A5["Pixel image"]
    end
    subgraph U1["SenseNova U1 (NEO-Unify, unified)"]
        direction TB
        B1["Text / image input"] --> B2["Single unified representation space<br/>(no VE, no VAE)"]
        B2 --> B3["Native MoT transformer<br/>shared understanding / generation / editing"]
        B3 --> B4["Text / image / interleaved output"]
    end
    SD -.->|"3 modules, 2 representations"| GAP["Cost of separation:<br/>understanding and generation live in different representations"]
    U1 -.->|"1 module, 1 representation"| WIN["Benefit of unification:<br/>pixel-word correlation preserved"]

The key point is that U1 is not a diffusion checkpoint - it’s a unified transformer that behaves like an LLM. That single fact determines everything that follows about how it’s served and which tools it’s compatible with.

What’s Open Is U1 Lite, Not U1 Pro

There’s a distinction that has to be made clear here. U1 Pro, on SenseTime’s platform page (sensenova.cn), is the hosted commercial flagship. Its dense infographic and poster-generation demos are impressive, but this “Pro”-tier weight is not published on HuggingFace. It’s best treated as an API-only commercial tier.

What can actually be self-hosted is the U1 Lite series. The main open weights are:

The SFT models go through an understanding warm-up, generation pretraining, joint mid-training, and joint SFT; the final model then adds a round of T2I reinforcement learning on top of that. SenseTime describes what’s released today as “Lite” and has flagged a larger-scale version to come. In other words, the 8B/A3B currently in hand is the relatively compact version, and there’s still headroom above it.

To put it plainly: if a blog or demo says “we spun up U1 Pro,” that claim is inaccurate. What we’re deploying on-premise is the open U1-8B-MoT (or A3B).

Where It Sits on Benchmarks

SenseTime claims U1 is “SoTA within the open-source camp on both understanding and generation.” Evaluation was run on OneIG (EN/ZH), LongText (EN/ZH), BizGenEval (Easy/Hard), CVTG, IGenBench, and infographic-specific benchmarks. The model card emphasizes a quality-versus-generation-latency tradeoff chart, with the emphasis on hitting the same quality faster.

The numbers matter less than the character of the results. U1 Lite is presented as delivering commercial-grade results specifically in complex infographic generation - an area where layout consistency and text-rendering accuracy matter most. Some outlets report that U1 Lite’s output quality rivals Qwen-Image 2.0 Pro or Seedream 4.5, but since that’s a vendor/secondary-source claim, it should be treated as [estimated] and verified empirically. Our standard is simple: we only trust numbers we’ve measured ourselves, on our data, our prompts, our GPUs.

Installation and Serving: Two Paths

The fact that U1 is a unified transformer rather than a diffusion checkpoint shows up directly in how it’s served. It’s not something you bolt onto a diffusion UI - it’s served like an LLM.

Path 1: Native transformers. The official repo installs dependencies via uv and ships task-specific example scripts - separate ones for text-to-image, image editing, and interleaved generation.

# Image editing example (pixel-level editing works even without a VAE)
python examples/editing/inference.py \
  --model_path sensenova/SenseNova-U1-8B-MoT \
  --prompt "Change the animal's fur color to a darker shade." \
  --image examples/editing/data/images/1.webp \
  --cfg_scale 4.0 --img_cfg_scale 1.0 --num_steps 50 \
  --output output_edited.png --profile --compare

# Interleaved generation (narration and illustrations in one flow)
python examples/interleave/inference.py \
  --model_path sensenova/SenseNova-U1-8B-MoT \
  --prompt "Create a beginner-friendly illustrated tutorial for tomato and egg stir-fry." \
  --resolution "16:9" --output_dir outputs/interleave/ --stem demo

Path 2: vLLM-Omni serving. For demos or production, you need an OpenAI-compatible endpoint. vLLM-Omni officially supports U1 and offers both offline inference and online serving examples. For environments tight on VRAM, there’s also module-level CPU offload. The pipeline implements component discovery, moving the LLM to CPU during text/vision encoding steps and moving the vision encoder to CPU during the diffusion loop, minimizing the weights resident on GPU at any given moment.

# vLLM-Omni: text-to-image with CPU offload enabled
python end2end.py \
  --prompt "A cute cat sitting on a windowsill" \
  --width 2048 --height 2048 \
  --enable-cpu-offload --think

Low-VRAM options. The official repo also ships a single-GPU layer-offload mode (--vram_mode full|low|balanced) alongside GGUF quantized loading. Combining Q4 GGUF with balanced reportedly runs on consumer cards in the 10-12GB range. That puts deployment into three tiers: full on 24GB+ for maximum speed, GGUF + balanced when headroom is limited, and low when you need to squeeze the hardest.

Which Tools Work: ComfyUI Yes, A1111 No

The most common expectation is “just drop it into Stable Diffusion WebUI (Automatic1111) as a checkpoint.” The short answer is: that doesn’t work. A1111 is built to load only SD-family checkpoints composed of a UNet/DiT + VAE + CLIP text encoder. U1 is a unified MoT transformer with no VAE, so even placing the .safetensors file in the checkpoint folder won’t get you a successful load - it’s an architectural incompatibility, not a configuration issue.

If you want an interactive, hands-on prompting workflow, the practical replacement for A1111 is ComfyUI. A community custom node (smthemex/ComfyUI_SenseNova_U1) supports U1 natively, covering 8B-MoT, A3B-MoT, the 8-step LoRA, and GGUF.

The summary comes down to two axes: for hands-on interactive UI, use ComfyUI; for programmatic demo/production backends, use vLLM-Omni (OpenAI-compatible). If you were counting on A1111, you’ll need to switch tools.

The ThakiCloud Serving Angle

ThakiCloud’s ai-platform exists to serve models across varied customer environments on K8s, and SenseNova U1 is a particularly well-suited candidate through that lens.

First, its size is on-premise-friendly. At roughly 8B parameters, it resides in about 16-20GB in fp16, so a single RTX 4090, 5090, or A6000 is enough to stand up a serving pod, and A3B is even lighter. That fits well with how we already queue GPUs through Kueue and share them across multi-tenant workloads. Unlike large frontier models that demand 8xH200, real production workloads become viable with just one or two customer-owned GPUs.

Second, vLLM-Omni’s OpenAI-compatible endpoint lowers the cost of integration. Our Metis serving layer and demo pipelines are already built around an OpenAI-compatible interface, so U1 can be dropped in without standing up a separate diffusion stack. Unifying the image-generation API under the same observability and cost-metering framework as our text LLMs is a real operational win.

Third, Apache 2.0 plus fully self-hostable weights lines up precisely with sovereign and on-premise requirements. For public-sector and financial customers whose data must never leave their own infrastructure, an image-generation model that runs on domestic GPUs is a competitive advantage in its own right - and that advantage starts with lower serving cost.

There’s an agentic angle too. Paxis, ThakiCloud’s Agent-Native Cloud, runs skills in isolated sandboxes and routes every action through policy gates and audit logs. A self-hosted, unified image model like U1 is a natural fit to register as an “image generation tool” that agents can call. When infographic and poster generation is completed inside an in-house pod rather than an external API, low-cost serving (ai-platform) directly boosts the economics of the agent workflow (Paxis).

Limitations and Counterpoints

Fairness requires looking at the other side too. First, what’s currently open is Lite (8B/A3B), and the top-tier quality is likely reserved for the hosted U1 Pro. “Open SoTA” is a claim within the open-source camp, not a guarantee of parity with the best commercial models.

Second, the benefit of a unified architecture is also, in some sense, an ecosystem drawback. Because U1 isn’t SD, it doesn’t inherit years of accumulated A1111/SD workflow assets - ControlNet, the vast library of community LoRAs, inpainting extensions, and so on. Migrating an existing pipeline to U1 means rebuilding the tooling from scratch. ComfyUI nodes and a dedicated LoRA trainer exist, but the ecosystem is still early.

Third, most of the benchmark numbers are vendor self-reported, and Korean text rendering and prompt adherence in particular need independent verification. Whether the infographic strengths hold up in Korean typesetting is something we need to confirm ourselves, hands-on.

Fourth, low-VRAM modes aren’t free. CPU offload and layer streaming save VRAM at the cost of added latency from CPU-GPU transfers. For services where real-time responsiveness matters, running full mode on 24GB+ without offload is the better choice - and that translates directly into GPU cost.

Closing

SenseNova U1 is a concrete, open-weight demonstration of “unified multimodal without a VAE.” How far the approach of folding understanding and generation into one representation can go remains to be seen once a larger version ships, but even the current 8B/A3B is compelling enough as an on-premise serving candidate. In the next post, we’ll actually deploy this model on RunPod and our own demo pipeline, run vLLM-Omni serving and a ComfyUI workflow side by side, and share the numbers.

References

• Model card: sensenova/SenseNova-U1-8B-MoT
• Code/docs: OpenSenseNova/SenseNova-U1 (GitHub)
• Paper: SenseNova-U1: Unifying Multimodal Understanding and Generation with NEO-unify (arXiv:2605.12500)
• Serving: vLLM-Omni SenseNova-U1 example
• ComfyUI node: smthemex/ComfyUI_SenseNova_U1
• Hosted U1 Pro: SenseNova U1 Pro

무엇이 화제였나

칭화대 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 카드 한 장이 데이터센터 랙을 대체한다는 그림과는 결이 다릅니다.

그래서 실제로 몇 tok/s이고, 얼마인가

앞의 실험들은 메커니즘을 분해했지만, 정작 실무자가 궁금한 두 숫자를 빠뜨렸습니다. 24GB에 안 들어가는 진짜 대형 모델이 얼마나 빠르고, 돈은 얼마나 아끼는가. 그래서 24GB에도 80GB 한 장에도 안 들어가는 Qwen3-235B-A22B(Q4, 약 130GB)로 다시 쟀습니다. 오프로드가 선택이 아니라 필수인 케이스입니다.

먼저 속도입니다. 2×A100 80GB에 모델을 통째로 올리면 디코딩이 51.5 tok/s 나옵니다. 사람이 읽는 속도의 다섯 배가 넘으니 실시간 대화에 넉넉합니다. 그런데 같은 모델을 전문가만 CPU로 내리면 GPU가 쓰는 메모리는 11GB로 줄어듭니다. 235B짜리 모델이 GPU 11GB만 먹는다는 뜻입니다. 24GB는 물론이고 12GB 카드에도 올라갑니다. “24GB 한 장으로 되냐”는 질문의 답은 여기서 분명해집니다. 됩니다, 그것도 여유롭게.

문제는 그 오프로드 상태의 디코딩 속도입니다. 우리 측정 환경(RunPod 네트워크 스토리지에 130GB를 둔 구성)에서는 토큰마다 원격 저장소를 읽느라 값이 무너져서, 이 수치는 정직하게 공표하지 않습니다. 로컬 NVMe를 쓰는 실제 배포에서는 생기지 않는 병목이기 때문입니다. 대신 1차 실험에서 깨끗하게 잰 30B 오프로드가 12 tok/s였고, 활성 파라미터가 훨씬 큰 235B는 그보다 낮은 한 자릿수 초중반으로 떨어집니다. AMX 서버면 여기에 1.4배쯤 붙습니다. 정리하면 오프로드 디코딩은 실시간 대화에는 빠듯하고, 배치 처리나 에이전트처럼 지연에 덜 민감한 작업에 맞습니다.

이제 비용입니다. RunPod 실가 기준으로 토큰 100만 개당 비용을 계산하면 이렇습니다.

여기서 반직관적인 결론이 나옵니다. 오프로드는 토큰당 비용으로는 거의 아끼지 못하고, 경우에 따라 오히려 비쌉니다. 하드웨어가 다섯 배 싸지만 그만큼 느려서 토큰당으로 환산하면 상쇄되기 때문입니다. 그러니 “비용을 얼마나 세이브하느냐”에 대한 솔직한 답은, 운영비로는 별로 아끼지 못한다는 것입니다.

진짜 절약은 다른 곳에 있습니다. 초기 투자와 접근성입니다. 대당 1만 5천 달러짜리 A100 두 장을 사거나 시간당 3달러에 빌리지 못하는 팀이, 커모디티 24GB 카드 한 장과 램 넉넉한 서버 한 대로 671B급 모델을 아예 돌릴 수 있게 됩니다. 운영비를 깎아주는 도구가 아니라, “돌아가느냐 안 돌아가느냐”의 경계를 바꾸는 도구입니다.

그래서 도입해야 하나

세 가지 조건을 먼저 확인하길 권합니다. 서빙 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 위에서 끝까지 세워보는 것입니다.

왜 지연 예산이라는 관점이 필요한가

사람과 사람이 대화할 때 상대의 말이 끝나고 내가 반응하기까지의 간격은 언어에 상관없이 중앙값이 약 200밀리초로 수렴한다는 연구가 있습니다(Stivers 외, 2009, PNAS). 실시간 음성 에이전트가 “사람 같다”고 느껴지려면 발화 종료부터 첫 응답 소리까지가 이 구간에 가까워야 하고, 실무에서는 서브초, 즉 800밀리초 아래를 유지하는 것을 흔한 목표로 삼습니다. 이 숫자는 벤더가 공개한 목표와도 대체로 맞습니다. Deepgram은 300밀리초 미만, Vapi는 500밀리초 미만을 이야기합니다.

문제는 이 총예산을 어떻게 나눠 쓰느냐입니다. 네트워크가 왕복 40밀리초를 먹고, STT가 300밀리초, LLM 첫 토큰이 500밀리초를 쓰면 이미 예산이 초과됩니다. 어느 단계를 줄여야 가장 크게 이득인지 감으로 판단하기는 어렵습니다. 그래서 각 단계의 예상 지연을 넣으면 누적 타임라인과 병목, 그리고 자연스러운 대화 구간에 드는지 여부를 즉시 보여주는 계산기를 만들었습니다. 완전히 클라이언트 사이드로 동작하고, 서버도 API 키도 없으며, 입력은 브라우저를 벗어나지 않습니다. 특정 제품을 홍보하지 않는 공공재 도구를 지향했습니다.

도구는 발화 종료 감지, 네트워크 왕복, STT, LLM 첫 토큰, 첫 문장 생성, TTS 합성, 재생 버퍼의 일곱 단계를 다룹니다. 각 단계의 슬라이더 힌트에는 2025년부터 2026년까지의 공개 자료에서 뽑은 일반 범위가 붙어 있고, 병목이 그 범위를 넘으면 처방을 띄웁니다. 프리셋으로 시작점을 잡고, 비교 모드로 두 구성을 겹쳐 보고, 부하가 걸렸을 때의 대략적인 p95도 함께 보여줍니다.

자가호스팅이라면 숫자가 어떻게 바뀌나

관리형 스트리밍 API의 지연 범위는 문서로 어느 정도 알 수 있습니다. 그러나 “내 GPU에 직접 올리면 얼마가 나오는가”는 직접 재보지 않으면 알 수 없습니다. 그래서 RunPod에서 큰 GPU와 중간 GPU를 빌려 실제 엔진을 돌려봤습니다. 큰 GPU는 H200(141GB), 중간 GPU는 L40S(48GB)를 골랐고, 엔진은 LLM에 vLLM으로 Qwen2.5-7B-Instruct, STT에 faster-whisper-large-v3, TTS에 Kokoro-82M을 썼습니다. 큰 GPU에서는 배치를 최대한 채우려고 vLLM을 GPU 메모리 활용률 0.9, 최대 시퀀스 256으로 띄웠습니다.

측정 자체보다 먼저 정리하고 싶은 것은 비용을 아끼는 방식입니다. GPU pod마다 15기가바이트가 넘는 모델과 CUDA 휠을 매번 새로 내려받으면, 비싼 GPU가 다운로드를 기다리며 놀고 있는 시간에 요금이 붙습니다. 그래서 네트워크 볼륨 하나를 만들고, 볼륨을 붙일 수 있는 가장 싼 pod이 가상환경과 모델 가중치를 딱 한 번만 볼륨에 내려받게 했습니다. 그다음 H200과 L40S가 같은 볼륨을 마운트하면 재다운로드가 전혀 없습니다. 이 방식 덕분에 37.4기가바이트를 한 번만 받고, 두 GPU의 벤치가 각각 몇 분 만에 끝났습니다. 실험이 끝나면 pod과 볼륨을 전부 삭제하도록 teardown을 finally 블록과 이름 기반 안전망으로 보장했습니다. 전체 비용은 약 3.6달러였고, 누수된 자원은 없었습니다.

한 가지 실전 함정을 적어 둡니다. RunPod 네트워크 볼륨은 secure 클라우드 전용인 데다, 특정 호스트 풀에만 붙습니다. 볼륨 없이 잘 뜨는 GPU가 볼륨을 붙이면 용량 없음으로 실패하기도 합니다. 그래서 볼륨을 붙인 상태로 먼저 프로브를 돌려 실제 용량이 있는 조합을 찾아야 하고, 값싼 소비자용 GPU는 볼륨 호스트가 아닌 경우가 많아 다운로드 pod은 “볼륨을 붙일 수 있는 가장 싼 GPU”를 골라야 합니다.

측정 결과: LLM은 GPU에서 병목이 아니었다

가장 먼저 눈에 띈 것은 LLM의 첫 토큰 지연이 대단히 짧다는 점입니다. H200에서 단일 요청의 첫 토큰은 15밀리초 정도였고, 동시 50 요청에서도 78밀리초에 그쳤습니다. L40S는 단일 48밀리초, 동시 50에서 210밀리초였습니다. 두 GPU 모두 부하가 걸려도 첫 토큰이 서브초 안에 넉넉히 들어옵니다. 7B급 소형 모델을 스트리밍으로 서빙하는 한, LLM은 지연 사슬에서 가장 걱정할 단계가 아니라는 뜻입니다.

큰 GPU를 꽉 채웠을 때의 이점은 지연보다 동시성에서 드러났습니다. H200은 KV 캐시로 약 61배의 동시 스트림을 담았고, 활용률 0.9로 143기가바이트 중 125기가바이트를 실제로 썼습니다. L40S는 같은 모델에서 약 12배였습니다. 스트림당 비용으로 보면, 동시 사용자가 많은 서비스일수록 큰 GPU를 채워 쓰는 편이 유리하다는 계산이 나옵니다. 반대로 동시성이 낮은 서비스라면 L40S 한 장으로 충분합니다.

STT는 조금 더 조심스럽게 읽어야 합니다. faster-whisper는 단일 스트림에서 10초 오디오를 0.1초 남짓에 처리할 만큼 빨랐습니다. 실시간 계수(RTF)가 0.01 수준입니다. 그러나 스레드 동시성을 50까지 올리자 지연이 4초에서 5초로 급증했습니다. 한 장의 GPU에 요청을 무한정 밀어 넣으면 큐가 쌓인다는 뜻입니다. 실서비스에서는 요청을 배치로 묶거나, GPU당 동시성을 낮게 유지하며 복제본으로 확장하거나, 진짜 스트리밍 STT 래퍼로 부분 전사를 하는 식으로 풀어야 합니다. 단일 GPU 한 대에 동시성을 몰아 넣는 구성은 피해야 합니다.

정직한 공백: TTS는 이번에 채우지 못했다

TTS 엔진 Kokoro의 GPU 벤치는 이번에 얻지 못했습니다. 재실행 시점에 RunPod의 해당 GPU 재고가 소진되어 pod 프로비저닝이 계속 실패했기 때문입니다. 하네스 문제가 아니라 외부 용량 문제라 판단해, 같은 실패를 반복하며 요금을 태우기보다 벤치를 보류했습니다. 페이로드와 실행기는 저장소에 커밋해 두었으니 용량이 돌아오면 바로 재실행할 수 있습니다. 그때까지 도구와 서빙 가이드에서 TTS는 스트리밍 벤더의 공개 범위, 즉 Kokoro의 GPU 첫 오디오 지연 45에서 97밀리초 사이를 인용값으로 표시하고 그 사실을 명시했습니다. 참고로 로컬에서 비스트리밍으로 재본 VoxCPM2는 문장당 7.2초가 걸려 실시간 대화에는 부적합했는데, 이 값은 도구의 로컬 스택 프리셋이 그대로 보여줍니다. 스트리밍 엔진으로 바꾸는 것이 핵심이라는 점을 숫자로 확인하는 셈입니다.

어떻게 셋팅해서 서비스할까

측정을 서빙 레시피로 옮기면 이렇게 정리됩니다. vLLM으로 올린 소형 LLM, faster-whisper, 스트리밍 TTS를 같은 노드에 두어 네트워크 홉을 없애고, 첫 문장이 나오는 즉시 TTS를 시작하는 문장 단위 스트리밍을 씁니다. 동시성은 단계마다 성격이 다릅니다. LLM은 KV 캐시가 허용하는 범위까지 올려도 되지만, STT는 배치와 복제본으로 확장하는 편이 안전합니다. 서브초 목표라면 H200 단일 스트림 구성이 여유 있게 들어옵니다. 첫 토큰 15밀리초에 whisper 108밀리초, 여기에 스트리밍 TTS의 첫 오디오 60에서 150밀리초와 네트워크를 더해도 예산 안입니다.

이 모든 과정은 재현 가능하게 공개했습니다. 계산기는 브라우저에서 바로 열어 볼 수 있고, 벤치 하네스는 볼륨 생성부터 다운로드, GPU 벤치, 전체 삭제까지를 한 스크립트로 묶었습니다. 실측 결과 JSON과 서빙 가이드도 저장소에 함께 정리해 두었습니다. 자가호스팅 음성 스택의 지연을 감이 아니라 숫자로 이야기하고 싶은 분들에게 출발점이 되기를 바랍니다.

• 계산기: voice-latency-budget
• 저장소와 벤치 하네스, 서빙 가이드: github.com/sylvanus4/voice-latency-budget

이 소식이 ThakiCloud 같은 인프라 회사에 남 이야기일 수 없는 이유는 분명합니다. 프런티어 모델의 공격 능력이 올라갈수록, 방어의 무게 중심은 “어떤 모델이 더 똑똑한가”에서 “그 모델을 어디에서, 누구의 통제 아래, 어떤 감사 기록을 남기며 돌리는가”로 이동합니다. 모델은 어차피 계속 강해집니다. 그렇다면 승부처는 실행 환경의 격리와 정책 게이트, 그리고 사후 추적 가능성입니다. 오늘 글은 GPT-5.6 Sol이 실제로 무엇을 해냈는지 확인된 사실만으로 짚은 뒤, 그 능력이 왜 온프렘 주권 AI와 에이전트 통제 평면의 수요를 오히려 키우는지로 이어가려 합니다.

GPT-5.6 Sol은 무엇이고 왜 사이버 보안이 초점인가

GPT-5.6은 OpenAI가 2026년 7월 9일 공개한 모델 패밀리입니다. 능력 순으로 루나(Luna), 테라(Terra), 솔(Sol) 세 등급이 있고, Sol이 가장 강력한 플래그십입니다. OpenAI는 Sol을 Cerebras 인프라 위에서 초당 최대 750토큰까지 서빙한다고 밝혀, 능력만이 아니라 처리 속도까지 함께 끌어올렸다는 점을 강조했습니다.

이번 발표에서 가장 두드러진 축은 사이버 보안입니다. OpenAI는 Sol을 자사 역대 가장 강력한 사이버 보안 모델로 규정하면서, 취약점 연구와 익스플로잇을 포함한 장기 호흡의 보안 작업에서 성능과 효율의 경계를 옮겼다고 설명합니다. 핵심은 “적은 토큰으로 더 멀리 간다”입니다. 같은 결과를 내기 위해 소모하는 추론 토큰이 줄었다는 것은, 같은 예산으로 더 많은 공격 시도를 자동화할 수 있다는 뜻이기도 합니다. 능력의 향상이 곧 비용의 하락으로 번역되는 구간에서, 방어자와 공격자 모두에게 문턱이 낮아집니다.

한 가지 정직하게 짚을 부분이 있습니다. 트윗의 원문은 OpenAI의 자체 발표이고, 뒤에서 다룰 “The Last Ones” 레인지의 독립 평가(영국 AI 안전연구소 AISI)는 공개 시점 기준으로 GPT-5.5까지를 대상으로 삼았습니다. 따라서 Sol의 “새 기록” 주장은 OpenAI가 제시한 수치이며, 제3자 재현 결과가 완전히 공개되기 전까지는 발표자의 주장으로 읽는 것이 안전합니다. 이 글은 검증 가능한 수치와 발표 주체를 구분해 인용합니다.

“The Last Ones”: 32단계 사이버 레인지가 측정하는 것

“The Last Ones”는 AISI가 운영하는 모의 기업 네트워크 침투 시나리오입니다. 총 32단계로 구성되어 있고, 숙련된 인간 전문가가 처음부터 끝까지 완수하는 데 약 20시간이 걸리는 것으로 추정됩니다. 단순한 문제 풀이가 아니라, 실제 침해에 필요한 여러 능력을 한 줄기로 엮어야 통과하는 구조입니다. 에이전트는 시스템을 장악하고, 프로토콜과 암호 인증을 역공학으로 뜯어보고, 제어기를 조작하는 일련의 과정을 스스로 판단하며 이어가야 합니다.

지금까지 이 레인지를 끝까지 완주한 모델은 손에 꼽습니다. Claude Mythos 프리뷰가 열 번 시도 중 세 번(3/10) 완주로 처음 성공했고, GPT-5.5가 열 번 중 두 번(2/10)으로 두 번째로 끝까지 밟았습니다. 시도 대비 성공률이 낮아 보이지만, 20시간짜리 다단계 공격을 사람 개입 없이 한 번이라도 완주했다는 사실 자체가 임계선을 넘은 신호입니다. 관련 연구(arXiv 2603.11214)는 이 능력이 추론 시점 연산량에 로그-선형으로 비례하며 아직 정체 구간이 관측되지 않는다고 보고합니다. 토큰 예산을 1천만에서 1억으로 늘리면 성능이 최대 59% 오른다는 결과는, 돈과 시간을 더 태울수록 공격 완주 확률이 계속 올라간다는 불편한 함의를 담고 있습니다.

벤치마크가 보여주는 능력 도약

능력의 도약은 개별 벤치마크에서도 드러납니다. OpenAI에 따르면 GPT-5.6은 익스플로잇 능력 평가인 ExploitBench2에서 73.5%를 기록해, 비슷한 출력 토큰 예산에서 GPT-5.5의 47.9%를 크게 앞섰습니다. 한 세대 만에 25%포인트 넘게 오른 수치입니다. 다만 여기에도 결이 있습니다. OpenAI 자신의 테스트는 GPT-5.6이 실제 공격을 끝까지 신뢰성 있게 수행하는 것보다, 취약점을 찾아내고 고치는 쪽에 더 능하다는 점을 시사합니다. 즉 능력의 무게추가 아직은 방어 쪽에 유리하게 기울어 있다는 해석이 가능합니다.

이 구분은 정책적으로 중요합니다. 같은 모델이 방어자의 손에 들리면 취약점을 대량으로 발굴해 패치하는 도구가 되고, 공격자의 손에 들리면 침투 자동화 엔진이 됩니다. OpenAI가 별도로 공개한 에이전트형 보안 연구원 Aardvark가 바로 이 방어 쪽 활용을 겨냥합니다. Aardvark는 개발자와 보안팀이 취약점을 자동으로 발견하고 고치도록 돕는 자율 에이전트로 소개되었고, OpenAI는 이 능력이 무엇보다 방어자에게 먼저 도달해야 한다는 우선순위를 명시했습니다.

공격보다 방어: OpenAI의 다층 안전 스택

OpenAI가 Sol을 처음부터 전면 개방하지 않고 신뢰할 수 있는 일부 파트너에게만 제한적으로 푼 것도 이 맥락입니다. 접근은 초기에 선별된 고객으로 한정되며, 사이버 보안 프레임워크를 두고 미국 정부와 긴밀히 협의하는 과정에서 나온 결정이라고 설명합니다. 능력이 임계선을 넘었다고 판단될수록 배포는 보수적으로 조인다는 신호입니다.

기술적으로도 여러 겹의 방어가 얹혔습니다. 발표에 따르면 Sol과 Terra에는 민감 영역에 초점을 둔 활성화 분류기가 새로 붙어, 생성 도중 모델을 감시하다가 위험한 답변을 만들기 시작하면 중간에 개입해 멈춥니다. 여기에 금지된 사이버 지원을 원천 차단하는 모델 수준 제한, 오용 분류기를 이용한 실시간 출력 모니터링, 악성 패턴을 잡아내는 계정 단위 행동 분석이 더해집니다. 출력은 곧바로 전달되지 않고 2차 추론 시스템의 검토를 거친 뒤에야 사용자에게 도달합니다. 아래는 이 다층 방어의 흐름을 정리한 것입니다.

flowchart TB
    A[사용자 요청] --> B[모델 수준 제한<br/>금지된 사이버 지원 차단]
    B --> C[활성화 분류기<br/>생성 중 감시·중간 개입]
    C --> D[실시간 출력 모니터링<br/>오용 분류기]
    D --> E[2차 추론 시스템 검토<br/>전달 전 일시정지]
    E --> F[계정 단위 행동 분석<br/>악성 패턴 탐지]
    F --> G[응답 전달 또는 차단]
    F -.이상 패턴.-> H[검토·차단·계정 조치]

주목할 지점은 이 구조가 단일 필터가 아니라는 데 있습니다. 모델 안쪽(활성화 분류기), 출력 경계(오용 분류기), 계정 층위(행동 분석)가 서로 다른 관점에서 겹겹이 감시합니다. 하나가 놓쳐도 다음 층이 잡도록 설계된 심층 방어입니다. 그리고 바로 이 발상이 인프라 사업자에게 그대로 이식됩니다.

ThakiCloud 제품 적용 시사점

프런티어 모델의 공격 능력이 올라간다는 뉴스는 역설적으로 온프렘과 주권 AI의 손을 들어줍니다. 자율 공격이 현실이 될수록, 기업과 공공은 “누가 이 모델을 호출했고 무엇을 시켰으며 어떤 출력을 받았는가”를 자기 통제 아래 두려 합니다. ThakiCloud의 ai-platform은 이 요구에 정확히 맞물립니다. K8s와 Kueue 기반 GPU 스케줄링 위에서 모델을 고객 클러스터 안에 두고, 멀티테넌트로 격리해 서빙하며, 데이터가 외부 경계를 넘지 않도록 온프렘과 소버린 배포를 지원합니다. 민감한 보안 워크로드일수록 모델 가중치와 추론 트래픽을 자기 인프라 안에 붙잡아 두는 self-hosting의 가치가 커집니다. 낮은 서빙 비용은 방어자가 취약점 스캔 같은 대량 반복 작업을 감당 가능한 예산으로 돌리게 해 주는 실질적 전제이기도 합니다.

에이전트 차원에서는 Paxis의 설계가 위에서 본 다층 안전 스택과 놀랍도록 닮아 있습니다. Paxis는 ai-platform 위에서 도는 Agent-Native Cloud 제어 평면으로, Skills와 Tools, Policies, Audit Logs를 일급 리소스로 다룹니다. 에이전트가 실행하는 스킬은 격리된 샌드박스에서 돌아 호스트 환경을 오염시키지 않고, 모든 행동은 정책 게이트를 통과한 뒤에야 수행되며, 그 전 과정이 감사 로그로 남습니다. OpenAI가 모델 안팎과 계정 층위에 걸쳐 감시망을 겹쳐 둔 것처럼, Paxis는 스킬 선택(BM25 하니스), 실행(샌드박스 격리), 통제(정책 게이트), 추적(감사 로그)을 서로 다른 층으로 분리해 둡니다. 자율 에이전트가 잘못된 도구를 잘못된 대상에 쓰지 못하도록 막고, 사고가 나더라도 무엇이 어디에서 어긋났는지 소급할 수 있게 하는 구조입니다.

두 렌즈는 서로를 보완합니다. ai-platform이 모델을 내 경계 안에 붙잡아 두는 물리적 통제라면, Paxis는 그 모델을 쓰는 에이전트의 행동을 정책과 로그로 묶는 논리적 통제입니다. AI가 32단계 침투를 자율로 밟는 시대에, 방어의 기본기는 강한 모델을 고르는 일이 아니라 어떤 모델이든 통제된 환경에서 돌리고 그 행적을 남기는 일이 됩니다. 이것이 온프렘과 에이전트 통제 평면이 지금 더 중요해지는 이유입니다.

한계 및 반론

균형을 위해 반대편도 짚겠습니다. 첫째, Sol의 사이버 보안 우위는 상당 부분 OpenAI의 자체 발표에 근거하며, 접근이 제한되어 있어 독립적 재현 검증이 아직 충분치 않습니다. 벤치마크 숫자는 발표자의 측정 조건에 좌우되므로, 제3자 평가가 쌓이기 전까지는 방향성 신호로만 받아들이는 편이 안전합니다.

둘째, 능력이 방어에 더 유리하게 기울어 있다는 관측이 곧 안심의 근거는 아닙니다. 로그-선형 스케일링이 정체 없이 이어진다면, 오늘 방어 우위인 균형이 연산량 증가만으로 언제든 뒤집힐 수 있습니다. “지금은 공격보다 방어에 능하다”는 서술은 현재 상태의 스냅숏이지 항구적 안전 보장이 아닙니다.

셋째, 온프렘과 격리, 정책 게이트는 공짜가 아닙니다. 자체 인프라 운영은 초기 투자와 전문 인력, 지속적 패치 부담을 요구합니다. 규모가 작은 조직에는 관리형 클라우드의 편의가 여전히 합리적 선택일 수 있습니다. 요점은 온프렘이 항상 정답이라는 게 아니라, 워크로드의 민감도가 높아질수록 통제와 감사 가능성의 가치가 편의 비용을 넘어서는 지점이 앞당겨진다는 것입니다.

마지막으로, 정책 게이트와 감사 로그 자체도 완벽하지 않습니다. 방어 스택은 우회 시도의 대상이 되며, 실제로 Sol에 대한 탈옥 연구도 이미 진행되고 있습니다. 다층 방어의 의미는 뚫리지 않는다는 약속이 아니라, 뚫리더라도 다음 층이 잡고 사후에 추적할 수 있게 한다는 데 있습니다. 그 겸손한 목표가 오히려 지금 시대의 현실적인 방어 설계입니다.

출처

• 원 트윗 (RT @OpenAI)

• [GPT-5.6: Frontier intelligence that scales with your ambition

  OpenAI](https://openai.com/index/gpt-5-6/)

• [Previewing GPT-5.6 Sol: a next-generation model

  OpenAI](https://openai.com/index/previewing-gpt-5-6-sol/)

• [GPT-5.6 Preview System Card

  OpenAI Deployment Safety Hub](https://deploymentsafety.openai.com/gpt-5-6-preview)

• Introducing Aardvark: OpenAI’s agentic security researcher

• [Our evaluation of OpenAI’s GPT-5.5 cyber capabilities

  AISI](https://www.aisi.gov.uk/blog/our-evaluation-of-openais-gpt-5-5-cyber-capabilities)

• [OpenAI Previews GPT-5.6 Sol With Restricted Access and Stronger Cyber Safeguards

  The Hacker News](https://thehackernews.com/2026/06/openai-limits-gpt-56-rollout-as-sol.html)

• [Measuring AI Agents’ Progress on Multi-Step Cyber Attack Scenarios

  arXiv 2603.11214](https://arxiv.org/html/2603.11214v2)

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

먼저 오르는 쪽부터 보겠습니다. 디지털데일리의 ‘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 보안 솔루션 고도화

개요

이미지 생성 모델은 오랫동안 두 갈래로 갈라져 있었습니다. 한쪽에는 텍스트를 이해하는 언어 모델이 있고, 다른 한쪽에는 픽셀을 그리는 확산(diffusion) 모델이 있었습니다. Stable Diffusion 계열이 대표적입니다. 텍스트 인코더가 프롬프트를 해석하고, UNet 또는 DiT가 잠재 공간에서 노이즈를 걷어내고, VAE(변분 오토인코더)가 그 잠재값을 다시 픽셀로 복원합니다. 이해와 생성이 서로 다른 모듈에서 서로 다른 표현으로 일어나는 구조입니다.

상탕(SenseTime)이 2026년 4월부터 순차 공개한 日日新 SenseNova U1은 이 분리를 정면으로 부정합니다. 비주얼 인코더와 VAE를 모두 없애고, 언어와 시각 정보를 하나의 표현 공간에서 끝까지 다루는 NEO-Unify 아키텍처를 내세웁니다. 이해, 생성, 편집, 그리고 텍스트와 이미지를 번갈아 쏟아내는 인터리브 생성까지 단일 모델 안에서 처리합니다. 가중치는 Apache 2.0으로 풀렸고, 8B급이라 RTX 5090 한 장이면 돌아갑니다. 상업적 자체 호스팅이 허용된다는 뜻입니다.

이 글은 SenseNova U1이 무엇인지 팩트로 정리하고, 우리가 온프렘에서 실제로 무엇을 얹을 수 있는지, 그리고 흔히 기대하는 Automatic1111 같은 기존 도구에 왜 그대로 올릴 수 없는지까지 솔직하게 리뷰합니다. ThakiCloud는 다양한 고객 환경에서 모델을 서빙하는 것을 업으로 삼기 때문에, “오픈 가중치가 나왔다”는 헤드라인과 “우리 클러스터에 올릴 수 있다”는 현실 사이의 간격을 짚는 것이 핵심입니다.

SenseNova U1은 무엇인가: VAE를 버린다는 것의 의미

NEO-Unify의 출발점은 단순한 관찰입니다. 픽셀과 단어는 본래 깊게 얽혀 있는데, 기존 파이프라인은 이를 억지로 분리해 왔다는 것입니다. 그래서 U1은 두 개의 중간 변환기를 통째로 제거합니다. 이미지를 특징으로 압축하던 비주얼 인코더(VE)도 없고, 잠재값을 픽셀로 되돌리던 VAE도 없습니다. 대신 언어와 시각 정보를 하나의 복합 표현으로 엮어 끝에서 끝까지 모델링합니다. 상탕은 이를 네이티브 MoT(Mixture-of-Transformers) 위에서 돌려, 모달리티 간 추론을 충돌 없이 효율적으로 수행한다고 설명합니다.

이 차이는 사용자 입장에서 “한 모델이 다 한다”로 드러납니다. 이미지를 이해하고(VQA), 이미지를 생성하고, 이미지를 편집하고, 텍스트와 이미지를 한 흐름 안에서 번갈아 만들어 냅니다. 요리 튜토리얼이나 여행 일기처럼 설명과 삽화가 교차하는 콘텐츠를 한 번의 생성으로 뽑을 수 있다는 것이 대표 사례로 제시됩니다. 공간 지능(spatial intelligence) 쪽에서도 복잡한 레이아웃과 물체 간 관계를 이해한다고 강조하는데, 이는 향후 로봇이 인식·추론·실행을 한 모델에서 완결하는 임베디드 AI로 이어지는 포석입니다.

아래는 기존 SD 계열 파이프라인과 U1의 통합 파이프라인을 나란히 놓은 개념도입니다.

flowchart TB
    subgraph SD["기존 SD 계열 (분리형)"]
        direction TB
        A1["텍스트 프롬프트"] --> A2["텍스트 인코더 (CLIP)"]
        A2 --> A3["UNet / DiT (잠재 확산)"]
        A3 --> A4["VAE 디코더"]
        A4 --> A5["픽셀 이미지"]
    end
    subgraph U1["SenseNova U1 (NEO-Unify 통합형)"]
        direction TB
        B1["텍스트 · 이미지 입력"] --> B2["단일 통합 표현 공간<br/>(VE 없음 · VAE 없음)"]
        B2 --> B3["네이티브 MoT 트랜스포머<br/>이해 · 생성 · 편집 공유"]
        B3 --> B4["텍스트 · 이미지 · 인터리브 출력"]
    end
    SD -.->|"모듈 3개, 표현 2종"| GAP["분리의 비용:<br/>이해와 생성이 다른 표현"]
    U1 -.->|"모듈 1개, 표현 1종"| WIN["통합의 이득:<br/>픽셀-단어 상관 보존"]

핵심은 U1이 확산 체크포인트가 아니라, LLM처럼 동작하는 통합 트랜스포머라는 점입니다. 이 사실 하나가 뒤에 나올 서빙 방식과 도구 호환성을 전부 결정합니다.

오픈된 것은 U1 Pro가 아니라 U1 Lite 시리즈입니다

여기서 반드시 짚어야 할 구분이 있습니다. 상탕 플랫폼 페이지(sensenova.cn)의 U1 Pro는 호스티드 상용 플래그십입니다. 고밀도 인포그래픽과 포스터 생성 데모가 인상적이지만, 이 “Pro” 등급 가중치는 HuggingFace에 올라와 있지 않습니다. API로만 접근하는 상용 티어로 보는 것이 맞습니다.

자체 호스팅이 가능한 것은 U1 Lite 시리즈입니다. 오픈된 주요 가중치는 다음과 같습니다.

SFT 모델은 이해 웜업 → 생성 사전학습 → 통합 중간학습 → 통합 SFT를 거치고, 최종 모델은 여기에 T2I 강화학습을 한 번 더 얹어 얻습니다. 상탕은 오늘 공개한 것은 “Lite”이며 더 큰 규모의 버전을 예고했습니다. 즉 지금 손에 쥔 8B/A3B는 비교적 컴팩트한 버전이고, 상한은 아직 열려 있습니다.

정리하면, 블로그나 데모에서 “U1 Pro를 띄웠다”고 말하면 부정확합니다. 우리가 온프렘에 올리는 대상은 오픈된 U1-8B-MoT(또는 A3B)입니다.

벤치마크상 위치

상탕은 U1을 “오픈소스 진영에서 이해와 생성 양쪽 모두 SoTA”라고 주장합니다. 평가는 OneIG(EN/ZH), LongText(EN/ZH), BizGenEval(Easy/Hard), CVTG, IGenBench, 그리고 인포그래픽 벤치마크 위에서 이뤄졌습니다. 모델카드는 성능 대 생성 지연(latency) 트레이드오프 그래프를 강조하는데, 같은 품질을 더 빠르게 뽑는 쪽에 방점이 있습니다.

숫자를 그대로 인용하기보다 성격을 봐야 합니다. U1 Lite는 특히 복잡한 인포그래픽 생성, 즉 레이아웃 일관성과 텍스트 렌더링 정확도가 중요한 영역에서 상용급 결과를 낸다고 소개됩니다. 일부 매체는 U1 Lite의 출력 품질이 Qwen-Image 2.0 Pro나 Seedream 4.5에 견줄 만하다고 전하지만, 이는 벤더·2차 출처 기준이므로 [추정]으로 두고 실측으로 검증할 대상입니다. 우리 기준은 하나입니다. 우리 데이터와 우리 프롬프트로 우리 GPU에서 돌려 본 수치만 신뢰합니다.

설치와 서빙: 두 갈래 경로

U1이 확산 체크포인트가 아니라 통합 트랜스포머라는 사실은 서빙에서 그대로 드러납니다. 확산 UI에 얹는 게 아니라, LLM처럼 서빙합니다.

경로 1: transformers 네이티브. 공식 리포는 uv로 의존성을 깔고 태스크별 예제 스크립트를 제공합니다. 텍스트-투-이미지, 이미지 편집, 인터리브 생성이 각각 있습니다.

# 이미지 편집 예시 (VAE가 없어도 픽셀 단위 편집이 됩니다)
python examples/editing/inference.py \
  --model_path sensenova/SenseNova-U1-8B-MoT \
  --prompt "Change the animal's fur color to a darker shade." \
  --image examples/editing/data/images/1.webp \
  --cfg_scale 4.0 --img_cfg_scale 1.0 --num_steps 50 \
  --output output_edited.png --profile --compare

# 인터리브 생성 (설명 + 삽화를 한 흐름으로)
python examples/interleave/inference.py \
  --model_path sensenova/SenseNova-U1-8B-MoT \
  --prompt "토마토 계란 볶음 초보자용 삽화 튜토리얼을 만들어줘." \
  --resolution "16:9" --output_dir outputs/interleave/ --stem demo

경로 2: vLLM-Omni 서빙. 데모나 제품에 붙이려면 OpenAI 호환 엔드포인트가 필요합니다. vLLM-Omni가 U1을 공식 지원하며, 오프라인 추론과 온라인 서빙 예제를 모두 제공합니다. VRAM이 빠듯한 환경을 위해 모듈 단위 CPU 오프로드도 있습니다. 파이프라인이 컴포넌트 디스커버리를 구현해, 텍스트·비전 인코딩 단계에서는 LLM을 CPU로 내리고 확산 루프에서는 비전 인코더를 CPU로 내리는 식으로 GPU에 상주하는 가중치를 최소화합니다.

# vLLM-Omni: CPU 오프로드를 켠 텍스트-투-이미지
python end2end.py \
  --prompt "A cute cat sitting on a windowsill" \
  --width 2048 --height 2048 \
  --enable-cpu-offload --think

저VRAM 옵션. 공식 리포는 단일 GPU 레이어 오프로드 모드(--vram_mode full|low|balanced)와 GGUF 양자화 로딩을 함께 제공합니다. Q4 GGUF와 balanced를 조합하면 10~12GB급 소비자 카드에서도 돌릴 수 있다고 안내합니다. 즉 배치는 세 단계로 나뉩니다. 최고 속도가 필요하면 24GB 이상에서 full, 여유가 없으면 GGUF + balanced, 극단적으로 아끼려면 low입니다.

어떤 툴과 쓰는가: ComfyUI는 되고 A1111은 안 됩니다

가장 흔한 기대가 “Stable Diffusion WebUI(Automatic1111)에 체크포인트로 올려 쓰자”입니다. 결론부터 말하면 그건 안 됩니다. A1111은 UNet/DiT + VAE + CLIP 텍스트 인코더로 이뤄진 SD 계열 체크포인트만 로드하도록 설계돼 있습니다. U1은 VAE가 없는 통합 MoT 트랜스포머이므로, .safetensors를 체크포인트 폴더에 넣어도 로드 자체가 성립하지 않습니다. 구조가 다르기 때문에 생기는 근본적인 비호환입니다.

인터랙티브하게 손으로 프롬프트를 넣고 뽑고 싶다면, A1111의 실질적 대체는 ComfyUI입니다. 커뮤니티가 만든 커스텀 노드(smthemex/ComfyUI_SenseNova_U1)가 U1을 네이티브로 지원하며, 8B-MoT·A3B-MoT·8스텝 LoRA·GGUF를 모두 다룹니다.

요약하면 두 축입니다. 사람이 만지는 인터랙티브 UI는 ComfyUI, 프로그램이 호출하는 데모·제품 백엔드는 vLLM-Omni(OpenAI 호환)입니다. A1111을 기대했다면 도구 선택을 바꿔야 합니다.

ThakiCloud 서빙 관점

ThakiCloud의 ai-platform은 K8s 위에서 다양한 고객 환경에 모델을 서빙하는 것을 업으로 삼습니다. SenseNova U1은 이 렌즈에서 특히 다루기 좋은 후보입니다.

첫째, 크기가 온프렘 친화적입니다. 8B급은 fp16 기준 대략 16~20GB면 상주하므로 RTX 4090, 5090, A6000 한 장으로 서빙 파드를 세울 수 있고, A3B는 더 가볍습니다. Kueue로 GPU를 큐잉하고 멀티테넌트로 나눠 쓰는 우리 방식과 잘 맞습니다. 대형 프론티어 모델처럼 8xH200을 요구하지 않으므로, 고객사 자체 GPU 한두 장으로도 실전 워크로드가 성립합니다.

둘째, vLLM-Omni의 OpenAI 호환 엔드포인트가 통합 비용을 낮춥니다. 우리 Metis 서빙 계층과 데모 파이프라인은 이미 OpenAI 호환 인터페이스를 전제로 붙기 때문에, U1을 별도 확산 스택 없이 그대로 얹을 수 있습니다. 이미지 생성 API를 텍스트 LLM과 같은 관측·비용 계량 체계 아래로 통일한다는 점이 실무적 이득입니다.

셋째, Apache 2.0과 완전한 자체 호스팅은 소버린·온프렘 요구에 정확히 부합합니다. 데이터가 외부 API로 나가지 않아야 하는 공공·금융 고객에게, 국내 GPU 위에서 도는 이미지 생성 모델은 그 자체로 경쟁력입니다. 낮은 서빙 비용에서 나오는 경쟁력도 여기서 시작됩니다.

에이전트 관점도 열립니다. ThakiCloud의 Agent-Native Cloud인 Paxis는 스킬을 격리 샌드박스에서 실행하고 모든 행동을 정책 게이트와 감사 로그로 통과시키는데, U1처럼 자체 호스팅되는 통합 이미지 모델은 에이전트가 호출하는 “이미지 생성 툴”로 등록하기에 적합합니다. 인포그래픽·포스터 생성을 외부 API 없이 사내 파드로 완결하면, 저비용 서빙(ai-platform)이 에이전트 워크플로의 경제성(Paxis)을 그대로 끌어올립니다.

한계와 반론

균형을 위해 반대편도 봐야 합니다. 첫째, 지금 오픈된 것은 Lite(8B/A3B)이고 최상급 품질은 호스티드 U1 Pro에 있을 가능성이 큽니다. “오픈 SoTA”라는 표현은 오픈소스 진영 안에서의 비교이지, 상용 최상위 모델과 동급이라는 보장이 아닙니다.

둘째, 통합 아키텍처의 이점은 곧 생태계의 단점이기도 합니다. U1은 SD가 아니므로 ControlNet, 방대한 커뮤니티 LoRA, 인페인팅 확장 등 수년간 축적된 A1111/SD 워크플로 자산을 그대로 물려받지 못합니다. 기존 파이프라인을 U1으로 이관하려면 도구 체계를 새로 짜야 합니다. ComfyUI 노드와 자체 LoRA 트레이너가 있지만 생태계 성숙도는 아직 초기입니다.

셋째, 벤치마크 수치는 대부분 벤더 자기보고이며, 특히 한국어 텍스트 렌더링과 프롬프트 준수는 별도 검증이 필요합니다. 인포그래픽의 강점이 한글 조판에서도 유지되는지는 우리가 직접 돌려 봐야 확인됩니다.

넷째, 저VRAM 모드는 공짜가 아닙니다. CPU 오프로드와 레이어 스트리밍은 VRAM을 아끼는 대신 CPU-GPU 전송으로 지연을 늘립니다. 실시간성이 중요한 서비스라면 오프로드 없이 24GB급에서 full로 돌리는 편이 낫고, 이는 곧 GPU 비용으로 돌아옵니다.

마무리

SenseNova U1은 “VAE를 버린 통합 멀티모달”이라는 방향을 오픈 가중치로 실증한 사례입니다. 이해와 생성을 한 표현으로 묶는 접근이 얼마나 멀리 갈지는 더 큰 버전이 나와 봐야 알겠지만, 지금의 8B/A3B만으로도 온프렘 서빙 후보로는 충분히 매력적입니다. 다음 글에서는 이 모델을 RunPod과 우리 데모 파이프라인에 실제로 얹어, vLLM-Omni 서빙과 ComfyUI 워크플로를 나란히 돌려 본 결과를 수치와 함께 정리하겠습니다.

참고 링크

• 모델카드: sensenova/SenseNova-U1-8B-MoT
• 코드/문서: OpenSenseNova/SenseNova-U1 (GitHub)
• 논문: SenseNova-U1: Unifying Multimodal Understanding and Generation with NEO-unify (arXiv:2605.12500)
• 서빙: vLLM-Omni SenseNova-U1 예제
• ComfyUI 노드: smthemex/ComfyUI_SenseNova_U1
• 호스티드 U1 Pro: SenseNova U1 Pro