Skip to content

Blog

Nano Banana Pro 完全指南

Nano-Banana Pro 相較於前幾代產品實現了重大飛躍,從「娛樂性」圖像生成躍升至「功能性」專業資產製作。它在文字渲染、字元一致性、視覺合成、世界知識(搜尋)和高解析度 (4K) 輸出方面表現卓越。

本文內容包括:

  1. 提示的黃金法則
  2. 文字渲染、資訊圖表與視覺合成
  3. 角色一致性與病毒式傳播的縮圖
  4. 利用Google搜尋進行基礎分析
  5. 進階編輯、修復和著色
  6. 維度轉換(2D ↔ 3D)
  7. 高解析度和紋理
  8. 思考和推理
  9. 一次性故事板與概念藝術
  10. 結構控制與佈局指導
  11. 下一步是什麼?

提示的黃金法則

Nano-Banana Pro 是一款「思考型(Thinking)」模型。它不只是匹配關鍵字,還能理解意圖、物理原理和構圖。為了獲得最佳效果,請停止使用「標籤大雜燴」(例如:狗、公園、4K、逼真),並像創意總監一樣進行創作。

持續編輯,不要都重新開始

該模型非常擅長理解 對話式修改。如果圖片已有 80% 的正確度,就不要從頭開始產生新圖。只需提出您需要的具體修改即可。

例如:"這很棒,但請將燈光改為日落色,並將文字改為霓虹藍色。"

使用自然語言和完整句子

與模型交流時,要像指導藝術家創作一樣。使用正確的語法和描述性的形容詞。

❌ Bad: "酷炫的汽車, 霓虹燈, 城市, 夜晚, 8K"

✅ Good: "電影般的廣角鏡頭展現了一輛未來感十足的跑車在雨夜的東京街道上疾馳。霓虹燈的光芒倒映在濕漉漉的路面和汽車的金屬底盤上。"

要具體、描述清楚

模糊的提示只會得到千篇一律的結果。要明確主題、場景、光線和氛圍。

主題: 不要說 "一位女士",而要說"一位穿著復古香奈兒風格套裝的優雅老婦人"。

材質: 描述質感。"霧面", "拉絲鋼", "柔軟天鵝絨", "皺紙"。

提供背景資訊(「為什麼」或「為了誰」)

因為模型會 思考,所以給它背景資訊有助於它做出合乎邏輯的藝術決定。

例如: "為一本巴西高端美食食譜創作一張三明治的圖片。"(該模型將推斷出專業的擺盤、淺景深和完美的照明)。

文字渲染、資訊圖表與視覺合成

Nano-Banana Pro 具備最先進的功能,能夠渲染出清晰易讀、風格化的文本,並將複雜的資訊合成為視覺格式。

最佳實踐:

  • 壓縮: 請模型將密集文字或 PDF 檔案「壓縮」成視覺化輔助資料。
  • 風格: 請指定您想要「精美編輯風格」、「技術圖表風格」或「手繪白板風格」。
  • 引用: 請明確指定需要用引號括起來的文字。

壓縮 範例:

獲利報告資訊圖:

輸入Google最新財報的PDF檔

"生成一份簡潔現代的 Infographic,概括這份財報的關鍵財務亮點。包含盈利增長和淨利潤圖表,並在風格化的引言框中突出顯示CEO的關鍵語錄。"

風格 範例-01:

復古資訊圖表:

"製作一張復古的、20世紀50年代風格的 infographic,介紹美國餐廳的歷史。內容應包含「食物」、「點唱機」和「裝飾」等不同部分。確保所有文字清晰易讀,並符合當時的風格。"

風格 範例-02:

技術圖解:

"繪製一份正投影藍圖,以平面圖、立面圖和剖面圖的形式描述建築物。使用專業建築字體清晰標註「北立面」與「主入口」。格式為16:9。"

Image title
上傳圖片給 Nano Banana 模型

Image title
Nano Banana 模型生成的圖片

風格 範例-03:

白板摘要:

如何設定 JupyterLab 環境

原文: https://docs.vultr.com/how-to-set-up-a-jupyterlab-environment-on-ubuntu-22-04

介紹

