Podcastに関するiwashi86のブックマーク (5)

  • 107. LLMをゼロから作るということ w/ Takahiro Omi | fukabori.fm

    MP3ファイルをダウンロード 内容紹介 ストックマークの近江さんをゲストに、大規模言語モデルをゼロから作る方法、学習のデータセット、モデルアーキテクチャ、学習環境への取り組みなどについて語っていただきました。 出演者 話したネタ どのような大規模言語モデルと作ったのか?特徴は何か? データセットに何を使ったのか? 日語と英語とのバランスは? 最終的なToken数は? 事前学習モデルを作りたいとして、何から考えるのか? ノイズのクリーニングと、その方法 今回活用したモデルアーキテクチャ(Llama) 前回のアーキテクチャは GPT-NeoX 今回の学習環境は? AWS Trainum 32コア x 16ノード 学習にかかった時間は? 学習時に大変だったこと・上手くいかなかったことは? 学習中のチェックポイントとは何か? なぜ、Token生成が速いのか? 手元でLLMを動かすときの一番のネッ

    107. LLMをゼロから作るということ w/ Takahiro Omi | fukabori.fm
  • 82. Node.js、Deno、Bun (前編) w/ yosuke_furukawa | fukabori.fm

    MP3ファイルをダウンロード 内容紹介 yosuke_furukawaさんをゲストに、JavaScriptランタイム、Node.js、イベントループモデル、JavaScriptエンジン、Denoの生まれた経緯について語っていただいたエピソードです。 出演者 話したネタ denoの話 Bun first impressions Node.js、DenoBunとは何か? JavaScriptランタイムとは何か? サーバーサイドJavaScript expressを利用してWebサーバーを立てるコードは、Node.js以外でも動くのか? ECMAScript と ランタイム との関係は? TC39 Node.js はどんな経緯で生まれてきた? Rubyを書くタイミングと、JavaScriptを書くタイミングでのコンテキストスイッチ netv8 イベントループモデルとは何か? ブロッキング処理、

    82. Node.js、Deno、Bun (前編) w/ yosuke_furukawa | fukabori.fm
  • fukabori.fmでチームトポロジーの話をしました #fukabori #ちいとぽ - ナイスビア珍道記

    fukabori.fm fukabori.fmは2018年からiwashiさんが運営している(すごい!)、技術・組織・開発などを中心に話すTech系のPodcastです。 実はお仕事のご縁でiwashiさんの社内向けラジオ(一般公開なし)に出たことがあるのですが、 それ以来ひさびさにお声がけいただき、2021年12月に発売された拙訳『チームトポロジー』について話してきました。 (話の中でたまに "チームトポロジーズ" って言ってるんですが、正しくは "チームトポロジー" ですね。英語タイトルが "Team Topologies" だったので…) fukabori.fm 月並みな感想ですが、社外の人と雑談をすること自体も久しぶりで楽しかったです。 ライブ感のある収録で、聞き直してみると「あー、ここは言葉が足りなかったな」とか思うところはあったり、ちいとぽ関係ないじゃんみたいな話も盛り上がって

    fukabori.fmでチームトポロジーの話をしました #fukabori #ちいとぽ - ナイスビア珍道記
    iwashi86
    iwashi86 2022/03/07
    出演いただきありがとうございました!
  • 14. なぜ、エンタープライズ業界でアジャイル・リーンは普及しないのか? | fukabori.fm

    話したネタ なぜ、企画と開発が責任を押し付け合う会社の前途は暗いのか? 計画が悪い vs 実装が悪い、というどっちが悪い論 問題の理解と、その実装(人・システム)が時間軸で離れると学習がない、課題の理解は実装で深まる 市場、世界は悠長に回っていない 将棋でのメタファーとRTSでのメタファー 上手くいかないのは全体という前提をどこまで作れるか? 仕様が固まってから開発の後半で発生する変更を怖がる あたかも世界の時間が止まっているように振る舞う オーシャンズ11 その場の状況にあった計画を立て直していく、情報を得続ける 現代の戦争は火力戦・物量戦から変わってきている 企画と開発も同じコンテキストで話さないと、リアルな変化に追従できない ピラミッド構造は例外処理が役割の1つ 手順書はQ&Aに答えてくれない Q&Aに答えられる人が現場にいない リーンスタートアップやアジャイルなやり方が出てきた背景

    14. なぜ、エンタープライズ業界でアジャイル・リーンは普及しないのか? | fukabori.fm
  • 12. エンプラ向けの組織改革とか、スクラムでのチーム作り・人事評価とか | fukabori.fm

    話したネタ 古くから大企業・組織で、ryuzeeさんならどう切り込んでいくか? 現場だけで変えられる範囲には限界がある 組織改革を若手がやるのは厳しい ボトムアップでやるには気の遠くなる話が多すぎる ミドルマネージャーや意思決定の権限を持つ 改革の範囲を全社ではなく、自分の部だけにする 徐々に広げていくのは、ボトムアップでは鉄板 トップダウンでいく場合は、ミドルマネージャーが障壁になりやすい 全社ルール・ガイドラインと、どう付き合っていけば良いのか? 複数のガイドライン/オプションを用意しておく ガイドラインをかならず守らなきゃいけないのは思い込みなこともある 緩い、自由があるガイドラインだと進めやすい 権限委譲が非常に難しいのではないか? 権限のないプロダクトオーナー問題 プロジェクト開始の時点で、決められる範囲の線引き 大きな会社になればなるほど、スクラムマスターが重要 スクラムマスタ

    12. エンプラ向けの組織改革とか、スクラムでのチーム作り・人事評価とか | fukabori.fm
  • 1