вы меня заинтересовали. наверное есть смысл взять 5060 (лучше 5060 Ti) и сравнить с V100. вот прямо на одних и тех же моделях.
Учитывая, что я хотел в сервер помимо пары V100 поставить еще что-то, то вполне нормальный вариант. Модель будет загружаться в V100, а сами вычисления распределяться
было бы очень интересно почитать, если есть возможность. я буквально последние два месяца мечусь и не решаюсь что-то конкретное взять просто из за всех вышеизложенных мной сомнений - новое но дорого, или старое но крутое. хочется всех зайцев и не по цене однушки в подмосковье, конечно же, но выбирать приходиться из того что есть =)
вот потому и спрашиваю собственно, мне тоже совсем не все очевидно. вроде 5060 это архитектура на годы вперед, сегодня вот такую штуку показали - https://huggingface.co/prism-ml/Ternary-Bonsai-27B-gguf грубо говоря стоит ждать новых способов квантования, с другой стороны отдавать x3-x4 за потребительскую карту ради только архитектуры-новизны и ещё и с низкой пропускной способностью... когда v100 p100 есть бу даже с гарантией прямо с цодов, nvlink, огромная п/с и огромная память.
в общем потому ваш материал важен не просто как "я сделал, и у меня действительно получилось", а потому что он реальная инструкция + реальный опыт, и есть над чем подумать, и есть пошагово что делать в случае выбора для себя этого варианта
p.s. я про Ti изначально говорил, всё интересное от 16 гб само собой, но сути это шибко по вопросам архитектур не меняет, для тех кто будет перечитывать топик позже
Вольта физически не поддерживает аппаратное асинхронное копирование данных в shared memory (cp.async), которое появилось только в Ampere. Из-за этого все подобные порты под CC 7.0 - не более чем эмуляция с диким оверхедом по памяти. как я изначально сказал:
будет идти условно как с Doom - на тесте на беременность запускаем, но в здравом уме кто так будет играть?
вот спеки Ampere и Volta, или ссылки автора архитектур для вас не доказательства?
Во все эти легенды о неподдерживаемых квантованиях
А пассаж про "неподдерживаемые квантования" вы вообще сами придумали и сами же бросились опровергать. Я ничего подобного не утверждал. без дословного цитирования такие выпады не несут достаточно объективности чтобы считаться серьёзными.
p.s. ваша вторая ссылка есть просто инструкция к первой, так что, сдаётся мне, не лень дальше искать было, а гипотеза просто резко обрела границы =)
квантование квантованием, а всякие flash attention на старых поколениях не поддерживаются... ну и будет идти условно как с Doom - на тесте на беременность запускаем, но в здравом уме кто так будет играть? тоже засматривался на p100, v100, но как будто в переплату за 5060 вложено как раз то время, что тратится на налаживание охлада и нервы вокруг этого всего. Не считаете?
даешь бтоп в массы! уже года два только его использую. единственный минус для себя нашёл (не минус самого софта, а тех особенность сборки метрик судя по всему) - если на 100мс ставить - начинает нехило поджирать рам, оптимум - 500мс, но для ощущения непрерывности бытия порой хочется 100мс видеть.
по теме статьи - ещё бы очень для работы с диском порекомендовал ncdu
Так они сейчас и так лежат в одном месте - единая база, рантайм и админка, а не размазаны по файлам проекта) в том и удобство
А насчёт семантического поиска - мысль отличная. Если тулов наберётся под сотню, эмбеддинги по описаниям категорий как надстройка над деревом прямо напрашиваются, чтобы агент не блуждал по веткам, а сразу прыгал в нужную папку.
Про тонкую CLI/MCP-обёртку - ровно об этом в статье и написал) Stdio-мост на 50 строк, чтобы тот же Claude Code или Cursor видели весь тулхаб как один MCP-сервер - это идеальный юзкейс. Пока в статье возложил это на сообщество, подожду немного - если никто не накидает PR, сам за вечер оформлю. Просто не хотелось с первого же дня превращать ToolHub в очередной обслуживающий адаптер под Claude Code - важнее было показать и обкатать саму концепцию дерева и рантайма в чистом виде.
Согласен! да, на рефли тоже натыкался какое-то время назад. Кстати, они тоже пришли к той же мысли что и мы с вами выше - Skills are not prompts. They are durable infrastructure. Выходит, тоже что-то знают)) правда, рефли это больше про тяжелый энтерпрайз, n8n like графы, очень много интеграций под капотом. Тулхаб таки что-то вроде минималистичный unix-way рантайм, но общая суть безусловно схожа - отделить слой тулинга от слоя мышления.
В итоге любой инженер неизбежно приходит к пониманию, что детерминированный вызов точечного скрипта с предсказуемым входом/выходом экономит не только токены, но и тонны нервов на отладке недетерминированного поведения модели.
Будем развивать дальше, планов по тулхабу ещё вагон!
Позволяем LLM самому написать, даже, например, запрос T-SQL адекватный именно текущему запросу.
Так toolhub ровно это и позволяет! Никто не заставляет хардкодить логику. Вы можете сделать тул callTool("/db/execute_sql", { "query": "SELECT ... FROM ..." }), где модель сама на лету генерирует любой T-SQL под текущий контекст. Но сам коннект к СУБД, пул соединений, таймауты и отлов ошибок берет на себя рантайм, а не LLM через консольные костыли.
И надо найти границу за которой ваш инструмент не станет тем же Курсором или Кодекс. Вы думаете они там ничего такого не придумали?
Именно что придумали! Но они зашили это внутрь своих закрытых, платных и проприетарных экосистем. Та же фича у Claude Code, когда модель сама пишет скрипт и крутит его во временном окружении - это ровно тот же паттерн. Смысл toolhub - дать этот же уровень удобства в виде открытого, self-hosted и ЯП-агностичного Function-as-a-service движка для любой модели (включая локальные через Ollama или в связке со своим UI).
mcp без соответствующих ему скилов может вообще быть бесполезен полностью, его не смогут позвать. Т.е. если человек не умеет свистеть, то ему можно дать свисток. Но ему все-равно надо будет объяснить когда, зачем и как свистеть...
Тут вы на 100% правы, инструмент без контекста применения бесполезен. Возможно, я недостаточно явно подсветил это в статье: в toolhub именно что уже заложен этот механизм, причем иерархически:
На уровне папки(у каждой папки есть appendPrompt - добавочный промпт, его можно как подмешивать в системный так и просто кормить им модель): Когда агент делает listTools("/1c"), он вместе со списком тулов получает мета-инструкцию: правила предметной области, когда какой тул звать и в каком порядке.
На уровне тула(описание конкретного тула + примеры few shots): У каждого инструмента есть не просто типы параметров, а текстовое описание поведения и few-shot примеры входных/выходных данных.
Разница лишь в доставке: мы не вываливаем на модель инструкции ко всем 50 "свисткам" на старте диалога (сжигая все бабки и лимиты), а отдаем объяснение к конкретному "свистку" ровно в тот момент, когда агент зашел в соответствующую категорию.
Супер примеры! Это как раз идеальная демонстрация разницы между Prompt-driven подходом и Runtime-driven. Смотрите, оба ваших скилла - это гигантские инструкции на несколько тыщ токенов каждая.
В вашем подходе:
Вы заставляете LLM держать в контексте огромную простыню документации (разницу между OData v3/v4, правила substringof, необходимость собирать Base64 для Basic Auth, URL-encoding кириллицы %D0%...) и тд.
Модель на каждом шаге сама пытается собрать длинную команду для универсального fetch/curl. Она может ошибиться в кавычках, забыть закодировать строку или сгенерировать невалидный заголовок.
Если подключить 5–10 таких интеграций (1С, Brave, GitLab, Jira, Postgres) через скиллы - агент выжрет 20-30k токенов контекста еще до начала диалога.
А сейчас мы возьмём и сделаем, к примеру, второй (потому что он посложнее и поинтереснее как по мне) ваш скилл в виде тула для тулхаба:
Это псевдокод, с 1C конкретно дел не имею, может потребовать адаптации под реалии, но суть - сколько тысяч токенов и минут сэкономили?)
Итог простой: В случае со SKILL.md мы перекладываем на дорогую и недетерминированную LLM работу парсера, кодировщика строк и генератора curl-команд, попутно сжигая контекст на чтение инструкций. В случае с toolhub - мы отдаём эту рутину обычному коду за 5 миллисек, а модели оставляем только высокоуровневое намерение (“дай сотрудников с фамилией Иванов”), экономя неимоверное количество токенов и своего времени в процессе самой работы, тратя лишь часть его на разработку тула/тулпака.
Вот в этом и есть фундаментальная разница: скилл учит модель, как костылить запрос в терминале, а toolhub даёт готовый атомарный микросервис, знать модели детали реализации которого для эффективной работы досконально не обязательно.
Бонусом: все ваши скиллы model-specific, а тулхабом одинаково не смогут пользоваться разве что уж совсем маленькие и глупые модельки.
Прям рекомендую попробовать в отдельном проекте, если понравится - переносить постепенно все .md на него. Разница в удобстве колоссальная.
Если внутри самого Python-скрипта запускаются вложенные сабпроцессы через голый Popen без subprocess.run или обвязки try/finally с proc.kill(), они могут остаться зомби в ОС даже после падения основного скрипта.
Со стороны рантайма ToolHub внешний вызов глушится по жесткому таймауту на уровне ОС (через PID родительского процесса и последующую зачистку воркспейса), но чистоплотность внутренних форков внутри самого скрипта - это зона ответственности автора конкретного тула, и об этом важно помнить.
Подождём ещё подобных edge case’ов, и в ридми их в дальнейшем добавлю обязательно.
Большой апдейт 🧪lab (v1.2.0) + Выкатил обещанный ToolHub!
Всем привет! За прошедшее время проект заметно вырос: переработана архитектура управления контекстом, добавлена работа с префиксными папками, мобильный PWA-режим и, главное, - выкатил обещанный тулхаб.
Релиз 🛠️toolhub (управление локальными скриптами и навыками агентов)
Как и обещал в статье, я довёл до ума и полностью открыл движок исполнения навыков toolhub, который работает в связке с 🧪lab. Теперь можно прямо из браузерного интерфейса давать моделям доступ к локальным скриптам (Bash, Bun, Python, Go) через древовидную файловую навигацию вместо сжигания контекста на килобайты JSON-схем.
Точечный контроль контекста и защита от вымывания правил:
Message Pinning: Закрепление якорных сообщений (системные правила, важные вводные) — закрепленные сообщения имеют иммунитет к автоочистке скользящего окна (Sliding Window).
Глубокая аналитика токенов: Раздельный подсчет User / Assistant / Tool + System, визуальные бейджи веса веток, детектор самых «тяжелых» сообщений и коэффициент расширения ответов ().
Хирургическая очистка: Оставить последние сообщений, срезать верхушку или сжать весь код в диалоге до плейсхолдеров, сохранив текстовую нить рассуждений.
PWA, автономность и мобайл:
Полноценная установка как standalone PWA-приложения (iOS, Android, macOS, Windows) с фоновым кэшированием статики.
Web Push: Системные уведомления по завершению тяжелых фоновых генераций.
Голосовой движок (для любителей и побаловаться):
STT (Push-to-Talk): Быстрый голосовой ввод по горячей клавише с автодобавлением в поле ввода.
Streaming TTS: Потоковое воспроизведение ответов модели по предложениям с санитаризацией (фильтрация блоков кода, LaTeX и эмодзи) и контролем скорости.
Увидел ниже скриншот, да. Но не все клиенты то поняли где пишут, что уж говорить обо мне, я из другой конторы вообще, тоже мной тегнутой. Помимо того, для многих тут телеграм без купры не открывается - в том и проблема.
Timeweb CloudFirstVDS и кто еще в купре сидит - всем было бы гораздо легче если бы вы хотя бы писали что происходит в данный момент. Ждём новые чиллеры, налаживаем систему охлаждения, пытаемся разобраться почему всё легло. Неужели купра настолько безответственные что не держат вас в курсе происходящего?
Судя по всему, вам и манагеры купры дают разную информацию. 1вдс до 15:00 по мск обещали инфу, таймвеб до 17:00. 17:30 - у всех всё лежит. Раз уж ЧП - не может один по связям с общественностью просто вести централизованный лог событий в цоде? Хотя бы передавать что купра говорит. Иначе что, сидеть просто ждать у моря погоды?
По маркдауну - пока с лихвой хватило react-markdown, react-gfm.
Хоть assistant-ui и выглядит красиво - множество лучших решений перетекут из него в более общие библиотеки компонентов рано или поздно, в тот же shadcn/tailwind. Да и тут прям особенного специфичного ничего реализовывать не пришлось, так что кардинальной разницы пока не вижу. В любом случае, посмотрим как дело пойдёт - внедрить никогда не поздно.
А я вот совсем не понял вопрос. Это просто лёгкий интерфейс, даже без бекенда - никаких виртуалок он не поднимает и не может. А что там клод в точке инференса делает - утверждать не возьмусь, но в любом случае очень сомневаюсь что кто-либо из провайдеров докидывает к инференсу execute бесплатно.
100%, туда и движемся.
было бы очень интересно почитать, если есть возможность. я буквально последние два месяца мечусь и не решаюсь что-то конкретное взять просто из за всех вышеизложенных мной сомнений - новое но дорого, или старое но крутое. хочется всех зайцев и не по цене однушки в подмосковье, конечно же, но выбирать приходиться из того что есть =)
вот потому и спрашиваю собственно, мне тоже совсем не все очевидно. вроде 5060 это архитектура на годы вперед, сегодня вот такую штуку показали - https://huggingface.co/prism-ml/Ternary-Bonsai-27B-gguf грубо говоря стоит ждать новых способов квантования, с другой стороны отдавать x3-x4 за потребительскую карту ради только архитектуры-новизны и ещё и с низкой пропускной способностью... когда v100 p100 есть бу даже с гарантией прямо с цодов, nvlink, огромная п/с и огромная память.
в общем потому ваш материал важен не просто как "я сделал, и у меня действительно получилось", а потому что он реальная инструкция + реальный опыт, и есть над чем подумать, и есть пошагово что делать в случае выбора для себя этого варианта
p.s. я про Ti изначально говорил, всё интересное от 16 гб само собой, но сути это шибко по вопросам архитектур не меняет, для тех кто будет перечитывать топик позже
спасибо! пища для размышлений
Вольта физически не поддерживает аппаратное асинхронное копирование данных в shared memory (cp.async), которое появилось только в Ampere. Из-за этого все подобные порты под CC 7.0 - не более чем эмуляция с диким оверхедом по памяти. как я изначально сказал:
вот спеки Ampere и Volta, или ссылки автора архитектур для вас не доказательства?
https://images.nvidia.com/content/volta-architecture/pdf/volta-architecture-whitepaper.pdf
https://images.nvidia.com/aem-dam/en-zz/Solutions/data-center/nvidia-ampere-architecture-whitepaper.pdf
А пассаж про "неподдерживаемые квантования" вы вообще сами придумали и сами же бросились опровергать. Я ничего подобного не утверждал. без дословного цитирования такие выпады не несут достаточно объективности чтобы считаться серьёзными.
p.s. ваша вторая ссылка есть просто инструкция к первой, так что, сдаётся мне, не лень дальше искать было, а гипотеза просто резко обрела границы =)
неплохо - понятие растяжимое... я и на ддр4 на гемма4 26б десяток токенов в секунду получаю, но вот докупать что то тензорное все равно хочу)
квантование квантованием, а всякие flash attention на старых поколениях не поддерживаются... ну и будет идти условно как с Doom - на тесте на беременность запускаем, но в здравом уме кто так будет играть? тоже засматривался на p100, v100, но как будто в переплату за 5060 вложено как раз то время, что тратится на налаживание охлада и нервы вокруг этого всего. Не считаете?
в любом случае спасибо за опыт, было интересно
даешь бтоп в массы! уже года два только его использую. единственный минус для себя нашёл (не минус самого софта, а тех особенность сборки метрик судя по всему) - если на 100мс ставить - начинает нехило поджирать рам, оптимум - 500мс, но для ощущения непрерывности бытия порой хочется 100мс видеть.
по теме статьи - ещё бы очень для работы с диском порекомендовал ncdu
Так они сейчас и так лежат в одном месте - единая база, рантайм и админка, а не размазаны по файлам проекта) в том и удобство
А насчёт семантического поиска - мысль отличная. Если тулов наберётся под сотню, эмбеддинги по описаниям категорий как надстройка над деревом прямо напрашиваются, чтобы агент не блуждал по веткам, а сразу прыгал в нужную папку.
Про тонкую CLI/MCP-обёртку - ровно об этом в статье и написал) Stdio-мост на 50 строк, чтобы тот же Claude Code или Cursor видели весь тулхаб как один MCP-сервер - это идеальный юзкейс. Пока в статье возложил это на сообщество, подожду немного - если никто не накидает PR, сам за вечер оформлю. Просто не хотелось с первого же дня превращать ToolHub в очередной обслуживающий адаптер под Claude Code - важнее было показать и обкатать саму концепцию дерева и рантайма в чистом виде.
Согласен! да, на рефли тоже натыкался какое-то время назад. Кстати, они тоже пришли к той же мысли что и мы с вами выше - Skills are not prompts. They are durable infrastructure. Выходит, тоже что-то знают)) правда, рефли это больше про тяжелый энтерпрайз, n8n like графы, очень много интеграций под капотом. Тулхаб таки что-то вроде минималистичный unix-way рантайм, но общая суть безусловно схожа - отделить слой тулинга от слоя мышления.
Спасибо за поддержку!
В итоге любой инженер неизбежно приходит к пониманию, что детерминированный вызов точечного скрипта с предсказуемым входом/выходом экономит не только токены, но и тонны нервов на отладке недетерминированного поведения модели.
Будем развивать дальше, планов по тулхабу ещё вагон!
Так toolhub ровно это и позволяет! Никто не заставляет хардкодить логику. Вы можете сделать тул
callTool("/db/execute_sql", { "query": "SELECT ... FROM ..." }), где модель сама на лету генерирует любой T-SQL под текущий контекст. Но сам коннект к СУБД, пул соединений, таймауты и отлов ошибок берет на себя рантайм, а не LLM через консольные костыли.Именно что придумали! Но они зашили это внутрь своих закрытых, платных и проприетарных экосистем. Та же фича у Claude Code, когда модель сама пишет скрипт и крутит его во временном окружении - это ровно тот же паттерн. Смысл toolhub - дать этот же уровень удобства в виде открытого, self-hosted и ЯП-агностичного Function-as-a-service движка для любой модели (включая локальные через Ollama или в связке со своим UI).
Тут вы на 100% правы, инструмент без контекста применения бесполезен. Возможно, я недостаточно явно подсветил это в статье: в toolhub именно что уже заложен этот механизм, причем иерархически:
На уровне папки (у каждой папки есть appendPrompt - добавочный промпт, его можно как подмешивать в системный так и просто кормить им модель): Когда агент делает
listTools("/1c"), он вместе со списком тулов получает мета-инструкцию: правила предметной области, когда какой тул звать и в каком порядке.На уровне тула (описание конкретного тула + примеры few shots): У каждого инструмента есть не просто типы параметров, а текстовое описание поведения и few-shot примеры входных/выходных данных.
Разница лишь в доставке: мы не вываливаем на модель инструкции ко всем 50 "свисткам" на старте диалога (сжигая все бабки и лимиты), а отдаем объяснение к конкретному "свистку" ровно в тот момент, когда агент зашел в соответствующую категорию.
Супер примеры! Это как раз идеальная демонстрация разницы между Prompt-driven подходом и Runtime-driven. Смотрите, оба ваших скилла - это гигантские инструкции на несколько тыщ токенов каждая.
В вашем подходе:
Вы заставляете LLM держать в контексте огромную простыню документации (разницу между OData v3/v4, правила substringof, необходимость собирать Base64 для Basic Auth, URL-encoding кириллицы
%D0%...) и тд.Модель на каждом шаге сама пытается собрать длинную команду для универсального fetch/curl. Она может ошибиться в кавычках, забыть закодировать строку или сгенерировать невалидный заголовок.
Если подключить 5–10 таких интеграций (1С, Brave, GitLab, Jira, Postgres) через скиллы - агент выжрет 20-30k токенов контекста еще до начала диалога.
А сейчас мы возьмём и сделаем, к примеру, второй (потому что он посложнее и поинтереснее как по мне) ваш скилл в виде тула для тулхаба:
Код
Это псевдокод, с 1C конкретно дел не имею, может потребовать адаптации под реалии, но суть - сколько тысяч токенов и минут сэкономили?)
Итог простой: В случае со SKILL.md мы перекладываем на дорогую и недетерминированную LLM работу парсера, кодировщика строк и генератора curl-команд, попутно сжигая контекст на чтение инструкций. В случае с toolhub - мы отдаём эту рутину обычному коду за 5 миллисек, а модели оставляем только высокоуровневое намерение (“дай сотрудников с фамилией Иванов”), экономя неимоверное количество токенов и своего времени в процессе самой работы, тратя лишь часть его на разработку тула/тулпака.
Вот в этом и есть фундаментальная разница: скилл учит модель, как костылить запрос в терминале, а toolhub даёт готовый атомарный микросервис, знать модели детали реализации которого для эффективной работы досконально не обязательно.
Бонусом: все ваши скиллы model-specific, а тулхабом одинаково не смогут пользоваться разве что уж совсем маленькие и глупые модельки.
Прям рекомендую попробовать в отдельном проекте, если понравится - переносить постепенно все .md на него. Разница в удобстве колоссальная.
Примерно тем же, чем идея пожарить картошку отличается от плиты и сковородки.
Покажите ваш конкретный "skill" - подробно на примере и рассмотрим чем отличается.
Ценное предостережение, спасибо!
Если внутри самого Python-скрипта запускаются вложенные сабпроцессы через голый
Popenбезsubprocess.runили обвязкиtry/finallyсproc.kill(), они могут остаться зомби в ОС даже после падения основного скрипта.Со стороны рантайма ToolHub внешний вызов глушится по жесткому таймауту на уровне ОС (через PID родительского процесса и последующую зачистку воркспейса), но чистоплотность внутренних форков внутри самого скрипта - это зона ответственности автора конкретного тула, и об этом важно помнить.
Подождём ещё подобных edge case’ов, и в ридми их в дальнейшем добавлю обязательно.
Большой апдейт 🧪lab (v1.2.0) + Выкатил обещанный ToolHub!
Всем привет! За прошедшее время проект заметно вырос: переработана архитектура управления контекстом, добавлена работа с префиксными папками, мобильный PWA-режим и, главное, - выкатил обещанный тулхаб.
Релиз 🛠️toolhub (управление локальными скриптами и навыками агентов)
Как и обещал в статье, я довёл до ума и полностью открыл движок исполнения навыков toolhub, который работает в связке с 🧪lab. Теперь можно прямо из браузерного интерфейса давать моделям доступ к локальным скриптам (Bash, Bun, Python, Go) через древовидную файловую навигацию вместо сжигания контекста на килобайты JSON-схем.
👉 Подробный разбор архитектуры, бенчмарки и исходники расписал в новой статье: Хорош хардкодить кривые MCP: превращаем любой скрипт в инструмент LLM за 2 секунды
А что нового появилось в 🧪lab:
Иерархические Radix-папки (Virtual Prefix Folders)
Точечный контроль контекста и защита от вымывания правил:
Message Pinning: Закрепление якорных сообщений (системные правила, важные вводные) — закрепленные сообщения имеют иммунитет к автоочистке скользящего окна (Sliding Window).
Глубокая аналитика токенов: Раздельный подсчет User / Assistant / Tool + System, визуальные бейджи веса веток, детектор самых «тяжелых» сообщений и коэффициент расширения ответов (
).
Хирургическая очистка: Оставить последние
сообщений, срезать верхушку или сжать весь код в диалоге до плейсхолдеров, сохранив текстовую нить рассуждений.
PWA, автономность и мобайл:
Полноценная установка как standalone PWA-приложения (iOS, Android, macOS, Windows) с фоновым кэшированием статики.
Web Push: Системные уведомления по завершению тяжелых фоновых генераций.
Голосовой движок (для любителей и побаловаться):
STT (Push-to-Talk): Быстрый голосовой ввод по горячей клавише с автодобавлением в поле ввода.
Streaming TTS: Потоковое воспроизведение ответов модели по предложениям с санитаризацией (фильтрация блоков кода, LaTeX и эмодзи) и контролем скорости.
LaTeX Math & Export:
Нативный рендеринг inline/block математических формул.
Экспорт диалогов в чистый Markdown со всеми блоками кода и форматированием.
Все настройки, чаты и ключи по-прежнему хранятся исключительно локально в вашем браузере (IndexedDB via Dexie.js), без сторонних бэкендов.
Онлайн-версия: labstudio.tech
GitHub Repo: github.com/Talos-popcorn/lab
Статья про движок тулов: habr.com/ru/articles/1080890/
Увидел ниже скриншот, да. Но не все клиенты то поняли где пишут, что уж говорить обо мне, я из другой конторы вообще, тоже мной тегнутой. Помимо того, для многих тут телеграм без купры не открывается - в том и проблема.
Timeweb CloudFirstVDS и кто еще в купре сидит - всем было бы гораздо легче если бы вы хотя бы писали что происходит в данный момент. Ждём новые чиллеры, налаживаем систему охлаждения, пытаемся разобраться почему всё легло. Неужели купра настолько безответственные что не держат вас в курсе происходящего?
Судя по всему, вам и манагеры купры дают разную информацию. 1вдс до 15:00 по мск обещали инфу, таймвеб до 17:00. 17:30 - у всех всё лежит. Раз уж ЧП - не может один по связям с общественностью просто вести централизованный лог событий в цоде? Хотя бы передавать что купра говорит. Иначе что, сидеть просто ждать у моря погоды?
По маркдауну - пока с лихвой хватило react-markdown, react-gfm.
Хоть assistant-ui и выглядит красиво - множество лучших решений перетекут из него в более общие библиотеки компонентов рано или поздно, в тот же shadcn/tailwind. Да и тут прям особенного специфичного ничего реализовывать не пришлось, так что кардинальной разницы пока не вижу. В любом случае, посмотрим как дело пойдёт - внедрить никогда не поздно.
А я вот совсем не понял вопрос. Это просто лёгкий интерфейс, даже без бекенда - никаких виртуалок он не поднимает и не может. А что там клод в точке инференса делает - утверждать не возьмусь, но в любом случае очень сомневаюсь что кто-либо из провайдеров докидывает к инференсу execute бесплатно.