JupyterLab 為資​​料科學和人工智慧專案提供基於 Web 的開發環境。它是一個靈活的介面,允許開發人員配置和管理機器學習和科學計算工作流程。 JupyterLab 是下一代 Jupyter Notebook。它旨在解決 Notebook 的許多可用性問題,並透過支援 40 多種程式語言(包括 R、Python、Scala 和 Julia)大大擴展了其使用的範圍。

先決條件

在開始之前,您應該:

  • 部署 Ubuntu 22.04 伺服器。
  • 建立一個非 root sudo 使用者。

Docker Inside Docker

Docker 無疑以其輕量級、可移植的容器改變了軟體開發和部署的世界。但是如果我告訴你 Docker 本身可以在另一個 Docker 容器中運作呢?恩,那就對了!這個概念通常被稱為 "Docker Inside Docker" 或 "DinD",為開發人員和系統管理員開闢了一個全新的可能性領域。在這篇文章中,我們將探索嵌套容器化的世界,討論它的眾多好處、各種用例以及在 Docker 中啟動 Docker 的逐步過程。那麼,讓我們深入了解一下吧!

了解 Docker Inside Docker

簡單來說,Docker Inside Docker 涉及在 Docker 容器內執行 Docker。容器內產生了一個新的 Docker 引擎,而不是與主機的 Docker 守護程式交互,為管理容器和映像提供了一個隔離的環境。

Docker Inside Docker 的好處

1. Isolated Development and Testing:

在 Docker 中執行 Docker 允許開發人員創建專門為其應用程式量身定制的隔離環境。這可確保依賴項、配置和執行時間環境在不同的開發階段保持一致,從而更輕鬆地重現和偵錯問題。

2. Enhanced Security and Isolation:

在 Docker 中執行 Docker 允許開發人員創建專門為其應用程式量身定制的隔離環境。這可確保依賴項、配置和執行時間環境在不同的開發階段保持一致,從而更輕鬆地重現和偵錯問題。

3. Simplified CI/CD Pipelines:

Docker Inside Docker 廣泛應用於持續整合和持續部署 (CI/CD) 工作流程。它支援創建用於建置、測試和部署應用程式的獨立的一次性環境,從而實現更快、更可靠的自動化管道。

4. Multi-tenancy and Resource Management:

在多個團隊或使用者需要共用基礎架構上的隔離環境的情況下,嵌套容器化非常有用。透過在 Docker 內部啟動 Docker,可以為每個團隊或使用者提供單獨的 Docker 引擎,確保資源隔離並防止不同應用程式之間的干擾。

使用 Poetry 管理依賴關係以及建置和發布 Python 套件

原文: How to Manage Dependencies and Build & Publish Python Packages using Poetry

本教程涵蓋:

  1. Poetry Installation
  2. Setup project with poetry
  3. A brief introduction to pyproject.toml
  4. Creating a virtual environment with poetry
  5. Dependency management using poetry
  6. Create a Python package
  7. Build a package with Poetry
  8. Publish package with Poetry on PyPI

在建立 Python 套件時,開發人員通常會依賴外部程式庫或不屬於 Python 標準庫的依賴項。手動管理這些第三方函式庫的安裝、卸載或更新是一項繁瑣的任務。這些第三方函式庫具有額外的外部相依性的情況並不罕見,這使得手動管理相依性變得更加複雜。

幸運的是,Python 有依賴管理工具,可以讓第三方函式庫的管理變得更容易。 Poetry 是其中一個值得注意的工具,它不僅有助於依賴管理,還負責創建虛擬環境以及建置和發布 Python 套件。

在本教程中,我們將使用 Poetry 建立、建構和發布一個命令列工具,該工具接收國家/地區名稱作為輸入並輸出其對應的 Alpha3 程式碼。

在 Pycharm 配置 Poetry 環境

原文: Configure a Poetry environment

Poetry 是一個有助於根據專案依賴關係建立 Python 虛擬環境的工具。您可以聲明您的專案所依賴的程式庫,Poetry 將為您安裝和更新它們。

專案依賴項記錄在 pyproject.toml 檔案中,該檔案指定所需的套件、腳本、外掛程式和 URL。有關其結構和格式的更多信息,請參閱 pyproject 參考。

要在 PyCharm 中使用 Poetry,您需要將其安裝在您的電腦上並建立特定的 Python 環境。

如何建立第一個 Python 套件並將其上傳到 PyPI

原文: How to Create and Upload Your First Python Package to PyPI

