كيف جعلنا واجهة برمجة تطبيقات تحويل النص إلى كلام مجانية: الهندسة البرمجية للاستدلال خلف S2.1 Pro

ملخص سريع (TL;DR)

• أصبح Fish Audio S2.1 Pro متاحًا الآن كـ واجهة برمجة تطبيقات مجانية لتحويل النص إلى كلام: 83 لغة، لا يوجد سقف استخدام صارم، اسم النموذج هو s2.1-pro-free. الوصول المجاني متاح لفترة أولية؛ وسنقوم بالإبلاغ عن أي تغييرات بإشعار مسبق. لمزيد من المعلومات، اطلع هنا.
• أدى تحسين الاستدلال الشامل إلى زيادة سعة الطلبات لكل وحدة معالجة رسومات بمقدار 4 أضعاف: نفس عبء العمل الذي كان يتطلب سابقاً أربعة وحدات H200 يعمل الآن على وحدة واحدة فقط.
• العوامل الرئيسية: كيرنلات CUDA مخصصة (أسرع بـ 2.1–4.3 مرة من cuBLAS في أشكال فك التشفير)، الدفعات المتصلة (زيادة الإنتاجية بمقدار 52 ضعفًا c=1→64)، رفع معدل استخدام وحدة معالجة الرسومات من ~50% إلى ~90%+.
• نفس الحزمة البرمجية تدعم واجهة برمجة تطبيقات استنساخ الصوت الخاصة بنا — نفس أوزان النموذج، نفس البنية التحتية، مع تضمين الفئة المجانية. يعتمد S2.1 Pro على Fish Speech، نموذجنا الأساسي مفتوح الأوزان.
• مكتبة الكيرنل الأساسية fish-scales-ops مفتوحة المصدر.

اكتشف لماذا ينتقل المطورون من المنصات الأخرى ← ابدأ البناء مجانًا

يوليو 2026 | أعادت Fish Audio بناء حزمة الاستدلال وجعلت S2.1 Pro مجانًا لكل مطور

السبب الحقيقي وراء تكلفة الذكاء الاصطناعي الصوتي

يواجه استدلال الذكاء الاصطناعي الصوتي مشكلة هيكلية لا توضحها صفحات التسعير: فك التشفير ذاتي الانحدار (autoregressive decode) بطبيعته غير ملائم لاستخدام وحدة معالجة الرسومات (GPU).

كل استدعاء لواجهة برمجة تطبيقات TTS يقوم بتشغيل حلقة فك تشفير تولد رموزاً صوتية (tokens) واحداً تلو الآخر. كل خطوة هي عملية ضرب مصفوفة صغيرة — M ≤ 128 في الممارسة العملية — يتبعها قراءة ذاكرة لـ KV cache لهذا التسلسل. تظل نوى CUDA خاملة في الغالب بينما ينتظر نظام الذاكرة الفرعي اللحاق بها. في وحدة H200 التي تبلغ تكلفتها 30 ألف دولار، أنت تدفع مقابل الحوسبة ولكنك تستهلكها في توقفات الذاكرة (memory stalls).

في حالات التزامن المنخفض، يزداد الأمر سوءاً. حلقة فك التشفير لطلب واحد تشغل وحدة معالجة الرسومات في نبضات مدتها 10-20 ميكروثانية يفصل بينها عبء جدولة. يمكن أن يقل استخدام وحدة معالجة الرسومات في نقطة نهاية TTS يتم خدمتها بشكل ساذج عند c=1 عن 10%. الأجهزة موجودة، لكن العمل لا يملأها.

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

إليك ما تطلبه ذلك.

التحسين الشامل: الحزمة الكاملة

لا يوجد تغيير واحد يمنحك تحسيناً في الكفاءة بمقدار 4 أضعاف. جاءت المكاسب من تحسين كل طبقة في وقت واحد وتركها تتضاعف:

• كيرنلات CUDA مخصصة — القضاء على هدر الحوسبة لكل رمز.
• تكميم FP8 — خفض ضغط عرض نطاق الذاكرة إلى النصف.
• الدفعات المتصلة (Continuous batching) — ملء وحدة معالجة الرسومات عبر الطلبات المتزامنة.
• جدولة وحدة معالجة الرسومات — القضاء على السعة الخاملة بين أعباء العمل.
• امتلاك الشبكة والتخزين — إزالة هوامش ربح البنية التحتية السحابية.

