ブログ
GPU・LLM・MLOps・Kubernetes、そしてマインドセット · 3516 件
#2026-03 764#japanese 587#deep-dive 254#kubernetes 249#culture 236#career 224#ai 217#llm 209#devops 196#2026-04 144#security 141#observability 113#database 110#communication 107#architecture 100#productivity 88#finance 87#mindset 80#ai-papers 79#history 79#it 78#psychology 78#english 75#networking 74#deep-learning 73#gpu 70#linux 70#performance 70#cs-fundamentals 63#ai-agent 61#postgresql 60#rag 59#economy 57#mlops 53#self-improvement 53#python 52#ai-platform 51#food 51#learning 51#travel 51
MIGとtime-slicing — GPU一枚を複数で使う二つの方法
GPU一枚に複数のワークロードを載せる方法は大きく二つあります。時間を分けるtime-slicingとハードウェアを分けるMIGですが、名前が似て見えるのとは裏腹に隔離の水準がまったく異なります。本記事ではNVIDIA GPU Operatorの公式ドキュメントを基準に、両方式の設定ファイル構造とノードラベル、広告されるリソース名、対応ハードウェア条件を整理し、time-slicingのレプリカ間にメモリ隔離も障害隔離も無いという事実が
2026-08-12 · 11 分で読めます #gpu#kubernetes#mig#time-slicing#nvidiaDCGM Exporter — GPU利用率はあなたが思っているものではない
DCGM ExporterはGPUテレメトリをPrometheus形式で公開する標準経路ですが、最も多くダッシュボードに載るGPU利用率系のメトリクスは、人々が期待するものを測っていません。本記事ではdcgm-exporterリポジトリの既定カウンタCSV、DCGM公式ドキュメント、NVML APIドキュメントを直接読み、既定で有効なメトリクス一覧、利用率メトリクスが実際に何を意味するのか、併せて見るべきプロファイリングメトリクスは何か
2026-08-12 · 16 分で読めます #gpu#kubernetes#dcgm#prometheus#observabilityGPUサービングのSLOとアラート設計 — 何を約束し何で人を起こすか
GPU推論サービスにSLOを掛けるには、まずどの指標が利用者体験を代弁するかを決める必要があります。最初のトークンまでの遅延とスループットは互いを食い合う関係にあり、片方だけを見て目標を立てると必ずもう一方が崩れます。本記事ではvLLMとDCGM Exporterが実際に公開する時系列だけを使ってSLIを定義する方法、ヒストグラムのバケット境界を閾値にすべき理由、飽和シグナルを読む順序、症状ベースのアラート設計、そしてGPUサービングで
2026-08-12 · 13 分で読めます #gpu#kubernetes#slo#alerting#prometheusデバイスプラグインとGPUスケジューリング — nvidia.com/gpuはどこから来るのか
KubernetesはGPUを知りません。ノードにGPUをリソースとして広告させるのはkubeletに登録されたデバイスプラグインであり、その結果生まれる名前が拡張リソースnvidia.com/gpuです。本記事では、デバイスプラグインが実装すべきgRPCインターフェースと登録ソケットのパス、拡張リソースでrequestsとlimitsが必ず一致しなければならない理由、GPUをCPUのようにミリコアへ分割できない根本的な理由、そしてGP
2026-08-12 · 10 分で読めます #gpu#kubernetes#device-plugin#scheduling#nvidia韓国の開発ブログ名文キュレーション 4 — フロントエンド、直接開いて確認した14本
フロントエンドをテーマに韓国語で書かれた記事から、説明が具体的で再現可能な14本を選びました。実行コンテキストで説明するクロージャ、JavaScriptがプロトタイプを選んだ背景、TypeScriptの条件型とinfer、型システムが証明のように働く理由、リフローとリペイント、React Fiberのリコンサイラ、useLayoutEffectで直したマーカー描画、バンドラ四種の系譜、宣言的プログラミングにまつわるよくある誤解、オーバー
2026-08-12 · 22 分で読めます #curation#큐레이션#frontend#javascript#typescript韓国の開発ブログ名文キュレーション 3 — AIとML実務、直接開いて確認した14本
AIとMLを実務で扱う韓国語記事から、具体的で再現可能な14本を選びました。LangChainによるRAGパイプラインの全工程、埋め込みとベクトル類似度から見た意味検索の原理、ベクトルデータベース7種の比較、pgvectorからQdrantへの移行記録、OllamaからvLLMへ移してスループットを上げた過程、LLMサービングの指標のトレードオフ、使用量トラッカーの自作記、Transformer論文のレビューとコード実装、BERTの整理
2026-08-12 · 24 分で読めます #curation#큐레이션#ai#llm#ragエンジニアのための韓国語のお金の記事九編 — 商品を売る記事を取り除いたら計算の構造だけが残りました
年末調整、社会保険料、ストックオプションの課税、退職金、フリーランスの確定申告。韓国の開発者が一度は検索する主題ですが、検索結果の大半は還付アプリと金融商品の広告で埋まります。何かを売ることが主目的の記事をすべて除外し、計算がなぜそうなるのかを説明する記事だけを残したところ九編が残り、そのうち六編が公式の案内でした。リンクはすべて直接開いて確認し、各項目がどの計算構造を説明するのか、誰が読むとよいのかを整理しました。
2026-08-12 · 22 分で読めます #큐레이션#korean-blogs#money#tax#payroll韓国の開発ブログ名文キュレーション 2 — 障害振り返りとトラブルシューティング、直接開いて確認した12本
韓国の開発者がもっとも得意とするジャンルは障害の振り返りです。p6spyがDBルーティングを無力化した事件、HTTPタイムアウトがDNS解決を覆えなかった理由、TCPハーフクローズが重複例外に偽装された事例、MetalLBの設定ひとつが生んだクラスタの遅延スパイク、ヒープダンプでOOMを追跡した記録、JITウォームアップでデプロイ直後のCPUスパイクを抑えた過程、外部キーが招いたデッドロック、HikariCPのコネクション枯渇、MySQ
2026-08-12 · 22 分で読めます #curation#큐레이션#troubleshooting#postmortem#incident技術文章とサイドプロジェクトに関する韓国語記事十編 — 始め方ではなく続け方
技術ブログの始め方を扱う記事は多いのに、ほとんどは最初の一編までしか連れて行ってくれません。この記事は書き続ける問題と作り続ける問題を扱った韓国語の記事十編を集めました。開発者が文章を書く理由の三編、習慣とプラットフォーム選びの五編、そしてサイドプロジェクトが実際の収益につながるまでを記録した二編です。リンクはすべて直接開いて確認し、各記事がどの段階を扱うのか、誰が読むとよいのかを整理しました。
2026-08-12 · 20 分で読めます #큐레이션#korean-blogs#writing#side-project#indie-dev開発者の転職記と年収交渉の記事八編 — 成功談ではなく手順を書いた記事だけを選びました
転職記は多いのに、ほとんどは結果だけが残ります。この記事は過程を順に書いた韓国語の記事八編を集めました。転職の全過程を記録した三編、年収交渉の根拠を扱った一編、履歴書と職務経歴書の書き方三編、そして合否と無関係に面接を振り返った一編です。リンクはすべて直接開いて確認し、各記事がどの段階を扱うのか、誰が読むとよいのかを整理しました。
2026-08-12 · 18 分で読めます #큐레이션#korean-blogs#career#job-change#salary-negotiationコンテキスト予算 — 何を入れるかではなく何を外すかが設計です
コンテキストウィンドウにはまだ余裕があるのに、エージェントの正確さは落ちていきます。コンテキストは有限の注意予算であり、ツールのスキーマもその予算を食います。ハーネスエンジニアリング連載第2回では、プロンプト累積をプレイブックに変える方法、ドロップポリシーとコンパクションの基準、サブエージェント委任の本当のコストまで、コンテキスト予算の設計を整理しました。
2026-08-12 · 10 分で読めます #llm#agent#harness-engineering#하네스엔지니어링#AI에이전트韓国の開発ブログ名文キュレーション 1 — バックエンドとインフラ、直接開いて確認した14本
韓国語で書かれたバックエンドとインフラの記事から、説明が具体的で再現可能な14本を選んで紹介します。IstioのSidecarとServiceEntry、Envoyのサーキットブレーカーとルーティング、Prometheus Push Gatewayの限界、JVMのメモリ構造とGC、クラスパスシャドーイング、Kafkaのパーティション増設時のコンシューマ設定、Linuxサーバーを60秒で把握する順序、HTTP Keep-AliveとTCP
2026-08-12 · 24 分で読めます #curation#큐레이션#backend#infra#istioノートアプリを五回乗り換えた人のための韓国語記事九編 — 道具ではなく構造の問題でした
ObsidianとNotionを行き来しながらテンプレートばかり整え、肝心のノートは溜まらないという経験はよくあります。この記事は道具の紹介ではなく記録の構造を扱う韓国語の記事九編を集めました。道具を選ぶ前に読む三編、つながりを軸にしたメモ法である제텔카스텐の二編、そして記録を実際の変化に変える振り返りの四編です。リンクはすべて直接開いて確認し、各記事がどの問題を扱うのか、誰が読むとよいのかを整理しました。
2026-08-12 · 18 分で読めます #큐레이션#korean-blogs#productivity#note-taking#obsidianFDE障害診断プレイブック — アクセス権から報告書まで6ステップ
自社サービスの障害と顧客先の障害の決定的な違いは、何も知らない状態から始まることです。だからForward Deployed Engineer（FDE）には、腕前より先に固定された順序が必要です。アクセスと権限の確認、症状の再現、レイヤーの切り分け、原因仮説、検証、報告書という6ステップを、決済APIが断続的に504を返すという構成した例一つで貫き、各ステップで実際に叩くkubectl、curl、grepのコマンドを併記しました。診断が
2026-08-12 · 11 分で読めます #career#fde#forward-deployed-engineer#incident-response#debuggingFDEオンボーディング90日 — 把握、単独チケット、主導ミッションの3か月
Forward Deployed Engineer（FDE）のオンボーディングは、自社と顧客企業という二重の未知の環境に同時に適応する仕事なので、普通のエンジニアのオンボーディングより設計が必要です。1か月目は環境・製品・人の地図を描き、2か月目は単独チケットで信頼口座を開き、3か月目は小さなミッションを一つ主導します。週ごとのチェックリスト、各月に潜む罠、そして90日が終わったときに自分を検証する三つの質問まで、最初の四半期を丸ごと設
2026-08-12 · 9 分で読めます #career#fde#forward-deployed-engineer#onboarding#checklistFDE（Forward Deployed Engineer）とは何か — 顧客の現場に配置されるエンジニア
Palantirが生み出し、いまOpenAIとAnthropicが競って採用している職種、Forward Deployed Engineer（FDE）を丁寧に整理します。本社ではなく顧客の現場に配置され、製品と顧客システムの間のラストワンマイルをコードでつなぐ仕事とは何か。ソリューションアーキテクト・セールスエンジニア・コンサルタント・サポートエンジニアとの違いを表で切り分け、未完成のプラットフォームであるほど現場のエンジニアリングが製
2026-08-12 · 11 分で読めます #career#fde#forward-deployed-engineer#ai#job-searchバックエンド・DevOps・データエンジニアからFDEへ — 6か月の転換ロードマップ
Forward Deployed Engineer（FDE）への転身を考える人の大半は、バックエンド、DevOps・SRE、データエンジニアのどれかから出発します。良い知らせは、どの背景でもFDEスキルマップの半分はすでに持っていること。悪い知らせは、空いている残り半分が背景ごとに違うことです。三つの背景それぞれについて、すでに持っているものと埋めるべきものを切り分け、共通して足りない顧客対面のスキルを指摘した上で、2か月単位の6か月転
2026-08-12 · 9 分で読めます #career#fde#forward-deployed-engineer#career-transition#roadmap「遅いんです」をエンジニアリングの問題に翻訳する — FDEの顧客コミュニケーション
顧客はバグレポートをくれません。「遅いんです」「動かないんです」「ときどき変なんです」という痛みの報告をくれます。Forward Deployed Engineer（FDE）の中核スキルの一つは、この言葉を測定可能なエンジニアリングの問題に翻訳する質問の技術です。いつから、誰が、何をするとき、どのくらい、何と比べての五つの軸で症状を絞る方法、同じ場面で信頼を削る返答と積む返答の対比、約束の単位を解決時刻から次の報告時刻に変える期待値マネ
2026-08-12 · 10 分で読めます #career#fde#forward-deployed-engineer#communication#customer-successPoCはなぜ本番にたどり着けないのか — 成功基準、セキュリティレビュー、引き継ぎ
デモで拍手をもらったPoCのかなりの部分は、そのまま静かに死にます。技術が足りないからではなく、成功基準がなかったから、セキュリティレビューを最後に始めたから、チャンピオンがいなかったから、PoC環境と本番環境の差に気づくのが遅かったからです。Forward Deployed Engineer（FDE）の仕事の中で、PoCを本番に運ぶ区間は技術より運営設計が勝負どころです。開始前に合意する成功基準の文書、最初の週に始めるセキュリティレビ
2026-08-12 · 10 分で読めます #career#fde#forward-deployed-engineer#poc#productionFDE面接準備 — 診断シナリオ、顧客シミュレーション、ケーススタディ
Forward Deployed Engineer（FDE）の面接では、アルゴリズム問題の代わりに未知のシステムの障害診断シナリオが、カルチャーフィット質問の代わりに怒った顧客の役割演技が出ることが多い。測ろうとしているのがコードではなく現場での判断だからです。会社ごとに形式は違うという前提の上で、公開求人票が共通して要求する能力を、技術診断ラウンド、顧客シミュレーションラウンド、ケーススタディの三形式に一般化し、それぞれの採点ポイント
2026-08-12 · 10 分で読めます #career#fde#forward-deployed-engineer#interview#job-search