Python package 檔案結構

在開始之前,我們應該知道在 Python 中套件的含義。

Python 套件是一個目錄,其中包含一堆模組以及名為 __init__.py 的依賴檔案。該檔案可以完全為空,您可以使用它來將磁碟上的目錄標記為 Python 套件。

下面顯示了套件目錄的範例:

package/
├──__init__.py
├──module_a.py
├──module_b.py
└──module_c.py

__init__.py 是一個依賴文件,可協助 Python 在套件目錄中尋找可用模組。如果我們刪除這個文件,Python 將無法導入我們的模組。

建立 Python 套件並將其發佈到 PyPI

PyPI 是 Python Package Index 的縮寫,是 Python 程式語言的官方第三方套件儲存庫。它是一個中央儲存庫,託管和分發軟體包供 Python 開發人員使用。

開發人員可以將 Python 套件上傳到 PyPI,其他人可以輕鬆存取這些套件。這些套件可以包括函式庫、框架、實用程式和工具來擴展和增強 Python 的功能。

本文將介紹 PyPI 的優點、套件的元件以及如何建立 PyPI 套件。

什麼是 PyPI?

PyPI 用於尋找和安裝專案的套件。它允許開發人員輕鬆管理依賴項並簡化應用程式的安裝過程。借助 PyPI,他們可以透過重複使用現有程式碼而不是從頭開始編寫所有內容來節省時間和精力。

PyPI 由 Python 軟體基金會 (PSF) 維護,可供開發人員和最終用戶免費使用。它是 Python 生態系統的重要組成部分,為該語言的流行和發展做出了貢獻。

在 Python 中,套件是一種分層組織相關模組、函數和類別的方式。它提供了一種捆綁程式碼的結構化方法,可以將其視為包含一個或多個 Python 模組的目錄。它有助於組織程式碼並使其更易於管理和分發。

Package 通常包含一個 init.py 文件,該文件在導入套件時執行。它可以定義包級屬性、函數和類,可供套件中的其他模組存取。 init.py 檔案也可以包含導入語句以從其他套件導入模組和函數。

可以使用 pip 等套件管理器來安裝和管理 Python 套件,pip 可以自動下載並安裝所需的依賴項。

透過套件,開發人員可以將相關功能封裝到一個單元中,從而更容易重複使用和維護程式碼。例如,流行的 NumPy 套件提供了處理數組和矩陣的功能,而 Pandas 套件提供了用於資料分析和操作的工具。

Personal Copilot: 訓練自己的程式設計助手

在不斷發展的程式設計和軟體開發領域,對效率和生產力的追求帶來了顯著的創新。其中一項創新就是 Codex、StarCoder 和 Code Llama 等程式碼產生模型的出現。這些模型在產生類似人類的程式碼片段方面表現出了卓越的能力,從而顯示出作為編碼助手的巨大潛力。

然而,雖然這些預先訓練的模型可以在一系列任務中表現出色,但還有一個令人興奮的可能性:能夠根據您的特定需求定製程式碼產生模型。想想可以在企業規模上利用的個人化編碼助手。

在這篇文章中,我們展示瞭如何建立 HugCoder 🤗,這是一個根據 Huggingface GitHub 組織的公共儲存庫中的程式碼內容進行微調的程式碼 LLM。我們將討論我們的資料收集工作流程、訓練實驗和一些有趣的結果。這將使您能夠根據您的專有程式碼庫創建您自己的個人副駕駛。我們將為您留下該項目的一些進一步擴展以供實驗。

讓我們開始吧🚀

資料收集工作流程

我們想要的資料集在概念上很簡單,我們的結構如下:

Repository Name Filepath in the Repository File Contents
--- --- ---

使用 Python GitHub API 從 GitHub 抓取程式碼內容非常簡單。然而,根據儲存庫的數量以及儲存庫中程式碼檔案的數量,人們可能很容易遇到 API 速率限制問題。

為了防止此類問題,我們決定在本地克隆所有公共儲存庫並從中提取內容,而不是透過 API。我們使用 Python 中的多處理模組並行下載所有儲存庫,如該下載腳本所示。

儲存庫通常可以包含非程式碼文件,例如圖像、簡報和其他數據資產。我們對收集它們不感興趣。我們創建了一個擴展列表來過濾掉它們。為了解析 Jupyter Notebooks 以外的程式碼文件,我們只需使用 "utf-8" 編碼。對於 Jupyter Notebooks,我們只考慮代碼單元(code cells) 裡的內容。

