Войти  Главная | Опросы | Регистрация |  | Поиск | Стата | 1.0Сайт
Радио Бингуру
🔊
Выбрать
Готово

Дневник Tick9er

Автор
Столкнулся с проблемой памяти проекта.
Контекста стало настолько много, что в какой-то момент проект начал просто теряться: модель уже не всегда помнила, что мы делали, почему приняли то или иное решение и по какой иерархии вообще двигаемся дальше.

В итоге лучшее, что пока придумал — вынести «память» самого проекта отдельно.

Теперь основные решения, текущее состояние, ограничения и следующие шаги фиксируются внутри самого проекта. Плюс периодически делаются checkpoints — условные контрольные снимки состояния (CKPT-000001, CKPT-000002, CKPT-000003 и т.д.). Старые не переписываются, а каждый новый фиксирует очередной важный этап.

Идея в том, что даже если завтра полностью закрыть все сессии и открыть проект с нуля с другой моделью, она должна восстановить всё из этих записей: где мы находимся, как сюда пришли и что делать дальше.

Посмотрим, как покажет себя на практике
Автор
@Tick9er

Посмотри LLM Wiki Карпатого. Дай оловянному https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f скажи «сделай также иначе подписку не продлю»

И там в комментах куча проектов на этой концепции тоже можно чет полезное взять
Автор
@ndr

Спасибо, реально полезно 👍
Прогнал идею на своей системе: большую часть уже по сути реализовал, но нашлись пробелы именно в навигации по накопленной истории.
Решил не делать отдельную LLM-wiki как второй источник правды, а сейчас делаю автоматически собираемый слой поверх основной памяти: карта веток/гипотез, хронология решений и проверки пропущенных связей/противоречий. Сам он ничего не решает и не хранит новую «истину» — его можно удалить и заново собрать из исходных записей.
Посмотрим, как покажет себя  👌
Автор
Теперь упёрся уже не в память модели, а в обычную оперативку и вычислительные ресурсы.

Сейчас часть проекта работает на небольшом VPS. Для постоянных задач его вполне хватает, но появились расчёты, которые на нём уже либо слишком тяжёлые, либо просто нецелесообразно запускать.

Пока решил такие задачи не мучить на слабом железе, а складывать отдельно и потом запускать пачкой на более мощной машине/VPS.

Интересно, кто на чём держит свои проекты?
Сколько CPU/RAM у вашего основного VPS? И если появляются тяжёлые вычисления — апгрейдите основной сервер или поднимаете отдельный мощный инстанс только на время?

Особенно интересно у тех, у кого боты + сбор данных + аналитика/исследования работают 24/7.
Автор
@Tick9er

Что у тебя занимает память скинь 

ps aux --sort=-%mem | head -n 11
Автор
@ndr

Вот что сейчас крутится 





В обычном режиме ему хватает, сам сборщик ест всего ~68 MB. 
Думаю основной VPS в перспективе поднять до 8–16 vCPU, чтобы был запас.
Но сейчас хочу прогнать довольно тяжёлый расчёт по историческим данным стакана — обработка большого объёма L2 данных и расчёт исполнимой стоимости по уровням книги. По оценке нужно уже 32–64 GB RAM, поэтому даже апгрейд основного VPS полностью вопрос не решит.
Думаю такие тяжёлые расчёты копить и периодически поднимать под них отдельную мощную машину на несколько часов/сутки. Интересно твоё мнение, как правильнее такое организовать — апгрейдить основной VPS или тяжёлые расчёты всё-таки выносить отдельно?
Автор
Tick9er: По оценке нужно уже 32–64 GB RAM
Оригинал
Это кто тебе так рассчитал, не подсказывай, мы точно знаем, кто  Никакой такой скрипт требует столько памяти. Обычный питон скрипт для просчета стаканов съест мегабайт 200

VPS не нужен тебе мощный, все такое не делается на них. Первое — оптимизируй, это бред юзать 60 гигов, ты ж не ллм модель тренируешь )

Если нужно, мощности берутся serverless on demand т.е. надо взять в аренду мощный компьют, просчитаешь что тебе надо за пару минут и за эти же пару минут и заплатишь

Это Targon, Akash, Phala, Marlin, Super Protocol и прочие их много. Подключил, дал оловянному апишку, закинул 10 баксов, дальше оловянный все сделает — возьмет в аренду, зальет, просчитает, выгрузит результаты, оплата по использованию

Таргон наверное самый простой https://targon.com у них есть агентский интерфейс для подключения одним промптом
Автор
@ndr

Спасибо, это хорошее направление.
Автор
@ndr, ты вчера оказался прав 

