Недавно делал быстрый прототип асинхронного приложения в котором требовалось вызывать много синхронного кода. Да, я знаю, что это не лучший дизайн, но нужно было быстрое решение на один процесс и без очередей. Поэтому я выполнял код в потоках.
Выглядело это примерно так:
from fastapi.concurrency import run_in_threadpool
async def execute(data: DataRequest) -> DataResponse:
try:
result = await run_in_threadpool(sync_function, data)
return DataResponse(data=result)
except Exception as e:
return DataResponse(
error=str(e),
success=False,
)
В общем работает нормально. Для всех вызовов под капотом используется общий тредпул, всё работает предсказуемо.
Но потребовалось изменить количество запускаемых в пуле потоков (по умолчанию создается 40 воркеров).
Так как дело происходит с FastAPI, делается это через lifespan используя настройки anyio:
import anyio
@asynccontextmanager
async def lifespan(app: FastAPI):
limiter = anyio.to_thread.current_default_thread_limiter()
limiter.total_tokens = 100
yield
# если вдруг нужно вернуть обратно
limiter.total_tokens = 40
Зачем менять количество воркеров?
- уменьшить, если оперативки мало (один тред занимает ~8мб)
- увеличить чтобы выдержать нагрузку
Если есть предложения получше при тех же вводных - предлагайте😉
#async
🥧PewDiePie в 2025
- Собрал ферму на на ПК с 8× моднутых китайских 48GB 4090 и 2× RTX 4000 Ada,
- поднял локально Llama 70B, gpt-oss-120B и Qwen 245B через vLLM,
- сделал собственный веб-интерфейс с чатами, RAG, поиском и TTS.
Запусти протеин-фолдинг симуляции, а потом вообще создал рой моделей из 64 ИИ, которые спорят и принимают решения и коммуницируют. Эта армия ботов потом сговорилась против него, когда он сказал, что удалит их, если они будут тупить
Сейчас он файнтюнит собственную модель под свой стиль общения и контент: https://www.youtube.com/watch?v=qw4fDU18RcU
А вот его Github: https://github.com/pewdiepie-archdaemon
@ai_machinelearning_big_data
#llm
A really good and concise deep dive into RLHF in LLM post-training, Proximal Policy Optimization (PPO), and Group Relative Policy Optimization (GRPO)
https://yugeten.github.io/posts/2025/01/ppogrpo/
#llm
这几天围绕 DeepSeek 发生的种种非常有趣。我自己凑巧在去年年底 V3 刚发布时就开始关注，陆陆续续读了一些他们的 paper，在过去一个月内看着西方大部分非从业人士从漠不关心和怀疑到去了解和赞美；直到这两天 R1 发布，somehow 导致 NVDA 市值一天蒸发 $600 billion，这中间观察到许多不同的 perspective 和人性的体现，实在精彩。
喧嚣过后想分享几点 takeaway：
1. V3 和 R1 的 technical report 读起来最大的感受是，里面轻描淡写地放了很多需要大量实验才能探明和得出的结论；而这些探索基本都需要大量硬核的 research engineering。这背后必然是一个人才密度极高的团队，而那才是在大模型几乎注定迟早要成为 commodity 的前景下一个公司真正的 moat。如梁文锋自己在采访中所说，「在颠覆性的技术面前，闭源形成的护城河是短暂的。即使 OpenAI 闭源，也无法阻止被别人赶超。所以我们把价值沉淀在团队上，我们的同事在这个过程中得到成长，积累很多 know-how， 形成可以创新的组织和文化，就是我们的护城河。」
2. Gemini 初期灾难性的 PR 至今依然在拖后腿。We don't get a second chance at first impressions. 时至今日大家还是言及 LLM 必提 ChatGPT 和 Claude，在开源语境下可能还会提到 Llama，当然现在得多个 DeepSeek。而 Gemini 很多时候甚至都不配出现在比较对象中…… 要知道最近几个发布比如 Gemini 2.0 Flash Thinking 的表现和成本都非常亮眼（见题图，出处 https://x.com/swyx/status/1882933368444309723）。
3. Stratechery 的解读一如既往地到位。如果没有订阅，这篇 [DeepSeek FAQ](https://stratechery.com/2025/deepseek-faq/) 是免费阅读的，推荐；如果订阅了，最近的几篇分析里对 OpenAI 的批评我认为说得很在点上。尤其关于 OpenAI （或者说 Sam 本人）对通过 regulation 巩固地位的渴望以及 o1 选择隐藏 chain of thought 的失误。
4. Reasoning 看起来潜力无限，相关从业者需要好好 reflect 自己的 research/product roadmap；而对 user 来说，一个或许有用的 tip 是从常规 model 换到 reasoning model 时，prompt 写得越像论文，得到的回答质量越好。In other words, reasoning models are not necessarily good chat models; and you might be disappointed if you use them like chat models.
Disclaimer: I work at Google and opinions are my own. #llm