我們也排除了所有與程式碼不直接相關的檔案路徑。其中包括:.git、__pycache__ 和 xcodeproj。

為了保持該內容的序列化相對記憶體友好,我們使用了進行了分塊和使用 feather 格式來序列化。請參閱此腳本以了解完整的實作。

最終的hf-codegen-v2 資料集可在 Hub 上找到,如下所示:

在本文中,我們考慮了基於 stargazer 的前 10 個 Hugging Face 公共儲存庫。它們是:

  • 'transformers'
  • 'pytorch-image-models'
  • 'datasets'
  • 'diffusers'
  • 'peft'
  • 'tokenizers'
  • 'accelerate'
  • 'text-generation-inference'
  • 'chat-ui'
  • 'deep-rl-https://github.com/pacman100/DHS-LLM-Workshop/tree/main/personal_copilot/dataset_generation">程式碼,這是 Hub 中的資料集。

    為了降低專案複雜度,我們沒有考慮資料集的去重。如果您有興趣在生產應用程式中應用重複資料刪除技術,這篇部落格文章是關於 code LLMs 案例的優秀參考資源。

    微調 Personal Co-Pilot

    在本節中,我們將展示如何微調以下模型:bigcode/starcoder(15.5B 參數)、bigcode/starcoderbase-1b(1B 參數)、Deci/DeciCoder-1b(1B 參數)。我們將使用一台 A100 40GB Colab 筆記本,並使用 🤗 PEFT(參數高效微調)進行所有實驗。此外,我們將展示如何使用 🤗 Accelerate 的 FSDP 整合在具有 8 個 A100 80GB GPU 的機器上完全微調 bigcode/starcoder(15.5B 參數)。訓練目標是 fill in the middle(FIM),其中訓練序列的部分內容被移動到末尾,並且對重新排序的序列進行自回歸預測。

    為什麼選擇PEFT? 進行完全微調的成本很高。讓我們用一些數字來正確看待事情:

    完全微調所需的最小 GPU 記憶體:

    • 權重:2 bytes(混合精準度訓練)
    • 權重梯度:2 bytes
    • 使用 Adam 時的最佳化器狀態:4 bytes 於原始 FP32 權重 + 8 bytes 用於第一和第二矩估計
    • 添加所有上述內容的每個參數的成本:每個參數 16 bytes
    • 15.5B 模型 -> 248GB GPU 內存,甚至無需考慮存儲中間激活的巨大內存要求 -> 至少需要 4X A100 80GB GPU

    由於硬體要求很高,我們將使用 QLoRA 進行參數高效的微調。以下是使用 QLoRA 微調 StarCoder 的最低 GPU 記憶體需求:

    可訓練參數:110,428,160 || 所有參數:15,627,884,544 || 可訓練%:0.7066097761926236

    • 基本模型權重:0.5 byte * 15.51B 凍結參數 = 7.755 GB
    • 適配器權重:2 bytes * 0.11B 可訓練參數 = 0.22GB
    • 權重梯度:2 bytes * 0.11B 可訓練參數 = 0.12GB
    • 使用 Adam 時的最佳化器狀態:4 byes * 0.11B 可訓練參數 * 3 = 1.32GB
    • 加總上述對於記憶體的所有內容 -> 9.51 GB ~ 10GB -> 需要 1 個 A100 40GB GPU。使用 A100 40GB GPU 的原因是,訓練時長序列長度為 2048 且批量大小為 4 的中間激活會導致更高的記憶體需求。如下所示,所需的 GPU 記憶體為 26GB,A100 40GB GPU 可以容納。此外,A100 GPU 與 Flash Attention 2 具有更好的兼容性。

    在上面的計算中,我們沒有考慮中間激活檢查點所需的內存,該內存相當大。我們利用 Flash Attention V2 和梯度檢查點來解決這個問題。

    • 對於 QLoRA 以及 Flash attention V2 和梯度檢查點,模型在單一 A100 40GB GPU 上佔用的總記憶體為 26 GB,批次大小為 4。
    • 對於使用 FSDP 以及 Flash Attention V2 和梯度檢查點進行完全微調,每個 GPU 佔用的記憶體範圍在 70 GB 到 77.6 GB 之間,per_gpu_batch_size 為 1。

    請參閱 model-memory-usage 情況,輕鬆計算在 🤗 Hugging Face Hub 上託管的模型上訓練和執行大模型推理所需的 vRAM 量。

    完整微調

    我們將了解如何使用 PyTorch 全分片資料並行 (FSDP) 技術在 8 個 A100 80GB GPU 上對 bigcode/starcoder(15B 參數)進行全面微調。有關 FSDP 的更多信息,請參閱使用 PyTorch FSDP 微調 Llama 2 70B 和使用 PyTorch 全分片資料並行加速大型模型訓練。

    資源

    透過 run_fsdp.sh 來啟動訓練的指令。

    acceleratelaunch--config_file"configs/fsdp_config.yaml"train.py\