При расчёте зря удерживался огромный промежуточный массив, который для результата вообще не был нужен.
В итоге два полных прогона прошли успешно, дали байт-в-байт одинаковый результат, а реальное потребление памяти оказалось ~2 GB вместо прогнозируемых 32–64 GB 
Targon взял на заметку — когда действительно упрусь в вычисления, а не в кривую работу с памятью 

Спасибо за совет 👍
#71
Скрытый пост
#72
@alex2899

Прежде чем ты что-то будешь куда-то загружать, нужно оптимизировать то, что ты делаешь. Если гпт говорит тебе нужен хулиард оперативной памяти — он врет, это не нужно. Нужно припереть его к стенке, идеально другим агентом, заставить оптимизировать процесс и он «внезапно» обнаружит что хулиард не нужен, а нужно три мегабайта

Учи пайтон, ты не сможешь без этого обойтись в любом случае. А в процессе базис — пропмтить и проч
Автор
И двух дней не прошло с момента ресета недельных лимитов — и тут вот 





Claude Max 20x.
Недельный лимит: 100% used.
Причём сейчас ещё действует временный +50% boost к лимитам.
То ли баг, то ли я немного переусердствовал. Написал в поддержку
Автор 10Только для участников с 10+ постами — войдите, чтобы продолжить
Скрытый пост
#75
Ахах, да, со вторым пунктом я уже разобрался 😄
/usage довольно быстро провёл расследование: 90% расхода пришло из сессий 8+ часов, 81% — из контекста 150k+, 64% — из subagent-heavy сессий.

А потом я посмотрел одну особо «удачную» сессию: $992.64 API-equivalent usage, 1.8B cache read, Opus 100% 😂



Там я действительно разогнал workflow примерно до 15 параллельных readers. Получилось быстро — просто я, видимо, случайно изобрёл способ превратить Max 20x в Max 0x.



#76
Tick9er: просто я, видимо, случайно изобрёл способ превратить Max 20x в Max 0x.
Оригинал
Это кек ) Все делегируй дешевым китайцам. Я не могу 5х нагрузить и на 10%, при непрерывном использовании. Единственное где его выюзал недавно это когда научный конкурс был. Но неужто ты каждый день ходишь по научному краю, едва ли





К опусу можно обращаться лишь когда нужен абсолютный эдж. Основную рабочую нагрузку с миллионами токенов надо переливать
Автор
Halo! Давно ничего не писал, хоть и захожу на форум практически каждый день

Последнее время строю собственный Market Graph из сырых данных Lighter — без обычных свечей и готовых индикаторов.

Тут очень пригодилась мысль коллег: выбросить привычные свечи, идти от raw ticks/events и попробовать построить своё представление рынка. Не искать очередной индикатор или готовый паттерн, а сначала понять, как вообще рынок должна «видеть» машина.

Уже собрана первая версия: ликвидность около цены, потребление книги сделками, mark/index, изменения open interest, структура исполненных мейкеров и т.д. Пока это скорее первый рабочий «холст», на котором машина начинает видеть рынок немного иначе, чем через привычный OHLC.

Сейчас дорисовываю этот же граф на нескольких разных днях и параллельно собираю causal-ядро — только из той информации, которую реально можно знать в момент принятия решения.

План дальше максимально короткий:

свой граф → несколько устойчивых физических состояний → постепенно добавлять новые метрики и их комбинации по мере необходимости → простой тест на экономический эффект → live-forward → реальные сделки маленьким размером.

При этом хочется не скатиться в бесконечный набор признаков ради количества. Идея как раз в обратном: каждая новая метрика должна появляться потому, что текущему представлению реально чего-то не хватает, а комбинации уже будут естественно накапливаться по мере развития графа.

Если со стороны всё это выглядит красиво и последовательно, то внутри всё намного веселее 😅 Периодически от количества данных, проверок, ошибок и развилок уже реально болит голова. Иногда садишься и вообще не понимаешь, куда дальше толкать этот вагон, чтобы опять не уйти на неделю не туда.

Потом немного отпускает, собираешь всё обратно по кусочкам и двигаешь дальше, пусть даже маленькими шагами. Постоянно ощущение: «ну вот ещё чуть-чуть... вроде уже почти...», а потом находится новая проблема и ещё один круг 😄

Но когда смотришь назад, вагон всё-таки едет. Поэтому продолжаю. Должно же когда-нибудь получиться
Ну и ниже немного страшилки для глаз — первая версия того, как оно сейчас видит рынок.



#78
Ухх красотища  Сразу видно человек занят делом 
хомяки 5 трейдят [ Human, ndr, NeonX, LegendaryNoname, Voidemir ] сегодня 75 постовпик 178
© 2026 Форум Бингуру. Уходи, тебя не звали
  ⇓     ⇑