Кэш позволяет не пересчитывать повторно, так что при низкой тпмпературе получите идентичные значкния, а при высокой - просто другие (ни хуже, ни лучше статистически - просто другие). Единственное как kv-кэш может повлиять на точность это освободить память для большей квантизации модели.
Кэш влияет на скорость, не на точность ответов. Грубо говоря, более низкая квантизация понижает вероятность нахождения кэшированного промпта и увеличивает количество полных пересчетов промпта.
Да, в RAM можно, но это все же медленно, особенно если карта в pcie x4-x8. Я имел в виду на соседнюю карту - условно, иметь быструю карту для модели и более медленную для кэша.
Увы, но кэш живет рядом со слоями, на отдельную карту вынести пока нельзя (или я пока не нашел как). Но хочется.
Слои модели распределяются между картами, после этого каждая карта работает со своим набором данных и со своей скоростью. Таким образом, если карта А быстрее карты Б в два раза, распределив слои как 2 к 1 получим примерно оптимальную общую скорость.
О, как они по скорости были? Я посматриваю на p102-100 на 10Gb в качестве расширения - если модель не вмещается в основную GPU, то остаток вгружается в p102 - всяко быстрее, чем на CPU, а по деньгам копейки.
«Неужели не понятно, что, с точки зрения фундаментальных принципов, эти ваши покойники — нисколько не более и не менее удивительная вещь, чем вечные аккумуляторы. Просто «этаки» нарушают первый принцип термодинамики, а покойники — второй, вот и вся разница...»
Ранее Вы писали "нет ничего, что указывало бы на то, что уже существующие и доступные инструменты и модели компаний из США будут закрыты". Вот модель закрыли. Вы можете поручиться, что завтра не закроют и остальное? Не можете.
Причем, закрыть могут как с той стороны, так и с этой - попробуйте, например, в сети Ростелекома скачать модель с Huggingface.
Мы живем в удивительное время, когда очень опрометчиво говорить "этого не может быть", увы.
Мы живем в интересное и непредсказуемое время, в которое, по заветам Рудольфа Сикорски, почуяв запах серы, нужно разворачивать производство святой воды в промышленных масштабах. Иначе можно с удивлением начать созерцать тыкву, в которую превратились рабочие процессы.
Не совсем. Webtorrent, насколько я вижу, допилили фичу, которая уже есть в некоторых торрент-клиентах - запрашивать пакеты в порядке воспроизведения и проигрывать их сразу. Технически это как раз ближе к HLS и работает для существующих видео, не для трансляций реального времени. Фильм так посмотреть можно, живую трансляцию хоккейного матча - увы. Но штука, безусловно, полезная для своих задач.
Вопрос цены вопроса, естественно. Пилить такое ради галочки "смотри чего мы умеем" или просто впрок - сомнительное решение. А когда на кону экономия весьма ощутимых денег и экономия эта даже в краткосрочной перспективе отобьет стоимость разработки и сопровождения - совсем другое пальто.
Насчет "отдавать единицы" не соглашусь - исходя из моих экспериментов, бюджетный ноут вполне способен отдавать 3-5 видео потоков без боли и страданий. С аудио все еще вкуснее, естетсвенно.
Идея эта давно витает в воздухе, но из-за узости ниши и высокого порога входа не сильно отсвечивает. И пока opensource-решение не появится - так и останется уделом фанатов и крупняка.
Не думаю, что разница оверхеда транспорта будет сколь либо значима / определяющя. Гораздо большая разница будет из-за того что в HLS гвоздями прибиты h264/mp3, а в WebRTC можно использовать VP8/VP9(если допустимо)/Opus. Например, чтобы предоставить несколько уровней качества, HLS требует отдельно кодировать каждый поток, а в VP можно использовать Simulcast.
Самый быстрый это не обязательно минимальный TTL на последней миле - у разных источников разная накопленная задержка.
Хорошим решением был бы выбор активного соединения из списка имеющихся основываясь на сумме "зарержка источника" + round trip time между источником и получателем. Т.е. * новый пир получает список из 10 источников с минимальной собственной задержкой * к каждому из них клиент устанавливает пассивное соединение и смотрит roundTripTime * лучшая комбинация выбирается активной.
Смотреть TTL до всех-всех источников я бы не стал - для этого нужно установить соединение (хотя бы DataChannel) ко всем источникам, на больших сетках это будет знатно грузить и источники и сигнальный.
Кэш позволяет не пересчитывать повторно, так что при низкой тпмпературе получите идентичные значкния, а при высокой - просто другие (ни хуже, ни лучше статистически - просто другие). Единственное как kv-кэш может повлиять на точность это освободить память для большей квантизации модели.
Кэш влияет на скорость, не на точность ответов. Грубо говоря, более низкая квантизация понижает вероятность нахождения кэшированного промпта и увеличивает количество полных пересчетов промпта.
Да, в RAM можно, но это все же медленно, особенно если карта в pcie x4-x8. Я имел в виду на соседнюю карту - условно, иметь быструю карту для модели и более медленную для кэша.
Увы, но кэш живет рядом со слоями, на отдельную карту вынести пока нельзя (или я пока не нашел как). Но хочется.
Слои модели распределяются между картами, после этого каждая карта работает со своим набором данных и со своей скоростью. Таким образом, если карта А быстрее карты Б в два раза, распределив слои как 2 к 1 получим примерно оптимальную общую скорость.
Две v100 в пике кушают меньше (~600Вт), чем один включенный кондиционер (up to 1кВт). Подписка дешевле, конечно - особенно включая стоимость железа.
Вопрос задачи. 5070ti должна быть ощутимо быстрее, но у 2xT4 будет 32Gb.
Что за железо, если не секрет?
На 16Gb вы запустите модельку на 7-9 гигов максимум, после этого начнется жесткий своппинг.
Macbook pro на m4 pro с 48Gb - qwen3.6-35b крутится, но краааайне неспешно.
О, как они по скорости были? Я посматриваю на p102-100 на 10Gb в качестве расширения - если модель не вмещается в основную GPU, то остаток вгружается в p102 - всяко быстрее, чем на CPU, а по деньгам копейки.
Ранее Вы писали "нет ничего, что указывало бы на то, что уже существующие и доступные инструменты и модели компаний из США будут закрыты". Вот модель закрыли. Вы можете поручиться, что завтра не закроют и остальное? Не можете.
Причем, закрыть могут как с той стороны, так и с этой - попробуйте, например, в сети Ростелекома скачать модель с Huggingface.
Мы живем в удивительное время, когда очень опрометчиво говорить "этого не может быть", увы.
https://www.anthropic.com/news/fable-mythos-access - вот заявление Антропика про закрытие доступа к модели из США для иностранцев, например.
Мы живем в интересное и непредсказуемое время, в которое, по заветам Рудольфа Сикорски, почуяв запах серы, нужно разворачивать производство святой воды в промышленных масштабах. Иначе можно с удивлением начать созерцать тыкву, в которую превратились рабочие процессы.
Добро пожаловать в 2026 ))
Не совсем. Webtorrent, насколько я вижу, допилили фичу, которая уже есть в некоторых торрент-клиентах - запрашивать пакеты в порядке воспроизведения и проигрывать их сразу. Технически это как раз ближе к HLS и работает для существующих видео, не для трансляций реального времени. Фильм так посмотреть можно, живую трансляцию хоккейного матча - увы. Но штука, безусловно, полезная для своих задач.
Вопрос цены вопроса, естественно. Пилить такое ради галочки "смотри чего мы умеем" или просто впрок - сомнительное решение. А когда на кону экономия весьма ощутимых денег и экономия эта даже в краткосрочной перспективе отобьет стоимость разработки и сопровождения - совсем другое пальто.
Насчет "отдавать единицы" не соглашусь - исходя из моих экспериментов, бюджетный ноут вполне способен отдавать 3-5 видео потоков без боли и страданий. С аудио все еще вкуснее, естетсвенно.
Идея эта давно витает в воздухе, но из-за узости ниши и высокого порога входа не сильно отсвечивает. И пока opensource-решение не появится - так и останется уделом фанатов и крупняка.
Не думаю, что разница оверхеда транспорта будет сколь либо значима / определяющя. Гораздо большая разница будет из-за того что в HLS гвоздями прибиты h264/mp3, а в WebRTC можно использовать VP8/VP9(если допустимо)/Opus. Например, чтобы предоставить несколько уровней качества, HLS требует отдельно кодировать каждый поток, а в VP можно использовать Simulcast.
Самый быстрый это не обязательно минимальный TTL на последней миле - у разных источников разная накопленная задержка.
Хорошим решением был бы выбор активного соединения из списка имеющихся основываясь на сумме "зарержка источника" + round trip time между источником и получателем. Т.е.
* новый пир получает список из 10 источников с минимальной собственной задержкой
* к каждому из них клиент устанавливает пассивное соединение и смотрит roundTripTime
* лучшая комбинация выбирается активной.
Смотреть TTL до всех-всех источников я бы не стал - для этого нужно установить соединение (хотя бы DataChannel) ко всем источникам, на больших сетках это будет знатно грузить и источники и сигнальный.