يتم وصف كل طبقة أدناه. أرقام الإنتاجية والتكلفة في النهاية هي نتاج كل هذه العوامل معاً.

كيرنلات CUDA مخصصة: fish-scales-ops

لماذا لم تكن cuBLAS كافية؟

أشكال فك التشفير في خدمة TTS (M ≤ 128) ليست هي الأشكال التي تم تحسين cuBLAS أو كيرنلات GEMM في PyTorch أو حتى torch.compile من أجلها. تستهدف تلك المكتبات التدريب والملء المسبق للدفعات الكبيرة — حيث تكون M بالآلاف. عند القيم الصغيرة لـ M، فإنها لا تستغل عرض نطاق الذاكرة بالكامل وتفوت فرص الدمج (fusion) التي تظهر فقط في أحجام دفعات فك التشفير.

الفجوة المحددة: بالنسبة لـ SwiGLU MLP forward عند M=1 (فك تشفير طلب واحد)، تطلق cuBLAS scaled_mm ثلاث عمليات إطلاق كيرنل منفصلة — التنشيط، ضرب البوابة، الإسقاط لأسفل — مع كتابة النتائج الوسيطة وقراءتها من HBM بين كل منها. عند M=1، تكون هذه الرحلة ذهاباً وإياباً هي عنق الزجاجة، وليس الحوسبة.

لقد قمنا ببناء fish-scales-ops لسد هذه الفجوة: وهي مكتبة FP8 GEMM و FlashAttention من الدرجة الإنتاجية تستهدف بنى NVIDIA Hopper (H200, sm_90a) و Blackwell (sm_120a)، وهي مفتوحة المصدر.

استراتيجية تكميم FP8

قمنا بتنفيذ مخططي تكميم لأجيال الأجهزة المختلفة:

bsgemm (128×128 block-scaled FP8) لوحدات H200/Hopper. يمنح قياس الكتلة (Block scaling) بدقة 128×128 استقراراً عددياً جيداً دون مخاطر دقة التكميم لكل موتر (per-tensor quantization).

mxfp8 (1×32, OCP UE8M0 format) لوحدات Blackwell (RTX 5090, RTX 6000 PRO). القياس الدقيق (Microscaling) مع أسس مشتركة لـ 32 عنصراً — وهو معيار OCP MX — يمنح دقة عددية أكثر تفصيلاً بالمقاييس التي تهم توليد الرموز الصوتية.

استغرق أحد الأخطاء غير الواضحة في مسار mxfp8 وقتاً طويلاً في تصحيح الأخطاء: قام quantize_blockscale.py بتجسيد موترات weight_scale باستخدام .contiguous() للتوافق مع safetensors، لكن linear_mxfp8_raw يقرأ المقاييس بخطوة K-major (1, N). أدى تحميل row-major متصل [N, K/128] إلى جعل كل GEMM ينتج logits غير صحيحة بأقصى سرعة للكيرنل — انهار وضع أخذ العينات لاحقاً إلى رمز دلالي واحد متكرر، وهو ما يبدو وكأنه مشكلة في جودة النموذج ولكنه في الواقع خطأ في تخطيط الذاكرة. كان الإصلاح هو إعادة التخطيط في MXFP8LinearMethod.process_weights_after_loading. بعد الإصلاح، يتطابق فك التشفير الجشع (greedy decode) مع bf16 بدقة الرموز في أول خمسة إطارات صوتية.

نتائج قياس الكيرنل

في أشكال فك التشفير (M ≤ 128)، أظهرت الاختبارات الداخلية على أجهزة مماثلة — المنهجية الكاملة في مستودع fish-scales-ops:

• يتفوق مسار MXFP8 على torch.nn.functional.scaled_mm في 8 من أصل 10 أشكال مربعة من 1024³ إلى 16384³، بزيادة تصل إلى +21%
• معالجة Qwen3-4B SwiGLU MLP شاملة: 1.7–6.2 مرة أسرع من cuBLAS الخام scaled_mm عند كل M من 1 إلى 4096
• مقارنة بـ cuBLAS المدمج مع torch.compile في أشكال فك التشفير: 2.1–4.3 مرة أسرع
• MXFP8 FlashAttention على sm_120a: 7–19 مرة أسرع من فك تشفير PyTorch SDPA، و 1.2–2.7 مرة أسرع من FlashInfer BF16

