Способы оптимизации сервера параметров тензорного потока
За последние несколько лет я провел много пользовательских оптимизаций в коде тензорного потока, и теперь оставшееся узкое место, похоже, лежит на сервере параметров. В частности, когда я делаю профилирование распределенного обучения на нескольких машинах, операция RecvTensor оказывается самой трудоемкой с большим отрывом. Поэтому, естественно, я пришел к мысли о способах оптимизации вызовов grpc сервера параметров. Я знаю, что есть альтернативы grpc, такие как brpc от baidu, хотя это кажется гораздо менее хорошо документированным, и подробное сравнение производительности также отсутствует в Интернете. Другая возможность - заменить буфер протокола, используемый для передачи тензоров, на плоский буфер, но это, вероятно, не решает проблему ввода-вывода, и сериализация запроса и ответа может быть не так уж плоха по сравнению с этим.Наконец, возможно, я могу вручную квантовать float32 в float16 и преобразовать его обратно на стороне получателя, чтобы сократить ввод-вывод примерно наполовину, если последнее можно компактно хранить в памяти, но преобразование может занять некоторое время.
Итак, мой вопрос: имеют ли три упомянутых выше подхода смысл как жизнеспособные способы повышения производительности сервера параметров? Какие еще пути следует учитывать? Может быть, он уже слишком оптимизирован, так что мне не следует тратить время на эту область (хотя я действительно хотел бы понять, как сервер параметров реализован именно под капотом, помимо api распределенной стратегии python)? Любая справочная рекомендация для получения подробного понимания его внутренней работы также будет оценена!