Infrastructure


Paper/Blog Link My Issue
#NLP #LanguageModel #Quantization #LLMServing #KV Cache #Compression #Initial Impression Notes Issue Date: 2026-04-22 GPT Summary- KVキャッシュメモリは、レイテンシーに敏感な小規模バッチと高スループットワークロードの同時サポートにおけるボトルネックとなっている。多くの圧縮手法は実用的な制約に違反し、デプロイメント時の有効性を制限している。本研究では、最小限の4ビット量子化手法を特定し、INT4量子化とブロック対角Hadamard回転の組み合わせが最良のトレードオフを実現することを発見した。実装により、エンドツーエンドのオーバーヘッドを抑え、INT4スループットに匹敵する性能を達成。結果として、KVキャッシュ圧縮はシステム共設計の問題であり、軽量な手法が実用的な精度を提供することを示した。 Comment

元ポスト:

Loading…

github: https://github.com/togethercomputer/saw-int4

以下のRequirementsがある
- MHA modelsのみをサポートしており、MLA、あるいはMHA以外のアーキテクチャはサポートされていない
- 実装かれていないだけなのか、理論的に無理なのかは区別がついていない
- Prefill backend: fa3
- Decode backend: triton




Paper/Blog Link My Issue
#EfficiencyImprovement #NLP #LanguageModel #LLMServing #Selected Papers/Blogs #reading #One-Line Notes #KV Cache #needs-revision #Author Thread-Post Issue Date: 2026-04-18 GPT Summary- Prefill-decode（PD）のデプロイにはKVCache転送が制限要因となっており、従来のアテンションモデルは大容量のKVCacheトラフィックを生成する。ハイブリッドアテンションアーキテクチャはKVCacheサイズを削減するが、データセンター間の運用に問題が残る。そこで、Prefill-as-a-Service（PrfaaS）を提案し、プリフィル処理を専用クラスタにオフロードして効率的なKVCache転送を実現。これにより、リソースの独立したスケーリングを可能にし、実績として、PrfaaSを用いた異種デプロイメントは従来よりも高い提供スループットを達成。 Comment

元ポスト:

Loading…

LLM servingにおいて、prefillはcompute-intensiveで、decodeは（kv cacheが肥大化するため）memory-intensiveであるという特性があるため、（それぞれ得意な処理は得意なノードに任せるため）prefillとdecodeを分離して異なるノードで実施するprefill-decode disaggreagated servingというインフラのアーキテクチャが超巨大モデルでは主流だが、prefill-decode間でKV Cacheを転送しなければならないため、このような分離は同じ計算機クラスター内のRDMA(Remote Direct Memory Access)が可能なノード間に限定されるのが一般的である。

しかし、compute/memory特化型のリソースは通常チップの種類と物理的な場所の両方に制約されてプールされるので、両方のハードウェアがRDMAのような密結合なドメインで利用できないという欠点がある。このため、クラスターを超えてPD分離をしたいのだが、KV Cacheの転送が結局のところボトルネックとなる。現在のモデルはSparse/LinearなアテンションによってKV Cacheに必要なリソースが一桁減っているが、それでもnaiveにクラスタを跨いでPD分離をすると、突発的なリクエストのバーストや、不均一なPrefix Cacheの分布、クラスター間の帯域幅の変動などによって、計算効率が低下してしまう。

そのため、提案手法では、高スループットな長文のprefillに特化した独立クラスタを作り、ローカルにキャッシュされていない（主に長文の）、　prefillのみを同クラスタにオフロードし、短いリクエストはローカルでPDを実施するようなアプローチをとる。こうしてprefill特化クラスタによって生成されたKV Cacheはdecode可能なPDクラスタに対してイーサネットを介して転送される。これは選択的なオフロードであり、帯域幅が制限された経路で非効率な短いリクエストを送信を避けて、prefillの高速化が重要なリクエストのみをクラスタ間転送に集中させるという考え方に基づく。

これを実現するためには、(i)長いリクエストのみをオフロードするルーティングの仕組みと、(ii)ネットワークの輻輳を制御するための、帯域幅を考慮したスケジューラ、(iii)リクエスト長、キャッシュ配置、利用可能なクラスタの帯域幅を総合的に考慮してKV Cache全体を効率的を保ちながら管理するグローバルKV Cacheマネージャが必要。
image

このようなアーキテクチャを1T級のKimi Linearモデルで実験した結果、スループットが1.54倍、TTFTが64%改善した、という感じらしい。




