Возможно, стоит пояснить разницу между синхронизацией из thread/process-safe и синхронизацией с помощью Lock🤔
Наша задача — заставить разные процессы и потоки обращаться к базе данных (или любым другим ресурсам) последовательно. Чтобы не случилось так называемого race condition, то есть состояние гонки. Это когда разные потоки или процессы пытаются одновременно что-то сделать с одним и тем же ресурсом.
В этом случае нам нужна какая-то логика ограничения. Пока один процесс не завершил своё действие, другие не могут получить доступ к ресурсу.
Так вот, thread-safe и process-safe означает что отдельно взятые операции записи в БД гарантированно будут последовательны. Запросы из разных процессов или потоков выстроятся в очередь и не будут мешать друг другу. Лучше всего когда этот блок реализован на уровне БД в виде атомарных операций или ещё как-то.
Но зачем нам тогда еще дополнительный Lock?
Этот способ синхронизации используется когда процесс никак не укладывается в одно действие и должен сделать множество операций прежде чем дать доступ следующему. В этом случае процесс ставит некий глобальный Lock на ресурс и никто другой, даже получив законное право на доступ, не может ничего сделать. Все ждут пока этот Lock не будет снят.
Это решается на уровне приложения и правильность реализации полностью в вашей ответственности. Например, если забыли разблокировать или сделали перекрёстный Lock (Deadlock как на картинке), то всё зависнет в бесконечном ожидании.
#basic
🚀 OpenAI **gpt-oss** с ультрадлинным контекстом!
Unsloth выпустили Flex Attention, который даёт до 61K контекста для gpt-oss bf16 при обучении на GPU с 80GB.
📊 Что это значит:
- 8× больше контекста
- потребляет на 50% меньше VRAM
- 1.5× быстрее по сравнению с альтернативами (включая FA3)
Для BF16 LoRA теперь можно тренировать с ~60K контекстом на одной H100 80GB.
🔗 Подробнее: https://docs.unsloth.ai/basics/long-context-gpt-oss-training
@ai_machinelearning_big_data
#Unsloth#OpenAI#gptoss#chatgpt
⚡️GGUF-версии GPT-OSS от Unsloth.
Unsloth конвертировали обе GPT-OSS (20B и 120B) и исправили ошибки, чтобы повысить качество инференса.
🟡Оптимальный сетап:
🟢20B работает со скоростью более 10 токенов/с при полной точности на 14 ГБ оперативной памяти.
🟢120B с полной точностью будет давать >40 токенов/с на примерно 64 ГБ ОЗУ.
Минимальных требований для запуска моделей нет, запуститься можно даже если у вас всего 6 ГБ и только CPU, но инференс будет медленнее.
GPU не требуется , особенно для модели 20B, но его наличие значительно увеличивает скорость вывода (~80 токенов/с). С чем-то вроде H100 можно получить пропускную способность 140 токенов/с, и это значительно быстрее, чем у OpenAI в ChatGPT.
Модели можно запустить через llama.cpp, LM Studio или Open WebUI. Если модель 120B слишком медленная, попробуйте версию 20B - она очень быстрая и работает не хуже o3-mini.
Помимо моделей формата GGUF c полной точностью, Unsloth сделали версии с 4-bit и 16-bit точностью. 4-бинтый квант, кстати, можно файнтюнить на 24 ГБ VRAM.
📌 Подробная пошаговая инструкция по локальному запуску и файнтюну - в документации Unsloth.
🟡Набор моделей
🟡Документация
@ai_machinelearning_big_data
#AI#ML#GPTOSS#GGUF#Unsloth
🖥gpt-oss работает на специальном формате промптов — Harmony, и без него модель просто не будет выдавать корректные ответы.
Зачем нужен Harmony?
Этот формат нужен для:
— 🧠 генерации chain of thought рассуждений
— 🔧 корректного вызова функций и использования инструментов
— 📦 вывода в разные каналы: обычный ответ, reasoning, tool call
— 🗂️ поддержки tool namespaces и иерархических инструкций
💡 Harmony имитирует OpenAI Responses API, так что если вы с ним работали — будет легко освоиться.
👉 Если вы используете gpt-oss через HuggingFace, Ollama или vLLM, волноваться не нужно.
Но если строите свой пайплайн — обязательно изучитегайд по Harmony.
Без него модель просто не будет работать как надо.
pip install openai-harmony
# or if you are using uv
uv pip install openai-harmony
@ai_machinelearning_big_data
#gptOSS#Harmony#OpenAI#LLM#PromptEngineering