Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
ぽこまち:DeepSeek 4.0 Flashの推論パフォーマンス改善
Search
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
そのだ
October 17, 2026
Technology
62
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
ぽこまち:DeepSeek 4.0 Flashの推論パフォーマンス改善
DGX Spark / GB10 ローカルLLM勉強会 #2
https://aibuilders.connpass.com/event/406172/
そのだ
October 17, 2026
More Decks by そのだ
See All by そのだ
DGX Sparkを2台使って いろいろ動かす話
sonoda_mj
1
210
Codex Microで 開発体験は変わるのか?
sonoda_mj
1
110
DGX Sparkを2台つないで 最強ローカルLLM環境を動かしてみた話
sonoda_mj
0
280
AGENTS.mdとSkillsで始めるAIエージェント活用
sonoda_mj
3
290
Google_ADKのSub_AgentをAgentic_Workflowに移行し_遷移成功率を改善した話.pdf
sonoda_mj
1
180
仕事はAIに任せてラスベガスへ行きたいのでDSPyで自分のクローンを作った
sonoda_mj
1
190
ハッカソンから社内プロダクトへ AIエージェント「ko☆shi」開発で学んだ4つの重要要素
sonoda_mj
6
2.9k
RAGの基礎から実践運用まで:AWS BedrockとLangfuseで実現する構築・監視・評価
sonoda_mj
1
2.4k
Amazon Bedrock Knowledge Basesに Data Autometionを導入してみた
sonoda_mj
1
300
Other Decks in Technology
See All in Technology
AI駆動開発におけるハーネスエンジニアリングの勘所
tsukuboshi
1
360
日本語に強いオープンな大規模言語モデル「LLM-jp」
odashi
5
1.2k
AIネイティブ企業への変革。パーソルキャリアが挑む「データメッシュ×ガバナンス」のアーキテクチャ戦略
techtekt
PRO
0
120
CSS2026:OWS研究会・招待講演「世界観を、実装する」
atsush1_sada
2
140
Tofu-Controller lightning talk @ Containerday 2026
gionn
0
170
Code for Security プロジェクト紹介 2026年10月
yu23ki14
0
120
僕のハーネスを紹介します
watany
4
1.3k
AI コーディングと人間の認知スループット / CTO Night & Day 2026 Morning Session / AI Coding and Human Cognitive Throughput
prog893
5
1.5k
Gemini Intelligence 入門 ― AppFunctions と Gemini Nano
takuroabe
0
340
データエンジニアの次の戦場は "プロセスエンジニアリング"
sansantech
PRO
1
150
ウォンテッドリーの最近のプロダクトと技術の紹介
stomk
0
320
価値について
gree_tech
PRO
0
140
Featured
See All Featured
Groundhog Day: Seeking Process in Gaming for Health
codingconduct
0
430
Heart Work Chapter 1 - Part 1
lfama
PRO
10
37k
Building Flexible Design Systems
yeseniaperezcruz
330
41k
Information Architects: The Missing Link in Design Systems
soysaucechin
1
1.2k
Facilitating Awesome Meetings
lara
57
7.2k
Making Projects Easy
brettharned
120
6.8k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
128
56k
Side Projects
sachag
456
43k
Building a Modern Day E-commerce SEO Strategy
aleyda
45
9.3k
Lessons Learnt from Crawling 1000+ Websites
charlesmeaden
PRO
1
1.6k
Google's AI Overviews - The New Search
badams
0
1.6k
Documentation Writing (for coders)
carmenintech
77
5.6k
Transcript
park勉強会 #2 ぽこまちの eep eek 4.0 lash 推論パフォーマンス改善 2026年10月
自己紹介 苑田 朝彰 omotada onoda 普段の業務内容 • エージェント開発( oogle ,
trands gent) • ローカル • 社内 推進( 駆動開発、エージェント開発) • クラウド( , oogle loud) 資格 ommunity uilders( ) / 甲賀流忍者検定(中級) 趣味 月に1回、面白いことに挑戦。 partanレース/100kmウォーキング/無人島かくれんぼ/滝行 x.com/sonoda_mj / zenn.dev/tomomj / note.com/sonoda_mj
目次 1. ぽこまちとは 2. eep eekの推論を速くする 3. まとめ
1 1. ぽこまちとは
ぽこまちとは 住民が暮らす街のシミュレーション。 住民の行動は eep eek 4.0 lashが判断。 https://pokomachi.tomotada.com/
ぽこまちの構成図 上のぽこまちアプリが、 loudflare経由で eep eekの推論 を呼び出す。 park( eep eek /
v mazon 2 ・シミュレーション ite loudflare ccess / unnel 街の処理は 2、モデルの推論は で実行。 )×2 ( =2) 1 2 ・推論 推論
eep eekの実行環境と測定項目 ぽこまちの実行環境と住民の判断に関する設定。 実行環境 固定設定 キャッシュ park 2台/ thinking =2
/アプリの同時判断数:4 refix ache: 平均入力 約12,310 tokens/回 平均出力 約51 tokens/回 測定項目 再利用トークン数・入力処理(prefill)・応答時間
2 2. eep eekの推論を速くする
refix acheとは 入力の先頭から一致する部分の を再利用し、入力処理の計算量を削減。 入力処理(prefill):計算量を削減 なし あり 回答生成(decode) 10,000 tokensを計算
再利用 6,000 tokens どちらも、回答生成には通常の 4,000 tokensを計算 acheを使用。 説明用の例:入力10,000 tokensのうち6,000 tokensを再利用。図の幅は処理時間の比率を表さない。 → 回答を生成 → 回答を生成
初期のキャッシュ再利用率:0% キャッシュは 。共通部分を先頭に移しても、再利用は0。 項目 整理前 整理後 共通部分(tokens) 1,867 2,247 再利用量(tokens)
0 0 整理前 共通ルール 整理後 共通ルール 住民別の情報 場所一覧 共通部分 2,247 tokens < 最初の保存位置 4,096 tokens 整理前116件。整理後95件のうち、再利用量が確認できた94件を集計(不明1件を除外)。 場所一覧 住民別の情報
v の保持間隔(4,096から2,048) キャッシュは のまま。保持間隔を4,096から2,048 tokensへ短縮。 保持間隔:再利用する中間状態の保存間隔(tokens) 入力の先頭 変更前 保持間隔 4,096
変更後 保持間隔 2,048 4,096 tokens 共通部分 2,247 tokens 毎回異なる部分 保存位置が共通部分の範囲外のため、再利用なし 共通部分 2,247 tokens 毎回異なる部分 共通部分の中に状態を保存し、2,048 tokensを再利用 指標 入力の再利用率 変更前:4,096 変更後:2,048 差分 0% 16.51% +16.51pt 再利用件数/集計件数 0 / 171 224 / 224 — 再利用トークン数(平均) 0 2,048 +2,048 入力処理時間の平均(秒) 9.17 7.31 −20.29% 応答時間の中央値(秒) 31.96 25.91 −18.94% 10/14、 eep eekの通常判断、前後各30分。検証時のv ビルドを使用。 変更前174件(再利用量の取得171件、不明3件)、変更後224件。
店舗情報の共通化 全住民で同じ店舗情報を、各入力の先頭へ。 変更前:住民別の情報と混在 変更後:店舗情報を先頭へ 店舗情報(共通) 住民別の情報 住民 好み:カフェ 喫茶店:10 ・初来店
喫茶店:10 好み:カフェ 初来店 住民 好み:音楽 喫茶店:10 ・訪問済 喫茶店:10 好み:音楽 訪問済 先頭を再利用 指標 入力トークン数(平均) 変更前 変更後 差分 12,171.55 11,054.18 −9.18% 入力処理時間の平均(秒) 7.47 6.35 −14.93% 応答時間の中央値(秒) 25.98 19.58 −24.64% 入力は保存済みの同じ40件で比較(表形式化などを含む)。時間は前後各30分の通常運転で比較。
v の保持間隔(2,048から1,024) v の保持間隔を、さらに1,024 tokensへ短縮。 v の環境変数: _ _ _
_ 入力の先頭 4,096 tokens 変更前 保持間隔 2,048 共通部分 3,362 tokens(例) 変更後 保持間隔 1,024 共通部分 3,362 tokens(例) 毎回異なる部分 2,048 tokens分を再利用(225件) 毎回異なる部分 3,072 tokens分を再利用(221件) 指標 変更前:2,048 変更後:1,024 差分 再利用トークン数(平均) 2,267.43 3,169.52 +39.78% 未再利用トークン数(平均) 8,482.19 7,743.63 −8.71% 入力処理時間の平均(秒) 6.13 5.62 −8.35% 再利用件数/集計件数 252 / 252 251 / 252 1件は未ヒット 応答時間の中央値(秒) 20.31 18.07 −11.01% 10/14 22:06〜22:36/22:58:23〜23:28:23( )。表のトークン数は1回の判断あたりの平均。 図は共通部分が3,362 tokensの保存済みの入力例。検証時のv ビルドを使用。
出力形式の重複削減 出力形式の指定を 側に集約し、本文の重複を削除。 変更前(簡略例) 変更後(簡略例) 本文(output ontract) action・reason:必須 reason:文字列 本文
現在の状態・行動候補 出力仕様の重複を削除 ( chema) action・reason:必須 reason:文字列 ( chema) action・reason:必須 reason:文字列 指標 入力トークン数(平均) 変更前 変更後 差分 11,198.10 10,721.25 −4.26% 入力処理時間の平均(秒) 5.78 5.41 −6.39% 応答時間の中央値(秒) 18.52 17.70 −4.43% 入力は保存済みの同じ20件、時間は前後各30分の通常運転で比較。
全体の測定結果 入力とキャッシュ設定の調整前後で、処理時間を比較。 指標 調整前 入力の再利用率 oken cache hit rate(%) 再利用トークン数
ached tokens・平均(tokens/回) 入力処理時間 refill・平均(秒) 処理開始待ち ueue・平均(秒) 回答生成時間 ecode・平均(秒) 応答完了時間 2 latency・中央値(秒) 受付 → 調整後 0% 30.15% +30.15pt 0 3,239.87 +3,239.87 9.17 5.41 −41.04% 8.29 2.11 −74.50% 13.34 9.31 −30.20% 31.96 17.70 −44.62% ueue → refill → 最初のトークン → ecode → 完了 :受付〜最初のトークン | 差分 2 :アプリの呼び出し〜応答完了 各30分の測定。入力処理・処理開始待ち・回答生成はエンジン全体の平均、応答完了時間はアプリの中央値。 調整前:10/14 00:15〜00:45、調整後:10/15 00:23〜00:53。集計対象が異なるため、各時間の値は合算できない。
3 3. まとめ
まとめ • 共通部分をプロンプトの先頭へ • 共通部分の長さに合わせて保持間隔を調整 • 入力の重複を削減