Сейчас уже не дают. И давали не 50%, а 40%, плюсом к скидке была беспроцентная рассрочка на год. Отличная возможность купить топовую технику, которой я конечно же воспользовался. Скорбим, помним, ждём возвращения
Есть масса отличных статей про то как писать код на Go от создателей Go, но народ зачем-то читает "экспертов", которые пытаются всё переусложнить, пытаются натянуть ООП-эшные подходы на Go.
Есть отличная статья от создателей Go по поводу организации кода в проекте, но народ продолжает натягивать сову на глобус, преподнося это как высшее знание, как эталон разработки.
За свои 10+ лет в Go я повидал не мало проектов и не мало создал сам. Могу сказать наверняка, нет архитектуры лучше, чем просто лежащие в корне проекта файлики, без этих ваших бесконечных репозиториев, сервисов, юзкейсов, без попыток бездумно "обмазать" всё интерфейсами, без мапинга структур на каждом повороте, без "кастрирующих" обёрток над действительно хорошими решениями.
Загрузил 8-ми битную MLX версию на M3 Max, так же через LM Studio, без каких либо оптимизаций. Результат - 109 tok/sec. С качеством ещё предстоит более детально разобраться, но с тестовым Epoll сервером на Go c подробным описанием и пояснением каждого шага LLM справилась достойно.
Что такое MOE я в курсе. Даже если предположить, что неактивные слои будут лежать на диске(потому что в RAM они все точно не влезут), то их копирование на каждый токен в VRAM будет занимать как минимум вечность и никакими 152 ток/с тут не пахнет. Но даже если представить, что весь инференс потребует только те 17B что были изначально загружены в память, то для 17B активных мой девайс не в состоянии выдать 152 ток/с.
Qwen3.6 конечно же прекрасен, хоть в 27b хоть в 35b, комент был про математику сервиса
Выбрал M3 Max 36Gb, говорят Qwen3.5 397B A17B запустится, да ещё и скорость ~152 ток/с. Странная математика 397b в Q4_K_M это 244Gb как предполагается вместить это в 36Gb?
Спасибо за статью. С недавних пор решил отказаться от LM Studio в пользу llama.cpp, но я запускаю просто с --fit on, а тут прям такой разбор всех этих флагов, очень познавательно, сам бы ни за что не стал разбираться.
Удивительные результаты у вас получились, мне Gemma4 вообще никак не зашла в плане кодинг ассистента, возможно потому что я тестил на стороне Backend и там Gemma не так сильна. Вероятно ваши результаты как-то зависят от mxfp4 и дополнительных урезаний Qwen, чтобы поместиться в VRAM. У меня macbook и всё нативно с запасом влезает в Unified memory.
P.S. Пробовал работать с Qwen3.6 27B, результаты не то чтобы сильно превосходящие MoE модели, но разница ощущается, а вот скорость просто заставляет плакать, 16-20 tok/sec
не знаю, что там по серверам для ДЦ, у меня данная модель(glm-4.7-flash 30b 6bit) отлично себя чувствует на Macbook Pro M3 36Gb. Но признаться честно мне пока больше нравится другая - Qwen3-Coder-30B-A3B-Instruct. Можно купить скромный MacMini позапрошлого поколения и сделать из него отличный сервер дома
Вовсе не обязательно самую дорогую GPU. У меня всё прекрасно работает на Macbook Pro M4 Max 36 Gb, модель 2023 года. Поставил LM Studio, качаю всякие Gemma, Qwen, Mistral, GLM, каждая хороша по своему. LLM специально адаптированны под Mac процессоры и их unified memory. Если просто початиться, то в LM Studio есть чатик, ну а для кодинга использую opencode. Решение достойное, но надо привыкать ставить правильно задачи, в Cursor с этим проще. Самый главный плюс LM Studio + opencode это то, что вся эта конструкция работает без интернета и для меня, как заядлого путешественника, это крайне важно. Из минусов то, что аккумулятор садится значительно быстрее
как же хорошо, что на lichess дела c читерами обстоят в разы лучше, там даже писать и жаловаться не надо, система сама анализирует все рейтинговые партии и блочит явных нарушителей, а тебе только отчётики присылает, что ваш рейтинг восстановлен, так как противник оказался читером
У Go давно появился отличный логгер из коробки, а люди зачем-то продолжают использовать древние решения. И не просто древние решения, а обёртки над ними, преподнося это как киллер-фичу. Кажется было бы на много лучше написать реализацию подобного функционала представив её в виде `slog.Handler`тогда подключить ваше решение не составить никакого труда. А так, просто представьте, надо будет везде внедрять зависимость в виде `emitlog`, кто на такое пойдёт? А потом ещё выпиливать если вдруг что-то пойдёт не так. Ну уж нет.
Это резко снизило затраты и ускорило выпуск новых курсов.
Ну-ну, месяцев 5 прошло как я достиг максимального уровня в "Сове" в рамках изучения английского. С тех пор ни одного нового задания не вышло. Вместо этого "умные алгоритмы" каждый день подсовывают мне в качестве повторения одни и те же задания, даже простой рандом по имеющимся материалам не освоили)
Но вообще приложение хорошее, ничего лучше я пока не встречал, жду, надеюсь, верю, что моё обучение продолжится, пока мой интерес не пропал из-за такого вот "захватывающего" повторения
Не совсем понял, что конкретно вы предлагаете. В рамках одной транзакции мне надо вызвать 2 обновления у двух разных репозиториев, у каждого из них свой юзкейс. Единственный выход, который вижу я, это на уровне хэндлера создавать транзакцию и далее её прокидывать через юзкейс в репозиторий, но кажется этот вариант нарушает созданные нами же ограничения о том, что юзкейс не должен ничего знать о технических деталях, плюс на уровне хэндлера надо где-то хранить указатель на коннект к базе, а из репозитория убирать указатель на базу, так как теперь он будет приходить из вне. То есть мы опять придём к тому, что перемешаем мух с котлетами
А где в этой схеме живут транзакции? Существует масса ситуаций, при которых в рамках одного http запроса надо выполнить более, чем одну операцию на запись в базу и при этом сущности которые мы хотим менять разные, а значит репозитории разные, юзкейсы разные. В каком слое стартует транзакция, в каком завершается, где хранится указатель на базу, с которого стартует транзакция?
Тут возможны, как мне кажется, всего два варианта. Либо сообщения из канала вам важны и вы блокируетесь на записи, либо сообщения не важны и вы их выкидываете при заполненном буфере.
Варианты с временным "расширением" вместимости канала кажутся странными и как минимум это переусложнение на ровном месте, можно просто сделать канал больше, но это путь в никуда. Можно "выкидывать" данные в другой канал, заполнение которого будет явно свидетельствовать о проблеме и тут уже можно будет "бить в колокол".
Размер канала в 50 кажется странным решением. Зачем вам ещё одна очередь? Что станет с данными в канале, если сервис вдруг "упадёт"? Вероятно стоит поднять количество обработчиков, если очерёдность не важна, ну и канал с нулевым буфером тоже напрашивается сам собой. Ну и конечно же добавить метрику по тому, на какой промежуток времени блокируетесь при записи в канал, либо сколько выкидываете данных и после на данную метрику повесить алерты.
Вот благодаря таким библиотекам появляются "сеньёры", которые понятия не имеют о том, как распараллелить обработку массива штатными средствами, как обрабатывать паники, как запускать/останавливать горутины.
Сейчас уже не дают. И давали не 50%, а 40%, плюсом к скидке была беспроцентная рассрочка на год. Отличная возможность купить топовую технику, которой я конечно же воспользовался. Скорбим, помним, ждём возвращения
Есть масса отличных статей про то как писать код на Go от создателей Go, но народ зачем-то читает "экспертов", которые пытаются всё переусложнить, пытаются натянуть ООП-эшные подходы на Go.
Есть отличная статья от создателей Go по поводу организации кода в проекте, но народ продолжает натягивать сову на глобус, преподнося это как высшее знание, как эталон разработки.
За свои 10+ лет в Go я повидал не мало проектов и не мало создал сам. Могу сказать наверняка, нет архитектуры лучше, чем просто лежащие в корне проекта файлики, без этих ваших бесконечных репозиториев, сервисов, юзкейсов, без попыток бездумно "обмазать" всё интерфейсами, без мапинга структур на каждом повороте, без "кастрирующих" обёрток над действительно хорошими решениями.
Загрузил 8-ми битную MLX версию на M3 Max, так же через LM Studio, без каких либо оптимизаций. Результат - 109 tok/sec. С качеством ещё предстоит более детально разобраться, но с тестовым Epoll сервером на Go c подробным описанием и пояснением каждого шага LLM справилась достойно.
Что такое MOE я в курсе. Даже если предположить, что неактивные слои будут лежать на диске(потому что в RAM они все точно не влезут), то их копирование на каждый токен в VRAM будет занимать как минимум вечность и никакими 152 ток/с тут не пахнет. Но даже если представить, что весь инференс потребует только те 17B что были изначально загружены в память, то для 17B активных мой девайс не в состоянии выдать 152 ток/с.
Qwen3.6 конечно же прекрасен, хоть в 27b хоть в 35b, комент был про математику сервиса
Выбрал M3 Max 36Gb, говорят Qwen3.5 397B A17B запустится, да ещё и скорость ~152 ток/с. Странная математика 397b в Q4_K_M это 244Gb как предполагается вместить это в 36Gb?
Спасибо за статью. С недавних пор решил отказаться от LM Studio в пользу llama.cpp, но я запускаю просто с
--fit on, а тут прям такой разбор всех этих флагов, очень познавательно, сам бы ни за что не стал разбираться.Удивительные результаты у вас получились, мне Gemma4 вообще никак не зашла в плане кодинг ассистента, возможно потому что я тестил на стороне Backend и там Gemma не так сильна. Вероятно ваши результаты как-то зависят от mxfp4 и дополнительных урезаний Qwen, чтобы поместиться в VRAM. У меня macbook и всё нативно с запасом влезает в Unified memory.
P.S. Пробовал работать с Qwen3.6 27B, результаты не то чтобы сильно превосходящие MoE модели, но разница ощущается, а вот скорость просто заставляет плакать, 16-20 tok/sec
не знаю, что там по серверам для ДЦ, у меня данная модель(glm-4.7-flash 30b 6bit) отлично себя чувствует на Macbook Pro M3 36Gb. Но признаться честно мне пока больше нравится другая - Qwen3-Coder-30B-A3B-Instruct. Можно купить скромный MacMini позапрошлого поколения и сделать из него отличный сервер дома
Вовсе не обязательно самую дорогую GPU. У меня всё прекрасно работает на Macbook Pro M4 Max 36 Gb, модель 2023 года. Поставил LM Studio, качаю всякие Gemma, Qwen, Mistral, GLM, каждая хороша по своему. LLM специально адаптированны под Mac процессоры и их unified memory. Если просто початиться, то в LM Studio есть чатик, ну а для кодинга использую opencode. Решение достойное, но надо привыкать ставить правильно задачи, в Cursor с этим проще. Самый главный плюс LM Studio + opencode это то, что вся эта конструкция работает без интернета и для меня, как заядлого путешественника, это крайне важно. Из минусов то, что аккумулятор садится значительно быстрее
как же хорошо, что на lichess дела c читерами обстоят в разы лучше, там даже писать и жаловаться не надо, система сама анализирует все рейтинговые партии и блочит явных нарушителей, а тебе только отчётики присылает, что ваш рейтинг восстановлен, так как противник оказался читером
Спецификация Go гарантирует, что поля структуры располагаются в памяти именно в том порядке, в котором они объявлены
А в сторону S2 от Google не смотрели? У них кажется отличное решение для Geo поиска
Не понятен выбор в пользу Gorilla Mux, оно ничего не даёт, кроме зависимости. Стандартный http.ServeMux умеет точно так же.
zerolog и zap давно в прошлом, стандартный log/slog ничем им не уступает
У Go давно появился отличный логгер из коробки, а люди зачем-то продолжают использовать древние решения. И не просто древние решения, а обёртки над ними, преподнося это как киллер-фичу. Кажется было бы на много лучше написать реализацию подобного функционала представив её в виде `slog.Handler`тогда подключить ваше решение не составить никакого труда. А так, просто представьте, надо будет везде внедрять зависимость в виде `emitlog`, кто на такое пойдёт? А потом ещё выпиливать если вдруг что-то пойдёт не так. Ну уж нет.
Ну-ну, месяцев 5 прошло как я достиг максимального уровня в "Сове" в рамках изучения английского. С тех пор ни одного нового задания не вышло. Вместо этого "умные алгоритмы" каждый день подсовывают мне в качестве повторения одни и те же задания, даже простой рандом по имеющимся материалам не освоили)
Но вообще приложение хорошее, ничего лучше я пока не встречал, жду, надеюсь, верю, что моё обучение продолжится, пока мой интерес не пропал из-за такого вот "захватывающего" повторения
Не совсем понял, что конкретно вы предлагаете. В рамках одной транзакции мне надо вызвать 2 обновления у двух разных репозиториев, у каждого из них свой юзкейс. Единственный выход, который вижу я, это на уровне хэндлера создавать транзакцию и далее её прокидывать через юзкейс в репозиторий, но кажется этот вариант нарушает созданные нами же ограничения о том, что юзкейс не должен ничего знать о технических деталях, плюс на уровне хэндлера надо где-то хранить указатель на коннект к базе, а из репозитория убирать указатель на базу, так как теперь он будет приходить из вне. То есть мы опять придём к тому, что перемешаем мух с котлетами
А где в этой схеме живут транзакции? Существует масса ситуаций, при которых в рамках одного http запроса надо выполнить более, чем одну операцию на запись в базу и при этом сущности которые мы хотим менять разные, а значит репозитории разные, юзкейсы разные. В каком слое стартует транзакция, в каком завершается, где хранится указатель на базу, с которого стартует транзакция?
Это не создание миллиона структур, это время подсчёта среднего значения в слайсе из миллиона значений
Тут возможны, как мне кажется, всего два варианта. Либо сообщения из канала вам важны и вы блокируетесь на записи, либо сообщения не важны и вы их выкидываете при заполненном буфере.
Варианты с временным "расширением" вместимости канала кажутся странными и как минимум это переусложнение на ровном месте, можно просто сделать канал больше, но это путь в никуда. Можно "выкидывать" данные в другой канал, заполнение которого будет явно свидетельствовать о проблеме и тут уже можно будет "бить в колокол".
Размер канала в 50 кажется странным решением. Зачем вам ещё одна очередь? Что станет с данными в канале, если сервис вдруг "упадёт"? Вероятно стоит поднять количество обработчиков, если очерёдность не важна, ну и канал с нулевым буфером тоже напрашивается сам собой. Ну и конечно же добавить метрику по тому, на какой промежуток времени блокируетесь при записи в канал, либо сколько выкидываете данных и после на данную метрику повесить алерты.
всё по факту. не смотря на тег "1 апреля", как минимум с половиной утверждений согласен) сам я пишу на go с версии 1.4
Вот благодаря таким библиотекам появляются "сеньёры", которые понятия не имеют о том, как распараллелить обработку массива штатными средствами, как обрабатывать паники, как запускать/останавливать горутины.