الكيرنلان المدمجان اللذان يحققان معظم المكاسب: أحدهما يدمج تكميم التنشيط + UE8M0 scale-pack في عملية إطلاق واحدة؛ والآخر يدمج مقدمة SwiGLU مباشرة في تكميم تنشيط down-GEMM، مما يلغي كتابة وقراءة وسيطة كاملة لـ BF16 كان PyTorch سيقوم بها بين العمليتين.

هندسة استدلال الدفعات: المفاضلة بين زمن الانتقال والإنتاجية

الدفعات المتصلة لـ TTS ذاتي الانحدار

كفاءة الكيرنل تحسن تكلفة كل رمز. التجميع في دفعات (Batching) هو ما يحول كفاءة الرمز الواحد إلى استخدام فعلي لوحدة معالجة الرسومات عبر تدفق الطلبات.

الدفعات الساكنة (Static batching) — حشو جميع التسلسلات لتكون بنفس الطول، وتشغيلها كدفعة ثابتة — تهدر الحوسبة على الحشو وتحظر الطلبات الجديدة حتى ينتهي أبطأ تسلسل في الدفعة. بالنسبة لـ TTS مع أطوال مخرجات متغيرة، تكون عقوبة زمن انتقال الذيل (tail latency) كبيرة.

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

DualAR: قيود التجميع الخاصة بـ S2

تولد بنية DualAR في S2.1 Pro رموزاً صوتية على مرحلتين — كتب الرموز الخشنة تليها كتب الرموز الدقيقة — مع نافذة previous_tokens منزلقة تشترط كل خطوة. هذا يخلق قيداً للصحة لا تملكه دفعات LLM القياسية: يتطلب كيرنل prev_tokens_shift_inplace عقداً صارماً للشكل ونوع البيانات (prev int32 [bs, W, cw], next_tokens int32 [bs, cw]). أي تعديل في الشكل — .unsqueeze()، ترقية نوع البيانات الضمنية — يفسد النافذة وينتج صوتاً رديئاً يصعب تمييزه عن تراجع جودة النموذج.

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

نتائج الإنتاجية

H200، bsgemm FP8، مسح التزامن:

تتوسع الإنتاجية بمقدار ~52 ضعفاً من c=1 إلى c=64، بينما يزيد TTFB بمقدار 36.6 ميللي ثانية — من 73 إلى 110 ميللي ثانية. تقوم وحدة معالجة الرسومات بـ 52 ضعف العمل مقابل عقوبة زمن انتقال غير محسوسة في معظم أعباء العمل الإنتاجية.

عند c=64، تحافظ وحدة H200 واحدة على 8,006 رمز/ثانية. هذا الرقم هو الآلية المباشرة وراء الفئة المجانية: المزيد من الإنتاجية لكل وحدة معالجة رسومات يعني تكلفة أقل لكل طلب.

هذه هي الأرقام التي تعمل خلف كل استدعاء مجاني لواجهة برمجة التطبيقات. ابدأ البناء ←

وضع الوقت الحقيقي: النهج الهندسي لأعباء العمل منخفضة زمن الانتقال

بالنسبة لعملاء الصوت وتطبيقات تبادل الأدوار، نوفر نقطة نهاية منفصلة للوقت الحقيقي محسنة للوقت حتى أول قطعة صوتية (TTFA) بدلاً من إجمالي الإنتاجية.

القرار المعماري الأساسي: يحدث الملء المسبق (prefill) عند فتح الاتصال، بعيداً عن مسار زمن الانتقال الحرج تماماً. يبدأ توقيت زمن انتقال البث عند إرسال أول قطعة صوتية، وليس عند إنشاء الاتصال. هذا يعني أن تكلفة الملء المسبق، والتي تتوسع مع طول النص، لا تظهر في رقم TTFA على الإطلاق.

على مستوى الجدولة، يعمل تصميم pingpong على تشغيل فك التشفير والملء المسبق في خيوط (threads) منفصلة دون عائق مضيف لكل دورة. إزالة العائق هي التحسين الأساسي لـ TTFA عند c≥4: في التنفيذ الساذج، تؤدي المزامنة من جانب المضيف بعد كل خطوة فك تشفير إلى تسلسل ما يجب أن يكون عملاً متزامناً. تعالج حلقة فك التشفير المتسلسلة ونقل ذاكرة H200 المثبتة مشكلة TTFB والتقطع عند التزامن العالي.

التصميم الكامل وتفاصيل زمن الانتقال موجودة في arXiv:2603.08823.

التحقق من الجودة: كيف تأكدنا من أن التحسين لم يفسد الصوت

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

