Кривой, тупой, погрязший в корпоративном аду гугол опять с безумным опозданием показал продукт своей жизнедеятельности. Через три буквы можно получить доступ, но оно не работает, просто виснет по пути. И на месяц кстати дает 5 запросов, два за сегодня зависли, даже проверять не хочется дальше. Как было год назад недоразумение, так и сейчас. С таким баблом так лажать, прям нужен искуственный для этого интеллект!
Пипец, называется, нифига не понял, но статью напишу! Ситуация многим знакомая, да DDD-сила, ватерфол могила и все такое. Но джуна в проектирование пускать не стоит. DDD - микросервисная архитектура? Каждую энтить в сервис? Пацаны, вяжите коллегу быстрее, а то потом огребете ушат лапши на годы. Наносервисы, пикосервисы, йоктосервисы :D Но общая направленность то к доброму, светлому, вечному. Просто учиться надо.
Ну да, должно быть как раз в районе 45, если 32b около 20 ест. Проблема видимо в вулкане, на винде на cuda поднялось, 30 слоев в gpu, конечно, ни о чем, 1.5 ток/сек. Однако в итоге не больно то умнее гвена, к сожалению,выдумывает. В работе на это нет времени. С 4o и o1 я уже как то от именно галюнов отвык, скорее не туда размышление уходит.
Привет, а сколько контекста запросили и сколько слоев в gpu? У меня на Lmstudio, linux, vulkan (cuda не хочет на лине), 24ram gpu (4090), 128ram, но даже если я контекст снижаю до 1024, и 0 слоев пускаю на gpu, выдает ошибку без конкретики
Большое человеческое спасибо! Счастлив, что теперь мне эту статью не писать, буду рекомендовать коллегам для быстрого ознакомления. По asyncapi - третья версия существенно упростила жизнь, прямо глоток воздуха после выверта "в publish описываем куда нам отправлять, а в subscribe - где на нас подписываться". Добавилась +- нативная поддержка таких протоколов, как, например, WebSocket.
Но тулинг - тот случай, когда хотели написать программу, а умеют только в javascript (спасибо, что typescript): с тормозами и плюшками переобобщенного программирования и 100500 паттернов. Впрочем, привычных фротендеру. А не злому бэку, которому пришлось лезть по локоть в modelina, чтобы допилить генережку dto'шек для go, а для плюсов - и вовсе свое писать. Потому что API-First наше всё.
Кстати. На 2.6.0 как то приходилось разделять контексты и документы, и это выглядело довольно нелепо, хотелось DRY. Сейчас я эмпирически оцениваю, где бОльшая доля ответственности, и сдвигаю контекст в этот сервис: теперь же можно описать исчерпывающе входящие-исходящие и ответы. А вы как выбираете, кого из сервисов назначить хозяином API - с чьей перспективы оно описывается?
Кривой, тупой, погрязший в корпоративном аду гугол опять с безумным опозданием показал продукт своей жизнедеятельности. Через три буквы можно получить доступ, но оно не работает, просто виснет по пути. И на месяц кстати дает 5 запросов, два за сегодня зависли, даже проверять не хочется дальше. Как было год назад недоразумение, так и сейчас. С таким баблом так лажать, прям нужен искуственный для этого интеллект!
Пипец, называется, нифига не понял, но статью напишу! Ситуация многим знакомая, да DDD-сила, ватерфол могила и все такое. Но джуна в проектирование пускать не стоит. DDD - микросервисная архитектура? Каждую энтить в сервис? Пацаны, вяжите коллегу быстрее, а то потом огребете ушат лапши на годы. Наносервисы, пикосервисы, йоктосервисы :D Но общая направленность то к доброму, светлому, вечному. Просто учиться надо.
Иииии.... Закрыто!
Ну да, должно быть как раз в районе 45, если 32b около 20 ест. Проблема видимо в вулкане, на винде на cuda поднялось, 30 слоев в gpu, конечно, ни о чем, 1.5 ток/сек. Однако в итоге не больно то умнее гвена, к сожалению,выдумывает. В работе на это нет времени. С 4o и o1 я уже как то от именно галюнов отвык, скорее не туда размышление уходит.
Привет, а сколько контекста запросили и сколько слоев в gpu? У меня на Lmstudio, linux, vulkan (cuda не хочет на лине), 24ram gpu (4090), 128ram, но даже если я контекст снижаю до 1024, и 0 слоев пускаю на gpu, выдает ошибку без конкретики
Большое человеческое спасибо! Счастлив, что теперь мне эту статью не писать, буду рекомендовать коллегам для быстрого ознакомления. По asyncapi - третья версия существенно упростила жизнь, прямо глоток воздуха после выверта "в publish описываем куда нам отправлять, а в subscribe - где на нас подписываться". Добавилась +- нативная поддержка таких протоколов, как, например, WebSocket.
Но тулинг - тот случай, когда хотели написать программу, а умеют только в javascript (спасибо, что typescript): с тормозами и плюшками переобобщенного программирования и 100500 паттернов. Впрочем, привычных фротендеру. А не злому бэку, которому пришлось лезть по локоть в modelina, чтобы допилить генережку dto'шек для go, а для плюсов - и вовсе свое писать. Потому что API-First наше всё.
Кстати. На 2.6.0 как то приходилось разделять контексты и документы, и это выглядело довольно нелепо, хотелось DRY. Сейчас я эмпирически оцениваю, где бОльшая доля ответственности, и сдвигаю контекст в этот сервис: теперь же можно описать исчерпывающе входящие-исходящие и ответы. А вы как выбираете, кого из сервисов назначить хозяином API - с чьей перспективы оно описывается?