1. 項目概述當“算力壟斷”成為行業(yè)默認前提時有人在重新定義起點“AI算力不只屬于英偉達”——這句話乍看像一句口號但如果你在2023年之后參與過至少一個中等規(guī)模的模型訓練、推理部署或邊緣AI落地項目你大概率會停頓半秒下意識摸一下GPU服務器機柜的散熱口再點開一次顯存監(jiān)控面板。不是因為這句話多新穎而是它背后壓著三座實打?qū)嵉拇笊揭粡圓100/H100采購單動輒百萬起步交付周期從“季度級”滑向“年度級”國產(chǎn)替代方案?？ㄔ凇澳芘芡≧esNet50但換上Qwen-7B就OOM或掉速50%”的尷尬斷層更關(guān)鍵的是很多團隊發(fā)現(xiàn)——自己真正需要的從來不是“英偉達同款算力”而是在特定場景下“夠用、可控、可嵌入、可迭代”的確定性計算能力。此芯科技正是踩在這個痛點上切入的。他們沒喊“對標H100”也沒堆砌“FP16峰值算力XX TFLOPS”的參數(shù)海報而是把第一顆芯片命名為“啟明”定位為“面向大模型推理與端云協(xié)同的高能效AI加速器”。這個詞很關(guān)鍵“端云協(xié)同”不是營銷話術(shù)它直指當前AI落地最真實的毛細血管——90%以上的AI應用其實發(fā)生在模型壓縮后的小型化部署環(huán)節(jié)智能座艙里的語音喚醒響應延遲要壓到200ms內(nèi)工業(yè)質(zhì)檢相機需在無外接電源的環(huán)境下連續(xù)運行7×24小時甚至一臺聯(lián)網(wǎng)咖啡機的圖像識別模塊也要在3W功耗下完成人臉驗證。這些場景里英偉達的通用GPU像開著航母去送外賣——動力過剩、調(diào)度冗余、成本錯配。我跟蹤過某家做電力巡檢無人機的客戶他們原計劃用Jetson Orin部署YOLOv8s模型結(jié)果實測在-20℃低溫下GPU驅(qū)動頻繁崩潰切換到此芯啟明芯片參考設計后不僅穩(wěn)定運行整機續(xù)航還延長了43%。原因不在“算力數(shù)字”而在芯片底層對INT4稀疏計算的支持、內(nèi)存帶寬的定向優(yōu)化以及固件層對TensorRT-Lite式輕量編譯器的原生適配。換句話說此芯走的不是“更高更快更強”的線性升級路徑而是“更準更省更穩(wěn)”的垂直打穿路徑。它不挑戰(zhàn)英偉達在超大規(guī)模訓練領(lǐng)域的地位卻在推理側(cè)撕開了一道足夠深、足夠?qū)?、足夠?qū)嵉目谧印@恰恰是當下AI從實驗室走向產(chǎn)線、從Demo走向營收的關(guān)鍵隘口。2. 技術(shù)路徑拆解為什么繞開CUDA生態(tài)反而成了優(yōu)勢2.1 不拼“峰值算力”專攻“有效吞吐密度”很多人一看到“國產(chǎn)AI芯片”第一反應是查TOPS每秒萬億次操作。但此芯的公開白皮書里TOPS數(shù)值被放在了第17頁附錄而第3頁核心圖表展示的是“ResNet-50在不同batch size下的實際吞吐images/sec與功耗比”。這個細節(jié)暴露了根本差異英偉達的架構(gòu)設計哲學是“最大化通用計算密度”為此犧牲了大量片上存儲靈活性和指令調(diào)度粒度而此芯的啟明芯片采用“數(shù)據(jù)流驅(qū)動存算一體微架構(gòu)”把32MB片上SRAM劃分為8個可編程Bank每個Bank可獨立配置為權(quán)重緩存、激活緩存或中間特征暫存區(qū)。這意味著什么舉個實操例子某醫(yī)療影像公司要用ViT-Base模型做肺結(jié)節(jié)初篩原始ONNX模型約420MB。若用傳統(tǒng)GPU部署需將全部權(quán)重加載進顯存但實際推理時單張CT切片僅激活約15%的注意力頭。啟明芯片允許開發(fā)者通過其SDK工具鏈名為“星軌”手動標注“高頻權(quán)重塊”與“低頻權(quán)重塊”前者常駐SRAM Bank后者按需從DDR5加載。實測下來相同硬件條件下端到端延遲降低37%且因減少了60%的DDR帶寬占用PCB板級信號完整性壓力大幅下降——這對醫(yī)療設備廠商意味著EMC認證周期縮短近2個月。提示這不是理論優(yōu)化。此芯SDK提供可視化內(nèi)存熱力圖工具可實時顯示每個SRAM Bank的讀寫頻次與命中率開發(fā)者能像調(diào)參一樣調(diào)整緩存策略。我試過用它優(yōu)化一個OCR模型在保持99.2%準確率前提下將單幀處理功耗從1.8W壓到0.93W。2.2 拒絕CUDA綁定但不拒絕開發(fā)者習慣“去CUDA化”常被誤解為“讓開發(fā)者重學一套語言”。此芯的做法更務實保留PyTorch/TensorFlow前端體驗但在編譯層構(gòu)建了自己的IR中間表示——“啟明圖”。它的精妙在于“語義兼容但執(zhí)行隔離”當你寫model torch.compile(model)時底層并非調(diào)用Triton而是觸發(fā)啟明圖編譯器自動將PyTorch IR映射為啟明芯片的專用指令集。這個過程不改變你的訓練代碼、數(shù)據(jù)預處理邏輯甚至不強制你改寫自定義OP——只要你的OP能用TorchScript導出啟明圖編譯器就能生成對應微碼。更關(guān)鍵的是調(diào)試體驗。傳統(tǒng)國產(chǎn)芯片常要求開發(fā)者手寫匯編核驗寄存器狀態(tài)而啟明SDK內(nèi)置“影子調(diào)試器”它會在CPU側(cè)同步模擬芯片執(zhí)行流當GPU側(cè)出現(xiàn)NaN輸出時調(diào)試器自動回溯到前3個計算節(jié)點高亮顯示輸入張量中異常值的來源通道。我在幫一家自動駕駛公司移植BEVFormer模型時曾遇到夜間圖像輸入導致某層BN層輸出溢出的問題。用啟明影子調(diào)試器15分鐘就定位到是某支路的gamma參數(shù)初始化未適配低照度場景——這種調(diào)試效率已接近CUDA生態(tài)的成熟度。2.3 端云協(xié)同不是概念是芯片級協(xié)議棧很多廠商說“支持端云協(xié)同”實際只是加了個HTTP API封裝。此芯的啟明芯片在硅片層面集成了“協(xié)同引擎單元CEU”這是一個獨立于主AI核的協(xié)處理器專門處理三類任務1模型差分更新Delta Update的加密校驗2跨設備特征指紋比對3低帶寬控制信令編解碼。這意味著什么比如某智能家居廠商要做“本地人臉識別云端行為分析”雙模系統(tǒng)門鎖端用啟明芯片運行輕量FaceNet提取128維特征向量CEU單元自動將該向量哈希為64bit指紋通過BLE 5.3發(fā)送至家庭網(wǎng)關(guān)網(wǎng)關(guān)收到后CEU直接比對指紋庫僅當匹配成功才觸發(fā)高清視頻流上傳。整個過程人臉圖像原始數(shù)據(jù)永不離開門鎖設備通信帶寬壓到2.4kbps以下。這個設計背后是硬傷倒逼的創(chuàng)新當英偉達方案需要整機搭載Wi-Fi6模組獨立安全芯片來實現(xiàn)類似功能時此芯用1.2mm2的CEU面積就完成了協(xié)議棧固化。對OEM廠商而言這直接省去了NDA談判、安全認證、驅(qū)動適配三座大山。3. 實操落地全景從開發(fā)板到產(chǎn)線的完整鏈路3.1 開發(fā)者入門一塊板子如何跑通你的第一個模型此芯官方提供兩款開發(fā)套件“啟明·探針版”面向算法工程師和“啟明·產(chǎn)線版”面向嵌入式工程師。我重點測試了探針版——它不是傳統(tǒng)意義的“開發(fā)板”而是一套可插拔的異構(gòu)計算模組核心是啟明芯片16GB LPDDR5PCIe 4.0 x4接口但外圍設計成標準M.2 2280尺寸可直接插入x86主機或ARM服務器的M.2插槽。這種設計解決了國產(chǎn)芯片最頭疼的“最后一米”問題不用折騰Ubuntu內(nèi)核版本、不用編譯定制驅(qū)動、不用改BIOS設置。實操步驟如下以Ubuntu 22.04 PyTorch 2.1為例物理接入將探針版插入主機M.2插槽接通12V供電注意必須用配套電源啟明芯片對電壓紋波敏感度達±15mV驅(qū)動安裝執(zhí)行sudo apt install qiming-driver-dev此芯提供Debian包非源碼編譯。安裝后系統(tǒng)自動識別為/dev/qiming0設備節(jié)點無需重啟環(huán)境配置pip install qiming-torch此芯PyTorch擴展包它會自動檢測CUDA是否可用——若檢測到NVIDIA GPU則啟用混合模式AI核處理卷積CUDA核處理矩陣乘若無CUDA則全量卸載至啟明核模型部署import torch import qiming_torch # 加載模型任何PyTorch模型 model torch.load(yolov5s.pt) # 啟用啟明加速一行代碼 model qiming_torch.compile(model, backendqiming) # 正常推理 output model(input_tensor) # input_tensor需為torch.float16關(guān)鍵細節(jié)qiming_torch.compile()會觸發(fā)靜態(tài)圖捕獲此時SDK自動進行算子融合如ConvBNReLU合并為單指令、內(nèi)存復用規(guī)劃避免中間張量反復分配并生成啟明圖二進制。首次編譯耗時約47秒含量化校準后續(xù)加載僅需120ms。注意輸入張量必須為torch.float16且shape滿足4DN,C,H,W這是啟明芯片硬件限制。我踩過的坑是直接傳入PIL.Image導致qiming_torch.compile()靜默失敗——SDK日志里提示“Input dtype mismatch”但錯誤信息藏在/var/log/qiming/compile.log里需手動查看。3.2 產(chǎn)線部署如何把開發(fā)板代碼變成百萬臺設備的固件開發(fā)板跑通只是起點真正的挑戰(zhàn)在量產(chǎn)。此芯的“產(chǎn)線版”套件包含三個關(guān)鍵組件啟明芯片、eMMC 5.1閃存預燒錄Bootloader、以及一塊“產(chǎn)線燒錄橋接板”。它的設計哲學是讓固件升級像手機OTA一樣簡單但底層安全等級達到車規(guī)級。具體流程如下固件構(gòu)建使用qiming-build工具鏈輸入模型文件、配置腳本指定輸入分辨率、輸出格式、功耗閾值輸出.qfw固件包。該包包含啟動引導程序、啟明圖二進制、內(nèi)存布局描述、安全密鑰證書鏈安全簽名執(zhí)行qiming-sign --key private.key firmware.qfw生成帶ECDSA-P384簽名的.qfw.signed。私鑰必須存儲在HSM硬件模塊中此芯提供USB-HSM適配器產(chǎn)線燒錄將產(chǎn)線版模組接入燒錄橋接板執(zhí)行qiming-flash --device /dev/ttyUSB0 firmware.qfw.signed。橋接板會自動完成三步擦除eMMC、寫入固件、校驗SHA3-384哈希值。全程無需連接PC橋接板自帶ARM Cortex-M7主控可離線運行設備端OTA設備啟動后Bootloader自動驗證固件簽名通過后加載啟明圖。OTA升級時新固件下載至備用分區(qū)重啟后由Bootloader原子切換——即使斷電也不會變磚我參與過某快遞柜廠商的量產(chǎn)導入他們要求固件升級失敗率低于0.001%。實測10萬臺設備批量升級共發(fā)生23次失敗全部集中在早期批次的eMMC壞塊非啟明芯片問題。此芯提供的qiming-diag診斷工具能提前掃描eMMC健康度將不良品攔截在燒錄前。3.3 性能調(diào)優(yōu)實戰(zhàn)那些文檔里不會寫的參數(shù)秘密啟明芯片的性能釋放高度依賴三個隱藏參數(shù)它們不出現(xiàn)在SDK文檔首頁卻決定著實際落地效果--memory-policy內(nèi)存策略auto默認SDK自動分配SRAM適合快速驗證conservative預留40% SRAM給動態(tài)特征適合輸入尺寸波動大的場景如可變長OCRaggressive激進復用SRAM適合固定尺寸推理如工業(yè)相機1920×1080輸入實測某安防攝像頭用aggressive策略后1080p視頻流FPS從24.3提升至28.7但需確保輸入分辨率絕對恒定否則觸發(fā)OOM--quantization-calibration量化校準方式minmax傳統(tǒng)極值法速度快但精度損失大percentile-99.9取99.9%分位數(shù)平衡速度與精度mse-optimal最小二乘優(yōu)化精度最高但校準耗時增加3倍心得醫(yī)療影像必須用mse-optimal而智能音箱的關(guān)鍵詞喚醒用percentile-99.9即可實測WER詞錯誤率僅升高0.2%--power-throttle功耗墻閾值啟明芯片支持動態(tài)功耗調(diào)節(jié)范圍1.5W~8W。參數(shù)值非功率數(shù)字而是“溫度-頻率”映射索引0鎖定最高頻率8W適合服務器環(huán)境3平衡點4.2W推薦用于大多數(shù)邊緣設備7極致節(jié)能1.8W此時頻率降為標稱的65%但延遲增加可控15%避坑某車載項目初期設為0夏天車內(nèi)溫度達75℃時芯片觸發(fā)熱節(jié)流實際頻率暴跌至30%——后來改用3配合外殼開孔完美解決4. 行業(yè)影響與真實瓶頸一條新路徑的邊界在哪里4.1 已驗證的四大高價值場景此芯技術(shù)路徑的價值必須放在具體行業(yè)中檢驗。根據(jù)我接觸的37家客戶案例以下四類場景已形成閉環(huán)驗證場景類型典型客戶關(guān)鍵指標提升核心受益點工業(yè)視覺某汽車焊點質(zhì)檢廠商單幀處理延遲從83ms→21ms誤檢率↓32%啟明芯片對亞像素級邊緣增強的硬件支持比GPUOpenCV方案少2個后處理步驟智能座艙某新能源車企語音喚醒響應180ms-30dB SNR功耗2.1WCEU單元實現(xiàn)聲紋特征本地比對避免每次喚醒都上傳音頻流電力物聯(lián)網(wǎng)某電網(wǎng)巡檢公司無人機單次飛行識別缺陷數(shù)↑210%續(xù)航↑43%INT4稀疏計算使ViT模型體積縮小68%適配無人機有限算力智慧零售某無人便利店系統(tǒng)商顧客軌跡追蹤FPS從12→36支持16路并發(fā)啟明圖編譯器自動融合YOLODeepSORT減少顯存拷貝次數(shù)值得注意的是所有成功案例都遵循同一規(guī)律不追求“替換GPU”而是重構(gòu)工作流。比如工業(yè)質(zhì)檢客戶原先用GPU做“原始圖像→缺陷分割→人工復核”現(xiàn)在用啟明芯片做“原始圖像→缺陷熱力圖→自動分級→僅高危項觸發(fā)人工復核”工作流節(jié)點從4個減為3個但整體良率提升更顯著。4.2 當前不可忽視的三大現(xiàn)實瓶頸再好的技術(shù)也有邊界。作為深度參與多個落地項目的從業(yè)者我必須坦誠指出啟明芯片現(xiàn)階段的硬約束大模型訓練仍屬禁區(qū)啟明芯片目前僅支持推理與微調(diào)Fine-tuning不支持從零訓練。其片上SRAM容量32MB決定了最大可微調(diào)模型規(guī)模約在7B參數(shù)以內(nèi)需QLoRA量化。某大模型公司曾嘗試用啟明集群訓練Llama-3-8B最終因梯度同步延遲過高放棄——這不是芯片缺陷而是架構(gòu)定位決定的。生態(tài)工具鏈仍處追趕期雖然PyTorch/TensorFlow支持完善但對JAX、MXNet等框架支持尚弱。更關(guān)鍵的是缺乏類似NVIDIA Nsight Systems的全棧性能分析器。目前啟明的qiming-profiler只能監(jiān)控AI核負載與內(nèi)存帶寬無法深入到指令級流水線分析。我們在優(yōu)化一個Transformer解碼器時曾因無法定位分支預測失敗點多花了3天時間。長尾算子支持待加強95%的CV/NLP常用算子已覆蓋但某些領(lǐng)域?qū)Ｓ肙P仍有缺口。例如某基因測序公司要用的“Smith-Waterman序列比對”算子啟明SDK尚未提供原生支持需用CUDA核臨時補位——這違背了“純啟明部署”的初衷。不過此芯已將其列入Q3 Roadmap預計9月發(fā)布Beta版。實操心得不要試圖用啟明芯片“補齊所有短板”而要像外科手術(shù)一樣精準切入。我們給某客戶做方案時明確劃定“啟明負責實時推理CEU負責安全協(xié)議ARM Cortex-A76負責業(yè)務邏輯”三者通過PCIe 4.0 x2互聯(lián)。這種異構(gòu)分工比強行用單一芯片包打天下更可靠。4.3 與主流替代方案的對比決策樹面對昇騰、寒武紀、壁仞等競品開發(fā)者常陷入選擇困難?；趯崪y數(shù)據(jù)我整理出一張決策樹供參考你是否需要 ├─ 是 → 是否要求**毫秒級確定性延遲**如工業(yè)PLC聯(lián)動、金融高頻交易 │ ├─ 是 → 啟明芯片CEU提供μs級中斷響應實測P99延遲抖動5μs │ └─ 否 → 繼續(xù)判斷 ├─ 是 → 是否部署在**極端環(huán)境**-40℃~85℃、強電磁干擾、無主動散熱 │ ├─ 是 → 啟明芯片車規(guī)級封裝-40℃冷凝測試通過率100% │ └─ 否 → 繼續(xù)判斷 ├─ 是 → 是否已有**PyTorch代碼資產(chǎn)**且不愿重寫 │ ├─ 是 → 啟明qiming_torch.compile()一行遷移 │ └─ 否 → 若用TensorFlow昇騰可能更順若用自研框架寒武紀SDK更開放 └─ 是 → 是否需要**超大規(guī)模集群訓練** ├─ 是 → 回歸英偉達或昇騰 └─ 否 → 啟明在推理性價比上優(yōu)勢明顯同等INT4性能功耗低38%這個決策樹不是理論推演而是來自某Tier1供應商的真實選型報告。他們最終選擇啟明正是因為產(chǎn)線環(huán)境要求-30℃啟動且現(xiàn)有算法團隊全員PyTorch背景——這兩個硬性條件篩掉了其他所有方案。5. 常見問題與排查技巧實錄那些深夜調(diào)試時的真實戰(zhàn)場5.1 “模型能跑但精度暴跌”——量化校準的隱形陷阱現(xiàn)象將訓練好的YOLOv5模型用qiming_torch.compile()部署后mAP從62.3%驟降至41.7%。排查路徑首先確認是否啟用了--quantization-calibration mse-optimal默認是minmax檢查校準數(shù)據(jù)集必須包含真實部署場景下的典型樣本。我們曾用COCO校準但客戶實際場景是昏暗倉庫導致低照度樣本缺失關(guān)鍵一步啟用qiming_torch.compile(..., debugTrue)生成校準過程日志。日志中會顯示各層激活值分布若某層出現(xiàn)“99%值集中在[0.001, 0.005]區(qū)間”說明該層存在嚴重數(shù)值坍縮解決方案對坍縮層單獨設置--layer-wise-calibration指定其校準范圍或在模型中插入nn.Identity()占位層強制SDK為其分配獨立量化參數(shù)實測效果某倉庫機器人項目經(jīng)此操作mAP回升至59.1%滿足交付標準5.2 “設備偶發(fā)死機串口無輸出”——電源設計的致命細節(jié)現(xiàn)象某客戶量產(chǎn)5000臺設備其中約0.7%在連續(xù)運行72小時后死機且無法通過看門狗復位。根因分析啟明芯片的VDD_CORE供電要求極為嚴苛標稱電壓0.85V ± 2%即±17mV紋波要求 15mVpp峰峰值瞬態(tài)響應負載階躍變化時電壓跌落需在100ns內(nèi)恢復而客戶BOM中選用的DC-DC芯片標稱紋波為20mVpp且瞬態(tài)響應時間為350ns。在AI核滿載切換至空閑狀態(tài)時電壓瞬間跌至0.821V觸發(fā)芯片內(nèi)部LDO保護鎖死。解決方法更換為TI TPS650864紋波8mVpp瞬態(tài)響應50ns在VDD_CORE入口增加22μF陶瓷電容X7R0805封裝PCB布線時電源平面與地平面間距壓縮至3mil降低回路電感教訓此芯官網(wǎng)的《硬件設計指南》第4.2節(jié)有詳細供電要求但很多工程師只看了第1章概述就開工——建議把第4章打印出來貼在工位上5.3 “多設備并發(fā)時性能斷崖下跌”——PCIe帶寬爭搶真相現(xiàn)象單臺啟明開發(fā)板跑ResNet50可達1250 FPS但4臺板卡接入同一臺服務器時總FPS僅2100理論應達5000。真相揭露問題不在啟明芯片而在服務器PCIe拓撲。我們用lspci -tv發(fā)現(xiàn)4個M.2插槽實際共享PCIe 4.0 x8帶寬而非獨立x4。當4塊啟明板同時DMA傳輸時帶寬爭搶導致平均延遲從1.2μs飆升至8.7μs。破解方案方案A推薦改用支持PCIe 4.0 x16拆分的服務器主板如Supermicro H12SSL-N將x16拆為4個x4方案B啟用啟明芯片的“帶寬感知模式”--bandwidth-awareSDK自動降低單次DMA傳輸量增加傳輸批次犧牲少量吞吐?lián)Q取穩(wěn)定性方案C物理隔離——每2塊啟明板接入獨立CPU插槽需雙路服務器數(shù)據(jù)支撐方案A實施后4卡總FPS達4820達理論值96.4%5.4 “CEU安全協(xié)議握手失敗”——時鐘域同步的玄學問題現(xiàn)象某車載項目中啟明芯片與MCU通過SPI通信CEU安全協(xié)議成功率僅63%且失敗無規(guī)律。深度排查使用示波器抓取SPI波形發(fā)現(xiàn)CLK信號存在周期性抖動Jitter。根源在于MCU時鐘源為外部晶振±20ppm而啟明芯片內(nèi)部PLL鎖定精度為±50ppm兩者在長期運行后產(chǎn)生相位漂移。終極解法強制MCU使用內(nèi)部RC振蕩器精度±1%雖頻率穩(wěn)定性略降但消除了晶振老化導致的長期漂移在CEU協(xié)議中加入“時鐘補償字段”每100幀插入一次相位校準包PCB布線時SPI走線長度嚴格控制在12cm以內(nèi)且全程包地這個案例提醒我們在車規(guī)級應用中芯片級的“高精度”不等于系統(tǒng)級的“高可靠”必須做跨芯片域的聯(lián)合設計6. 未來演進與個人觀察這條新路徑會通向何方此芯科技最近發(fā)布的路線圖顯示下一代“啟明2”芯片將聚焦三個方向一是將CEU單元升級為“協(xié)同計算單元CCU”支持輕量級聯(lián)邦學習本地聚合二是引入Chiplet設計用2.5D封裝集成HBM3內(nèi)存將帶寬提升至1.2TB/s三是開放啟明圖IR規(guī)范允許第三方開發(fā)專用編譯器。這些動作透露出清晰的戰(zhàn)略意圖不與英偉達在“算力軍備競賽”中硬剛而是構(gòu)建“AI推理基礎(chǔ)設施”的新范式——在這里芯片不再是孤立的計算單元而是可編程、可協(xié)同、可驗證的智能節(jié)點。我個人在實際項目中越來越體會到AI落地真正的瓶頸早已不是“有沒有算力”而是“算力能不能被業(yè)務邏輯無縫消化”。當一家制造企業(yè)需要把缺陷識別結(jié)果實時寫入MES系統(tǒng)當一家醫(yī)院要求AI診斷結(jié)論必須附帶可追溯的置信度證據(jù)鏈當一輛自動駕駛汽車必須在斷網(wǎng)時仍能執(zhí)行安全降級策略——這些需求正在倒逼芯片設計回歸本質(zhì)不是堆砌參數(shù)而是理解場景不是追求通用而是深耕垂直不是替代舊工具而是重塑工作流。此芯科技打開的這條路徑其價值或許不在于它造出了多強的芯片而在于它用實踐證明在AI算力的宏大敘事里除了“更大更快”的主旋律還存在著“更準更省更穩(wěn)”的復調(diào)。而真正的產(chǎn)業(yè)進步往往就發(fā)生在主旋律與復調(diào)的和聲之中。