لقد رصدنا حالة واحدة من هذا أثناء تطوير mxfp8: أنتج خطأ تخطيط الأوزان الموصوف أعلاه خطأ logit بنسبة ~53% بينما كان زمن انتقال الكيرنل طبيعياً تماماً. ظهر التراجع فقط في تحليل الرموز الناتجة، وليس في أي مقياس أداء.

يحتوي خط أنابيب التحقق الخاص بنا على بوابتين:

بوابة الصحة (Correctness gate): يجب أن يتطابق فك التشفير الجشع بعد التكميم مع bf16 بدقة الرموز في أول خمسة إطارات صوتية لمدخل مرجعي ثابت. رصد التطابق التام في الرموز في الإطارات الأولى يكشف فساد الـ logits المنهجي — إذا أنتج النموذج المكمم توزيعات احتمالية مختلفة، فسوف ينحرف عن bf16 فوراً عند المدخلات الحتمية.

بوابة تراجع الأداء (Performance regression gate): يجب أن يظل decode_tps لكل طلب ضمن نطاق 5% من أرقام الخط الأساسي المجمدة عند كل نقطة تزامن. أي تغيير يقلل الإنتاجية بأكثر من 5% عند أي تزامن — c=1، c=16، c=64 — يتطلب تبريراً صريحاً قبل الدمج. تحمي هذه البوابة من إصلاحات الصحة التي قد تضيف مزامنة صامتة إلى حلقة فك التشفير.

تعمل كلتا البوابتين مع كل تغيير في حزمة الاستدلال. النتيجة: أوزان نموذج S2.1 Pro Free مطابقة للفئة المدفوعة، ويتم التحقق من مسار الخدمة المكمم مقابل الخط الأساسي غير المكمم في كل عملية نشر.

استنساخ الصوت على نطاق واسع: لماذا تهم كفاءة الاستدلال

لقد كان استنساخ الصوت في Fish Audio دائماً مجانياً — ويظل، حسب تقييمنا الخاص وتعليقات المطورين، الأقوى في فئته. ثبات المتحدث عبر 83 لغة، والنبرة الطبيعية، والأداء المستقر عبر اللهجات ليست ميزات أضفناها للفئة المدفوعة. إنها الخط الأساسي. يعتمد S2.1 Pro على Fish Speech S2 Pro، نموذجنا الأساسي مفتوح الأوزان الذي تم إصداره في وقت سابق من هذا العام.

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

ثلاثة تحسينات تهم بشكل خاص لاستنساخ الصوت:

تكميم FP8 يحافظ على اشتراطات المتحدث. التحقق من صحة تطابق الرموز — الذي يرصد فساد مستوى logit — يتحقق مباشرة من أن التكميم لا يقلل من جودة إشارة تضمين المتحدث. ثبات المتحدث في المخرجات المستنسخة يطابق خط أساس bf16.

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

توسيع الإنتاجية بمقدار 52 ضعفاً يجعل التوليد الضخم ممكناً. عند 8,006 رمز/ثانية على وحدة H200 واحدة، يصبح توليد مكتبات صوتية مستنسخة كبيرة — كتب صوتية، حوارات ألعاب، محتوى محلي على نطاق واسع — ممكناً اقتصادياً ضمن الفئة المجانية.

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

استنسخ صوتاً في أقل من 60 ثانية ← جرب مجانًا

البنية التحتية لوحدة معالجة الرسومات: امتلاك الحزمة كاملة

الأجهزة والمشتريات

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

بالنسبة للاستدلال، نقوم بتشغيل أسطول مختلط. تتعامل H200 SXM5 مع الخدمة الإنتاجية ذات التزامن العالي حيث تسود إنتاجية bsgemm FP8 الإجمالية. وتخدم بطاقات RTX 5090 و RTX 6000 PRO (sm_120a) نقاط نهاية الحافة — عند c=64، تحقق 5090 mxfp8 سرعة 5,869 رمز/ثانية، أي حوالي 71% من إنتاجية H200 bsgemm بتكلفة أجهزة أقل بكثير لكل بطاقة.

تطلب نشر sm_120a إصلاحاً واحداً غير واضح: أدى حد cuda_graph_max_bs = 24 الأصلي لوحدات معالجة الرسومات سعة 32 جيجابايت إلى انخفاض حاد في الإنتاجية عند التزامن العالي — انخفض c=32 إلى ~31 رمز/ثانية/طلب، و c=64 إلى ~35 رمز/ثانية/طلب. أدى رفع الحد إلى min(max_running_requests, 64) إلى استعادة منحنى الإنتاجية الكامل. المشكلة الكامنة: كان التقاط مخطط CUDA عند bs=24 يترك وحدة معالجة الرسومات غير مستغلة بالكامل في أحجام دفعات فك التشفير التي تظهر فعلياً عند c=32+.