Paper/Blog Link My Issue
#EfficiencyImprovement #NLP #LanguageModel #ReinforcementLearning #Architecture #SoftwareEngineering #read-later #On-Policy #Stability #One-Line Notes #Author Thread-Post Issue Date: 2026-03-28 GPT Summary- ProRL Agentは、マルチターンのLLMエージェントにおける強化学習トレーニングを支援するためのAPIサービスであり、ロールアウトのライフサイクル全体を提供するスケーラブルなインフラです。標準化されたサンドボックス環境を通じて、多様なエージェント駆動タスクに対応し、ソフトウェア工学やSTEM関連のタスクで検証されています。ProRL Agentはオープンソースで、NVIDIA NeMo Gymに統合されています。 Comment

元ポスト:

Loading…

処理が重いロールアウトを独立したhttp serviceとして扱い（rollout-as-a-service)、モデルのtrainingと分離することで、リソース分離、可搬性、拡張性を向上させる。
image




Paper/Blog Link My Issue
#NLP #LanguageModel #SoftwareEngineering #read-later Issue Date: 2026-02-28 GPT Summary- エージェント型LLM推論において、KVキャッシュのストレージI/Oが性能に大きく影響している。従来のアーキテクチャでは、KVキャッシュの読み込みがボトルネックとなり、システム全体のスループットが制約されている。DualPathは、このボトルネックを解消するためのデュアルパスKVキャッシュ読み込みシステムであり、デコードエンジンへの新たなストレージ経路を提供する。これにより、データ転送が効率化され、負荷が動的にバランスされる。実運用のモデル評価では、DualPathがオフライン推論スループットを最大1.87倍、オンライン提供スループットを平均1.96倍向上させることが示された。 Comment

元ポスト:

Loading…

ポイント解説:

Loading…




Paper/Blog Link My Issue
#Pretraining #NLP #LanguageModel #SoftwareEngineering #mid-training #PostTraining #Stability Issue Date: 2026-02-03 GPT Summary- FT-HSDPという新しいトレーニングパラダイムを提案し、故障耐性を持つデータ並列レプリカを活用。故障時には影響を受けたレプリカのみがオフラインとなり、他のレプリカはトレーニングを継続。FTARプロトコルと非ブロッキングキャッチアップを用いることで、故障回復時間を短縮し、有効なトレーニング時間を大幅に増加。精度への悪影響もないことを確認。 Comment

元ポスト:

Loading…

100k GPU🤯




Paper/Blog Link My Issue
#NLP #LanguageModel #Architecture #SoftwareEngineering #read-later #Selected Papers/Blogs Issue Date: 2026-04-11 GPT Summary- Step-3は、321Bパラメータの大規模言語モデルで、デコードコストの最小化を目的としたハードウェア意識のモデル-システム共設計を導入。主な革新点は、Multi-Matrix Factorization Attention (MFA)による計算量削減とAttention-FFN Disaggregation (AFD)による分散推論システムの構築。これにより、DeepSeek-V3やQwen3 MoE 235Bと比較して理論的デコードコストを大幅に低下させ、特に長文脈での利得が顕著。Hopper GPU上で最大4,039トークン/秒のデコードスループットを達成し、LLMデコードの新たなパレート前線を確立した。 Comment

元ポスト:

Loading…

所見:

Loading…




Paper/Blog Link My Issue
#ComputerVision #NLP #AIAgents #SoftwareEngineering #ComputerUse #read-later #VisionLanguageModel #Initial Impression Notes Issue Date: 2026-04-07 GPT Summary- コンピュータ利用エージェントの訓練には、リソース効率の良いスケーラブルなOS環境が必要であり、OSGymを提案。主な特徴は、(1) 故障の分散型管理でシステム信頼性を向上、(2) CPUボトルネック対策によるオーバーヘッド軽減、(3) コピーオンライトによるディスク利用の大幅削減、(4) 堅牢なフォールトリカバリの実装。OSGymは1000以上のOSレプリカを管理し、コストを90%削減しつつ、高速なマルチターン軌道生成を実現。これにより、汎用的なエージェント研究の基盤を提供。 Comment

元ポスト:

Loading…

ソースやcodeをオープンにはしないのだろうか。と思ったら、リプにoss releaseの準備をしていると言及があった。




Paper/Blog Link My Issue
#RecommenderSystems #Tutorial #python #Slide #KeyPoint Notes Issue Date: 2021-10-21 Comment

・ママ向けのQ&AサービスにおけるレコメンドとMLパイプラインについて紹介



◆レコメンドエンジンの変遷

　・Tensorflowで実装したMFから始まり、その後トピックを絞り込んだ上で推薦するためにLDAを活用したレコメンド、最終的にSoftmax Recommendationを開発