--model_path"bigcode/starcoder"\
--dataset_name"smangrul/hf-stack-v1"\
--subset"data"\
--data_column"content"\
--split"train"\
--seq_length2048\
--max_steps2000\
--batch_size1\
--gradient_accumulation_steps2\
--learning_rate5e-5\
--lr_scheduler_type"cosine"\
--weight_decay0.01\
--num_warmup_steps30\
--eval_freq100\
--save_freq500\
--log_freq25\
--num_workers4\
--bf16\
--no_fp16\
--output_dir"starcoder-personal-copilot-A100-40GB-colab"\
--fim_rate0.5\
--fim_spm_rate0.5\
--use_flash_attn

    總訓練時間為9小時。根據 lambdalabs 計算 8 個 A100 80GB GPU 的成本為 12.00 美元/小時,總成本為 108 美元。

    PEFT

    接下來我們將了解如何使用 QLoRA 使用 🤗 PEFT 在單一 A100 40GB GPU 上微調 巷bigcode/starcoder(15B 參數)。有關 QLoRA 和 PEFT 方法的更多信息,請參閱 Making LLMs even more accessible with bitsandbytes, 4-bit quantization and QLoRA 和 🤗 PEFT: Parameter-Efficient Fine-Tuning of Billion-Scale Models on Low-Resource Hardware。

    資源

    啟動訓練的命令在 run_peft.sh 中。總訓練時間為12.5小時。根據 lambdalabs,以 1.10 美元/小時的成本計算,總成本為 13.75 美元。那就相當不錯了🚀!就成本而言,它比完全微調的成本低7.8倍。

    比較

    下圖顯示了 QLoRA 與完全微調的評估損失、訓練損失和學習率調度程序。我們觀察到,與 QLoRA 相比,完全微調會導致損失略低且收斂速度更快。 pef 微調的學習率比 full 微調的學習率高 10 倍。

    為了確保我們的 QLoRA 模型不會導致災難性遺忘,我們在其上運行了 Python Human Eval。以下是我們得到的結果。 Pass@1 衡量完成的通過率,僅考慮每個問題產生的單一候選代碼。我們可以觀察到,基本 bigcode/starcoder(15B 參數)和微調 PEFT 模型 smangrul/peft-lora-starcoder15B-v2-personal-copilot-A100-40GB-colab 在 humaneval-python 上的表現相當。

    |Model |Pass@1| |bigcode/starcoder |33.57| |smangrul/peft-lora-starcoder15B-v2-personal-copilot-A100-40GB-colab |33.37|

    現在讓我們來看一些定性樣本。在我們的手動分析中,我們注意到 QLoRA 導致了輕微的過度擬合,因此我們透過 PEFT 的 add_weighted_adapter utility 程式創建權重為 0.8 的新加權適配器來降低其權重。

    我們將看兩個程式碼填充範例,其中模型的任務是填入 <FILL_ME> 佔位符表示的部分。我們將考慮填滿來自 GitHub Copilot、QLoRA 微調模型和完整微調模型的補全。

    Qualitative Example 1

    在上面的範例中,GitHub Copilot 的補全是正確的,但沒有太大幫助。另一方面,QLoRA 的補全和完全微調的模型正確地用必要的參數填充了整個函數呼叫。然而,他們之後也增加了更多的噪音。這可以透過後處理步驟來控制,以將完成限制為右括號或新行。請注意,QLoRA 和完全微調模型都會產生類似品質的結果。

    Qualitative Example 2

    在上面的第二個範例中,GitHub Copilot 沒有給出任何補全資訊。這可能是因為 🤗 PEFT 是一個新函式庫,尚未成為 Copilot 訓練資料的一部分,而這正是我們試圖解決的問題類型。另一方面,QLoRA 的補全和完全微調的模型正確地用必要的參數填充了整個函數呼叫。

    再次請注意,QLoRA 和完全微調的模型都提供了類似的品質。 Full_Fintuned_StarCoder_Inference.ipynb 和 PEFT_StarCoder_Inference.ipynb 分別提供了完整微調模型和 peft 模型的各種範例的推理程式碼。

    因此,我們可以觀察到兩個變體的模型都符合預期。驚人! 🚀

    如何在 VS Code 中使用它?

    您可以使用 🤗 llm-vscode 來在 VS Code 中輕鬆配置自訂程式碼完成 LLM 的擴充,並透過 🤗 推理端點託管模型。我們將完成下面所需的步驟。您可以在推理端點文件中了解有關部署端點的更多詳細資訊。

    設定推理端點

    以下是螢幕截圖,其中包含我們建立自訂推理端點所遵循的步驟。我們使用 QLoRA 模型,匯出為全尺寸合併模型,可以輕鬆載入到 Transformer 中。

    設定 VS 代碼擴展

    只需按照安裝步驟操作即可。在設定中,取代下方欄位中的端點,使其指向您部署的 HF 推理端點。

    用法如下:

    微調您自己的 Code Chat Assistant

    到目前為止,我們訓練的模型被專門訓練為程式碼完成任務的個人副駕駛。他們沒有接受過進行對話或回答問題的訓練。 Octocoder 和 StarChat 是此類模型的很好的例子。本節簡要介紹如何實現這一目標。

    資源

    LoRA 之舞

    如果您曾嘗試使用 Stable Diffusion 模型和 LoRA 來製作自己的 Dreambooth 模型,那麼您可能熟悉將不同的 LoRA 與不同權重相結合的概念,即使用具有與訓練時不同的基礎模型的 LoRA 模型。在文字/程式碼領域,這仍然是未開發的領域。我們在這方面進行了實驗,並觀察到了非常有希望的發現。你準備好了嗎?我們走吧! 🚀

  • in LLM
  • 10 min read