جدولة وحدة معالجة الرسومات: القضاء على السعة الخاملة

يبلغ معدل استخدام وحدة معالجة الرسومات في المجموعة المخصصة للاستدلال فقط حوالي 50%. حركة مرور الاستدلال متقطعة بطبيعتها؛ وتظل وحدة معالجة الرسومات خاملة خلال ساعات غير الذروة، وبين فترات التدريب، وأثناء مراحل تحميل البيانات.

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

ترتيب الأولوية: الاستدلال > التنظيف في مجموعة K8s؛ التدريب > التنظيف في Slurm. يستخدم المقياس التلقائي (autoscaler) في جانب الاستدلال إشارات حركة المرور الحقيقية — وليس الاستدلال القائم على الوقت — لذا يتم طرد وظائف التنظيف بمجرد ارتفاع الحمل.

النتيجة: ارتفع استخدام وحدة معالجة الرسومات من ~50% إلى ~90%+. على مستوى المجموعة، يقلل هذا الفرق التكلفة الفعلية لكل طلب استدلال إلى النصف تقريباً — ميزانية الأجهزة ثابتة، ولكن يتم خدمة ضعف عدد الطلبات مقابلها.

البنية التحتية للشبكة

نحن ندير شبكتنا الخاصة: شراء عرض نطاق ترددي مباشر من مزودي خدمة الإنترنت، ASN، اتصال بسرعة 300 جيجابت في الثانية، واتصال مباشر (peering) مع Cloudflare. هناك تأثيران للتكلفة بالنسبة لـ TTS على وجه الخصوص.

حركة البيانات الخارجة (Egress) بمقياس TTS ليست هينة. تسعير الخروج لدى مزودي السحاب ذو هامش ربح عالٍ؛ امتلاك طبقة الشبكة يزيل هذا الهامش تماماً.

زمن الانتقال هو السبب الثاني. كل ميللي ثانية من رحلة الشبكة تظهر في زمن TTFB الذي يشعر به المستخدم. يضع الاتصال المباشر مع Cloudflare نقاط نهاية Fish Audio قريباً من المستخدمين الموجهين عبر شبكة Cloudflare — وهي جزء كبير من حركة مرور واجهة برمجة التطبيقات العالمية. النشر في مراكز بيانات متعددة يعني أن معظم الطلبات تصل إلى عقدة استدلال قريبة دون عبور الإنترنت العام بالكامل.

التخزين: بنية متدرجة

بيانات التدريب، ونقاط فحص النموذج، وذاكرة التخزين المؤقت للاستدلال لها أنماط وصول ومتطلبات تكلفة مختلفة. نحن نستخدم بنية من ثلاث طبقات:

• الساخنة (Hot - NVMe flash): بيانات التدريب النشطة، أوزان النموذج للخدمة.
• الدافئة (Warm - mixed flash/HDD): نقاط الفحص الحديثة، مجموعات البيانات المعالجة مسبقاً.
• الباردة (Cold - self-hosted Ceph HDD cluster): بيانات التدريب التاريخية، التخزين طويل الأمد.

حلت الطبقة الباردة محل التخزين الكائني التابع لجهات خارجية للبيانات الضخمة. تعني طبقة التخزين المؤقت المحلية أمام التخزين البارد أن القراءات المتكررة — الشائعة في خطوط أنابيب بيانات التدريب — يتم خدمتها من NVMe بدلاً من HDD البارد.

النتيجة: ما تنتجه هذه الحزمة

عبر جميع الطبقات:

• كيرنلات FP8 مخصصة: أسرع بـ 2.1–4.3 مرة من cuBLAS القياسية في أشكال فك التشفير.
• الدفعات المتصلة: توسع الإنتاجية بمقدار 52 ضعفاً من c=1 إلى c=64، مع زيادة 37 ميللي ثانية في زمن الانتقال.
• جدولة وحدة معالجة الرسومات: استخدام ~50% ← ~90%+، مما يقلل التكلفة لكل طلب إلى النصف تقريباً.
• البنية التحتية المملوكة: إزالة هوامش الربح السحابية من الحوسبة والشبكة والتخزين.

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

