Обновить

Акт подписан, но система не работает:  суд вернул 185 млн 

В IT-проектах бытует мнение: если промежуточный акт подписан, деньги за этап не надо возвращать. Арбитражное дело, дошедшее до Верховного суда России, показало обратное.

Заказчик оплатил первый этап работ на 185,9 млн рублей, но программное обеспечение (ПО)  так  и не заработала в нужных режимах. Суд расторг контракт и взыскал всю сумму с Исполнителя, указав на отсутствие потребительской ценности результата. Разбираем, почему подписанные промежуточные акты не гарантируют оплату и какие выводы должны сделать заказчики и исполнители, чтобы не повторить эту историю.

Суть дела

Между Заказчиком и Исполнителем был заключён контракт на создание сложной информационной системы. За первый этап работ Заказчик оплатил Исполнителю 185,9 млн руб. Однако в ходе дальнейшей реализации проекта выяснилось, что система не обеспечивает требуемый функционал и не может использоваться по назначению.

Проблема

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

Решение суда

Апелляционный суд расторг  контракт и взыскал с Исполнителя 185,9 млн руб. неосновательного обогащения и почти 4 млн руб. неустойки. Кассационный суд  и Верховный Суд РФ поддержали этот вывод. Суды указали на отсутствие для Заказчика потребительской ценности результата работ и недоказанность полноценного встречного предоставления на перечисленную сумму.

Что делать, чтобы не повторилась ситуация

Для Заказчика:

· Включайте в контракт условие о потребительской ценности как критерии приёмки: не просто «акт подписан», а «система работает в заданных режимах, согласно ТЗ».

· Прописывайте право не подписывать финальный акт до подтверждения работоспособности системы в реальных условиях.

· Фиксируйте в договоре конкретные сценарии использования и метрики, по которым будет проверяться результат.

· Проводите независимую экспертизу до подписания итогового акта.

 

Для Исполнителя:

· Не полагайтесь на подписанные промежуточные акты как на гарантию оплаты — суд смотрит на итоговый результат.

· Перед сдачей этапа убеждайтесь, что функционал соответствует технической документации и может быть проверен Заказчиком.

· Фиксируйте письменное согласование изменений и уточнений, чтобы избежать споров о несоответствии результата ожиданиям.

· Включайте в договор ограничение ответственности по объёму и срокам, если это возможно.

Если проект зашёл в тупик, а Исполнитель ссылается на подписанные акты — это не приговор.

Провожу анализ ситуации на стыке IT, права и финансов.

Пишите @RRSadykov

 

 

Теги:
+1
Комментарии5

Как мы запустили Qwen3.8–27B целиком на RTX 5060 8 GB и получили ~30 токенов/с

Наш проект называется ExVRAM Lab. Это открытая исследовательская лаборатория, в которой мы проверяем, насколько большие локальные LLM можно запускать на обычных видеокартах с ограниченным объёмом VRAM, если использовать ultra‑low‑bit quantization, полное размещение весов на GPU и существующие open‑source inference‑технологии.

ExVRAM расшифровывается как Exchange Compute for VRAM. Основная идея проекта — в ряде сценариев выгоднее потратить часть свободной вычислительной мощности GPU на работу с более компактным представлением весов, чем хранить часть модели в оперативной памяти и постоянно передавать данные через PCIe.

Когда мы начинали проект, исходный вопрос был достаточно простой: можно ли запустить dense‑модель примерно на 27 миллиардов параметров на видеокарте всего с 8 ГБ VRAM так, чтобы она не просто «запустилась», а работала полностью на GPU, поддерживала длинный контекст и обеспечивала нормальную интерактивную скорость генерации.

В качестве основной тестовой системы мы используем NVIDIA GeForce RTX 5060 8 GB на архитектуре Blackwell. Основная модель в текущих экспериментах — Qwen3.8–27B.

Сначала результат выглядел не слишком впечатляюще. Модель запускалась, но значительная часть весов оставалась в системной памяти. Около 5,7 GiB весов находилось на GPU, ещё примерно 2,5 GiB — на CPU. Скорость генерации составляла порядка 3,8–5,5 токена в секунду.

При этом сама видеокарта была загружена далеко не полностью.

Это стало одним из первых важных наблюдений проекта. Проблема заключалась не столько в нехватке вычислительной мощности RTX 5060, сколько в том, что часть decoder weights находилась в RAM. Во время autoregressive generation данные приходилось постоянно передавать между CPU и GPU через PCIe.

Как мы запустили Qwen3.8–27B целиком на RTX 5060 8 GB и получили ~30 токенов/с

Публикации