在生產環境中優化您的 LLM

原文: Optimizing your LLM in production

GPT¾、Falcon 和 LLama 等大型語言模型 (LLM) 處理以人為中心的任務的能力正在迅速提高,成為現代知識型產業的重要工具。然而,在現實世界的任務中部署這些模型仍然具有挑戰性:

  • 為了展現接近人類的文本理解和生成能力,LLM 目前需要由數十億個參數組成(參見 Kaplan 等人、Wei 等人)。因此,這放大了推理的記憶體需求。
  • 在許多現實世界的任務中,LLM 需要獲得廣泛的背景資訊。這需要模型能夠在推理過程中管理很長的輸入序列。

這些挑戰的關鍵在於增強 LLM 的計算和儲存能力,特別是在處理廣泛的輸入序列時。

在這篇文章中,我們將回顧撰寫本文時最有效的技術,以應對高效 LLM 部署的這些挑戰:

  1. Lower Precision: 研究表明,降低的 LLM 模型參數的數值精度(即 8-bit 和 4-bit)可以實現計算優勢,而不會顯著降低模型性能。
  2. Flash Attention: Flash Attention 是 attention 演算法的變體,它不僅提供了一種更節省記憶體的方法,而且由於優化了 GPU 記憶體利用率而實現了效率的提高。
  3. Architectural Innovations: 考慮到 LLM 在推論過程中總是以相同的方式部署,即具有長輸入上下文的自回歸文本生成 (autoregressive text generation),因此提出了專門的模型架構,以實現更有效的推論。模型架構中最重要的進展是 Alibi、Rotary embeddings、Multi-Query Attention (MQA) 和 Grouped-Query-Attention (GQA)。

在本文的範示筆記本中,我們將從張量的角度對自迴歸產生進行分析。我們深入研究了採用較低精度的利弊,對最新的注意力演算法進行了全面的探索,並討論了改進的 LLM 架構。在此過程中,我們運行實際範例來展示每項功能改進。

AltStyle によって変換されたページ (->オリジナル) /