　　* Softmax Recommendation: https://developers.google.com/machine-learning/recommendation/dnn/softmax

　　* ユーザプロファイル（e.g. 行動ベクトル, ユーザの属性情報）等を入力とし、hidden layerをかませて最終的にアイテム次元数分のスコアベクトルを得る手法

　　* 行動ベクトル=ユーザが過去にクリックしたQ&Aだが、質問ベクトルを得るために内容テキストは利用せず行動ログ+word2vecで学習

　　* 類似質問検索による定性評価の結果良い結果、関連質問を抽出できるベクトルとなっていることを確認

　→ レコメンド手法の変遷につれ、ベンチマークを上回るようになっていった

◆MLパイプラインについて
- AWS Step FunctionsとAmazon Sagemakerを利用
- AWS Step Functions
* AWS上の様々なサービスをワークフローとして定義できる（json形式でワークフローを記述）
- Amazon Sagemaker
* 機械学習向けのIDE
* notebook上でのデータ分析・モデル学習、実験管理や学習済みモデルのデプロイが可能
* Sagemaker Processingを用いることで、実行したい処理やインスタンスタイプを指定することで、notebookとは別の実行環境（コンテナ）で任意のpythonスクリプトを実行可
- ワークフローの定義=AWS Stepfunctions, スクリプト実行のリソース=Sagemaker Processingとして利用

MLパイプラインについては下記資料により詳しい情報が書かれている

https://speakerdeck.com/takapy/sagemaker-studiotostep-functionswoyong-itemlopshefalse-bu-wota-michu-sou




Paper/Blog Link My Issue
#Article #ComputerVision #MachineLearning #NLP #LanguageModel #ReinforcementLearning #AIAgents #Blog #ScientificDiscovery #PostTraining #Selected Papers/Blogs #One-Line Notes #Reference Collection #Environment Issue Date: 2026-02-11 Comment

元ポスト:

Loading…

事後学習、特にAgenticな研究の民主化のためのプラットフォームの提供

所見:

Loading…

利用例 (Environment Hub):

Loading…




Paper/Blog Link My Issue
#Article #GPU-Platform #KeyPoint Notes #Reading Reflections Issue Date: 2024-11-09 Comment

元ポスト:

Loading…


A100を1時間あたり1.29$で使えるぽいので、安価である。8BのLLMをLoRAでちょろっとSFTするくらいなら、数ドルくらいでいけそう。

AWSだと、A100を8基、vCPU96、VRAM320G、RAM1152GiBのインスタンス（p4d24xlarge）が、1時間あたりオンデマンドで32.77$なのに対し、

LambdaではA100 1基あたり1.29$なので、8基で10.32$となる。したがって、コストはだいたいAWSのおよそ1/3くらいに見える（他にも安価なAWSインスタンスあるかもだが）。
ちなみにLambdaでは、vCPU124、RAM1800GiBである。

AWS参考: https://aws.amazon.com/jp/ec2/instance-types/p4/

こちらのポストも参照のこと:

Loading…


