Pull to refresh

Comments 4

Здорово! Коллеги в параллельной команде как раз пытаются увязать TF с Ignite. Пара наболевших вопросов. Посоветуйте пожалуйста:


  • Основное затруднение — в Ignite лежат структурированные объекты, с реляциями между кэшами, а TF (tf.transform) хочет вектора. Писать трансформацию руками — очень занудное (а с учетом того, что на питоне — еще и весьма рискованное) занятие. Хотелось бы что-то вроде Graph QL или подобного, чтобы формировать векторы на стороне Ignite, а не тащить кучу данных в питон, чтобы потом большую часть просто выкинуть. Есть ли планы в этом направлении?


  • Побочное затруднение — никак не можем решить есть ли смысл гонять TF локально на Ignite нодах (или может вообще внутри процесса)? На момент начала проекта (год назад) бытовало мнение, что сеть будет "узким горлом", потому что внутренние query в Ignite очень быстрые. Сейчас мы в этом уже не уверены. Вот и по вашим цифрам получается что разница — всего 5%. Т.е. для записей размером, скажем, 4Кб, получается поток в 200К записей в секунду, что в общем соответствует нашим замерам скорости чтения прогретого кэша одним потоком. Как вы думаете: есть ли смысл в колокации вычислений для TF и Ignite?


Что касается структурированных объектов, то tf.data с ними справляется очень неплохо, позволяет работать со сложными объектами и применять практически произвольную трансформацию. А еще читать из разных источников, делать concatenate, reduce, flat_map и так далее. А в чем риск писать трансформацию на питоне?

Запросы с трансформацией на стороне Ignite доступны только из Java API. Других способов, на сколько я знаю, в ближайшее время не предвидится.

По поводу сети, если обучение делается на одной машине, то кроме разницы +-5% мы ничего не получим. Если же мы думаем о распределенном DL, когда на каждом узле вычисляются градиенты только для локальных данных, разница уже заключается не в +-5%, а в теоретически неограниченной линейной масштабируемости. То есть, конечно, ограниченной передачей градиентов, но не данных, а значит теоретическая верхняя планка производительности намного выше. Мы как раз над этим сейчас работаем. Впрочем, с практической точки зрения, я бы не переходил к распределенному обучению, если ситуация позволяет делать его локально.

Спасибо! Под структурированными объектами имелось в виду, например, пользовательский профайл и к нему коллекция из фактов, каждый из которых может, например, содержать ещё и коллекцию событий. Если я правильно понимаю tf data хочет на вход многоколоночное представление, с ключами и значениями. Можно, конечно, развернуть все в вид user.facts.42.event.33.location.longitude, но ворчать такими "колонками" в трансформациях не айс. Особенно если надо, например, три последних локации с пользователя. Проблема именно с коллекциями переменного размера.


Питона боимся из-за питоньей типизации. Она конечно есть, но вроде того суслика. Все попытки заставить хотя бы intellisense работать в jupiter с нашими объектами провалились с позором. Ловить эти вещи на этапе компиляции значительно лучше чем на излете в стейджинге.


Вычисление градиентов распараллелить было бы очень круто. Спасибо!


Кстати, до этого наш СТО нарисовал библиотеку векторизации на Scala, работающую напрямую с Ignite. Она у нас даже продержалась пол года в проде, но потом вышел tf.transform, и мы решили от этого изделия отказаться...

Про многоколоночное представление для tf.data – это не совсем так. По крайней мере на уровне API. Там может быть абсолютно любая схема. Например, как у меня в параграфе про структурированные объекты.

Если интересны внутренности, то происходит все примерно следующим образом. Ядро TensorFlow, которые на C++, возвращает просто список объектов как std::vector (код тут). Обертка, которая на Python, специфицирует как этот список интерпретировать и как его превратить в иерархический объект (код тут). В итоге, в Python API мы работаем именно со структурированными иерархическими объектами, а не с колоночным представлением.
Sign up to leave a comment.