The Two Most Misunderstood Metrics in Enterprise LLM Deployment When evaluating Large Language Model (LLM) deployment options, many teams focus on GPU models and parameter counts—70B, 235B, 671B—while overlooking two metrics that actually determine whether a system is usable in real life: These two metrics directly affect: This article explains what Token/s and concurrency really…
Category: AI
About AI
Token/s 與並發：企業導入大型語言模型時，最容易被誤解的兩個指標
在評估大型語言模型（LLM）部署方案時，許多人會被顯卡型號、模型參數量（70B、235B、671B）所吸引，卻忽略了兩個真正決定「用起來好不好」的核心指標： 這兩個指標，直接決定了： 本文將從「工程實務」的角度，說清楚這兩個概念，以及企業在規劃本地或私有化 LLM 時，應該如何正確看待它們。 一、什麼是 Token/s？它其實就是「AI 的輸出速度」 1. Token 是什麼？ 在 LLM 中，模型不是一次輸出一句話，而是一個 Token 一個 Token 地生成內容。 模型的所有「思考與輸出」，本質上都是 Token 的連續生成。 2. Token/s 的實際意義 Token/s = 模型每秒能生成多少 Token 舉例來說： Token/s 不影響模型會不會回答對，但會直接影響： 二、Token/s 與使用者體感的真實關係 實際使用 LLM 時，使用者會感受到兩個時間點： 這兩者常被混在一起，但意義完全不同。 實務比較範例 假設模型要輸出 400 Token： 情境 TTFT Token/s 總等待時間 A 0.5 秒 10 約 40 秒 B 3 秒…
Running OpenCode AI using Docker
A Practical, Reproducible, and Enterprise-Ready Implementation Guide AI coding tools such as OpenCode AI can significantly improve developer productivity. However, installing them directly on developer machines quickly becomes problematic in team or enterprise environments: This guide shows how to run OpenCode AI inside a Docker container, following best practices for security, reproducibility, and enterprise governance….
使用 Docker 實際運行 OpenCode AI
一個可重現、可控、可維運的 AI Coding 環境實作指南 AI Coding 工具（如 OpenCode AI）若直接安裝在開發者本機，雖然方便，但在團隊或企業環境中，往往會帶來： 本文將示範 如何依照實務最佳做法，使用 Docker 建立一個可實際運行的 OpenCode AI 容器環境，讓 AI Coding 工具成為一個 可管理的工程元件。 一、整體設計目標 本實作的設計目標如下： 二、專案目錄結構 建議建立一個乾淨的目錄： 三、Dockerfile（核心實作） 以下是一份 可直接使用的 Dockerfile，已包含實務上必要的修正與安全考量。 四、Build Image 建立 build.sh： 執行： 五、執行容器（關鍵實作） OpenCode AI 需要使用者的認證資料，這些資料 必須存在主機上，再掛載進容器。 1️⃣ 主機端準備（只做一次） 登入一次 OpenCode（或依你實際使用方式）後，通常會產生： 2️⃣ run.sh（正式使用方式） 執行： 六、實際使用情境 進入後，你會在容器內： 這讓 OpenCode AI 的行為符合： 「工具可丟棄，資料留在主機」的雲原生設計原則 七、為什麼這種做法適合企業 ✔ IT…
Security Risks and Governance Models for AI Coding Tools
From Developer Productivity to Enterprise Control AI coding tools such as OpenCode AI, Copilot-style assistants, and code-generating agents are rapidly transforming how software is written. While the productivity gains are undeniable, these tools also introduce a new and often underestimated security surface. For enterprises, the critical question is no longer: “Is this tool useful?” but…
AI Coding 工具的資安風險與治理模型
從工程效率工具到企業可控的 AI 能力 AI Coding 工具（如 OpenCode AI、Copilot 類型助手、Code Agent）正在快速改變軟體開發的方式。然而，當企業開始大規模導入這類工具時，真正的挑戰往往不在「功能」，而在 資安與治理。 企業必須思考的問題已不再是： 「這個工具能不能提升工程師效率？」 而是： 「我們是否有能力在可控、可稽核、可治理的前提下使用 AI Coding 工具？」 本文將系統性說明 AI Coding 工具帶來的主要資安風險，並提出一套 適合企業導入的治理模型。 為什麼 AI Coding 工具是一個新的資安風險類型 傳統開發工具（IDE、編譯器、Formatter）本質上是被動工具；AI Coding 工具則完全不同。 AI Coding 工具通常具備以下特性： 從資安角度來看，它更像是一個： 具高權限、可連網、能操作原始碼的自動化代理程式 這使得 AI Coding 工具成為一個全新的攻擊與風險面。 AI Coding 工具的五大核心資安風險 1️⃣ 原始碼外洩風險（Source Code Leakage） AI Coding 工具通常需要讀取： 潛在風險包括： 一旦原始碼離開企業邊界，實際上就失去控制權。 2️⃣ 憑證與權限暴露風險 AI Coding…
Running OpenCode AI in Docker
An Enterprise-Ready Approach to AI Coding Tool Adoption As AI coding tools rapidly become part of everyday software development, the real challenge for enterprises is no longer whether to adopt them, but how to do so responsibly. The key question for IT and security teams is: How can we introduce AI coding tools without compromising…
企業如何以 Docker 導入 OpenCode AI
——讓 AI Coding 工具可控、可維運、可複製 隨著 AI Coding 工具逐漸成為工程師日常的一部分，企業 IT 部門面臨的問題已不再是「要不要用 AI」，而是： 如何在不破壞資安與系統治理前提下，把 AI 工具導入企業環境？ 本文將以 OpenCode AI 為例，說明如何透過 Docker 容器化 的方式，將 AI Coding 工具導入企業內部，並兼顧： 為什麼企業不適合「直接在本機安裝 AI 工具」 在個人使用情境中，直接執行安裝腳本或下載 binary 可能沒有太大問題；但在企業環境，這樣的方式會快速累積風險： 從 IT 管理角度來看，AI 工具本質上已經是一種「高權限的自動化程式」，不應該任由其在工程師電腦上無限制擴散。 為什麼選擇 Docker 來導入 OpenCode AI 將 OpenCode AI 以 Docker 方式執行，可以解決上述大多數問題。 對 IT 部門而言的實際好處 這讓 OpenCode AI 從「個人工具」轉變為： 一個 IT 可治理的內部開發工具元件…
RAG vs Fine-Tuning: Which One Should You Actually Use?
When organizations adopt LLMs, one question almost always appears early: “Should we use RAG, or should we fine-tune the model?” This question is often misunderstood because many assume RAG and fine-tuning are alternatives. They are not. 👉 RAG and fine-tuning solve fundamentally different problems. This article explains the difference in plain terms—so you don’t waste…
RAG vs Fine-tuning：到底該用哪一個？
在企業導入 AI 時，幾乎一定會遇到這個選擇題： 「我們是要用 RAG，還是要做 Fine-tuning？」 這個問題之所以常被問錯，是因為很多人以為它們是互相替代的方案。事實上—— 👉 RAG 和 Fine-tuning 解決的是「完全不同的問題」。 這篇文章會用白話＋架構角度，幫你一次搞清楚。 先給結論（一句話版） RAG 解決的是「模型不知道資料在哪裡」，Fine-tuning 解決的是「模型不知道該怎麼做事」。 如果你把問題分清楚，答案通常會自己出現。 先釐清兩者在做什麼（非常重要） 🔎 RAG（Retrieval-Augmented Generation） 👉 本質是：即時資料注入（Inference 行為） 🧠 Fine-tuning 👉 本質是：模型能力調整（Training 行為） 用一個最直覺的比喻 RAG 就像「考試時可以翻資料」Fine-tuning 就像「把解題方法背起來」 什麼情況「一定要用 RAG」？ 適合 RAG 的典型場景 📌 為什麼？ 👉 這些資料「不該被學進模型」。 什麼情況「適合 Fine-tuning」？ 適合 Fine-tuning 的典型場景 📌 這些特點是： 👉 能力，才值得被訓練進模型。 把 RAG 拿去做…