AI за анализи в реално време получава тласък под 50 ms
28.4x е най-голямата разлика в латентността при пускането на RIPL от Liquid AI, обявено на 22 октомври 2026 г.: в собствените тестове на компанията един модел с 1.2B параметъра е постигнал 155.8 ms p95 спрямо 4,431 ms p95 за Qwen3.5-0.8B на vLLM. За корпоративните екипи, които следят AI за анализи в реално време, това е важно, защото подсказва, че генеративните модели може да навлизат в пътища за заявки, които досега бяха запазени за класически системи. Според публикацията на MarkTechPost за обявяването, водещото твърдение е за крайни отговори под 50 ms за някои live production натоварвания.
Това не означава, че всяка заявка изведнъж става достатъчно бърза за плащания, търсене или проверки за измами. Означава обаче, че разговорът за латентността се променя. Ако отчетените от доставчика показатели издържат при тестове от страна на купувачите, през 2027 г. дебатът може да се измести от това дали генеративните модели изобщо се вписват в live decision системи към това кои натоварвания оправдават разходите за внедряване и експлоатация.
Liquid AI пуска RIPL за live request paths
Обявяването на Liquid AI е тясно фокусирано, но стратегически важно. RIPL, съкратено от Real-time Inference Pipeline, е създаден да обслужва Liquid Foundation Models в рамките на live request path, а не в batch режими или при дълго работещи agent workflows. Компанията твърди, че при някои внедрявания може да върне завършени отговори end-to-end за под 50 ms, докато трафикът продължава и при пиково натоварване.
И хардуерният таргет е ясен. Liquid позиционира RIPL за enterprise внедрявания върху NVIDIA H100, H200, B200 и RTX PRO 6000 GPU, като публикуваните бенчмаркове са изпълнени на един B200. Това е важно, защото твърденията за латентност често са трудни за сравнение между различни serving stack среди, освен ако хардуерният профил не е изрично посочен. Материалите на NVIDIA за Blackwell platform дават контекст защо доставчиците вече натискат по-силно върху икономиката на продукционния inference, а не само върху обучението на модели.
Практическото послание към купувачите е просто: компанията не продава на първо място гъвкавост за general-purpose serving. Тя продава поведение с ниска латентност за конкретни продукционни пътища, където всеки допълнителен интервал от 50 до 100 милисекунди може да влияе върху приходите, процента на одобрение или отпадането на потребители.
Защо милисекундите имат по-голямо значение от размера на модела в продукция
В enterprise системите ключовият въпрос рядко е дали един модел е достатъчно „умен“ в абстрактен план. Въпросът е дали решението пристига в рамките на твърд бюджет. Search reranking, fraud checks, payment authorization и adtech query rewriting не могат да си позволят чакане от по няколко секунди. Именно затова класическите модели все още доминират в много от тези системи.
Позиционирането на Liquid AI е убедително именно по тази точка. Много open serving stack среди, включително vLLM, са оптимизирани около throughput, batching и по-широка поддръжка на модели. Това са полезни цели, но не са същото като обслужване на модел в critical path на взаимодействие с клиент.
Споменаването на Shopify е показателно, защото приземява темата в продукционна релевантност. Liquid твърди, че Shopify внедрява LFM в latency-sensitive commerce натоварвания, включително search enhancement с inference под 20 ms. Shopify отделно е документирала как скоростта на търсене влияе върху резултатите в електронната търговия в своя engineering ecosystem, а по-широки retail изследвания като данните на Google за mobile latency и conversion отдавна показват, че забавянията се натрупват бързо.
За екипите, които оценяват архитектурни избори, AI-powered data analytics dashboards е полезен съседен модел за внедряване: техническото предизвикателство не е само качеството на модела, а как анализите, сигналите и продукционните решения остават бързи при live натоварване.
Какво всъщност показват числата от бенчмарковете
Най-силната част от обявяването е конкретиката в таблицата с бенчмаркове. Най-слабата част е, че числата са самоотчетени. И двете твърдения могат да са верни едновременно.
Ето основните данни, които Liquid публикува за p95 end-to-end латентност на един B200 при open-loop Poisson arrivals:
| Workload | RIPL latency | vLLM baseline | Reported gap |
|---|---|---|---|
| 1B class, 32 in → 32 out | 34.6 ms | 498 ms | 14.4x |
| 1B class, 256 in → 128 out | 155.8 ms | 4,431 ms | 28.4x |
| 2B class, 32 in → 32 out | 76.4 ms | 586.8 ms | 7.7x |
| 2B class, 256 in → 128 out | 449.1 ms | 2,499 ms | 5.6x |
Три числа се открояват.
- 34.6 ms p95 при 1,000 заявки в секунда е най-важният резултат от търговска гледна точка, защото попада в диапазон, който вече изглежда приложим за adtech и някои search edge cases.
- 155.8 ms p95 все още е над водещото твърдение за под 50 ms, но остава релевантен за workflows като risk scoring или assisted decisioning, където 150 ms са приемливи, а 4 секунди — не.
- Спадът от предимство 28.4x до 5.6x при по-дълги 2B-class натоварвания напомня, че дължината на prompt-а и размерът на output-а все още определят икономиката.
Точно тук enterprise купувачите трябва да запазят баланс. Според изходната публикация на Liquid AI, предадена от MarkTechPost, изглежда RIPL изпреварва vLLM дори когато работи със същия модел LFM2.5-350M, което подсказва, че самият engine допринася за подобрението. Но сравнението все пак е рамкирано от доставчика — с различни семейства модели, различни design choices и затворен enterprise engine от едната страна.
С какво RIPL се различава от стандартен serving stack
Същественото твърдение не е само, че моделите LFM2.5 са бързи. То е, че RIPL оптимизира целия път на заявката — от постъпването ѝ до завършения отговор. Това е архитектурно твърдение, а не просто бенчмарк на модел.
Liquid описва LFM2.5 като хибридно семейство, смесващо double-gated convolution blocks с grouped-query attention blocks. На теория това е важно, защото inference с ниска латентност често е резултат от натрупване на инженерни решения: path за генериране на токени, движение на паметта, поведение на scheduler-а, управление на опашките и архитектура на модела. MLPerf Inference benchmarks неведнъж показват, че системната производителност рядко се обяснява само с теглата на модела.
За enterprise AI интеграциите това е по-интересният сигнал. Много екипи все още възприемат генеративния inference като проблем по избор на модел. На практика продукционният резултат зависи също толкова от serving architecture, допусканията за concurrency и управлението на откази. Добър модел в грешния stack пак може да не покрие бизнес SLA.
Кои enterprise workflows са най-подходящи за RIPL
Шестте примерни натоварвания в обявяването разказват по-ясна история от самото headline твърдение. Liquid свързва RIPL с adtech query rewriting, search intent classification, search reranking, payments risk scoring, credit decisioning и генериране на alt text за изображения. Това не са демонстрации за показ. Това са решения, близки до приходите, с тесни времеви бюджети.
Съвпадението е най-силно там, където са налице две условия: заявката е достатъчно кратка, за да се държи латентността под контрол, и бизнес ползата от генеративното reasoning е по-висока от това, което вече дава класическият модел. Това е особено релевантно за AI във fintech и AI fraud detection, където по-богатият контекст може да подобри качеството на решението, но само ако моделът върне резултат достатъчно бързо, за да запази throughput.
Полезен начин да се прочете списъкът е според толеранса към латентност:
- 20 до 30 ms бюджети: search intent classification и reranking изглеждат правдоподобни само за малки, силно оптимизирани натоварвания.
- 50 ms бюджети: adtech rewriting и payments risk scoring са истинският тест за AI за анализи в реално време.
- 100 до 150 ms бюджети: alt text за изображения и credit decisioning разширяват търговския аргумент, дори без водещото твърдение за под 50 ms.
Тази разбивка обяснява и защо обявяването е по-важно за e-commerce, payments и adtech, отколкото за екипи, които работят с по-бавни вътрешни copilots. Ако пътят на трафика е customer-facing и с голям обем, спестяването на стотици милисекунди има оперативна стойност. Ако workflow-ът вече е асинхронен, предимството намалява.
Какво подсказва това обявяване за enterprise AI екипите
Трендът става все по-труден за пренебрегване. През 2025 г. много enterprise организации разглеждаха генеративните модели като асистенти извън transaction path. Към края на 2026 г. доставчиците вече ги представят като кандидати за продукционни решения, които се вземат в рамките на милисекунди. RIPL не решава въпроса окончателно, но мести границата.
Оперативният извод е ясен. Купувачите трябва да тестват p95 и p99 латентност при непрекъснато натоварване, а не средна латентност в чисти демонстрации. Трябва също да сравняват кратки и дълги prompt-и поотделно, защото собствените данни на Liquid показват колко бързо се променя икономиката с нарастването на броя токени. И трябва да питат дали затвореният serving software не създава зависимости, които надвишават ползата от производителността.
За AI за анализи в реално време по-големият тренд не е, че един engine е публикувал бързо число. А че екипите по внедряване скоро може да имат по-малко причини по подразбиране да избират класически модели за всеки live decision path. Оставащата работа е дисциплинирана валидация, а не аплодисменти за доставчика.
Написано от екипа на Encorp. Свържете се с нас: запазете 30-минутен разговор или ни последвайте в LinkedIn.
Martin Kuvandzhiev
Co-Founder & CEO, encorp.ai
CEO and Founder of Encorp.io with expertise in AI and business transformation
LinkedIn