不行，M/M/1 排隊計算機無法模擬多個伺服器，因為 Kendall 的 M/M/1 標記法中最後的「1」依定義就是明確指定單一伺服器。排隊理論使用 Kendall 標記法以簡寫方式描述一個系統：第一個 M 代表馬可夫（Poisson）到達，第二個 M 代表馬可夫（指數）服務時間，而數字則代表有多少個相同伺服器平行運作。當計算機頁面標示為 M/M/1 模型時，它就把結果限定為單一 FIFO 伺服器，具備無限等候空間且到達率為穩態。若要同時評估多個伺服器，你必須改用其他模型，最常見的是 M/M/c，其中 c 是伺服器的數量。排隊理論計算機專注於單一伺服器的穩態情形，會根據你提供的到達率與服務率，計算使用率 ρ、平均排隊長度 Lq、平均系統人數 L、平均排隊等候時間 Wq，以及平均總時間 W，並會在 λ 接近或超過 μ 這類不穩定排隊時予以拒絕。在依賴其輸出之前，請先確認單一伺服器確實能描述你正在評估規模的系統；因為把一個四個出納員的銀行櫃台排隊硬塞進 M/M/1，將會默默地低估顧客實際感受到的等候時間。
M/M/1 中「1」的意義
Kendall 標記法是一種精簡記錄排隊模型背後假設的方式。M/M/1 這三個字元並非裝飾性的標籤，而是數學所依賴的限制。由左至右讀，第一個 M 聲明到達服從 Poisson 過程，也就是從具備固定均值的指數分布中抽取獨立的到達間隔時間。第二個 M 聲明服務時間遵循相同的指數型態，彼此獨立，且與到達流無關。1 則聲明正好由一個伺服器依 FIFO 處理排隊，擁有無限等候空間，且呼叫母體實際上為無限。這三個字元共同界定出排隊現實中一條狹窄的切片，而後續的公式僅在這個切片內成立。
還有兩項假設默默伴隨：系統必須已達到穩態，使長期平均值不再漂移，而且到達率 λ 必須嚴格小於服務率 μ。若缺少這些條件，產生 L、Lq、W 與 Wq 的公式就不會有意義的有限解。任何標示為 M/M/1 計算機的工具都隨身帶著這些限制，無論介面長什麼樣，這也正是你即將使用的這個頁面，對單一伺服器問題是刻意合適，而對多伺服器問題則是刻意不合的原因。
為何 M/M/1 無法模擬多個伺服器
單一伺服器的假設直接寫在公式之中，不只是標籤而已。使用率寫作 ρ = λ/μ，是單一伺服器忙碌的時間比例，因此結果被限制在零與一之間。平均總時間 W = 1/(μ − λ) 是顧客在由單一伺服器服務的系統中所花的平均時間。當你擁有兩個伺服器共用一條排隊時，每個伺服器的忙碌比例變成 λ/(cμ)，而系統時間的公式形狀也隨之改變，因為工作量可以分散到 c 個平行處理器上。把多個伺服器塞進一個公式預設為單一伺服器的工具，會悄悄地產生出看似合理、但卻大幅低估等候時間的數字。
這是結構性的問題，而不是缺少功能。多伺服器系統擁有本質上不同的馬可夫鏈：一個到達可以被任何閒置的伺服器服務，系統中正被服務的顧客人數最多可以上升到 c，排隊才開始增長，且穩態機率帶有只有在 c = 1 時才會消失的組合項。把多伺服器系統改稱為「μ 變大的 M/M/1」並無法還原正確答案，因為 M/M/1 中的 μ 是單一伺服器的服務率，不是合併後的吞吐量。正確的做法是切換到一個知道伺服器數量、並使用 Erlang-C 等候機率的模型。
應該改用的多伺服器模型
| 特性 | M/M/1 | M/M/c |
|---|---|---|
| 伺服器數量 | 1 | c ≥ 2 |
| 穩態條件 | λ < μ | λ < cμ |
| 每個伺服器的使用率 | λ/μ | λ/(cμ) |
| 工作量分布 | 單一指數服務 | 相同的指數服務，由任何閒置伺服器接手下一個到達 |
| 適用時機 | 單一自助櫃台、單一 CPU 核心、單一結帳通道 | 銀行出納員小組、客服中心團隊、匯入單一 FIFO 線的多通道排隊 |
針對 c 個相同伺服器加上 Poisson 到達的常見情形，M/M/c 模型會產生圍繞 Erlang-C 機率（亦即一位到達顧客必須等候直到所有伺服器都忙碌的機率）建構的封閉式表達式。若服務時間不是指數分布，這個家族還會進一步延伸：M/D/c 處理確定性服務，M/G/c 處理具已知均值與變異數的一般服務，而有限容量變體則限制等候室的大小。選擇正確的模型是任何容量規劃工作中最關鍵的一步，因為所有下游指標都取決於它。
如何逐步計算 M/M/1 指標
排隊理論計算機會在本機完成運算，一旦你提供兩個服務率，就會回報所有五項穩態指標。三個簡短步驟就能涵蓋整個工作流程。
- 使用相同的時間單位輸入正的到達率 λ 與服務率 μ，例如兩者都以「每位顧客每小時」為單位，使最終的 W 與 Wq 以小時為單位。
- 確認 μ 大於 λ，並確認 Poisson 到達、指數服務、單一 FIFO 伺服器，以及穩態對你所評估規模的系統而言是合理的假設。
- 計算並檢視使用率、Lq、L、Wq 與 W，然後把這些指標連同其單位詮釋複製到你的工作表或容量討論中。
輸出背後的 M/M/1 公式
| 指標 | 公式 | 白話意義 |
|---|---|---|
| 使用率 (ρ) | λ/μ | 單一伺服器忙碌的時間比例 |
| 閒置機率 | 1 − ρ | 伺服器空閒的時間比例 |
| 系統中平均人數 (L) | λ/(μ − λ) | 正在被服務的顧客加上等候中的顧客 |
| 平均等候人數 (Lq) | λ²/[μ(μ − λ)] | 排隊中、未在伺服器前的顧客 |
| 平均總時間 (W) | 1/(μ − λ) | 從到達到離開的時間 |
| 平均排隊等候時間 (Wq) | λ/[μ(μ − λ)] | 在服務開始前所花的等候時間 |
在實作上，這個計算機會在 1e-12 到 1e12 之間、並嚴格遵守 0 < λ < μ 的條件下驗證同單位的服務率，計算上述每條公式，拒絕任何不穩定或非有限的結果，並交叉檢驗 Little 定律，使 L 等於 λW、Lq 等於 λWq，容差控制在浮點精度範圍內。輸入值同時會避開數值下溢，並加以限縮，使每個顯示的數字都是有限且易於閱讀的。
解讀輸出：一個完整範例
在 λ = 9 與 μ = 10（兩者皆為每小時到達數）的情況下，每個指標都可以用手算驗證，以確認工具在接近飽和時的行為。替換步驟與結果詳列於後，讓公式到數字的路徑清晰可見。
- 使用率：ρ = λ/μ = 9/10 = 0.9，因此單一伺服器有 90% 的時間是忙碌的。
- 系統中平均人數：L = λ/(μ − λ) = 9/(10 − 9) = 9。
- 平均等候人數：Lq = λ²/[μ(μ − λ)] = 81/(10 × 1) = 8.1。
- 平均總時間：W = 1/(μ − λ) = 1/1 = 每位顧客 1 小時。
- 平均排隊等候時間：Wq = λ/[μ(μ − λ)] = 9/(10 × 1) = 0.9 小時。
Little 定律對兩條恆等式做了交叉檢查：λW = 9 × 1 = 9 = L，而 λWq = 9 × 0.9 = 8.1 = Lq。這個工具在內部計算相同的恆等式，並在報告時不帶捨入誤差。值得注意的是，90% 的使用率產生了一條深達九人的隊伍，以及整整一小時的總時間；這種非線性是 M/M/1 的真實特徵，而不是瑕疵。當 λ 由下方向 μ 靠近時，分母會縮小，預期等候時間會無界地增大，這也正是計算機拒絕任何 λ ≥ μ 輸入的原因。
M/M/1 假設失效的時機
真實系統違反 M/M/1 假設的頻率，比符合這些假設的頻率還高。到達可能是排程性或突發性，而非 Poisson；服務時間可能近乎固定（例如條碼掃描）、具厚尾特性（例如偶爾會卡住的請求），或依請求類型而有所不同。系統中可能有多個伺服器、有限的等候空間、優先順序類別、顧客放棄、伺服器輪休、批次處理，或隨時段而變動的服務率。只要上述任何一項成立，單一伺服器的指數模型就會開始偏離實際觀察。一個快速感受這種偏差的方式，是把計算機預測的尾端行為（它隱含地假設了指數尾端）與你實際量測到的第 95 百分位進行比較。若兩者不一致，這個模型就不適用於這個工作。
兩份教學參考資料更深入地涵蓋了背後的數學：Princeton 入門演算法筆記以程式範例介紹 M/M/1，而佛羅里達大學基礎排隊理論筆記則逐步推導相關公式。請把這個計算機視為一份教學參考、單一伺服器容量的粗略基線，或是課本習題的驗算工具。在據此決定人力或容量配置之前，請以觀察資料驗證到達與服務分布、選擇合適的排隊模型、檢視變異性與百分位數，並審視錯誤可能帶來的後果。
若你正在權衡各種選項，在 M/M/1 中，80% 的使用率代表 80% 的等候時間嗎？對此有詳細說明。
若你正在權衡各種選項，計算 M/M/1 排隊時如何避免錯誤對此有詳細說明。