كيف تقارن حزمة استدلال Fish Audio بغيرها

بيانات البنية التحتية بناءً على الوثائق المتاحة علنًا ومستودعات GitHub ومدونات الهندسة حتى يونيو 2026.

النمط ثابت: Fish Audio هو المزود الرئيسي الوحيد لـ TTS الذي وثق علناً بنية الاستدلال الخاصة به، وفتح مصدر مكتبة الكيرنل الخاصة به، ونشر أرقام إنتاجية ملموسة. "غير معلن" ليس انتقاداً — بل هو ملاحظة لما يمكن التحقق منه. للحصول على تقييم مستقل لجودة الصوت عبر المزودين، راجع مقارنة مزودي TTS العمياء.

ما هو مفتوح المصدر

fish-scales-ops متاح الآن: FP8 GEMM و FlashAttention لبنى Hopper و Blackwell، بجودة إنتاجية، وآمن لالتقاط مخطط CUDA.

إذا كنت تبني بنية تحتية للاستدلال للنماذج ذاتية الانحدار على H200 أو RTX 5090/6000 PRO، فإن فجوة أداء فك التشفير مقارنة بالمكتبات القياسية حقيقية والكيرنلات موجودة لسدها.

ما تحتويه المكتبة:

• FP8 GEMM: bsgemm (1×128 act × 128×128 wgt) لـ Hopper؛ MXFP8 1×32 (OCP UE8M0) لـ Blackwell.
• MXFP8 FlashAttention لـ sm_120a: ملء مسبق متصل، ملء مسبق بصفحات (توسيع)، فك تشفير بصفحات مع GQA أصلي عبر بث stride-0 K/V.
• آمن لالتقاط مخطط CUDA بالكامل.

الخطوات التالية

دعم B300 مدرج في خارطة الطريق. ستدفع نوى تنسور FP8 الأصلية وعرض نطاق NVLink 5 على Blackwell منحنى الإنتاجية إلى أبعد من ذلك.

يستمر تحسين الاستدلال. أرقام القياس المجمدة هي بوابة تراجع، وليست هدفاً نهائياً. كل نقطة تزامن هي تحدٍ يجب التغلب عليه.

المزيد من حزمة الخدمة مرشح ليكون مفتوح المصدر مع استقراره — تعديلات sglang_lite، منطق التجميع الخاص بـ DualAR، معالجة مخطط CUDA لـ sm_120a. البنية التحتية التي تجعل الفئة المجانية مستدامة هي نفس البنية التحتية التي نود أن يبني عليها المجتمع.

البدء مع واجهة برمجة تطبيقات TTS المجانية

اسم النموذج: s2.1-pro-free. تغيير واحد في الترويسة (header) عن أي استدعاء حالي لواجهة برمجة تطبيقات Fish Audio.

python

import httpx

body = {
    "text": "مرحباً بالعالم!",
    "reference_id": "your_model_id",
    "format": "mp3",
}

with httpx.Client() as client:
    res = client.post(
        "https://api.fish.audio/v1/tts",
        headers={
            "Authorization": "Bearer <YOUR_API_KEY>",
            "Content-Type": "application/json",
            "model": "s2.1-pro-free",
        },
        json=body,
    )

res.raise_for_status()

with open("output.mp3", "wb") as f:
    f.write(res.content)

JavaScript

import { writeFile } from "fs/promises";

const body = {
  text: "مرحباً بالعالم!",
  reference_id: "your_model_id",
  format: "mp3",
};

const res = await fetch("https://api.fish.audio/v1/tts", {
  method: "POST",
  headers: {
    Authorization: "Bearer <YOUR_API_KEY>",
    "Content-Type": "application/json",
    model: "s2.1-pro-free",
  },
  body: JSON.stringify(body),
});

if (!res.ok) {
  throw new Error(`TTS request failed: ${res.status} ${await res.text()}`);
}

const buffer = Buffer.from(await res.arrayBuffer());
await writeFile("output.mp3", buffer);

83 لغة. لا يوجد سقف استخدام صارم. لا بطاقة ائتمان مطلوبة. استنساخ الصوت متضمن.

كل واجهات برمجة تطبيقات TTS المتطورة الأخرى تفرض رسوماً من الرمز الأول. S2.1 Pro لا تفعل ذلك.

استنسخ صوتاً في أقل من 60 ثانية ←

وثائق واجهة برمجة التطبيقات الكاملة ←