Там количество документации умопомрачительное. Прочитать и проанализировать её не сможет ни одна нейросеть в мире. Это ли не "obscurity" ?
В 90-х года мне доводилось администрировать цифровые телефонны станции Nortel Meridian-1, чем-то они похожи на IBM-овских динозавров. Так вот, документации к Meridian-1 было около 80-ти жирных томов. Что либо найти в них можно было если только ты абсолютно точно уверен в каком именно томе искать. При этом нужно быть хорошо знакомым с используемой терминологией, а она там очень специфическая. IBM это вообще отдельный мир.
Помоему это такой способ конкурентной борьбы. IBM вырастила себе поляну и сама её топчет. Как только они переведут свои сервисы на что-то более человечное (Java, Scala) и стандартное x86 железо, их тут же потеснят с этого сочного рынка. Все эти IBM i/z и прочие однобуквенные платформы - типичный пример дичайшего переусложнения. Есть мнение, что эти машины тратят более половины своих вычислительных ресурсов только на организацию многоуровневой виртуализации, трансляцию форматов данных и протоколов между ними.
Ага, тривиальна, если не лезть в CMakeLists и не смотреть какие опции там используются,
Во-первых, в CMakeLists смотреть не надо, надо читать README.md, это если Вас интересуют какие-то специализированные опции. Во-вторых, там подефолту всё нормально отстроено, никаких опций крутить не требуется. Инструкция, которую я привел выше, рабочая! cmake автоматом подхватывает CUDA если он у Вас есть и собирает всё что требуется. Я вот буквально вчера запустил llama.cpp на RTX 4060, никаких опций не накручивал.
При запуске llama-server пришлось, правда, ограничить число слоёв для оффлоада на GPU (-ngl 20) из-за малого обьема VRAM памяти на карточке.
За свой небольшой опыт с линуксом, если я вижу make , я до победного ищу готовые бинарники.
Какой-то у Вас неправильный опыт. Если я вижу Makefile, то беру и собираю из исходников. Я вообще стараюсь держать всё в исходниках, кроме компилятора. Как раз потому, что когда-то их обязательно сломают и я смогу откатиться на требуемую мне версию (может быть даже исправить проблему самостоятельно), а не судорожно искать и качать новые бинарники ко всему стеку используемого софта со всеми его зависимостями.
Похоже что автор статьи "слышал звон". llama.cpp это давно уже не просто библиотека, а целая система с кучей плагинов и собственным Web сервером с поддерждкой различных API. Установка llama.cpp выглядить до боли тривиальна: cmake . && make install. Установка моделей полность автоматизирована, просто указываете название модели и он выкачивает её с Huggingface и запускает. Какое еще нужно продуктовое мышление ?
$ git clone https://github.com/ggml-org/llama.cpp.git
$ cmake .
$ make && make install
# далее
$ llama-cli --help
# Web сервер с чатом можно запустить вот так:
$ llama-server -m $MODEL --host 1.2.3.4 --port 8080
# далее подключаетесь Web браузером на 1.2.3.4:8080 и получаете
# полноценный интерфейс к ИИ чат-боту
И да, llama.cpp поддерживает FIM API позволяя подключать vim, vscode и прочие IDE.
Мы держим свой локальный сервер на базе llama.cpp с моделями DeepSeek для чата и для FIM. Спасибо Георгию за то, что сделал инферренс моделей простым и доступным для старпёров умеющих в make.
Что такое Ollama - понятия не имею. Очень похоже, что это еще одни паразиты из лагеря питонистов. В который раз убеждаюсь, что питонисты без поддержки сишников и плюсоводов ничего толком сделать не могут, только обертку красивую нарисовать и вперед - клянчить деньги инвесторов. На Hacker News таких добрая половина, а в составе YC - все 100% стартапов.
SDH это не только телефония, это транспорт для многих других систем цифровой связи, в том числе и для IP. Так как IP начал превалировать, а стоимость порта и оборудования для преобразования STM в Ethernet уходит далеко в космос, то операторы стали отказываться от такого вида сетей и строить сразу всё на Ethernet, благо MPLS подвезли вовремя, тут же телефония и телевидение переехали на IP.
Проблема в том, что синхронные сети типа SDH это очень неэффективное использование дорогостоящего ресурса. Пакетная коммутация потому и вытеснила коммутацию каналов, потому что позволяет более рационально использовать полосу пропускания и является более гибкой, с точки зрения управления сетью, технологией, не говоря уже о стоимости порта (STM1 в десятки раз дороже обычного GigabitEthernet, при том что скорость всего 155Мбит/с).
Пакетная коммутация, в общем-то, при грамотной настройке, не должна создавать проблем для передачи голоса и модема поверх голосового тракта, все технические средства для этого имеются. Беда в ленивости и низкой квалификации современных инженеров эксплуатирующих сети.
SDH очень чувствителен к ошибкам, повышенный BER может приводить к сбою синхронизации и развалу сети. SDH требует точного источника синхронизации - одного на всю сеть. Очевидно, что в Ethernet таких проблем нет, ошибки могут приводить к потере пакетов, которые решаются ретрансмитами или избыточным кодированием. Локальная ошибка на сети Ethernet не является глобалной для всей сети, как это часто бывает в SDH.
Если Сеть работает стабильно, нет потерь и аномалий в виде ассиметричного рутинга, то модем поверх PCM кодеков работать будет. Но на дальних дистанциях (через континент) скорее всего уже не свяжется просто из-за лага.
Ну и ради прикола, попробуйте связать модемы и нагрузить сеть паралелльно перекачкой чего нибудь тяжелого, через пару секунд Вас ожидает NO CARRIER.
Вопрос, как я понимаю, стоит не в том чтобы два мопеда повязать. А в том, чтобы сделать эту через существующую современную ТфОП. На тот случай, когда IP сеть ляжет на пузо ровно.
Все верно. Только остался ли еще у кого-то SDH ? В начале 2000-х я занимался развертыванием синхронных сетей, но это дело было быстро показало свою несостоятельность (дорого и бесполезно) и было вымещено традиционным теперь Ethernet-ом с MPLS.
В более старых сетях используются потоки E1. Там никаких потерь нет.
Вы отстали лет на двадцать. Синхронные сети уже давно нигде и ни кем не используются (ну почти), пакетная коммутация и Ethernet вытеснили абсолютно всё. Операторы связи уже второй десяток лет гоняют голосовой трафик поверх IP различными способами, от традиционного RTP (VoIP), до всякой эзотерики (VoMPLS).
Модемная связь может работать по верх такого VoIP канала, но для этого требуется выполнение одного из условий:
Использование кодеков PCMA (или PCMU) на всём протяжении, от абонента до абонент, без транскодинга. Не должно быть потерь и девиации (т.е. когда пакеты приходят в разнобой с разной задержкой).
Помощь со стороны аппаратуры (V.92,V.152 и прочие): VoIP шлюзы умеют распознавать модемный трафик и инкапсулировать его в отдельные вид пакетов с приоретизацией.
На сколько мне известно, на сетях крупных провайдеров, таких как Ростелеком, всё это дело отстроено и работает. Пару лет назад мои коллеги устраивали масштабное тестирование резервной (модемной) связи из деревень с городским центром в рамках одного гос проекта. В подавляющем большинстве всё работало, а там где не работало сделано предписание операторам устранить неисправность.
Где модемная связь может не работать, так это на абонентских линиях типа GPON и прочих подключениях через Ethernet, а также на беспроводных подключениях. Но и там это можно заставить работать. Если оператор связи предоставляет услуги классической телефонии, т.е. в домешнем маршрутизаторе есть порт FXS с аналоговой линией (разъем RJ-11), то у абонента есть полное право напрячь оператора чтобы он отстроил своё оборудование соответствующим образом. Проблема только в том, как пользователю это проверить. :-)
Там количество документации умопомрачительное. Прочитать и проанализировать её не сможет ни одна нейросеть в мире. Это ли не "obscurity" ?
В 90-х года мне доводилось администрировать цифровые телефонны станции Nortel Meridian-1, чем-то они похожи на IBM-овских динозавров. Так вот, документации к Meridian-1 было около 80-ти жирных томов. Что либо найти в них можно было если только ты абсолютно точно уверен в каком именно томе искать. При этом нужно быть хорошо знакомым с используемой терминологией, а она там очень специфическая. IBM это вообще отдельный мир.
А их никто и не пишет для IBM кроме самой IBM.
Это не безопасность, это "security through obscurity".
Помоему это такой способ конкурентной борьбы. IBM вырастила себе поляну и сама её топчет. Как только они переведут свои сервисы на что-то более человечное (Java, Scala) и стандартное x86 железо, их тут же потеснят с этого сочного рынка. Все эти IBM i/z и прочие однобуквенные платформы - типичный пример дичайшего переусложнения. Есть мнение, что эти машины тратят более половины своих вычислительных ресурсов только на организацию многоуровневой виртуализации, трансляцию форматов данных и протоколов между ними.
Во-первых, в CMakeLists смотреть не надо, надо читать README.md, это если Вас интересуют какие-то специализированные опции. Во-вторых, там подефолту всё нормально отстроено, никаких опций крутить не требуется. Инструкция, которую я привел выше, рабочая! cmake автоматом подхватывает CUDA если он у Вас есть и собирает всё что требуется. Я вот буквально вчера запустил llama.cpp на RTX 4060, никаких опций не накручивал.
При запуске llama-server пришлось, правда, ограничить число слоёв для оффлоада на GPU (-ngl 20) из-за малого обьема VRAM памяти на карточке.
Какой-то у Вас неправильный опыт. Если я вижу Makefile, то беру и собираю из исходников. Я вообще стараюсь держать всё в исходниках, кроме компилятора. Как раз потому, что когда-то их обязательно сломают и я смогу откатиться на требуемую мне версию (может быть даже исправить проблему самостоятельно), а не судорожно искать и качать новые бинарники ко всему стеку используемого софта со всеми его зависимостями.
А это, постите, кто ?
80ГГц / 5ГБит/сек... да, далеко ускакал прогресс. В конце 90-х мы ставили "релейки" на 4-е порта E1 между узлами и радовались диким скоростям. :-)
Я думал, что Георгий Герганов наш соотечественник, оказывается - потомственный болгагин. :-)
Похоже что автор статьи "слышал звон". llama.cpp это давно уже не просто библиотека, а целая система с кучей плагинов и собственным Web сервером с поддерждкой различных API. Установка llama.cpp выглядить до боли тривиальна:
cmake . && make install. Установка моделей полность автоматизирована, просто указываете название модели и он выкачивает её с Huggingface и запускает. Какое еще нужно продуктовое мышление ?И да, llama.cpp поддерживает FIM API позволяя подключать vim, vscode и прочие IDE.
Мы держим свой локальный сервер на базе llama.cpp с моделями DeepSeek для чата и для FIM. Спасибо Георгию за то, что сделал инферренс моделей простым и доступным для старпёров умеющих в make.
Что такое Ollama - понятия не имею. Очень похоже, что это еще одни паразиты из лагеря питонистов. В который раз убеждаюсь, что питонисты без поддержки сишников и плюсоводов ничего толком сделать не могут, только обертку красивую нарисовать и вперед - клянчить деньги инвесторов. На Hacker News таких добрая половина, а в составе YC - все 100% стартапов.
SDH это не только телефония, это транспорт для многих других систем цифровой связи, в том числе и для IP. Так как IP начал превалировать, а стоимость порта и оборудования для преобразования STM в Ethernet уходит далеко в космос, то операторы стали отказываться от такого вида сетей и строить сразу всё на Ethernet, благо MPLS подвезли вовремя, тут же телефония и телевидение переехали на IP.
Проблема в том, что синхронные сети типа SDH это очень неэффективное использование дорогостоящего ресурса. Пакетная коммутация потому и вытеснила коммутацию каналов, потому что позволяет более рационально использовать полосу пропускания и является более гибкой, с точки зрения управления сетью, технологией, не говоря уже о стоимости порта (STM1 в десятки раз дороже обычного GigabitEthernet, при том что скорость всего 155Мбит/с).
Пакетная коммутация, в общем-то, при грамотной настройке, не должна создавать проблем для передачи голоса и модема поверх голосового тракта, все технические средства для этого имеются. Беда в ленивости и низкой квалификации современных инженеров эксплуатирующих сети.
SDH очень чувствителен к ошибкам, повышенный BER может приводить к сбою синхронизации и развалу сети. SDH требует точного источника синхронизации - одного на всю сеть. Очевидно, что в Ethernet таких проблем нет, ошибки могут приводить к потере пакетов, которые решаются ретрансмитами или избыточным кодированием. Локальная ошибка на сети Ethernet не является глобалной для всей сети, как это часто бывает в SDH.
У GSM 2G синхронные каналы только до коммутатора, дальше уже давно всё на пакете.
В этом деле главное - не привлечь к себе санитаров. ;)
Тут некоторые комментаторы пишут, что на сетях Ростелекома до сих пор работает SDH. Скорее всего ТфОП тоже ляжет, но не так быстро как IP.
Если Сеть работает стабильно, нет потерь и аномалий в виде ассиметричного рутинга, то модем поверх PCM кодеков работать будет. Но на дальних дистанциях (через континент) скорее всего уже не свяжется просто из-за лага.
Ну и ради прикола, попробуйте связать модемы и нагрузить сеть паралелльно перекачкой чего нибудь тяжелого, через пару секунд Вас ожидает NO CARRIER.
Вопрос, как я понимаю, стоит не в том чтобы два мопеда повязать. А в том, чтобы сделать эту через существующую современную ТфОП. На тот случай, когда IP сеть ляжет на пузо ровно.
Всю работу выполнила Cisco ATA. Хвала цисочным инженерам.
Вопрос: где Вы раздобыли в наше время Курьера ? :)
Все верно. Только остался ли еще у кого-то SDH ? В начале 2000-х я занимался развертыванием синхронных сетей, но это дело было быстро показало свою несостоятельность (дорого и бесполезно) и было вымещено традиционным теперь Ethernet-ом с MPLS.
Вы отстали лет на двадцать. Синхронные сети уже давно нигде и ни кем не используются (ну почти), пакетная коммутация и Ethernet вытеснили абсолютно всё. Операторы связи уже второй десяток лет гоняют голосовой трафик поверх IP различными способами, от традиционного RTP (VoIP), до всякой эзотерики (VoMPLS).
Модемная связь может работать по верх такого VoIP канала, но для этого требуется выполнение одного из условий:
Использование кодеков PCMA (или PCMU) на всём протяжении, от абонента до абонент, без транскодинга. Не должно быть потерь и девиации (т.е. когда пакеты приходят в разнобой с разной задержкой).
Помощь со стороны аппаратуры (V.92,V.152 и прочие): VoIP шлюзы умеют распознавать модемный трафик и инкапсулировать его в отдельные вид пакетов с приоретизацией.
На сколько мне известно, на сетях крупных провайдеров, таких как Ростелеком, всё это дело отстроено и работает. Пару лет назад мои коллеги устраивали масштабное тестирование резервной (модемной) связи из деревень с городским центром в рамках одного гос проекта. В подавляющем большинстве всё работало, а там где не работало сделано предписание операторам устранить неисправность.
Где модемная связь может не работать, так это на абонентских линиях типа GPON и прочих подключениях через Ethernet, а также на беспроводных подключениях. Но и там это можно заставить работать. Если оператор связи предоставляет услуги классической телефонии, т.е. в домешнем маршрутизаторе есть порт FXS с аналоговой линией (разъем RJ-11), то у абонента есть полное право напрячь оператора чтобы он отстроил своё оборудование соответствующим образом. Проблема только в том, как пользователю это проверить. :-)