Lambdaに加え
- [runpod.io]( https://www.runpod.io)
- [vast.ai]( https://vast.ai/)

というサービスも紹介されている。

[Perplexityで3つを比較させた結果（参考; Hallucinationに注意）]( https://www.perplexity.ai/search/runpod-io-vast-ai-lambdatea100-vJgXn4osSfCqxPsxuJEPKA)

>これらのサービスの中では、Vast.aiが最も安価ですが、セキュリティと安定性に注意が必要です。RunPodは多機能で使いやすいものの、やや高価です。Lambdaは安定性が高いですが、柔軟性に欠ける面があります。選択する際は、予算、セキュリティ要件、必要な機能性を考慮して判断することが重要です。




Paper/Blog Link My Issue
#Article #NLP #MLOps #RAG(RetrievalAugmentedGeneration) #Blog #KeyPoint Notes #Reading Reflections Issue Date: 2023-11-15 Comment

低コストで社内文書に対するRAGを実現することに注力している。
以下、図はブログから引用。

image

基本的にはバッチジョブで社内文書をベクトル化しS3へ格納。アプリ起動時にS3から最新データを読み込み検索可能にしRAGするという流れ。
低コスト化のために、Embedding作成にOpenWeightの言語モデル（text-edbedding-ada002と同等の性能）を利用している。実装は基本的にllamaindexを利用している。

特に日本語テキストにおいてはtext-embedding-ada002は OpenAI の Embeddings API はイケてるのか、定量的に調べてみる, akeyhero (Akihiro Katsura), Qiita, 2023.04 において、JSTSタスクにおいてあまり性能が高くない（ただし、OpenAI の Embeddings API はイケてるのか、定量的に調べてみる, akeyhero (Akihiro Katsura), Qiita, 2023.04 での報告値は基本的にJSTSデータでfinetuningされてた結果と思われる）と言われているので、お金かけて無理して使う必要はないのかなという印象はある。




Paper/Blog Link My Issue
#Article #AWS #One-Line Notes Issue Date: 2023-08-27 Comment

データタイプやユースケースに応じてAWS上のサービスなどをマッピングしてくれているチートシート。わかりやすい。
image




Paper/Blog Link My Issue
#Article #AWS #AWSLambda #Reference Collection Issue Date: 2023-04-23 Comment

- AWS Lambda and EFS Troubleshooting

- https://www.digitalsanctuary.com/aws/aws-lambda-and-efs-troubleshooting.html

- VPC内のEFSにアクセスできるようなセキュリティーポリシーを作成してアタッチすると良いという話。in-bound, out-boundともにNFSを許可

- 【AWS】VPC Lambdaを構築したときのメモ

- https://qiita.com/aiko_han/items/6b3010250e2887206b4f

- Amazon VPC に接続されている Lambda 関数にインターネットアクセスを許可するにはどうすればよいですか?

- https://repost.aws/ja/knowledge-center/internet-access-lambda-function




Paper/Blog Link My Issue
#Article #AWS #ECS #Reference Collection Issue Date: 2023-04-16 Comment

- キャパシティプロバイダーについて

- https://dev.classmethod.jp/articles/regrwoth-capacity-provider/

- Fargateをスポットで7割引で使うFargate Spotとは？ #reinvent

- https://dev.classmethod.jp/articles/fargate-spot-detail/

- ECSでのデプロイでコケる原因ざっくりまとめ

- https://zenn.dev/isosa/articles/e371bc2d76e812

- M1 MacでビルドしたイメージをFARGATEで使おうとした時の'exec user process caused: exec format error' の対処法

- https://qiita.com/ms2geki/items/1cfb0db3f4c1aab96e75

- PythonでログをCloudWatchに出力する「Watchtower」

- https://dev.classmethod.jp/articles/python_log_cloudwatch_watchtower/




Paper/Blog Link My Issue
#Article #Tools #MLOps #Blog #Repository #API #SoftwareEngineering Issue Date: 2022-12-01 Comment

FlaskAPIを（Flaskでなくても良い）Google Cloud Run上で、TerraFormで定義したインフラ環境でデプロイするためのリポジトリ

0. リポジトリをclone
1. Flaskアプリ作成
2. FlaskアプリをDocker化
3. TerraFormのStateを保存するためのCloudStorage作成
4. TerraFormのコード作成
5. GitHub Actionでデプロイ（CI/CD）

5によってmainブランチに対するプルリクが本番環境にデプロイされる。

Cloud Runについて
https://dev.classmethod.jp/articles/gc-cloud-run/




Paper/Blog Link My Issue
#Article #MLOps #Blog #One-Line Notes #needs-revision Issue Date: 2022-04-27 Comment

機械学習（ML）システムの継続的インテグレーション（CI）、継続的デリバリー（CD）、継続的トレーニング（CT）の実装と自動化

MLOpsのレベルを0~2で表現しており、各レベルごとに何が達成されるべきかが図解されている。




Paper/Blog Link My Issue
#Article #AWS #Slide #One-Line Notes Issue Date: 2021-10-08 Comment

こちらも参照のこと

https://logmi.jp/tech/articles/324242

◆伝統的なデータウェアハウスの限界：
場当たり的にデータを蓄積し、活用しているとデータのサイロ化が生じてしまう。
サイロ化したデータを一箇所にまとめて活用できるようにしましょうというのがData Lakeの考え方。

◆データレイクアーキテクチャ
すべてのデータを一元的に保管でき、耐障害性、可用性が高く、スケーラブルで低コストな必要がある。
また、データは非常に多様化しているので、多様なデータをそのままのフォーマットで保管し活用できる必要がある。
ストレージとデータの活用層を疎結合にして、さまざまなユースケース・分析に対処できるようにする。
（たとえば、ストレージに特定のスキーマのテーブルを使っており、そのスキーマに対してしか分析できません、とかは避けるということかな？）

S3上に生データを保存し、AWS Glueでメタデータを管理する。AWS GlueのようなETLサービスを利用してデータを利用しやすい形式に変更して格納し、活用する(pp.9--10)。

データレイクを作る際のポイント「小さく始める」という部分も重要だと思われるので参照のこと